Chào cả nhà,
Chào alice,

Prof rất vui khi nhận được comments từ alice, father_nghia_den, và thangdiablo. Mấy ngày qua mình khá bận nên việc reply có phần chậm trễ. Mong các bạn thông cảm. Bây giờ ta tiếp tục thảo luận nhé. )

alice wrote:

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ữ. )
 

Uhm, mục đích của bài viết bổ sung cho loạt bài của bạn thangdiablo là nhằm đào sâu hơn một chút về những thứ mà thangdiablo chưa có dịp đề cập đến. Rõ ràng, bài viết sẽ không thành công nếu như tạo thêm sự khó hiểu cho người đọc. Vì vậy, trong quá trình thảo luận, mình sẵn sàng "thay đổi vài điểm về thuật ngữ" nhằm giúp độc giả *tiêu hóa* tốt hơn. Cũng cần nói thêm là bài bổ sung trên được viết khá gấp rút, nên không thể tránh khỏi thiếu sót. Góp ý của các bạn sẽ giúp bài viết thêm phần hoàn thiện. )

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.
 

Trước tiên, hoàn toàn đồng ý với alice ở điểm ICV không phải là DS. ) Tuy nhiên, khi viết đoạn này, ý đồ của mình không nhằm so sánh DS và ICV. Mình tuy là kẻ *ngâm cứu* không chuyên về applied crypto. & its related stuffs nhưng cũng may mắn hiểu được sự khác biệt về phạm vi ứng dụng, và về bản chất của DS. Trong phạm vi bài này, mình sử dụng DS với mục đích giúp người đọc hiểu được những lợi điểm do ICV đem lại, kiểu như dùng một thuật ngữ đã quen thuộc để giải thích cho một thuật ngữ mới hơn. Có lẽ chúng ta đều biết DS có khả năng cung cấp tính xác thực (Authentication), tính toàn vẹn (Integrity), và tính chống phủ nhận (Non-repudiation). ICV trong AH Header cũng hội đủ các điều kiện để cung cấp 2 trong 3 khả năng này. Vì vậy, ở một khía cạnh hẹp & trực quan nào đó, ICV mang đặc điểm của DS.

Mình cũng đã từng gặp ở một số tài liệu khác, khi đề cập đến một intemediate device/application/middleware/..., người viết thường mượn thuật ngữ proxy server nhằm mục đích nói lên tính trung gian của đối tượng đang xét, mặc dù nếu khắt khe hơn, thì proxy server không thể là đối tượng mà họ đang bàn. Đó chỉ là một ví dụ khá *thô* về cách dùng thuật ngữ mà thôi. )

Anyway, có lẽ mình đã lạm dụng thuật ngữ DS này nên dẫn đến hiểu lầm. Prof sẽ chỉnh sửa lại đoạn này bằng việc bỏ đi thuật ngữ 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. 

Yep! Câu trên đúng là gây khó hiểu. Rất may mắn, bạn father_nghia_den đã giải thích lại giúp một cách hợp lý. Thanks father_nghia_den. )

Đ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?
 

Thanks alice. Mình quả thật đã thiếu xót khi không đề cập đến khía cạnh NAT-T trong IKE.

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?. 

Chà, xem ra "người đọc" muốn mở rộng thêm vấn đề về tính tương thích giữa NAT và việc cố định cổng nguồn của IKE đây. Trường hợp này, có lẽ phải mời người tham khảo thêm RFC 3715 để biết chi tiết. ) Phải thừa nhận một điều là còn khá nhiều vấn đề giữa NAT và IPSec mà prof chưa thể nói hết. Bởi vậy, ngay từ đầu, mình chỉ dám đi sâu một chút, vì biết sẽ không đủ sức. Nếu alice hay bạn nào đó có thời gian, các bạn có thể bổ sung thêm những vấn đề mà mình chưa đề cập đến.

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.
 

Đồng ý! )