--- 1/draft-ietf-ipsecme-traffic-visibility-05.txt 2009-08-06 20:12:10.000000000 +0200 +++ 2/draft-ietf-ipsecme-traffic-visibility-06.txt 2009-08-06 20:12:10.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group K. Grewal Internet Draft Intel Corporation Intended status: Standards Track G. Montenegro -Expires: December 23, 2009 Microsoft Corporation +Expires: February 06, 2010 Microsoft Corporation M. Bhatia Alcatel-Lucent - June 24, 2009 + August 06, 2009 Wrapped ESP for Traffic Visibility - draft-ietf-ipsecme-traffic-visibility-05.txt + draft-ietf-ipsecme-traffic-visibility-06.txt Status of this Memo 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. @@ -24,21 +24,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 October 30, 2009. + This Internet-Draft will expire on February 06, 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 @@ -60,31 +60,31 @@ mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................4 1.2. Applicability Statement...................................4 2. Wrapped ESP (WESP) Header format...............................4 - 2.1. UDP Encapsulation.........................................6 - 2.2. Transport and Tunnel Mode Considerations..................7 + 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.......................................10 - 4. IANA Considerations...........................................11 - 5. Acknowledgments...............................................11 - 6. References....................................................11 - 6.1. Normative References.....................................11 - 6.2. Informative References...................................12 + 3. Security Considerations.......................................11 + 4. IANA Considerations...........................................12 + 5. Acknowledgments...............................................12 + 6. References....................................................12 + 6.1. Normative References.....................................12 + 6.2. Informative References...................................13 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. @@ -224,47 +224,57 @@ 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 receiver MUST ensure that the Next Header field in the WESP - header is zero if using ESP with encryption. In this case, the - packet MUST be dropped if it is not set to zero and the packet - is encrypted. + header is zero if using WESP with encryption. The WESP flags + dictate if the packet is encrypted and/or integrity protected. - HdrLen, 8 bits: Offset to the beginning of the Payload Data 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. + 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 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). - 6 bits: Flags, reserved for future use. The flags MUST be + 1 bit: Encrypted Payload. 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