Hello thangdiablo,

Bài viết của bạn rất hay. Tuy nhiên, có một số điểm, prof nghĩ, nếu được đào sâu thêm một chút, sẽ hoàn thiện hơn.

- Nếu sử dụng giao thức ESP :
Thì giao thức ESP sẽ làm công việc là mã hóa ( encryption ) , xác thực ( authentication ) , bảo đảm tính trọn vẹn của dữ liệu ( Securing of data ) . Sau khi đóng gói xong bằng ESP mọi thông tin về mã hóa và giải mã sẽ nằm trong ESP Header .
Các thuật toán mã hóa bao gồm DES , 3DES , AES
Các thuật toán để xác thực bao gồm MD5 hoặc SHA-1
ESP còn cung cấp tính năng anti-relay để bảo vệ các gói tin bị ghi đè lên nó.

- Nếu sử dụng giao thức AH
Thì giao thức AH chỉ làm công việc xác thực ( authentication ) và bảo đảm tính trọn vẹn dự liệu . Giao thức AH không có chức năng mã hóa dự liệu . Do đó AH ít được dùng trong IPSec vì nó không đãm bảo tính an ninh .
 

Lý do AH có khả năng cung cấp cơ chế xác thực và bảo đảm tính toàn vẹn (integrity) của dữ liệu là vì AH Header chứa một "chữ ký số" -1- được gọi là giá trị kiểm tra tính toàn vẹn (Integrity Check Value-ICV). Thực chất nó là một giá trị băm được dùng để kiểm tra xem liệu gói tin có bị thay đổi trên đường truyền hay không. Vì AH sử dụng IP header để tính toán ICV nên chúng ta có thể chắc chắn rằng địa chỉ nguồn của gói tin là xác thực và gói tin này xuất phát từ đúng nơi gửi.

Hơn nữa, AH cũng sử dụng các giá trị sequence number hỗ trợ việc chống lại kiểu tấn công phát lại (replay attack). Vì các thiết bị truyền thông sử dụng giá trị này để theo dõi dòng dữ liệu trao đổi, một kẻ tấn công với ý định chiếm quyền truy cập vào VPN không thể gửi lại gói tin mà hắn "bắt" được.

Ngoài ra, một vấn đề cần lưu tâm ở đây, đó là AH xác thực gói tin dựa vào thông tin IP header. Do vậy, nó sẽ không tương thích với các thay đổi do cơ chế NAT mang lại. Vì giá trị ICV của AH đã được tính toán trước NAT nên khi gói tin được gửi tới đích, việc kiểm tra tính toàn vẹn sẽ thất bại(!)

Mặt khác, vì AH không hỗ trợ bảo vệ tính mật (confidentiality) của dữ liệu trong các gói tin, nên nó sẽ không phải thực hiện tính toán nhiều để mã hoá các gói tin, do đó công việc xử lý và đóng gói các gói tin sẽ dễ dàng và nhanh chóng hơn. Đây là những đặc điểm góp phần làm cho AH trở thành một giải pháp hợp lý cho những nơi chỉ cần bảo toàn và xác thực thông tin địa chỉ IP và cần hiệu năng cao.

Để có thể xem thông tin chi tiết về một AH packet, bạn có thể dùng tcpdump để thu bắt thông tin về AH traffic. Khi đó, bạn sẽ thấy phần payload của gói tin sẽ không được mã hoá vì AH không hỗ trợ cơ chế này.

....
4 . Giao thức ESP
Phía dưới đây là cơ chế mã hóa gói dữ liệu bằng giao thức ESP

Esp là giao thức hỗ trợ cả xác thực và mã hóa .

Phía trên là gói dự liệu ban đầu và ESP sẽ dùng 1 cái key để mã hóa toàn bộ dữ liệu ban đầu . Và trường hợp trên là Ipsec đang chạy ở chế độ Tunel mode nên ngoài ESP header ra nó sẽ sinh ra 1 Ip Header mới không bị mã hóa để có thể truyền đi trong mạng Internet .

....
 

Cách thức hoạt động của ESP có khác biệt đôi chút phụ thuộc vào chế độ làm việc của IPSec. Trong chế độ Transport, ESP chỉ đơn thuần thêm phần header của bản thân nó vào sau phần IP header và mã hoá toàn bộ phần còn lại của gói tin từ tầng 4 trở lên. Nếu trong quá trình thương lượng khởi tạo một IPSec connection có chỉ định sử dụng dịch vụ xác thực của ESP, khi đó ESP sẽ thêm một phần (trailer) chứa thông tin ICV để đảm bảo tính toàn vẹn và tính xác thực. Không giống với AH, ESP ICV không tính toán dựa trên các thông tin về IP header.

ESP là giải pháp cho phép IPSec chạy trên hệ thống có xảy ra quá trình NAT với điều kiện IPSEC được thiết lập ở chế độ tunnel -2-. Tuy nhiên trong chế độ transport, ESP và NAT không tương thích với nhau vì các thông tin của phần header của gói tin đã bị NAT thay đổi. Khi NAT thực hiện thay đổi phần thông tin về IP, nó cũng sẽ tính lại giá trị checksum trong TCP header. Và bởi vì TCP checksum được tính toán không chỉ dựa vào TCP header, mà nó còn dựa vào các thông tin từ IP header, như địa chỉ nguồn/đích của gói tin nên NAT đã phá vỡ tính toàn vẹn của gói tin. Trong chế độ Transport ESP, toàn bộ TCP header đã được mã hoá, NAT box sẽ không thể tính toán lại TCP checksum. (Vấn đề tương tự đối với UDP packets khi UDP checksum được tính đến). Kết quả là trước khi giải mã, gói tin sẽ bị hủy vì không bảo đảm tính toàn vẹn. Vấn đề này có thể được giải quyết nếu như không đụng đến TCP checksum trong mọi trường hợp.

Trong chế độ Tunnel ESP, NAT hoàn toàn được tương thích vì toàn bộ gói tin nguồn bao gồm các thông tin về IP và thông tin ở tầng 4 được đóng gói và do đó không bị xử lý bởi NAT. Vì thông tin về IP, TCP header, TCP checksum không bị thay đổi trong chế độ Tunnel ESP nên gói tin sẽ được giải mã và thoả mãn tính toàn vẹn. Tuy nhiên, mặc dù ESP traffic trong chế độ Tunnel có thể tương thích với NAT, bạn sẽ gặp phải các vấn đề liên quan đến NAT khi thương lượng các tham số cho IPSec connection. Chẳng hạn, one-to-many NAT (thường được hiểu là PAT) sẽ sửa đổi tham số cổng nguồn của một outbound IKE packet, dẫn đến giá trị cổng UDP 500 dành cho IKE bị thay đổi, từ đó dẫn đến việc thất bại khi phân phối khoá cho các tham số của IPSec session.

Một vấn đề còn đang tranh cãi nữa là khả năng xác thực của ESP. Như ta đã biết, ESP có khả năng cung cấp cơ chế xác thực, nhưng giá trị băm mà nó sử dụng được sinh ra dựa trên toàn bộ gói tin ngoại trừ phần IP header và phần authentication trailer. Điều này giúp cho ESP authentication tương thích với NAT, nhưng việc thiếu xác thực của IP header sẽ không đảm bảo được nguồn gốc của gói tin. May thay, trong hầu hết các cài đặt, việc kiểm tra tính xác thực cho phần IP payload -3- cũng đủ để nói lên nguồn gốc của gói tin này!

Chúc vui.

-------------
-1- và -3-: chỉnh sửa theo góp ý của alice.
-2-: chỉnh sửa theo góp ý của father_nghia_den.