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/