draft-ietf-ipsecme-traffic-visibility-02.txt   draft-ietf-ipsecme-traffic-visibility-03.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: October 30, 2009 Microsoft Corporation Expires: November 30, 2009 Microsoft Corporation
M. Bhatia M. Bhatia
Alcatel-Lucent Alcatel-Lucent
April 30, 2009 May 30, 2009
Wrapped ESP for Traffic Visibility Wrapped ESP for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-02.txt draft-ietf-ipsecme-traffic-visibility-03.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 5 skipping to change at page 2, line 5
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 the Wrapped Encapsulating Security
Payload (WESP) protocol, which builds on top of ESP [RFC4303] Payload (WESP) protocol, which builds on top of Encapsulating
and is designed to allow intermediate devices to ascertain if Security Payload (ESP) [RFC4303] and is designed to allow
ESP-NULL is being employed and hence inspect the IPsec packets intermediate devices to ascertain if ESP-NULL [RFC2410] is being
for network monitoring and access control functions. Currently employed and hence inspect the IPsec packets for network
in the IPsec standard, there is no way to differentiate between monitoring and access control functions. Currently in the IPsec
ESP encryption and ESP NULL encryption by simply examining a standard, there is no way to differentiate between ESP
packet. This poses certain challenges to the intermediate encryption and ESP NULL encryption by simply examining a packet.
devices that need to deep inspect the packet before making a This poses certain challenges to the intermediate devices that
decision on what should be done with that packet (Inspect and/or need to deep inspect the packet before making a decision on what
Allow/Drop). The mechanism described in this document can be should be done with that packet (Inspect and/or Allow/Drop). The
used to easily disambiguate ESP-NULL from ESP encrypted packets, mechanism described in this document can be used to easily
without compromising on the security provided by ESP. 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.........................................6 2.1. UDP Encapsulation.........................................6
2.2. Transport and Tunnel Mode Considerations..................7 2.2. Transport and Tunnel Mode Considerations..................8
2.2.1. Transport Mode Processing............................7 2.2.1. Transport Mode Processing............................8
2.2.2. Tunnel Mode Processing...............................8 2.2.2. Tunnel Mode Processing...............................9
2.3. IKE Considerations........................................9 2.3. IKE Considerations.......................................10
3. Security Considerations.......................................10 3. Security Considerations.......................................11
4. IANA Considerations...........................................11 4. IANA Considerations...........................................12
5. Acknowledgments...............................................11 5. Acknowledgments...............................................12
6. References....................................................11 6. References....................................................12
6.1. Normative References.....................................11 6.1. Normative References.....................................12
6.2. Informative References...................................11 6.2. Informative References...................................13
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 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, content screening, firewalls, network monitoring control, content screening, firewalls, network monitoring
functions, deep packet inspection, Intrusion Detection and functions, deep packet inspection, Intrusion Detection and
Prevention Systems (IDS and IPS), scanning and detection of Prevention Systems (IDS and IPS), scanning and detection of
viruses and worms, etc. In order to enforce these policies, viruses and worms, etc. In order to enforce these policies,
skipping to change at page 4, line 31 skipping to change at page 4, line 31
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
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 AH [RFC4302]. [RFC4303] nor IP Authentication Header (AH) [RFC4302].
2. Wrapped ESP (WESP) Header format 2. Wrapped ESP (WESP) Header format
The proposal is to define a protocol number for Wrapped ESP Wrapped ESP encapsulation (WESP) uses protocol number (TBD via
encapsulation (WESP), which provides additional attributes in IANA) different from AH and ESP. Accordingly, the (outer)
each packet to assist in differentiating between encrypted and protocol header (IPv4, IPv6, or Extension) that immediately
non-encrypted data, as well as aid parsing of the packet. WESP precedes the WESP header SHALL contain the value (TBD via IANA)
follows RFC 4303 for all IPv6 and IPv4 considerations (e.g., in its Protocol (IPv4) or Next Header (IPv6, Extension) field.
alignment considerations). WESP provides additional attributes in each packet to assist in
differentiating between encrypted and non-encrypted data, and to
aid parsing of the packet. WESP follows RFC 4303 for all IPv6
and IPv4 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.
This may be depicted as follows: This 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 26 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Next Header | HdrLen | TrailerLen | | Next Header | HdrLen | TrailerLen | 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
Header field in the ESP trailer when using ESP in the Integrity
only mode, and MUST be set to zero when using ESP with
Encryption. The receiver MUST do some sanity checks before the
WESP packet is accepted. Receiver MUST ensure that the Next
Header field in the WESP header and the Next Header field in 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
header is zero if using ESP with encryption. In this case, the
packet MUST be dropped if it is not set to zero and the packet
is encrypted.
HdrLen, 8 bits: Offset to the beginning of the Payload Data in
octets. The receiver MUST ensure that this field matches with
the header offset computed from using the negotiated SA and MUST
drop the packet in case it doesn't match.
TrailerLen, 8 bits: Offset from the end of the packet to the
last byte of the payload data in octets. TrailerLen MUST be set
to zero when using ESP with encryption. The receiver MUST only
accept the packet if this field matches with the value computed
from using the negotiated SA. This insures that sender is not
deliberately setting this value to obfuscate a part of the
payload from examination by a trusted intermediary device.
Flags, 8 bits Flags, 8 bits
2 bits: Version. Version is set to 0 by the transmitter and 2 bits: Version. Version is set to 0 by the transmitter and
validated by the receiver. Any modifications to the WESP header validated by the receiver. Any modifications to the WESP header
in the future will require an update in the version number. in the future may require an update in the version number.
Intermediate nodes dealing with unknown versions are not
necessarily able to parse the packet correctly. Intermediate
treatment of such packets is policy-dependent (e.g., it may
dictate dropping such packets).
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. Intermediate nodes compliant with this
specification SHOULD check that these bits are set to zero. If
any bits are non-zero, it is possible that the packet has a
different format than specified here. Policy dictates final
treatment of such packets at intermediate nodes (e.g., including
dropping such packets).
Note: To provide future compatibility, the version number is Note: To provide future compatibility, the version number is
negotiated by the control channel handshake. An implementation negotiated by the control channel handshake. An end-node
compatible with this specification must set the version number implementation compatible with this specification must set the
and the reserved bits to the values specified above when version number and the reserved bits to the values specified
transmitting a packet. On receiving a packet, these values must above when transmitting a packet. On receiving a packet, these
be checked to ensure that they are as indicated above. values must be checked to ensure that they are as indicated
above and the packet MUST be dropped in case they don't match.
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, the WESP format extends the standard ESP header
header by the first 4 octets. The WESP header is integrity by the first 4 octets. The WESP header is integrity protected,
protected, along with all the fields specified for ESP in RFC along with all the fields specified for ESP in RFC 4303.
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, RFC4306],
preserving the existing UDP ports for ESP (port 4500). With UDP as well as preserving the existing UDP ports for ESP (port
encapsulation, the packet format can be depicted as follows. 4500). With UDP 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier (value = 0x00000002) | | Protocol Identifier (value = 0x00000002) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 28 skipping to change at page 8, line 7
that the values 1-255 are reserved and cannot be used as the that the values 1-255 are reserved and cannot be used as the
SPI. We leverage that knowledge and use one of these reserved SPI. We leverage that knowledge and use one of these reserved
values to indicate that the UDP encapsulated ESP header contains values to indicate that the UDP encapsulated ESP header contains
this new packet format 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. Transport and Tunnel Mode Considerations 2.2. Transport and Tunnel Mode Considerations
This extension is equally applicable for transport and tunnel This extension is equally applicable to transport and tunnel mode
mode where the ESP Next Header field is used to differentiate where the ESP Next Header field is used to differentiate between
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
------------------------------------------------- -------------------------------------------------
skipping to change at page 10, line 36 skipping to change at page 11, line 35
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 IKEv2, 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 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 tweak the WESP header so that correct. It is thus possible to modify the WESP header so that
the packet sneaks past the 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
the attacker, could change the WESP fields back to the original the attacker, could change the WESP fields back to the original
values so that the attack goes unnoticed. However, this is not a values so that the attack goes unnoticed. However, this is not a
new problem and it already exists IPSec. new problem and it already exists IPSec.
4. IANA Considerations 4. IANA Considerations
Reserving an appropriate value for this encapsulation as well as The WESP protocol number is assigned by IANA out of the IP
a new value for the protocol in the IKE negotiation is TBD by Protocol Number space (and as recorded at the IANA web page at
IANA. http://www.iana.org/assignments/protocol-numbers) is: TBD.
The USE_WESP_MODE notification number is assigned out of the
"IKEv2 Notify Message Types - Status Types" registry's 16384-
40959 (Expert Review) range: TBD.
This specification requests that IANA create a new registry for
"WESP Flags" to be managed as follows:
The first 2 bits are the WESP Version Number. The value 0 is
assigned to the version defined in this specification. Further
assignments of the WESP Version Number are to be managed via the
IANA Policy of "Standards Action" [RFC5226]. The final 6 bits of
the WESP Flags are the "Non-version Flags". This specification
defines no values, 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.
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
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
6.2. Informative References 6.2. Informative References
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, "Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005. January 2005.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
3948, January 2005. RFC 3948, January 2005.
[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) [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Protocol", RFC 4306, December 2005. RFC 4306, December 2005.
[RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 5226,
May 2008.
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:
 End of changes. 24 change blocks. 
77 lines changed or deleted 131 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/