< draft-tschofenig-hiprg-hip-natfw-traversal-03.txt		draft-tschofenig-hiprg-hip-natfw-traversal-04.txt >
	HIPRG H. Tschofenig		HIPRG H. Tschofenig
	Internet-Draft Siemens		Internet-Draft M. Shanmugam
	Expires: April 27, 2006 M. Shanmugam		Expires: September 7, 2006 Siemens AG
	TUHH		March 6, 2006
	October 24, 2005
	Traversing HIP-aware NATs and Firewalls: Problem Statement and		Traversing HIP-aware NATs and Firewalls: Problem Statement and
	Requirements		Requirements
	draft-tschofenig-hiprg-hip-natfw-traversal-03.txt		draft-tschofenig-hiprg-hip-natfw-traversal-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 35 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		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 April 27, 2006.		This Internet-Draft will expire on September 7, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The Host Identity Protocol is a signaling protocol which adds another		The Host Identity Protocol (HIP) is a signaling protocol, which
	layer to the Internet model and (optionally) establishes IPsec ESP		supports mobility and multihoming by adding a new layer to the TCP/IP
	SAs to protect subsequent data traffic. HIP is designed to be a		stack. By carring relevant parameters in the signaling messages, HIP
	middlebox friendly protocol, it allows the middleboxes (such as NATs		can be used to establish IPsec encapsulating security payload (ESP)
	and Firewalls) to participate in the base exchange messages in order		security associations between two hosts. Middleboxes (e.g. firewalls
	to learn the flow identifier and thereby, relying the data traffic.		and network address translators) cannot inspect transport layer
			headers of data traffic if that traffic is sent over an IPsec ESP
	Adding authentication and authorization mechanisms can help the		tunnel. However, HIP is designed to be middlebox friendly; it
	middlebox decide which end hosts are allowed to traverse a firewall.		enables the middleboxes to inspect the signaling messages. The
	This can potentially prevent waste of network resources and limit		information that they can derive from that messages enables the
	unwanted traffic. This document gives a problem statement and		middleboxes to uniquely identify the subsequent data flows, e.g. for
	requirements for HIP-aware middlebox traversal techniques.		the purposes of multiplexing and demultiplexing . A middlebox that
			implements the relevant mechanisms is called "HIP-aware". This
			document presents a problem statement and lists some requirements
			that are necessary for a HIP-aware middlebox traversal technique.
			These include authentication and authorization of signaling end-hosts
			by the middleboxes. Such authorization will help the middleboxes to
			decide whether or not an end host is allowed to traverse, and can
			potentially limit unwanted traffic.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
	4. Overview of HIP Base Exchange with Middleboxes . . . . . . . . 7		4. HIP with Middleboxes . . . . . . . . . . . . . . . . . . . . . 8
	4.1. HIP Base Exchange with NAT . . . . . . . . . . . . . . . . 7		4.1. HIP Base Exchange with middleboxes . . . . . . . . . . . . 8
	4.2. HIP Base Exchange with Firewall . . . . . . . . . . . . . 8		4.2. HIP Base Exchange with ESP Parameters and Middleboxes . . 9
	5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.3. HIP Mobility/Multihoming Exchange with Middleboxes . . . . 10
	5.1. Same Firewall at Initiator for both outgoing and		5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	incoming packets . . . . . . . . . . . . . . . . . . . . . 10		5.1. Different Firewalls at Initiator for outgoing and
	5.2. Different Firewalls at Initiator for outgoing and		incoming packets . . . . . . . . . . . . . . . . . . . . . 13
	incoming packets . . . . . . . . . . . . . . . . . . . . . 11		5.2. Data Receiver behind a NAT . . . . . . . . . . . . . . . . 15
	5.3. Different Firewalls at Initiator and Receiver . . . . . . 12		6. Requirements for HIP Middlebox Solution . . . . . . . . . . . 17
	6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		10.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 19		10.2. Informative References . . . . . . . . . . . . . . . . . . 21
	10.2. Informative References . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Intellectual Property and Copyright Statements . . . . . . . . . . 24
	Intellectual Property and Copyright Statements . . . . . . . . . . 22
	1. Introduction		1. Introduction
	An IP address serves the dual role of a locator and an identifier for		In the current Internet architecture, an IP address is used to locate
	every host on the Internet. Since, the transport layer connections		and to identify a host, termed as "locator" and "identifier"
	are bound to the IP address, end systems that use IP addresses as		respectively. Hosts that move and change their IP addresses are said
	identifiers cannot support dynamic changes in the mapping between the		to be mobile and those that prefer to be addressed with multiple IPs
	identifier and the locator in case of multi-homing and mobility.		at a given time are said to be multihomed. Mobility and Multihoming
			are together expressed as Multiaddressing. When hosts use IP
			addresses for communication, all transport connections are bound to
			it. Changes to IP addresses mean breaking the existing transport
			bindings and establishing a new transport connection. Hence, the
			existing dual role of IP addresses are not able to cope with the
			requirements for multiaddressing.
	The Host Identity Protocol (HIP) [I-D.ietf-hip-base] proposes to		The Host Identity Protocol (HIP) [I-D.ietf-hip-base], a
	separate the identifier from the locator by adding an additional		multiaddressing proposal, presents a novel approach to separate the
	layer between the transport layer and the network layer. The		"identifier" role from the "locator" role by adding an additional
	transport layer uses a new, mobility-unrelated identifier called as		layer between the traditional transport layer and the network layer.
	Host Identity Tags (HITs), in place of IP addresses, while the		The transport layer uses a new, mobility-unrelated identifier called
	network layer uses conventional IP addresses for routing. IPsec		as Host Identity Tags (HITs), in place of IP addresses, while the
	security associations are bound to the HITs and are not modified with		network layer uses conventional IP addresses for routing. As the
	IP address changes. In other words, a host despite being mobile or		transport connections are bound to the HITs, they are not disturbed
	multi-homed can use a single transport layer connection associated to		with the change in IP address. In other words, a host despite being
	one HIT and multiple IP addresses.		mobile can use a single transport layer connection associated to one
			HIT and multiple IP addresses.
	The Host Identity Protocol offers also the functionality to establish		HIP uses a two-way handshake mechanism, termed as base exchange
	IPsec ESP SAs which are subsequently used to encrypt data traffic		messages, to authenticate and to establish a connection with an end
	between the two end hosts. HIP is liable to all known		host. HIP also offers the functionality to carry IPsec ESP relevant
	incompatibilities of IPsec with middleboxes such as NATs [RFC3022]		payloads together with the base exchange messages in order to
	and firewalls. The problem statement for dealing with legacy NATs is		establish IPsec ESP security associations, which are subsequently
	described in [I-D.irtf-hiprg-nat]. The main goal of the draft is to		used to encrypt the data traffic between the two end hosts.
	present a problem statement and requirements in order to aim for a		Consequently, if HIP is used to establish IPsec ESP SAs then it will
	NAT/FW traversal solution using the Host Identity Protocol.		also inherit some of the well-known incompatibilities similar to
			IPsec ESP-NAT problems, as described in [RFC3715]. To overcome that,
			HIP allows the middleboxes to participate in the base exchange,
			inspect the relevant traffic identifiers and later the middleboxes
			will use those identifiers to distinguish and to allow a particular
			data traffic.
			This document presents a problem statement in the context of HIP and
			middlebox traversal, and discusses the requirements that has to be
			addressed by a HIP-aware NAT/FW traversal technique.
			[Editor's Note: The problem statement for the HIP dealing with legacy
			NATs is described in [I-D.irtf-hiprg-nat].]
			The document is organized as follows: Section 3 presents the problem
			statement, Section 4 sketches the overview of the HIP base exchange
			together with the middleboxes, Section 5 discusses possible scenarios
			and Section 6 discusses the requirements and properties for a HIP-
			aware middlebox solution.
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	This draft used the terminology defined in [NATTerminology],		This draft used the terminology defined in [RFC2663], [I-D.ietf-hip-
	[I-D.ietf-hip-base], [I-D.ietf-HIP-esp] and		base], [I-D.ietf-hip-esp] and [I-D.ietf-hip-arch] and [RFC2401].
	[draft-moskowitz-hip-arch] and [RFC2401].
	The term SPI refers to the Security Parameter Index value used in		The term SPI refers to the Security Parameter Index value used in
	IPsec packets. The initiator selects one SPI(I) that can be found in		IPsec packets. The initiator selects one SPI(I) that can be found in
	the ESP_info parameter, which is then used by the responder to create		the ESP_info parameter, which is then used by the responder to create
	an IPsec packet (ESP packet in this case) for traffic sent to the		an IPsec packet (ESP packet in this case) for traffic sent to the
	initiator. The responder selects one SPI(R)(using ESP_info(R)		initiator. The responder selects one SPI(R)(using ESP_info(R)
	parameter) which is used by the initiator to encrypt all data sent to		parameter) which is used by the initiator to encrypt all data sent to
	the responder.		the responder.
	Other relevant abbreviations can be found in [I-D.ietf-hip-base] and		Other relevant abbreviations can be found in [I-D.ietf-hip-base] and
	[I-D.ietf-HIP-esp].		[I-D.ietf-hip-esp].
	The concept of a flow identifier is described in [RFC4080].		The concept of a flow identifier is described in [RFC4080].
	We use the following notation throughout this document:		We use the following notation throughout this document:
	o [x] indicates that x is optional.		[x] indicates that x is optional.
	o {x} indicates that x is encrypted.		{x} indicates that x is encrypted.
	o <x>y indicates that "x" is encrypted with the key "y".		<x>y indicates that "x" is encrypted with the key "y".
	o --> signifies "Initiator to Responder" communication (requests).		--> signifies "Initiator to Responder" communication (requests).
	o <-- signifies "Responder to Initiator" communication (replies).		<-- signifies "Responder to Initiator" communication (replies).
	3. Problem Statement		3. Problem Statement
	This document assumes that the data traffic following the HIP base
	exchange is IPsec protected using the mechanism described in
	[I-D.ietf-HIP-esp] for exchanging the IPsec parameters. A future
	version of this draft might also be extended to support other
	mechanisms for data traffic protection including no protection at
	all.
	Besides the communicating hosts in the Internet, the entities such as		Besides the communicating hosts in the Internet, the entities such as
	NATs and Firewalls play a major role in the event of delivering		NATs and Firewalls play a major role in the event of delivering
	packets to an appropriate host, and each meant for specific		packets to an appropriate host, and each meant for specific
	functionality. For instance, NATs are used to combat the IPv4		functionality. For instance, NATs are used to combat the IPv4
	address depletion problem, and Firewalls are erected to protect		address depletion problem, and Firewalls are erected to protect
	unsolicited information flowing in and out of a corporate network.		unsolicited information flowing in and out of a corporate network.
	NATs use <src IP ,dst IP, src port, dst port, protocol> as an flow
	identifier to identify a particular traffic or connection. Because		Typically, NATs use <src IP ,dst IP, src port, dst port, protocol> as
	of this, protocols like IPsec suffers from well-known NAT related		an flow identifier to identify a particular traffic or connection.
	problems. The NAT traversal approach described in [RFC3947] and		Because of this, protocols like IPsec suffers from well-known NAT
	[I-D.ietf-ipsec-ikev2] allows the end hosts to detect one or more		related problems[RFC3715]. The NAT traversal approaches described in
			[RFC3947] and [RFC4306] allows the end hosts to detect one or more
	NATs in between them and [RFC3948] proposes to use the UDP		NATs in between them and [RFC3948] proposes to use the UDP
	encapsulation of IPsec ESP packets to traverse NATs.		encapsulation of IPsec ESP packets to traverse NATs.
	Since HIP uses IPsec protection for the data traffic, the flow		If HIP uses IPsec protection for the data traffic then the flow
	identifier takes the shape of a <destination IP address, SPI and ESP>		identifier will take the shape of <destination IP address, SPI and
	(in order to support smooth traversal of the middleboxes) and the		ESP>. Although HIP is described as a two-party protocol, middle
	middleboxes should learn this flow id in order to relay the data		boxes are supposed to intercept the base exchange messages to learn
	packets. To achieve this, HIP aims to interact with middleboxes		the flow identifier and to process them correctly. In other words, a
	actively whereby these devices need to understand the HIP protocol		multi party protocol is created such that the flow identifier is
	and they need to be involved in the protocol exchange. HIP also		available to middle boxes between the HIP hosts. To achieve this,
	provides a way to deal with legacy NATs, as described in		HIP aims to interact with middleboxes actively whereby these devices
	[draft-nikander-hip-path-00.txt]. To support this functionality, it		need to understand the HIP protocol and they need to be involved in
	is necessary to provide UDP encapsulation for both HIP signaling and		the protocol exchange.
	IPsec packets. Legacy NAT traversal does not require NATs to be HIP
	aware or to understand the HIP message exchange.
	Even though HIP allows the middleboxes to participate in the base
	exchange, but scenarios like routing asymmetry poses a serious
	challenge for the HIP to traverse a middlebox. Section 5 explains
	some possible scenarios which have routing asymmetry. The inability
	of HIP to handle routing asymmetry motivates to use an explicit
	signaling mechanism for the HIP hosts in order to support secure and
	smooth traversal of the middleboxes.
	Although HIP is described as a two-party protocol, middle boxes are		This interaction, obviously, requires the middleboxes to verify the
	supposed to intercept these messages in order to learn the flow		authenticity of the base exchange messages in order to learn the flow
	identifier and to process them correctly. In other words, a multi		identifier and to create a state i.e., NAT binding or a pinhole. In
	party protocol is created such that the flow identifier is available		this context, to provide proper security, middleboxes should not be
	to middle boxes between the HIP hosts. To provide proper security,		vulnerable to denial of service attacks and might want to
	middleboxes should not be subject to denial of service attacks and		authenticate or authorize entities before creating state information.
	might want to authenticate or authorize entities which create state.
	Note that the IPsec SA is unidirectional and therefore two IPsec SAs		Note that the IPsec SA is unidirectional and therefore two IPsec SAs
	(with two different SPIs, ESP_info contains the SPI value) have to be		(with two different SPIs, ESP_info contains the SPI value) have to be
	established.		established.
	4. Overview of HIP Base Exchange with Middleboxes		Finally, End hosts, behind middleboxes especially NATs, require the
			following steps to facilitate its reachability.
	This section explains the HIP base exchange together with the		1. Connection, end host connects to the server, while doing that it
	middleboxes and describes how the middleboxes behave during the base		may also identify the middleboxes.
	exchange.
	4.1. HIP Base Exchange with NAT		2. Registration, end host registers with the middlebox in order to
			inform the middlebox to relay its traffic.
	Figure 1 shows the HIP base exchange traversing a NAT.		3. Keep-alive, end host maintains the NAT registration by sending
			heart-beat messages.
			4. Messaging, end host receives the solicited traffic.
			HIP hosts can also make use of such procedures by binding their HITs
			(static identifier) with the middlebox to be connected, anywhere.
			Evidently, this requires the HIP hosts to perform a explicit
			registration mechanism with the middleboxes.
			HIP also provides a way to deal with legacy NATs, as described in
			[I-D.nikander-hip-path]. To support this functionality, it is
			necessary to provide UDP encapsulation for both HIP signaling and
			IPsec packets. Legacy NAT traversal does not require NATs to be HIP
			aware or to understand the HIP message exchange.
			4. HIP with Middleboxes
			This section describes the message exchange between the Initiator and
			the Responder, in which some of them situated behind a middlebox.
			Curently, this document explains the interaction of middlebox with
			plain HIP base exchange and the HIP base exchange carrying ESP
			payloads. However, this draft can also be extended to support other
			mechanisms for data traffic protection.
			4.1. HIP Base Exchange with middleboxes
			Assume that the initiator starts the HIP base exchange, Figure 1
			shows the HIP base exchange traversing a middlebox. Note that if a
			host wants to be contacted by the other peers, it needs some other
			mechanisms to signal its public address to the peers and, if
			necessary, should also inform the middlebox to allow the peers.
			I1 +-----+ I1
			+-------------------->| |----------------------+
			| | | |
			| | | |
			R1 | | R1 v
			+---------+ <-------------| |<---------------- +---------+
			|Initiator| I2 | | I2 |Responder|
			+---------+ ------------->| |----------------> +---------+
			^ | | |
			| | | |
			| R2 | | R2 |
			+---------------------| |<----------------------+
			+-----+
			Middlebox
			Figure 1: HIP Base Exchange and middleboxes
			Subsequently, the HIP base exchange is depicted in more detail.
			I -> R: I1: Trigger exchange
			I <- R: R1: (Puzzle, {D-H(R), HI(R), HIP Transform})SIG
			I -> R: I2: {Solution, LSI(I),D-H(I),
			HIP Transform, {H(I)}SK }SIG
			I <- R: R2: {LSI(R), HMAC}SIG
			Here, the base exchange becomes vulnerable to a DoS attack (for the
			middleboxes) because the initiator's HI is encrypted in the I2 packet
			and the middleboxes are unable to verify the I2 message. As a
			consequence, an attacker may send spoofed I2 messages before the
			authentic initiator does that.
			When HIP is used with HIP-aware NAT devices, the checksum, computed
			over the source and destination address, in the IP header must be
			recomputed. Additionally, it might be necessary to include support
			for storing the respective HITs and host identities.
			4.2. HIP Base Exchange with ESP Parameters and Middleboxes
			This section explains the HIP base exchange, carrying ESP parameters,
			together with the middleboxes and describes how the middleboxes
			behave during the base exchange. Figure 3 shows the corresponding
			message exchange traversing a middlebox.
	I1 +-----------+ I1		I1 +-----------+ I1
	+-------------------->| |----------------------+		+-------------------->| |----------------------+
	| | | |		| | | |
	| | | |		| | | |
	R1 | Intercept | R1 v		R1 | Intercept | R1 v
	+---------+ <-------------| the flow |<---------------- +---------+		+---------+ <-------------| the flow |<---------------- +---------+
	|Initiator| I2 | identifer | I2 |Responder|		|Initiator| I2 | identifer | I2 |Responder|
	+---------+ ------------->| <Dest IP, |----------------> +---------+		+---------+ ------------->| <Dest IP, |----------------> +---------+
	^ | SPI,ESP> |		^ | SPI,ESP> |
	| | | |		| | | |
	| R2 | | R2 |		| R2 | | R2 |
	+---------------------| |<----------------------+		+---------------------| |<----------------------+
	+-----------+		+-----------+
	NAT		middlebox
	Figure 1: NAT and HIP Base Exchange		Figure 3: ESP Transport Format with HIP Base Exchange and Middleboxes
	Subsequently, the HIP base exchange is described in more detail.		Subsequently, the HIP with ESP exchange is described in more detail.
	I -> R: I1: Trigger exchange		I -> R: I1: Trigger exchange
	I <- R: R1: {Puzzle, D-H(R), HI(R), ESP Transform,		I <- R: R1: {Puzzle, D-H(R), HI(R), ESP Transform,
	HIP Transform }SIG		HIP Transform }SIG
	I -> R: I2: {Solution, LSI(I), ESP_info(I), D-H(I),		I -> R: I2: {Solution, LSI(I), ESP_info(I), D-H(I),
	ESP_Transform, HIP Transform, {H(I)}SK }SIG		ESP_Transform, HIP Transform, {H(I)}SK }SIG
	I <- R: R2: {LSI(R), ESP_info(R), HMAC}SIG		I <- R: R2: {LSI(R), ESP_info(R), HMAC}SIG
	A potential responsibility of the NAT, as shown in Figure 1, can be		A potential responsibility of the middlebox, as shown in Figure 3,
	the following		can be the following
	o Intercept the signaling messages		o Intercept the signaling messages
	o Authenticate and authorize the HIP nodes by verifying the		o Authenticate and authorize the HIP nodes by verifying the
	signatures.		signatures.
	o Process the flow identifier information		o Process the flow identifier information
	o Perform actions according to the state machine		o Perform actions according to the state machine
	o Create state based on the content of message I2 with ESP_info(I)		o Create state based on the content of message I2 with ESP_info(I)
	and R2 with ESP_info(R). Additionally, it might be necessary to		and R2 with ESP_info(R). Additionally, it might be necessary to
	include support for storing the respective HITs and host		include support for storing the respective HITs and host
	identities.		identities.
	4.2. HIP Base Exchange with Firewall		The middleboxes should participate in the signaling messages and has
			to learn the flow identifier to pass the subsequent data traffic.
	In case of a firewall traversal, the routing asymmetry needs to be		Here, together with the spoofed I2 message, an attacker may send a
	considered i.e., the fact that the messages I1 and I2 do not		bogus SPI value, which will result in an inconsistent state at
	necessarily traverse the same devices as R1 and R2. The same is true		NAT/FW.
	with more complex network topologies with a mixture of NATs and
	Firewalls. This is an assumption made in the NSIS working group (and
	therefore also with NAT/Firewall traversal). Pure NAT traversal is
	therefore simpler to handle in comparison to middlebox traversal
	which also includes devices such as Firewalls. Figure 3 shows this
	circumstance graphically:
	I1 +----------+ I1		4.3. HIP Mobility/Multihoming Exchange with Middleboxes
	+--------------------> | Firewall | -----------------------+
	| I2 | 1 | I2 |
	| +-----------------> | | ------------------+ |
	| | +----------+ v v
	+---------+ +---------+
	|Initiator| |Responder|
	+---------+ +---------+
	^ ^ R1 +----------+ R1 | |
	| +------------------ | Firewall | <-------------------+ |
	| R2 | 2 | R2 |
	+--------------------- | | <-----------------------+
	+----------+
	............... IPsec ESP protected traffic (SPI(R)).........>		This section explains the HIP mobility and multihoming extensions for
	<.............. IPsec ESP protected traffic (SPI(I))..........		the HIP hosts [I-D.ietf-hip-mm] together with the middleboxes.
			Assume that the initiator moves after the base exchange and wants to
			inform the responder. During this procedure, the Initiator wants to
			start the rekeying proceudre in order to establish new keys.
			Figure 5 shows the mobility message exchange, traversing a middlebox.
			Note that this draft explains only one possible exchange for
			mobility, [I-D.ietf-hip-mm] provides a detailed message exchange for
			other variants such as rekeying initiated by responder.
	Legend:		+-----+ UPDATE SEQ
	--- = HIP signaling		+----------> | |--------------------------------------+
	... = IPsec protected data traffic		| | | UPDATE ACK |
			| +------ | |---------------------------------+ |
			| | | | | |
			| v | | | v
			+---------+ | | +---------+
			|Initiator| | | |Responder|
			+---------+ | | +---------+
			| | | ^
			| | | ACK |
			+------ | |----------------------------------+
			| |
			+-----+
			middlebox
	Figure 3: Firewall and HIP Base Exchange		Figure 5: HIP Mobility Exchange with Middleboxee
	With one single NAT between the HIP nodes, all messages of the base		Subsequently, the HIP mobility exchange is depicted below.
	exchange are forced through it. With firewalls, it becomes obvious
	that the nice property of a NAT with respect to the symmetric
	forwarding path is lost and the individual firewalls (Firewall 1 and
	Firewall 2) are unable to create the necessary firewall pinholes.
	SPI(I) is exchanged in I2 message (ESP_info(I)) through firewall 1,
	however firewall 2 only needs it. Similarly firewall 2 needs SPI (R)
	which is sent in message R2 (ESP_info(I)) through firewall 1.
	5. Scenarios		I -> R:UPDATE SEQ (ESP_INFO(I), LOCATOR, [DIFFIE_HELLMAN], SEQ)
	The following section describes some sample scenarios, in the context		I <- R:UPDATE ACK (ESP_INFO(R), SEQ, ACK,
	of involving middleboxes, to learn the flow identifier:		[DIFFIE_HELLMAN], ECHO_REQUEST)
	5.1. Same Firewall at Initiator for both outgoing and incoming packets		I -> R:ACK (ACK, ECHO_RESPONSE)
	This scenario assumes that the initiator I alone is behind a firewall		In such cases, a middlebox should,
	named FW(I). This firewall is both for the outgoing and incoming
	packets and hence can look into all the base exchange messages. This
	scenario is also applicable for NATs as well. This is illustrated in
	Figure 4
	FW(I)		o Intercept the HIP mobility messages
	I1 +-----+ I1
	+----------> | |--------------------------------------+
	| I2 | | I2 |
	| +-----> | |---------------------------------+ |
	| | | | | |
	| | | | v v
	---------+ | | +--------+
	Initiator| | | |Receiver|
	---------+ | | +--------+
	^ ^ | |
	| | R2 | | R2 | |
	| +------ | |< --------------------------------+ |
	| R1 | | R1 |
	+---------- | |< -------------------------------------+
	+-----+
	Figure 4: One FW only at initiator end		o Authenticate and authorize the HIP nodes by verifying the
			signatures
	1. I1 packet is sent from the initiator I to receiver R.		o Process the flow identifier information and perform actions
			according to the state machine
	2. FW(I) forward the packet to the Receiver.		o Update the location of the initiator based on the "LOCATOR
			parameter" in the UPDATE messages, also in case of rekeying, the
			middlebox should update the state based on the information in the
			ESP_info parameter, together with the respective HITs and host
			identities
	3. R sends R1 message with puzzle,D-H key protected with the		The problem with the mobilty exchange, when the host is behind a NAT,
	signature of R.		is that the address in the LOCATOR parameter is a private address and
			not globally routable.
	4. FW(I) forward the packet to the Initiator.		[Editor's Note: Some possible solutions, to overcome this problem,
			are to use RVS server as a contact point, initiator should find the
			public address and somehow has to inform it to the responder and the
			NAT has to bind the new private address and the public address.]
	5. On receiving I2, FW(I) verifies the signature of I and learns the		In case of multihoming scenario, in which the hosts can be reached by
	SPI value form the ESP_info parameter and forwards it to the		several addresses, the NAT handling becomes complicated. For
	Receiver		example, if a host is multihomed, assume that the initial HIP and
			security associations are established with a public IP address of the
			host. Later, if it decides to use the address which is behind a NAT,
			then the "new" NAT has to create a binding between the hosts.
	6. R sends the message R2 to I.		+---------+ 1. Base Exchange +---------+
			|Initiator|<------------------------------------->|Responder|
			+---------+ +---------+
			^ ^
			| +------+ |
			| 2. Update | NAT | 2. Update |
			+-------------------->| |----------------------+
			+------+
			Intercept the flow id
	7. On receiving R2, FW(I) verifies the signature of R. Accordingly,		Figure 7: Multihoming and Middleboxes
	it earns the SPI value form the ESP_info parameter and forwards
	it to the Initiator.
	8. The base exchange continues until complete. Since all messages		Figure 7 depicts the one possible scenario in which the initiator is
	I1,R1,I2 and R2 traverse through FW(I), it can look into these		multihomed.
	messages to learn the flow identifier information.
	5.2. Different Firewalls at Initiator for outgoing and incoming packets		1. If the Initiator notices the change, it can update the new
			address by using "Locator" parameter in the UPDATE messages (or
			can inform the NAT). By this way, a NAT can create a new binding
			by intercepting the UPDATE messages.
	This scenario assumes that both the initiator I and the receiver R is		2. If the Responder itself decides to send the traffic to the
			previously exchanged address (informed as alternative address),
			then the NAT will disrupt the connection, since it does not have
			necessary state information to handle the traffic. A more
			detailed analysis, about multihoming, will be done in the future
			version of this draft.
			5. Scenarios
			The following section describes some sample scenarios, in the context
			of involving middleboxes, to learn the flow identifier:
			5.1. Different Firewalls at Initiator for outgoing and incoming packets
			This scenario assumes that both the initiator I and the responderR is
	situated behind firewalls named FW(I) and FW(R) respectively. FW(I)		situated behind firewalls named FW(I) and FW(R) respectively. FW(I)
	is for the incoming packets to I and FW(R) is for the incoming		is for the incoming packets to I and FW(R) is for the incoming
	packets to R. It is necessary that both the firewalls must learn the		packets to R. It is necessary that both the firewalls must learn the
	flow identifier information and should store the state <SPI,IP,HIT>		flow identifier information and should store the state <SPI,IP,HIT>
	to forward IPsec protected payload packets. This scenario is		to forward IPsec protected payload packets. This scenario is
	illustrated in Figure 5		illustrated in Figure 8
	FW(R)		I1 +----------+ I1
	I1 +-----+ I1		+--------------------> | Firewall | -----------------------+
	+------------------------>| |--------+		| I2 | FW(R) | I2 |
	| I2 | | I2 |		| +-----------------> | | ------------------+ |
	| +------------------->| |---+ |		| | +----------+ v v
	| | +-----+ | |		+---------+ +---------+
	| | v v		|Initiator| |Responder|
	+---------+ +--------+		+---------+ +---------+
	|Initiator| |Receiver|		^ ^ R1 +----------+ R1 | |
	+---------+ FW(I) +--------+		| +------------------ | Firewall | <-------------------+ |
	^ ^ +-----+ | |		| R2 | FW(I) | R2 |
	| | R2 | | R2 | |		+--------------------- | | <-----------------------+
	| +--------| |<--------------+ |		+----------+
	| R1 | | R1 |
	+------------| |<-------------------+
	+-----+
	Figure 5: End hosts behind FWs		............... IPsec ESP protected traffic (SPI(R)).........>
			<.............. IPsec ESP protected traffic (SPI(I))..........
	1. I1 packet is sent from the initiator I to receiver R.		Legend:
			--- = HIP signaling
			... = IPsec protected data traffic
	2. FW(R) forwards the packet to the Receiver.		Figure 8: End hosts behind FWs
			1. I1 packet is sent from the initiator I to responder R.
			2. FW(R) forwards the packet to the Responder.
	3. Then, R sends R1 message with puzzle,D-H key protected with the		3. Then, R sends R1 message with puzzle,D-H key protected with the
	signature of R.		signature of R.
	4. FW(I) forward the packet to the Initiator.		4. FW(I) forward the packet to the Initiator.
	5. Now, I sends the I2 packet, on receiving I2, FW(R) verifies the		5. Now, I sends the I2 packet, on receiving I2, FW(R) verifies the
	signature of I and learns the SPI value form the ESP_info		signature of I and learns the SPI value form the ESP_info
	parameter and forwards it to the Receiver		parameter and forwards it to the Responder
	6. To complete the base exchange, R sends the message R2 to I.		6. To complete the base exchange, R sends the message R2 to I.
	7. On receiving R2, FW(I) verifies the signature of R. Accordingly,		7. On receiving R2, FW(I) verifies the signature of R. Accordingly,
	it earns the SPI value from the ESP_info parameter and forwards		it earns the SPI value from the ESP_info parameter and forwards
	it to the Initiator.		it to the Initiator.
	Here, the problem with this asymmetric base exchange is that the SPI		Here, the problem with this asymmetric base exchange is that the SPI
	needed for the FW(I) is sent through the I2 message, which flows		needed for the FW(I) is sent through the I2 message, which flows
	through the FW(R) and the SPI needed for for the FW(I) is sent to		through the FW(R) and the SPI needed for for the FW(I) is sent to
	FW(R).		FW(R).
	5.3. Different Firewalls at Initiator and Receiver		The topology shown in Figure 8 shows a scenario where messages R1/R2
			are traversed by middlebox FW(I) and messages I1/I2 traverse
			middlebox FW(R). These scenarios might be found in larger networks
			with routing asymmetry and multi-homed networks. Today, in many
			cases a state synchronization protocol is used between these two
			middleboxes to make them apear as a single device and therefore
			avoiding problems.
	This scenario looks into a more complicated situation. Initiator I		A solution for dealing with NAT traversal is simpler compared to
	is behind multiple firewalls FW1(I) for outgoing packets and FW2(I)		firewall traversal. With one single NAT between the HIP nodes, all
	and FW3(I) are for incoming packets. Similarly, receiver R is behind		messages of the base exchange are forced to pass through it. With
	FW1(R) and FW2(R) for incoming packets and FW3(R) for outgoing		firewalls, it becomes obvious that the nice property of a NAT with
	packets. The incoming firewalls are chosen based on the type of the		respect to the symmetric forwarding path is lost and here the
	application and the hosts are unaware from which firewall they		individual firewalls are unable to create the necessary firewall
	receive packets. Here, however for our scenario we assume that		pinholes. SPI(I) is exchanged in I2 message (ESP_info(I)) through
	FW2(R) and FW2(I) are chosen about which also the hosts are unaware		firewall 1, however firewall 2 only needs it. Similarly firewall 2
	of. This scenario is illustrated in Figure 6		needs SPI (R) which is sent in message R2 (ESP_info(I)) through
	+-----+		firewall 1.
	| |
	|FW1-R|
	| |
	+-----+ +-----+
	I1 | | I1 +-----+
	+------------| | -------------------> | |---------+
	| I2 |FW1-I| I2 |FW2-R| |
	| +-------| | -------------------> | |----+ |
	| | | | +-----+ | |
	| | +-----+ v v
	+---------+ +--------+
	|Initiator| |Receiver|
	+---------+ +--------+
	^ ^ +-----+
	| | R2 | | R2 +-----+ | |
	| +------ |FW2-I| <--------------------| |-----+ |
	| R1 | | R1 |FW3-R| |
	+---------- | | <--------------------| |----------+
	+-----+ | |
	+-----+ | |
	| | +-----+
	|FW3-I|
	| |
	+-----+
	Figure 6: Multiple FWs at initiator's and receiver's end		Hence, problems related with routing asymmetry and firewall traversal
			are :
	1. I1 packet is sent from the initiator I to receiver R.		1. When hosts are behind multiple incoming firewalls, they are
			unable to decide to which firewall they have to signal the
			appropriate SPI values.
	2. FW1(I) and FW2(R) forwards the packet to the Receiver.		2. The second problem is to secure the SPI signalling message from
			the end host to the FW. Since the end hosts authenticate and
			authorize to the FW that lets outgoing packets, they share keys
			only with them. However, as mentioned earlier, they, somehow,
			need to signal the SPI value to the FW on the other end which
			forwards incoming packets.
	3. Then, R sends R1 message with puzzle,D-H key protected with the		5.2. Data Receiver behind a NAT
	signature of R.
	4. Now, FW3(R) and FW2(I) forward the packet to the Initiator.		This scenario explains the full operation during the HIP base
			exchange between the Initiator and the Responder, where the Responder
			is assumed to be situated behind a NAT and registered with the
			rendevous server (RVS) to facilitate its reachability.
	5. Now, the I sends the I2 packet, on receiving I2, FW1(I) and		-------
	FW2(R) can verify the signature of I and can learn the SPI value		/// \\\
	from the ESP_info parameter and forward it to the Receiver.		1. DNS Look Up | |
			+--------------> DNS
			| | |
			| +-----------\\\ ///
			| | ------- 1'. Registration
			| | +------------------------+
			| | | |
			| | | |
			| |2. IP_RVS,HIT_R | |
			| | v |
			| | +-----+ +-----+ |
			| | |RVS | | | |
			| v +----->| +->| | |
			++--------+ 3. I1 | +-----+ | | 3.'I1 +---------+
			| +-----------+ | +---------->| |
			|Initiator| | | |Responder|
			| | 4. Base Exchg | NAT | | |
			+---------+ <-------------------------+-----+---------> +--+------+
			| | |
			| |1''.Registration |
			| |<----------------+
			+-----+
	6. To complete the base exchange, R sends the message R2 to I.		Figure 9: HIP Responder with RVS and NAT
	7. On receiving R2, FW3(R) and FW2(I) can verify the signature of R.		Figure 9 shows the pictorial representaton of the operation.
	Accordingly, they learn the SPI value form the ESP_info parameter
	and forwards it to the Initiator.
	Here, the problems are :		o Initiator looks up the DNS in order to find the connection
			parameters for the responder, This is typically done by querying
			the DNS with the corresponding FQDN.
	1. With this asymmetric base exchange is that the SPI needed for the		o Since the responder is registerd with the RVS, the DNS record will
	Firewall(s) on the receiver side is sent through the I2 message,		contain the IP of the RVS and the HIT of the responder.
	Which is actually sent through FW1(I) and FW2(R) and the SPI
	needed for for the Firewall(s) on the Initiator side is sent to
	FW3(R) and FW2(I).
	2. When hosts are behind multiple incoming firewalls, there are		o The Initiator, now, contacts the RVS by sending I1 message, the
	unable to decide to which firewall they have to inform their SPI		RVS relays the message to the responder. If the responder is
	values to.		situated behind a NAT, it must inform the NAT, beforehand, to
			allow the HIP base exchange packets to be traversed via the NAT.
	3. The second problem is to secure the SPI signalling message from		This typically requires a registration mechanism to siganl the
	the end host to the FW. Since the end hosts authenticate and		NAT.
	authorize to the FW that lets outgoing packets, they share keys
	only with them. However, as mentioned earlier, they, somehow,
	need to signal the SPI value to the FW on the other end which
	forwards incoming packets.
	6. Requirements		o The NAT forwards the HIP packets and actively participates in the
			base exchange. If ESP traffic information is exchanged, the
			middlebox will also learn the flow identifier.
	In the context of middlebox signaling, a few high-level requirements		Here, the NAT might require authentication and authorization from the
	have to be accomplished:		endhosts in order to enable a NAT binding for the requesting hosts.
			This can be done achieved by performing middlebox signaling, the
			requirements for such solution is explained in Section 6.
	o Add some authentication and authorization capabilities to NAT		6. Requirements for HIP Middlebox Solution
	traversal. Many NAT/Firewall traversal solutions do not allow the
	end host to interact with the middlebox. As a consequence, some		This section presents a few high-level requirements that are derived
	security vulnerabilities are introduced.		from the given problem statement. A novel middlebox signaling
			approach has to accomplish the following goals:
			o Add some authentication and authorization capabilities to the NAT/
			Firewall traversal. Many NAT/Firewall traversal solutions do not
			allow the end host to interact with the middlebox. As a
			consequence, some security vulnerabilities are introduced
			e.g.,denial of service.
	o Add secure firewall traversal functionality as another type of		o Add secure firewall traversal functionality as another type of
	middlebox signaling by using <destination IP address, SPI and		middlebox signaling by using <destination IP address, SPI and
	protocol> triplet. as a substitute for the typical < source IP,		protocol> triplet. as a substitute for the traditional < source
	destination IP, source port, destination port, transport protocol>		IP, destination IP, source port, destination port, transport
	information.		protocol> information.
	Such a solution for HIP-based middlebox signaling needs to have the		It is recommended that a solution for HIP-aware middlebox signaling
	following properties:		needs to have the following properties:
	o A HIP-aware NAT/FW MUST be able to authenticate the entity		o A HIP-aware NAT/FW MUST be able to authenticate the entity
	requesting a NAT binding or a firewall pinhole.		requesting a NAT binding or a firewall pinhole.
			o A HIP-aware NAT/FW MUST be able to intercept HIP messages in order
			to extract the flow identifier information and other related
			information. A HIP-aware NAT/FW MUST be able to distinguish these
			messages.
	o A HIP-aware NAT/FW MUST authorize the entity requesting a NAT		o A HIP-aware NAT/FW MUST authorize the entity requesting a NAT
	binding or a firewall pinhole before storing state information.		binding or a firewall pinhole before storing state information.
	This requirement might be accomplished by identity based		This requirement might be accomplished by identity based
	authorization or an identity independent authorization mechanism.		authorization or an identity independent authorization mechanism.
	o A HIP-aware NAT/FW MUST be able to intercept HIP messages in order		o A NAT/FW node MUST NOT introduce denial of service attacks.
	to extract the flow identifier information and other related
	information. HIP messages are base exchange messages during
	context establishment and readdressing messages during IP address
	changes. A NAT/FW MUST be able to distinguish these messages.
	o A NAT/FW node MUST NOT introduce new denial of service attacks
	based on authentication or key management mechanisms.
	o A potential solution MUST respect the property of some middleboxes		o A potential solution MUST respect the property of some middleboxes
	which do not allow traffic (data and signaling traffic) to		which do not allow traffic (data and signaling traffic) to
	traverse this middlebox without proper authorization.		traverse the middlebox without proper authorization.
	Some requirements are taken from [I-D.ietf-nsis-nslp-natfw].		Some requirements are taken from [I-D.ietf-nsis-nslp-natfw].
	7. Security Considerations		7. Security Considerations
	This document analyzes the traversal of HIP-aware middleboxes. A		In this document, a problem statement is given and scenarios are
	problem statement is given and scenarios are described that lead to a		described that lead to a number of requirements, which focusses on
	number of requirements.		security at a higher level of abstraction. However, this document
			does not perform a detailed security analysis for a HIP-aware
			middlebox solution.
	This document therefore lists a number of security aspects throughout		The authors recommend that, atmost care should be taken when
	the document. Care should be taken when solutions are developed and		solutions are developed and the solution must not introduce new
	the security solution must not introduce new vulnerabilities to the		security vulnerabilities to the middlebox.
	middlebox.
	8. Contributors		8. Contributors
	We would like to thank Aarthi Nagarajan, Vesa Torvinen, Jochen		We would like to thank Aarthi Nagarajan, Vesa Torvinen, Jochen
	Grimminger and Jukka Ylitalo for their help with initial versions of		Grimminger and Jukka Ylitalo for their help with initial versions of
	this document.		this document.
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank Pekka Nikander, Dieter Gollmann and		The authors would like to thank Pekka Nikander, Dieter Gollmann and
	Thomas Aura for their feedback to this document.		Tuomas Aura for their feedback to this document.
	This document is a byproduct of the Ambient Networks Project,		This document is a byproduct of the Ambient Networks Project,
	partially funded by the European Commission under its Sixth Framework		partially funded by the European Commission under its Sixth Framework
	Programme. It is provided "as is" and without any express or implied		Programme. It is provided "as is" and without any express or implied
	warranties, including, without limitation, the implied warranties of		warranties, including, without limitation, the implied warranties of
	fitness for a particular purpose. The views and conclusions		fitness for a particular purpose. The views and conclusions
	contained herein are those of the authors and should not be		contained herein are those of the authors and should not be
	interpreted as necessarily representing the official policies or		interpreted as necessarily representing the official policies or
	endorsements, either expressed or implied, of the Ambient Networks		endorsements, either expressed or implied, of the Ambient Networks
	Project or the European Commission.		Project or the European Commission.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-HIP-esp]
	Moskowitz, R., Nikander, P., and P. Jokela, "Using ESP
	transport format with HIP", draft-ietf-hip-esp-00 (work in
	progress), June 2005.
	[I-D.ietf-hip-base]		[I-D.ietf-hip-base]
	Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,		Moskowitz, R., "Host Identity Protocol",
	"Host Identity Protocol", draft-ietf-hip-base-03 (work in		draft-ietf-hip-base-05 (work in progress), March 2006.
	progress), June 2005.
			[I-D.ietf-hip-esp]
			Jokela, P., "Using ESP transport format with HIP",
			draft-ietf-hip-esp-02 (work in progress), March 2006.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", March 1997.		Requirement Levels", March 1997.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-ipsec-ikev2]		[I-D.ietf-hip-arch]
	Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		Moskowitz, R. and P. Nikander, "Host Identity Protocol
	draft-ietf-ipsec-ikev2-17 (work in progress),		Architecture", draft-ietf-hip-arch-03 (work in progress),
	September 2004.		August 2005.
			[I-D.ietf-hip-mm]
			Nikander, P., "End-Host Mobility and Multihoming with the
			Host Identity Protocol", draft-ietf-hip-mm-03 (work in
			progress), March 2006.
	[I-D.ietf-nsis-nslp-natfw]		[I-D.ietf-nsis-nslp-natfw]
	Stiemerling, M., Tschofenig, H., and C. Aoun, "A NAT/		Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
	Firewall NSIS Signaling Layer Protocol (NSLP)",		Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in
	draft-ietf-nsis-nslp-natfw-07 (work in progress),		progress), February 2006.
	July 2005.
	[I-D.irtf-hiprg-nat]		[I-D.irtf-hiprg-nat]
	Stiemerling, M., Quittek, J., and L. Eggert, "Middlebox		Stiemerling, M., "Middlebox Traversal Issues of Host
	Traversal Issues of Host Identity Protocol (HIP)		Identity Protocol (HIP) Communication",
	Communication", draft-irtf-hiprg-nat-00.txt (work in		draft-irtf-hiprg-nat-01 (work in progress), January 2006.
	progress) (work in progress), October 2005.
	[NATTerminology]		[I-D.nikander-hip-path]
	Srisuresh, P. and M. Holdrege, "IP Network Address		Nikander, P., "Preferred Alternatives for Tunnelling HIP
	Translator (NAT) Terminology and Considerations", Request		(PATH)", draft-nikander-hip-path-00 (work in progress),
	For Comments RFC 2663, August 1999.		February 2005.
	[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the		[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
	Internet Protocol", RFC 2401, November 1998.		Internet Protocol", RFC 2401, November 1998.
			[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
			Translator (NAT) Terminology and Considerations",
			RFC 2663, August 1999.
	[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network		[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
	Address Translator (Traditional NAT)", RFC 3022,		Address Translator (Traditional NAT)", RFC 3022,
	January 2001.		January 2001.
			[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
			(NAT) Compatibility Requirements", RFC 3715, March 2004.
	[RFC3947] Kivinen, T., A. Huttunen, A., Swander, B., and V. Volpe,		[RFC3947] Kivinen, T., A. Huttunen, A., Swander, B., and V. Volpe,
	"Negotiation of NAT-Traversal in the IKE", RFC 3947,		"Negotiation of NAT-Traversal in the IKE", RFC 3947,
	January 2005.		January 2005.
	[RFC3948] A. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and		[RFC3948] A. Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
	M. Stenberg, "UDP Encapsulation of IPsec Packets",		M. Stenberg, "UDP Encapsulation of IPsec Packets",
	RFC 3948, January 2005.		RFC 3948, January 2005.
	[RFC4080] Hancock, R., "Next Steps in Signaling: Framework",		[RFC4080] Hancock, R., "Next Steps in Signaling: Framework",
	RFC 4080, November 2004.		RFC 4080, November 2004.
	[draft-ietf-hip-mm]		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	Henderson (Editor), T., "End-Host Mobility and Multi-		RFC RFC4303, December 2005.
	Homing with Host Identity Protocol",
	draft-nikander-hip-mm-02.txt (work in progress) (work in
	progress), July 2005.
	[draft-ietf-ipsec-esp-v3-08]
	Kent, S., "IP Encapsulating Security Payload (ESP)",
	draft-ietf-ipsec-esp-v3-10 (work in progress) (work in
	progress), March 2005.
	[draft-moskowitz-hip-arch]
	Moskowitz, R. and P. Nikander, "Host Identity Protocol
	Architecture", draft-ietf-hip-arch-03 (work in progress)
	(work in progress), August 2005.
	[draft-nikander-hip-path-00.txt]
	Nikander, P., Tschofenig, H., Henderson, T., Eggert, L.,
	and J. Laganier, "Preferred Alternatives for Tunnelling
	HIP (PATH)", draft-nikander-hip-path-00.txt (work in
	progress) (work in progress), February 2005.
	[rfc3022] Srisuresh, P. and K. Egevang, "Traditional IP Network		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	Address Translator (Traditional NAT)", Request For		RFC 3948, September 2004.
	Comments RFC 3022, January 2001.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens AG
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	Murugaraj Shanmugam		Murugaraj Shanmugam
	Technical Univeristy Hamburg-Harburg		Siemens AG
	Schwarzenbergstrasse 95		Otto-Hahn-Ring 6
	Harburg, Hamburg 21073		Munich, Bayern 81739
	Germany		Germany
	Email: murugaraj.shanmugam@tuhh.de		Email: murugaraj.shanmugam@siemens.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 22, line 41 ¶		skipping to change at page 24, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 96 change blocks.
	368 lines changed or deleted		478 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/