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á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 . 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 cũng đủ để nói lên nguồn gốc của gói tin này!
No comments:
Post a Comment