draft-ietf-ipsecme-traffic-visibility-08.txt		draft-ietf-ipsecme-traffic-visibility-09.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: March 01, 2010 Microsoft Corporation		Expires: April 07, 2010 Microsoft Corporation
	M. Bhatia		M. Bhatia
	Alcatel-Lucent		Alcatel-Lucent
	September 01, 2009		October 07, 2009
	Wrapped ESP for Traffic Visibility		Wrapped ESP for Traffic Visibility
	draft-ietf-ipsecme-traffic-visibility-08.txt		draft-ietf-ipsecme-traffic-visibility-09.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 March 01, 2010.		This Internet-Draft will expire on April 07, 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
	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 Encapsulating		Payload (WESP) protocol, which builds on the Encapsulating
	Security Payload (ESP) [RFC4303] and is designed to allow		Security Payload (ESP) [RFC4303], and is designed to allow
	intermediate devices to ascertain if ESP-NULL [RFC2410] is being		intermediate devices to (1) ascertain if data confidentiality is
	employed and hence inspect the IPsec packets for network		being employed within ESP and if not, (2) inspect the IPsec
	monitoring and access control functions. Currently in the IPsec		packets for network monitoring and access control functions.
	standard, there is no way to differentiate between ESP		Currently in the IPsec ESP standard, there is no way to
	encryption and ESP NULL encryption by simply examining a packet.		differentiate between encrypted and unencrypted payloads by
	This poses certain challenges to the intermediate devices that		simply examining a packet. This poses certain challenges to the
	need to deep inspect the packet before making a decision on what		intermediate devices that need to deep inspect the packet before
	should be done with that packet (Inspect and/or Allow/Drop). The		making a decision on what should be done with that packet
	mechanism described in this document can be used to easily		(Inspect and/or Allow/Drop). The mechanism described in this
	disambiguate ESP-NULL from ESP encrypted packets, without		document can be used to easily disambiguate integrity-only ESP
	compromising on the security provided by ESP.		from ESP-encrypted packets, without 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.........................................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............................9
	2.2.2. Tunnel Mode Processing..............................10		2.2.2. Tunnel Mode Processing..............................10
	2.3. IKE Considerations.......................................11		2.3. IKE Considerations.......................................11
	3. Security Considerations.......................................12		3. Security Considerations.......................................12
	4. IANA Considerations...........................................13		4. IANA Considerations...........................................12
	5. Acknowledgments...............................................13		5. Acknowledgments...............................................13
	6. References....................................................13		6. References....................................................13
	6.1. Normative References.....................................13		6.1. Normative References.....................................13
	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 use		encapsulation is performed. It also specifies that ESP can
	NULL encryption while preserving data integrity and		provide data confidentiality and data integrity services. Data
	authenticity. The exact encapsulation and algorithms employed		integrity without data confidentiality ("integrity-only ESP") is
	are negotiated out-of-band using, for example, IKEv2 [RFC4306]		possible via the ESP-NULL encryption algorithm [RFC2410] or via
	and based on policy.		combined-mode algorithms such as AES-GMAC [RFC4543]. The exact
			encapsulation and algorithms employed are negotiated out-of-band
			using, for example, IKEv2 [RFC4306] 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,
	network tools and intermediate devices require visibility into		network tools and intermediate devices require visibility into
	packets, ranging from simple packet header inspection to deeper		packets, ranging from simple packet header inspection to deeper
	payload examination. Network security protocols which encrypt		payload examination. Network security protocols which encrypt
	the data in transit prevent these network tools from performing		the data in transit prevent these network tools from performing
	the aforementioned 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
	NULL. In a mixed mode environment some packets containing		integrity-only ESP. In a mixed-mode environment, some packets
	sensitive data employ a given encryption cipher suite, while		containing sensitive data employ a given encryption cipher
	other packets employ ESP-NULL. For an intermediate device to		suite, while other packets employ integrity-only ESP. For an
	unambiguously distinguish which packets are leveraging ESP-NULL,		intermediate device to unambiguously distinguish which packets
	they would require knowledge of all the policies being employed		are using integrity-only ESP requires knowledge of all the
	for each protected session. This is clearly not practical.		policies being employed for each protected session. This is
	Heuristic-based methods can be employed to parse the packets,		clearly not practical. Heuristics-based methods can be employed
	but these can be very expensive, containing numerous rules based		to parse the packets, but these can be very expensive, requiring
	on each different protocol and payload. Even then, the parsing		numerous rules based on each different protocol and payload.
	may not be robust in cases where fields within a given encrypted		Even then, the parsing may not be robust in cases where fields
	packet happen to resemble the fields for a given protocol or		within a given encrypted packet happen to resemble the fields
	heuristic rule. This is even more problematic when different		for a given protocol or heuristic rule. In cases where the
	length Initialization Vectors (IVs), Integrity Check Values
	(ICVs) and padding are used for different security associations,
	making it difficult to determine the start and end of the
	payload data, let alone attempting any further parsing.
	Furthermore, storage, lookup and cross-checking a set of
	comprehensive rules against every packet adds cost to hardware
	implementations and degrades performance. In cases where the
	packets may be encrypted, it is also wasteful to check against		packets may be encrypted, it is also wasteful to check against
	heuristics-based rules, when a simple exception policy (e.g.,		heuristics-based rules, when a simple exception policy (e.g.,
	allow, drop or redirect) can be employed to handle the encrypted		allow, drop or redirect) can be employed to handle the encrypted
	packets. Because of the non-deterministic nature of heuristics-		packets. Because of the non-deterministic nature of heuristics-
	based rules for disambiguating between encrypted and non-		based rules for disambiguating between encrypted and non-
	encrypted data, an alternative method for enabling intermediate		encrypted data, an alternative method for enabling intermediate
	devices to function in encrypted data environments needs to be		devices to function in encrypted data environments needs to be
	defined. Additionally there are many types and classes of		defined. Additionally there are many types and classes of
	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 provides a simple solution for all of
	these devices. Enterprise environments typically use both		them. Enterprise environments typically use both stateful and
	stateful and stateless packet inspection mechanisms. The		stateless packet inspection mechanisms. The previous
	previous considerations weigh particularly heavy on stateless		considerations weigh particularly heavy on stateless mechanisms
	mechanisms such as router ACLs and NetFlow exporters.		such as router ACLs and NetFlow exporters. Nevertheless, a
	Nevertheless, a deterministic approach provides a simple		deterministic approach provides a simple solution for the myriad
	solution for the myriad types of devices employed within a		types of devices employed within a network, regardless of their
	network, regardless of their stateful or stateless nature.		stateful or stateless nature.
	This document defines a mechanism to provide 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 and integrity-
	ESP packets with NULL encryption.		only packets. Additionally and in the interest of consistency,
			this extended format can also be used to carry encrypted packets
			without loss in disambiguation.
	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
	traffic		traffic
	o Leverage the existing hardware IPsec parsing engines as much		o Leverage the existing hardware IPsec parsing engines as much
	skipping to change at page 5, line 27		skipping to change at page 5, line 27
	endpoints are being modified to adopt WESP, we expect both		endpoints are being modified to adopt WESP, we expect both
	approaches to coexist for years, because the heuristic approach		approaches to coexist for years, because the heuristic approach
	is needed to inspect traffic where at least one of the endpoints		is needed to inspect traffic where at least one of the endpoints
	has not been modified. In other words, intermediate nodes are		has not been modified. In other words, intermediate nodes are
	expected to support both approaches in order to achieve good		expected to support both approaches in order to achieve good
	security and performance during the transition period.		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). Accordingly, the (outer) protocol header (IPv4, IPv6, or
	protocol header (IPv4, IPv6, or Extension) that immediately		Extension) that immediately precedes the WESP header SHALL
	precedes the WESP header SHALL contain the value (TBD via IANA)		contain the value (TBD via IANA) in its Protocol (IPv4) or Next
	in its Protocol (IPv4) or Next Header (IPv6, Extension) field.		Header (IPv6, Extension) field. WESP provides additional
	WESP provides additional attributes in each packet to assist in		attributes in each packet to assist in differentiating between
	differentiating between encrypted and non-encrypted data, and to		encrypted and non-encrypted data, and to aid parsing of the
	aid parsing of the packet. WESP follows RFC 4303 for all IPv6		packet. WESP follows RFC 4303 for all IPv6 and IPv4
	and IPv4 considerations (e.g., alignment considerations).		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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 |V|V|E| Flags |		| Next Header | HdrLen | TrailerLen | Flags |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv6Padding (optional) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Existing ESP Encapsulation |		| Existing ESP Encapsulation |
	~ ~		~ ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2 Detailed WESP Packet Format		Figure 2 Detailed WESP Packet Format
	Where:		Where:
	skipping to change at page 6, line 37		skipping to change at page 6, line 39
	only mode. When using ESP with encryption, the "Next Header"		only mode. When using ESP with encryption, the "Next Header"
	field looses this name and semantics and becomes an empty field		field looses this name and semantics and becomes an empty field
	which MUST be initialized to all zeros. The receiver MUST do		which MUST be initialized to all zeros. The receiver MUST do
	some sanity checks before the WESP packet is accepted. The		some sanity checks before the WESP packet is accepted. The
	receiver MUST ensure that the Next Header field in the WESP		receiver MUST ensure that the Next Header field in the WESP
	header and the Next Header field in the ESP trailer match when		header and the Next Header field in the ESP trailer match when
	using ESP in the Integrity only mode. The packet MUST be dropped		using ESP in the Integrity only mode. The packet MUST be dropped
	if the two do not match. Similarly, the receiver MUST ensure		if the two do not match. Similarly, the receiver MUST ensure
	that the Next Header field in the WESP header is an empty field		that the Next Header field in the WESP header is an empty field
	initialized to zero if using WESP with encryption. The WESP		initialized to zero if using WESP with encryption. The WESP
	flags dictate if the packet is encrypted and/or integrity		flags dictate if the packet is encrypted.
	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. HdrLen
	receiver MUST ensure that this field matches with the header		MUST be set to zero when using ESP with encryption. When using
	offset computed from using the negotiated SA and MUST drop the		integrity-only ESP, the following HdrLen values are invalid: any
	packet in case it doesn't match.		value less than 12; any value that is not a multiple of 4; any
			value that is not a multiple of 8 when using IPv6. 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 does not match.
	TrailerLen, 8 bits: Offset from the end of the packet to the		TrailerLen, 8 bits: TrailerLen contains the size of the ICV
	last byte of the payload data in octets. TrailerLen MUST be set		being used by the negotiated algorithms within the IPsec SA.
	to zero when using ESP with encryption. The receiver MUST only		TrailerLen MUST be set to zero when using ESP with encryption.
	accept the packet if this field matches with the value computed		The receiver MUST only accept the packet if this field matches
	from using the negotiated SA. This insures that sender is not		with the value computed from using the negotiated SA. This
	deliberately setting this value to obfuscate a part of the		insures that sender is not deliberately setting this value to
	payload from examination by a trusted intermediary device.		obfuscate a part of the payload from examination by a trusted
			intermediary device.
	Flags, 8 bits: The bits are defined LSB first, so bit 0 would be		Flags, 8 bits: The bits are defined most-significant-bit (MSB)
	the least significant bit of the flags octet.		first, so bit 0 is the most significant bit of the flags octet.
	2 bits: Version (V). MUST be sent as 0 and checked by the		0 1 2 3 4 5 6 7
			+-+-+-+-+-+-+-+-+
			|V V|E|X| Rsvd |
			+-+-+-+-+-+-+-+-+
			Figure 3 Flags format
			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
	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).
	1 bit: Encrypted Payload (E). 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 ESP-NULL cipher. Setting or clearing this bit		payload is using integrity-only ESP. Setting or clearing this
	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.
	5 bits: Flags, reserved for future use. The flags MUST be		Extended header (X), 1 bit: If set (value 1), the 4 octet padding
	sent as 0, and ignored by the receiver. Future documents		is present. If not set (value 0), the 4 octet padding is absent. This
	defining any of these flags MUST NOT affect the distinction		padding SHOULD be used with IPv6 in order to preserve IPv6 8-octet
			IPv6 alignment. This padding SHOULD 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
			MUST be sent as 0, and ignored by the receiver. Future documents
			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 flags are not necessarily able to parse the		dealing with unknown reserved bits are not necessarily able to
	packet correctly. Intermediate treatment of such packets is		parse the packet correctly. Intermediate treatment of such
	policy-dependent (e.g., it may dictate dropping such packets).		packets is 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 reserved bits sent, possibly by negotiating them over
	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. The WESP header is integrity protected,		by the first 4 octets for IPv4 and by 8 octets for IPv6. The
	along with all the fields specified for ESP in RFC 4303.		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, 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 3 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
	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.
	skipping to change at page 9, line 24		skipping to change at page 9, line 42
	Otherwise, the ICV computation is as specified by ESP [RFC4303].		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
	-------------------------------------------------		----------------------------
	|orig IP hdr | ESP | | | ESP | ESP|		|orig IP hdr | | |
	|(any options)| Hdr | TCP | Data | Trailer | ICV|		|(any options)| TCP | Data |
	-------------------------------------------------		----------------------------
	|<----encryption ----->|
	|<------- integrity -------->|
	AFTER APPLYING WESP - IPv4		AFTER APPLYING WESP - IPv4
	--------------------------------------------------------		--------------------------------------------------------
	|orig IP hdr | WESP | ESP | | | ESP |WESP|		|orig IP hdr | WESP | ESP | | | ESP |WESP|
	|(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV|		|(any options)| Hdr | Hdr | TCP | Data | Trailer | ICV|
	--------------------------------------------------------		--------------------------------------------------------
	|<---- encryption ---->|		|<---- encryption ---->|
	|<----------- integrity ----------->|		|<----------- integrity ----------->|
	BEFORE APPLYING WESP - IPv6		BEFORE APPLYING WESP - IPv6
	---------------------------------------------------------		----------------------------------------
	| orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|		| orig |hop-by-hop,dest*,|dest| | |
	|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|		|IP hdr|routing,fragment.|opt*|TCP|Data|
	---------------------------------------------------------		----------------------------------------
	|<---- encryption --->|
	|<------ integrity ------>|
	AFTER APPLYING WESP - IPv6		AFTER APPLYING WESP - IPv6
	--------------------------------------------------------------		--------------------------------------------------------------
	| orig |hop-by-hop,dest*,| | |dest| | | ESP |WESP|		| orig |hop-by-hop,dest*,| | |dest| | | ESP |WESP|
	|IP hdr|routing,fragment.|WESP|ESP|opt*|TCP|Data|Trailer| ICV|		|IP hdr|routing,fragment.|WESP|ESP|opt*|TCP|Data|Trailer| ICV|
	--------------------------------------------------------------		--------------------------------------------------------------
	|<---- encryption --->|		|<---- encryption --->|
	|<-------- integrity --------->|		|<-------- integrity --------->|
	* = if present, could be before WESP, after ESP, or both		* = if present, could be before WESP, after ESP, or both
	skipping to change at page 11, line 6		skipping to change at page 11, line 6
	All other considerations are as per RFC 4303.		All other considerations are as per RFC 4303.
	2.2.2. Tunnel Mode Processing		2.2.2. Tunnel Mode Processing
	In tunnel mode, ESP is inserted after the new IP header and before		In tunnel mode, ESP is inserted after the new IP header and before
	the original IP header, as per RFC 4303. The following diagram		the original IP header, as per RFC 4303. The following diagram
	illustrates how WESP is applied to the ESP tunnel mode for a typical		illustrates how WESP is applied to the ESP tunnel mode for a typical
	packet, on a "before and after" basis.		packet, on a "before and after" basis.
	BEFORE APPLYING WESP - IPv4		BEFORE APPLYING WESP - IPv4
	-----------------------------------------------------------		--------------------------
	| new IP hdr* | | orig IP hdr* | | | ESP | ESP|		| orig IP hdr* | | |
	|(any options)| ESP | (any options) |TCP|Data|Trailer| ICV|		| (any options) |TCP|Data|
	-----------------------------------------------------------		--------------------------
	|<--------- encryption --------->|
	|<------------- integrity ------------>|
	AFTER APPLYING WESP - IPv4		AFTER APPLYING WESP - IPv4
	--------------------------------------------------------------		--------------------------------------------------------------
	|new IP hdr* | | | orig IP hdr* | | | ESP |WESP|		|new IP hdr* | | | orig IP hdr* | | | ESP |WESP|
	|(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV|		|(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV|
	--------------------------------------------------------------		--------------------------------------------------------------
	|<--------- encryption --------->|		|<--------- encryption --------->|
	|<--------------- integrity ------------->|		|<--------------- integrity ------------->|
	BEFORE APPLYING WESP - IPv6		BEFORE APPLYING WESP - IPv6
	------------------------------------------------------------		---------------------------
	| new* |new ext | | orig*|orig ext | | | ESP | ESP|		| orig*|orig ext | | |
	|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|		|IP hdr| hdrs * |TCP|Data|
	------------------------------------------------------------		---------------------------
	|<--------- encryption ---------->|
	|<------------ integrity ------------>|
	AFTER APPLYING WESP - IPv6		AFTER APPLYING WESP - IPv6
	-----------------------------------------------------------------		-----------------------------------------------------------------
	| new* |new ext | | | orig*|orig ext | | | ESP |WESP|		| new* |new ext | | | orig*|orig ext | | | ESP |WESP|
	|IP hdr| hdrs* |WESP|ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|		|IP hdr| hdrs* |WESP|ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|
	-----------------------------------------------------------------		-----------------------------------------------------------------
	|<--------- encryption ---------->|		|<--------- encryption ---------->|
	|<--------------- integrity -------------->|		|<--------------- integrity -------------->|
	* = if present, construction of outer IP hdr/extensions and		* = if present, construction of outer IP hdr/extensions and
	skipping to change at page 12, line 49		skipping to change at page 12, line 44
	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 modify the WESP header so that		correct. It is thus possible to modify the WESP header so that
	the packet sneaks past a 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
	The WESP protocol number is assigned by IANA out of the IP		The WESP protocol number is assigned by IANA out of the IP
	Protocol Number space (and as recorded at the IANA web page at		Protocol Number space (and as recorded at the IANA web page at
	http://www.iana.org/assignments/protocol-numbers) is: TBD.		http://www.iana.org/assignments/protocol-numbers) is: TBD.
	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.
			The SPI value of 2 is assigned by IANA out of the reserved SPI
			range from the SPI values registry to indicate use of the WESP
			protocol within a UDP encapsulated, NAT-T environment.
	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 Encrypted		IANA Policy of "Standards Action" [RFC5226]. For WESP version
			numbers, the unassigned values are 1, 2 and 3. The Encrypted
	Payload bit is used to indicate if the payload is encrypted or		Payload bit is used to indicate if the payload is encrypted or
	using ESP-NULL. The remaining 5 bits of the WESP Flags are		using integrity-only ESP. The extended header bit is used to
	undefined and future assignment is to be managed via the IANA		signal the use of padding required to preserve IPv6 alignment.
	Policy of "Specification Required".		The remaining 4 bits of the WESP Flags are 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.
	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
	[RFC2410] Glenn, R. and S. Kent, "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.
			[RFC4543] McGrew, D. and Viega J., "The Use of Galois Message
			Authentication Code (GMAC) in IPsec ESP and AH", RFC
			4543, May 2006.
	[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.
	[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. 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,
	skipping to change at page 14, line 28		skipping to change at page 14, line 31
	[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		[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
	Phone:		Phone:
	Email: ken.grewal@intel.com		Email: ken.grewal@intel.com
	Gabriel Montenegro		Gabriel Montenegro
End of changes. 41 change blocks.
	130 lines changed or deleted		154 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/