draft-ietf-ipsecme-traffic-visibility-07.txt		draft-ietf-ipsecme-traffic-visibility-08.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: February 10, 2010 Microsoft Corporation		Expires: March 01, 2010 Microsoft Corporation
	M. Bhatia		M. Bhatia
	Alcatel-Lucent		Alcatel-Lucent
	August 10, 2009		September 01, 2009
	Wrapped ESP for Traffic Visibility		Wrapped ESP for Traffic Visibility
	draft-ietf-ipsecme-traffic-visibility-07.txt		draft-ietf-ipsecme-traffic-visibility-08.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 February 10, 2010.		This Internet-Draft will expire on March 01, 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 40		skipping to change at page 2, line 40
	disambiguate ESP-NULL from ESP encrypted packets, without		disambiguate ESP-NULL from ESP encrypted packets, without
	compromising on the security provided by ESP.		compromising on the security 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.........................................7		2.1. UDP Encapsulation.........................................7
	2.2. Transport and Tunnel Mode Considerations..................8		2.2. Transport and Tunnel Mode Considerations..................9
	2.2.1. Transport Mode Processing............................8		2.2.1. Transport Mode Processing............................9
	2.2.2. Tunnel Mode Processing...............................9		2.2.2. Tunnel Mode Processing..............................10
	2.3. IKE Considerations.......................................10		2.3. IKE Considerations.......................................11
	3. Security Considerations.......................................11		3. Security Considerations.......................................12
	4. IANA Considerations...........................................12		4. IANA Considerations...........................................13
	5. Acknowledgments...............................................12		5. Acknowledgments...............................................13
	6. References....................................................12		6. References....................................................13
	6.1. Normative References.....................................12		6.1. Normative References.....................................13
	6.2. Informative References...................................13		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 use		encapsulation is performed. It also specifies that ESP can use
	NULL encryption 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.
	skipping to change at page 5, line 5		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
			distinguish between encrypted and unencrypted ESP traffic:
			- The heuristics approach [Heuristics I-D] has the intermediate
			node inspect the unchanged ESP traffic, to determine with
			extremely high probability whether or not the traffic stream is
			encrypted.
			- The Wrapped ESP (WESP) approach described in this document, in
			contrast, requires the ESP endpoints to be modified to support
			the new protocol. WESP allows the intermediate node to
			distinguish encrypted and unencrypted traffic deterministically,
			using a simpler implementation for the intermediate node.
			Both approaches are being documented simultaneously by the IP
			Security Maintenance and Extensions (IPsecME) Working Group,
			with WESP being put on Standards Track while the heuristics
			approach is being published as an Informational RFC. While
			endpoints are being modified to adopt WESP, we expect both
			approaches to coexist for years, because the heuristic approach
			is needed to inspect traffic where at least one of the endpoints
			has not been modified. In other words, intermediate nodes are
			expected to support both approaches in order to achieve good
			security and performance during the transition period.
	2. Wrapped ESP (WESP) Header format		2. Wrapped ESP (WESP) Header format
	Wrapped ESP encapsulation (WESP) uses protocol number (TBD via		Wrapped ESP encapsulation (WESP) uses protocol number (TBD via
	IANA) different from AH and ESP. Accordingly, the (outer)		IANA) different from AH and ESP. Accordingly, the (outer)
	protocol header (IPv4, IPv6, or Extension) that immediately		protocol header (IPv4, IPv6, or Extension) that immediately
	precedes the WESP header SHALL contain the value (TBD via IANA)		precedes the WESP header SHALL contain the value (TBD via IANA)
	in its Protocol (IPv4) or Next Header (IPv6, Extension) field.		in its Protocol (IPv4) or Next Header (IPv6, Extension) field.
	WESP provides additional attributes in each packet to assist in		WESP provides additional attributes in each packet to assist in
	differentiating between encrypted and non-encrypted data, and to		differentiating between encrypted and non-encrypted data, and to
	aid parsing of the packet. WESP follows RFC 4303 for all IPv6		aid parsing of the packet. WESP follows RFC 4303 for all IPv6
	skipping to change at page 5, line 34		skipping to change at page 6, line 4
	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 |
	~ ~		~ ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1 WESP Packet Format		Figure 1 WESP Packet Format
	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 |		| Next Header | HdrLen | TrailerLen |V|V|E| 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		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		Header field in the ESP trailer when using ESP in the Integrity
	only mode, and MUST be set to zero when using ESP with		only mode. When using ESP with encryption, the "Next Header"
	Encryption. The receiver MUST do some sanity checks before the		field looses this name and semantics and becomes an empty field
	WESP packet is accepted. Receiver MUST ensure that the Next		which MUST be initialized to all zeros. The receiver MUST do
	Header field in the WESP header and the Next Header field in the		some sanity checks before the WESP packet is accepted. 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		receiver MUST ensure that the Next Header field in the WESP
	header is zero if using WESP with encryption. The WESP flags		header and the Next Header field in the ESP trailer match when
	dictate if the packet is encrypted and/or integrity protected.		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 an empty field
			initialized to zero if using WESP with encryption. The WESP
			flags dictate if the packet is encrypted and/or integrity
			protected.
	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. The		present) within the encapsulated ESP header, in octets. The
	receiver MUST ensure that this field matches with the header		receiver MUST ensure that this field matches with the header
	offset computed from using the negotiated SA and MUST drop the		offset computed from using the negotiated SA and MUST drop the
	packet in case it doesn't match.		packet in case it doesn't match.
	TrailerLen, 8 bits: Offset from the end of the packet to the		TrailerLen, 8 bits: Offset from the end of the packet to the
	last byte of the payload data in octets. TrailerLen MUST be set		last byte of the payload data in octets. TrailerLen MUST be set
	to zero when using ESP with encryption. The receiver MUST only		to zero when using ESP with encryption. The receiver MUST only
	accept the packet if this field matches with the value computed		accept the packet if this field matches with the value computed
	from using the negotiated SA. This insures that sender is not		from using the negotiated SA. This insures that sender is not
	deliberately setting this value to obfuscate a part of the		deliberately setting this value to obfuscate a part of the
	payload from examination by a trusted intermediary device.		payload from examination by a trusted intermediary device.
	Flags, 8 bits		Flags, 8 bits: The bits are defined LSB first, so bit 0 would be
			the least significant bit of the flags octet.
	2 bits: Version. MUST be sent as 0 and checked by the		2 bits: Version (V). MUST be sent as 0 and checked by the
	receiver. Future modifications to the WESP header may require a		receiver. If the version is different than an expected version
	new version number. Intermediate nodes dealing with unknown		number (e.g. negotiated via the control channel), then the
	versions are not necessarily able to parse the packet correctly.		packet must be dropped by the receiver. Future modifications to
	Intermediate treatment of such packets is policy-dependent		the WESP header may require a new version number. Intermediate
	(e.g., it may dictate dropping such packets).		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).
	1 bit: Encrypted Payload. Setting the Encrypted Payload bit		1 bit: Encrypted Payload (E). Setting the Encrypted Payload
	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 ESP-NULL cipher. Setting or clearing this bit		payload is using ESP-NULL cipher. Setting or clearing this bit
	also impacts the value in the WESP Next Header field, as		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.
	5 bits: Flags, reserved for future use. The flags MUST be		5 bits: Flags, reserved for future use. The flags MUST be
	sent as 0, and ignored by the receiver. Future documents		sent as 0, and ignored by the receiver. Future documents
	defining any of these flags MUST NOT affect the distinction		defining any of these flags MUST NOT affect the distinction
	between encrypted and unencrypted packets. Intermediate nodes		between encrypted and unencrypted packets. Intermediate nodes
	dealing with unknown flags are not necessarily able to parse the		dealing with unknown flags are not necessarily able to parse the
	packet correctly. Intermediate treatment of such packets is		packet correctly. Intermediate treatment of such packets is
	policy-dependent (e.g., it may dictate dropping such packets).		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 Flag bits sent, possibly by negotiating them over the		and/or the Flag bits sent, possibly by negotiating them over the
	control channel. The receiver MUST drop packets for which the		control channel.
	integrity check is invalid.
	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. The WESP header is integrity protected,		by the first 4 octets. The WESP header is integrity protected,
	along with all the fields specified for ESP in RFC 4303.		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
	skipping to change at page 12, line 21		skipping to change at page 13, line 21
	The USE_WESP_MODE notification number is assigned out of the		The USE_WESP_MODE notification number is assigned out of the
	"IKEv2 Notify Message Types - Status Types" registry's 16384-		"IKEv2 Notify Message Types - Status Types" registry's 16384-
	40959 (Expert Review) range: TBD.		40959 (Expert Review) range: TBD.
	This specification requests that IANA create a new registry for		This specification requests that IANA create a new registry for
	"WESP Flags" to be managed as follows:		"WESP Flags" to be managed as follows:
	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]. The final 6 bits of		IANA Policy of "Standards Action" [RFC5226]. The Encrypted
	the WESP Flags are the "Non-version Flags". This specification		Payload bit is used to indicate if the payload is encrypted or
	defines no values, and future assignment is to be managed via		using ESP-NULL. The remaining 5 bits of the WESP Flags are
	the IANA Policy of "Specification Required".		undefined 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.
	skipping to change at page 13, line 25		skipping to change at page 14, line 25
	[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		[RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing
	an IANA Considerations Section in RFCs", RFC 5226,		an IANA Considerations Section in RFCs", RFC 5226,
	May 2008.		May 2008.
			[Heuristics I-D] Kivinen, T., McDonald, D., "Heuristics for Detecting
			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
	Phone:		Phone:
	Email: ken.grewal@intel.com		Email: ken.grewal@intel.com
End of changes. 17 change blocks.
	39 lines changed or deleted		74 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/