< draft-grewal-ipsec-traffic-visibility-00.txt		draft-grewal-ipsec-traffic-visibility-01.txt >
	Internet Draft K. Grewal		Internet Engineering Task Force K. Grewal
	D. Durham		Internet-Draft Intel Corporation
	M. Long		Intended status: Standards Track G. Montenegro
	Network Working Group Intel Corporation		Expires: December 25, 2008 Microsoft Corporation
	draft-grewal-ipsec-traffic-visibility-00.txt		June 23, 2008
	Intended Status: Standards
	Expires: June 2008 January 2008
	Traffic visibility using IPsec ESP NULL encryption		XESP for Traffic Visibility
			draft-grewal-ipsec-traffic-visibility-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026 [i].
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work 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
	http://www.ietf.org/shadow.html.
	Copyright Notice		The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
	Copyright (C) The IETF Trust (2008).		This Internet-Draft will expire on December 25, 2008.
	Abstract		Abstract
	This document describes leveraging UDP encapsulation for IPsec, using		This document describes an ESP encapsulation for IPsec, allowing
	ESP NULL encryption in order for intermediary devices to inspect the		intermediate devices to ascertain if ESP-NULL is being employed and
	IPsec packets. Currently in the IPsec standard, there is no way to		hence inspect the IPsec packets for network monitoring and access
	differentiate between ESP encryption and ESP NULL encryption by		control functions. Currently in the IPsec standard, there is no way
			to differentiate between ESP encryption and ESP NULL encryption by
	simply examining a packet.		simply examining a packet.
	Conventions used in this document		1. Introduction
			Use of ESP within IPsec [RFC4303] specifies how ESP packet
			encapsulation is performed. It also specifies that ESP can use NULL
			encryption [RFC2410] while preserving data integrity and
			authenticity. The exact encapsulation and algorithms employed are
			negotiated out-of-band using, for example, IKE [RFC2409] or IKEv2
			[RFC4306] and based on policy.
			Enterprise environments typically employ numerous security policies
			(and tools for enforcing them), as related to access control,
			firewalls, network monitoring functions, deep packet inspection,
			Intrusion Detection and Prevention Systems (IDS and IPS), scanning
			and detection of viruses and worms, etc. In order to enforce these
			policies, network tools and intermediate devices require visibility
			into packets, ranging from simple packet header inspection to deeper
			payload examination. Network security protocols which encrypt the
			data in transit prevent these network tools from performing the
			aforementioned functions.
			When employing IPsec within an enterprise environment, it is
			desirable to employ ESP instead of AH [RFC4302], as AH does not work
			in NAT environments. Furthermore, in order to preserve the above
			network monitoring functions, it is desirable to use ESP-NULL. In a
			mixed mode environment some packets containing sensitive data employ
			a given encryption cipher suite, while other packets employ ESP-NULL.
			For an intermediate device to unambiguously distinguish which packets
			are leveraging ESP-NULL, they would require knowledge of all the
			policies being employed for each protected session. This is clearly
			not practical. Heuristic-based methods can be employed to parse the
			packets, but these can be very expensive, containing numerous rules
			based on each different protocol and payload. Even then, the parsing
			may not be robust in cases where fields within a given encrypted
			packet happen to resemble the fields for a given protocol or
			heuristic rule. This is even more problematic when different 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 heuristics-based rules, when a simple exception policy
			(e.g., allow, drop or redirect) can be employed to handle the
			encrypted packets. Because of the non-deterministic nature of
			heuristics-based rules for disambiguating between encrypted and non-
			encrypted data, an alternative method for enabling intermediate
			devices to function in encrypted data environments needs to be
			defined. Enterprise environments typically use both stateful and
			stateless packet inspection mechanisms. The previous considerations
			weigh particularly heavy on stateless mechanisms such as router ACLs
			and NetFlow exporters.
			This document defines a mechanism to prove additional information in
			relevant IPsec packets so intermediate devices can efficiently
			differentiate between encrypted ESP packets and ESP packets with NULL
			encryption.
			The document is consistent with the operation of ESP in NAT
			environments [RFC3947].
			The design principles for this protocol are the following:
			o Allow easy identification and parsing of integrity-only IPsec
			traffic
			o Leverage the existing hardware IPsec parsing engines as much as
			possible to minimize additional hardware design costs
			o Minimize the packet overhead in the common case
			1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [ii].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Table of Contents		1.2. Applicability Statement
	1. Introduction...................................................2		The document is applicable only to the Extended ESP header defined
	1.1 Applicability Statement....................................3		below, and does not describe any changes to either ESP [RFC4303] nor
	2. UDP Encapsulation of IPsec ESP.................................3		AH [RFC4302].
	2.1 Extension Header...........................................4
	2.2 Tunnel and Transport mode of considerations................5
	2.3 Port conflicts.............................................5
	3. IANA Considerations............................................6
	4. Formal Syntax..................................................6
	5. Security Considerations........................................6
	6. References.....................................................6
	7. Acknowledgements...............................................7
	Author's Addresses.............................................7
	Full Copyright Statement.......................................8
	1. Introduction		2. Extended ESP (XESP) Header format
	The RFCs for leveraging ESP within IPsec describes how ESP packet		The proposal is to define an Extended ESP protocol number, which
	encapsulation is performed. Other RFCs describe how ESP can be		provides additional attributes in each packet. The value of the new
	leveraged using NULL encryption, while preserving data integrity and		protocol is TBD and the format of the new encapsulation is defined
	authenticity. However, the exact encapsulation employed and the		below.
	algorithms employed are negotiated out-of-band using the Internet-
	Key-Exchange (IKE) protocol. Once the packet is formatted and sent on
	the wire, it is infeasible to distinguish if encryption has been
	employed or is absent (ESP-NULL) by purely examining the packet.
	In the case of employing IPsec within the Enterprise environment, it
	is desirable for intermediate devices (such as load balancers,
	Intrusion Detection / Prevention Systems (IDS/IPS)) to have access to
	the data within each packet to preserve existing critical network
	services. In a mixed mode environment, where some packets containing
	sensitive data may employ a given encryption cipher suite, while
	other packets are employing ESP-NULL, the intermediate devices is
	unable to discern which packets are leveraging ESP-NULL, hence
	inhibiting further analysis on that packet. This document describes a
	mechanism leveraging UDP-encapsulation of IPsec ESP packets using a
	fixed destination port, allowing the intermediate device to
	differentiate between encrypted data and NULL encrypted data for ESP.
	1.1 Applicability Statement		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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Next Header | HdrLen | TrailerLen | Flags |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Security Parameters Index (SPI) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sequence Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IV (variable) |
			~ ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Payload Data |
			~ ~
			| |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| | TFC Padding * (optional, variable) |
			+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| | Padding (variable) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|Padding (0-255 bytes) |PAD Length | Next Header |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Integrity Check Value-ICV (variable) |
			~ ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The document is applicable to IPsec ESP only and does not describe		XESP Header
	any changes to IPsec AH.
	2. UDP Encapsulation of IPsec ESP		Figure 1
	UDP encapsulation of IPsec ESP packets is defined in RFC 3948 and		Where:
	takes the following basic format.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Port | Destination Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ESP header [RFC2406] |
	~ ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	According to RFC 3948, the source / destination port values are as		Next Header: next protocol header (encrypted in ESP trailer, but in
	the same as used by IKE.		the clear in header), providing easy access to a HW parser to
	We extend this to include a discrete destination port (value TBD)		extract the upper layer protocol. Note: For security concerns,
	which identifies the UDP/ESP payload as accessible for intermediate		this value may optionally be set to zero, in which case the next
	devices. The source UDP port must be as used by IKE and does not		header can be extracted from the ESP trailer.
	change from the above specification. Having a reserved, unique
	destination port to identify the payload as decipherable by
	intermediate devices provides flexibility in adding an additional,
	unique header following the UDP header which allows the intermediate
	device to parse the packet according to additional hints on how the
	packet has been encoded. This is needed to pass information within
	each packet on the algorithm employed for the data authenticity and
	hence any IV requirements for that particular algorithm. As different
	algorithms may have differing IV requirements, this extension allows
	the intermediate device to take into account IV (/ICV) for a given
	algorithm and parse the remaining data pertaining to the upper layer
	protocol. This extension encoding is a fixed size and encodes
	information about the specific data authenticity algorithm used for
	the given packet / SA, the offset to the upper layer protocol and the
	upper layer protocol value. Diagrammatically, this may be depicted as
	follows.
	0 1 2 3		HdrLen: includes the new header + full ESP header + the IV (if
	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		present). It is an offset to the beginning of the Payload Data.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source Port | Destination Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Next Header | offset |Reserved |Algo Encoding |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| ESP header [RFC2406] |
	~ ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The attributes in the extension header are described further below.		TrailerLen: Offset from the end of the packet including the ICV, pad
			length, and any padding. It is an offset from the end of the
			packet to the last byte of the payload data.
	2.1 Extension Header		Flags
	The extension header is exactly 32-bits, where the first 8-bits are		2 bits: Version
	used to convey the upper layer protocol being carried in the ESP
	payload. The value of this field is copied directly from the Next
	Header field of the ESP trailer and can be used by the intermediate
	device to determine / parse the upper layer protocol without having
	to find and parse the ESP trailer. The second 8-bits are used to
	convey the offset of the upper layer protocol from the end of this
	extension header (described further below). The third 8 bits are
	reserved for future expansion and set to zero. The last 8-bits
	contain the Algorithm Encoding and carries information about the
	algorithm being used to compute the ICV. This extension is needed in
	order for the intermediate device to determine which authentication
	algorithm is being used for generation of the ESP Integrity Check
	Value (ICV) and further parse the packet to extract the data portion.
	The size of the IV and ICV in the IPsec packet is algorithm
	dependent.
	In this document, we do not define explicit values for the Algorithm
	Encoding, but choose to reuse the same values defined in various
	IPsec RFCs which describe how to negotiate a given algorithm using
	IKE. In this manner, this specification will be future proofed for
	any new algorithm definitions. For example, RFC 4302, section 3.3.2
	defines specific values for the integrity algorithms, which are used
	within IKE. These are reserved for IKE via IANA. Additional RFCs
	defining other (newer) algorithms build upon these definitions and
	define new values for these algorithms. One example is RFC 4543,
	which describes usage of AES-GMAC within IPsec and hence defines the
	values used for different AES key sizes in section 9. The algorithm
	encoding is also useful in determining the size of the ICV for a
	given algorithm in order to deterministically extract the upper layer
	payload.
	The offset is an 8-bit value, which defines the number of octets		1 bit: IntegrityOnly: Payload Data is not encrypted (ESP-NULL).
	between the end of this extension header and the start of the upper
	layer protocol. This includes the ESP header, any additional IP
	header for tunnel mode and also the size of the IV, which may be
	algorithm dependent. Having an explicit value for the offset in the
	packet allows the intermediate device to directly parse past any
	algorithm dependent structures within the packet and reach the upper
	layer protocol header.
	The reserved 8-bits are used to pad this extension to a long word
	alignment. This should be set to 0 by the sender, but it is not
	mandatory for the recipient to validate this value.
	2.2 Tunnel and Transport mode of considerations		5 bits: reserved for future use. These MUST be set to zero per
			this specification, but usage may be defined by other
			specifications.
			As can be seen, this Extended ESP format simply extended the standard
			ESP header by the first 4 octets.
			2.1. UDP Encapsulation
			This section describes a mechanism for running the new packet format
			over the existing UDP encapsulation of ESP as defined in RFC 3948.
			This allows leveraging the existing IKE negotiation of the UDP port
			for NAT-T discovery and usage [RFC3947], as well as preserving the
			existing UDP ports for ESP (port 4500). With UDP encapsulation, the
			packet format can be depicted as follows.
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Src Port (4500) | Dest Port (4500) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Checksum |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Protocol Identifier (value = 0x00000001) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Next Header | HdrLen | TrailerLen | Flags |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Security Parameters Index (SPI) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Sequence Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IV (variable) |
			~ ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Payload Data |
			~ ~
			| |
			+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| | TFC Padding * (optional, variable) |
			+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| | Padding (0-255 bytes) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|Padding (0-255 bytes) |PAD Length | Next Header |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Integrity Check Value-ICV (variable) |
			~ ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			UDP-encapsulated XESP Header
			Figure 2
			Where:
			Source/Destination port (4500) and checksum: describes the UDP
			encapsulation header, per RFC3948.
			Protocol Identifier: new field to demultiplex between UDP
			encapsulation of IKE, UDP encapsulation of ESP per RFC 3948, and
			this proposal.
			According to RFC 3948, clause 2.2, a 4 octet value of zero (0)
			immediately following the UDP header indicates a Non-ESP marker,
			which can be used to assume that the data following that value is an
			IKE packet. Similarly, a value of non-zero indicates that the packet
			is an ESP packet and the 4-octet value can be treated as the ESP SPI.
			However, RFC 4303, clause 2.1 indicates that the values 1-255 are
			reserved and cannot be used as the SPI. We leverage that knowledge
			and use a value of 1 to indicate that the UDP encapsulated ESP header
			contains this new packet format for ESP encapsulation.
			The remaining fields in the packet have the same meaning as per
			section 2.0 above.
			2.2. Tunnel and Transport mode of considerations
	This extension is equally applicable for tunnel and transport mode		This extension is equally applicable for tunnel and transport 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 IPsec specifications.		these modes, as per the existing IPsec specifications.
	2.3 Port conflicts		2.3. IKE Considerations
	Another consideration is that a legacy client may choose the UDP port		In order to negotiate the new format of ESP encapsulation via IKE,
	reserved for this specification as a random source port for a totally		both sides of the security channel need to agree upon using the new
	different protocol exchange. Although this should not happen if the		packet format. This can be achieved by proposing a new protocol ID
	client is choosing ports from the dynamic range specified by IANA, it		within the existing IKE proposal structure as defined by RFC 4306,
	is still possible and hence the responsibility rests on the		clause 3.3.1. The existing proposal substructure in this clause
	intermediate device to ensure it can differentiate between the two		allows negotiation of ESP/AH (among others) by using different
	cases. The intermediate device can ensure that it is looking at ESP-		protocol Ids for these protocols. By using the same protocol
	NULL traffic that is UDP encapsulated in this form by validating		substructure in the proposal payload and using a new value (TBD) for
	additional data elements following the UDP header. The format of the		this encapsulation, the existing IKE negotiation can be leverage with
	UDP extension described above can be validated. If this is deemed		minimal changes to support negotiation of this encapsulation.
	insufficient, then as a process of extracting the upper layer payload
	from the ESP encapsulated packet, the ESP trailer needs to be
	examined (this will be at a fixed place in the packet, proceeding the
	ICV value) and can be validated according to IPsec ESP trailer
	construction, which may include some padding octets. Furthermore, the
	intermediate device can now validate that the upper layer protocol
	begins after a fixed length following the UDP header (UDP extension +
	ESP header). Additionally, if the upper layer protocol contains a
	checksum, the intermediate device can further validate the checksum
	to ensure that packet construction is as expected. Validating these
	additional elements reduces the probability of any random payload for
	a UDP exchange where the source port is the same as this
	specification from being treated as an ESP encapsulated payload.
	These checks are not mandatory, but should be performed to cater for
	this exception case. The extent and number of additional the checks
	performed are protocol dependent.
	3. IANA Considerations		Furthermore, because the negotiation is at the protocol level, other
			transforms remain valid for this new encapsulation and consistent
			with IKEv2 [RFC4306]. Additionally, NAT-T [RFC3948] is wholly
			compatible with this extended frame format and can be used as-is,
			without any modifications, in environments where NAT is present and
			needs to be taken into account.
	Reserving an appropriate value for the UDP destination port in order		3. Acknowledgements
	to provide this encapsulation is TBD and can happen after further
	peer review of this document.
	4. Formal Syntax		The authors would like to acknowledge the following people for their
			feedback on updating the definitions in this document.
	The following syntax specification uses the augmented Backus-Naur		David McGrew, Brian Weis, Philippe Joubert, Brian Swander, Yaron
	Form (BNF) as described in RFC-2234 [iii].		Sheffer, Men Long, David Durham, Prashant Dewan, Marc Millier among
			others.
	There is no new syntax defined by this document.		4. IANA Considerations
	5. Security Considerations		Reserving an appropriate value for this encapsulation as well as a
			new value for the protocol in the IKE negotiation is TBD by IANA.
	As this document augments the UDP encapsulation definitions specified		5. Security Considerations
	in RFC 3948, the security observations made in that document also
	apply here. In addition, as this document promotes intermediate		As this document augments the existing ESP encapsulation format, UDP
	device visibility into IPsec ESP encapsulated frames for the purposes		encapsulation definitions specified in RFC 3948 and IKE negotiation
	of Network monitoring functions, care should be taken not to send		of the new encapsulation, the security observations made in those
	sensitive data over connections using definitions from this document.		documents also apply here. In addition, as this document allows
	A strong key agreement protocol, such as IKE, together with a strong		intermediate device visibility into IPsec ESP encapsulated frames for
			the purposes of network monitoring functions, care should be taken
			not to send sensitive data over connections using definitions from
			this document, based on network domain/administrative policy. A
			strong key agreement protocol, such as IKE, together with a strong
	policy engine should be used to in determining appropriate security		policy engine should be used to in determining appropriate security
	policy for the given traffic streams and data over which it is being		policy for the given traffic streams and data over which it is being
	employed.		employed.
	6. References		6. References
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		6.1. Normative References
	3", BCP 9, RFC 2026, October 1996.
	[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.
	[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for		[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
	Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium		Its Use With IPsec", RFC 2410, November 1998.
	and Demon Internet Ltd., November 1997
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	August 1980.		RFC 4303, December 2005.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		6.2. Informative References
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
	Internet Protocol", RFC 2401, November 1998.		(IKE)", RFC 2409, November 1998.
	[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security		[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
	Payload (ESP)", RFC 2406, November 1998.		"Negotiation of NAT-Traversal in the IKE", RFC 3947,
			January 2005.
	[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange		[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
	(IKE)", RFC 2409, November 1998.		Stenberg, "UDP Encapsulation of IPsec ESP Packets",
			RFC 3948, January 2005.
	[RFC3947] Kivinen, T., "Negotiation of NAT-Traversal in the IKE",		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	RFC 3947, January 2005.		December 2005.
	[RFC4543] McGrew & Viega, "GMAC in IPsec ESP and AH",
	RFC 4543, May 2006.
	[RFC4306] Kaufman, C. "Internet Key Exchange (IKEv2) Protocol ",
	RFC 4306, December 2005.
	7. Acknowledgements		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
			RFC 4306, December 2005.
	Author's Addresses		Authors' Addresses
	Ken Grewal		Ken Grewal
	Intel Corporation		Intel Corporation
	2111 NE 25th Avenue		2111 NE 25th Avenue, JF3-232
	JF3-232		Hillsboro, OR 97124
	Hillsboro, OR 97124
	USA		USA
			Phone:
	Email: ken.grewal@intel.com		Email: ken.grewal@intel.com
	David Durham		Gabriel Montenegro
	Intel Corporation		Microsoft Corporation
	2111 NE 25th Avenue		One Microsoft Way
	JF3-232		Redmond, WA 98052
	Hillsboro, OR 97124
	USA
	Email: david.durham@intel.com
	Men Long
	Intel Corporation
	2111 NE 25th Avenue
	JF3-232
	Hillsboro, OR 97124
	USA		USA
	Email: men.long@intel.com
			Phone:
			Email: gabriel.montenegro@microsoft.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
			The IETF takes no position regarding the validity or scope of any
			Intellectual Property Rights or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; nor does it represent that it has
			made any independent effort to identify any such rights. Information
			on the procedures with respect to rights in RFC documents can be
			found in BCP 78 and BCP 79.
			Copies of IPR disclosures made to the IETF Secretariat and any
			assurances of licenses to be made available, or the result of an
			attempt made to obtain a general license or permission for the use of
			such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights that may cover technology that may be required to implement
			this standard. Please address the information to the IETF at
			ietf-ipr@ietf.org.
End of changes. 52 change blocks.
	242 lines changed or deleted		293 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/