< draft-tschofenig-hiprg-hip-natfw-traversal-04.txt		draft-tschofenig-hiprg-hip-natfw-traversal-05.txt >
	HIPRG H. Tschofenig		HIPRG H. Tschofenig
	Internet-Draft M. Shanmugam		Internet-Draft M. Shanmugam
	Expires: September 7, 2006 Siemens AG		Intended status: Informational Siemens Networks GmbH & Co KG
	March 6, 2006		Expires: April 26, 2007 October 23, 2006
	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-04.txt		draft-tschofenig-hiprg-hip-natfw-traversal-05.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 35 ¶		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 September 7, 2006.		This Internet-Draft will expire on April 26, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The Host Identity Protocol (HIP) is a signaling protocol, which		The Host Identity Protocol (HIP) is a signaling protocol, which
	supports mobility and multihoming by adding a new layer to the TCP/IP		supports mobility and multihoming by adding a new layer in the TCP/IP
	stack. By carring relevant parameters in the signaling messages, HIP		stack. By carring relevant parameters in the signaling messages, HIP
	can be used to establish IPsec encapsulating security payload (ESP)		can be used to establish IPsec encapsulating security payload (ESP)
	security associations between two hosts. Middleboxes (e.g. firewalls		security associations between two hosts. Middleboxes (e.g. firewalls
	and network address translators) cannot inspect transport layer		and network address translators) cannot inspect transport layer
	headers of data traffic if that traffic is sent over an IPsec ESP		headers of data traffic if that traffic is sent over an IPsec ESP
	tunnel. However, HIP is designed to be middlebox friendly; it		tunnel. However, HIP is designed to be middlebox friendly; it
	enables the middleboxes to inspect the signaling messages. The		enables the middleboxes to inspect the signaling messages. The
	information that they can derive from that messages enables the		information that they can derive from that messages enables the
	middleboxes to uniquely identify the subsequent data flows, e.g. for		middleboxes to uniquely identify the subsequent data flows, e.g. for
	the purposes of multiplexing and demultiplexing . A middlebox that		the purposes of multiplexing and demultiplexing . A middlebox that
	implements the relevant mechanisms is called "HIP-aware". This		implements the relevant mechanisms is called "HIP-aware". This
	document presents a problem statement and lists some requirements		document presents a problem statement and lists some requirements
	that are necessary for a HIP-aware middlebox traversal technique.		that are necessary for a HIP-aware middlebox traversal technique.
	These include authentication and authorization of signaling end-hosts		These include authentication and authorization of signaling end-hosts
	by the middleboxes. Such authorization will help the middleboxes to		by the middleboxes. Such authorization will help the middleboxes to
	decide whether or not an end host is allowed to traverse, and can		decide whether or not an end host is allowed to traverse, and can
	potentially limit unwanted traffic.		potentially limit unwanted traffic.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
	4. HIP with Middleboxes . . . . . . . . . . . . . . . . . . . . . 8		4. HIP with Middleboxes . . . . . . . . . . . . . . . . . . . . . 9
	4.1. HIP Base Exchange with middleboxes . . . . . . . . . . . . 8		4.1. HIP Base Exchange with middleboxes . . . . . . . . . . . . 9
	4.2. HIP Base Exchange with ESP Parameters and Middleboxes . . 9		4.2. HIP Base Exchange with ESP Parameters and Middleboxes . . 10
	4.3. HIP Mobility/Multihoming Exchange with Middleboxes . . . . 10		4.3. HIP Mobility/Multihoming Exchange with Middleboxes . . . . 11
	5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1. Different Firewalls at Initiator for outgoing and		5.1. Different Firewalls at Initiator for outgoing and
	incoming packets . . . . . . . . . . . . . . . . . . . . . 13		incoming packets . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Data Receiver behind a NAT . . . . . . . . . . . . . . . . 15		5.2. Data Receiver behind a NAT . . . . . . . . . . . . . . . . 16
	6. Requirements for HIP Middlebox Solution . . . . . . . . . . . 17		6. Requirements for HIP Middlebox Solution . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 21		10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
	10.2. Informative References . . . . . . . . . . . . . . . . . . 21		10.2. Informative References . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	Intellectual Property and Copyright Statements . . . . . . . . . . 24		Intellectual Property and Copyright Statements . . . . . . . . . . 25
	1. Introduction		1. Introduction
	In the current Internet architecture, an IP address is used to locate		In the current Internet architecture, an IP address is used to locate
	and to identify a host, termed as "locator" and "identifier"		and to identify a host, termed as "locator" and "identifier"
	respectively. Hosts that move and change their IP addresses are said		respectively. Hosts that move and change their IP addresses are said
	to be mobile and those that prefer to be addressed with multiple IPs		to be mobile and those that prefer to be addressed with multiple IPs
	at a given time are said to be multihomed. Mobility and Multihoming		at a given time are said to be multihomed. Mobility and Multihoming
	are together expressed as Multiaddressing. When hosts use IP		are together expressed as Multiaddressing. When hosts use IP
	addresses for communication, all transport connections are bound to		addresses for communication, all transport connections are bound to
	skipping to change at page 5, line 11 ¶		skipping to change at page 6, line 11 ¶
	together with the middleboxes, Section 5 discusses possible scenarios		together with the middleboxes, Section 5 discusses possible scenarios
	and Section 6 discusses the requirements and properties for a HIP-		and Section 6 discusses the requirements and properties for a HIP-
	aware middlebox solution.		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 [RFC2663], [I-D.ietf-hip-		This draft used the terminology defined in [RFC2663],
	base], [I-D.ietf-hip-esp] and [I-D.ietf-hip-arch] and [RFC2401].		[I-D.ietf-hip-base], [I-D.ietf-hip-esp] and [RFC4423] 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
	skipping to change at page 6, line 15 ¶		skipping to change at page 7, line 15 ¶
	3. Problem Statement		3. Problem Statement
	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.
	Typically, NATs use <src IP ,dst IP, src port, dst port, protocol> as		Typically, NATs use <src IP ,dst IP, src port, dst port, protocol> as
	an flow identifier to identify a particular traffic or connection.		a flow identifier to identify a particular traffic or connection.
	Because of this, protocols like IPsec suffers from well-known NAT		Because of this, protocols like IPsec suffers from well-known NAT
	related problems[RFC3715]. The NAT traversal approaches described in		related problems [RFC3715] (middleboxes cannot inspect the port
	[RFC3947] and [RFC4306] allows the end hosts to detect one or more		numbers, when the packets are IPsec-ESP protected). To work around
	NATs in between them and [RFC3948] proposes to use the UDP		IPsec-NAT problems several approaches have been discussed, e.g., the
	encapsulation of IPsec ESP packets to traverse NATs.		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 encapsulation of IPsec ESP packets
			to traverse NATs.
	If HIP uses IPsec protection for the data traffic then the flow		If HIP uses IPsec protection for the data traffic then the flow
	identifier will take the shape of <destination IP address, SPI and		identifier will take the shape of <destination IP address, SPI and
	ESP>. Although HIP is described as a two-party protocol, middle		ESP> in order to facilitate the middlebox traversal. Note that the
	boxes are supposed to intercept the base exchange messages to learn		flow identifier used here is one possible example and used throughout
	the flow identifier and to process them correctly. In other words, a		the document, however it could be possible to have other variants of
	multi party protocol is created such that the flow identifier is		flow identitier as well. Although HIP is described as a two-party
	available to middle boxes between the HIP hosts. To achieve this,		protocol, middle boxes are supposed to intercept the base exchange
	HIP aims to interact with middleboxes actively whereby these devices		messages to learn the flow identifier and to process them correctly.
	need to understand the HIP protocol and they need to be involved in		In other words, a multi party protocol is created such that the flow
	the protocol exchange.		identifier is available to middle boxes between the HIP hosts. To
			achieve this, HIP aims to interact with middleboxes actively whereby
			these devices need to understand the HIP protocol and they need to be
			involved in the protocol exchange.
	This interaction, obviously, requires the middleboxes to verify the		This interaction, obviously, requires the middleboxes to verify the
	authenticity of the base exchange messages in order to learn the flow		authenticity of the base exchange messages in order to learn the flow
	identifier and to create a state i.e., NAT binding or a pinhole. In		identifier and to create a state i.e., NAT binding or a pinhole. In
	this context, to provide proper security, middleboxes should not be		this context, to provide proper security, middleboxes should not be
	vulnerable to denial of service attacks and might want to		vulnerable to denial of service attacks and might want to
	authenticate or authorize entities before creating state information.		authenticate or authorize entities before creating state information.
	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.
	Finally, End hosts, behind middleboxes especially NATs, require the		Additionally, End hosts behind middleboxes, especially NATs, require
	following steps to facilitate its reachability.		the following steps to facilitate its reachability.
	1. Connection, end host connects to the server, while doing that it		1. Connection, end host connects to the server, while doing that it
	may also identify the middleboxes.		may also identify the middleboxes.
	2. Registration, end host registers with the middlebox in order to		2. Registration, end host registers with the middlebox in order to
	inform the middlebox to relay its traffic.		inform the middlebox to relay its traffic.
	3. Keep-alive, end host maintains the NAT registration by sending		3. Keep-alive, end host maintains the NAT registration by sending
	heart-beat messages.		heart-beat messages.
	skipping to change at page 8, line 7 ¶		skipping to change at page 9, line 7 ¶
	registration mechanism with the middleboxes.		registration mechanism with the middleboxes.
	HIP also provides a way to deal with legacy NATs, as described in		HIP also provides a way to deal with legacy NATs, as described in
	[I-D.nikander-hip-path]. To support this functionality, it is		[I-D.nikander-hip-path]. To support this functionality, it is
	necessary to provide UDP encapsulation for both HIP signaling and		necessary to provide UDP encapsulation for both HIP signaling and
	IPsec packets. Legacy NAT traversal does not require NATs to be HIP		IPsec packets. Legacy NAT traversal does not require NATs to be HIP
	aware or to understand the HIP message exchange.		aware or to understand the HIP message exchange.
	4. HIP with Middleboxes		4. HIP with Middleboxes
	This section describes the message exchange between the Initiator and		This section describes some sample message exchanges between the
	the Responder, in which some of them situated behind a middlebox.		Initiator and the Responder, in which some of them situated behind a
	Curently, this document explains the interaction of middlebox with		middlebox. Curently, this document explains the interaction of
	plain HIP base exchange and the HIP base exchange carrying ESP		middlebox with plain HIP base exchange and the HIP base exchange
	payloads. However, this draft can also be extended to support other		carrying ESP payloads. However, this draft can also be extended to
	mechanisms for data traffic protection.		support other mechanisms.
	4.1. HIP Base Exchange with middleboxes		4.1. HIP Base Exchange with middleboxes
	Assume that the initiator starts the HIP base exchange, Figure 1		Assume that the initiator starts the HIP base exchange, Figure 1
	shows the HIP base exchange traversing a middlebox. Note that if a		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		host wants to be contacted by the other peers, it needs some other
	mechanisms to signal its public address to the peers and, if		mechanisms to signal its public address to the peers and, if
	necessary, should also inform the middlebox to allow the peers.		necessary, should also inform the middlebox to allow the peers.
	I1 +-----+ I1		I1 +-----+ I1
	skipping to change at page 8, line 37 ¶		skipping to change at page 9, line 37 ¶
	+---------+ <-------------| |<---------------- +---------+		+---------+ <-------------| |<---------------- +---------+
	|Initiator| I2 | | I2 |Responder|		|Initiator| I2 | | I2 |Responder|
	+---------+ ------------->| |----------------> +---------+		+---------+ ------------->| |----------------> +---------+
	^ | | |		^ | | |
	| | | |		| | | |
	| R2 | | R2 |		| R2 | | R2 |
	+---------------------| |<----------------------+		+---------------------| |<----------------------+
	+-----+		+-----+
	Middlebox		Middlebox
	Figure 1: HIP Base Exchange and middleboxes		Figure 1: HIP Base Exchange and middleboxes
	Subsequently, the HIP base exchange is depicted in more detail.		Subsequently, the HIP base exchange is depicted in more detail.
	I -> R: I1: Trigger exchange		I -> R: I1: Trigger exchange
	I <- R: R1: (Puzzle, {D-H(R), HI(R), HIP Transform})SIG		I <- R: R1: (Puzzle, {D-H(R), HI(R), HIP Transform})SIG
	I -> R: I2: {Solution, LSI(I),D-H(I),		I -> R: I2: {Solution, LSI(I),D-H(I),
	HIP Transform, {H(I)}SK }SIG		HIP Transform, {H(I)}SK }SIG
	skipping to change at page 9, line 17 ¶		skipping to change at page 10, line 17 ¶
	authentic initiator does that.		authentic initiator does that.
	When HIP is used with HIP-aware NAT devices, the checksum, computed		When HIP is used with HIP-aware NAT devices, the checksum, computed
	over the source and destination address, in the IP header must be		over the source and destination address, in the IP header must be
	recomputed. Additionally, it might be necessary to include support		recomputed. Additionally, it might be necessary to include support
	for storing the respective HITs and host identities.		for storing the respective HITs and host identities.
	4.2. HIP Base Exchange with ESP Parameters and Middleboxes		4.2. HIP Base Exchange with ESP Parameters and Middleboxes
	This section explains the HIP base exchange, carrying ESP parameters,		This section explains the HIP base exchange, carrying ESP parameters,
	together with the middleboxes and describes how the middleboxes		together with the middleboxes and describes how the middleboxes may
	behave during the base exchange. Figure 3 shows the corresponding		behave during the base exchange. Figure 3 shows the corresponding
	message exchange traversing a middlebox.		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|
	skipping to change at page 10, line 35 ¶		skipping to change at page 11, line 35 ¶
	Here, together with the spoofed I2 message, an attacker may send a		Here, together with the spoofed I2 message, an attacker may send a
	bogus SPI value, which will result in an inconsistent state at		bogus SPI value, which will result in an inconsistent state at
	NAT/FW.		NAT/FW.
	4.3. HIP Mobility/Multihoming Exchange with Middleboxes		4.3. HIP Mobility/Multihoming Exchange with Middleboxes
	This section explains the HIP mobility and multihoming extensions for		This section explains the HIP mobility and multihoming extensions for
	the HIP hosts [I-D.ietf-hip-mm] together with the middleboxes.		the HIP hosts [I-D.ietf-hip-mm] together with the middleboxes.
	Assume that the initiator moves after the base exchange and wants to		Assume that the initiator moves after the base exchange and wants to
	inform the responder. During this procedure, the Initiator wants to		inform the responder. During this procedure, the Initiator wants to
	start the rekeying proceudre in order to establish new keys.		start the rekeying procedure in order to establish new keys.
	Figure 5 shows the mobility message exchange, traversing a middlebox.		Figure 5 shows the mobility message exchange, traversing a middlebox.
	Note that this draft explains only one possible exchange for		Note that this draft explains only one possible exchange for
	mobility, [I-D.ietf-hip-mm] provides a detailed message exchange for		mobility, [I-D.ietf-hip-mm] provides a detailed message exchange for
	other variants such as rekeying initiated by responder.		other variants such as rekeying initiated by responder.
	+-----+ UPDATE SEQ		+-----+ UPDATE SEQ
	+----------> | |--------------------------------------+		+----------> | |--------------------------------------+
	| | | UPDATE ACK |		| | | UPDATE ACK |
	| +------ | |---------------------------------+ |		| +------ | |---------------------------------+ |
	| | | | | |		| | | | | |
	skipping to change at page 11, line 21 ¶		skipping to change at page 12, line 21 ¶
	+---------+ | | +---------+		+---------+ | | +---------+
	|Initiator| | | |Responder|		|Initiator| | | |Responder|
	+---------+ | | +---------+		+---------+ | | +---------+
	| | | ^		| | | ^
	| | | ACK |		| | | ACK |
	+------ | |----------------------------------+		+------ | |----------------------------------+
	| |		| |
	+-----+		+-----+
	middlebox		middlebox
	Figure 5: HIP Mobility Exchange with Middleboxee		Figure 5: HIP Mobility Exchange with Middleboxee
	Subsequently, the HIP mobility exchange is depicted below.		Subsequently, the HIP mobility exchange is depicted below.
	I -> R:UPDATE SEQ (ESP_INFO(I), LOCATOR, [DIFFIE_HELLMAN], SEQ)		I -> R:UPDATE SEQ (ESP_INFO(I), LOCATOR, [DIFFIE_HELLMAN], SEQ)
	I <- R:UPDATE ACK (ESP_INFO(R), SEQ, ACK,		I <- R:UPDATE ACK (ESP_INFO(R), SEQ, ACK,
	[DIFFIE_HELLMAN], ECHO_REQUEST)		[DIFFIE_HELLMAN], ECHO_REQUEST)
	I -> R:ACK (ACK, ECHO_RESPONSE)		I -> R:ACK (ACK, ECHO_RESPONSE)
	skipping to change at page 12, line 27 ¶		skipping to change at page 13, line 27 ¶
	+---------+ 1. Base Exchange +---------+		+---------+ 1. Base Exchange +---------+
	|Initiator|<------------------------------------->|Responder|		|Initiator|<------------------------------------->|Responder|
	+---------+ +---------+		+---------+ +---------+
	^ ^		^ ^
	| +------+ |		| +------+ |
	| 2. Update | NAT | 2. Update |		| 2. Update | NAT | 2. Update |
	+-------------------->| |----------------------+		+-------------------->| |----------------------+
	+------+		+------+
	Intercept the flow id		Intercept the flow id
	Figure 7: Multihoming and Middleboxes		Figure 7: Multihoming and Middleboxes
	Figure 7 depicts the one possible scenario in which the initiator is		Figure 7 depicts the one possible scenario in which the initiator is
	multihomed.		multihomed.
	1. If the Initiator notices the change, it can update the new		1. If the Initiator notices the change, it can update the new
	address by using "Locator" parameter in the UPDATE messages (or		address by using "Locator" parameter in the UPDATE messages (or
	can inform the NAT). By this way, a NAT can create a new binding		can inform the NAT). By this way, a NAT can create a new binding
	by intercepting the UPDATE messages.		by intercepting the UPDATE messages.
	2. If the Responder itself decides to send the traffic to the		2. If the Responder itself decides to send the traffic to the
	previously exchanged address (informed as alternative address),		previously exchanged address (informed as alternative address),
	then the NAT will disrupt the connection, since it does not have		then the NAT will disrupt the connection, since it does not have
	necessary state information to handle the traffic. A more		necessary state information to handle the traffic. A more
	detailed analysis, about multihoming, will be done in the future		detailed analysis, about multihoming, will be done in the future
	version of this draft.		version of this draft.
	5. Scenarios		5. Scenarios
	The following section describes some sample scenarios, in the context		The following section describes some example scenarios, in the
	of involving middleboxes, to learn the flow identifier:		context of involving middleboxes, to learn the flow identifier:
	5.1. Different Firewalls at Initiator for outgoing and incoming packets		5.1. Different Firewalls at Initiator for outgoing and incoming packets
	This scenario assumes that both the initiator I and the responderR is		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 8		illustrated in Figure 8
	skipping to change at page 13, line 41 ¶		skipping to change at page 14, line 41 ¶
	+--------------------- | | <-----------------------+		+--------------------- | | <-----------------------+
	+----------+		+----------+
	............... IPsec ESP protected traffic (SPI(R)).........>		............... IPsec ESP protected traffic (SPI(R)).........>
	<.............. IPsec ESP protected traffic (SPI(I))..........		<.............. IPsec ESP protected traffic (SPI(I))..........
	Legend:		Legend:
	--- = HIP signaling		--- = HIP signaling
	... = IPsec protected data traffic		... = IPsec protected data traffic
	Figure 8: End hosts behind FWs		Figure 8: End hosts behind FWs
	1. I1 packet is sent from the initiator I to responder R.		1. I1 packet is sent from the initiator I to responder R.
	2. FW(R) forwards the packet to the Responder.		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.
	skipping to change at page 15, line 37 ¶		skipping to change at page 16, line 37 ¶
	++--------+ 3. I1 | +-----+ | | 3.'I1 +---------+		++--------+ 3. I1 | +-----+ | | 3.'I1 +---------+
	| +-----------+ | +---------->| |		| +-----------+ | +---------->| |
	|Initiator| | | |Responder|		|Initiator| | | |Responder|
	| | 4. Base Exchg | NAT | | |		| | 4. Base Exchg | NAT | | |
	+---------+ <-------------------------+-----+---------> +--+------+		+---------+ <-------------------------+-----+---------> +--+------+
	| | |		| | |
	| |1''.Registration |		| |1''.Registration |
	| |<----------------+		| |<----------------+
	+-----+		+-----+
	Figure 9: HIP Responder with RVS and NAT		Figure 9: HIP Responder with RVS and NAT
	Figure 9 shows the pictorial representaton of the operation.		Figure 9 shows the pictorial representaton of the operation.
	o Initiator looks up the DNS in order to find the connection		o Initiator looks up the DNS in order to find the connection
	parameters for the responder, This is typically done by querying		parameters for the responder, This is typically done by querying
	the DNS with the corresponding FQDN.		the DNS with the corresponding FQDN.
	o Since the responder is registerd with the RVS, the DNS record will		o Since the responder is registerd with the RVS, the DNS record will
	contain the IP of the RVS and the HIT of the responder.		contain the IP of the RVS and the HIT of the responder.
	skipping to change at page 21, line 11 ¶		skipping to change at page 22, line 11 ¶
	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-base]		[I-D.ietf-hip-base]
	Moskowitz, R., "Host Identity Protocol",		Moskowitz, R., "Host Identity Protocol",
	draft-ietf-hip-base-05 (work in progress), March 2006.		draft-ietf-hip-base-06 (work in progress), June 2006.
	[I-D.ietf-hip-esp]		[I-D.ietf-hip-esp]
	Jokela, P., "Using ESP transport format with HIP",		Jokela, P., "Using ESP transport format with HIP",
	draft-ietf-hip-esp-02 (work in progress), March 2006.		draft-ietf-hip-esp-04 (work in progress), October 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-hip-arch]
	Moskowitz, R. and P. Nikander, "Host Identity Protocol
	Architecture", draft-ietf-hip-arch-03 (work in progress),
	August 2005.
	[I-D.ietf-hip-mm]		[I-D.ietf-hip-mm]
	Nikander, P., "End-Host Mobility and Multihoming with the		Nikander, P., "End-Host Mobility and Multihoming with the
	Host Identity Protocol", draft-ietf-hip-mm-03 (work in		Host Identity Protocol", draft-ietf-hip-mm-04 (work in
	progress), March 2006.		progress), June 2006.
	[I-D.ietf-nsis-nslp-natfw]		[I-D.ietf-nsis-nslp-natfw]
	Stiemerling, M., "NAT/Firewall NSIS Signaling Layer		Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
	Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in		Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-12 (work in
	progress), February 2006.		progress), June 2006.
	[I-D.irtf-hiprg-nat]		[I-D.irtf-hiprg-nat]
	Stiemerling, M., "Middlebox Traversal Issues of Host		Stiemerling, M., "NAT and Firewall Traversal Issues of
	Identity Protocol (HIP) Communication",		Host Identity Protocol (HIP) Communication",
	draft-irtf-hiprg-nat-01 (work in progress), January 2006.		draft-irtf-hiprg-nat-03 (work in progress), June 2006.
	[I-D.nikander-hip-path]		[I-D.nikander-hip-path]
	Nikander, P., "Preferred Alternatives for Tunnelling HIP		Nikander, P., "Preferred Alternatives for Tunnelling HIP
	(PATH)", draft-nikander-hip-path-00 (work in progress),		(PATH)", draft-nikander-hip-path-01 (work in progress),
	February 2005.		March 2006.
	[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		[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
	Translator (NAT) Terminology and Considerations",		Translator (NAT) Terminology and Considerations",
	RFC 2663, August 1999.		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,
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 25 ¶
	[RFC4080] Hancock, R., "Next Steps in Signaling: Framework",		[RFC4080] Hancock, R., "Next Steps in Signaling: Framework",
	RFC 4080, November 2004.		RFC 4080, November 2004.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC RFC4303, December 2005.		RFC RFC4303, December 2005.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 3948, September 2004.		RFC 3948, September 2004.
			[RFC4423] Moskowitz, R. and P. Nikandar, "Host Identity Protocol
			(HIP) Architecture", RFC RFC4423, May 2006.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Siemens AG		Siemens Networks GmbH & Co KG
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bavaria 81739
	Germany		Germany
			Phone: +49 89 636 40390
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
			URI: http://www.tschofenig.com
	Murugaraj Shanmugam		Murugaraj Shanmugam
	Siemens AG		Siemens Networks GmbH & Co KG
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	Email: murugaraj.shanmugam@siemens.com		Email: murugaraj.shanmugam@siemens.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The Internet Society (2006).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 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.
			Intellectual Property
	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
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 24, line 29 ¶		skipping to change at page 25, line 45 ¶
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 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.
	Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	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 provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 36 change blocks.
	92 lines changed or deleted		98 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/