Đề tài IPSEC và triển khai hệ thống IPSEC/VNP trên windows server 2003

xuất hiện.SG2 thiết lập transport mode SA với giả định rằng nó là ngõ vào duy nhất với N2 do đó nó có thể bắt được tất cả các gói tin và thực hiện xác thực trước khi các gói tin đến H2.Nếu bất kì một gói tin nào được định tuyến thông qua SG3 thì quá trình tổng hợp sẽ diễn ra không chính xác.Trường hợp 1 ,SG2 xác thực mỗi gói tin nó nhận được và cố gắng tổng hợp chúng lại .Tuy nhiên vì không phải tất cả các phân mảnh đều đi qua SG2,nên gói tin đang tổng hợp dở sẽ bị hủy bỏ khi thời gian tổng hợp hết(reasembly timer expires).Cùng lúc đó phân mảnh đến SG3 có thể bị SG3 hủy bỏ hoặc chuyển tiếp đến H2,tại đây không xác định được SA phù hợp cho phân mảnh trên ,nên nó bị hủy bỏ.Trong trường hợp 2 ,SG2 cố gắng tổng hợp các gói tin trước khi xác thực chúng.Tuy nhiên kết quả vẫn diễn ra tương tự như trường hợp1.Đây là trường hợp xấu nhất.Nhưng trên thực tế tình huống này lại xảy ra với tần suất đáng báo động.Minh họa trên lý giải vì sao phải áp dụng tunnel mode giữa hai gateway. -Để chống quá trình phân mảnh ,các gateway cần phải thông báo với các host mà nó bảo vệ về kích thước header mà nó có thể thêm vào gói được gửi bởi host đó.Host ban đầu thường cố gắng gửi các gói tin có kích thước xấp xỉ PMTU (path maximum tranmisstion unit).Chỉ cần trừ đi kích thước header mà các security gateway phải thêm vào thì quá trình phân mảnh có thể tránh được. Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 20 Ngoài ra còn có một cách tránh việc phân mảnh.Host ban đầu có thể kiểm tra mô hình mạng để xác định giá trị PMTU và dựa vào đó để điều chỉnh kích thước gói tin cho phù hợp.Kĩ thuật này trong Ipv4 đòi hỏi host source phải bật bit DF (Don’t fragment) lên một,để tránh việc phân mảnh tại các router trung gian.Cách làm này có thể làm xuất hiện vấn đề khi áp dụng đối với IPSEC.Nếu một gói tin có kích thước quá lớn ,không thể đi qua toàn bộ các route, khi đó một router trung gian sẽ gửi một ICMP với thông điệp là “gói tin quá lớn” đến host ban đầu.Trong trường hợp tunnel mode SA,gói ICMP sẽ được gửi đến cho security gateway có địa chỉ là điạ chỉ source trong outer header.Vấn đề rất nghiêm trọng đặt ra là khi gói tin ICMP trên không phải được gửi từ đích đến cuối cùng của thông điệp mà là từ một router trung gian.Điều này lại càng nghiêm trọng khi áp dụng IPSEC vì trong ipsec các gói tin đều phải xác thực rõ nguồn gốc.Gateway sau khi nhận được gói tin trên sẽ phải lựa chọn giữa các phương án:Liệu có thể tin tưởng thông điệp trong gói ICMP chưa xác thực trên hay không ? Nếu tin tưởng thì phải chuyển tiếp gói tin ICMP trên cùng với số PMTU mới đến host nguồn ban đầu( trong inner header).Nếu gateway không chuyển tiếp gói tin ICMP trên về host nguồn thì một lỗ hổng lớn sẽ xuất hiện:Host nguồn tiếp tục gửi các gói tin với cờ DF được bật lên vì nó không bao giờ nhận được gói tin thông báo về số PMTU mới, do đó nó không giảm kích thước của gói tin.Do đó các gói tin cứ tiếp tục được gửi đi làm tăng truyền thông trên mạng một cách vô ích vì chúng không bao giờ đến được đích cuối cùng. Việc sử dụng các gói tin ICMP để gửi thông điệp về PMTU có thể bị lợi dụng để tấn công deny of service.Một attacker gửi một gói ICMP với một số PTMU nhỏ hơn giá trị PMTU cần thiết.Nếu gateway chấp nhận gói tin ICMP chưa được xác thực này và chuyển tiếp cho host ban đầu .Host ban đầu sẽ giàm kích thước cho tất cả các gói tin lưu thông trên con đường đó.Điều này dẫn tới việc gia tăng số lượng của các gói tin có kích thước nhỏ hơn đồng nghĩa với việc gia chi phí tính toán với các vấn đề IP liên quan,có thể làm gia tăng lưu lượng trên mạng và làm giảm chất lượng dịch vụ. Một số giải pháp đưa ra để khắc phục vấn đề đưa ra về PMTU.Giải pháp đầu tiên đòi hỏi sự hợp tác giữa SG1 và SG2.SG1 cho phép các gói tin đã phân mảnh từ H1 tiếp tục con đường của chúng.Để làm được điều này nếu innner header set bit DF thì outer header không set bit này.Khi SG2 nhận được các gói tin đã bị phân mảnh.Nó gửi một số PMTU đến SG1,thông báo cho SG1 biết về kích thước của phân mảnh lớn nhất đi qua đoạn đường từ SG1 đến SG2 thành công.Bởi vì đoạn đường từ SG1 đến SG2 đã thiết lập các cơ chế bảo vệ gói tin.Gói tin PMTU này khác so với các gói tin PMTU thông thường vì PMTU được gửi sau khi đã nhận các phân mảnh.Trong khi bình thường,gói PMTU là kết quả của việc truyền không thành công một phân mảnh.Một cách khác SG2 có thể lưu trữ PMTU như một thành phần của SA và đều đặn thông báo SG1 giá trị PMTU mới nhất.Nếu H1 cố gắng gửi một gói tin có kích thước quá lớn,SG1 sẽ thông báo giá trị PMTU hiện tại với H1.Cho đến thời điểm này chưa có thêm giải pháp nào cho vấn đề này được đưa ra. 3.9.2:Mối quan hệ giữa NAT và IPSEC: Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 21 - Một NAT(network address translation) box có thể là một thực thể riêng biệt hoặc được kết hợp với các security gateway.NAT được áp dụng trong hai tình huống sau.Thứ nhất trong các mạng riêng đòi hỏi tính bí mật nhằm bảo đảm tính bảo mật và riêng tư.Thứ hai là trong các mạng riêng sử dụng các địa chỉ riêng có thể đã được sử dụng tại một nơi nào đó trong mạng internet,cách làm này nhằm tiết kiệm địa chỉ ip.Khi một gói tin đi qua NAT box .địa chỉ nguồn riêng của gói tin outbound được chuyển đổi thành một địa chỉ chung (public address) và địa chỉ đến chung của một gói tin inbound ( public destion address ) được chuyển đổi địa chỉ riêng tương ứng.Việc áp dụng NAT có thể làm cho việc xác thực AH trong transport mode bị sai.Vì trong mode này AH xác thực cả địa chỉ nguồn và địa chỉ đích.Việc thay đổi lại địa chỉ nguồn và địa chỉ đích làm cho quá trình xác thực bị sai khi gói tin tới đích.Nếu quá trình chuyển đổi NAT được diễn ra trước quá trình xử lí IPSEC cho các gói tin outbound và sau quá trình xử lí IPSEC cho các gói tin inbound cơ chế bảo vệ gateway to gateway vẫn được thỏa mãn.Hình dưới đây mô tả một trường hợp một cấu hình mạng giữa NAT và các security gateway có thể hoạt động tốt. Một giao thức IPSEC thân thiện với NAT với tên gọi realm-specific-internet protocol (RSIP) đã đuợc xuất hiện .Khi áp dụng RSIP các gói tin từ một host với địa chỉ riêng không cần sử dụng địa chỉ này cho các gói tin đích nằm ngoài mạng riêng.Host này đóng vai trò là một RSIP client có thể xin một địa chỉ ip công cộng (public ip address) từ RSIP server .Bằng cách này địa chỉ nguồn của các gói tin xuất phát là một trá trị duy nhất trong mạng internet và có thể sử dụng trong xác thực đầu cuối . 3.9.3:Cơ chế giám sát trong IPSEC: Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 22 Nếu một sự kiện được lưu trữ trong audit log thì giá trị lưu trữ cần chứa ngày ,giờ ,địa chỉ nguồn,địa chỉ đích,SPI ,riêng đối với Ipv6 thì flow ID cũng cần được lưu trữ.Ngoài ra nếu hệ thống có áp dụng khả năng giám sát với IPSEC thì cần có một cơ chế hỗ trợ admin kích hoạt hoặc vô hiệu hóa chức năng này.Các gói tin cảnh báo không yêu cầu phải gửi cho các bên vì nó có thể làm tăng truyền thông giữa các bên ảnh hưởng đến chất lượng mạng. -Một số các sự kiện được lưu trữ lại trong audit log là: +Việc cố gắng sử dụng một outbound SA có replay counter đã đạt đến giá trị max trong tình huống bên nhận có sử dụng chức năng chống phát lại. +Việc xử lí IPSEC trên một gói tin inbound đã bị phân mảnh. +Việc nhận được một gói tin inbound mà không tìm thấy SA phù hợp. +Việc nhận được một gói tin inbound mà việc kiểm tra lại tính xác thực của gói tin không đáp ứng được yêu cầu. 4. Giao thức ESP 4.1:Các cơ chế bảo vệ được cung cấp bởi cơ chế ESP ESP cung cấp hai cơ chế bảo vệ một cơ chế là của riêng ESP và một cơ chế là sự lặp lại cơ chế được cung cấp bởi AH.Các cơ chế bảo vệ sau được cung cấp bởi ESP mà không có trong AH: -Tính riêng tư (confidentialy):Điều này đảm bảo một thông điệp nếu bị bắt trên đường truyền thì bên trung gian không thể hiểu được nội dung của thông điệp mà điều này chỉ có bên gửi và bên nhận mới hiểu được. -Bảo vệ việc phân tích truyền thông(chỉ trong mode tunnel):Điều này đảm bảo rằng các bên trung gian không thể xác định được các đối tượng đang liên lạc với nhau,tần số và lượng thông tin trao đổi giữa các bên. ESP có thể cung cấp một số cơ chế bảo vệ đã được cung cấp trong AH:Tính toàn vẹn dữ liệu ,xác thực nguồn gốc ,chống phát lại. Có một số điểm khác biệt về tính toàn vẹn dữ liệu và xác thực nguồn gốc được cung cấp bởi AH và ESP .Một AH hoạt động ở transport mode bảo vệ cả tiêu đề ip và dữ liệu trong gói trong khi transport mode ESP chỉ bảo vệ dữ liệu trong gói tin.Trong chế độ tunnel cả 2 cơ chế đều bảo vệ tiêu đề ban đầu ,tuy nhiên chỉ mình AH bảo vệ tiêu đề bên ngoài.Tuy nhiên việc tạo ra SA, có thể gián tiếp xác thực địa chỉ ip do đó giúp xóa bỏ sự khác biệt này. 4.2 Cấu trúc của ESP: Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 23 ESP gồm có các trường sau: -SPI giá trị được cất vào SAD. -Sequence number:Tương tự như đối với AH. -Pay load data là gói dữ liệu ip đã được mã hóa -Padding(độ dài bất kì ) và pad length ( 8 bits) dữ liệu chèn và kích thước của nó. -Next header :Loại dữ liệu bên trong ESP. -Authentiaction data (bội số của 32 bits):Thông tin xác thực được tình trên toàn bộ gói ESP ngoại trừ phần authentiaction data. ESP header thường được chia làm bốn phần như sau: -Initial ESP header chứa SPI và sequence number. -Data chứa một số dữ liệu đặc biệt không mã hóa(nếu có),phần mở rộng tiêu đề của địa chỉ đích theo sau ESP header ( chỉ xét trong Ipv6),TCP hoặc UDP header,và dữ liệu của thông điệp. -ESP trailer chứa padding ( nếu có ),trường pad length, và trường next header -ESP authentication data chứa các dữ liệu xác thực nếu có. 4.3:Vị trí và các mode làm việc của ESP: ESP header có thể được sử dụng trong cả transport mode và tunnel mode.Hình dưới đây mô tả vị trí của ESP transport header trong cả Ipv4 và Ipv6.Trong Ipv4 nó có thể theo sau bởi ip header hoặc AH.Kế đó là trường next header (TCP,UDP,ICMP).Trong Ipv6 không hoặc nhiều tiêu đề mở rộng (hop by hop,routing,fragment,hoặc destination header option) có thể đứng trước ESP Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 24 header.Ngoài ra trường destination header option có thể đứng sau ESP header.Vị trí tương quan giữa trường này và ESP header tùy thuộc vào quá trình xử lí riêng của nó được thực hiện trước hay sau quá trình xử lí ESP.Nếu gói tin đã được mã hóa một destionation option header theo sau trường ESP header không thể được đọc bởi bất cứ một đích đến trung gian nào.Nó chỉ xuất hiện (visible ) trở lại khi quá trình xử lí ESP header mã hóa đã thực hiện ở đích đến cuối cùng. Hình tiếp theo minh họa vị trí của ESP header trong tunnel mode.Trong Ipv4 ESP header theo sau IP header mới và IP header gốc.Trong Ipv6 ESP theo sau các trường mở rộng (nếu có) như trong transport mode và đứng trước IP header gốc. Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 25 4.4: Nested và Adjacent header trong ESP Với hai loại security header việc việc áp dụng nhiều hơn một SA cho một thông điệp trở nên phức tạp hơn.Nếu adjacent header được sử dụng ( ví dụ : khi các điểm đầu cuối của cả hai SA là giống nhau),AH header sẽ đứng trước ESP header.Điều này có nghĩa là gói tin sẽ được mã hóa trước rồi mới được xác thực.Bằng cách này gói tin đã được mã hóa được bảo vệ khỏi vấn đề xáo trộn .Tuy nhiên kết quả này có thể đạt được một cách tốt hơn bằng cách sử dụng một ESP header cung cấp cả xác thực và mã hóa. Nested header thường được sử dụng thường xuyên hơn.Trong trường hợp hai(đã trình bày ở phần về AH) ,nếu 2 gateway SG1 và SG2 yêu cầu tất cả các truyền thông gateway to gateway đều được xác thực và mã hóa.Điều này có thể thực hiện bằng hai cách như sau: Thông qua một ESP SA cung cấp cả xác thực và mã hóa ,hoặc thông qua một adjacent AH và ESP SA.Đối với những gateway bảo vệ truyền thông giữa các host H1 và H2 ,SA nên là tunnel mode SA.Tuy nhiên điều này dẫn tới truyền thông giữa H1 và SG1 chưa được bảo vệ.Nếu H1 không tưởng security gateway của nó để vận chuyển truyền thông ,hoặc có một user trong mạng cục bộ của H1 không đáng tin cậy,lúc này H1 cũng cần xác thực truyền thông trong mạng cục bộ.Để đạt Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 26 được điều này ,sử dụng một nested (lồng) SA là giải pháp lí tưởng.Một cặp ESP tunnel mode SA giữa SG1 và SG2 và một cặp AH transport mode SA giữa H1 và H2.Hình dưới đây mô tả cách sử dụng của một nested SA. Trong trường hợp này khi một thông điệp được truyền từ H1 đến H2,nó có một tranport mode AH kể từ thời điểm nó rời H1 đến khi nó tới SG1.Khi nó được truyền từ SG1 đến SG2 nó kết hợp giữa AH và ESP thông qua một inner transport mode AH header và một outer tunnel mode ESP header.Khi truyền từ SG2 đến H2, lúc này nó chỉ còn transport mode AH header. 4.5 Quá trình xử lí ESP đối với các thông điệp Outbond Một số bước xử lí diễn ra tương tự như đối với AH.Những bước này sẽ không được trình bày lại chi tiết ở đây.Một khi đã xác định thông điệp Outbound được bảo vệ bởi ESP header và Outbound SA đảm nhận việc quản lí thông điệp này đã được tìm thấy hoặc được thỏa thuận,thông điệp này được chuyển sang các quá trình xử lí trong IPSEC,bao gồm các bước sau: Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 27 -1:Thêm một khuôn dạng ESP header vào vị trí thích hợp. -2:Thêm vào trường SPI bằng giá trị SPI của SA đuợc chọn. -3:Tính toán trường sequence number. -4: Nếu quá trình mã hóa diễn ra,thuật toán mã hóa phù hợp sẽ yêu cầu một số dữ liệu cần thiết ( không được mã hóa) và thêm những dữ liệu này vào gói tin. -5:Thêm tunnel header nếu cần thiết. -6:Thêm các dữ liệu còn lại của gói tin. -7:Tính toán chiều dài của phần padding nếu cần thiết.Các giá trị padding cần phải được xác định bởi một thuật toán mã hóa xác định hoặc nếu không xác định trước một thuật toán mã hóa nào một chuỗi các số tự nhiên liên tiếp có thể sử dụng làm phần padding. -8:Thêm trường next header. -9:Mã hóa thông điệp nếu SA yêu cầu mã hóa dữ liệu .Các trường packet data, padding,pad length và next header được mã hóa cùng với tunnel header của tunnel mode SA.Các thuật toán mã hóa được xác định cho quá trình xử lí IPSEC đối với ESP là DES-CBC hoặc null encycrypt algorithm.Thuật toán sau không cup cấp sự mã hóa dữ liệu.Bởi vì ESP header cần phải cung cấp tính riêng tư,tính xác thực hoặc cả hai , khi null encycrypt algortithm được sử dụng cho việc mã hóa, null authentication algorithm không được sử dụng để xác thực. -10:Tính toán dữ liệu xác thực nếu việc xác thực được yêu cầu bởi SA.Các dữ liệu được xác thực gồm có initial ESP header cũng như các dữ liệu đã được mã hóa.Thuật toán xác thực được dùng trong quá trình xử lí IPSEC đối với ESP là HMAC-MD5 ,HMAC-SHA1 và null authentication algorithm.Thuật toán cuối cùng không cung cấp sự xác thực.Bởi vì ESP header cần phải cung cấp tính toàn vẹn ,tính xác thực hoặc cả hai ,nên khi null authentication algorithm được sử dụng để xác thực thì null encycript algorithm không được sử dụng để mã hóa. -11:Phân mảnh nếu cần thiết. 4.6:Quá trình xử lí ESP đối với các thông điệp Inbound: Khi nhận được một thông điệp có chứa ESP header.Quá trình xử lí gói tin IP sẽ đảm bảo tổng hợp tất cả các phân mảnh thành một thông điệp hoàn thiện.Thông điệp sau đó được chuyển sang quá trình xử lí IPSEC,gồm các bước sau: -1:Tìm kiếm trong SAD để xác định inbound SA phù hợp để quản lí thông điệp này. -2:Nếu bên nhận có sử dụng chức năng chống phát lại,thực hiện viêc kiểm tra chống phát lại. -3:Kiểm tra tính xác thực.Nếu việc kiểm tra xác định rằng gói tin không xác thực được thì sẽ loại bỏ gói tin này,ngược lại tiếp tục chuyển sang bước tiếp theo.Việc thực hiện xác thực trước quá Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 28 trình giải mã giúp bớt chi phí tính toán mã hóa khi thông điệp đã bị xáo trộn ( không thể xác thực đúng). -4:Mã hóa phần còn lại của gói tin.Nếu quá trình giải mã không thành công hoặc kết quả giải mã bị xáo trộn so về vị trí của các trường thì thông điệp sẽ bị hủy bỏ. -5:Loại bỏ phần padding nếu chúng đã được thêm vào. -6:Loại bỏ trường ESP header và tiếp tục quá trình xử lí IPSEC đối với bất kì tiêu đề IPSEC nào còn lại. -7:Kiểm tra số SPI để đảm bảo các chính sách IPSEC đã áp dụng cho thông điệp trên phù hợp với các chính sách IPSEC được yêu cầu cho thông điệp. Việc xác thực và mã hóa thành công một thông điệp inbound bằng một SA trong SAD chưa chắc đảm bảo SA này nên được sử dụng để bảo vệ các loại truyền thông tương tự. Trong trường hợp 1 (Đã được trình bày ở chương trước),giả sử H1 và H2 đã thiết lập một số SA để bảo vệ truyền thông giữa hai đầu cuối của chúng.SA1 và SA2 bảo vệ các gói tin HTTP không bị xáo trộn là các AH SA. SA3 và SA4 bảo vệ các gói tin FTP là các ESP SA. Khi một thông điệp đến H2 và các thông số như SPI,protocol(ESP) và địa chỉ đích gắn gói tin với SA3,SA này sẽ được sử dụng để mã hóa thông điệp.Tuy nhiên điều gì sẽ xảy ra nếu H1 sử dụng nhầm SA3 cho các gói tin HTTP để gửi đến H2.Các chỉ số của thông điệp inbound như địa chỉ đích ,SPI,protocol (ESP) tất cả đều chỉ đến SA3.Chỉ số port number (chỉ số này dùng để xác Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 29 định gói tin này không phải là gói FTP(lưu ý rằng theo giả định của ta SA3 chỉ dùng để bảo vệ các gói FTP)) không thể đọc được trước khi gói tin được mã hóa.Gói tin này sẽ tiếp tục được mã hóa vì nó xác định được một SA phù hợp trong SAD.Quá trình kiểm tra các policy đã áp dụng cho gói tin xác định rằng policy đã áp dụng cho gói tin trên không giống với các policy yêu cầu đối với SA3 và do đó gói tin bị hủy bỏ.Việc này khiến chi phí tính toán mã hóa..là vô ích.(vấn đề này sẽ được thảo luận tiếp ở mục sau). Một tình huống nghiêm trọng hơn khi SA sử dụng một SA budle ,một nhóm các SA có quan hệ với nhau, để bảo vệ cùng một thông điệp Giả sử H1 và H2 thiết lập hai SA bảo vệ đầu cuối (end to end):SA1 và SA2 là các ESP encycrypt only SA (Các ESP SA chỉ cung cấp việc mã hóa) và SA3,SA4 là các AH SA xác thực các thông điệp đã được mã hóa và ip header của chúng.Điều gì xảy ra nếu H1 chỉ sừ dụng SA1 để gửi các FTP request đến H2.Các thông số của gói tin inboud như SPI,protocol,địa chỉ đích đều chỉ đến SA1.Gói tin sẽ được mã hóa thành công vì nó chỉ đến một SA hợp lệ trong SAD.Tuy nhiên khi chuyển sang quá trình kiểm tra các policy áp dụng cho gói tin trên có phù hợp không thì gói tin Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 30 trên sẽ bị loại bỏ vì quá trình kiểm tra policy xác định rằng gói tin trên phải có hai security header tuy nhiên nó chỉ có một security header.Trường hợp a trong hình trên mô tả tình huống sủ dụng sai SA bundle còn trường hợp b mô tả tình huống sử dụng SA bundle đúng. 4.7:Một số điểm phức tạp trong ESP Mặc dù việc mã hóa các tiêu đề của lớp trên nhằm mục đích bảo mật,nó mã hóa luôn một số trường ở transport header bao gồm transport protocol và port.Nó cũng mã hóa luôn một số trường mà các trường này thường được sử dụng để phân tích truyền thông trên internet.Một số trường trong transport header có thể sử dụng cho một số mục đich khác như network traffic analyst ( phân tích truyền thông trên mạng):sự quản lí ,cách cải tiến hiệu suất, kiểm tra sự xâm nhập bất hợp pháp và cách xử lí cho một số loại truyền thông nhất định (được phân loại thành một số loại chất lượng dịch vụ (QOS) khác nhau. Một giao thức mới với tên gọi transport-friendly ESP (TF-ESP) đã được đề xuất ( tuy nhiên chi tiết của giao thức này vẫn chưa được đưa ra).Có hai giải pháp được đưa ra: +Xác định một TF-ESP header sẽ nhân đôi các trường dữ liệu cần thiết và lưu trữ chúng dưới dạng không mã hóa. +Thực hiện việc mã hóa tại các trường trong của gói tin và để lại các trường cần thiết ở dạng không mã hóa. Giải pháp thứ nhất có hai nhược điểm : +Việc nhân đôi một số trường cần thiết làm tăng kích thước gói tin. +Việc chấp nhận tồn tại cả dạng mã hóa và không mã hóa của một số trường tại một số vị trí xác định trong gói tin là một lỗ hổng bảo mật.Thông qua việc phân tích các dữ liệu này hacker có thể xác định được cách giải mã gói tin. Giải pháp thứ hai làm phức tạp hóa một giao thức vốn đã phức tạp,nó đòi hỏi phải thêm vào một số quá trình xử lí nhất định 4.8:Một số đánh giá phê bình của các chuyên gia: Nhà mật mã học nổi tiếng Bruce Schneier và cộng sự của ông Neil Ferguson đặc biệt chỉ trích kiến trúc của IPSEC và IKE.Hai ông cho rằng sự phức tạp là đối thủ lớn của bảo mật(điều này có thể hiểu là muốn có tính bảo mật càng cao thì đồng nghĩa phải xây dựng các giao thức ngày càng phức tạp).Đương nhiên quan điểm của họ là đúng.Tuy nhiên thật không may là IPSEC được xây dựng để nhằm vào một trong những lĩnh vực đặc biệt phức tạp và đa phương diện. IPSEC không chỉ nhằm bảo vệ các gói tin IP mà nó còn phải đảm bảo tính tương thích ,sự hợp tác với rất nhiều các giao thức khác,phải đối mặt với một mô hình mạng mở (open –end network topology) và tính tương thích với các giao thức mạng sẽ được xây dựng trong tương lai. Đồ án bảo mật thông tin –IPSEC và Triển khai hệ thống IPSEC/VPN trên Windows Server 2003 31 Để đạt được sự đơn giản theo Bruce Schneier và Neil Ferguson nên loại bỏ giao AH và transport mode .Rất nhiều nhà phát triển IPSEC cho rằng giao thức AH nên bị bỏ đi và điều này có thể xảy ra trong phiên bản tiếp theo của IPSEC.Tuy nhiên có một số ý kiến đối lập cho rằng có một số giao thức đòi hỏi sử dụng AH và điều này chống lại ý kiến phải loại bỏ giao thức này.Tiếp theo khi giới hạn tất cả các SA về tunnel mode, hai ông đề xuất nên sử dụng một header phức hợp nào đó để giúp tiết kiệm kích thước gói thêm vào khi sử dụng tunnel mode nếu chúng không thật sự cần thiết.Các tác giả thú nhận rằng họ không phải là các chuyên gia về mạng máy tính.Những chuyên gia làm việc trong lĩnh vực này kiên quyết bảo vệ rằng việc bao gồm cả transport mode và tunnel mode là do sự tất yếu của kiến mạng máy tính. Bruce Schneier và Neil Ferguson không hài lòng với trình tự xử lí của giao thức ESP.Hai ông cho rằng gói tin đi ra ngoài cần được xác thực trước khi mã hóa.Trình tự này được lựa chọn một cách có chủ ý giúp gói tin inbound nếu không xác thực đúng sẽ không cần phải trải qua việc giải mã tốn thời gian,chi phí.Các tác giả dẫn ra một tình huống khi các quá tình xác thực và mã hóa khóa chưa hoàn thành,do đó một gói tin sau khi đã được xác thực đúng chưa chắc đảm bảo sẽ được giả mã đúng.Để giải quyết vấn đề này mà không làm thay đổi trình tự của việc xử lí ESP,hai ông cho rằng nên xác thực cả khóa giải mã và các dữ liệu cần dùng trong mã hóa cùng với dữ liệu của gói tin.Về phía đối lập ,các chuyên gia mật mã (những người đã tham gia và quá trình xây dựng IPSEC) hài lòng với trình tự này và cho rằng không cần thiết phải xác thực thêm một số dữ liệu như trên.Ngoài ra ,khi IKE thỏa thuận về khóa việc xác thực và mã hóa khóa của ESP là một thành phần của cả quá trình tổng thể. Các tác giả cho rằng việc sử dụng các SA không định hướng là một điều không thực sự cần thiết,có thể làm tăng kích thước của SAD.Họ đề xuất một SA có hai hướng,cách làm này có thể làm giảm kích thước của SAD.Tuy nhiên một entry SAD đơn lẻ không thể cho phép một phía có thể lựa chọn cho nó giá trị SPI inbound.Một entry kép.mỗi cái với một SPI riêng của nó có thể làm cho kích thước SAD lớn trở lại.Ngoài ra IPSEC còn được sử dụng trong tình huống các truyền thông chỉ được thực hiện theo một hướng(trong multicast). 4.9:Lý do sử dụng hai tiêu đề bảo vệ: Ta có thể dễ dàng nhận thấy rằng ESP cung cấp sự xác thực như AH ngoài ra còn cung cấp thêm cả việc bảo vệ tính riêng tư .Vậy việc sử dụng hai tiêu đề riêng biệt có thật sự cần thiết? Câu trả lời cho câu hỏi này liên quan đến lịch sử và chính trị.Một số quốc gia cấm xuất khẩu các phần mềm thực hiện hoặc hỗ trợ việc mã hóa.Phiên bản đầu của RFC tách biệt phần có thể xuất khẩu được là AH với phần liên quan đến vấn đề về vũ khí chiến tranh (ESP header)( vì một số quốc gia cho rằng các phần mềm mã hóa là một vũ khí chiến tranh).Trong dạng nguyên thủy của nó,ESP header chỉ cung cấp việc mã hóa nếu việc xác thực được yêu cầu thì cả hai tiêu đề được sử dụng.Bởi vì một gói tin đã được mã hóa mà chưa được xác thực tạo lỗ hổng cho một số loại tấn công sửa đổi dữ liệu ( modification attack).Mỗi gói tin đã được mã hóa cần phải xác thực,việc này yêu cầu hai SA riêng biệt và phân chia công bằng các xử lí kh