AH hay ESP? Quyết định theo thứ mà gói tin phải bảo vệ

Hai đề xuất IPsec có thể nêu cùng một thuật toán toàn vẹn dựa trên SHA mà vẫn yêu cầu các giao thức bảo vệ khác nhau; AH và ESP không phải hai cách viết của một thiết lập xác thực. Đọc giao thức trước, rồi đến các thuật toán của nó, rồi đến chế độ của nó, và phần lớn sự mơ hồ biến mất. AH xác thực gói tin, kể cả những trường tiêu đề IP không đổi trên đường đi, trong khi ESP xác thực và mã hóa nội dung nó bao gói và để yên tiêu đề ngoài. Chính khác biệt đó quyết định nhiều triển khai hơn bất kỳ tên hàm băm nào.

Điều AH bao phủ mà ESP không

AH cung cấp tính toàn vẹn, xác thực nguồn dữ liệu và dịch vụ chống phát lại do nó tự định nghĩa, và không có chút bí mật nào. Phạm vi của nó gồm dữ liệu tầng trên và các trường tiêu đề IP mà quy tắc của nó coi là bất biến, đúng phần mà ESP trong chế độ vận chuyển để ra ngoài. Khi yêu cầu nói rằng phải xác thực chính tiêu đề IP, AH là giao thức đáp lại điều đó.

Phạm vi này cũng là lý do AH mong manh trong thực tế. Các trường thay đổi như TTL, tổng kiểm tra tiêu đề và một số tùy chọn không thể xác thực vì bộ định tuyến có thể ghi lại chúng, nên giao thức đặt chúng về không trước khi tính kiểm tra. Vì vậy bất cứ thứ gì ghi lại địa chỉ đều phá vỡ phép tính, chứ không chỉ phá vỡ chính sách.

NAT biến lựa chọn thành ràng buộc

Dịch địa chỉ ghi lại nguồn hoặc đích trong tiêu đề IP mà AH vừa xác thực, nên kiểm tra toàn vẹn thất bại ở đầu kia, và thất bại như một lỗi giao thức chứ không phải một thông báo đọc được. ESP không xác thực tiêu đề ngoài, vì thế ESP có xuyên NAT hoạt động còn AH sau NAT thì không. Một đường hầm với hai đầu nằm sau các bộ định tuyến thông thường chính là nơi điều này xuất hiện trước tiên. Vì vậy câu hỏi đầu tiên không phải giao thức nào mạnh hơn, mà là có bộ chuyển đổi nằm giữa hai đầu hay không.

Nếu có, AH bị loại, và cuộc trao đổi chuyển sang ESP cùng các lựa chọn thuật toán của nó. Đây là ràng buộc chứ không phải sở thích, nên nó thuộc về đầu quyết định chứ không phải cuối.

Chế độ nhân câu hỏi lên

ESP trong chế độ vận chuyển bảo vệ tải trọng tầng trên và để yên tiêu đề IP; trong chế độ đường hầm nó bao gói toàn bộ gói bên trong, kể cả tiêu đề IP bên trong, và bảo vệ gói đó. AH cũng có hai chế độ như vậy, nên AH hay ESP thực ra là bốn tổ hợp trước khi chọn bất kỳ thuật toán nào.

Các thuật toán ESP ở chế độ kết hợp sau đó giải quyết tính toàn vẹn mà không cần giao thức thứ hai. AES-GCM và ChaCha20-Poly1305 xác thực và mã hóa trong một cấu trúc, nên thêm AH lên trên không mua được gì mà còn tốn thêm một tiêu đề và một vòng thương lượng. Kiến trúc cho phép AH và ESP cùng tồn tại, và câu hỏi thực tế là cổng và bản phát hành của bạn có hỗ trợ tổ hợp đó không và sau này ai đó có bảo trì được không.

Sự thay thế trung thực cho riêng AH

Biến thể ESP chỉ có toàn vẹn giữ lại thuật toán và bỏ tuyên bố mã hóa thay vì giả tạo nó, và nó vượt qua NAT. Nếu một thiết kế cũ dùng AH vì cần xác thực mà không cần bí mật, thì biến thể đó chính là bản dịch trực tiếp, chứ không phải một đường hầm mã hóa kèm ghi chú.

Thấy ESP trong một đề xuất cũng không phải bằng chứng của mã hóa. Hãy đọc thuật toán mã hóa: mục NULL nghĩa là chỉ toàn vẹn, còn mục chế độ kết hợp nghĩa là cả hai.

Quyết định bằng ba câu hỏi

Hỏi xem có cần bí mật không, trên đường có bộ chuyển đổi không, và những trường tiêu đề nào phải được xác thực. Ba câu trả lời đó chỉ ra một giao thức và một chế độ, và việc ghi chúng lại tốn ít thời gian hơn đọc lại RFC sau này.

Sau đó kiểm chứng điều đã được chấp nhận chứ không phải điều đã được đề xuất. ip xfrm state hiển thị giao thức, chế độ và thuật toán của liên kết đã cài đặt, và sự không khớp sẽ không cài gì cả, đó là một thất bại sạch sẽ hơn một đường hầm dựng lên mà không có sự bảo vệ như dự định.

Hãy tách các lỗi xác thực, phạm vi bộ chọn và lỗi định tuyến ra khỏi lựa chọn này. Chúng cho triệu chứng khác nhau, và đổ lỗi cho giao thức vì một vấn đề bộ chọn là cách chắc chắn để mất một ngày đổi hàm băm mà không có lý do.