draft-ietf-ipsecme-traffic-visibility-03.txt   draft-ietf-ipsecme-traffic-visibility-04.txt 
Network Working Group K. Grewal Network Working Group K. Grewal
Internet Draft Intel Corporation Internet Draft Intel Corporation
Intended status: Standards Track G. Montenegro Intended status: Standards Track G. Montenegro
Expires: November 30, 2009 Microsoft Corporation Expires: December 05, 2009 Microsoft Corporation
M. Bhatia M. Bhatia
Alcatel-Lucent Alcatel-Lucent
May 30, 2009 June 05, 2009
Wrapped ESP for Traffic Visibility Wrapped ESP for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-03.txt draft-ietf-ipsecme-traffic-visibility-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance This Internet-Draft is submitted to IETF in full conformance
with the provisions of BCP 78 and BCP 79. with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 2, line 26 skipping to change at page 2, line 29
disambiguate ESP-NULL from ESP encrypted packets, without disambiguate ESP-NULL from ESP encrypted packets, without
compromising on the security provided by ESP. compromising on the security provided by ESP.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
1.1. Requirements Language.....................................4 1.1. Requirements Language.....................................4
1.2. Applicability Statement...................................4 1.2. Applicability Statement...................................4
2. Wrapped ESP (WESP) Header format...............................4 2. Wrapped ESP (WESP) Header format...............................4
2.1. UDP Encapsulation.........................................6 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.1. Transport Mode Processing............................8
2.2.2. Tunnel Mode Processing...............................9 2.2.2. Tunnel Mode Processing...............................9
2.3. IKE Considerations.......................................10 2.3. IKE Considerations.......................................10
3. Security Considerations.......................................11 3. Security Considerations.......................................10
4. IANA Considerations...........................................12 4. IANA Considerations...........................................11
5. Acknowledgments...............................................12 5. Acknowledgments...............................................11
6. References....................................................12 6. References....................................................11
6.1. Normative References.....................................12 6.1. Normative References.....................................11
6.2. Informative References...................................13 6.2. Informative References...................................12
1. Introduction 1. Introduction
Use of ESP within IPsec [RFC4303] specifies how ESP packet Use of ESP within IPsec [RFC4303] specifies how ESP packet
encapsulation is performed. It also specifies that ESP can use encapsulation is performed. It also specifies that ESP can use
NULL encryption while preserving data integrity and NULL encryption while preserving data integrity and
authenticity. The exact encapsulation and algorithms employed authenticity. The exact encapsulation and algorithms employed
are negotiated out-of-band using, for example, IKEv2 [RFC4306] are negotiated out-of-band using, for example, IKEv2 [RFC4306]
and based on policy. and based on policy.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
TrailerLen, 8 bits: Offset from the end of the packet to the TrailerLen, 8 bits: Offset from the end of the packet to the
last byte of the payload data in octets. TrailerLen MUST be set last byte of the payload data in octets. TrailerLen MUST be set
to zero when using ESP with encryption. The receiver MUST only to zero when using ESP with encryption. The receiver MUST only
accept the packet if this field matches with the value computed accept the packet if this field matches with the value computed
from using the negotiated SA. This insures that sender is not from using the negotiated SA. This insures that sender is not
deliberately setting this value to obfuscate a part of the deliberately setting this value to obfuscate a part of the
payload from examination by a trusted intermediary device. payload from examination by a trusted intermediary device.
Flags, 8 bits Flags, 8 bits
2 bits: Version. Version is set to 0 by the transmitter and 2 bits: Version. MUST be sent as 0 and checked by the
validated by the receiver. Any modifications to the WESP header receiver. Future modifications to the WESP header may require a
in the future may require an update in the version number. new version number. Intermediate nodes dealing with unknown
Intermediate nodes dealing with unknown versions are not versions are not necessarily able to parse the packet correctly.
necessarily able to parse the packet correctly. Intermediate Intermediate treatment of such packets is policy-dependent
treatment of such packets is policy-dependent (e.g., it may (e.g., it may dictate dropping such packets).
dictate dropping such packets).
6 bits: reserved for future use. These MUST be set to zero 6 bits: Flags, reserved for future use. The flags MUST be
per this specification, but usage may be defined by other sent as 0, and ignored by the receiver. Future documents
specifications. Intermediate nodes compliant with this defining any of these flags MUST NOT affect the distinction
specification SHOULD check that these bits are set to zero. If between encrypted and unencrypted packets. Intermediate nodes
any bits are non-zero, it is possible that the packet has a dealing with unknown flags are not necessarily able to parse the
different format than specified here. Policy dictates final packet correctly. Intermediate treatment of such packets is
treatment of such packets at intermediate nodes (e.g., including policy-dependent (e.g., it may dictate dropping such packets).
dropping such packets).
Note: To provide future compatibility, the version number is Future versions of this protocol may change the Version number
negotiated by the control channel handshake. An end-node and/or the Flag bits sent, possibly by negotiating them over the
implementation compatible with this specification must set the control channel. The receiver MUST drop packets for which the
version number and the reserved bits to the values specified integrity check is invalid.
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.
As can be seen, the WESP format extends the standard ESP header As can be seen, the WESP format extends the standard ESP header
by the first 4 octets. The WESP header is integrity protected, by the first 4 octets. The WESP header is integrity protected,
along with all the fields specified for ESP in RFC 4303. along with all the fields specified for ESP in RFC 4303.
2.1. UDP Encapsulation 2.1. UDP Encapsulation
This section describes a mechanism for running the new packet This section describes a mechanism for running the new packet
format over the existing UDP encapsulation of ESP as defined in format over the existing UDP encapsulation of ESP as defined in
RFC 3948. This allows leveraging the existing IKE negotiation of RFC 3948. This allows leveraging the existing IKE negotiation of
 End of changes. 8 change blocks. 
32 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/