Bài bổ sung của prof rất tốt, alice chỉ nghĩ có thể bài viết sẽ dễ hiểu hơn nếu thay đổi vài điểm về thuật ngữ. )

prof wrote:

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ố (Digital Signature - DS) đượ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 DS 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.  

Dùng từ ICV là đủ, tránh dùng từ DS. ICV nói chung không phải là DS và thực tế không phải là DS.

prof wrote:

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 thường được xem như là sự kết hợp của IPSec với NAT. ESP thường được sử dụng trong chế độ tunnel. 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.  

Chỗ IPSec màu vàng có vẻ khó hiểu. Đối tượng đang được giải thích là IPSEC. ESP là một phần của IPSEC. Sẽ không hợp lý lắm khi đem IPSEC để giải thích ESP.

Khi đưa TCP/UDP vào cuộc, cũng nên nói rõ hoàn cảnh sử dụng là ESP bao bọc TCP/UDP. Để phân biệt với hoàn cảnh UDP bao bọc ESP (NAT-T) mà loạt bài sẽ nói đến về sau.

prof wrote:

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. 

Đoạn này có thể xem như có 2 phần:

Phần NAT màu vàng thứ nhất nói về tính tương thích của NAT với ESP. Ở đây nên làm rõ thêm từ NAT bởi một từ khác (thí dụ, basic NAT theo tự điển wikipedia), ngụ ý rằng ở đây chỉ có dịch địa chỉ mà thôi. Cũng nên nói rõ thêm NAT trong trường hợp chung (bao hàm PAT) với ESP trong chế độ tunnel là không tương thích bởi vì khác với TCP/UDP, ESP không có khái niệm "cổng". Như thế người đọc sẽ không phải thắc mắc đại loại như nếu ESP tunnel và NAT đã tương thích với nhau, tại sao phải dùng UDP bao bọc ESP để có NAT-T?

Phần NAT màu vàng thứ hai nói về tính tương thích của NAT với IKE, cũng nên nói rõ hơn một chút (nhưng chính alice cũng chưa biết nói thế nào cho rõ ), tránh cho người đọc những thắc mắc kiểu như tại sao khác với nhiều giao thức trên nền TCP/UDP, IKE phải cố định cổng nguồn?.

prof wrote:

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 payload của ESP cũng đủ để nói lên nguồn gốc của gói tin này!  

Theo alice, cụm từ payload của ESP có lẽ sửa thành IP payload hoặc cụ thể hơn 1 chút thì ESP header mới đúng. Như chính prof đã nói, authentication trailer xác thực không những ESP payload mà còn cả ESP header, trong đó có SPI (security parameter index), từ đó dựa theo SAD (security association database) tra được địa chỉ IP của người gửi. Nói cách khác, với một chi phí tính toán thích đáng, cài đặt không cần phải xác thực IP header vẫn xác thực được địa chỉ IP nguồn của gói tin.


Cám ơn thangdiablo, prof, Mr. Khoai và các bạn khác vì một loạt bài lý thú. )