< draft-ietf-ipsec-nat-t-ike-07.txt		draft-ietf-ipsec-nat-t-ike-08.txt >
	IP Security Protocol Working Group (IPSEC) T. Kivinen
	INTERNET-DRAFT SSH Communications Security
	draft-ietf-ipsec-nat-t-ike-07.txt B. Swander
	Expires: 29 March 2004 Microsoft
	A. Huttunen
	F-Secure Corporation
	V. Volpe
	Cisco Systems
	29 Sep 2003
	Negotiation of NAT-Traversal in the IKE		IP Security Protocol Working Group (IPsec) T. Kivinen
			INTERNET-DRAFT SafeNet A. Huttunen
			draft-ietf-ipsec-nat-t-ike-08.txt B. Swander
			Expires: 10 July 2004 Microsoft F-Secure Corporation
			V. Volpe
			Cisco Systems
			10 Feb 2004
	Status of This Memo		Negotiation of NAT-Traversal in the IKE
	This document is a submission to the IETF IP Security Protocol		Status of This Memo
	(IPSEC) Working Group. Comments are solicited and should be
	addressed to the working group mailing list (ipsec@lists.tislabs.com)
	or to the editor.
	This document is an Internet-Draft and is in full conformance		This document is a submission to the IETF IP Security Protocol
	with all provisions of Section 10 of RFC2026.		(IPSEC) Working Group. Comments are solicited and should be
			addressed to the working group mailing list (ipsec@lists.tislabs.com)
			or to the editor.
	Internet-Drafts are working documents of the Internet Engineering		This document is an Internet-Draft and is in full conformance
	Task Force (IETF), its areas, and its working groups. Note that		with all provisions of Section 10 of RFC2026.
	other groups may also distribute working documents as
	Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are working documents of the Internet Engineering
	months and may be updated, replaced, or obsoleted by other		Task Force (IETF), its areas, and its working groups. Note that
	documents at any time. It is inappropriate to use Internet-		other groups may also distribute working documents as
	Drafts as reference material or to cite them other than as		Internet-Drafts.
	"work in progress."
	The list of current Internet-Drafts can be accessed at		Internet-Drafts are draft documents valid for a maximum of six
	http://www.ietf.org/ietf/1id-abstracts.txt		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 Internet-Draft Shadow Directories can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/ietf/1id-abstracts.txt
	Abstract		The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
	This document describes how to detect one or more network address trans-		Abstract
	lation devices (NATs) between IPsec hosts, and how to negotiate the use
	of UDP encapsulation of the IPsec packets through the NAT boxes in
	Internet Key Exchange (IKE).
	Table of Contents		This document describes how to detect one or more network address trans-
			lation devices (NATs) between IPsec hosts, and how to negotiate the use
			of UDP encapsulation of IPsec packets through NAT boxes in Internet Key
			Exchange (IKE).
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2		Table of Contents
	2. Specification of Requirements . . . . . . . . . . . . . . . . . 2
	3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3.1. Detecting support of Nat-Traversal . . . . . . . . . . . . . 3
	3.2. Detecting presence of NAT . . . . . . . . . . . . . . . . . 3
	4. Changing to the new ports . . . . . . . . . . . . . . . . . . . 5
	5. Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Negotiation of the NAT-Traversal encapsulation . . . . . . . 7
	5.2. Sending the original source and destination addresses . . . 8
	6. Initial contact notifications . . . . . . . . . . . . . . . . . 9
	7. Recovering from the expiring NAT mappings . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
	10. Intellectual property rights . . . . . . . . . . . . . . . . . 11
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12
	12. Normative References . . . . . . . . . . . . . . . . . . . . . 12
	13. Non-Normative References . . . . . . . . . . . . . . . . . . . 12
	14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
			2. Specification of Requirements . . . . . . . . . . . . . . . . . 3
			3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
			3.1. Detecting support of Nat-Traversal . . . . . . . . . . . . . 3
			3.2. Detecting the presence of NAT . . . . . . . . . . . . . . . 3
			4. Changing to new ports . . . . . . . . . . . . . . . . . . . . . 5
			5. Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
			5.1. Negotiation of the NAT-Traversal encapsulation . . . . . . . 8
			5.2. Sending the original source and destination addresses . . . 8
			6. Initial contact notifications . . . . . . . . . . . . . . . . . 10
			7. Recovering from the expiring NAT mappings . . . . . . . . . . . 10
			8. Security Considerations . . . . . . . . . . . . . . . . . . . . 10
			9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
			10. Intellectual property rights . . . . . . . . . . . . . . . . . 12
			11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12
			12. Normative References . . . . . . . . . . . . . . . . . . . . . 13
			13. Non-Normative References . . . . . . . . . . . . . . . . . . . 13
			14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
			15. Full copyright statement . . . . . . . . . . . . . . . . . . . 14
	This document is split in two parts. The first part describes what is		1. Introduction
	needed in the IKE phase 1 for the NAT-Traversal support. This includes
	detecting if the other end supports NAT-Traversal, and detecting if
	there is one or more NAT along the path from host to host.
	The second part describes how to negotiate the use of UDP encapsulated		This document is split in two parts. The first part describes what is
	IPsec packets in the IKE Quick Mode. It also describes how to transmit		needed in IKE Phase 1 for NAT-Traversal support. This includes detecting
	the original source and destination addresses to the other end if		if the other end supports NAT-Traversal, and detecting if there is one
	needed. The original source and destination addresses are used in		or more NAT between the peers.
	transport mode to incrementally update the TCP/IP checksums so that they
	will match after the NAT transform (The NAT cannot do this, because the
	TCP/IP checksum is inside the UDP encapsulated IPsec packet).
	The document [Hutt03] describes the details of the UDP encapsulation and		The second part describes how to negotiate the use of UDP encapsulated
	[Aboba03] provides background information and motivation of the NAT-		IPsec packets in IKE's Quick Mode. It also describes how to transmit the
	Traversal in general. This document in combination with [Hutt03]		original source and destination addresses to the peer if required. The
	represent an "unconditionally compliant" solution to the requirements as		original source and destination addresses are used in transport mode to
	defined by [Aboba03].		incrementally update the TCP/IP checksums so that they will match after
			the NAT transform (The NAT cannot do this, because the TCP/IP checksum
			is inside the UDP encapsulated IPsec packet).
	2. Specification of Requirements		The document [Hutt03] describes the details of UDP encapsulation and
			[Aboba03] provides background information and motivation of NAT-
			Traversal in general. This document, in combination with [Hutt03]
			represents an "unconditionally compliant" solution to the requirements
			as defined by [Aboba03].
	This document shall use the keywords "MUST", "MUST NOT", "REQUIRED",		The basic scenario for this document is the case where the initiator is
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and		behind NA(P)T and the responder has a fixed static IP address.
	"OPTIONAL" to describe requirements. They are to be interpreted as
	described in [RFC-2119] document.
	3. Phase 1		This document defines a protocol that will work even if both ends are
			behind NAT, but the process of how to locate the other end is out of the
			scope of this document. In one scenario, the responder is behind a
			static host NAT (only one responder per IP as there is no way to use any
			other destination ports than 500/4500), i.e. it is known by the
			configuration.
	The detection of the support for the NAT-Traversal and detection of the		2. Specification of Requirements
	NAT along the path happens in the IKE [RFC-2409] phase 1.
	The NAT may change the IKE UDP source port, and recipients MUST be able
	to process IKE packets whose source port is different than 500. There
	are cases where the NAT does not have to change the source port:
	o only one IPsec host behind the NAT		This document shall use the keywords "MUST", "MUST NOT", "REQUIRED",
			"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and
			"OPTIONAL" to describe requirements. They are to be interpreted as
			described in [RFC-2119] document.
	o for the first IPsec host the NAT can keep the port 500, and change		3. Phase 1
	only specified IPsec host IP addresses
	Recipients MUST reply back to the source address from the packet. This		The detection of support for NAT-Traversal and detection of NAT along
	also means that when the original responder is doing rekeying, or		the path between the two IKE peers occurs in IKE [RFC-2409] Phase 1.
	sending notifications etc. to the original initiator it MUST send the
	packets from the same set of port and IP numbers that was used when the
	IKE SA was last time used (i.e the source and destination port and IP
	numbers must be same).
	For example, when the initiator sends a packet having source and		The NAT may change the IKE UDP source port, and recipients MUST be able
	destination port 500, the NAT may change that to a packet which has		to process IKE packets whose source port is different than 500. There
	source port 12312 and destination port 500. The responder must be able		are cases where the NAT does not have to change the source port:
	to process the packet whose source port is that 12312. It must reply
	back with a packet whose source port is 500 and destination port 12312.
	The NAT will then translate this packet to have source port 500 and
	destination port 500.
	3.1. Detecting support of Nat-Traversal		o only one IPsec host behind the NAT
	The NAT-Traversal capability of the remote host is determined by an		o for the first IPsec host the NAT can keep the port 500, and the NAT
	exchange of vendor strings; in Phase 1 two first messages, the vendor id		will only change the port number for later connections
	payload for this specification of NAT-Traversal (MD5 hash of "RFC XXXX"
	- ["XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX"]) MUST be sent if supported
	(and it MUST be received by both sides) for the NAT-Traversal probe to
	continue.
	3.2. Detecting presence of NAT		Recipients MUST reply back to the source address from the packet (See
			[Aboba03] section 2.1, case d). This also means that when the original
			responder is doing rekeying, or sending notifications etc. to the
			original initiator it MUST send the packets using the same set of port
			and IP numbers that was used when the IKE SA was last time used.
	The purpose of the NAT-D payload is twofold, It not only detects the		For example, when the initiator sends a packet having source and
	presence of NAT between two IKE peers, it also detects where the NAT is.		destination port 500, the NAT may change that to a packet which has
	The location of the NAT device is important in that the keepalives need		source port 12312 and destination port 500. The responder must be able
	to initiate from the peer "behind" the NAT.		to process the packet whose source port is that 12312. It must reply
			back with a packet whose source port is 500 and destination port 12312.
			The NAT will then translate this packet to have source port 500 and
			destination port 500.
	To detect the NAT between the two hosts, we need to detect if the IP		3.1. Detecting support of Nat-Traversal
	address or the port changes along the path. This is done by sending the
	hashes of IP address and port of both source and destination addresses
	from each end to another. When both ends calculate those hashes and get
	same result they know there is no NAT between. If the hashes do not
	match, somebody translated the address or port between, meaning we need
	to do NAT-Traversal to get IPsec packet through.
	If the sender of the packet does not know his own IP address (in case of		The NAT-Traversal capability of the remote host is determined by an
	multiple interfaces, and implementation don't know which is used to		exchange of vendor ID payloads. In the first two messages of Phase 1,
	route the packet out), he can include multiple local hashes to the		the vendor id payload for this specification of NAT-Traversal (MD5 hash
	packet (as separate NAT-D payloads). In this case the NAT is detected if		of "RFC XXXX" - ["XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX"]) MUST be sent if
	and only if none of the hashes match.		supported (and it MUST be received by both sides) for the NAT-Traversal
			probe to continue.
	The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each		[Note to the RFC Editor: The XXXX is replaced with the RFC number of
	payload contains one hash, so in case of multiple hashes, multiple NAT-D		this document when the number is known. The XXXXXXXX XXXXXXXX XXXXXXXX
	payloads are sent. In normal case there is only two NAT-D payloads.		XXXXXXXX will be replaced with MD5 hash of the text "RFC XXXX" (the
			exact hex string will be provided by the authors when the rfc number is
			known). This instruction is to be removed from the final RFC].
	The NAT-D payloads are included in the third and fourth packet in the		3.2. Detecting the presence of NAT
	main mode and second and third packet in the aggressive mode.		The purpose of the NAT-D payload is twofold, It not only detects the
			presence of NAT between the two IKE peers, it also detects where the NAT
			is. The location of the NAT device is important in that the keepalives
			need to initiate from the peer "behind" the NAT.
	The format of the NAT-D packet is		To detect NAT between the two hosts, we need to detect if the IP address
			or the port changes along the path. This is done by sending the hashes
			of the IP addresses and ports of both IKE peers from each end to the
			other. If both ends calculate those hashes and get same result they know
			there is no NAT between. If the hashes do not match, somebody has
			translated the address or port, meaning that we need to do NAT-Traversal
			to get IPsec packets through.
	1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8		If the sender of the packet does not know his own IP address (in case of
	+---------------+---------------+---------------+---------------+		multiple interfaces, and the implementation does not know which IP
	| Next Payload | RESERVED | Payload length |		address is used to route the packet out), the sender can include
	+---------------+---------------+---------------+---------------+		multiple local hashes to the packet (as separate NAT-D payloads). In
	~ HASH of the address and port ~		this case, NAT is detected if and only if none of the hashes match.
	+---------------+---------------+---------------+---------------+
	The payload type for the NAT discovery payload is 15.		The hashes are sent as a series of NAT-D (NAT discovery) payloads. Each
			payload contains one hash, so in case of multiple hashes, multiple NAT-D
			payloads are sent. In the normal case there are only two NAT-D payloads.
	The HASH is calculated as follows:		The NAT-D payloads are included in the third and fourth packet of Main
			Mode, and in second and third packet in the Aggressive Mode.
	HASH = HASH(CKY-I | CKY-R | IP | Port)		The format of the NAT-D packet is
	using the negotiated HASH algorithm. All data inside the HASH is in the		1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
	network byte-order. The IP is 4 octets for the IPv4 address and 16		+---------------+---------------+---------------+---------------+
	octets for the IPv6 address. The port number is encoded as 2 octet		| Next Payload | RESERVED | Payload length |
	number in network byte-order. The first NAT-D payload contains the		+---------------+---------------+---------------+---------------+
	remote ends IP address and port (i.e the destination address of the UDP		~ HASH of the address and port ~
	packet). The rest of the NAT-D payloads contain possible local end IP		+---------------+---------------+---------------+---------------+
	addresses and ports (i.e all possible source addresses of the UDP
	packet).
	If there is no NAT between then the first NAT-D payload received should		The payload type for the NAT discovery payload is 15.
	match one of the local NAT-D payloads (i.e local NAT-D payloads this
	host is sending out), and the one of the other NAT-D payloads must match
	the remote ends IP address and port. If the first check fails (i.e first
	NAT-D payload does not match any of the local IP addresses and ports),
	then it means that there is dynamic NAT between, and this end should
	start sending keepalives as defined in the [Hutt03].
	The CKY-I and CKY-R are the initiator and responder cookies, and they		The HASH is calculated as follows:
	are added to the hash to make precomputation attacks for the IP address
	and port impossible.
	An example of phase 1 exchange using NAT-Traversal in main mode		HASH = HASH(CKY-I | CKY-R | IP | Port)
	(authentication with signatures) is:
	Initiator Responder		using the negotiated HASH algorithm. All data inside the HASH is in the
	------------ ------------		network byte-order. The IP is 4 octets for an IPv4 address and 16 octets
	HDR, SA, VID -->		for an IPv6 address. The port number is encoded as a 2 octet number in
	<-- HDR, SA, VID		network byte-order. The first NAT-D payload contains the remote end's IP
	HDR, KE, Ni, NAT-D, NAT-D -->		address and port (i.e. the destination address of the UDP packet). The
	<-- HDR, KE, Nr, NAT-D, NAT-D		remaining NAT-D payloads contain possible local end IP addresses and
	HDR*#, IDii, [CERT, ] SIG_I -->		ports (i.e. all possible source addresses of the UDP packet).
	<-- HDR*#, IDir, [ CERT, ], SIG_R
	An example of phase 1 exchange using NAT-Traversal in aggressive mode		If there is no NAT between the peers, the first NAT-D payload received
	(authentication with signatures) is:		should match one of the local NAT-D payloads (i.e. the local NAT-D
			payloads this host is sending out), and one of the other NAT-D payloads
			must match the remote end's IP address and port. If the first check
			fails (i.e. first NAT-D payload does not match any of the local IP
			addresses and ports), then it means that there is dynamic NAT between
			the peers, and this end should start sending keepalives as defined in
			the [Hutt03] (this end is behind the NAT).
	Initiator Responder		The CKY-I and CKY-R are the initiator and responder cookies. They are
	------------ ------------		added to the hash to make precomputation attacks for the IP address and
	HDR, SA, KE, Ni, IDii, VID -->		port impossible.
	<-- HDR, SA, KE, Nr, IDir,
	[CERT, ], VID, NAT-D,
	NAT-D, SIG_R
	HDR*#, [CERT, ], NAT-D, NAT-D,
	SIG_I -->
	The '#' sign identifies that those packets are sent to the changed port		An example of a Phase 1 exchange using NAT-Traversal in Main Mode
	if NAT is detected.		(authentication with signatures) is:
	4. Changing to the new ports		Initiator Responder
			------------ ------------
			HDR, SA, VID -->
			<-- HDR, SA, VID
			HDR, KE, Ni, NAT-D, NAT-D -->
			<-- HDR, KE, Nr, NAT-D, NAT-D
			HDR*#, IDii, [CERT, ] SIG_I -->
			<-- HDR*#, IDir, [ CERT, ], SIG_R
	IPsec-aware NATs can cause problems. Some NATs will not change IKE		An example of Phase 1 exchange using NAT-Traversal in Aggressive Mode
	source port 500 even if there are multiple clients behind the NAT. They		(authentication with signatures) is:
	can also map IKE cookies to demultiplex traffic instead of using the
	source port. Both of these are problematic for generic NAT transparency
	since it is difficult for IKE to discover the capabilities of the NAT.
	The best approach is to simply move the IKE traffic off port 500 as soon
	as possible to avoid any IPsec-aware NAT special casing.
	Take the common case of the initiator behind the NAT. The initiator must		Initiator Responder
	quickly change to 4500 once the NAT has been detected to minimize the		------------ ------------
	window of IPsec-aware NAT problems.		HDR, SA, KE, Ni, IDii, VID -->
			<-- HDR, SA, KE, Nr, IDir,
			[CERT, ], VID, NAT-D,
			NAT-D, SIG_R
			HDR*#, [CERT, ], NAT-D, NAT-D,
			SIG_I -->
	In main mode, the initiator MUST change ports when sending the ID		The '#' sign identifies that those packets are sent to the changed port
	payload if there is NAT between the hosts. The initiator MUST set both		if NAT is detected.
	UDP source and destination ports to 4500. All subsequent packets sent to
	this peer (including informational notifications) MUST be sent on 4500.
	In addition, the IKE data MUST be prepended with a non-ESP marker
	allowing for demultiplexing of traffic as defined in [Hutt03].
	Thus, the IKE packet now looks like:		4. Changing to new ports
	IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I		IPsec-aware NATs can cause problems (See [Aboba03] section 2.3). Some
			NATs will not change IKE source port 500 even if there are multiple
			clients behind the NAT (See [Aboba03] section 2.3, case n). They can
			also use IKE cookies to demultiplex traffic instead of using the source
			port (See [Aboba03] section 2.3, case m). Both of these are problematic
			for generic NAT transparency since it is difficult for IKE to discover
			the capabilities of the NAT. The best approach is to simply move the IKE
			traffic off port 500 as soon as possible to avoid any IPsec-aware NAT
			special casing.
	assuming authentication using signatures. The 4 bytes of non-ESP marker		Take the common case of the initiator behind the NAT. The initiator must
	is defined in the [Hutt03].		quickly change to port 4500 once the NAT has been detected to minimize
			the window of IPsec-aware NAT problems.
	When the responder gets this packet he performs the usual decryption and		In Main Mode, the initiator MUST change ports when sending the ID
	processing of the various payloads. If this is successful, he MUST		payload if there is NAT between the hosts. The initiator MUST set both
	update local state so that all subsequent packets (including		UDP source and destination ports to 4500. All subsequent packets sent to
	informational notifications) to the peer use the new port, and possibly		this peer (including informational notifications) MUST be sent on port
	new IP address obtained from the incoming valid packet. The port will		4500. In addition, the IKE data MUST be prepended with a non-ESP marker
	generally be different since the NAT will map UDP(500,500) to		allowing for demultiplexing of traffic as defined in [Hutt03].
	UDP(X,500), and UDP(4500,4500) to UDP(Y,4500). The IP address will
	seldom be different from the pre-change IP address. The responder MUST
	respond with all subsequent IKE packets to this peer using UDP(4500,Y).
	Similarly, if the responder needs to rekey the phase 1 SA, then he MUST		Thus, the IKE packet now looks like:
	start the negotiation using UDP(4500,Y). Any implementation that
	supports NAT traversal, MUST support negotiations that begin on port
	4500. If a negotiation starts on 4500, then it doesn't need to change
	anywhere else in the exchange.
	Once port change has occurred, if a packet is received on 500, that		IP UDP(4500,4500) <non-ESP marker> HDR*, IDii, [CERT, ] SIG_I
	packet is old. If the packet is an informational, it MAY be processed if
	local policy allows. If the packet is a main mode or aggressive mode
	packet, it SHOULD be discarded.
	Here is an example of phase 1 exchange using NAT-Traversal in main mode		assuming authentication using signatures. The 4 bytes of non-ESP marker
	(authentication with signatures) with changing port:		is defined in the [Hutt03].
	Initiator Responder		When the responder gets this packet, the usual decryption and processing
	------------ ------------		of the various payloads is performed. If this is successful, the
	UDP(500,500) HDR, SA, VID -->		responder MUST update local state so that all subsequent packets
	<-- UDP(500,X) HDR, SA, VID		(including informational notifications) to the peer use the new port,
	UDP(500,500) HDR, KE, Ni,		and possibly the new IP address obtained from the incoming valid packet.
	NAT-D, NAT-D -->		The port will generally be different since the NAT will map UDP(500,500)
	<-- UDP(500,X) HDR, KE, Nr,		to UDP(X,500), and UDP(4500,4500) to UDP(Y,4500). The IP address will
	NAT-D, NAT-D		seldom be different from the pre-changed IP address. The responder MUST
	UDP(4500,4500) HDR*#, IDii,		respond with all subsequent IKE packets to this peer using UDP(4500,Y).
	[CERT, ]SIG_I -->
	<-- UDP(4500,Y) HDR*#, IDir,
	[ CERT, ], SIG_R
	The algorithm for aggressive mode is very similar. After the NAT has		Similarly, if the responder needs to rekey the Phase 1 SA, then the
	been detected, the initiator sends: IP UDP(4500,4500) <4 bytes of non-		rekey negotiation MUST be started using UDP(4500,Y). Any implementation
	ESP marker> HDR*, [CERT, ], NAT-D, NAT-D, SIG_I The responder does		that supports NAT traversal MUST support negotiations that begin on port
	similar processing to the above, and if successful, MUST update his		4500. If a negotiation starts on port 4500, then it doesn't need to
	internal IKE ports. The responder MUST respond with all subsequent IKE		change anywhere else in the exchange.
	packets to this peer using UDP(4500,Y).
	Initiator Responder		Once port change has occurred, if a packet is received on port 500, that
	------------ ------------		packet is old. If the packet is an informational packet, it MAY be
			processed if local policy allows. If the packet is a Main Mode or
			Aggressive Mode packet (with same cookies than previous packets), it
			SHOULD be discarded. If the packet is new Main Mode or Aggressive
			exchange then it is processed normally (the other end might have
			rebooted, and this is starting new exchange).
	UDP(500,500) HDR, SA, KE,		Here is an example of a Phase 1 exchange using NAT-Traversal in Main
	Ni, IDii, VID -->		Mode (authentication with signatures) with changing port:
	<-- UDP(500,X) HDR, SA, KE,
	Nr, IDir, [CERT, ],
	VID, NAT-D, NAT-D,
	SIG_R
	UDP(4500,4500) HDR*#, [CERT, ],
	NAT-D, NAT-D,
	SIG_I -->
	<-- UDP(4500, Y) HDR*#, ...		Initiator Responder
			------------ ------------
			UDP(500,500) HDR, SA, VID -->
			<-- UDP(500,X) HDR, SA, VID
			UDP(500,500) HDR, KE, Ni,
			NAT-D, NAT-D -->
			<-- UDP(500,X) HDR, KE, Nr,
			NAT-D, NAT-D
			UDP(4500,4500) HDR*#, IDii,
			[CERT, ]SIG_I -->
			<-- UDP(4500,Y) HDR*#, IDir,
			[ CERT, ], SIG_R
	While changing ports, the port in the ID payload in Main Mode/Aggressive		The procedure for Aggressive Mode is very similar. After the NAT has
	Mode MUST be 0.		been detected, the initiator sends: IP UDP(4500,4500) <4 bytes of non-
			ESP marker> HDR*, [CERT, ], NAT-D, NAT-D, SIG_I. The responder does
			similar processing to the above, and if successful, MUST update it's
			internal IKE ports. The responder MUST respond with all subsequent IKE
			packets to this peer using UDP(4500,Y).
	The most common case for the responder behind the NAT is if the NAT is		Initiator Responder
	simply doing 1-1 address translation. In this case, the initiator still		------------ ------------
	changes both ports to 4500. The responder uses the identical algorithm
	as above, although in this case, Y will equal 4500, since no port
	translation is happening.
	A different port change case involves out-of-band discovery of the ports		UDP(500,500) HDR, SA, KE,
	to use. For instance, if the responder is behind a port translating NAT,		Ni, IDii, VID -->
	and the initiator needs to contact it first, then the initiator will		<-- UDP(500,X) HDR, SA, KE,
	need to determine which ports to use, usually by contacting some other		Nr, IDir, [CERT, ],
	server. Once the initiator knows which ports to use to traverse the NAT,		VID, NAT-D, NAT-D,
	generally something like UDP(Z,4500), he initiates using these ports.		SIG_R
	This is similar to the responder rekey case above in that the ports to		UDP(4500,4500) HDR*#, [CERT, ],
	use are already known upfront, and no additional change need take place.		NAT-D, NAT-D,
			SIG_I -->
	Also the first keepalive timer starts after change to new port, no		<-- UDP(4500, Y) HDR*#, ...
	keepalives are sent to the port 500.
	5. Quick Mode		If the support of the NAT-Traversal is enabled the port in the ID
			payload in Main Mode/Aggressive Mode MUST be set to 0.
	After the Phase 1 both ends know if there is a NAT present between. The		The most common case for the responder behind the NAT is if the NAT is
	final decision of using the NAT-Traversal is left to the quick mode. The		simply doing 1-1 address translation. In this case, the initiator still
	use of NAT-Traversal is negotiated inside the SA payloads of the quick		changes both ports to 4500. The responder uses the identical algorithm
	mode. In the quick mode both ends can also send the original addresses		as above, although in this case Y will equal 4500, since no port
	of the IPsec packets (in case of the transport mode) to the other, end		translation is happening.
	so the other end has possibility to fix the TCP/IP checksum field after
	the NAT transform.
	5.1. Negotiation of the NAT-Traversal encapsulation		A different port change case involves out-of-band discovery of the ports
			to use. Those discovery methods are out of scope of this document. For
			instance, if the responder is behind a port translating NAT, and the
			initiator needs to contact it first, then the initiator will need to
			determine which ports to use, usually by contacting some other server.
			Once the initiator knows which ports to use to traverse the NAT,
			generally something like UDP(Z,4500), it initiates using these ports.
			This is similar to the responder rekey case above in that the ports to
			use are already known upfront, and no additional change need take place.
			Also, the first keepalive timer starts after the change to the new port,
			no keepalives are sent to the port 500.
	The negotiation of the NAT-Traversal happens by adding two new		5. Quick Mode
	encapsulation modes. These encapsulation modes are:
	UDP-Encapsulated-Tunnel 3		After the Phase 1 both ends know if there is a NAT present between them.
	UDP-Encapsulated-Transport 4		The final decision of using NAT-Traversal is left to Quick Mode. The
			use of NAT-Traversal is negotiated inside the SA payloads of Quick Mode.
			In Quick Mode, both ends can also send the original addresses of the
			IPsec packets (in case of the transport mode) to the other end, so the
			other end has possibility to fix the TCP/IP checksum field after the NAT
			transform.
	It is not normally useful to propose both normal tunnel or transport		5.1. Negotiation of the NAT-Traversal encapsulation
	mode and UDP-Encapsulated modes.
	If there is a NAT box between normal tunnel or transport encapsulations		The negotiation of the NAT-Traversal happens by adding two new
	may not work and in that case UDP-Encapsulation SHOULD be used.		encapsulation modes. These encapsulation modes are:
	If there is no NAT box between, there is no point of wasting bandwidth		UDP-Encapsulated-Tunnel 3
	by adding UDP encapsulation of packets, thus UDP-Encapsulation SHOULD		UDP-Encapsulated-Transport 4
	NOT be used.
	Also initiator SHOULD NOT include both normal tunnel or transport mode		It is not normally useful to propose both normal tunnel or transport
	and UDP-Encapsulated-Tunnel or UDP-Encapsulated-Transport in its		mode and UDP-Encapsulated modes. UDP encapsulation is required to fix
	proposals.		the inability to handle non-UDP/TCP traffic by NATs (See [Aboba03]
			section 2.2, case i).
	5.2. Sending the original source and destination addresses		If there is a NAT box between hosts, normal tunnel or transport
			encapsulations may not work and in that case UDP-Encapsulation SHOULD be
			used.
	In order to perform incremental TCP checksum fix ups, both peers may		If there is no NAT box between, there is no point of wasting bandwidth
	need to know the original IP addresses used by their peer when that peer		by adding UDP encapsulation of packets, thus UDP-Encapsulation SHOULD
	constructed the packet. On the initiator, the original Initiator address		NOT be used.
	is defined to be the Initiator's IP address. The original Responder
	address is defined to be the perceived peer's IP address. On the
	responder, the original Initiator address is defined to be the perceived
	peer's address. The original Responder address is defined to be the
	Responder's IP address.
	The original addresses are sent using NAT-OA (NAT Original Address)		Also, the initiator SHOULD NOT include both normal tunnel or transport
	payloads.		mode and UDP-Encapsulated-Tunnel or UDP-Encapsulated-Transport in its
			proposals.
	The Initiator NAT-OA payload is first. The Responder NAT-OA payload is		5.2. Sending the original source and destination addresses
	second.
	Example 1:		In order to perform incremental TCP checksum updates, both peers may
			need to know the original IP addresses used by their peer when that peer
			constructed the packet (See [Aboba03] section 2.1, case b). For the
			initiator, the original Initiator address is defined to be the
			Initiator's IP address. The original Responder address is defined to be
			the perceived peer's IP address. For the responder, the original
			Initiator address is defined to be the perceived peer's address. The
			original Responder address is defined to be the Responder's IP address.
	Initiator <---------> NAT <---------> Responder		The original addresses are sent using NAT-OA (NAT Original Address)
	^ ^ ^		payloads.
	Iaddr NatPub Raddr
	The initiator is behind a NAT talking to the publicly available		The Initiator NAT-OA payload is first. The Responder NAT-OA payload is
	responder. Initiator and Responder have IP addresses Iaddr, and Raddr.		second.
	NAT has public IP address NatPub.
	Initiator:		Example 1:
	NAT-OAi = Iaddr
	NAT-OAr = Raddr
	Responder:		Initiator <---------> NAT <---------> Responder
	NAT-OAi = NATPub		^ ^ ^
	NAT-OAr = Raddr		Iaddr NatPub Raddr
	Example 2:		The initiator is behind a NAT talking to the publicly available
			responder. Initiator and Responder have IP addresses Iaddr, and Raddr.
			NAT has public IP address NatPub.
	Initiator <------> NAT1 <---------> NAT2 <-------> Responder		Initiator:
	^ ^ ^ ^
	Iaddr Nat1Pub Nat2Pub Raddr
	Here, NAT2 "publishes" Nat2Pub for Responder and forwards all traffic to		NAT-OAi = Iaddr
	that address to Responder.		NAT-OAr = Raddr
	Initiator:		Responder:
	NAT-OAi = Iaddr		NAT-OAi = NATPub
	NAT-OAr = Nat2Pub		NAT-OAr = Raddr
	Responder:		Example 2:
	NAT-OAi = Nat1Pub
	NAT-OAr = Raddr
	In case of transport mode both ends MUST send the both original		Initiator <------> NAT1 <---------> NAT2 <-------> Responder
	Initiator and Responder addresses to the other end. For the tunnel mode		^ ^ ^ ^
	both ends SHOULD NOT send original addresses to the other end.		Iaddr Nat1Pub Nat2Pub Raddr
	The NAT-OA payloads are sent inside the first and second packets of the		Here, NAT2 "publishes" Nat2Pub for Responder and forwards all traffic to
	quick mode. The initiator MUST send the payloads if it proposes any UDP-		that address to Responder.
	Encapsulated-Transport mode and the responder MUST send the payload only
	if it selected UDP-Encapsulated-Transport mode. I.e it is possible that
	the initiator send the NAT-OA payload, but proposes both UDP-
	Encapsulated transport and tunnel mode. Then the responder selects the
	UDP-Encapsulated tunnel mode and does not send the NAT-OA payload back.
	The format of the NAT-OA packet is		Initiator:
			NAT-OAi = Iaddr
			NAT-OAr = Nat2Pub
	1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8		Responder:
	+---------------+---------------+---------------+---------------+		NAT-OAi = Nat1Pub
	| Next Payload | RESERVED | Payload length |		NAT-OAr = Raddr
	+---------------+---------------+---------------+---------------+
	| ID Type | RESERVED | RESERVED |
	+---------------+---------------+---------------+---------------+
	| IPv4 (4 octets) or IPv6 address (16 octets) |
	+---------------+---------------+---------------+---------------+
	The payload type for the NAT original address payload is 16.		In case of transport mode both ends MUST send the both original
			Initiator and Responder addresses to the other end. For tunnel mode both
			ends SHOULD NOT send original addresses to the other end.
	The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and		The NAT-OA payloads are sent inside the first and second packets of
	ID_IPV6_ADDR types are allowed. The two reserved fields after the ID		Quick Mode. The initiator MUST send the payloads if it proposes any UDP-
	Type must be zero.		Encapsulated-Transport mode and the responder MUST send the payload only
			if it selected UDP-Encapsulated-Transport mode, i.e. it is possible that
			the initiator sends the NAT-OA payload, but proposes both UDP-
			Encapsulated transport and tunnel mode. Then the responder selects the
			UDP-Encapsulated tunnel mode and does not send the NAT-OA payload back.
	An example of quick mode using NAT-OA payloads is:		The format of the NAT-OA packet is
	Initiator Responder		1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
	------------ ------------		+---------------+---------------+---------------+---------------+
	HDR*, HASH(1), SA, Ni, [, KE]		| Next Payload | RESERVED | Payload length |
	[, IDci, IDcr ]		+---------------+---------------+---------------+---------------+
	[, NAT-OAi, NAT-OAr] -->		| ID Type | RESERVED | RESERVED |
	<-- HDR*, HASH(2), SA, Nr, [, KE]		+---------------+---------------+---------------+---------------+
	[, IDci, IDcr ]		| IPv4 (4 octets) or IPv6 address (16 octets) |
	[, NAT-OAi, NAT-OAr]		+---------------+---------------+---------------+---------------+
	HDR*, HASH(3)
	6. Initial contact notifications		The payload type for the NAT original address payload is 16.
	The source IP and port address of the INITIAL-CONTACT notification for		The ID type is defined in the [RFC-2407]. Only ID_IPV4_ADDR and
	the host behind NAT are not meaningful, so the IP and port numbers MUST		ID_IPV6_ADDR types are allowed. The two reserved fields after the ID
	NOT be used for the determine which IKE/IPsec SAs to remove. The ID		Type must be zero.
	payload sent from the other SHOULD be used instead. I.e when INITIAL-
	CONTACT notification is received from the other end, the receiving end
	SHOULD remove all the SAs associated with the same ID payload.
	7. Recovering from the expiring NAT mappings		An example of Quick Mode using NAT-OA payloads is:
	There are cases where NAT box decides to remove mappings that are still		Initiator Responder
	alive (for example, the keepalive interval is too long, or the NAT box		------------ ------------
	is rebooted). To recover from those ends which are NOT behind NAT SHOULD		HDR*, HASH(1), SA, Ni, [, KE]
	use the last valid authenticated packet from the other end to determine		[, IDci, IDcr ]
	which IP and port addresses should be used. The host behind dynamic NAT		[, NAT-OAi, NAT-OAr] -->
	MUST NOT do this as otherwise it opens DoS attack possibility, and there		<-- HDR*, HASH(2), SA, Nr, [, KE]
	is no need for that, because the IP address or port of other host will		[, IDci, IDcr ]
	not change (it is not behind NAT).		[, NAT-OAi, NAT-OAr]
			HDR*, HASH(3)
	Keepalives cannot be used for this purposes as they are not		6. Initial contact notifications
	authenticated, but any IKE authenticated IKE packet or ESP packet can be
	used to detect that the IP address or the port has changed.
	8. Security Considerations		The source IP and port address of the INITIAL-CONTACT notification for
			the host behind NAT are not meaningful (NAT can change them), so the IP
			and port numbers MUST NOT be used for determining which IKE/IPsec SAs to
			remove (See [Aboba03] section 2.1, case c). The ID payload sent from the
			other end SHOULD be used instead, i.e. when an INITIAL-CONTACT
			notification is received from the other end, the receiving end SHOULD
			remove all the SAs associated with the same ID payload.
	Whenever changes to some fundamental parts of a security protocol are		7. Recovering from the expiring NAT mappings
	proposed, the examination of security implications cannot be skipped.
	Therefore, here are some observations on the effects, and whether or not
	these effects matter.
	o IKE probe reveals NAT-Traversal support to anyone watching the		There are cases where NAT box decides to remove mappings that are still
	traffic. Disclosure that NAT-Traversal is supported does not		alive (for example, the keepalive interval is too long, or the NAT box
	introduce new vulnerabilities.		is rebooted). To recover from this, ends which are NOT behind NAT SHOULD
			use the last valid authenticated packet from the other end to determine
			which IP and port addresses should be used. The host behind dynamic NAT
			MUST NOT do this as otherwise it opens a DoS attack possibility, and
			there is no need for that, because the IP address or port of the other
			host will not change (it is not behind NAT).
	o The value of authentication mechanisms based on IP addresses		Keepalives cannot be used for this purposes as they are not
	disappears once NATs are in the picture. That is not necessarily a		authenticated, but any IKE authenticated IKE packet or ESP packet can be
	bad thing (for any real security, other authentication measures than		used to detect that the IP address or the port has changed.
	IP addresses should be used). This means that pre-shared-keys
	authentication cannot be used with the main mode without group shared
	keys for everybody behind the NAT box. Using group shared keys is
	huge risk because that would allow any of the group to authenticate
	to any other party in the group and claim to be anybody in the group.
	I.e normal user could be impersonating as vpn-gateway, and acting man
	in the middle, and read/modify all traffic to/from others in the
	group. Use of group shared keys is NOT RECOMMENDED.
	o As the internal address space is only 32 bits, and it is usually very		8. Security Considerations
	sparse, it might be possible for the attacker to find out the
	internal address used behind the NAT box by trying all possible IP-
	addresses and trying to find the matching hash. The port numbers are
	normally fixed to 500, and the cookies can be extracted from the
	packet. This limits the hash calculations down to 2^32. If educated
	guess of use of private address space is done, then the number of
	hash calculations needed to find out the internal IP address goes
	down to the 2^24 + 2 * (2^16).
	o Neither NAT-D payloads or Vendor ID payloads are authenticated at all		Whenever changes to some fundamental parts of a security protocol are
	in the main mode nor in the aggressive mode. This means that attacker		proposed, the examination of security implications cannot be skipped.
	can remove those payloads, modify them or add them. By removing or		Therefore, here are some observations on the effects, and whether or not
	adding them the attacker can cause Denial Of Service attacks. By		these effects matter.
	modifying the NAT-D packets the attacker can cause both ends to use
	UDP-Encapsulated modes instead of directly using tunnel or transport
	mode, thus wasting some bandwidth.
	o The sending of the original source address in the Quick Mode reveals		o IKE probes reveal NAT-Traversal support to anyone watching the
	the internal IP address behind the NAT to the other end. In this case		traffic. Disclosure that NAT-Traversal is supported does not
	we have already authenticated the other end, and sending of the		introduce new vulnerabilities.
	original source address is only needed in transport mode.
	o Updating the IKE SA / ESP UDP encapsulation IP addresses and ports		o The value of authentication mechanisms based on IP addresses
	for each valid authenticated packet can cause DoS in case we have		disappears once NATs are in the picture. That is not necessarily a
	attacker who can listen all traffic in the network, and can change		bad thing (for any real security, authentication measures other than
	the order of the packet and inject new packets before the packet he		IP addresses should be used). This means that authentication using
	has already seen. I.e attacker can take the authenticated packet from		pre-shared-keys cannot be used in Main Mode without using group
	the host behind NAT, change the packet UDP source or destination		shared keys for everybody behind the NAT box. Using group shared keys
	ports or IP addresses and sent it out to the other end before the		is huge risk because it allows anyone in the group to authenticate to
	real packet reaches there. The host not behind the NAT will update		any other party and claim to be anybody in the group, i.e. a normal
	its IP address and port mapping and sends further traffic to wrong		user could be impersonating a vpn-gateway, and acting as a man in the
	host or port. This situation is fixed immediately when the attacker		middle, and read/modify all traffic to/from others in the group. Use
	stops modifying the packets as the first real packet will fix the		of group shared keys is NOT RECOMMENDED.
	situation back to normal. Implementations SHOULD AUDIT the event
	every time the mapping is changed, as in normal case it should not
	happen that often.
	9. IANA Considerations		o As the internal address space is only 32 bits, and it is usually very
			sparse, it might be possible for the attacker to find out the
			internal address used behind the NAT box by trying all possible IP-
			addresses and trying to find the matching hash. The port numbers are
			normally fixed to 500, and the cookies can be extracted from the
			packet. This limits the hash calculations down to 2^32. If an
			educated guess of the private address space is done, then the number
			of hash calculations needed to find out the internal IP address goes
			down to 2^24 + 2 * (2^16).
	This documents contains two new "magic numbers" which are allocated from		o Neither NAT-D payloads or Vendor ID payloads are authenticated at all
	the existing IANA registry for IPsec. This document also renames		in Main Mode nor in Aggressive Mode. This means that attacker can
	existing registered port 4500. This document also defines 2 new payload		remove those payloads, modify them or add them. By removing or adding
	types for IKE, and there is no registry for those in the IANA.		them, the attacker can cause Denial Of Service attacks. By modifying
			the NAT-D packets the attacker can cause both ends to use UDP-
			Encapsulated modes instead of directly using tunnel or transport
			mode, thus wasting some bandwidth.
	New items to be added in the "Internet Security Association and Key		o The sending of the original source address in the Quick Mode reveals
	Management Protocol (ISAKMP) Identifiers" Encapsulation Mode registry:		the internal IP address behind the NAT to the other end. In this case
			we have already authenticated the other end, and sending of the
			original source address is only needed in transport mode.
	Name Value Reference		o Updating the IKE SA / ESP UDP encapsulation IP addresses and ports
	---- ----- ---------		for each valid authenticated packet can cause DoS in the case where
	UDP-Encapsulated-Tunnel 3 [RFC XXXX]		we have an attacker who can listen to all traffic in the network, and
	UDP-Encapsulated-Transport 4 [RFC XXXX]		can change the order of the packets and inject new packets before the
			packet he has already seen, i.e. the attacker can take an
			authenticated packet from the host behind NAT, change the packet UDP
			source or destination ports or IP addresses and sent it out to the
			other end before the real packet reaches there. The host not behind
			the NAT will update its IP address and port mapping and sends further
			traffic to the wrong host or port. This situation is fixed
			immediately when the attacker stops modifying the packets as the
			first real packet will fix the situation back to normal.
			Implementations SHOULD AUDIT the event every time the mapping is
			changed, as in the normal case it should not happen that often.
	Change in the registered port registry:		9. IANA Considerations
	Keyword Decimal Description Reference		This documents contains two new "magic numbers" which are allocated from
	------- ------- ----------- ---------		the existing IANA registry for IPsec. This document also renames
	ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC XXXX]		existing registered port 4500. This document also defines 2 new payload
	ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC XXXX]		types for IKE, and there is no registry for those in the IANA.
	New IKE payload numbers are (There is no IANA registry related to this,		New items to be added in the "Internet Security Association and Key
	and no need to create new one, but if one is added these should be added		Management Protocol (ISAKMP) Identifiers" Encapsulation Mode registry:
	to there):
	NAT-D 15 NAT Discovery Payload		Name Value Reference
	NAT-OA 16 NAT Original Address Payload		---- ----- ---------
			UDP-Encapsulated-Tunnel 3 [RFC XXXX]
			UDP-Encapsulated-Transport 4 [RFC XXXX]
	10. Intellectual property rights		Change in the registered port registry:
	The IETF has been notified of intellectual property rights claimed in		Keyword Decimal Description Reference
	regard to some or all of the specification contained in this document.		------- ------- ----------- ---------
	For more information consult the online list of claimed rights.		ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFC XXXX]
			ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC XXXX]
	11. Acknowledgments		New IKE payload numbers are (There is no IANA registry related to this,
			and no need to create new one, but if one is added these should be added
			to there):
	Thanks to Markus Stenberg, Larry DiBurro and William Dixon who		NAT-D 15 NAT Discovery Payload
	contributed actively to this document.		NAT-OA 16 NAT Original Address Payload
	Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who		10. Intellectual property rights
	contributed to the document used as base for this document.
	12. Normative References		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
			IETF's procedures with respect to rights in IETF Documents can be found
			in RFC XX and RFC XY. [note to RFC Editor - replace XX with the number
			of IETF IPR and replace XY with number of IETF SUB.]
	[RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)",		Copies of IPR disclosures made to the IETF Secretariat and any
	November 1998		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.
	[RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation		The IETF invites any interested party to bring to its attention any
	for ISAKMP", November 1998		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.
	[Hutt03] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets",		11. Acknowledgments
	[RFC-2119] Bradner, S., "Key words for use in RFCs to indicate
	Requirement Levels", March 1997
	13. Non-Normative References		Thanks to Markus Stenberg, Larry DiBurro and William Dixon who
			contributed actively to this document.
	[Aboba03] Aboba, B. et. al., "IPsec-NAT Compatibility Requirements",		Thanks to Tatu Ylonen, Santeri Paavolainen, and Joern Sierwald who
	draft-ietf-ipsec-nat-reqts-04.txt, March 2003.		contributed to the document used as the base for this document.
	14. Authors' Addresses		12. Normative References
	Tero Kivinen		[RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)",
	SSH Communications Security Corp		November 1998
	Fredrikinkatu 42
	FIN-00100 HELSINKI
	Finland
	E-mail: kivinen@ssh.fi
	Ari Huttunen		[RFC-2407] Piper D., "The Internet IP Security Domain Of Interpretation
	F-Secure Corporation		for ISAKMP", November 1998
	Tammasaarenkatu 7,
	FIN-00181 HELSINKI
	Finland
	E-mail: Ari.Huttunen@F-Secure.com
	Brian Swander		[Hutt03] Huttunen, A. et. al., "UDP Encapsulation of IPsec Packets",
	Microsoft		draft-ietf-ipsec-udp-encaps-06.txt, January 2003
	One Microsoft Way
	Redmond WA 98052
	E-mail: briansw@microsoft.com
	Victor Volpe		[RFC-2119] Bradner, S., "Key words for use in RFCs to indicate
	Cisco Systems		Requirement Levels", March 1997
	124 Grove Street
	Suite 205		[IETF SUB] Bradner, S., "IETF Rights in Contributions", draft-ietf-ipr-
	Franklin, MA 02038		submission-rights-08.txt, October 2003
	E-mail: vvolpe@cisco.com
			[IETF IPR] Bradner, S., "Intellectual Property Rights in IETF
			Technology", draft-ietf-ipr-technology-rights-12.txt, October 2003
			13. Non-Normative References
			[Aboba03] Aboba, B. et. al., "IPsec-NAT Compatibility Requirements",
			draft-ietf-ipsec-nat-reqts-06.txt, October 2003.
			14. Authors' Addresses
			Tero Kivinen
			SafeNet, Inc.
			Fredrikinkatu 47
			FIN-00100 HELSINKI
			Finland
			E-mail: kivinen@safenet-inc.com
			Ari Huttunen
			F-Secure Corporation
			Tammasaarenkatu 7,
			FIN-00181 HELSINKI
			Finland
			E-mail: Ari.Huttunen@F-Secure.com
			Brian Swander
			Microsoft
			One Microsoft Way
			Redmond WA 98052
			E-mail: briansw@microsoft.com
			Victor Volpe
			Cisco Systems
			124 Grove Street
			Suite 205
			Franklin, MA 02038
			E-mail: vvolpe@cisco.com
			15. Full copyright statement
			Copyright (C) The Internet Society (year). This document is subject to
			the rights, licenses and restrictions contained in RFC XXXX and except
			as set forth therein, the authors retain all their rights.
			[Note to the RFC Editor - XXXX above to be replaced with the number of
			[IETF SUB]]
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 134 change blocks.
	490 lines changed or deleted		506 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/