< draft-ietf-ipsecme-traffic-visibility-11.txt   draft-ietf-ipsecme-traffic-visibility-12.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: May 30, 2010 Microsoft Corporation Expires: July 19, 2010 Microsoft Corporation
M. Bhatia M. Bhatia
Alcatel-Lucent Alcatel-Lucent
November 30, 2009 January 20, 2010
Wrapped ESP for Traffic Visibility Wrapped ESP for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-11.txt draft-ietf-ipsecme-traffic-visibility-12.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 May 30, 2010. This Internet-Draft will expire on July 19, 2010.
Copyright Copyright
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license- (http://trustee.ietf.org/license-info) in effect on the date of
info). Please review these documents carefully, as they describe publication of this document. Please review these documents
your rights and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Abstract Abstract
This document describes the Wrapped Encapsulating Security This document describes the Wrapped Encapsulating Security
Payload (WESP) protocol, which builds on the Encapsulating Payload (WESP) protocol, which builds on the Encapsulating
Security Payload (ESP) [RFC4303], and is designed to allow Security Payload (ESP) [RFC4303], and is designed to allow
intermediate devices to (1) ascertain if data confidentiality is intermediate devices to (1) ascertain if data confidentiality is
being employed within ESP and if not, (2) inspect the IPsec being employed within ESP and if not, (2) inspect the IPsec
packets for network monitoring and access control functions. packets for network monitoring and access control functions.
Currently in the IPsec ESP standard, there is no way to Currently in the IPsec ESP standard, there is no deterministic
differentiate between encrypted and unencrypted payloads by way to differentiate between encrypted and unencrypted payloads
simply examining a packet. This poses certain challenges to the by simply examining a packet. This poses certain challenges to
intermediate devices that need to deep inspect the packet before the intermediate devices that need to deep inspect the packet
making a decision on what should be done with that packet before making a decision on what should be done with that packet
(Inspect and/or Allow/Drop). The mechanism described in this (Inspect and/or Allow/Drop). The mechanism described in this
document can be used to easily disambiguate integrity-only ESP document can be used to easily disambiguate integrity-only ESP
from ESP-encrypted packets, without compromising on the security from ESP-encrypted packets, without compromising on the security
provided by ESP. 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
skipping to change at page 4, line 48 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 There are two well accepted ways to enable intermediate security
distinguish between encrypted and unencrypted ESP traffic: devices to distinguish between encrypted and unencrypted ESP
traffic:
- The heuristics approach [Heuristics I-D] has the intermediate - The heuristics approach [Heuristics I-D] has the intermediate
node inspect the unchanged ESP traffic, to determine with node inspect the unchanged ESP traffic, to determine with
extremely high probability whether or not the traffic stream is extremely high probability whether or not the traffic stream is
encrypted. encrypted.
- The Wrapped ESP (WESP) approach described in this document, in - The Wrapped ESP (WESP) approach described in this document, in
contrast, requires the ESP endpoints to be modified to support contrast, requires the ESP endpoints to be modified to support
the new protocol. WESP allows the intermediate node to the new protocol. WESP allows the intermediate node to
distinguish encrypted and unencrypted traffic deterministically, distinguish encrypted and unencrypted traffic deterministically,
skipping to change at page 5, line 38 skipping to change at page 5, line 41
Extension) that immediately precedes the WESP header SHALL Extension) that immediately precedes the WESP header SHALL
contain the value (TBD via IANA) in its Protocol (IPv4) or Next contain the value (TBD via IANA) in its Protocol (IPv4) or Next
Header (IPv6, Extension) field. WESP provides additional Header (IPv6, Extension) field. WESP provides additional
attributes in each packet to assist in differentiating between attributes in each packet to assist in differentiating between
encrypted and non-encrypted data, and to aid parsing of the encrypted and non-encrypted data, and to aid parsing of the
packet. WESP follows RFC 4303 for all IPv6 and IPv4 packet. WESP follows RFC 4303 for all IPv6 and IPv4
considerations (e.g., alignment considerations). considerations (e.g., alignment considerations).
This extension essentially acts as a wrapper to the existing ESP This extension essentially acts as a wrapper to the existing ESP
protocol and provides an additional 4 octets at the front of the protocol and provides an additional 4 octets at the front of the
existing ESP packet. existing ESP packet for IPv4. For IPv6, additional padding may
be required and this is described below.
This may be depicted as follows: The packet format may be depicted as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wrapped ESP Header | | Wrapped ESP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation | | Existing ESP Encapsulation |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 43 skipping to change at page 7, line 7
receiver MUST ensure that the Next Header field in the WESP receiver MUST ensure that the Next Header field in the WESP
header and the Next Header field in the ESP trailer match when header and the Next Header field in the ESP trailer match when
using ESP in the Integrity only mode. The packet MUST be dropped using ESP in the Integrity only mode. The packet MUST be dropped
if the two do not match. Similarly, the receiver MUST ensure if the two do not match. Similarly, the receiver MUST ensure
that the Next Header field in the WESP header is an empty field that the Next Header field in the WESP header is an empty field
initialized to zero if using WESP with encryption. The WESP initialized to zero if using WESP with encryption. The WESP
flags dictate if the packet is encrypted. flags dictate if the packet is encrypted.
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. HdrLen present and any other WESP options defined in future) within the
MUST be set to zero when using ESP with encryption. When using encapsulated ESP header, in octets. HdrLen MUST be set to zero
integrity-only ESP, the following HdrLen values are invalid: any when using ESP with encryption. When using integrity-only ESP,
value less than 12; any value that is not a multiple of 4; any the following HdrLen values are invalid: any value less than 12;
value that is not a multiple of 8 when using IPv6. The receiver any value that is not a multiple of 4; any value that is not a
MUST ensure that this field matches with the header offset multiple of 8 when using IPv6. The receiver MUST ensure that
computed from using the negotiated SA and MUST drop the packet this field matches with the header offset computed from using
in case it does not match. the negotiated SA and MUST drop the packet in case it does not
match.
TrailerLen, 8 bits: TrailerLen contains the size of the ICV TrailerLen, 8 bits: TrailerLen contains the size of the ICV
being used by the negotiated algorithms within the IPsec SA, in being used by the negotiated algorithms within the IPsec SA, in
octets. TrailerLen MUST be set to zero when using ESP with octets. TrailerLen MUST be set to zero when using ESP with
encryption. The receiver MUST only accept the packet if this encryption. The receiver MUST only accept the packet if this
field matches with the value computed from using the negotiated field matches with the value computed from using the negotiated
SA. This insures that sender is not deliberately setting this SA. This insures that sender is not deliberately setting this
value to obfuscate a part of the payload from examination by a value to obfuscate a part of the payload from examination by a
trusted intermediary device. trusted intermediary device.
skipping to change at page 7, line 28 skipping to change at page 7, line 40
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V V|E|P| Rsvd | |V V|E|P| Rsvd |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3 Flags format Figure 3 Flags format
Version (V), 2 bits: MUST be sent as 0 and checked by the Version (V), 2 bits: MUST be sent as 0 and checked by the
receiver. If the version is different than an expected version receiver. If the version is different than an expected version
number (e.g. negotiated via the control channel), then the number (e.g. negotiated via the control channel), then the
packet MUST be dropped by the receiver. Future modifications to packet MUST be dropped by the receiver. Future modifications to
the WESP header may require a new version number. Intermediate the WESP header require a new version number. In particular, the
version of WESP defined in this document does not allow for any
extensions. However, old implementations will still be able to
find the encapsulated cleartext packet using the HdrLen field
from the WESP header, when the 'E' bit is not set. Intermediate
nodes dealing with unknown versions are not necessarily able to nodes dealing with unknown versions are not necessarily able to
parse the packet correctly. Intermediate treatment of such parse the packet correctly. Intermediate treatment of such
packets is policy-dependent (e.g., it may dictate dropping such packets is policy-dependent (e.g., it may dictate dropping such
packets). packets).
Encrypted Payload (E), 1 bit: Setting the Encrypted Payload Encrypted Payload (E), 1 bit: Setting the Encrypted Payload
bit 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 integrity-only ESP. Setting or clearing this payload is using integrity-only ESP. Setting or clearing this
bit also impacts the value in the WESP Next Header field, as bit 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.
Padding Present (P), 1 bit: If P=1 (Padding Present flag), Padding header (P), 1 bit: If set (value 1), the 4 octet
the first octet of the Padding field holds the padding length, padding is present. If not set (value 0), the 4 octet padding
in octets (including the length octet). All other Padding is absent. This padding MUST be used with IPv6 in order to
octets MUST be sent as zero, and MUST be ignored by the preserve IPv6 8-octet alignment. If WESP is being used with UDP
receiver and intermediate devices (however, this field is encapsulation (see 2.1 below) and IPv6, the Protocol Identifier
intended to allow future extensibility, so these restrictions (0x00000002) occupies four octets so the IPv6 padding is not
may be relaxed in a future document updating this RFC). needed, as the header is already on an 8-octet boundary. This
padding MUST NOT be used with IPv4, as it is not needed to
The padding length may be any length between 4 and 252 that guarantee 4-octet IPv4 alignment.
preserves the alignment of the ESP header (4 octet alignment
for IPv4, 8 octet alignment for IPv6). This padding MUST be
used with IPv6 in order to preserve IPv6 8-octet alignment. If
WESP is being used with UDP encapsulation (see 2.1 below) and
IPv6, the Protocol Identifier (0x00000002) occupies four octets
so the padding is not needed, as the header is already on an 8-
octet boundary.
Rsvd, 4 bits: Reserved for future use. The reserved bits Rsvd, 4 bits: Reserved for future use. The reserved bits
MUST be sent as 0, and ignored by the receiver. Future documents MUST be sent as 0, and ignored by the receiver. Future documents
defining any of these bits MUST NOT affect the distinction defining any of these bits MUST NOT affect the distinction
between encrypted and unencrypted packets. Intermediate nodes between encrypted and unencrypted packets or the semantics of
dealing with unknown reserved bits are not necessarily able to HdrLen. In other words, even if new bits are defined, old
parse the packet correctly. Intermediate treatment of such implementations will be able to find the encapsulated packet
packets is policy-dependent (e.g., it may dictate dropping such correctly. Intermediate nodes dealing with unknown reserved bits
packets). 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 Future versions of this protocol may change the version number
and/or the reserved bits sent, possibly by negotiating them over and/or the reserved bits sent, possibly by negotiating them over
the control channel. the control channel.
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 for IPv4 and optionally (see above) by 8 by the first 4 octets for IPv4 and optionally (see above) by 8
octets for IPv6. The WESP header is integrity protected, along octets for IPv6.
with all the fields specified for ESP in RFC 4303.
Modifying the integrity protection in ESP to include the
additional WESP header octets means that ESP implementations
cannot be simply reused. The chosen tradeoff errs on the side of
caution instead of treating ESP as a completely modular
component.
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
the UDP port for NAT-T discovery and usage [RFC3947, RFC4306], the UDP port for NAT-T discovery and usage [RFC3947, RFC4306],
as well as preserving the existing UDP ports for ESP (port as well as preserving the existing UDP ports for ESP (port
4500). With UDP encapsulation, the packet format can be 4500). With UDP encapsulation, the packet format can be
depicted as follows. depicted as follows.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
The remaining fields in the packet have the same meaning as per The remaining fields in the packet have the same meaning as per
section 2 above. section 2 above.
2.2. Transport and Tunnel Mode Considerations 2.2. Transport and Tunnel Mode Considerations
This extension is equally applicable to transport and tunnel mode This extension is equally applicable to transport and tunnel mode
where the ESP Next Header field is used to differentiate between where the ESP Next Header field is used to differentiate between
these modes, as per the existing IPsec specifications. these modes, as per the existing IPsec specifications.
In the diagrams below, "WESP ICV" refers to the ICV computation as
modified by this specification. Namely, the ESP ICV computation is
augmented to include the four octets that constitute the WESP header.
Otherwise, the ICV computation is as specified by ESP [RFC4303].
2.2.1. Transport Mode Processing 2.2.1. Transport Mode Processing
In transport mode, ESP is inserted after the IP header and before a In transport mode, ESP is inserted after the IP header and before a
next layer protocol, e.g., TCP, UDP, ICMP, etc. The following next layer protocol, e.g., TCP, UDP, ICMP, etc. The following
diagrams illustrate how WESP is applied to the ESP transport mode for diagrams illustrate how WESP is applied to the ESP transport mode for
a typical packet, on a "before and after" basis. a typical packet, on a "before and after" basis.
BEFORE APPLYING WESP - IPv4 BEFORE APPLYING WESP -IPv4
---------------------------- -------------------------------------------------
|orig IP hdr | | | |orig IP hdr | ESP | | | ESP | ESP|
|(any options)| TCP | Data | |(any options)| Hdr | TCP | Data | Trailer | ICV|
---------------------------- -------------------------------------------------
|<---- encryption ---->|
|<------- integrity -------->|
AFTER APPLYING WESP - IPv4 AFTER APPLYING WESP - IPv4
-------------------------------------------------------- --------------------------------------------------------
|orig IP hdr | WESP | ESP | | | ESP |WESP| |orig IP hdr | WESP | ESP | | | ESP | ESP|
|(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV| |(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------------- --------------------------------------------------------
|<---- encryption ---->| |<---- encryption ---->|
|<----------- integrity ----------->| |<------- integrity -------->|
BEFORE APPLYING WESP - IPv6 BEFORE APPLYING WESP - IPv6
---------------------------------------- --------------------------------------------------------------
| orig |hop-by-hop,dest*,|dest| | | | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|opt*|TCP|Data| |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------- --------------------------------------------------------------
|<---- encryption --->|
|<----- integrity ------->|
AFTER APPLYING WESP - IPv6 AFTER APPLYING WESP - IPv6
-------------------------------------------------------------- --------------------------------------------------------------
| orig |hop-by-hop,dest*,| | |dest| | | ESP |WESP| | orig |hop-by-hop,dest*,| | |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|WESP|ESP|opt*|TCP|Data|Trailer| ICV| |IP hdr|routing,fragment.|WESP|ESP|opt*|TCP|Data|Trailer| ICV|
-------------------------------------------------------------- --------------------------------------------------------------
|<---- encryption --->| |<---- encryption --->|
|<-------- integrity --------->| |<----- integrity ------->|
* = if present, could be before WESP, after ESP, or both * = if present, could be before WESP, after ESP, or both
All other considerations are as per RFC 4303. All other considerations are as per RFC 4303.
2.2.2. Tunnel Mode Processing 2.2.2. Tunnel Mode Processing
In tunnel mode, ESP is inserted after the new IP header and before In tunnel mode, ESP is inserted after the new IP header and before
the original IP header, as per RFC 4303. The following diagram the original IP header, as per RFC 4303. The following diagram
illustrates how WESP is applied to the ESP tunnel mode for a typical illustrates how WESP is applied to the ESP tunnel mode for a typical
packet, on a "before and after" basis. packet, on a "before and after" basis.
BEFORE APPLYING WESP - IPv4 BEFORE APPLYING WESP - IPv4
-------------------------- ---------------------------------------------------------
| orig IP hdr* | | | |new IP hdr* | | orig IP hdr* | | | ESP | ESP|
| (any options) |TCP|Data| |(any options)|ESP| (any options) |TCP|Data|Trailer| ICV|
-------------------------- ---------------------------------------------------------
|<--------- encryption --------->|
|<----------- integrity ------------>|
AFTER APPLYING WESP - IPv4 AFTER APPLYING WESP - IPv4
-------------------------------------------------------------- --------------------------------------------------------------
|new IP hdr* | | | orig IP hdr* | | | ESP |WESP| |new IP hdr* | | | orig IP hdr* | | | ESP | ESP|
|(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV| |(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV|
-------------------------------------------------------------- --------------------------------------------------------------
|<--------- encryption --------->| |<--------- encryption --------->|
|<--------------- integrity ------------->| |<----------- integrity ------------>|
BEFORE APPLYING WESP - IPv6 BEFORE APPLYING WESP - IPv6
--------------------------- -----------------------------------------------------------------
| orig*|orig ext | | | | new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs * |TCP|Data| |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
--------------------------- -----------------------------------------------------------------
|<--------- encryption ---------->|
|<------------- integrity ----------->|
AFTER APPLYING WESP - IPv6 AFTER APPLYING WESP - IPv6
----------------------------------------------------------------- -----------------------------------------------------------------
| new* |new ext | | | orig*|orig ext | | | ESP |WESP| | new* |new ext | | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |WESP|ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV| |IP hdr| hdrs* |WESP|ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
----------------------------------------------------------------- -----------------------------------------------------------------
|<--------- encryption ---------->| |<--------- encryption ---------->|
|<--------------- integrity -------------->| |<------------- integrity ----------->|
* = if present, construction of outer IP hdr/extensions and * = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in modification of inner IP hdr/extensions is discussed in
the Security Architecture document. the Security Architecture document.
All other considerations are as per RFC 4303. All other considerations are as per RFC 4303.
2.3. IKE Considerations 2.3. IKE Considerations
This document assumes that WESP negotiation is performed using This document assumes that WESP negotiation is performed using
IKEv2. In order to negotiate the new format of ESP encapsulation IKEv2. In order to negotiate the new format of ESP encapsulation
via IKEv2 [RFC4306], both parties need to agree to use the new via IKEv2 [RFC4306], both parties need to agree to use the new
packet format. This can be achieved using a notification method packet format. This can be achieved using a notification method
similar to USE_TRANSPORT_MODE defined in RFC 4306. similar to USE_TRANSPORT_MODE defined in RFC 4306.
The notification, USE_WESP_MODE (value TBD) MAY be included in a The notification, USE_WESP_MODE (value TBD) MUST be included in
request message that also includes an SA payload requesting a a request message that also includes an SA payload requesting a
CHILD_SA using ESP. It requests that the CHILD_SA use WESP mode CHILD_SA using ESP. It signals that the sender supports the
rather than ESP for the SA created. If the request is accepted, WESP version defined in the current document a requests that the
the response MUST also include a notification of type CHILD_SA use WESP mode rather than ESP for the SA created. If
USE_WESP_MODE. If the responder declines the request, the the request is accepted, the response MUST also include a
CHILD_SA will be established using ESP, as per RFC 4303. If notification of type USE_WESP_MODE. If the responder declines
this is unacceptable to the initiator, the initiator MUST delete the request, the CHILD_SA will be established using ESP, as per
the SA. Note: Except when using this option to negotiate WESP RFC 4303. If this is unacceptable to the initiator, the
mode, all CHILD_SAs will use standard ESP. initiator MUST delete the SA. Note: Except when using this
option to negotiate WESP mode, all CHILD_SAs will use standard
ESP.
Negotiation of WESP in this manner preserves all other Negotiation of WESP in this manner preserves all other
negotiation parameters, including NAT-T [RFC3948]. NAT-T is negotiation parameters, including NAT-T [RFC3948]. NAT-T is
wholly compatible with this wrapped frame format and can be used wholly compatible with this wrapped frame format and can be used
as-is, without any modifications, in environments where NAT is as-is, without any modifications, in environments where NAT is
present and needs to be taken into account. present and needs to be taken into account.
WESP version negotiation is not introduced as part of this
specification. If the WESP version is updated in a future
specification, then that document MUST specify how the WESP
version is negotiated.
3. Security Considerations 3. Security Considerations
As this document augments the existing ESP encapsulation format, As this document augments the existing ESP encapsulation format,
UDP encapsulation definitions specified in RFC 3948 and IKE UDP encapsulation definitions specified in RFC 3948 and IKE
negotiation of the new encapsulation, the security observations negotiation of the new encapsulation, the security observations
made in those documents also apply here. In addition, as this made in those documents also apply here. In addition, as this
document allows intermediate device visibility into IPsec ESP document allows intermediate device visibility into IPsec ESP
encapsulated frames for the purposes of network monitoring encapsulated frames for the purposes of network monitoring
functions, care should be taken not to send sensitive data over functions, care should be taken not to send sensitive data over
connections using definitions from this document, based on connections using definitions from this document, based on
network domain/administrative policy. A strong key agreement network domain/administrative policy. A strong key agreement
protocol, such as IKEv2, together with a strong policy engine protocol, such as IKEv2, together with a strong policy engine
should be used to in determining appropriate security policy for should be used in determining appropriate security policy for
the given traffic streams and data over which it is being the given traffic streams and data over which it is being
employed. employed.
ESP is end-to-end and it will be impossible for the intermediate ESP is end-to-end and it will be impossible for the intermediate
devices to verify that all the fields in the WESP header are devices to verify that all the fields in the WESP header are
correct. It is thus possible to modify the WESP header so that correct. It is thus possible to modify the WESP header so that
the packet sneaks past a firewall if the fields in the WESP the packet sneaks past a firewall if the fields in the WESP
header are set to something that the firewall will allow. The header are set to something that the firewall will allow. The
endpoint thus must verify the sanity of the WESP header before endpoint thus must verify the sanity of the WESP header before
accepting the packet. In an extreme case, someone colluding with accepting the packet. In an extreme case, someone colluding with
skipping to change at page 13, line 33 skipping to change at page 13, line 42
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]. For WESP version IANA Policy of "Standards Action" [RFC5226]. For WESP version
numbers, the unassigned values are 1, 2 and 3. The Encrypted numbers, the unassigned values are 1, 2 and 3. The Encrypted
Payload bit is used to indicate if the payload is encrypted or Payload bit is used to indicate if the payload is encrypted or
using integrity-only ESP. The Padding Present bit is used to using integrity-only ESP. The Padding Present bit is used to
signal the presence of padding. The remaining 4 bits of the WESP signal the presence of padding. The remaining 4 bits of the WESP
Flags are undefined and future assignment is to be managed via Flags are undefined and future assignment is to be managed via
the IANA Policy of "Specification Required". the IANA Policy of "IETF Review" [RFC5226].
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, Pasi Eronen, Men Long, David Durham, Prashant Dewan, Sheffer, Pasi Eronen, Men Long, David Durham, Prashant Dewan,
Marc Millier among others. Marc Millier, Russ Housley, Jari Arkko among others.
This document was prepared using 2-Word-v2.0.template.doc. This document was prepared using 2-Word-v2.0.template.doc.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 34 change blocks. 
100 lines changed or deleted 109 lines changed or added

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