draft-ietf-ipsecme-traffic-visibility-01.txt   draft-ietf-ipsecme-traffic-visibility-02.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: September 09, 2009 Microsoft Corporation Expires: October 30, 2009 Microsoft Corporation
March 09, 2009 M. Bhatia
Alcatel-Lucent
April 30, 2009
Wrapped ESP for Traffic Visibility Wrapped ESP for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-01.txt draft-ietf-ipsecme-traffic-visibility-02.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 1, line 33 skipping to change at page 1, line 35
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 September 9, 2009. This Internet-Draft will expire on October 30, 2009.
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
your rights and restrictions with respect to this document. your rights and restrictions with respect to this document.
Abstract Abstract
This document describes the Wrapped Encapsulating Security
This document describes an ESP encapsulation for IPsec, allowing Payload (WESP) protocol, which builds on top of ESP [RFC4303]
intermediate devices to ascertain if ESP-NULL is being employed and is designed to allow intermediate devices to ascertain if
and hence inspect the IPsec packets for network monitoring and ESP-NULL is being employed and hence inspect the IPsec packets
access control functions. Currently in the IPsec standard, for network monitoring and access control functions. Currently
there is no way to differentiate between ESP encryption and ESP in the IPsec standard, there is no way to differentiate between
NULL encryption by simply examining a packet. ESP encryption and ESP NULL encryption by simply examining a
packet. This poses certain challenges to the intermediate
devices that need to deep inspect the packet before making a
decision on what should be done with that packet (Inspect and/or
Allow/Drop). The 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 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......................................5 2.1. UDP Encapsulation.........................................6
2.2. Tunnel and Transport mode of considerations............7 2.2. Transport and Tunnel Mode Considerations..................7
2.3. IKE Considerations.....................................7 2.2.1. Transport Mode Processing............................7
3. Security Considerations.....................................7 2.2.2. Tunnel Mode Processing...............................8
4. IANA Considerations.........................................8 2.3. IKE Considerations........................................9
5. Acknowledgments.............................................8 3. Security Considerations.......................................10
6. References..................................................8 4. IANA Considerations...........................................11
6.1. Normative References...................................8 5. Acknowledgments...............................................11
6.2. Informative References.................................8 6. References....................................................11
6.1. Normative References.....................................11
6.2. Informative References...................................11
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 [RFC2410] while preserving data integrity and NULL encryption [RFC2410] 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.
Enterprise environments typically employ numerous security Enterprise environments typically employ numerous security
policies (and tools for enforcing them), as related to access policies (and tools for enforcing them), as related to access
control, firewalls, network monitoring functions, deep packet control, content screening, firewalls, network monitoring
inspection, Intrusion Detection and Prevention Systems (IDS and functions, deep packet inspection, Intrusion Detection and
IPS), scanning and detection of viruses and worms, etc. In Prevention Systems (IDS and IPS), scanning and detection of
order to enforce these policies, network tools and intermediate viruses and worms, etc. In order to enforce these policies,
devices require visibility into packets, ranging from simple network tools and intermediate devices require visibility into
packet header inspection to deeper payload examination. Network packets, ranging from simple packet header inspection to deeper
security protocols which encrypt the data in transit prevent payload examination. Network security protocols which encrypt
these network tools from performing the aforementioned the data in transit prevent these network tools from performing
functions. the aforementioned functions.
When employing IPsec within an enterprise environment, it is When employing IPsec within an enterprise environment, it is
desirable to employ ESP instead of AH [RFC4302], as AH does not desirable to employ ESP instead of AH [RFC4302], as AH does not
work in NAT environments. Furthermore, in order to preserve the work in NAT environments. Furthermore, in order to preserve the
above network monitoring functions, it is desirable to use ESP- above network monitoring functions, it is desirable to use ESP-
NULL. In a mixed mode environment some packets containing NULL. In a mixed mode environment some packets containing
sensitive data employ a given encryption cipher suite, while sensitive data employ a given encryption cipher suite, while
other packets employ ESP-NULL. For an intermediate device to other packets employ ESP-NULL. For an intermediate device to
unambiguously distinguish which packets are leveraging ESP-NULL, unambiguously distinguish which packets are leveraging ESP-NULL,
they would require knowledge of all the policies being employed they would require knowledge of all the policies being employed
skipping to change at page 3, line 40 skipping to change at page 3, line 50
network devices employed within a given network and a network devices employed within a given network and a
deterministic approach would provide a simple solution for all deterministic approach would provide a simple solution for all
these devices. Enterprise environments typically use both these devices. Enterprise environments typically use both
stateful and stateless packet inspection mechanisms. The stateful and stateless packet inspection mechanisms. The
previous considerations weigh particularly heavy on stateless previous considerations weigh particularly heavy on stateless
mechanisms such as router ACLs and NetFlow exporters. mechanisms such as router ACLs and NetFlow exporters.
Nevertheless, a deterministic approach provides a simple Nevertheless, a deterministic approach provides a simple
solution for the myriad types of devices employed within a solution for the myriad types of devices employed within a
network, regardless of their stateful or stateless nature. network, regardless of their stateful or stateless nature.
This document defines a mechanism to prove additional This document defines a mechanism to provide additional
information in relevant IPsec packets so intermediate devices information in relevant IPsec packets so intermediate devices
can efficiently differentiate between encrypted ESP packets and can efficiently differentiate between encrypted ESP packets and
ESP packets with NULL encryption. ESP packets with NULL encryption.
The document is consistent with the operation of ESP in NAT The document is consistent with the operation of ESP in NAT
environments [RFC3947]. environments [RFC3947].
The design principles for this protocol are the following: The design principles for this protocol are the following:
o Allow easy identification and parsing of integrity-only IPsec o Allow easy identification and parsing of integrity-only IPsec
skipping to change at page 5, line 10 skipping to change at page 5, line 26
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 | | Flags | Next Header | HdrLen | TrailerLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation | | Existing ESP Encapsulation |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Detailed WESP Packet Format Figure 2 Detailed WESP Packet Format
Where: Where:
Next Header, 8 bits: next protocol header (encrypted in ESP
trailer, but in the clear in header), providing easy access to a
HW parser to extract the upper layer protocol. Note: For
security concerns, this value may optionally be set to zero, in
which case the next header can be extracted from the ESP
trailer.
HdrLen, 8 bits: includes the new header, the full ESP header and
the IV (if present). It is an offset to the beginning of the
Payload Data.
TrailerLen, 8 bits: Offset from the end of the packet including
the ICV, pad length, and any padding. It is an offset from the
end of the packet to the last byte of the payload data.
Flags, 8 bits Flags, 8 bits
2 bits: Version 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 will require an update in the version number.
6 bits: reserved for future use. These MUST be set to zero 6 bits: reserved for future use. These MUST be set to zero
per this specification, but usage may be defined by other per this specification, but usage may be defined by other
specifications. specifications.
Note: To provide future compatibility, the version number is
negotiated by the control channel handshake. An 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.
Next Header, 8 bits: If using ESP-NULL, this field MUST be
equal to the Next Header field in the ESP trailer. If using ESP
in encryption mode, this field MUST be set to zero..
HdrLen, 8 bits: Offset to the beginning of the Payload Data in
octets.
TrailerLen, 8 bits: Offset from the end of the packet to the
last byte of the payload data in octets.
As can be seen, this wrapped ESP format extends the standard ESP As can be seen, this wrapped ESP format extends the standard ESP
header by the first 4 octets. 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 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], as well as the UDP port for NAT-T discovery and usage [RFC3947], as well as
preserving the existing UDP ports for ESP (port 4500). With UDP preserving the existing UDP ports for ESP (port 4500). With UDP
encapsulation, the packet format can be depicted as follows. encapsulation, the packet format can 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src Port (4500) | Dest Port (4500) | | Src Port (4500) | Dest Port (4500) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier (value = 0x00000001) | | Protocol Identifier (value = 0x00000002) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrLen | TrailerLen | Flags | | Flags | Next Header | HdrLen | TrailerLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation | | Existing ESP Encapsulation |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 UDP-Encapsulated WESP Header Figure 3 UDP-Encapsulated WESP Header
Where: Where:
Source/Destination port (4500) and checksum: describes the UDP Source/Destination port (4500) and checksum: describes the UDP
encapsulation header, per RFC3948. encapsulation header, per RFC3948.
Protocol Identifier: new field to demultiplex between UDP Protocol Identifier: new field to demultiplex between UDP
encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and
the UDP encapsulation in this specification. the UDP encapsulation in this specification.
According to RFC 3948, clause 2.2, a 4 octet value of zero (0) According to RFC 3948, clause 2.2, a 4 octet value of zero (0)
immediately following the UDP header indicates a Non-ESP marker, immediately following the UDP header indicates a Non-ESP marker,
which can be used to assume that the data following that value which can be used to assume that the data following that value
is an IKE packet. Similarly, a value of non-zero indicates that is an IKE packet. Similarly, a value greater then 255 indicates
the packet is an ESP packet and the 4-octet value can be treated that the packet is an ESP packet and the 4-octet value can be
as the ESP SPI. However, RFC 4303, clause 2.1 indicates that the treated as the ESP SPI. However, RFC 4303, clause 2.1 indicates
values 1-255 are reserved and cannot be used as the SPI. We that the values 1-255 are reserved and cannot be used as the
leverage that knowledge and use a value of 1 to indicate that SPI. We leverage that knowledge and use one of these reserved
the UDP encapsulated ESP header contains this new packet format values to indicate that the UDP encapsulated ESP header contains
for ESP encapsulation. this new packet format for ESP encapsulation.
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. Tunnel and Transport mode of considerations 2.2. Transport and Tunnel Mode Considerations
This extension is equally applicable for tunnel and transport This extension is equally applicable for transport and tunnel
mode where the ESP Next Header field is used to differentiate mode where the ESP Next Header field is used to differentiate
between these modes, as per the existing IPsec specifications. between these modes, as per the existing IPsec specifications.
2.2.1. Transport Mode Processing
In transport mode, ESP is inserted after the IP header and before a
next layer protocol, e.g., TCP, UDP, ICMP, etc. The following
diagrams illustrate how WESP is applied to the ESP transport mode for
a typical packet, on a "before and after" basis.
BEFORE APPLYING WESP - IPv4
-------------------------------------------------
|orig IP hdr | ESP | | | ESP | ESP|
|(any options)| Hdr | TCP | Data | Trailer | ICV|
-------------------------------------------------
|<----encryption ----->|
|<------- integrity -------->|
AFTER APPLYING WESP - IPv4
--------------------------------------------------------
|orig IP hdr | WESP | ESP | | | ESP |WESP|
|(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV|
--------------------------------------------------------
|<---- encryption ---->|
|<----------- integrity ----------->|
BEFORE APPLYING WESP - IPv6
---------------------------------------------------------
| orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
---------------------------------------------------------
|<---- encryption --->|
|<------ integrity ------>|
AFTER APPLYING WESP - IPv6
--------------------------------------------------------------
| orig |hop-by-hop,dest*,| | |dest| | | ESP |WESP|
|IP hdr|routing,fragment.|WESP|ESP|opt*|TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<---- encryption --->|
|<-------- integrity --------->|
* = if present, could be before WESP, after ESP, or both
All other considerations are as per RFC 4303.
2.2.2. Tunnel Mode Processing
In tunnel mode, ESP is inserted after the new IP header and before
the original IP header, as per RFC 4303. The following diagram
illustrates how WESP is applied to the ESP tunnel mode for a typical
packet, on a "before and after" basis.
BEFORE APPLYING WESP - IPv4
-----------------------------------------------------------
| new IP hdr* | | orig IP hdr* | | | ESP | ESP|
|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|
-----------------------------------------------------------
|<--------- encryption --------->|
|<------------- integrity ------------>|
AFTER APPLYING WESP - IPv4
--------------------------------------------------------------
|new IP hdr* | | | orig IP hdr* | | | ESP |WESP|
|(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV|
--------------------------------------------------------------
|<--------- encryption --------->|
|<--------------- integrity ------------->|
BEFORE APPLYING WESP - IPv6
------------------------------------------------------------
| new* |new ext | | orig*|orig ext | | | ESP | ESP|
|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
------------------------------------------------------------
|<--------- encryption ---------->|
|<------------ integrity ------------>|
AFTER APPLYING WESP - IPv6
-----------------------------------------------------------------
| new* |new ext | | | orig*|orig ext | | | ESP |WESP|
|IP hdr| hdrs* |WESP|ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
-----------------------------------------------------------------
|<--------- encryption ---------->|
|<--------------- integrity -------------->|
* = if present, construction of outer IP hdr/extensions and
modification of inner IP hdr/extensions is discussed in
the Security Architecture document.
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 by proposing a new protocol packet format. This can be achieved using a notification method
ID within the existing IKE proposal structure as defined by RFC similar to USE_TRANSPORT_MODE defined in RFC 4306.
4306, clause 3.3.1. The existing proposal substructure in this
clause allows negotiation of ESP/AH (among others) by using
different protocol Ids for these protocols. By using the same
protocol substructure in the proposal payload and using a new
value (TBD) for this encapsulation, the existing IKE negotiation
can be leverage with minimal changes to support negotiation of
this encapsulation.
Furthermore, because the negotiation is at the protocol level, The notification, USE_WESP_MODE (value TBD) MAY be included in a
other transforms remain valid for this new encapsulation and request message that also includes an SA payload requesting a
consistent with IKEv2 [RFC4306]. Additionally, NAT-T [RFC3948] CHILD_SA using ESP. It requests that the CHILD_SA use WESP mode
is wholly compatible with this wrapped frame format and can be rather than ESP for the SA created. If the request is accepted,
used as-is, without any modifications, in environments where NAT the response MUST also include a notification of type
is present and needs to be taken into account. USE_WESP_MODE. If the responder declines the request, the
CHILD_SA will be established using ESP, as per RFC 4303. If
this is unacceptable to the initiator, the 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 parameters, including NAT-T [RFC3948]. NAT-T is
wholly compatible with this wrapped frame format and can be used
as-is, without any modifications, in environments where NAT is
present and needs to be taken into account.
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 IKE, together with a strong policy engine protocol, such as IKE, together with a strong policy engine
should be used to in determining appropriate security policy for should be used to 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
devices to verify that all the fields in the WESP header are
correct. It is thus possible to tweak the WESP header so that
the packet sneaks past the firewall if the fields in the WESP
header are set to something that the firewall will allow. The
endpoint thus must verify the sanity of the WESP header before
accepting the packet. In an extreme case, someone colluding with
the attacker, could change the WESP fields back to the original
values so that the attack goes unnoticed. However, this is not a
new problem and it already exists IPSec.
4. IANA Considerations 4. IANA Considerations
Reserving an appropriate value for this encapsulation as well as Reserving an appropriate value for this encapsulation as well as
a new value for the protocol in the IKE negotiation is TBD by a new value for the protocol in the IKE negotiation is TBD by
IANA. IANA.
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.
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.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm
and Its Use With IPsec", RFC 2410, November 1998. and Its Use With IPsec", RFC 2410, November 1998.
skipping to change at line 392 skipping to change at page 12, line 24
Email: ken.grewal@intel.com Email: ken.grewal@intel.com
Gabriel Montenegro Gabriel Montenegro
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Phone: Phone:
Email: gabriel.montenegro@microsoft.com Email: gabriel.montenegro@microsoft.com
Manav Bhatia
Alcatel-Lucent
Bangalore
India
Phone:
Email: manav@alcatel-lucent.com
 End of changes. 24 change blocks. 
79 lines changed or deleted 200 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/