--- 1/draft-ietf-ipsecme-traffic-visibility-07.txt 2009-09-01 20:12:09.000000000 +0200 +++ 2/draft-ietf-ipsecme-traffic-visibility-08.txt 2009-09-01 20:12:09.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group K. Grewal Internet Draft Intel Corporation Intended status: Standards Track G. Montenegro -Expires: February 10, 2010 Microsoft Corporation +Expires: March 01, 2010 Microsoft Corporation M. Bhatia Alcatel-Lucent - August 10, 2009 + September 01, 2009 Wrapped ESP for Traffic Visibility - draft-ietf-ipsecme-traffic-visibility-07.txt + draft-ietf-ipsecme-traffic-visibility-08.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards @@ -35,21 +35,21 @@ 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on February 10, 2010. + This Internet-Draft will expire on March 01, 2010. 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 @@ -72,30 +72,30 @@ disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. Table of Contents 1. Introduction...................................................3 1.1. Requirements Language.....................................4 1.2. Applicability Statement...................................4 2. Wrapped ESP (WESP) Header format...............................5 2.1. UDP Encapsulation.........................................7 - 2.2. Transport and Tunnel Mode Considerations..................8 - 2.2.1. Transport Mode Processing............................8 - 2.2.2. Tunnel Mode Processing...............................9 - 2.3. IKE Considerations.......................................10 - 3. Security Considerations.......................................11 - 4. IANA Considerations...........................................12 - 5. Acknowledgments...............................................12 - 6. References....................................................12 - 6.1. Normative References.....................................12 - 6.2. Informative References...................................13 + 2.2. Transport and Tunnel Mode Considerations..................9 + 2.2.1. Transport Mode Processing............................9 + 2.2.2. Tunnel Mode Processing..............................10 + 2.3. IKE Considerations.......................................11 + 3. Security Considerations.......................................12 + 4. IANA Considerations...........................................13 + 5. Acknowledgments...............................................13 + 6. References....................................................13 + 6.1. Normative References.....................................13 + 6.2. Informative References...................................14 1. Introduction Use of ESP within IPsec [RFC4303] specifies how ESP packet encapsulation is performed. It also specifies that ESP can use NULL encryption while preserving data integrity and authenticity. The exact encapsulation and algorithms employed are negotiated out-of-band using, for example, IKEv2 [RFC4306] and based on policy. @@ -176,20 +176,45 @@ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.2. Applicability Statement The document is applicable only to the wrapped ESP header defined below, and does not describe any changes to either ESP [RFC4303] nor IP Authentication Header (AH) [RFC4302]. + There are two ways to enable intermediate security devices to + distinguish between encrypted and unencrypted ESP traffic: + + - The heuristics approach [Heuristics I-D] has the intermediate + node inspect the unchanged ESP traffic, to determine with + extremely high probability whether or not the traffic stream is + encrypted. + + - The Wrapped ESP (WESP) approach described in this document, in + contrast, requires the ESP endpoints to be modified to support + the new protocol. WESP allows the intermediate node to + distinguish encrypted and unencrypted traffic deterministically, + using a simpler implementation for the intermediate node. + + Both approaches are being documented simultaneously by the IP + Security Maintenance and Extensions (IPsecME) Working Group, + with WESP being put on Standards Track while the heuristics + approach is being published as an Informational RFC. While + endpoints are being modified to adopt WESP, we expect both + approaches to coexist for years, because the heuristic approach + is needed to inspect traffic where at least one of the endpoints + has not been modified. In other words, intermediate nodes are + expected to support both approaches in order to achieve good + security and performance during the transition period. + 2. Wrapped ESP (WESP) Header format Wrapped ESP encapsulation (WESP) uses protocol number (TBD via IANA) different from AH and ESP. Accordingly, the (outer) protocol header (IPv4, IPv6, or Extension) that immediately precedes the WESP header SHALL contain the value (TBD via IANA) in its Protocol (IPv4) or Next Header (IPv6, Extension) field. WESP provides additional attributes in each packet to assist in differentiating between encrypted and non-encrypted data, and to aid parsing of the packet. WESP follows RFC 4303 for all IPv6 @@ -205,97 +230,103 @@ 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 | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 WESP Packet Format - By preserving the body of the existing ESP packet format, a compliant implementation can simply add in the new header, without needing to change the body of the packet. The value of the new protocol used to identify this new header is TBD via IANA. Further details are shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Next Header | HdrLen | TrailerLen | Flags | + | Next Header | HdrLen | TrailerLen |V|V|E| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Existing ESP Encapsulation | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Detailed WESP Packet Format + Where: Next Header, 8 bits: This field MUST be the same as the Next Header field in the ESP trailer when using ESP in the Integrity - only mode, and MUST be set to zero when using ESP with - Encryption. The receiver MUST do some sanity checks before the - WESP packet is accepted. Receiver MUST ensure that the Next - Header field in the WESP header and the Next Header field in the - ESP trailer match when using ESP in the Integrity only mode. The - packet MUST be dropped if the two do not match. Similarly, the + only mode. When using ESP with encryption, the "Next Header" + field looses this name and semantics and becomes an empty field + which MUST be initialized to all zeros. The receiver MUST do + some sanity checks before the WESP packet is accepted. The receiver MUST ensure that the Next Header field in the WESP - header is zero if using WESP with encryption. The WESP flags - dictate if the packet is encrypted and/or integrity protected. + header and the Next Header field in the ESP trailer match when + using ESP in the Integrity only mode. The packet MUST be dropped + if the two do not match. Similarly, the receiver MUST ensure + that the Next Header field in the WESP header is an empty field + initialized to zero if using WESP with encryption. The WESP + flags dictate if the packet is encrypted and/or integrity + protected. HdrLen, 8 bits: Offset from the beginning of the WESP header to the beginning of the Rest of Payload Data (i.e., past the IV, if present) within the encapsulated ESP header, in octets. The receiver MUST ensure that this field matches with the header offset computed from using the negotiated SA and MUST drop the packet in case it doesn't match. TrailerLen, 8 bits: Offset from the end of the packet to the last byte of the payload data in octets. TrailerLen MUST be set to zero when using ESP with encryption. The receiver MUST only accept the packet if this field matches with the value computed from using the negotiated SA. This insures that sender is not deliberately setting this value to obfuscate a part of the payload from examination by a trusted intermediary device. - Flags, 8 bits + Flags, 8 bits: The bits are defined LSB first, so bit 0 would be + the least significant bit of the flags octet. - 2 bits: Version. MUST be sent as 0 and checked by the - receiver. Future modifications to the WESP header may require a - new version number. Intermediate nodes dealing with unknown - versions are not necessarily able to parse the packet correctly. - Intermediate treatment of such packets is policy-dependent - (e.g., it may dictate dropping such packets). + 2 bits: Version (V). MUST be sent as 0 and checked by the + receiver. If the version is different than an expected version + number (e.g. negotiated via the control channel), then the + packet must be dropped by the receiver. Future modifications to + the WESP header may require a new version number. Intermediate + nodes dealing with unknown versions are not necessarily able to + parse the packet correctly. Intermediate treatment of such + packets is policy-dependent (e.g., it may dictate dropping such + packets). - 1 bit: Encrypted Payload. Setting the Encrypted Payload bit - to 1 indicates that the WESP (and therefore ESP) payload is + 1 bit: Encrypted Payload (E). Setting the Encrypted Payload + bit to 1 indicates that the WESP (and therefore ESP) payload is protected with encryption. If this bit is set to 0, then the payload is using ESP-NULL cipher. Setting or clearing this bit also impacts the value in the WESP Next Header field, as described above. The recipient MUST ensure consistency of this flag with the negotiated policy and MUST drop the incoming packet otherwise. 5 bits: Flags, reserved for future use. The flags MUST be sent as 0, and ignored by the receiver. Future documents defining any of these flags MUST NOT affect the distinction between encrypted and unencrypted packets. Intermediate nodes dealing with unknown flags are not necessarily able to parse the packet correctly. Intermediate treatment of such packets is policy-dependent (e.g., it may dictate dropping such packets). Future versions of this protocol may change the Version number and/or the Flag bits sent, possibly by negotiating them over the - control channel. The receiver MUST drop packets for which the - integrity check is invalid. + control channel. As can be seen, the WESP format extends the standard ESP header by the first 4 octets. The WESP header is integrity protected, along with all the fields specified for ESP in RFC 4303. 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 @@ -506,24 +537,25 @@ The USE_WESP_MODE notification number is assigned out of the "IKEv2 Notify Message Types - Status Types" registry's 16384- 40959 (Expert Review) range: TBD. This specification requests that IANA create a new registry for "WESP Flags" to be managed as follows: The first 2 bits are the WESP Version Number. The value 0 is assigned to the version defined in this specification. Further assignments of the WESP Version Number are to be managed via the - IANA Policy of "Standards Action" [RFC5226]. The final 6 bits of - the WESP Flags are the "Non-version Flags". This specification - defines no values, and future assignment is to be managed via - the IANA Policy of "Specification Required". + IANA Policy of "Standards Action" [RFC5226]. The Encrypted + Payload bit is used to indicate if the payload is encrypted or + using ESP-NULL. The remaining 5 bits of the WESP Flags are + undefined and future assignment is to be managed via the IANA + Policy of "Specification Required". 5. Acknowledgments The authors would like to acknowledge the following people for their feedback on updating the definitions in this document. David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier among others. @@ -555,20 +587,23 @@ [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, May 2008. + [Heuristics I-D] Kivinen, T., McDonald, D., "Heuristics for Detecting + ESP-NULL packets", Internet Draft, April 2009. + Author's Addresses Ken Grewal Intel Corporation 2111 NE 25th Avenue, JF3-232 Hillsboro, OR 97124 USA Phone: Email: ken.grewal@intel.com