draft-ietf-ipsecme-traffic-visibility-09.txt   draft-ietf-ipsecme-traffic-visibility-10.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: April 07, 2010 Microsoft Corporation Expires: May 10, 2010 Microsoft Corporation
M. Bhatia M. Bhatia
Alcatel-Lucent Alcatel-Lucent
October 07, 2009 November 10, 2009
Wrapped ESP for Traffic Visibility Wrapped ESP for Traffic Visibility
draft-ietf-ipsecme-traffic-visibility-09.txt draft-ietf-ipsecme-traffic-visibility-10.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 April 07, 2010. This Internet-Draft will expire on May 10, 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 42 skipping to change at page 2, line 42
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
2. Wrapped ESP (WESP) Header format...............................5 2. Wrapped ESP (WESP) Header format...............................5
2.1. UDP Encapsulation.........................................8 2.1. UDP Encapsulation.........................................8
2.2. Transport and Tunnel Mode Considerations..................9 2.2. Transport and Tunnel Mode Considerations..................9
2.2.1. Transport Mode Processing............................9 2.2.1. Transport Mode Processing...........................10
2.2.2. Tunnel Mode Processing..............................10 2.2.2. Tunnel Mode Processing..............................11
2.3. IKE Considerations.......................................11 2.3. IKE Considerations.......................................12
3. Security Considerations.......................................12 3. Security Considerations.......................................12
4. IANA Considerations...........................................12 4. IANA Considerations...........................................13
5. Acknowledgments...............................................13 5. Acknowledgments...............................................13
6. References....................................................13 6. References....................................................14
6.1. Normative References.....................................13 6.1. Normative References.....................................14
6.2. Informative References...................................14 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 encapsulation is performed. It also specifies that ESP can
provide data confidentiality and data integrity services. Data provide data confidentiality and data integrity services. Data
integrity without data confidentiality ("integrity-only ESP") is integrity without data confidentiality ("integrity-only ESP") is
possible via the ESP-NULL encryption algorithm [RFC2410] or via possible via the ESP-NULL encryption algorithm [RFC2410] or via
combined-mode algorithms such as AES-GMAC [RFC4543]. The exact combined-mode algorithms such as AES-GMAC [RFC4543]. The exact
skipping to change at page 7, line 19 skipping to change at page 7, line 19
with the value computed from using the negotiated SA. This with the value computed from using the negotiated SA. This
insures that sender is not deliberately setting this value to insures that sender is not deliberately setting this value to
obfuscate a part of the payload from examination by a trusted obfuscate a part of the payload from examination by a trusted
intermediary device. intermediary device.
Flags, 8 bits: The bits are defined most-significant-bit (MSB) Flags, 8 bits: The bits are defined most-significant-bit (MSB)
first, so bit 0 is the most significant bit of the flags octet. first, so bit 0 is the most significant bit of the flags octet.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V V|E|X| 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 may require a new version number. Intermediate
nodes dealing with unknown versions are not necessarily able to nodes dealing with unknown versions are not necessarily able to
skipping to change at page 7, line 43 skipping to change at page 7, line 43
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.
Extended header (X), 1 bit: If set (value 1), the 4 octet padding Padding header (P), 1 bit: If set (value 1), the 4 octet padding
is present. If not set (value 0), the 4 octet padding is absent. This is present. If not set (value 0), the 4 octet padding is absent. This
padding SHOULD be used with IPv6 in order to preserve IPv6 8-octet padding MUST be used with IPv6 in order to preserve IPv6 8-octet
IPv6 alignment. This padding SHOULD NOT be used with IPv4, as it is alignment. If WESP is being used with UDP encapsulation (see 2.1
not needed to guarantee 4-octet IPv4 alignment. below) and IPv6, the Protocol Identifier (0x00000002) occupies four
octets so the IPv6 padding is not 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 guarantee 4-octet IPv4 alignment.
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. Intermediate nodes
dealing with unknown reserved bits are not necessarily able to dealing with unknown reserved bits 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).
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 by 8 octets for IPv6. The by the first 4 octets for IPv4 and optionally (see above) by 8
WESP header is integrity protected, along with all the fields octets for IPv6. The WESP header is integrity protected, along
specified for ESP in RFC 4303. 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.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrLen | TrailerLen | Flags | | Next Header | HdrLen | TrailerLen | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6Padding (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Existing ESP Encapsulation | | Existing ESP Encapsulation |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 UDP-Encapsulated WESP Header Figure 4 UDP-Encapsulated WESP Header
Where: Where:
Source/Destination port (4500) and checksum: describes the UDP Source/Destination port (4500) and checksum: describes the UDP
skipping to change at page 13, line 43 skipping to change at page 14, line 9
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 Kent, S., "The NULL Encryption Algorithm [RFC2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm
and Its Use With IPsec", RFC 2410, November 1998. and Its Use With IPsec", RFC 2410, November 1998.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4543] McGrew, D. and Viega J., "The Use of Galois Message [RFC4543] McGrew, D. and Viega J., "The Use of Galois Message
Authentication Code (GMAC) in IPsec ESP and AH", RFC Authentication Code (GMAC) in IPsec ESP and AH", RFC
4543, May 2006. 4543, May 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing
Requirement Levels", BCP 14, RFC 2119, March 1997. an IANA Considerations Section in RFCs", RFC 5226,
May 2008.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
6.2. Informative References 6.2. Informative References
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. 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., and
M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
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) 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
an IANA Considerations Section in RFCs", RFC 5226,
May 2008.
[Heuristics I-D] Kivinen, T., McDonald, D., "Heuristics for Detecting [Heuristics I-D] Kivinen, T., McDonald, D., "Heuristics for Detecting
ESP-NULL packets", Internet Draft, April 2009. 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
skipping to change at page 15, line 15 skipping to change at page 15, line 27
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 Manav Bhatia
Alcatel-Lucent Alcatel-Lucent
Bangalore Manyata Embassy
Nagawara Bangalore
India India
Phone: Phone:
Email: manav@alcatel-lucent.com Email: manav.bhatia@alcatel-lucent.com
 End of changes. 20 change blocks. 
35 lines changed or deleted 44 lines changed or added

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