--- 1/draft-ietf-ipsecme-traffic-visibility-00.txt 2009-03-09 20:12:25.000000000 +0100 +++ 2/draft-ietf-ipsecme-traffic-visibility-01.txt 2009-03-09 20:12:25.000000000 +0100 @@ -1,66 +1,74 @@ Network Working Group K. Grewal Internet Draft Intel Corporation Intended status: Standards Track G. Montenegro -Expires: April 22, 2009 Microsoft Corporation - October 22, 2008 +Expires: September 09, 2009 Microsoft Corporation + March 09, 2009 Wrapped ESP for Traffic Visibility - draft-ietf-ipsecme-traffic-visibility-00.txt + draft-ietf-ipsecme-traffic-visibility-01.txt Status of this Memo - By submitting this Internet-Draft, each author represents that - any applicable patent or other IPR claims of which he or she is - aware have been or will be disclosed, and any of which he or she - becomes aware will be disclosed, in accordance with Section 6 of - BCP 79. + This Internet-Draft is submitted to IETF in full conformance + with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt + http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html + http://www.ietf.org/shadow.html. - This Internet-Draft will expire on April 22, 2009. + This Internet-Draft will expire on September 9, 2009. + +Copyright + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license- + info). Please review these documents carefully, as they describe + your rights and restrictions with respect to this document. Abstract This document describes an ESP encapsulation for IPsec, allowing intermediate devices to ascertain if ESP-NULL is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. Table of Contents 1. Introduction................................................2 - 1.1. Requirements Language..................................3 + 1.1. Requirements Language..................................4 1.2. Applicability Statement................................4 2. Wrapped ESP (WESP) Header format............................4 2.1. UDP Encapsulation......................................5 2.2. Tunnel and Transport mode of considerations............7 2.3. IKE Considerations.....................................7 3. Security Considerations.....................................7 - 4. IANA Considerations.........................................7 + 4. IANA Considerations.........................................8 5. Acknowledgments.............................................8 6. References..................................................8 6.1. Normative References...................................8 6.2. Informative References.................................8 1. Introduction Use of ESP within IPsec [RFC4303] specifies how ESP packet encapsulation is performed. It also specifies that ESP can use NULL encryption [RFC2410] while preserving data integrity and @@ -103,24 +111,30 @@ Furthermore, storage, lookup and cross-checking a set of comprehensive rules against every packet adds cost to hardware implementations and degrades performance. In cases where the packets may be encrypted, it is also wasteful to check against heuristics-based rules, when a simple exception policy (e.g., allow, drop or redirect) can be employed to handle the encrypted packets. Because of the non-deterministic nature of heuristics- based rules for disambiguating between encrypted and non- encrypted data, an alternative method for enabling intermediate devices to function in encrypted data environments needs to be - defined. Enterprise environments typically use both stateful and - stateless packet inspection mechanisms. The previous - considerations weigh particularly heavy on stateless mechanisms - such as router ACLs and NetFlow exporters. + defined. Additionally there are many types and classes of + network devices employed within a given network and a + deterministic approach would provide a simple solution for all + these devices. Enterprise environments typically use both + stateful and stateless packet inspection mechanisms. The + previous considerations weigh particularly heavy on stateless + mechanisms such as router ACLs and NetFlow exporters. + Nevertheless, a deterministic approach provides a simple + solution for the myriad types of devices employed within a + network, regardless of their stateful or stateless nature. This document defines a mechanism to prove additional information in relevant IPsec packets so intermediate devices can efficiently differentiate between encrypted ESP packets and ESP packets with NULL encryption. The document is consistent with the operation of ESP in NAT environments [RFC3947]. The design principles for this protocol are the following: @@ -144,24 +157,29 @@ The document is applicable only to the wrapped ESP header defined below, and does not describe any changes to either ESP [RFC4303] nor AH [RFC4302]. 2. Wrapped ESP (WESP) Header format The proposal is to define a protocol number for Wrapped ESP encapsulation (WESP), which provides additional attributes in each packet to assist in differentiating between encrypted and - non-encrypted data, as well as aid parsing of the packet. This - extension essentially acts as a wrapper to the existing ESP + non-encrypted data, as well as aid parsing of the packet. WESP + follows RFC 4303 for all IPv6 and IPv4 considerations (e.g., + alignment considerations). + + This extension essentially acts as a wrapper to the existing ESP protocol and provides an additional 4 octets at the front of the - existing ESP packet. This may be depicted simply as follows: + existing ESP packet. + + This may be depicted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wrapped ESP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Existing ESP Encapsulation | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -181,43 +199,45 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Existing ESP Encapsulation | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Detailed WESP Packet Format Where: - Next Header: next protocol header (encrypted in ESP trailer, - but in the clear in header), providing easy access to a HW - parser to extract the upper layer protocol. Note: For security - concerns, this value may optionally be set to zero, in which - case the next header an be extracted from the ESP trailer. + Next Header, 8 bits: next protocol header (encrypted in ESP + trailer, but in the clear in header), providing easy access to a + HW parser to extract the upper layer protocol. Note: For + security concerns, this value may optionally be set to zero, in + which case the next header can be extracted from the ESP + trailer. - HdrLen: includes the new header + full ESP header + the IV (if - present). It is an offset to the beginning of the Payload Data. + HdrLen, 8 bits: includes the new header, the full ESP header and + the IV (if present). It is an offset to the beginning of the + Payload Data. - TrailerLen: Offset from the end of the packet including the ICV, - pad length, and any padding. It is an offset from the end of - the packet to the last byte of the payload data. + TrailerLen, 8 bits: Offset from the end of the packet including + the ICV, pad length, and any padding. It is an offset from the + end of the packet to the last byte of the payload data. - Flags + Flags, 8 bits 2 bits: Version 6 bits: reserved for future use. These MUST be set to zero per this specification, but usage may be defined by other specifications. - As can be seen, this wrapped ESP format simply extends the - standard ESP header by the first 4 octets. + As can be seen, this wrapped ESP format extends the standard ESP + header by the first 4 octets. 2.1. UDP Encapsulation This section describes a mechanism for running the new packet format over the existing UDP encapsulation of ESP as defined in RFC 3948. This allows leveraging the existing IKE negotiation of the UDP port for NAT-T discovery and usage [RFC3947], as well as preserving the existing UDP ports for ESP (port 4500). With UDP encapsulation, the packet format can be depicted as follows. @@ -253,34 +273,35 @@ which can be used to assume that the data following that value is an IKE packet. Similarly, a value of non-zero indicates that the packet is an ESP packet and the 4-octet value can be treated as the ESP SPI. However, RFC 4303, clause 2.1 indicates that the values 1-255 are reserved and cannot be used as the SPI. We leverage that knowledge and use a value of 1 to indicate that the UDP encapsulated ESP header contains this new packet format for ESP encapsulation. The remaining fields in the packet have the same meaning as per - section 2.0 above. + section 2 above. 2.2. Tunnel and Transport mode of considerations This extension is equally applicable for tunnel and transport mode where the ESP Next Header field is used to differentiate between these modes, as per the existing IPsec specifications. 2.3. IKE Considerations - In order to negotiate the new format of ESP encapsulation via - IKE [RFC4306], both parties need to agree to use the new packet - format. This can be achieved by proposing a new protocol ID - within the existing IKE proposal structure as defined by RFC + This document assumes that WESP negotiation is performed using + IKEv2. In order to negotiate the new format of ESP encapsulation + via IKEv2 [RFC4306], both parties need to agree to use the new + packet format. This can be achieved by proposing a new protocol + ID within the existing IKE proposal structure as defined by RFC 4306, clause 3.3.1. The existing proposal substructure in this clause allows negotiation of ESP/AH (among others) by using different protocol Ids for these protocols. By using the same protocol substructure in the proposal payload and using a new value (TBD) for this encapsulation, the existing IKE negotiation can be leverage with minimal changes to support negotiation of this encapsulation. Furthermore, because the negotiation is at the protocol level, other transforms remain valid for this new encapsulation and @@ -361,52 +382,10 @@ Email: ken.grewal@intel.com Gabriel Montenegro Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: Email: gabriel.montenegro@microsoft.com - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and - restrictions contained in BCP 78, and except as set forth - therein, the authors retain all their rights. - - This document and the information contained herein are provided - on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, - THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM - ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO - ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT - INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY - OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of - any Intellectual Property Rights or other rights that might be - claimed to pertain to the implementation or use of the - technology described in this document or the extent to which any - license under such rights might or might not be available; nor - does it represent that it has made any independent effort to - identify any such rights. Information on the procedures with - respect to rights in RFC documents can be found in BCP 78 and - BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the - use of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR - repository at http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention - any copyrights, patents or patent applications, or other - proprietary rights that may cover technology that may be - required to implement this standard. Please address the - information to the IETF at ietf-ipr@ietf.org.