draft-ietf-ipsecme-traffic-visibility-05.txt		draft-ietf-ipsecme-traffic-visibility-06.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: December 23, 2009 Microsoft Corporation		Expires: February 06, 2010 Microsoft Corporation
	M. Bhatia		M. Bhatia
	Alcatel-Lucent		Alcatel-Lucent
	June 24, 2009		August 06, 2009
	Wrapped ESP for Traffic Visibility		Wrapped ESP for Traffic Visibility
	draft-ietf-ipsecme-traffic-visibility-05.txt		draft-ietf-ipsecme-traffic-visibility-06.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.		with the provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet		Internet-Drafts are working documents of the Internet
	Engineering Task Force (IETF), its areas, and its working		Engineering Task Force (IETF), its areas, and its working
	groups. Note that other groups may also distribute working		groups. Note that other groups may also distribute working
	documents as Internet-Drafts.		documents as Internet-Drafts.
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 October 30, 2009.		This Internet-Draft will expire on February 06, 2010.
	Copyright		Copyright
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-		publication of this document (http://trustee.ietf.org/license-
	info). Please review these documents carefully, as they describe		info). Please review these documents carefully, as they describe
	skipping to change at page 2, line 28		skipping to change at page 2, line 28
	mechanism described in this document can be used to easily		mechanism described in this document can be used to easily
	disambiguate ESP-NULL from ESP encrypted packets, without		disambiguate ESP-NULL from ESP encrypted packets, without
	compromising on the security provided by ESP.		compromising on the security provided by ESP.
	Table of Contents		Table of Contents
	1. Introduction...................................................2		1. Introduction...................................................2
	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...............................4		2. Wrapped ESP (WESP) Header format...............................4
	2.1. UDP Encapsulation.........................................6		2.1. UDP Encapsulation.........................................7
	2.2. Transport and Tunnel Mode Considerations..................7		2.2. Transport and Tunnel Mode Considerations..................8
	2.2.1. Transport Mode Processing............................8		2.2.1. Transport Mode Processing............................8
	2.2.2. Tunnel Mode Processing...............................9		2.2.2. Tunnel Mode Processing...............................9
	2.3. IKE Considerations.......................................10		2.3. IKE Considerations.......................................10
	3. Security Considerations.......................................10		3. Security Considerations.......................................11
	4. IANA Considerations...........................................11		4. IANA Considerations...........................................12
	5. Acknowledgments...............................................11		5. Acknowledgments...............................................12
	6. References....................................................11		6. References....................................................12
	6.1. Normative References.....................................11		6.1. Normative References.....................................12
	6.2. Informative References...................................12		6.2. Informative References...................................13
	1. Introduction		1. Introduction
	Use of ESP within IPsec [RFC4303] specifies how ESP packet		Use of ESP within IPsec [RFC4303] specifies how ESP packet
	encapsulation is performed. It also specifies that ESP can use		encapsulation is performed. It also specifies that ESP can use
	NULL encryption while preserving data integrity and		NULL encryption while preserving data integrity and
	authenticity. The exact encapsulation and algorithms employed		authenticity. The exact encapsulation and algorithms employed
	are negotiated out-of-band using, for example, IKEv2 [RFC4306]		are negotiated out-of-band using, for example, IKEv2 [RFC4306]
	and based on policy.		and based on policy.
	skipping to change at page 5, line 46		skipping to change at page 5, line 46
	Next Header, 8 bits: This field MUST be the same as the Next		Next Header, 8 bits: This field MUST be the same as the Next
	Header field in the ESP trailer when using ESP in the Integrity		Header field in the ESP trailer when using ESP in the Integrity
	only mode, and MUST be set to zero when using ESP with		only mode, and MUST be set to zero when using ESP with
	Encryption. The receiver MUST do some sanity checks before the		Encryption. The receiver MUST do some sanity checks before the
	WESP packet is accepted. Receiver MUST ensure that the Next		WESP packet is accepted. Receiver MUST ensure that the Next
	Header field in the WESP header and the Next Header field in the		Header field in the WESP header and the Next Header field in the
	ESP trailer match when using ESP in the Integrity only mode. The		ESP trailer match when using ESP in the Integrity only mode. The
	packet MUST be dropped if the two do not match. Similarly, the		packet MUST be dropped if the two do not match. Similarly, the
	receiver MUST ensure that the Next Header field in the WESP		receiver MUST ensure that the Next Header field in the WESP
	header is zero if using ESP with encryption. In this case, the		header is zero if using WESP with encryption. The WESP flags
	packet MUST be dropped if it is not set to zero and the packet		dictate if the packet is encrypted and/or integrity protected.
	is encrypted.
	HdrLen, 8 bits: Offset to the beginning of the Payload Data in		HdrLen, 8 bits: Offset from the beginning of the WESP header to
	octets. The receiver MUST ensure that this field matches with		the beginning of the Rest of Payload Data (i.e., past the IV, if
	the header offset computed from using the negotiated SA and MUST		present) within the encapsulated ESP header, in octets. The
	drop the packet in case it doesn't match.		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 doesn't match.
	TrailerLen, 8 bits: Offset from the end of the packet to the		TrailerLen, 8 bits: Offset from the end of the packet to the
	last byte of the payload data in octets. TrailerLen MUST be set		last byte of the payload data in octets. TrailerLen MUST be set
	to zero when using ESP with encryption. The receiver MUST only		to zero when using ESP with encryption. The receiver MUST only
	accept the packet if this field matches with the value computed		accept the packet if this field matches with the value computed
	from using the negotiated SA. This insures that sender is not		from using the negotiated SA. This insures that sender is not
	deliberately setting this value to obfuscate a part of the		deliberately setting this value to obfuscate a part of the
	payload from examination by a trusted intermediary device.		payload from examination by a trusted intermediary device.
	Flags, 8 bits		Flags, 8 bits
	2 bits: Version. MUST be sent as 0 and checked by the		2 bits: Version. MUST be sent as 0 and checked by the
	receiver. Future modifications to the WESP header may require a		receiver. Future modifications to the WESP header may require a
	new version number. Intermediate nodes dealing with unknown		new version number. Intermediate nodes dealing with unknown
	versions are not necessarily able to parse the packet correctly.		versions are not necessarily able to parse the packet correctly.
	Intermediate treatment of such packets is policy-dependent		Intermediate treatment of such packets is policy-dependent
	(e.g., it may dictate dropping such packets).		(e.g., it may dictate dropping such packets).
	6 bits: Flags, reserved for future use. The flags MUST be		1 bit: Encrypted Payload. Setting the Encrypted Payload bit
			to 1 indicates that the WESP (and therefore ESP) payload is
			protected with encryption. If this bit is set to 0, then the
			payload is using ESP-NULL cipher. Setting or clearing this bit
			also impacts the value in the WESP Next Header field, as
			described above. The recipient MUST ensure consistency of this
			flag with the negotiated policy and MUST drop the incoming
			packet otherwise.
			5 bits: Flags, reserved for future use. The flags MUST be
	sent as 0, and ignored by the receiver. Future documents		sent as 0, and ignored by the receiver. Future documents
	defining any of these flags MUST NOT affect the distinction		defining any of these flags MUST NOT affect the distinction
	between encrypted and unencrypted packets. Intermediate nodes		between encrypted and unencrypted packets. Intermediate nodes
	dealing with unknown flags are not necessarily able to parse the		dealing with unknown flags are not necessarily able to parse the
	packet correctly. Intermediate treatment of such packets is		packet correctly. Intermediate treatment of such packets is
	policy-dependent (e.g., it may dictate dropping such packets).		policy-dependent (e.g., it may dictate dropping such packets).
	Future versions of this protocol may change the Version number		Future versions of this protocol may change the Version number
	and/or the Flag bits sent, possibly by negotiating them over the		and/or the Flag bits sent, possibly by negotiating them over the
	control channel. The receiver MUST drop packets for which the		control channel. The receiver MUST drop packets for which the
End of changes. 9 change blocks.
	20 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/