--- 1/draft-ietf-ipsecme-traffic-visibility-03.txt 2009-06-05 18:12:10.000000000 +0200 +++ 2/draft-ietf-ipsecme-traffic-visibility-04.txt 2009-06-05 18:12:10.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group K. Grewal Internet Draft Intel Corporation Intended status: Standards Track G. Montenegro -Expires: November 30, 2009 Microsoft Corporation +Expires: December 05, 2009 Microsoft Corporation M. Bhatia Alcatel-Lucent - May 30, 2009 + June 05, 2009 Wrapped ESP for Traffic Visibility - draft-ietf-ipsecme-traffic-visibility-03.txt + draft-ietf-ipsecme-traffic-visibility-04.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. @@ -60,30 +61,30 @@ 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..................8 + 2.2. Transport and Tunnel Mode Considerations..................7 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 + 3. Security Considerations.......................................10 + 4. IANA Considerations...........................................11 + 5. Acknowledgments...............................................11 + 6. References....................................................11 + 6.1. Normative References.....................................11 + 6.2. Informative References...................................12 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. @@ -242,44 +243,39 @@ 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. Version is set to 0 by the transmitter and - validated by the receiver. Any modifications to the WESP header - in the future may require an update in the 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. 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: reserved for future use. These MUST be set to zero - per this specification, but usage may be defined by other - specifications. Intermediate nodes compliant with this - specification SHOULD check that these bits are set to zero. If - any bits are non-zero, it is possible that the packet has a - different format than specified here. Policy dictates final - treatment of such packets at intermediate nodes (e.g., including - dropping such packets). + 6 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). - Note: To provide future compatibility, the version number is - negotiated by the control channel handshake. An end-node - implementation compatible with this specification must set the - version number and the reserved bits to the values specified - above when transmitting a packet. On receiving a packet, these - values must be checked to ensure that they are as indicated - above and the packet MUST be dropped in case they don't match. + 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. 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