< draft-boutros-nvo3-ipsec-over-geneve-00.txt		draft-boutros-nvo3-ipsec-over-geneve-01.txt >
	INTERNET-DRAFT Sami Boutros(Ed.)		NVO3 S. Boutros, Ed.
	Intended Status: Standard Track VMware		Internet-Draft C. Qian
			Intended status: Standards Track D. Wing
	Dan Wing		Expires: July 14, 2018 VMware, Inc.
	Calvin Qian		January 10, 2018
	VMware
	Expires: January 1, 2018 June 30, 2017
	IPSec over Geneve encapsulation		IPsec over Geneve Encapsulation
	draft-boutros-nvo3-ipsec-over-geneve-00		draft-boutros-nvo3-ipsec-over-geneve-01
	Abstract		Abstract
	This document specifies how Generic Network Virtualization		This document specifies how Generic Network Virtualization
	Encapsulation (Geneve) can be used to carry IP Encapsulating Security		Encapsulation (Geneve) can be used to carry IP Encapsulating Security
	Payload (ESP) and IP Authentication Header (AH) to provide secure		Payload (ESP) and IP Authentication Header (AH) to provide secure
	transport over IP networks. Using IPSec ESP and AH will provide both		transport over IP networks. Using IPSec ESP the Geneve payload is
	Geneve header integrity protection and Geneve payload encryption.		encrypted and integrity protected, and using IPSec AH the Geneve
			headers and payload are integrity protected.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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). Note that other groups may also distribute
	other groups may also distribute working documents as		working documents as Internet-Drafts. The list of current Internet-
	Internet-Drafts.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	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		This Internet-Draft will expire on July 14, 2018.
	http://www.ietf.org/1id-abstracts.html
	The list of Internet-Draft Shadow Directories can be accessed at		Copyright Notice
	http://www.ietf.org/shadow.html
	Copyright and License Notice		Copyright (c) 2018 IETF Trust and the persons identified as the
	Copyright (c) 2017 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		(https://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 respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 3
	4.0 Encapsulation Security Payload (ESP) over Geneve tunnel . . 4		4. Encapsulation Security Payload (ESP) over Geneve tunnel . . . 3
	5.0 IP Authentication header (AH) over Geneve tunnel . . . . . . 5		5. IP Authentication header (AH) over Geneve tunnel . . . . . . 4
	6. Control Plane Considerations . . . . . . . . . . . . . . . . . 6		6. Control Plane Considerations . . . . . . . . . . . . . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	10.1 Normative References . . . . . . . . . . . . . . . . . . . 7		10.1. Normative References . . . . . . . . . . . . . . . . . . 6
	10.2 Informative References . . . . . . . . . . . . . . . . . . 7		10.2. Informative References . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The Network Virtualization over Layer 3 (NVO3) develop solutions for		The Network Virtualization over Layer 3 (NVO3) develop solutions for
	network virtualization within a data center (DC) environment that		network virtualization within a data center (DC) environment that
	assumes an IP-based underlay. An NVO3 solution provides layer 2		assumes an IP-based underlay. An NVO3 solution provides layer 2 and/
	and/or layer 3 overlay services for virtual networks enabling multi-		or layer 3 overlay services for virtual networks enabling multi-
	tenancy and workload mobility. The Generic Network Virtualization		tenancy and workload mobility. The Generic Network Virtualization
	Encapsulation [GENEVE] have been recently recommended to be the		Encapsulation [I-D.ietf-nvo3-geneve] have been recently recommended
	proposed standard for network virtualization overlay encapsulation.		to be the proposed standard for network virtualization overlay
			encapsulation.
	Generic Network Virtualization Encapsulation (Geneve) does not have		Generic Network Virtualization Encapsulation (Geneve) does not have
	any inherent security mechanisms. An attacker with access to the		any inherent security mechanisms. An attacker with access to the
	underlay network transporting the IP packets has the ability to snoop		underlay network transporting the IP packets has the ability to snoop
	or inject packets.		or inject packets.
	Within a particular security domain, such as a data center operated		Within a particular security domain, such as a data center operated
	by a single provider, the most common and highest performing security		by a single provider, the most common and highest performing security
	mechanism is isolation of trusted components. Tunnel traffic can be		mechanism is isolation of trusted components. Tunnel traffic can be
	carried over a separate VLAN and filtered at any untrusted		carried over a separate VLAN and filtered at any untrusted
	boundaries. In addition, tunnel endpoints should only be operated in		boundaries. In addition, tunnel endpoints should only be operated in
	environments controlled by the service provider, such as the		environments controlled by the service provider, such as the
	hypervisor itself rather than within a customer VM.		hypervisor itself rather than within a customer VM.
	When crossing an untrusted link, such as the public Internet, IPsec		When crossing an untrusted link, such as the public Internet, IPsec
	[RFC4301] may be used to provide authentication and/or encryption of		[RFC4301] may be used to provide authentication and/or encryption of
	the IP packets formed as part of Geneve encapsulation. If the remote		the IP packets formed as part of Geneve encapsulation. If the remote
	tunnel endpoint is not completely trusted, for example it resides on		tunnel endpoint is not completely trusted, for example it resides on
	a customer premises, then it may also be necessary to sanitize any		a customer premises, then it may also be necessary to sanitize any
	tunnel metadata to prevent tenant-hopping attacks.		tunnel metadata to prevent tenant-hopping attacks.
	This document describes how Geneve tunnel encapsulation [GENEVE] can		This document describes how Geneve tunnel encapsulation
	be used to carry both the IP Encapsulation security payload (ESP)		[I-D.ietf-nvo3-geneve] can be used to carry both the IP Encapsulation
	[RFC4303] and the IP authentication header (AH) [RFC4302] to provide		security payload (ESP) [RFC4303] and the IP authentication header
	secure transport over IP networks. Using IPSec ESP and AH will		(AH) [RFC4302] to provide secure transport over IP networks. Using
	provide both Geneve header integrity protection and Geneve payload		IPsec ESP and AH will provide both Geneve header integrity protection
	encryption.		and Geneve payload encryption.
	2. Terminology		2. Terminology
	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 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Abbreviations		3. Abbreviations
	NVO3 Network Virtualization Overlays over Layer 3		NVO3: Network Virtualization Overlays over Layer 3
	OAM Operations, Administration, and Maintenance		OAM: Operations, Administration, and Maintenance
	TLV Type, Length, and Value
	VNI Virtual Network Identifier		TLV: Type, Length, and Value
	NVE Network Virtualization Edge		VNI: Virtual Network Identifier
	NVA Network Virtualization Authority		NVE: Network Virtualization Edge
	NIC Network interface card		NVA: Network Virtualization Authority
	IPSec IP Security		NIC: Network Interface Card
	ESP IP Encapsulating Security Payload		IPsec: IP Security
	AH IP Authentication Header		ESP: IP Encapsulating Security Payload
	GRE Generic Routing Encapsulation (GRE)		AH: IP Authentication Header
	EtherIP Tunneling Ethernet Frames in IP Datagrams		GRE: Generic Routing Encapsulation (GRE)
	Transit device Underlay network devices between NVE(s).		EtherIP: Tunneling Ethernet Frames in IP Datagrams
	4.0 Encapsulation Security Payload (ESP) over Geneve tunnel		4. Encapsulation Security Payload (ESP) over Geneve tunnel
	The Geneve packet is encapsulated in UDP over either IPv4 or IPv6.		The Geneve packet is encapsulated in UDP over either IPv4 or IPv6.
	The Geneve packet consists of a Geneve header which is then followed		The Geneve packet consists of a Geneve header which is then followed
	by a set of variable options. The Geneve header protocol type will		by a set of variable options. The Geneve header protocol type will
	indicate that the Geneve payload is the ESP protocol (IP Protocol		indicate that the Geneve payload is the ESP protocol (IP Protocol
	50), and the Geneve payload will consist of the ESP protocol data.		50), and the Geneve payload will consist of the ESP protocol data.
	The ESP next header can carry only an IP protocol so can't carry the		The ESP next header can carry only an IP protocol so can't carry the
	inner Ethernet frame, so given that (1) Generic Routing Encapsulation		inner Ethernet frame, so given that (1) Generic Routing Encapsulation
	(GRE) [RFC2784] and EtherIP [RFC3378] are IP protocols and (2)		(GRE) [RFC2784] and EtherIP [RFC3378] are IP protocols and (2) GRE/
	GRE/EtherIP can carry Ethernet Frames, hence the need of EtherIP/GRE		EtherIP can carry Ethernet Frames, hence the need of EtherIP/GRE
	encapsulation for the inner Ethernet payload.		encapsulation for the inner Ethernet payload.
	The ESP Next Header field will be set to inner payload protocol which		The ESP Next Header field will be set to inner payload protocol which
	can be either EtherIP (97) or to the Generic Routing Encapsulation		can be either EtherIP (97) or to the Generic Routing Encapsulation
	(GRE) (47). The GRE protocol type will be set to the Ethernet		(GRE) (47). The GRE protocol type will be set to the Ethernet
	protocol type.		protocol type. IPsec transport mode encryption is used.
	Inner Ethernet packet, as sent/received by the virtual machine:		Inner Ethernet packet, as sent/received by the virtual machine:
	+----------+---------+
	| Ethernet | Ethernet|
	| header | Payload |
	+----------+---------+
	After applying Geneve and ESP, with ETH-IP header.		+----------+---------+
			| Ethernet | Ethernet|
			| header | Payload |
			+----------+---------+
	+--------+------+------+----------+------+---+-------+------+-------+---+		After applying Geneve and ESP, with ETH-IP header:
	|Ethernet|outer |UDP |Geneve Hdr|Geneve|ESP|EtherIP|Inner |ESP |ESP|
	|header |IP |port= |Protocol |Option|Hdr|Header |Ether |Trailer|ICV|
	| |header|Geneve|=50 |TLV(s)| | |packet| | |
	+--------+------+------+----------+------+---+-------+------+-------+---+
	|<----Encrypted------->|
	|<---Integrity------------>|
	After applying Geneve and ESP, with GRE header.		+-----+------+------+----------+------+---+-------+------+-------+---+
			|Ether|outer |UDP |Geneve Hdr|Geneve|ESP|EtherIP|Inner |ESP |ESP|
			|hdr |IP |port= |Protocol |Option|Hdr|Header |Ether |Trailer|ICV|
			| |header|Geneve|=50 |TLV(s)| | |packet| | |
			+-----+------+------+----------+------+---+-------+------+-------+---+
			|<----Encrypted------->|
			|<---Integrity------------>|
	+--------+------+------+----------+------+---+-------+------+-------+---+		After applying Geneve and ESP, with GRE header:
	|Ethernet|outer |UDP |Geneve Hdr|Geneve|ESP|GRE |Inner |ESP |ESP|
	|header |IP |port= |Protocol |Option|Hdr|Header |Ether |Trailer|ICV|
	| |header|Geneve|=50 |TLV(s)| | |packet| | |
	+--------+------+------+----------+------+---+-------+------+-------+---+
	|<----Encrypted------->|
	|<---Integrity------------>|
	Figure 1: ESP over Geneve Packet Diagram		+-----+------+------+----------+------+---+-------+------+-------+---+
			|Ether|outer |UDP |Geneve Hdr|Geneve|ESP|GRE |Inner |ESP |ESP|
			|hdr |IP |port= |Protocol |Option|Hdr|Header |Ether |Trailer|ICV|
			| |header|Geneve|=50 |TLV(s)| | |packet| | |
			+-----+------+------+----------+------+---+-------+------+-------+---+
			|<----Encrypted------->|
			|<---Integrity------------>|
	5.0 IP Authentication header (AH) over Geneve tunnel		5. IP Authentication header (AH) over Geneve tunnel
	The Geneve packet is encapsulated in UDP over either IPv4 or IPv6.		The Geneve packet is encapsulated in UDP over either IPv4 or IPv6.
	The Geneve packet consists of a Geneve header which is then followed		The Geneve packet consists of a Geneve header which is then followed
	by a set of variable options. The Geneve header protocol type will		by a set of variable options. The Geneve header protocol type will
	indicate that the Geneve payload is the AH protocol (IP Protocol 51),		indicate that the Geneve payload is the AH protocol (IP Protocol 51),
	and the Geneve payload will consist of the Authentication header		and the Geneve payload will consist of the Authentication header
	(AH). The AH next header can carry only an IP protocol so can't carry		(AH). The AH next header can carry only an IP protocol so can't
	the inner Ethernet frame, so given that (1) Generic Routing		carry the inner Ethernet frame, so given that (1) Generic Routing
	Encapsulation (GRE) [RFC2784] and EtherIP [RFC3378] are IP protocols		Encapsulation (GRE) [RFC2784] and EtherIP [RFC3378] are IP protocols
	and (2) GRE/EtherIP can carry Ethernet Frames, hence the need of		and (2) GRE/EtherIP can carry Ethernet Frames, hence the need of
	EtherIP/GRE encapsulation for the inner Ethernet payload.		EtherIP/GRE encapsulation for the inner Ethernet payload.
	The AH Next Header field will be set to inner payload protocol which		The AH Next Header field will be set to inner payload protocol which
	can be either EtherIP (97) or to the Generic Routing Encapsulation		can be either EtherIP (97) or to the Generic Routing Encapsulation
	(GRE) (47). The GRE protocol type will be set to the Ethernet		(GRE) (47). The GRE protocol type will be set to the Ethernet
	protocol type.		protocol type.
	It is to be noted that some of the option TLV(s) in the Geneve header		It is to be noted that some of the option TLV(s) in the Geneve header
	SHOULD be treated as mutable fields and not included in the AH		SHOULD be treated as mutable fields and not included in the AH
	authentication.		authentication.
	Inner Ethernet packet, as sent/received by the virtual machine:		Inner Ethernet packet, as sent/received by the virtual machine:
	+----------+---------+
	| Ethernet | Ethernet|
	| header | Payload |
	+----------+---------+
	After applying Geneve and AH, with ETH-IP header.		+----------+---------+
			| Ethernet | Ethernet|
			| header | Payload |
			+----------+---------+
	+--------+------+------+----------+------+---+-------+------+		After applying Geneve and AH, with ETH-IP header:
	|Ethernet|outer |UDP |Geneve Hdr|Geneve|AH |EtherIP|Inner |
	|header |IP |port= |Protocol |Option| |Header |Ether |
	| |header|Geneve|=51 |TLV(s)| | |packet|
	+--------+------+------+----------+------+---+-------+------+
	|<--- authenticated except for mutable fields ---->|
	After applying Geneve and AH, with GRE header.		+--------+------+------+----------+------+---+-------+------+
			|Ethernet|outer |UDP |Geneve Hdr|Geneve|AH |EtherIP|Inner |
			|header |IP |port= |Protocol |Option| |Header |Ether |
			| |header|Geneve|=51 |TLV(s)| | |packet|
			+--------+------+------+----------+------+---+-------+------+
			|<--- authenticated except for mutable fields ---->|
	+--------+------+------+----------+------+---+-------+------+		After applying Geneve and AH, with GRE header:
	|Ethernet|outer |UDP |Geneve Hdr|Geneve|AH |GRE |Inner |
	|header |IP |port= |Protocol |Option| |Header |Ether |
	| |header|Geneve|=51 |TLV(s)| | |packet|
	+--------+------+------+----------+------+---+-------+------+
	|<--- authenticated except for mutable fields ---->|
	Figure 2: AH over Geneve Packet Diagram		+--------+------+------+----------+------+---+-------+------+
			|Ethernet|outer |UDP |Geneve Hdr|Geneve|AH |GRE |Inner |
			|header |IP |port= |Protocol |Option| |Header |Ether |
			| |header|Geneve|=51 |TLV(s)| | |packet|
			+--------+------+------+----------+------+---+-------+------+
			|<--- authenticated except for mutable fields ---->|
	6. Control Plane Considerations		6. Control Plane Considerations
	A control plane extension could allow a Network Virtualization		A control plane extension could allow a Network Virtualization
	Endpoint (NVE) to express the next protocol that can be carried by		Endpoint (NVE) to express the next protocol that can be carried by
	Geneve to its peers.		Geneve to its peers.
	In the datapath, a transmitting NVE MUST NOT encapsulate a packet		In the datapath, a transmitting NVE MUST NOT encapsulate a packet
	destined to another NVE with any protocol the receiving NVE is not		destined to another NVE with any protocol the receiving NVE is not
	capable of processing.		capable of processing.
	In this document the next protocol signaled in control plane by		In this document the next protocol signaled in control plane by
	NVE(s) can be ESP or AH.		NVE(s) can be ESP or AH.
	Once 2 NVE(s) agree to carry ESP or AH as next protocol, Security		Once two NVE(s) agree to carry ESP or AH as next protocol, the NVEs
	Association and Key Management Protocol defined in [RFC2408] can be		can use IKEv2 [RFC7296] to negotiate, establish, modify, and delete
	used to negotiate, establish, modify and delete Security		IPsec Security Associations.
	Associations. As well, mechanisms to perform key exchange defined in
	[RFC2409] can be used.
	7. Acknowledgements		7. Security Considerations
	The authors would like to thank T. Sridhar for his valuable comments.		If network policy requires IPsec encryption for certain traffic, it
			is important to ensure un-encrypted packets are not delivered to the
			guest virtual machine. This is implemented by dropping packets that
			arrive without the necessary IPsec encryption.
	8. Security Considerations		8. IANA Considerations
	This document does not introduce any additional security constraints.		This document does not register anything new with IANA.
	9. IANA Considerations		9. Acknowledgements
	TBD		The authors thank T. Sridhar for his valuable comments.
	10. References		10. References
	10.1 Normative References		10.1. Normative References
	[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate		[I-D.ietf-nvo3-geneve]
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
			Network Virtualization Encapsulation", draft-ietf-
			nvo3-geneve-05 (work in progress), September 2017.
	10.2 Informative References		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[Geneve] "Generic Network Virtualization Encapsulation", [I-D.ietf-		[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
	nvo3-geneve]		Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
			DOI 10.17487/RFC2784, March 2000,
			<https://www.rfc-editor.org/info/rfc2784>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	<http://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	[RFC4302] Kent, S. "IP Authentication Header", RFC 4302, December
	2005, <http://www.rfc-editor.org/info/rfc4302>.
	[RFC4303] Kent, S. "IP Encapsulating Security Payload", RFC 4303,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	December 2005, <http://www.rfc-editor.org/info/rfc4303>.		DOI 10.17487/RFC4302, December 2005,
			<https://www.rfc-editor.org/info/rfc4302>.
	[RFC3378] R. Housley, et al. "EtherIP: Tunneling Ethernet Frames in		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	IP Datagrams", RFC 3378, September 2002, <http://www.rfc-		RFC 4303, DOI 10.17487/RFC4303, December 2005,
	editor.org/info/rfc3378>.		<https://www.rfc-editor.org/info/rfc4303>.
	[RFC2784] T. Li, et al. "Generic Routing Encapsulation (GRE)", RFC		[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
	2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>.		Kivinen, "Internet Key Exchange Protocol Version 2
			(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
			2014, <https://www.rfc-editor.org/info/rfc7296>.
	[RFC2408] D. Maughan, et al. "Internet Security Association and Key		10.2. Informative References
	Management Protocol (ISAKMP)", RFC 2408, November 1998,
	<http://www.rfc-editor.org/info/rfc2408>.
	[RFC2409] D. Harkins, et al. "The Internet Key Exchange (IKE)", RFC		[RFC3378] Housley, R. and S. Hollenbeck, "EtherIP: Tunneling
	2409, November 1998, <http://www.rfc-editor.org/info/rfc2409>.		Ethernet Frames in IP Datagrams", RFC 3378,
			DOI 10.17487/RFC3378, September 2002,
			<https://www.rfc-editor.org/info/rfc3378>.
	Authors' Addresses		Authors' Addresses
	Sami Boutros		Sami Boutros (editor)
	VMware
	Email: sboutros@vmware.com
	Dan Wing
	VMware, Inc.		VMware, Inc.
	Email: dwing@vmware.com		3401 Hillview Ave.
			Palo Alto, CA 94304
			USA
			Email: sboutros@vmware.com
	Calvin Qian		Calvin Qian
	VMware, Inc.		VMware, Inc.
			3401 Hillview Ave.
			Palo Alto, CA 94304
			USA
	Email: calvinq@vmware.com		Email: calvinq@vmware.com
			Dan Wing
			VMware, Inc.
			3401 Hillview Ave.
			Palo Alto, CA 94304
			USA
			Email: dwing@vmware.com
End of changes. 73 change blocks.
	161 lines changed or deleted		166 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/