draft-ietf-ipsecme-traffic-visibility-12.txt		rfc5840.txt
	Network Working Group K. Grewal
	Internet Draft Intel Corporation
	Intended status: Standards Track G. Montenegro
	Expires: July 19, 2010 Microsoft Corporation
	M. Bhatia
	Alcatel-Lucent
	January 20, 2010
	Wrapped ESP for Traffic Visibility		Internet Engineering Task Force (IETF) K. Grewal
	draft-ietf-ipsecme-traffic-visibility-12.txt		Request for Comments: 5840 Intel Corporation
			Category: Standards Track G. Montenegro
			ISSN: 2070-1721 Microsoft Corporation
			M. Bhatia
			Alcatel-Lucent
			April 2010
	Status of this Memo		Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility
	This Internet-Draft is submitted to IETF in full conformance		Abstract
	with the provisions of BCP 78 and BCP 79. This document may
	contain material from IETF Documents or IETF Contributions
	published or made publicly available before November 10, 2008.
	The person(s) controlling the copyright in some of this material
	may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards
	Process. Without obtaining an adequate license from the
	person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process,
	and derivative works of it may not be created outside the IETF
	Standards Process, except to format it for publication as an RFC
	or to translate it into languages other than English.
	Internet-Drafts are working documents of the Internet		This document describes the Wrapped Encapsulating Security Payload
	Engineering Task Force (IETF), its areas, and its working		(WESP) protocol, which builds on the Encapsulating Security Payload
	groups. Note that other groups may also distribute working		(ESP) RFC 4303 and is designed to allow intermediate devices to (1)
	documents as Internet-Drafts.		ascertain if data confidentiality is being employed within ESP, and
			if not, (2) inspect the IPsec packets for network monitoring and
			access control functions. Currently, in the IPsec ESP standard,
			there is no deterministic way to differentiate between encrypted and
			unencrypted payloads by simply examining a packet. This poses
			certain challenges to the intermediate devices that need to deep
			inspect the packet before making a decision on what should be done
			with that packet (Inspect and/or Allow/Drop). The mechanism
			described in this document can be used to easily disambiguate
			integrity-only ESP from ESP-encrypted packets, without compromising
			on the security provided by ESP.
	Internet-Drafts are draft documents valid for a maximum of six		Status of This Memo
	months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as "work
	in progress."
	The list of current Internet-Drafts can be accessed at		This is an Internet Standards Track document.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		This document is a product of the Internet Engineering Task Force
	http://www.ietf.org/shadow.html.		(IETF). It represents the consensus of the IETF community. It has
			received public review and has been approved for publication by the
			Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on July 19, 2010.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc5840.
	Copyright		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with		carefully, as they describe your rights and restrictions with respect
	respect to this document. Code Components extracted from this		to this document. Code Components extracted from this document must
	document must include Simplified BSD License text as described		include Simplified BSD License text as described in Section 4.e of
	in Section 4.e of the Trust Legal Provisions and are provided		the Trust Legal Provisions and are provided without warranty as
	without warranty as described in the Simplified BSD License.		described in the Simplified BSD License.
	Abstract
	This document describes the Wrapped Encapsulating Security		This document may contain material from IETF Documents or IETF
	Payload (WESP) protocol, which builds on the Encapsulating		Contributions published or made publicly available before November
	Security Payload (ESP) [RFC4303], and is designed to allow		10, 2008. The person(s) controlling the copyright in some of this
	intermediate devices to (1) ascertain if data confidentiality is		material may not have granted the IETF Trust the right to allow
	being employed within ESP and if not, (2) inspect the IPsec		modifications of such material outside the IETF Standards Process.
	packets for network monitoring and access control functions.		Without obtaining an adequate license from the person(s) controlling
	Currently in the IPsec ESP standard, there is no deterministic		the copyright in such materials, this document may not be modified
	way to differentiate between encrypted and unencrypted payloads		outside the IETF Standards Process, and derivative works of it may
	by simply examining a packet. This poses certain challenges to		not be created outside the IETF Standards Process, except to format
	the intermediate devices that need to deep inspect the packet		it for publication as an RFC or to translate it into languages other
	before making a decision on what should be done with that packet		than English.
	(Inspect and/or Allow/Drop). The mechanism described in this
	document can be used to easily disambiguate integrity-only 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.........................................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...........................10		2.2.1. Transport Mode Processing ...........................9
	2.2.2. Tunnel Mode Processing..............................11		2.2.2. Tunnel Mode Processing .............................10
	2.3. IKE Considerations.......................................12		2.3. IKE Considerations ........................................11
	3. Security Considerations.......................................12		3. Security Considerations ........................................12
	4. IANA Considerations...........................................13		4. IANA Considerations ............................................13
	5. Acknowledgments...............................................13		5. Acknowledgments ................................................13
	6. References....................................................14		6. References .....................................................14
	6.1. Normative References.....................................14		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
	provide data confidentiality and data integrity services. Data		data confidentiality and data integrity services. Data integrity
	integrity without data confidentiality ("integrity-only ESP") is		without data confidentiality ("integrity-only ESP") is possible via
	possible via the ESP-NULL encryption algorithm [RFC2410] or via		the ESP-NULL encryption algorithm [RFC2410] or via combined-mode
	combined-mode algorithms such as AES-GMAC [RFC4543]. The exact		algorithms such as AES-GMAC [RFC4543]. The exact encapsulation and
	encapsulation and algorithms employed are negotiated out-of-band		algorithms employed are negotiated out of band using, for example,
	using, for example, IKEv2 [RFC4306] and based on policy.		Internet Key Exchange Protocol version 2 (IKEv2) [RFC4306] and based
			on policy.
	Enterprise environments typically employ numerous security		Enterprise environments typically employ numerous security policies
	policies (and tools for enforcing them), as related to access		(and tools for enforcing them), as related to access control, content
	control, content screening, firewalls, network monitoring		screening, firewalls, network monitoring functions, deep packet
	functions, deep packet inspection, Intrusion Detection and		inspection, Intrusion Detection and Prevention Systems (IDS and IPS),
	Prevention Systems (IDS and IPS), scanning and detection of		scanning and detection of viruses and worms, etc. In order to
	viruses and worms, etc. In order to enforce these policies,		enforce these policies, network tools and intermediate devices
	network tools and intermediate devices require visibility into		require visibility into packets, ranging from simple packet header
	packets, ranging from simple packet header inspection to deeper		inspection to deeper payload examination. Network security protocols
	payload examination. Network security protocols which encrypt		that encrypt the data in transit prevent these network tools from
	the data in transit prevent these network tools from performing		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 Authentication Header (AH)
	work in NAT environments. Furthermore, in order to preserve the		[RFC4302], as AH does not work in NAT environments. Furthermore, in
	above network monitoring functions, it is desirable to use		order to preserve the above network monitoring functions, it is
	integrity-only ESP. In a mixed-mode environment, some packets		desirable to use integrity-only ESP. In a mixed-mode environment,
	containing sensitive data employ a given encryption cipher		some packets containing sensitive data employ a given encryption
	suite, while other packets employ integrity-only ESP. For an		cipher suite, while other packets employ integrity-only ESP. For an
	intermediate device to unambiguously distinguish which packets		intermediate device to unambiguously distinguish which packets are
	are using integrity-only ESP requires knowledge of all the		using integrity-only ESP requires knowledge of all the policies being
	policies being employed for each protected session. This is		employed for each protected session. This is clearly not practical.
	clearly not practical. Heuristics-based methods can be employed		Heuristics-based methods can be employed to parse the packets, but
	to parse the packets, but these can be very expensive, requiring		these can be very expensive, requiring numerous rules based on each
	numerous rules based on each different protocol and payload.		different protocol and payload. Even then, the parsing may not be
	Even then, the parsing may not be robust in cases where fields		robust in cases where fields within a given encrypted packet happen
	within a given encrypted packet happen to resemble the fields		to resemble the fields for a given protocol or heuristic rule. In
	for a given protocol or heuristic rule. In cases where the		cases where the packets may be encrypted, it is also wasteful to
	packets may be encrypted, it is also wasteful to check against		check against heuristics-based rules, when a simple exception policy
	heuristics-based rules, when a simple exception policy (e.g.,		(e.g., allow, drop, or redirect) can be employed to handle the
	allow, drop or redirect) can be employed to handle the encrypted		encrypted packets. Because of the non-deterministic nature of
	packets. Because of the non-deterministic nature of heuristics-		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
	network devices employed within a given network and a		devices employed within a given network and a deterministic approach
	deterministic approach provides a simple solution for all of		provides a simple solution for all of them. Enterprise environments
	them. Enterprise environments typically use both stateful and		typically use both stateful and stateless packet inspection
	stateless packet inspection mechanisms. The previous		mechanisms. The previous considerations weigh particularly heavy on
	considerations weigh particularly heavy on stateless mechanisms		stateless mechanisms such as router Access Control Lists (ACLs) and
	such as router ACLs and NetFlow exporters. Nevertheless, a		NetFlow exporters. Nevertheless, a deterministic approach provides a
	deterministic approach provides a simple solution for the myriad		simple 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
	information in relevant IPsec packets so intermediate devices		in relevant IPsec packets so intermediate devices can efficiently
	can efficiently differentiate between encrypted and integrity-		differentiate between encrypted and integrity-only packets.
	only packets. Additionally and in the interest of consistency,		Additionally, and in the interest of consistency, this extended
	this extended format can also be used to carry encrypted packets		format can also be used to carry encrypted packets without loss in
	without loss in disambiguation.		disambiguation.
	The document is consistent with the operation of ESP in NAT		This 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 as
	as possible to minimize additional hardware design costs		possible to minimize additional hardware design costs
	o Minimize the packet overhead in the common case		o Minimize the packet overhead in the common case
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	"OPTIONAL" in this document are to be interpreted as described		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
	defined below, and does not describe any changes to either ESP		below, and does not describe any changes to either ESP [RFC4303] or
	[RFC4303] nor IP Authentication Header (AH) [RFC4302].		the IP Authentication Header (AH) [RFC4302].
	There are two well accepted ways to enable intermediate security		There are two well-accepted ways to enable intermediate security
	devices to distinguish between encrypted and unencrypted ESP		devices to distinguish between encrypted and unencrypted ESP traffic:
	traffic:
	- The heuristics approach [Heuristics I-D] has the intermediate		- The heuristics approach [Heuristics] has the intermediate node
	node inspect the unchanged ESP traffic, to determine with		inspect the unchanged ESP traffic, to determine with extremely high
	extremely high probability whether or not the traffic stream is		probability whether or not the traffic stream is encrypted.
	encrypted.
	- The Wrapped ESP (WESP) approach described in this document, in		- The Wrapped ESP (WESP) approach, described in this document, in
	contrast, requires the ESP endpoints to be modified to support		contrast, requires the ESP endpoints to be modified to support the
	the new protocol. WESP allows the intermediate node to		new protocol. WESP allows the intermediate node to distinguish
	distinguish encrypted and unencrypted traffic deterministically,		encrypted and unencrypted traffic deterministically, using a
	using a simpler implementation for the intermediate node.		simpler implementation for the intermediate node.
	Both approaches are being documented simultaneously by the IP		Both approaches are being documented simultaneously by the IP
	Security Maintenance and Extensions (IPsecME) Working Group,		Security Maintenance and Extensions (IPsecME) Working Group, with
	with WESP being put on Standards Track while the heuristics		WESP (this document) as a Standards Track RFC while the heuristics
	approach is being published as an Informational RFC. While		approach is expected to be published as an Informational RFC. While
	endpoints are being modified to adopt WESP, we expect both		endpoints are being modified to adopt WESP, we expect both approaches
	approaches to coexist for years, because the heuristic approach		to coexist for years because the heuristic approach is needed to
	is needed to inspect traffic where at least one of the endpoints		inspect traffic where at least one of the endpoints has not been
	has not been modified. In other words, intermediate nodes are		modified. In other words, intermediate nodes are expected to support
	expected to support both approaches in order to achieve good		both approaches in order to achieve good security and performance
	security and performance during the transition period.		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 (WESP) encapsulation uses protocol number 141.
	IANA). Accordingly, the (outer) protocol header (IPv4, IPv6, or		Accordingly, the (outer) protocol header (IPv4, IPv6, or Extension)
	Extension) that immediately precedes the WESP header SHALL		that immediately precedes the WESP header SHALL contain the value
	contain the value (TBD via IANA) in its Protocol (IPv4) or Next		(141) 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 aid
	encrypted and non-encrypted data, and to aid parsing of the		in parsing of the packet. WESP follows RFC 4303 for all IPv6 and
	packet. WESP follows RFC 4303 for all IPv6 and IPv4		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 for IPv4. For IPv6, additional padding may		existing ESP packet for IPv4. For IPv6, additional padding may be
	be required and this is described below.		required and this is described below.
	The packet format may be depicted as follows:		The packet format 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
	compliant implementation can simply add in the new header,		implementation can simply add in the new header, without needing to
	without needing to change the body of the packet. The value of		change the body of the packet. The value of the new protocol used to
	the new protocol used to identify this new header is TBD via		identify this new header is 141. 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 | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Padding (optional) |		| Padding (optional) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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
	Header field in the ESP trailer when using ESP in the Integrity		field in the ESP trailer when using ESP in the Integrity-only mode.
	only mode. When using ESP with encryption, the "Next Header"		When using ESP with encryption, the "Next Header" field looses this
	field looses this name and semantics and becomes an empty field		name and semantics and becomes an empty field that MUST be
	which MUST be initialized to all zeros. The receiver MUST do		initialized to all zeros. The receiver MUST do some sanity checks
	some sanity checks before the WESP packet is accepted. The		before the WESP packet is accepted. The receiver MUST ensure that
	receiver MUST ensure that the Next Header field in the WESP		the Next Header field in the WESP header and the Next Header field in
	header and the Next Header field in the ESP trailer match when		the ESP trailer match when using ESP in the Integrity-only mode. The
	using ESP in the Integrity only mode. The packet MUST be dropped		packet MUST be dropped if the two do not match. Similarly, the
	if the two do not match. Similarly, the receiver MUST ensure		receiver MUST ensure that the Next Header field in the WESP header is
	that the Next Header field in the WESP header is an empty field		an empty field initialized to zero if using WESP with encryption.
	initialized to zero if using WESP with encryption. The WESP		The WESP flags dictate if the packet is encrypted.
	flags dictate if the packet is encrypted.
	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
	the beginning of the Rest of Payload Data (i.e., past the IV, if		beginning of the Rest of Payload Data (i.e., past the IV, if present
	present and any other WESP options defined in future) within the		and any other WESP options defined in the future) within the
	encapsulated ESP header, in octets. HdrLen MUST be set to zero		encapsulated ESP header, in octets. HdrLen MUST be set to zero when
	when using ESP with encryption. When using integrity-only ESP,		using ESP with encryption. When using integrity-only ESP, the
	the following HdrLen values are invalid: any value less than 12;		following HdrLen values are invalid: any value less than 12; any
	any value that is not a multiple of 4; any value that is not a		value that is not a multiple of 4; any value that is not a multiple
	multiple of 8 when using IPv6. The receiver MUST ensure that		of 8 when using IPv6. The receiver MUST ensure that this field
	this field matches with the header offset computed from using		matches with the header offset computed from using the negotiated
	the negotiated SA and MUST drop the packet in case it does not		Security Association (SA) and MUST drop the packet in case it does
	match.		not match.
	TrailerLen, 8 bits: TrailerLen contains the size of the ICV		TrailerLen, 8 bits: TrailerLen contains the size of the Integrity
	being used by the negotiated algorithms within the IPsec SA, in		Check Value (ICV) being used by the negotiated algorithms within the
	octets. TrailerLen MUST be set to zero when using ESP with		IPsec SA, in octets. TrailerLen MUST be set to zero when using ESP
	encryption. The receiver MUST only accept the packet if this		with encryption. The receiver MUST only accept the packet if this
	field matches with the value computed from using the negotiated		field matches with the value computed from using the negotiated SA.
	SA. This insures that sender is not deliberately setting this		This ensures that sender is not deliberately setting this value to
	value to obfuscate a part of the payload from examination by a		obfuscate a part of the payload from examination by a trusted
	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,
	first, so bit 0 is the most significant bit of the flags octet.		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|P| 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.
	receiver. If the version is different than an expected version		If the version is different than an expected version number (e.g.,
	number (e.g. negotiated via the control channel), then the		negotiated via the control channel), then the packet MUST be dropped
	packet MUST be dropped by the receiver. Future modifications to		by the receiver. Future modifications to the WESP header require a
	the WESP header require a new version number. In particular, the		new version number. In particular, the version of WESP defined in
	version of WESP defined in this document does not allow for any		this document does not allow for any extensions. However, old
	extensions. However, old implementations will still be able to		implementations will still be able to find the encapsulated cleartext
	find the encapsulated cleartext packet using the HdrLen field		packet using the HdrLen field from the WESP header, when the 'E' bit
	from the WESP header, when the 'E' bit is not set. Intermediate		is not set. Intermediate nodes dealing with unknown versions are not
	nodes dealing with unknown versions are not necessarily able to		necessarily able to parse the packet correctly. Intermediate
	parse the packet correctly. Intermediate treatment of such		treatment of such packets is policy dependent (e.g., it may dictate
	packets is policy-dependent (e.g., it may dictate dropping such		dropping such packets).
	packets).
	Encrypted Payload (E), 1 bit: Setting the Encrypted Payload		Encrypted Payload (E), 1 bit: Setting the Encrypted Payload bit to 1
	bit to 1 indicates that the WESP (and therefore ESP) payload is		indicates that the WESP (and therefore ESP) payload is protected with
	protected with encryption. If this bit is set to 0, then the		encryption. If this bit is set to 0, then the payload is using
	payload is using integrity-only ESP. Setting or clearing this		integrity-only ESP. Setting or clearing this bit also impacts the
	bit also impacts the value in the WESP Next Header field, as		value in the WESP Next Header field, as described above. The
	described above. The recipient MUST ensure consistency of this		recipient MUST ensure consistency of this flag with the negotiated
	flag with the negotiated policy and MUST drop the incoming		policy and MUST drop the incoming packet otherwise.
	packet otherwise.
	Padding header (P), 1 bit: If set (value 1), the 4 octet		Padding header (P), 1 bit: If set (value 1), the 4-octet padding is
	padding is present. If not set (value 0), the 4 octet padding		present. If not set (value 0), the 4-octet padding is absent. This
	is absent. This padding MUST be used with IPv6 in order to		padding MUST be used with IPv6 in order to preserve IPv6 8-octet
	preserve IPv6 8-octet alignment. If WESP is being used with UDP		alignment. If WESP is being used with UDP encapsulation (see Section
	encapsulation (see 2.1 below) and IPv6, the Protocol Identifier		2.1 below) and IPv6, the Protocol Identifier (0x00000002) occupies 4
	(0x00000002) occupies four octets so the IPv6 padding is not		octets so the IPv6 padding is not needed, as the header is already on
	needed, as the header is already on an 8-octet boundary. This		an 8-octet boundary. This padding MUST NOT be used with IPv4, as it
	padding MUST NOT be used with IPv4, as it is not needed to		is not needed to guarantee 4-octet IPv4 alignment.
	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
	MUST be sent as 0, and ignored by the receiver. Future documents		sent as 0, and ignored by the receiver. Future documents defining
	defining any of these bits MUST NOT affect the distinction		any of these bits MUST NOT affect the distinction between encrypted
	between encrypted and unencrypted packets or the semantics of		and unencrypted packets or the semantics of HdrLen. In other words,
	HdrLen. In other words, even if new bits are defined, old		even if new bits are defined, old implementations will be able to
	implementations will be able to find the encapsulated packet		find the encapsulated packet correctly. Intermediate nodes dealing
	correctly. Intermediate nodes dealing with unknown reserved bits		with unknown reserved bits are not necessarily able to parse the
	are not necessarily able to parse the packet correctly.		packet correctly. Intermediate treatment of such packets is policy
	Intermediate treatment of such packets is policy-dependent		dependent (e.g., it may dictate dropping such packets).
	(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
	and/or the reserved bits sent, possibly by negotiating them over		the reserved bits sent, possibly by negotiating them over the control
	the control channel.		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
	by the first 4 octets for IPv4 and optionally (see above) by 8		the first 4 octets for IPv4 and optionally (see above) by 8 octets
	octets for IPv6.		for IPv6.
	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
	format over the existing UDP encapsulation of ESP as defined in		over the existing UDP encapsulation of ESP as defined in RFC 3948.
	RFC 3948. This allows leveraging the existing IKE negotiation of		This allows leveraging the existing IKE negotiation of the UDP port
	the UDP port for NAT-T discovery and usage [RFC3947, RFC4306],		for Network Address Translation Traversal (NAT-T) discovery and usage
	as well as preserving the existing UDP ports for ESP (port		[RFC3947] [RFC4306], as well as preserving the existing UDP ports for
	4500). With UDP encapsulation, the packet format can be		ESP (port 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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 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
	encapsulation header, per RFC3948.		encapsulation header, per RFC 3948.
	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
	the UDP encapsulation in this specification.		UDP encapsulation in this specification.
	According to RFC 3948, clause 2.2, a 4 octet value of zero (0)		According to RFC 3948, Section 2.2, a 4-octet value of zero (0)
	immediately following the UDP header indicates a Non-ESP marker,		immediately following the UDP header indicates a Non-ESP marker,
	which can be used to assume that the data following that value		which can be used to assume that the data following that value is an
	is an IKE packet. Similarly, a value greater then 255 indicates		IKE packet. Similarly, a value greater then 255 indicates that the
	that the packet is an ESP packet and the 4-octet value can be		packet is an ESP packet and the 4-octet value can be treated as the
	treated as the ESP SPI. However, RFC 4303, clause 2.1 indicates		ESP Security Parameter Index (SPI). However, RFC 4303, Section 2.1
	that the values 1-255 are reserved and cannot be used as the		indicates that the values 1-255 are reserved and cannot be used as
	SPI. We leverage that knowledge and use one of these reserved		the SPI. We leverage that knowledge and use one of these reserved
	values to indicate that the UDP encapsulated ESP header contains		values to indicate that the UDP encapsulated ESP header contains this
	this new packet format for ESP encapsulation.		new packet format for ESP encapsulation.
	The remaining fields in the packet have the same meaning as per		The remaining fields in the packet have the same meaning as per
	section 2 above.		Section 2 above.
	2.2. Transport and Tunnel Mode Considerations		2.2. Transport and Tunnel Mode Considerations
	This extension is equally applicable to transport and tunnel mode		This extension is equally applicable to transport and tunnel mode
	where the ESP Next Header field is used to differentiate between		where the ESP Next Header field is used to differentiate between
	these modes, as per the existing IPsec specifications.		these modes, as per the existing IPsec specifications.
	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 | ESP | | | ESP | ESP|
	|(any options)| Hdr | TCP | Data | Trailer | ICV|		|(any options)| Hdr | TCP | Data | Trailer | ICV|
	-------------------------------------------------		-------------------------------------------------
	|<---- encryption ---->|		|<---- encryption ---->|
	|<------- integrity -------->|		|<------- integrity -------->|
	AFTER APPLYING WESP - IPv4		AFTER APPLYING WESP - IPv4
	--------------------------------------------------------		--------------------------------------------------------
	|orig IP hdr | WESP | ESP | | | ESP | ESP|		|orig IP hdr | WESP | ESP | | | ESP | ESP|
	|(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| | | ESP | ESP|
	|IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|		|IP hdr|routing,fragment |ESP|opt*|TCP|Data|Trailer| ICV|
	--------------------------------------------------------------		--------------------------------------------------------------
	|<---- encryption --->|		|<---- encryption --->|
	|<----- integrity ------->|		|<----- integrity ------->|
	AFTER APPLYING WESP - IPv6		AFTER APPLYING WESP - IPv6
	--------------------------------------------------------------		--------------------------------------------------------------
	| orig |hop-by-hop,dest*,| | |dest| | | ESP | ESP|		| orig |hop-by-hop,dest*,| | |dest| | | ESP | ESP|
	|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
	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
	---------------------------------------------------------
	|new IP hdr* | | orig IP hdr* | | | ESP | ESP|
	|(any options)|ESP| (any options) |TCP|Data|Trailer| ICV|
	---------------------------------------------------------
	|<--------- encryption --------->|
	|<----------- integrity ------------>|
	AFTER APPLYING WESP - IPv4
	--------------------------------------------------------------
	|new IP hdr* | | | orig IP hdr* | | | ESP | ESP|
	|(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV|
	--------------------------------------------------------------
	|<--------- encryption --------->|
	|<----------- integrity ------------>|
	BEFORE APPLYING WESP - IPv6		BEFORE APPLYING WESP - IPv4
	-----------------------------------------------------------------		---------------------------------------------------------
	| new* |new ext | | orig*|orig ext | | | ESP | ESP|		|new IP hdr* | | orig IP hdr* | | | ESP | ESP|
	|IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|		|(any options)|ESP| (any options) |TCP|Data|Trailer| ICV|
	-----------------------------------------------------------------		---------------------------------------------------------
	|<--------- encryption ---------->|		|<--------- encryption --------->|
	|<------------- integrity ----------->|		|<----------- integrity ------------>|
	AFTER APPLYING WESP - IPv6		AFTER APPLYING WESP - IPv4
	-----------------------------------------------------------------		--------------------------------------------------------------
	| new* |new ext | | | orig*|orig ext | | | ESP | ESP|		|new IP hdr* | | | orig IP hdr* | | | ESP | ESP|
	|IP hdr| hdrs* |WESP|ESP|IP hdr| hdrs * |TCP|Data|Trailer| ICV|		|(any options)|WESP|ESP| (any options) |TCP|Data|Trailer| ICV|
	-----------------------------------------------------------------		--------------------------------------------------------------
	|<--------- encryption ---------->|		|<--------- encryption --------->|
	|<------------- integrity ----------->|		|<----------- integrity ------------>|
	* = if present, construction of outer IP hdr/extensions and		BEFORE APPLYING WESP - IPv6
			-----------------------------------------------------------------
			|new IP|new ext | |orig IP|orig ext| | | ESP | ESP|
			| hdr* | hdrs* |ESP| hdr* | hdrs * |TCP|Data|Trailer| ICV|
			-----------------------------------------------------------------
			|<--------- encryption ---------->|
			|<------------- integrity ----------->|
	modification of inner IP hdr/extensions is discussed in		AFTER APPLYING WESP - IPv6
			-----------------------------------------------------------------
			|new IP|new ext | | |orig IP|orig ext| | | ESP | ESP|
			| hdr* | hdrs* |WESP|ESP| hdr* | hdrs * |TCP|Data|Trailer| ICV|
			-----------------------------------------------------------------
			|<--------- encryption ---------->|
			|<------------- integrity ----------->|
	the Security Architecture document.		* = if present, construction of outer IP hdr/extensions and
			modification of inner IP hdr/extensions is discussed in
			the Security Architecture document.
	All other considerations are as per RFC 4303.		All other considerations are as per RFC 4303.
	2.3. IKE Considerations		2.3. IKE Considerations
	This document assumes that WESP negotiation is performed using		This document assumes that WESP negotiation is performed using IKEv2.
	IKEv2. In order to negotiate the new format of ESP encapsulation		In order to negotiate the new format of ESP encapsulation via IKEv2
	via IKEv2 [RFC4306], both parties need to agree to use the new		[RFC4306], both parties need to agree to use the new packet format.
	packet format. This can be achieved using a notification method		This can be achieved using a notification method similar to
	similar to USE_TRANSPORT_MODE defined in RFC 4306.		USE_TRANSPORT_MODE, defined in RFC 4306.
	The notification, USE_WESP_MODE (value TBD) MUST be included in		The notification, USE_WESP_MODE (value 16415) MUST be included in a
	a request message that also includes an SA payload requesting a		request message that also includes an SA payload requesting a
	CHILD_SA using ESP. It signals that the sender supports the		CHILD_SA using ESP. It signals that the sender supports the WESP
	WESP version defined in the current document a requests that the		version defined in the current document and requests that the
	CHILD_SA use WESP mode rather than ESP for the SA created. If		CHILD_SA use WESP mode rather than ESP for the SA created. If the
	the request is accepted, the response MUST also include a		request is accepted, the response MUST also include a notification of
	notification of type USE_WESP_MODE. If the responder declines		type USE_WESP_MODE. If the responder declines the request, the
	the request, the CHILD_SA will be established using ESP, as per		CHILD_SA will be established using ESP, as per RFC 4303. If this is
	RFC 4303. If this is unacceptable to the initiator, the		unacceptable to the initiator, the initiator MUST delete the SA.
	initiator MUST delete the SA. Note: Except when using this
	option to negotiate WESP mode, all CHILD_SAs will use standard
	ESP.
	Negotiation of WESP in this manner preserves all other		Note: Except when using this option to negotiate WESP mode, all
	negotiation parameters, including NAT-T [RFC3948]. NAT-T is		CHILD_SAs will use standard ESP.
	wholly compatible with this wrapped frame format and can be used
	as-is, without any modifications, in environments where NAT is		Negotiation of WESP in this manner preserves all other negotiation
	present and needs to be taken into account.		parameters, including NAT-T [RFC3948]. NAT-T is wholly compatible
			with this wrapped format and can be used as-is, without any
			modifications, in environments where NAT is present and needs to be
			taken into account.
	WESP version negotiation is not introduced as part of this		WESP version negotiation is not introduced as part of this
	specification. If the WESP version is updated in a future		specification. If the WESP version is updated in a future
	specification, then that document MUST specify how the WESP		specification, then that document MUST specify how the WESP version
	version is negotiated.		is negotiated.
	3. Security Considerations		3. Security Considerations
	As this document augments the existing ESP encapsulation format,		As this document augments the existing ESP encapsulation format, UDP
	UDP encapsulation definitions specified in RFC 3948 and IKE		encapsulation definitions specified in RFC 3948 and IKE negotiation
	negotiation of the new encapsulation, the security observations		of the new encapsulation, the security observations made in those
	made in those documents also apply here. In addition, as this		documents also apply here. In addition, as this document allows
	document allows intermediate device visibility into IPsec ESP		intermediate device visibility into IPsec ESP encapsulated frames for
	encapsulated frames for the purposes of network monitoring		the purposes of network monitoring functions, care should be taken
	functions, care should be taken not to send sensitive data over		not to send sensitive data over connections using definitions from
	connections using definitions from this document, based on		this document, based on network domain/administrative policy. A
	network domain/administrative policy. A strong key agreement		strong key agreement protocol, such as IKEv2, together with a strong
	protocol, such as IKEv2, together with a strong policy engine		policy engine should be used in determining appropriate security
	should be used in determining appropriate security policy for		policy for the given traffic streams and data over which it is being
	the given traffic streams and data over which it is being
	employed.		employed.
	ESP is end-to-end and it will be impossible for the intermediate		ESP is end-to-end and it will be impossible for the intermediate
	devices to verify that all the fields in the WESP header are		devices to verify that all the fields in the WESP header are correct.
	correct. It is thus possible to modify the WESP header so that		It is thus possible to modify the WESP header so that the packet
	the packet sneaks past a firewall if the fields in the WESP		sneaks past a firewall if the fields in the WESP header are set to
	header are set to something that the firewall will allow. The		something that the firewall will allow. The endpoint thus must
	endpoint thus must verify the sanity of the WESP header before		verify the sanity of the WESP header before accepting the packet. In
	accepting the packet. In an extreme case, someone colluding with		an extreme case, someone colluding with the attacker, could change
	the attacker, could change the WESP fields back to the original		the WESP fields back to the original values so that the attack goes
	values so that the attack goes unnoticed. However, this is not a		unnoticed. However, this is not a new problem and it already exists
	new problem and it already exists IPsec.		IPsec.
	4. IANA Considerations		4. IANA Considerations
	The WESP protocol number is assigned by IANA out of the IP		The WESP protocol number assigned by IANA out of the IP Protocol
	Protocol Number space (and as recorded at the IANA web page at		Number space is 141.
	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 assigned out of the "IKEv2
	"IKEv2 Notify Message Types - Status Types" registry's 16384-		Notify Message Types - Status Types" registry's 16384-40959 (Expert
	40959 (Expert Review) range: TBD.		Review) range is 16415.
	The SPI value of 2 is assigned by IANA out of the reserved SPI		The SPI value of 2 has been assigned by IANA out of the reserved SPI
	range from the SPI values registry to indicate use of the WESP		range from the SPI values registry to indicate use of the WESP
	protocol within a UDP encapsulated, NAT-T environment.		protocol within a UDP-encapsulated, NAT-T environment.
	This specification requests that IANA create a new registry for		IANA has created a new registry for "WESP Flags" to be managed as
	"WESP Flags" to be managed as follows:		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
	IANA Policy of "Standards Action" [RFC5226]. For WESP version		Policy of "Standards Action" [RFC5226]. For WESP version numbers,
	numbers, the unassigned values are 1, 2 and 3. The Encrypted		the unassigned values are 1, 2, and 3. The Encrypted Payload bit is
	Payload bit is used to indicate if the payload is encrypted or		used to indicate if the payload is encrypted or using integrity-only
	using integrity-only ESP. The Padding Present bit is used to		ESP. The Padding Present bit is used to signal the presence of
	signal the presence of padding. The remaining 4 bits of the WESP		padding. The remaining 4 bits of the WESP Flags are undefined and
	Flags are undefined and future assignment is to be managed via		future assignment is to be managed via the IANA Policy of "IETF
	the IANA Policy of "IETF Review" [RFC5226].		Review" [RFC5226].
	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
	their feedback on updating the definitions in this document.		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, Pasi Eronen, Men Long, David Durham, Prashant Dewan,		Sheffer, Pasi Eronen, Men Long, David Durham, Prashant Dewan, Marc
	Marc Millier, Russ Housley, Jari Arkko among others.		Millier, Russ Housley, and Jari Arkko, among others.
	This document was prepared using 2-Word-v2.0.template.doc.		Manav Bhatia would also like to acknowledge Swati and Maitri for
			their continued support.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[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.
	[RFC2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm		[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm
	and Its Use With IPsec", RFC 2410, November 1998.		and Its Use With IPsec", RFC 2410, November 1998.
	[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and		[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
	M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",		M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
	RFC 3948, January 2005.		RFC 3948, January 2005.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
	RFC 4303, December 2005.		4303, December 2005.
	[RFC4543] McGrew, D. and Viega J., "The Use of Galois Message		[RFC4543] McGrew, D. and J. Viega, "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.
	[RFC5226] Narten, T., Alverstrand, H., "Guidelines for Writing		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	an IANA Considerations Section in RFCs", RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	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.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
	December 2005.		2005.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
	RFC 4306, December 2005.		Protocol", RFC 4306, December 2005.
	[Heuristics I-D] Kivinen, T., McDonald, D., "Heuristics for Detecting		[Heuristics] Kivinen, T. and D. McDonald, "Heuristics for Detecting
	ESP-NULL packets", Internet Draft, April 2009.		ESP-NULL packets", Work in Progress, March 2010.
	Author's Addresses		Authors' 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:		EMail: ken.grewal@intel.com
	Email: ken.grewal@intel.com
	Gabriel Montenegro		Gabriel Montenegro
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	Phone:		EMail: gabriel.montenegro@microsoft.com
	Email: gabriel.montenegro@microsoft.com
	Manav Bhatia		Manav Bhatia
	Alcatel-Lucent		Alcatel-Lucent
	Manyata Embassy		Manyata Embassy
	Nagawara Bangalore		Nagawara Bangalore
	India		India
	Phone:		EMail: manav.bhatia@alcatel-lucent.com
	Email: manav.bhatia@alcatel-lucent.com
End of changes. 113 change blocks.
	502 lines changed or deleted		474 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/