draft-ietf-ipsecme-traffic-visibility-07.txt   draft-ietf-ipsecme-traffic-visibility-08.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: February 10, 2010 Microsoft Corporation Expires: March 01, 2010 Microsoft Corporation
M. Bhatia M. Bhatia
Alcatel-Lucent Alcatel-Lucent
August 10, 2009 September 01, 2009
Wrapped ESP for Traffic Visibility Wrapped ESP for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-07.txt draft-ietf-ipsecme-traffic-visibility-08.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. This document may with the provisions of BCP 78 and BCP 79. This document may
contain material from IETF Documents or IETF Contributions contain material from IETF Documents or IETF Contributions
published or made publicly available before November 10, 2008. published or made publicly available before November 10, 2008.
The person(s) controlling the copyright in some of this material The person(s) controlling the copyright in some of this material
may not have granted the IETF Trust the right to allow may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards modifications of such material outside the IETF Standards
skipping to change at page 1, line 46 skipping to change at page 1, line 46
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work Drafts as reference material or to cite them other than as "work
in progress." in progress."
The list of current Internet-Drafts can be accessed at 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 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 February 10, 2010. This Internet-Draft will expire on March 01, 2010.
Copyright Copyright
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license- publication of this document (http://trustee.ietf.org/license-
info). Please review these documents carefully, as they describe info). Please review these documents carefully, as they describe
skipping to change at page 2, line 40 skipping to change at page 2, line 40
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...................................................3 1. Introduction...................................................3
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...............................5 2. Wrapped ESP (WESP) Header format...............................5
2.1. UDP Encapsulation.........................................7 2.1. UDP Encapsulation.........................................7
2.2. Transport and Tunnel Mode Considerations..................8 2.2. Transport and Tunnel Mode Considerations..................9
2.2.1. Transport Mode Processing............................8 2.2.1. Transport Mode Processing............................9
2.2.2. Tunnel Mode Processing...............................9 2.2.2. Tunnel Mode Processing..............................10
2.3. IKE Considerations.......................................10 2.3. IKE Considerations.......................................11
3. Security Considerations.......................................11 3. Security Considerations.......................................12
4. IANA Considerations...........................................12 4. IANA Considerations...........................................13
5. Acknowledgments...............................................12 5. Acknowledgments...............................................13
6. References....................................................12 6. References....................................................13
6.1. Normative References.....................................12 6.1. Normative References.....................................13
6.2. Informative References...................................13 6.2. Informative References...................................14
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 5, line 5 skipping to change at page 4, line 48
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described "OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [RFC2119]. in RFC 2119 [RFC2119].
1.2. Applicability Statement 1.2. Applicability Statement
The document is applicable only to the wrapped ESP header The document is applicable only to the wrapped ESP header
defined below, and does not describe any changes to either ESP defined below, and does not describe any changes to either ESP
[RFC4303] nor IP Authentication Header (AH) [RFC4302]. [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 2. Wrapped ESP (WESP) Header format
Wrapped ESP encapsulation (WESP) uses protocol number (TBD via Wrapped ESP encapsulation (WESP) uses protocol number (TBD via
IANA) different from AH and ESP. Accordingly, the (outer) IANA) different from AH and ESP. Accordingly, the (outer)
protocol header (IPv4, IPv6, or Extension) that immediately protocol header (IPv4, IPv6, or Extension) that immediately
precedes the WESP header SHALL contain the value (TBD via IANA) precedes the WESP header SHALL contain the value (TBD via IANA)
in its Protocol (IPv4) or Next Header (IPv6, Extension) field. in its Protocol (IPv4) or Next Header (IPv6, Extension) field.
WESP provides additional attributes in each packet to assist in WESP provides additional attributes in each packet to assist in
differentiating between encrypted and non-encrypted data, and to differentiating between encrypted and non-encrypted data, and to
aid parsing of the packet. WESP follows RFC 4303 for all IPv6 aid parsing of the packet. WESP follows RFC 4303 for all IPv6
skipping to change at page 5, line 34 skipping to change at page 6, line 4
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 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 | | Wrapped ESP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation | | Existing ESP Encapsulation |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 WESP Packet Format Figure 1 WESP Packet Format
By preserving the body of the existing ESP packet format, a By preserving the body of the existing ESP packet format, a
compliant implementation can simply add in the new header, compliant implementation can simply add in the new header,
without needing to change the body of the packet. The value of without needing to change the body of the packet. The value of
the new protocol used to identify this new header is TBD via the new protocol used to identify this new header is TBD via
IANA. Further details are shown below: IANA. Further details are shown below:
0 1 2 3 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 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 | | Existing ESP Encapsulation |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Detailed WESP Packet Format Figure 2 Detailed WESP Packet Format
Where: Where:
Next Header, 8 bits: This field MUST be the same as the Next 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 Header field in the ESP trailer when using ESP in the Integrity
only mode, and MUST be set to zero when using ESP with only mode. When using ESP with encryption, the "Next Header"
Encryption. The receiver MUST do some sanity checks before the field looses this name and semantics and becomes an empty field
WESP packet is accepted. Receiver MUST ensure that the Next which MUST be initialized to all zeros. The receiver MUST do
Header field in the WESP header and the Next Header field in the some sanity checks before the WESP packet is accepted. 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 receiver MUST ensure that the Next Header field in the WESP
header is zero if using WESP with encryption. The WESP flags header and the Next Header field in the ESP trailer match when
dictate if the packet is encrypted and/or integrity protected. 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 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 the beginning of the Rest of Payload Data (i.e., past the IV, if
present) within the encapsulated ESP header, in octets. The present) within the encapsulated ESP header, in octets. The
receiver MUST ensure that this field matches with the header receiver MUST ensure that this field matches with the header
offset computed from using the negotiated SA and MUST drop the offset computed from using the negotiated SA and MUST drop the
packet in case it doesn't match. packet in case it doesn't match.
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: 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 2 bits: Version (V). MUST be sent as 0 and checked by the
receiver. Future modifications to the WESP header may require a receiver. If the version is different than an expected version
new version number. Intermediate nodes dealing with unknown number (e.g. negotiated via the control channel), then the
versions are not necessarily able to parse the packet correctly. packet must be dropped by the receiver. Future modifications to
Intermediate treatment of such packets is policy-dependent the WESP header may require a new version number. Intermediate
(e.g., it may dictate dropping such packets). 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 1 bit: Encrypted Payload (E). Setting the Encrypted Payload
to 1 indicates that the WESP (and therefore ESP) payload is bit to 1 indicates that the WESP (and therefore ESP) payload is
protected with encryption. If this bit is set to 0, then the protected with encryption. If this bit is set to 0, then the
payload is using ESP-NULL cipher. Setting or clearing this bit payload is using ESP-NULL cipher. Setting or clearing this bit
also impacts the value in the WESP Next Header field, as also impacts the value in the WESP Next Header field, as
described above. The recipient MUST ensure consistency of this described above. The recipient MUST ensure consistency of this
flag with the negotiated policy and MUST drop the incoming flag with the negotiated policy and MUST drop the incoming
packet otherwise. packet otherwise.
5 bits: Flags, reserved for future use. The flags MUST be 5 bits: Flags, reserved for future use. The flags MUST be
sent as 0, and ignored by the receiver. Future documents sent as 0, and ignored by the receiver. Future documents
defining any of these flags MUST NOT affect the distinction defining any of these flags MUST NOT affect the distinction
between encrypted and unencrypted packets. Intermediate nodes between encrypted and unencrypted packets. Intermediate nodes
dealing with unknown flags are not necessarily able to parse the dealing with unknown flags are not necessarily able to parse the
packet correctly. Intermediate treatment of such packets is packet correctly. Intermediate treatment of such packets is
policy-dependent (e.g., it may dictate dropping such packets). policy-dependent (e.g., it may dictate dropping such packets).
Future versions of this protocol may change the Version number Future versions of this protocol may change the Version number
and/or the Flag bits sent, possibly by negotiating them over the and/or the Flag bits sent, possibly by negotiating them over the
control channel. The receiver MUST drop packets for which the control channel.
integrity check is invalid.
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
skipping to change at page 12, line 21 skipping to change at page 13, line 21
The USE_WESP_MODE notification number is assigned out of the The USE_WESP_MODE notification number is assigned out of the
"IKEv2 Notify Message Types - Status Types" registry's 16384- "IKEv2 Notify Message Types - Status Types" registry's 16384-
40959 (Expert Review) range: TBD. 40959 (Expert Review) range: TBD.
This specification requests that IANA create a new registry for This specification requests that IANA create a new registry for
"WESP Flags" to be managed as follows: "WESP Flags" to be managed as follows:
The first 2 bits are the WESP Version Number. The value 0 is The first 2 bits are the WESP Version Number. The value 0 is
assigned to the version defined in this specification. Further assigned to the version defined in this specification. Further
assignments of the WESP Version Number are to be managed via the assignments of the WESP Version Number are to be managed via the
IANA Policy of "Standards Action" [RFC5226]. The final 6 bits of IANA Policy of "Standards Action" [RFC5226]. The Encrypted
the WESP Flags are the "Non-version Flags". This specification Payload bit is used to indicate if the payload is encrypted or
defines no values, and future assignment is to be managed via using ESP-NULL. The remaining 5 bits of the WESP Flags are
the IANA Policy of "Specification Required". undefined and future assignment is to be managed via the IANA
Policy of "Specification Required".
5. Acknowledgments 5. Acknowledgments
The authors would like to acknowledge the following people for The authors would like to acknowledge the following people for
their feedback on updating the definitions in this document. their feedback on updating the definitions in this document.
David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron
Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier
among others. among others.
skipping to change at page 13, line 25 skipping to change at page 14, line 25
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226, an IANA Considerations Section in RFCs", RFC 5226,
May 2008. May 2008.
[Heuristics I-D] Kivinen, T., McDonald, D., "Heuristics for Detecting
ESP-NULL packets", Internet Draft, April 2009.
Author's Addresses Author's Addresses
Ken Grewal Ken Grewal
Intel Corporation Intel Corporation
2111 NE 25th Avenue, JF3-232 2111 NE 25th Avenue, JF3-232
Hillsboro, OR 97124 Hillsboro, OR 97124
USA USA
Phone: Phone:
Email: ken.grewal@intel.com Email: ken.grewal@intel.com
 End of changes. 17 change blocks. 
39 lines changed or deleted 74 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/