< draft-tschofenig-hiprg-hip-natfw-traversal-00.txt		draft-tschofenig-hiprg-hip-natfw-traversal-01.txt >
	HIPRG H. Tschofenig		HIPRG H. Tschofenig
	Internet-Draft A. Nagarajan		Internet-Draft A. Nagarajan
	Expires: April 18, 2005 Siemens		Expires: August 25, 2005 Siemens
	V. Torvinen		V. Torvinen
	J. Ylitalo		J. Ylitalo
	Ericsson		Ericsson
	J. Grimminger		M. Shanmugam
	Siemens		Siemens
	October 18, 2004		February 21, 2005
	NAT and Firewall Traversal for HIP		NAT and Firewall Traversal for HIP
	draft-tschofenig-hiprg-hip-natfw-traversal-00.txt		draft-tschofenig-hiprg-hip-natfw-traversal-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any 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 become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		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 18, 2005.		This Internet-Draft will expire on August 25, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	The Host Identity Protocol is a signaling protocol which adds another		The Host Identity Protocol is a signaling protocol which adds another
	layer to the Internet model and establishes IPsec ESP SAs to protect		layer to the Internet model and establishes IPsec ESP SAs to protect
	subsequent data traffic. HIP also aims to interwork with middleboxes		subsequent data traffic. HIP also aims to interwork with middleboxes
	(such as NATs and Firewalls). This document investigates this aspect		(such as NATs and Firewalls). This document investigates this aspect
	in more detail.		in more detail.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
	4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Solution Approach . . . . . . . . . . . . . . . . . . . . . . 9		4.1 Same Firewall at Initiator for both outgoing and
	5.1 Flow identifier interception . . . . . . . . . . . . . . . 9		incoming packets . . . . . . . . . . . . . . . . . . . . . 8
	5.2 Sender Invariance . . . . . . . . . . . . . . . . . . . . 10		4.2 Different Firewalls at Initiator for outgoing and
	5.3 Authentication and Authorization . . . . . . . . . . . . . 11		incoming packets . . . . . . . . . . . . . . . . . . . . . 9
	5.3.1 What is SPKI? . . . . . . . . . . . . . . . . . . . . 11		4.3 Different Firewalls at Initiator and Receiver . . . . . . 11
	5.3.2 SAML Usage in HIP . . . . . . . . . . . . . . . . . . 12		5. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.3.3 SPKI usage for HIP . . . . . . . . . . . . . . . . . . 14		6. Solution Approach . . . . . . . . . . . . . . . . . . . . . . 15
	5.3.4 Authentication and authorization for Base Exchange . . 15		6.1 Flow identifier interception . . . . . . . . . . . . . . . 15
	5.3.5 Authentication and authorization for Readdressing . . 18		6.2 Sender Invariance . . . . . . . . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 21		6.3 Authentication and Authorization . . . . . . . . . . . . . 17
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22		6.3.1 What is SPKI? . . . . . . . . . . . . . . . . . . . . 17
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		6.3.2 SAML Usage in HIP . . . . . . . . . . . . . . . . . . 18
	8.1 Normative References . . . . . . . . . . . . . . . . . . . . 23		6.3.3 SPKI usage for HIP . . . . . . . . . . . . . . . . . . 20
	8.2 Informative References . . . . . . . . . . . . . . . . . . . 23		6.3.4 Authentication and authorization for Base Exchange . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25		6.3.5 Authentication and authorization for Readdressing . . 24
	A. Same FW at Initiator for both outgoing and incoming packets . 26		7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	B. Different FWs at Initiator for outgoing and incoming		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
	packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	C. Different Firewalls at Initiator and Receiver . . . . . . . . 30		9.1 Normative References . . . . . . . . . . . . . . . . . . . 29
	Intellectual Property and Copyright Statements . . . . . . . . 33		9.2 Informative References . . . . . . . . . . . . . . . . . . 29
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
			Intellectual Property and Copyright Statements . . . . . . . . 32
	1. Introduction		1. Introduction
	An IP address serves the dual role of a locator and an identifier for		An IP address serves the dual role of a locator and an identifier for
	every host on the Internet. End systems that use IP addresses as		every host on the Internet. End systems that use IP addresses as
	identifiers cannot support dynamic changes in the mapping between the		identifiers cannot support dynamic changes in the mapping between the
	identifier and the locator in case of multi-homing and mobility.		identifier and the locator in case of multi-homing and mobility.
	The Host Identity Protocol (HIP) [I-D.ietf-hip-base] proposes to		The Host Identity Protocol (HIP) [1] proposes to separate the
	separate the identifier from the locator by adding an additional		identifier from the locator by adding an additional layer between the
	layer between the transport layer and the network layer. The		transport layer and the network layer. The transport layer uses a
	transport layer uses a new, mobility-unrelated identifier, Host		new, mobility-unrelated identifier, Host Identity Tags (HITs), in
	Identity Tags (HITs), in place of IP addresses, while the network		place of IP addresses, while the network layer uses conventional IP
	layer uses conventional IP addresses. IPsec security associations		addresses. IPsec security associations are bound to the HITs and are
	are bound to the HITs and are not modified with IP address changes.		not modified with IP address changes. In other words, a host despite
	In other words, a host despite being mobile or multi-homed can use a		being mobile or multi-homed can use a single transport layer
	single transport layer connection associated to one HIT and multiple		connection associated to one HIT and multiple IP addresses.
	IP addresses.
	One of the integral features of HIP is a protocol to establish IPsec		One of the integral features of HIP protocol is, it establishes IPsec
	ESP which are subsequently used to encrypt data traffic between the		ESP which are subsequently used to encrypt data traffic between the
	two end hosts. HIP being a mobility protocol also supports changes		two end hosts. HIP being a mobility protocol also supports changes
	in IP addresses. Because of this, HIP is liable to all known		in IP addresses. Because of this, HIP is liable to all known
	incompatibilities of IPsec with middleboxes as NATs [RFC3022] and		incompatibilities of IPsec with middleboxes as NATs [3] and
	firewalls. This draft investigates problems with the HIP protocol		firewalls. This draft investigates problems with the HIP protocol
	when supporting the secure traversal of NATs and Firewalls.		when supporting the secure traversal of NATs and Firewalls.
	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 [2].
	This draft used the terminology defined in [NATTerminology],		This draft used the terminology defined in [4], [1] and [5] and [6].
	[I-D.ietf-hip-base] and [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) which is then used		IPsec packets. The initiator selects one SPI(I) which is then used
	by the responder to create an IPsec packet (ESP packet in this case)		by the responder to create an IPsec packet (ESP packet in this case)
	for traffic sent to the initiator. The responder selects one SPI(R)		for traffic sent to the initiator. The responder selects one SPI(R)
	which is used by the initiator to encrypt all data sent to the		which is used by the initiator to encrypt all data sent to the
	responder.		responder.
	Other relevant abbreviations can be found in [I-D.ietf-hip-base].		Other relevant abbreviations can be found in [1].
	The concept of a flow identifier is described in [I-D.ietf-nsis-fw].		The concept of a flow identifier is described in [7].
	3. Problem Statement		3. Problem Statement
	HIP, as defined in [I-D.ietf-hip-base], does not deal with NATs in		This version of the document assumes that the data traffic following
	the classical way as proposed in [I-D.ietf-ipsec-nat-t-ike] for IKEv1		the HIP base exchange is IPsec protected. Besides the communicating
	and [I-D.ietf-ipsec-ikev2] for IKEv2. The NAT traversal approach		hosts, the entities such as NATs and Firewalls play a major role to
	described in [I-D.ietf-ipsec-nat-t-ike] and [I-D.ietf-ipsec-ikev2]		allow the packets to traverse through them. The NAT traversal
	allows the NAT to be detected and IPsec protected packets to		approach described in [8] and [9] allows the NAT to be detected and
	experience UDP encapsulation (see also [I-D.ietf-ipsec-udp-encaps]		IPsec protected packets to experience UDP encapsulation (see also
	with regard to UDP encapsulation). HIP aims to interact with		[10] with regard to UDP encapsulation). HIP also provides a way to
	middleboxes (and NATs).		deal with legacy NATs, as described in [11]. 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. HIP, however, 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.
	In the context of middlebox signaling a few goals can be		In the context of middlebox signaling a few goals can be
	accomplished:		accomplished:
	o The UDP encapsulation could be avoided to allow the NAT to use the
	<destination IP address, SPI and protocol> triplet. The change of
	an end hosts IP address requires this triplet to be updated. As
	such it also provides a micro-mobility solution.
	o Add some authentication and authorization capabilities to NAT		o Add some authentication and authorization capabilities to NAT
	traversal. Many NAT traversal solutions today do not provide		traversal. Many NAT/Firewall traversal solutions do not allow the
	security at all.		end host to interact with the middlebox. As a consequence, some
			security vulnerabilities are introduced.
	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 typical < source IP,
	destination IP, source port, destination port, transport protocol>		destination IP, source port, destination port, transport protocol>
	information.		information.
	The HIP protocol is a signaling protocol that carries (what NSIS		The HIP protocol is a signaling protocol that carries (what NSIS
	calls a flow identifier) inside the signaling protocol payloads.		calls a flow identifier) inside the signaling protocol payloads.
	Since HIP uses IPsec ESP to encrypt all its payload messages, the		Since HIP uses IPsec ESP to encrypt all its payload messages, the
	flow identifier takes the shape of a <destination IP address, SPI and		flow identifier takes the shape of a <destination IP address, SPI and
	ESP>. Although HIP is described as a two-party protocol, middle		ESP>. Although HIP is described as a two-party protocol, middle
	boxes are supposed to intercept these messages in order to learn the		boxes are supposed to intercept these messages in order to learn the
	flow identifier and to process them correctly. In other words, a		flow identifier and to process them correctly. In other words, a
	multi party protocol is created such that the flow identifier is		multi party protocol is created such that the flow identifier is
	available to middle boxes between the HIP hosts. To provide proper		available to middle boxes between the HIP hosts. To provide proper
	security middleboxes should not be subject to denial of service		security, middleboxes should not be subject to denial of service
	attacks and might want to authenticate or authorize entities which		attacks and might want to authenticate or authorize entities which
	create state. Note that the IPsec SA is unidirectional and therefore		create state. Note that the IPsec SA is unidirectional and therefore
	two IPsec SAs (with two different SPIs) have to be established.		two IPsec SAs (with two different SPIs) have to be established.
	Figure 1 shows the HIP base exchange traversing a NAT.		Figure 1 shows the HIP base exchange traversing a NAT.
	I1 +-----------+ I1		I1 +-----------+ I1
	+-------------------->| |----------------------+		+-------------------->| |----------------------+
	| | | |		| | | |
	| | | |		| | | |
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	With one single NAT between the HIP nodes, all messages of the base		With one single NAT between the HIP nodes, all messages of the base
	exchange are forced through it. With firewalls, it becomes obvious		exchange are forced through it. With firewalls, it becomes obvious
	that the nice property of a NAT with respect to the symmetric		that the nice property of a NAT with respect to the symmetric
	forwarding path is lost and the individual firewalls (Firewall 1 and		forwarding path is lost and the individual firewalls (Firewall 1 and
	Firewall 2) are unable to create the necessary firewall pinholes.		Firewall 2) are unable to create the necessary firewall pinholes.
	SPI(I) is exchanged in I2 message through firewall 1, however		SPI(I) is exchanged in I2 message through firewall 1, however
	firewall 2 only needs it. Similarly firewall 2 needs SPI (R) which		firewall 2 only needs it. Similarly firewall 2 needs SPI (R) which
	is sent in message R2 through firewall 1.		is sent in message R2 through firewall 1.
	4. Goals		4. Scenarios
			The following section describes some sample scenarios and the
			possible solutions to learn the flow identifier:
			4.1 Same Firewall at Initiator for both outgoing and incoming packets
			This scenario assumes that the initiator I alone is behind a firewall
			named FW(I). This firewall is both for the outgoing and incoming
			packets and hence can look into all the base exchange messages. The
			FW(I) is expected to authenticate and authorize the initiator to send
			out going packets, receiver if necessary to let incoming packets and
			intercept the flow identifier from the base exchange. With the E2M
			messages, it can be achieved as follows. This is illustrated in
			Figure 4
			FW(I)
			I1 +-----+ I1
			+----------> | |--------------------------------------+
			| I2 | | I2 |
			| +-----> | |---------------------------------+ |
			| | | | | |
			| | | | v v
			---------+ | | +--------+
			Initiator| | | |Receiver|
			---------+ | | +--------+
			^ ^ | |
			| | R2 | | R2 | |
			| +------ | |< --------------------------------+ |
			| R1 | | R1 |
			+---------- | |< -------------------------------------+
			+-----+
			Figure 4: One FW only at initiator end
			1. I1 packet is sent from the initiator I to receiver R.
			2. FW(I) drops the packet and sends a R1' message back to I. This
			is the End host-to-Middlebox or E2M message exchange initiation.
			3. I sends I2' message with CERT(I) parameters to FW(I). It
			requests the FW(I) to open up a pinhole.
			4. FW verifies SPKI certificate and the signature of I.
			Accordingly, it either sends a R2' to acknowledge I that it can
			continue with the base exchange with message I1 or drops packet
			if verification fails.
			5. On receiving R2',I sends message I1 to R again. Now the FW(I)
			will let the packet through.
			6. R sends the message R1 to I.
			7. On receiving R1, if FW(I) wishes to authenticate/authorize the
			receiver R, it should initiate E2M exchange here. It sends
			message R1'to R forcing R to send an I2' in exchange.
			8. R sends the CERT(R) parameter in I2'.
			9. FW verifies SPKI certificate and the signature of R.
			Accordingly, it either sends a R2' to acknowledge R that it can
			continue with the base exchange with message R1 or drops packet
			if verification fails.
			10. On receiving R2', R sends message R1 to I again. Now the FW(I)
			will let it through.
			11. The base exchange continues until complete. Since all messages
			I1,R1,I2 and R2 traverse through FW(I), it can look into these
			messages to learn the flow identifier information.
			4.2 Different Firewalls at Initiator for outgoing and incoming packets
			This scenario assumes that the initiator I alone is behind firewalls
			named FW1(I) and FW2(I).FW1(I) is for the incoming packets to I and
			FW2(I) is for the outgoing packets to R. The FW(I) is expected to
			authenticate and authorize the initiator to send out going packets,
			while FW2(I) would authenticate and authorize the receiver, if
			necessary to let incoming packets. It is sufficient that FW2(I)
			alone learns the flow identifier information of I. It should store
			the state <SPI(I),IP(I),HIT(I)> to forward IPsec protected payload
			packets. This scenario is illustrated in Figure 5
			FW1(I)
			I1 +-----+ I1
			+----------> | |--------------------------------------+
			| I2 | | I2 |
			| +-----> | |---------------------------------+ |
			| | +-----+ | |
			| | v v
			+---------+ +--------+
			|Initiator| |Receiver|
			+---------+ FW2(I) +--------+
			^ ^ +-----+
			| | R2 | | R2 | |
			| +------ | |< --------------------------------+ |
			| R1 | | R1 |
			+---------- | |< -------------------------------------+
			+-----+
			Figure 5: Two FWs at initiator's end
			1. I1 packet is sent from the initiator I to receiver R.
			2. FW1(I) drops the packet and sends a R1' message back to I. This
			is the E2M message exchange initiation.
			3. I sends I2' message with CERT(I) parameters to FW1(I). It
			requests the FW1(I) to open up a pinhole.
			4. FW1(I) verifies SPKI certificate and the signature of I.
			Accordingly, it either sends a R2' to acknowledge I that it can
			continue with the base exchange with message I1 or drops packet
			if verification fails.
			5. On receiving R2',I sends message I1 to R again. Now the FW1(I)
			will let the packet through.
			6. R sends the message R1 to I.
			7. On receiving R1, if FW2(I) wishes to authenticate/authorize the
			receiver R, it should initiate E2M exchange here. It sends
			message R1'to R forcing R to send an I2' in exchange.
			8. R sends the CERT(R) parameter in I2'.
			9. FW2(I) verifies SPKI certificate and the signature of R.
			Accordingly, it either sends a R2' to acknowledge R that it can
			continue with the base exchange with message R1 or drops packet
			if verification fails.
			10. On receiving R2', R sends message R1 to I again. Now the FW2(I)
			will let it through.
			11. Since FW2(I) needs the store the state, once the base exchange
			is complete, the initiator should inform the FW2(I) about the
			SPI it has chosen for the exchange. This way, FW2(I) can
			forward further IPsec payload packets from R to I
			4.3 Different Firewalls at Initiator and Receiver
			This scenario looks into a more complicated situation. Initiator I
			is behind multiple firewalls FW1(I) for outgoing packets and FW2(I)
			and FW3(I) are for incoming packets. Similarly, receiver R is behind
			FW1(R) and FW2(R) for incoming packets and FW3(R) for outgoing
			packets. The incoming firewalls are chosen based on the type of the
			application and the hosts are unaware from which firewall they
			receive packets. Here, however for our scenario we assume that
			FW2(R) and FW2(I) are chosen about which also the hosts are unaware
			of. The FW1(I) is expected to authenticate and authorize the
			initiator to send outgoing packets to R, while FW2(R) would
			authenticate and authorize the receiver to let outgoing packets to I.
			FW2(R) should store the state <SPI(R),IP(R),HIT(R)> for the receiver
			while FW2(I) should store the state <SPI(I),IP(I),HIT(I)> for the
			initiator. This scenario is illustrated in Figure 6
			+-----+
			| |
			|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
			1. I1 packet is sent from the initiator I to receiver R.
			2. FW1(I) drops the packet and sends a R1' message back to I. This
			is the E2M message exchange initiation.
			3. I sends I2' message with CERT(I) parameters to FW1(I). It
			requests the FW1(I) to open up a pinhole.
			4. FW1(I) verifies SPKI certificate and the signature of I.
			Accordingly, it either sends a R2' to acknowledge I that it can
			continue with the base exchange with message I1 or drops packet
			if verification fails.
			5. On receiving R2',I sends message I1 to R again. Now the FW1(I)
			will let the packet through.
			6. This packet would reach FW2(R). If this firewall wishes to
			authenticate and authorize the initiator I, then it can start a
			E2M exchange with I. After this is successfully completed,
			FW2(R) would open up a pinhole to send packets to R.
			7. R sends the message R1 to I.
			8. When R sends R1 to I, FW3(R) would initiate a E2M message to
			authenticate and authorize the receiver R. After this is
			complete, it will forward the packet to the initiator. On
			receiving R1, if FW2(I) wishes to authenticate/authorize the
			receiver R, it should initiate E2M exchange here.
			9. FW2(I) verifies SPKI certificate and the signature of R.
			Accordingly, it either sends a R2' to acknowledge R that it can
			continue with the base exchange with message R1 or drops packet
			if verification fails.
			10. On receiving R2', R sends message R1 to I again. Now the FW2(I)
			will let it through.
			11. This has completed only one round of authentication and
			authorization. However, the states are still not established at
			the firewalls. For this, the hosts have to signal their
			incoming firewalls about the SPI that they have chosen for IPsec
			ESP packets to follow.
			When hosts are behind multiple incoming firewalls, there are uble to
			decide to which firewall they have to inform their SPI values to.
			The first option would be to somehow make the chosen FW to signal the
			host about its requirement for a state to forward IPsec protected
			packets (similar to a pull model). This could be possibly done along
			with the first incoming packet which is R1. R1 packet could include
			extra signaling as record route to the initiator. The second option
			would be to inform firewall about the SPI values (like the push
			model). Here, however it would be necessary to send an extra message
			I3 from the initiator to the receiver which would include the SPI(I)
			for FW(I) and to resend the SPI(R) in I2 message for FW(R).
			The second problem is to secure the SPI signalling message from the
			end host to the FW. Since the endhosts authenticate and authorize to
			the FW that lets outgoing packets, they share keys only with them.
			However, they need to signal the SPI value to the FW on the other end
			which forwards incoming packets . For the sake of securing the SPI
			value, it might be necessary that the end hosts have to run a E2M
			exchange with the firewalls on the receiving end also.
			5. Goals
	The main goal of the draft is to find a suitable NAT/FW traversal		The main goal of the draft is to find a suitable NAT/FW traversal
	solution for the Host Identity Protocol. Such a solution for		solution for the Host Identity Protocol. Such a solution for
	HIP-based middlebox signaling has to provide the following		HIP-based middlebox signaling has to provide the following
	properties:		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 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
	skipping to change at page 8, line 28 ¶		skipping to change at page 14, line 28 ¶
	to extract the flow identifier information and other related		to extract the flow identifier information and other related
	information. HIP messages are base exchange messages during		information. HIP messages are base exchange messages during
	context establishment and readdressing messages during IP address		context establishment and readdressing messages during IP address
	changes. A NAT/FW MUST be able to distinguish these messages.		changes. A NAT/FW MUST be able to distinguish these messages.
	o A NAT/FW node MUST NOT introduce new denial of service attacks		o A NAT/FW node MUST NOT introduce new denial of service attacks
	based on authentication or key management mechanisms.		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 this middlebox without proper authorization.
	Some requirements are taken from [I-D.fessi-nsis-natfw-threats].		Some requirements are taken from [12].
	5. Solution Approach		6. Solution Approach
	5.1 Flow identifier interception		6.1 Flow identifier interception
	The most important issue with the HIP NAT/FW traversal is to make the		The most important issue with the HIP NAT/FW traversal is to make the
	flow identifier <destination IP address, SPI and ESP> available to		flow identifier <destination IP address, SPI and ESP> available to
	the middleboxes. In the presence of NATs, we are always sure that		the middleboxes. In the presence of NATs, we are always sure that
	the forward path and the backward path are same, since the NAT forces		the forward path and the backward path are same, since the NAT forces
	the IP packets to flow through these devices. Hence all the 4		the IP packets to flow through these devices. Hence all the 4
	messages I1, R1, I2 and R2 traverse through a single NAT. This makes		messages I1, R1, I2 and R2 traverse through a single NAT. This makes
	it possible for the NATs to intercept the messages for the relevant		it possible for the NATs to intercept the messages for the relevant
	flow identifier information. But, in the presence of firewalls,		flow identifier information. But, in the presence of firewalls,
	routing asymmetry has to be taken into consideration.		routing asymmetry has to be taken into consideration.
	To enable the firewalls intercept the correct mapping triplet < dest		To enable the firewalls intercept the correct mapping triplet < dest
	IP, SPI, ESP > certain values have to be resent with the base		IP, SPI, ESP > certain values have to be resent with the base
	exchange messages. This is illustrated in the Figure 4. While the		exchange messages. This is illustrated in the Figure 7. While the
	IP value of the flow identifier can be intercepted from the IP header		IP value of the flow identifier can be intercepted from the IP header
	of any base exchange message, the SPI value can be intercepted only		of any base exchange message, the SPI value can be intercepted only
	in messages I2 and R2. I generates its SPI(I) and sends it to R		in messages I2 and R2. I generates its SPI(I) and sends it to R
	through FW-R. However, FW-I needs this information to forward all		through FW-R. However, FW-I needs this information to forward all
	packets from R to I. Therefore there has to be someway FW-I can		packets from R to I. Therefore there has to be someway FW-I can
	learn this information. One possible method would be that message R2		learn this information. One possible method would be that message R2
	could include the SPI(I) value. However, changes to the base		could include the SPI(I) value. However, changes to the base
	exchange are not desired and we try to keep the base exchange		exchange are not desired and we try to keep the base exchange
	unaffected. The only other possibility would be that once the base		unaffected. The only other possibility would be that once the base
	exchange is complete, the HIP host I could inform the FW-I in its		exchange is complete, the HIP host I could inform the FW-I in its
	skipping to change at page 10, line 34 ¶		skipping to change at page 16, line 34 ¶
	| |		| |
	+-+		+-+
	FW-I FW-R		FW-I FW-R
	+-+ +-+		+-+ +-+
	5.SPI(I) | | | | 5.SPI(R)		5.SPI(I) | | | | 5.SPI(R)
	-------->| | | |<--------		-------->| | | |<--------
	| | | |		| | | |
	+-+ +-+		+-+ +-+
	Figure 4: Firewalls and mapping information during Base exchange		Figure 7: Firewalls and mapping information during Base exchange
	5.2 Sender Invariance		6.2 Sender Invariance
	The NAT/Firewall HIP node establishes state at possibly several		The NAT/Firewall HIP node establishes state at possibly several
	entities between the HIP Initiator and the HIP Responder. Providing		entities between the HIP Initiator and the HIP Responder. Providing
	authentication of the signaling initiator to each individual HIP node		authentication of the signaling initiator to each individual HIP node
	along the path might be possible but not particularly useful, since		along the path might be possible but not particularly useful, since
	the initiator is most likely unknown to some middlebox along the		the initiator is most likely unknown to some middlebox along the
	path. Hence, authentication per se does not solve the security		path. Hence, authentication per se does not solve the security
	problem.		problem.
	With mobility it might be possible that intermediate HIP-aware		With mobility, it might be possible that the intermediate HIP-aware
	middlebox need some assurance that a particular node is the allowed		middlebox need some assurance that a particular node is the allowed
	to modify existing state. No other entity should be allowed to		to modify existing state. No other entity should be allowed to
	modify state since this would allow certain attacks (such as denial		modify state since this would allow certain attacks (such as denial
	of service or third party flooding). In some respect this issue is		of service or third party flooding). In some respect this issue is
	similar to the authorization property in Mobile IP where the mobility		similar to the authorization property in Mobile IP where the mobility
	binding state established at the CN needs to be protected against		binding state established at the CN needs to be protected against
	unauthorized modifications.		unauthorized modifications.
	It seems that the property of "sender Invariance" is required in this		It seems that the property of "sender Invariance" is required in this
	case: "A party is assured that the source of the communication has		case: "A party is assured that the source of the communication has
	remained the same as the one that started the communication, although		remained the same as the one that started the communication, although
	the actual identity of the source is not important to the recipient."		the actual identity of the source is not important to the recipient."
	This property is particularly important in the context of mobility		This property is particularly important in the context of mobility
	which requires a change in the NAT binding or the packet filter. An		which requires a change in the NAT binding or the packet filter. An
	outline for solutions have been presented in		outline for solutions have been presented in [13]. SPINAT (see [14]
	[I-D.tschofenig-nsis-sid]. SPINAT (see [SPINAT] and [SPINAT1])		and [15]) provided innovative aspects by using a hash chain approach
	provided innovative aspects by using a hash chain approach in		in combination with delayed authorization to secure state
	combination with delayed authorization to secure state modifications		modifications at NAT devices.
	at NAT devices.
	A future version of this document will address the aspect of sender		A future version of this document will address the aspect of sender
	invariance in more details.		invariance in more details.
	5.3 Authentication and Authorization		6.3 Authentication and Authorization
	Before a middlebox can allocate a NAT binding or a pin hole, the HIP		Before a middlebox can allocate a NAT binding or a pin hole, the HIP
	nodes requesting them may need to be authenticated. Middleboxes		nodes requesting them may need to be authenticated. Middleboxes
	could potentially use information stored in the DNS to authenticate		could potentially use information stored in the DNS to authenticate
	the HIP end points. Since Host Identities are used to identify HIP		the HIP end points. Since Host Identities are used to identify HIP
	nodes, middleboxes can also use signature verification at relevant		nodes, middleboxes can also use signature verification at relevant
	HIP messages for authentication. This might raise some issues on		HIP messages for authentication. This might raise some issues on
	denial of service attacks at the middleboxes and these need to be		denial of service attacks at the middleboxes and these need to be
	determined. Authorization is certainly more important than		determined. Authorization is certainly more important than
	authentication particularly since HIP supports ephemeral host		authentication particularly since HIP supports ephemeral host
	identities as a mechanism to preserve privacy. As such it would be		identities as a mechanism to preserve privacy. As such it would be
	useful to use identity independent authorization assertions. SPKI		useful to use identity independent authorization assertions. SPKI
	certificates, attribute certificates or similar mechanisms could be		certificates, attribute certificates or similar mechanisms could be
	of particular use, especially in cases where the HIP nodes prefer to		of particular use, especially in cases where the HIP nodes prefer to
	remain anonymous.		remain anonymous.
	5.3.1 What is SPKI?		6.3.1 What is SPKI?
	SPKI authorization certificates are used in access control and are		SPKI authorization certificates are used in access control and are
	identity independent. Issuing and receiving an SPKI certificate is		identity independent. Issuing and receiving an SPKI certificate is
	completely local to the network domain and there is no need for a		completely local to the network domain and there is no need for a
	higher certification authority to issue them. For a HIP protocol		higher certification authority to issue them. For a HIP protocol
	this would mean whenever a HIP host wishes to create a NAT binding or		this would mean whenever a HIP host wishes to create a NAT binding or
	a FW pinhole, it can locally obtain the SPKI certificate for		a FW pinhole, it can locally obtain the SPKI certificate for
	authorization at middleboxes. The structure of the SPKI certificate		authorization at middleboxes. The structure of the SPKI certificate
	is shown in Figure 5.		is shown in Figure 8.
	+--------+---------+-----------------+		+--------+---------+-----------------+
	| Key 1 | Key 2 | |		| Key 1 | Key 2 | |
	| Issuer | Receiver| Can delegate ? |		| Issuer | Receiver| Can delegate ? |
	| | | |		| | | |
	+--------+---------+-----------------+		+--------+---------+-----------------+
	| |		| |
	| Rights |		| Rights |
	| |		| |
	+------------------------------------+		+------------------------------------+
	| |		| |
	| Dates |Certificate signed		| Dates |Certificate signed
	| |by issuer		| |by issuer
	+------------------------------------+		+------------------------------------+
	Figure 5: SPKI certificate structure		Figure 8: SPKI certificate structure
	o Key 1 is the public key of the certificate issuer.		o Key 1 is the public key of the certificate issuer.
	o Key 2 is the public key of the certificate receiver.		o Key 2 is the public key of the certificate receiver.
	o If a subject gets the right to re-delegate its rights, it can		o If a subject gets the right to re-delegate its rights, it can
	re-delegate its certificates to other subjects. In addition, he		re-delegate its certificates to other subjects. In addition, he
	can freely sign new certificates to other subjects.		can freely sign new certificates to other subjects.
	o Rights define access control of the receiver.		o Rights define access control of the receiver.
	o Dates define the validity period of the certificate.		o Dates define the validity period of the certificate.
	o The complete certificate is signed by the private key of the		o The complete certificate is signed by the private key of the
	issuer.		issuer.
	When a subject wishes to use his certificates, it sends a request		When a subject wishes to use his certificates, it sends a request
	that is signed by the subject's private key. Attached are a chain of		that is signed by the subject's private key. Attached are a chain of
	certificates that belong not only to it but also to those of its		certificates that belong not only to it but also to those of its
	delegates. When a verifier receives requests along with a chain of		delegates. When a verifier receives requests along with a chain of
	certificates from a subject, the verifier verifies the requests and		certificates from a subject, the verifier verifies the requests and
	the certificates. If the verifier is satisfied with the		the certificates. If the verifier is satisfied with the
	certificates, then the requested operation is allowed. Otherwise,		certificates, then the requested operation is allowed. Otherwise,
	the requests will be refused.		the requests will be refused.
	5.3.2 SAML Usage in HIP		6.3.2 SAML Usage in HIP
	Security Assertion Markup Language (SAML)		Security Assertion Markup Language (SAML) [16] is an XML extension
	[I-D.saml-tech-overview-1.1-03] is an XML extension for security		for security information exchange. It is being developed by OASIS.
	information exchange. It is being developed by OASIS. SAML enables		SAML enables entities to access resources by providing assertions
	entities to access resources by providing assertions which allow		which allow authorization.
	authorization.
	5.3.2.1 Assertions		6.3.2.1 Assertions
	An Assertion is a package of information including authentication		An Assertion is a package of information including authentication
	statements, attribute statements and authorization decision		statements, attribute statements and authorization decision
	statements. All kinds of statements do not have to be present, but		statements. All kinds of statements do not have to be present, but
	at least one. An Assertion contains several elements:		at least one. An Assertion contains several elements:
	Issuing information:		Issuing information:
	Who issued the assertion, when was it issued and the assertion		Who issued the assertion, when was it issued and the assertion
	identifier.		identifier.
	skipping to change at page 13, line 41 ¶		skipping to change at page 19, line 40 ¶
	with the attribute 'Department', which has the value 'Computer		with the attribute 'Department', which has the value 'Computer
	Science'.		Science'.
	In an authorization decision statement, a certain subject with a		In an authorization decision statement, a certain subject with a
	certain access type to a certain resource has given certain evidence		certain access type to a certain resource has given certain evidence
	that the identity is correct. Based on this, the relying party then		that the identity is correct. Based on this, the relying party then
	makes the decision on giving access or not. The subject could be a		makes the decision on giving access or not. The subject could be a
	human or a program, the resource could be a webpage or a web service,		human or a program, the resource could be a webpage or a web service,
	for example.		for example.
	5.3.2.2 Artifact		6.3.2.2 Artifact
	The Artifact is a base-64 encoded string which is 40 bytes long. 20		The Artifact is a base-64 encoded string which is 40 bytes long. 20
	bytes consists of the typecode, which is the source id. The		bytes consists of the typecode, which is the source id. The
	remaining 20 bytes consists of a 20-byte random number that servers		remaining 20 bytes consists of a 20-byte random number that servers
	use to look up an assertion. The entity creating an Assertion stores		use to look up an assertion. The entity creating an Assertion stores
	it temporarily. The entity performing the authorization decision		it temporarily. The entity performing the authorization decision
	uses the received Artifact to retrieve the assertion. The purpose of		uses the received Artifact to retrieve the assertion. The purpose of
	the Artifact is to act as a token which references an Assertion.		the Artifact is to act as a token which references an Assertion.
	SAML also defines a request/response protocol for obtaining		SAML also defines a request/response protocol for obtaining
	skipping to change at page 14, line 24 ¶		skipping to change at page 20, line 22 ¶
	emerging technology. Furthermore, SAML Assertions can be used to		emerging technology. Furthermore, SAML Assertions can be used to
	bind the authorization decision of different protocols sessions from		bind the authorization decision of different protocols sessions from
	different layers in the ISO-OSI model together. As an example, the		different layers in the ISO-OSI model together. As an example, the
	authorization decision by an application layer entity can be used to		authorization decision by an application layer entity can be used to
	bind it to a subsequent HIP exchange. SAML provides a complete		bind it to a subsequent HIP exchange. SAML provides a complete
	solution for authorization using Artifacts and Assertions and the		solution for authorization using Artifacts and Assertions and the
	corresponding protocols to obtain them. The assertions are based on		corresponding protocols to obtain them. The assertions are based on
	XML which allows extensibility beyond the initially envisioned		XML which allows extensibility beyond the initially envisioned
	deployment area.		deployment area.
	5.3.3 SPKI usage for HIP		6.3.3 SPKI usage for HIP
	HIP has already defined the CERT parameter that can carry		HIP has already defined the CERT parameter that can carry
	certificates. The HIP nodes requesting a NAT/FW traversal can send		certificates. The HIP nodes requesting a NAT/FW traversal can send
	their base exchange message with the CERT parameter. The CERT will		their base exchange message with the CERT parameter. The CERT will
	carry the SPKI certificate and the packet will be signed by the		carry the SPKI certificate and the packet will be signed by the
	requesting HIP node. This would mean, messages I2 and R2 should		requesting HIP node. This would mean, messages I2 and R2 should
	include the CERT parameter to get them authorized at the middleboxes.		include the CERT parameter to get them authorized at the middleboxes.
	The structure of the SPKI certificate for HIP is shown in Figure 6.		The structure of the SPKI certificate for HIP is shown in Figure 9.
	+------+-------+---------------+		+------+-------+---------------+
	| Key1 |HI(I/R)|Can Delegate? |		| Key1 |HI(I/R)|Can Delegate? |
	+------+-------+---------------+		+------+-------+---------------+
	| |		| |
	| Rights for NAT/FW traversal |		| Rights for NAT/FW traversal |
	+------------------------------+		+------------------------------+
	| |		| |
	| Date and further info |		| Date and further info |
	+------------------------------+		+------------------------------+
	| |		| |
	| Digital Signature |		| Digital Signature |
	+------------------------------+		+------------------------------+
	Figure 6: SPKI certificate structure for HIP		Figure 9: SPKI certificate structure for HIP
	5.3.4 Authentication and authorization for Base Exchange		6.3.4 Authentication and authorization for Base Exchange
	When a HIP host requests a NAT binding or a FW pinhole, it has to be		When a HIP host requests a NAT binding or a FW pinhole, it has to be
	first authenticated and authorized by the middleboxes. Since all HIP		first authenticated and authorized by the middleboxes.
			Authentication is necessary in many cases,because, in case of
			mobility, the middlebox should be authorized to change the flow id
			and no other party forge the middlebox to change. Since all HIP
	packets are signed using the private keys of the HIP hosts,		packets are signed using the private keys of the HIP hosts,
	middleboxes can verify these packets using the signature		middleboxes can verify these packets using the signature
	verifications. These of course will introduce certain kinds of		verifications. This, of course, will introduce certain kinds of
	denial of service attacks. Denial of service attacks for signature		denial of service attacks. Denial of service attacks for signature
	verification at middleboxes can be prevented by using the client		verification at middleboxes can be prevented by using the client
	puzzle concept used by the HIP protocol. For more details the HIP		puzzle concept used by the HIP protocol. For more details the HIP
	protocol [I-D.ietf-hip-base] can be consulted. This will force the		protocol [1] can be consulted. This will force the middleboxes to
	middleboxes to delay state creation and to also delay expensive		delay state creation and to also delay expensive computational
	computational operations. As detailed in previous sections, we seek		operations. As explained in the previous sections, we seek to use
	to use non-identity based authorization mechanisms that can be		non-identity based authorization mechanisms that can be verified by
	verified by the middleboxes before creating a NAT binding or FW		the middleboxes before creating a NAT binding or FW pinhole. Since
	pinhole. Since NATs force the outbound and inbound packets to flow		NATs force the outbound and inbound packets to flow through them,
	through them, they are much easier to handle. For instance, the		they are much easier to handle. For instance, the mechanism used by
	mechanism used by SPINAT [SPINAT] can be used for authorization of		SPINAT [14] can be used for authorization of state modifications by
	state modifications by utilizing hash chains and delayed		utilizing hash chains and delayed authentication with NATS. However,
	authentication with NATS. However, this is not presently suitable		this is not presently suitable for firewalls with asymmetric paths.
	for firewalls with asymmetric paths. More work needs to be done		More work needs to be done towards extending this idea for a
	towards extending this idea for a combination of NATs and firewalls		combination of NATs and firewalls with routing asymmetry.
	with routing asymmetry.
	A HIP host behind a firewall might need to register itself with local		A HIP host behind a firewall might need to register itself with local
	middleboxes before the base exchange can be initiated or completed.		middleboxes before the base exchange can be initiated or completed.
	Firewalls might not allow the traffic to bypass the firewall. For		Firewalls might not allow the traffic to bypass the firewall. For
	this, we consider using messages I1',R1',I2' and R2' which are an		this, we consider using messages I1',R1',I2' and R2' which are an
	extended version of the normal base exchange messages used in HIP.		extended version of the normal base exchange messages used in HIP.
	However, these messages are exclusively used only for configuring the		However, these messages are exclusively used only for configuring the
	HIP host with the firewalls such that authentication and		HIP host with the firewalls such that authentication and
	authorization is complete before the firewall opens up a pinhole.		authorization is complete before the firewall opens up a pinhole.
	With this approach, we make fewer changes to the base exchange by		With this approach, we make fewer changes to the base exchange by
	avoiding the inclusion of certain authorization parameters into them.		avoiding the inclusion of certain authorization parameters into them.
	We refer to this exchange as 'Registration Procedure' as shown in		We refer to this exchange as 'Registration Procedure', defined in
	Figure 7 which provides more details of this lightweight protocol		[17], as shown in Figure 10 which provides more details of this
	exchange.		lightweight protocol exchange.
	End host-to-Middlebox or E2M messages		End host-to-Middlebox or E2M messages
	I -> R: I1: Trigger exchange		I -> R: I1: Trigger exchange
	OR		OR
	I -> FW1: I1': Trigger exchange		I -> FW1: I1': Trigger exchange
	I <- FW1: R1': {Puzzle, D-H(R), HI(R),HIP Transform}SIG		I <- FW1: R1': {Puzzle, D-H(R), HI(R),HIP Transform}SIG
	I -> FW1: I2': {Solution,D-H(I),HIP Transform,{H(I)},CERT(I)}SIG		I -> FW1: I2': {Solution,D-H(I),HIP Transform,{H(I)},CERT(I)}SIG
	I <- FW1: R2': {HMAC}SIG		I <- FW1: R2': {HMAC}SIG
	Figure 7: HIP NAT/Firewall Registration Procedure		Figure 10: HIP NAT/Firewall Registration Procedure
	As an overview, we modify the HIP exchange protocol to authenticate		As an overview, we modify the HIP exchange protocol to authenticate
	the middlebox towards the initiator, to authorize (and possibly		the middlebox towards the initiator, to authorize (and possibly
	authenticate) the initiator towards the firewall and to establish a		authenticate) the initiator towards the firewall and to establish a
	security association between the initiator and the responder. We		security association between the initiator and the responder. We
	reuse the HIP protocol for this purpose to use the same		reuse the HIP protocol for this purpose to use the same
	infrastructure and to benefit from a lightweight protocol. Note that		infrastructure and to benefit from a lightweight protocol. Note that
	the message flow in Figure 7 does not establish IPsec security		the message flow in Figure 10 does not establish IPsec security
	associations. These security associations are not necessary in most		associations. These security associations are not necessary in most
	scenarios.		scenarios.
	When a host I wishes to create a pinhole with a FW on its side (named		When a host I wishes to create a pinhole with a FW on its side (named
	as FW-I), it has two choices:		as FW-I), it has two choices:
	o It sends a regular I1 message to the firewall. This assumes that		o It sends a regular I1 message to the firewall. This assumes that
	the end host knows that a firewall is located in the network and		the end host knows that a firewall is located in the network and
	additionally the address of this firewall is also known to the end		additionally the address of this firewall is also known to the end
	host. This might be the case in a corporate network environment.		host. This might be the case in a corporate network environment.
	This is shown as the I1' message.		This is shown as the I1' message.
	o The initiator I can also send a regular HIP I1 message towards a		o The initiator I can also send a regular HIP I1 message towards a
	destination host (denoted as R). This message will then be		destination host (denoted as R). This message will then be
	intercepted by the firewall and a R1' is returned.		intercepted by the firewall and a R1' is returned.
	With R1' the firewall sends a puzzle to the initiator similar to the		With R1' the firewall sends a puzzle to the initiator similar to the
	one sent from a HIP receiver to a HIP initiator. The initiator		one sent from a HIP receiver to a HIP initiator. The initiator
	solves the puzzle and sends the solution back to the FW along with		solves the puzzle and sends the solution back to the FW along with
	its SPKI certificate using the I2' message. Note that the Initiator		its SPKI certificate using the I2' message. Note that the Initiator
	can send its certificate in the I1/I1' message. This will, however,		can send its certificate in the I1/I1' message. This will, however,
	the FW to create a state even before the client puzzle solution is		create a state even before the client puzzle solution is obtained
	obtained from the initiator. This raises some denial of service		from the initiator. This raises some denial of service concerns.
	concerns. The FW can validate this SPKI certificate and authorize		The FW can validate this SPKI certificate and authorize the HIP host
	the HIP host I1. This packet is not liable to any denial of service		I1. This packet is not liable to any denial of service or replay
	or replay attacks as the solution is dependent on the cookie that R1'		attacks as the solution is dependent on the cookie that R1' included.
	included. Hence, the FW can look into the cookie index to avoid		Hence, the FW can look into the cookie index to avoid unwanted
	unwanted signature verifications. The ESP transforms are also		signature verifications. The ESP transforms are also dropped here as
	dropped here as the there will be no IPsec ESP packets exchanged		the there will be no IPsec ESP packets exchanged between the HIP host
	between the HIP host and the FW. There is also no need for the		and the FW. There is also no need for the SPI(I) values in I2' and
	SPI(I) values in I2' and R2' messages.		R2' messages.
	Once the FW receives the I2' packet, it verifies the solution to make		Once the FW receives the I2' packet, it verifies the solution to make
	sure that it is the entity to which it sent the R1' packet. It sends		sure that it is the entity to which it sent the R1' packet. It sends
	a R2' packet back to the initiator as an acknowledgement for		a R2' packet back to the initiator as an acknowledgement for
	authorization. The R2' packet however should include a HMAC to		authorization. The R2' packet however should include a HMAC to
	prevent denial of service attacks on I.		prevent denial of service attacks on I.
	After I receives the R2' packet, it can now initiate the normal base		After I receives the R2' packet, it can now initiate the normal base
	exchange that the FW will forward to R.		exchange that the FW will forward to R.
	skipping to change at page 18, line 31 ¶		skipping to change at page 24, line 24 ¶
	| |		| |
	+-+		+-+
	FW-I FW-R		FW-I FW-R
	+-+ +-+		+-+ +-+
	5.SPI(I) | | | | 5.SPI(R)		5.SPI(I) | | | | 5.SPI(R)
	--------------->| | | |<------------------		--------------->| | | |<------------------
	| | | |		| | | |
	+-+ +-+		+-+ +-+
	Figure 8: Authentication and authorization for base exchange messages		Figure 11: Authentication and authorization for base exchange
			messages
	5.3.5 Authentication and authorization for Readdressing		6.3.5 Authentication and authorization for Readdressing
	After the base exchange is complete, IPsec payload packets are		After the base exchange is complete, IPsec payload packets are
	exchanged among the HIP hosts. The middleboxes use the state that is		exchanged among the HIP hosts. The middleboxes use the state that is
	established with them to forward such packets to the HIP hosts. The		established with them to forward such packets to the HIP hosts. The
	state at FW-R is < SPI(R), IP(R), HIT(R) > and state at FW-I will be		state at FW-R is < SPI(R), IP(R), HIT(R) > and state at FW-I will be
	< SPI(I), IP(I), HIT(I) >.When one of the HIP hosts moves, it sends		< SPI(I), IP(I), HIT(I) >.When one of the HIP hosts moves, it sends
	an UPDATE message to its peer informing about the new IP addresses.		an UPDATE message to its peer informing about the new IP addresses.
	The peer will send a new SPI value back to the initiator to make a		The peer will send a new SPI value back to the initiator to make a
	return routability check. If the peer receives data from the		return routability check. If the peer receives data from the
	initiator on the new security association with this new SPI, it		initiator on the new security association with this new SPI, it
	confirms the mobile node has moved and is indeed reachable at the new		confirms the mobile node has moved and is indeed reachable at the new
	IP address. For middleboxes that use <destination IP address, SPI		IP address. For middleboxes that use <destination IP address, SPI
	and ESP> as the flow identifier to forward HIP packets, this		and ESP> as the flow identifier to forward HIP packets, this
	information needs to be updated with every UPDATE message. FW-I		information needs to be updated with every UPDATE message. FW-I
	(assuming that I is mobile) has to intercept the new IP address of I		(assuming that I is mobile) has to intercept the new IP address of I
	while FW-R (behind which is the peer R) has to update the new SPI(R)		while FW-R (behind which is the peer R) has to update the new SPI(R)
	to forward packets correctly. This is illustrated in Figure 9.		to forward packets correctly. This is illustrated in Figure 12.
	FW-R <SPI(R), IP(R), HIT(R)>		FW-R <SPI(R), IP(R), HIT(R)>
	+-+		+-+
	1.UPDATE with REA[new IP(I)] | |		1.UPDATE with REA[new IP(I)] | |
	---------------------------------+ |---------------->		---------------------------------+ |---------------->
	| |		| |
	FW-I +-+		FW-I +-+
	+-+		+-+
	| | 2.UPDATE[new SPI(R)] to IP(I)		| | 2.UPDATE[new SPI(R)] to IP(I)
	<---------| |----------------------------------------		<---------| |----------------------------------------
	skipping to change at page 19, line 33 ¶		skipping to change at page 25, line 32 ¶
	| |		| |
	+-+		+-+
	FW-I		FW-I
	+-+		+-+
	| | 4.Data on the new SA		| | 4.Data on the new SA
	---------| |---------------------------------------->		---------| |---------------------------------------->
	| |		| |
	| |		| |
	+-+		+-+
	Figure 9: Authentication and authorization for UPDATE messages		Figure 12: Authentication and authorization for UPDATE messages
	As seen, FW-R has the flow identifier information for receiver R and		As seen, FW-R has the flow identifier information for receiver R and
	FW-I has the flow identifier information for initiator I. When I		FW-I has the flow identifier information for initiator I. When I
	sends a UPDATE message with a REA parameter, R sends a new SPI(R) to		sends a UPDATE message with a REA parameter, R sends a new SPI(R) to
	check the reachability of the new IP address. FW-I can intercept the		check the reachability of the new IP address. FW-I can intercept the
	destination IP address from this message and can update its		destination IP address from this message and can update its
	information. After both the UPDATE and UPDATE reply messages have		information. After both the UPDATE and UPDATE reply messages have
	been sent out, the receiver needs to signal the FW-R about it new		been sent out, the receiver needs to signal the FW-R about it new
	SPI(R). Denial of service attacks and replay attacks are		SPI(R). Denial of service attacks and replay attacks are
	considerably reduced at firewalls if the firewalls keep track of the		considerably reduced at firewalls if the firewalls keep track of the
	skipping to change at page 20, line 10 ¶		skipping to change at page 26, line 7 ¶
	middleboxes are able to keep up the sequence. Issues as to how the		middleboxes are able to keep up the sequence. Issues as to how the
	receiver can inform the FW-R about its new SPI(R) even before it has		receiver can inform the FW-R about its new SPI(R) even before it has
	received a confirmation on the return routability test have to be		received a confirmation on the return routability test have to be
	considered.		considered.
	However, even this is true only if the new access point has the same		However, even this is true only if the new access point has the same
	set of middleboxes. If the mobile node is behind a new firewall		set of middleboxes. If the mobile node is behind a new firewall
	while sending an UPDATE message, the firewall does not have any state		while sending an UPDATE message, the firewall does not have any state
	information to create a pin hole. Hence, it should send a trigger		information to create a pin hole. Hence, it should send a trigger
	message that will reinitiate the extended E2M messages between the		message that will reinitiate the extended E2M messages between the
	mobile node and the firewall as in Figure 8.		mobile node and the firewall as in Figure 11.
	6. Security Considerations		7. Security Considerations
	In this approach, we have tried to extend the HIP base exchange to		In this approach, we have tried to extend the HIP base exchange to
	create a state at the NAT/FW securely. Though it is possible to make		create a state at the NAT/FW securely. Though it is possible to make
	this configuration along with the base exchange messages itself, the		this configuration along with the base exchange messages itself, the
	middlebox traversal will significantly alter the original base		middlebox traversal will significantly alter the original base
	exchange messages as including the sequence numbers and SPI values		exchange messages as including the sequence numbers and SPI values
	for the middleboxes. By extending the base exchange messages as		for the middleboxes. By extending the base exchange messages as
	I1',R1',I2' and R2', we also effectively make use of the security		I1',R1',I2' and R2', we also effectively make use of the security
	features that comes with the HIP protocol to protect the		features that comes with the HIP protocol to protect the
	configuration information between the HIP hosts and the middleboxes.		configuration information between the HIP hosts and the middleboxes.
	skipping to change at page 22, line 5 ¶		skipping to change at page 28, line 5 ¶
	match the expected values. These verifications can considerably		match the expected values. These verifications can considerably
	prevent such attacks.		prevent such attacks.
	o Hosts are protected against replays to R2' by use of a less		o Hosts are protected against replays to R2' by use of a less
	expensive HMAC verification preceding HIP signature verification.		expensive HMAC verification preceding HIP signature verification.
	o Hosts can prevent denial of service attacks and replay attacks		o Hosts can prevent denial of service attacks and replay attacks
	with the UPDATE message with the use of the UPDATE ID in the		with the UPDATE message with the use of the UPDATE ID in the
	UPDATE packets. These UPDATE messages are sequence numbers which		UPDATE packets. These UPDATE messages are sequence numbers which
	the middleboxes can keep a track of. They can simply precede any		the middleboxes can keep a track of. They can simply precede any
	signature verification by checking the UPDATE ID first.		signature verification by checking the UPDATE ID first.
	7. Acknowledgements		8. 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.		Thomas 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.
	8. References		9. References
	8.1 Normative References		9.1 Normative References
	[I-D.ietf-hip-base]		[1] Moskowitz, R., "Host Identity Protocol",
	Moskowitz, R., "Host Identity Protocol",		Internet-Draft draft-ietf-hip-base-00, June 2004.
	draft-ietf-hip-base-00 (work in progress), June 2004.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Requirement Levels", March 1997.		Levels", March 1997.
	8.2 Informative References		9.2 Informative References
	[I-D.fessi-nsis-natfw-threats]		[3] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
	Fessi, A., "Security Threats for the NAT/Firewall NSLP",		Translator (Traditional NAT)", RFC 3022, January 2001.
	draft-fessi-nsis-natfw-threats-01 (work in progress), July
	2004.
	[I-D.ietf-ipsec-ikev2]		[4] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
	Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		(NAT) Terminology and Considerations", Request For Comments RFC
	draft-ietf-ipsec-ikev2-14 (work in progress), May 2004.		2663, August 1999.
	[I-D.ietf-ipsec-nat-t-ike]		[5] Moskowitz, R. and P. Nikander, "Host Identity Protocol
	Kivinen, T., "Negotiation of NAT-Traversal in the IKE",		Architecture", Internet-Draft draft-moskowitz-hip-arch-05 (work
	draft-ietf-ipsec-nat-t-ike-08 (work in progress), February		in progress), September 2003.
	2004.
	[I-D.ietf-ipsec-udp-encaps]		[6] Kent, S. and R. Atkinson, "Security Architecture for the
	A. Huttunen et all, A., "UDP Encapsulation of IPsec		Internet Protocol", RFC 2401, November 1998.
	Packets", DRAFT draft-ietf-ipsec-udp-encaps-07.txt, Jan
	2003.
	[I-D.ietf-nsis-fw]		[7] Hancock, R., "Next Steps in Signaling: Framework",
	Hancock, R., "Next Steps in Signaling: Framework",		Internet-Draft draft-ietf-nsis-fw-07, November 2004.
	draft-ietf-nsis-fw-05 (work in progress), October 2003.
	[I-D.saml-tech-overview-1.1-03]		[8] Kivinen, T., A. Huttunen, A., Swander, B. and V. Volpe,
	Maler, E. and J. Hughes, "Technical Overview of the OASIS		"Negotiation of NAT-Traversal in the IKE", RFC 3947, January
	Security Assertion Markup Language (SAML) V1.1", March		2005.
	2004.
	[I-D.tschofenig-nsis-sid]		[9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	Tschofenig, H., "Security Implications of the Session		Internet-Draft draft-ietf-ipsec-ikev2-17, September 2004.
	Identifier", draft-tschofenig-nsis-sid-00 (work in
	progress), June 2003.
	[NATTerminology]		[10] A. Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M.
	Srisuresh, P. and M. Holdrege, "IP Network Address		Stenberg, "UDP Encapsulation of IPsec Packets", RFC 3948,
	Translator (NAT) Terminology and Considerations", Request		January 2005.
	For Comments RFC 2663, August 1999.
	[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the		[11] Nikander, P., Tschofenig, H., Henderson, T., Eggert, L. and J.
	Internet Protocol", RFC 2401, November 1998.		Laganier, "Preferred Alternatives for Tunnelling HIP (PATH)",
			Internet-Draft draft-nikander-hip-path-00.txt (work in
			progress), February 2005.
	[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network		[12] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
	Address Translator (Traditional NAT)", RFC 3022, January		(NSLP)", Internet-Draft draft-ietf-nsis-nslp-natfw-04, October
	2001.		2004.
	[SPINAT] Ylitalo, J., Melen, J., Nikander, P. and V. Torvinen,		[13] Tschofenig, H., "Security Implications of the Session
	"Re-thinking Security in IP based Micro-Mobility", 7th		Identifier", Internet-Draft draft-tschofenig-nsis-sid-00, June
	Information Security Conference (ISC-04), Palo Alto,",		2003.
	September 2004.
	[SPINAT1] Ylitalo, J., Melen, J. and P. Nikander, "SPINAT: A		[14] Ylitalo, J., Melen, J., Nikander, P. and V. Torvinen,
	Security Framework for Local IP Mobility Management,		"Re-thinking Security in IP based Micro-Mobility", 7th
	unpublished manuscript", November 2003.		Information Security Conference (ISC-04), Palo Alto,",
			September 2004.
	[draft-crocker-multiaddr-analysis]		[15] Ylitalo, J., Melen, J. and P. Nikander, "SPINAT: A Security
	Crocker, D., "Choices for Multiaddressing",		Framework for Local IP Mobility Management, unpublished
	draft-crocker-multiaddr-analysis-01.txt (work in		manuscript", November 2003.
	progress), October 2003.
	[draft-ietf-ipsec-esp-v3-08]		[16] Maler, E. and J. Hughes, "Technical Overview of the OASIS
	Kent, S., "IP Encapsulating Security Payload (ESP)",		Security Assertion Markup Language (SAML) V1.1", March 2004.
	draft-ietf-ipsec-esp-v3-08 (work in progress) (work in
	progress), March 2004.
	[draft-moskowitz-hip-arch]		[17] Laganier, J., Koponen, T. and L. Eggert, "Host Identity
	Moskowitz, R. and P. Nikander, "Host Identity Protocol		Protocol (HIP) Registration Extension",
	Architecture", draft-moskowitz-hip-arch-05 (work in		Internet-Draft draft-koponen-hip-registration-00.txt, February
	progress) (work in progress), September 2003.		2005.
	[draft-nikander-hip-mm]		[18] Kent, S., "IP Encapsulating Security Payload (ESP)",
	Nikander, P. and J. Arkko, "End-Host Mobility and		Internet-Draft draft-ietf-ipsec-esp-v3-08 (work in progress),
	Multi-Homing with Host Identity Protocol",		March 2004.
	draft-nikander-hip-mm-01.txt (work in progress) (work in
	progress), December 2003.
	[rfc3022] Srisuresh, P. and K. Egevang, "Traditional IP Network		[19] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
	Address Translator (Traditional NAT)", Request For		Translator (Traditional NAT)", Request For Comments RFC 3022,
	Comments RFC 3022, January 2001.		January 2001.
			[20] Nikander, P. and J. Arkko, "End-Host Mobility and Multi-Homing
			with Host Identity Protocol",
			Internet-Draft draft-nikander-hip-mm-01.txt (work in progress),
			October 2004.
			[21] Crocker, D., "Choices for Multiaddressing",
			Internet-Draft draft-crocker-multiaddr-analysis-01.txt, October
			2003.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	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
	Aarthi Nagarajan		Aarthi Nagarajan
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	EMail: aarthi.nagarajan@tuhh.de		Email: aarthi.nagarajan@tuhh.de
	Vesa Torvinen		Vesa Torvinen
	Ericsson		Ericsson
	Joukahaisenkatu 1		Joukahaisenkatu 1
	Turku FIN 20520		Turku FIN 20520
	Finland		Finland
	EMail: vesa.torvinen@ericsson.com		Email: vesa.torvinen@ericsson.com
	Jukka Ylitalo		Jukka Ylitalo
	Ericsson Research Nomadiclab		Ericsson Research Nomadiclab
	Jorvas FIN 02420		Jorvas FIN 02420
	Finland		Finland
	Phone: +358 9 299 1		Phone: +358 9 299 1
	EMail: jukka.ylitalo@ericsson.com		Email: jukka.ylitalo@ericsson.com
	Jochen Grimminger		Murugaraj Shanmugam
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	EMail: jochen.grimminger@siemens.com		Email: murugaraj.shanmugam@tuhh.de
	Appendix A. Same FW at Initiator for both outgoing and incoming packets
	This scenario assumes that the initiator I alone is behind a firewall
	named FW(I). This firewall is both for the outgoing and incoming
	packets and hence can look into all the base exchange messages. The
	FW(I) is expected to authenticate and authorize the initiator to send
	out going packets, receiver if necessary to let incoming packets and
	intercept the flow identifier from the base exchange. With the E2M
	messages, it can be achieved as follows. This is illustrated in
	Figure 10
	FW(I)
	I1 +-----+ I1
	+----------> | |--------------------------------------+
	| I2 | | I2 |
	| +-----> | |---------------------------------+ |
	| | | | | |
	| | | | v v
	---------+ | | +--------+
	Initiator| | | |Receiver|
	---------+ | | +--------+
	^ ^ | |
	| | R2 | | R2 | |
	| +------ | |< --------------------------------+ |
	| R1 | | R1 |
	+---------- | |< -------------------------------------+
	+-----+
	Figure 10: One FW only at initiator end
	1. I1 packet is sent from the initiator I to receiver R.
	2. FW(I) drops the packet and sends a R1' message back to I. This
	is the End host-to-Middlebox or E2M message exchange initiation.
	3. I sends I2' message with CERT(I) parameters to FW(I). It
	requests the FW(I) to open up a pinhole.
	4. FW verifies SPKI certificate and the signature of I.
	Accordingly, it either sends a R2' to acknowledge I that it can
	continue with the base exchange with message I1 or drops packet
	if verification fails.
	5. On receiving R2',I sends message I1 to R again. Now the FW(I)
	will let the packet through.
	6. R sends the message R1 to I.
	7. On receiving R1, if FW(I) wishes to authenticate/authorize the
	receiver R, it should initiate E2M exchange here. It sends
	message R1'to R forcing R to send an I2' in exchange.
	8. R sends the CERT(R) parameter in I2'.
	9. FW verifies SPKI certificate and the signature of R.
	Accordingly, it either sends a R2' to acknowledge R that it can
	continue with the base exchange with message R1 or drops packet
	if verification fails.
	10. On receiving R2', R sends message R1 to I again. Now the FW(I)
	will let it through.
	11. The base exchange continues until complete. Since all messages
	I1,R1,I2 and R2 traverse through FW(I), it can look into these
	messages to learn the flow identifier information.
	Appendix B. Different FWs at Initiator for outgoing and incoming
	packets
	This scenario assumes that the initiator I alone is behind firewalls
	named FW1(I) and FW2(I).FW1(I) is for the incoming packets to I and
	FW2(I) is for the outgoing packets to R. The FW(I) is expected to
	authenticate and authorize the initiator to send out going packets,
	while FW2(I) would authenticate and authorize the receiver, if
	necessary to let incoming packets. It is sufficient that FW2(I)
	alone learns the flow identifier information of I. It should store
	the state <SPI(I),IP(I),HIT(I)> to forward IPsec protected payload
	packets. This scenario is illustrated in Figure 11
	FW1(I)
	I1 +-----+ I1
	+----------> | |--------------------------------------+
	| I2 | | I2 |
	| +-----> | |---------------------------------+ |
	| | +-----+ | |
	| | v v
	+---------+ +--------+
	|Initiator| |Receiver|
	+---------+ FW2(I) +--------+
	^ ^ +-----+
	| | R2 | | R2 | |
	| +------ | |< --------------------------------+ |
	| R1 | | R1 |
	+---------- | |< -------------------------------------+
	+-----+
	Figure 11: Two FWs at initiator's end
	1. I1 packet is sent from the initiator I to receiver R.
	2. FW1(I) drops the packet and sends a R1' message back to I. This
	is the E2M message exchange initiation.
	3. I sends I2' message with CERT(I) parameters to FW1(I). It
	requests the FW1(I) to open up a pinhole.
	4. FW1(I) verifies SPKI certificate and the signature of I.
	Accordingly, it either sends a R2' to acknowledge I that it can
	continue with the base exchange with message I1 or drops packet
	if verification fails.
	5. On receiving R2',I sends message I1 to R again. Now the FW1(I)
	will let the packet through.
	6. R sends the message R1 to I.
	7. On receiving R1, if FW2(I) wishes to authenticate/authorize the
	receiver R, it should initiate E2M exchange here. It sends
	message R1'to R forcing R to send an I2' in exchange.
	8. R sends the CERT(R) parameter in I2'.
	9. FW2(I) verifies SPKI certificate and the signature of R.
	Accordingly, it either sends a R2' to acknowledge R that it can
	continue with the base exchange with message R1 or drops packet
	if verification fails.
	10. On receiving R2', R sends message R1 to I again. Now the FW2(I)
	will let it through.
	11. Since FW2(I) needs the store the state, once the base exchange
	is complete, the initiator should inform the FW2(I) about the
	SPI it has chosen for the exchange. This way, FW2(I) can
	forward further IPsec payload packets from R to I
	Appendix C. Different Firewalls at Initiator and Receiver
	This scenario looks into a more complicated situation. Initiator I
	is behind multiple firewalls FW1(I) for outgoing packets and FW2(I)
	and FW3(I) are for incoming packets. Similarly, receiver R is behind
	FW1(R) and FW2(R) for incoming packets and FW3(R) for outgoing
	packets. The incoming firewalls are chosen based on the type of the
	application and the hosts are unaware from which firewall they
	receive packets. Here, however for our scenario we assume that
	FW2(R) and FW2(I) are chosen about which also the hosts are unaware
	of. The FW1(I) is expected to authenticate and authorize the
	initiator to send outgoing packets to R, while FW2(R) would
	authenticate and authorize the receiver to let outgoing packets to I.
	FW2(R) should store the state <SPI(R),IP(R),HIT(R)> for the receiver
	while FW2(I) should store the state <SPI(I),IP(I),HIT(I)> for the
	initiator. This scenario is illustrated in Figure 12
	+-----+
	| |
	|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 12: Multiple FWs at initiator's and receiver's end
	1. I1 packet is sent from the initiator I to receiver R.
	2. FW1(I) drops the packet and sends a R1' message back to I. This
	is the E2M message exchange initiation.
	3. I sends I2' message with CERT(I) parameters to FW1(I). It
	requests the FW1(I) to open up a pinhole.
	4. FW1(I) verifies SPKI certificate and the signature of I.
	Accordingly, it either sends a R2' to acknowledge I that it can
	continue with the base exchange with message I1 or drops packet
	if verification fails.
	5. On receiving R2',I sends message I1 to R again. Now the FW1(I)
	will let the packet through.
	6. This packet would reach FW2(R). If this firewall wishes to
	authenticate and authorize the initiator I, then it can start a
	E2M exchange with I. After this is successfully completed,
	FW2(R) would open up a pinhole to send packets to R.
	7. R sends the message R1 to I.
	8. When R sends R1 to I, FW3(R) would initiate a E2M message to
	authenticate and authorize the receiver R. After this is
	complete, it will forward the packet to the initiator. On
	receiving R1, if FW2(I) wishes to authenticate/authorize the
	receiver R, it should initiate E2M exchange here.
	9. FW2(I) verifies SPKI certificate and the signature of R.
	Accordingly, it either sends a R2' to acknowledge R that it can
	continue with the base exchange with message R1 or drops packet
	if verification fails.
	10. On receiving R2', R sends message R1 to I again. Now the FW2(I)
	will let it through.
	11. This has completed only one round of authentication and
	authorization. However, the states are still not established at
	the firewalls. For this, the hosts have to signal their
	incoming firewalls about the SPI that they have chosen for IPsec
	ESP packets to follow.
	When hosts are behind multiple incoming firewalls, there are uble to
	decide to which firewall they have to inform their SPI values to.
	The first option would be to somehow make the chosen FW to signal the
	host about its requirement for a state to forward IPsec protected
	packets (similar to a pull model). This could be possibly done along
	with the first incoming packet which is R1. R1 packet could include
	extra signaling as record route to the initiator. The second option
	would be to inform firewall about the SPI values (like the push
	model). Here, however it would be necessary to send an extra message
	I3 from the initiator to the receiver which would include the SPI(I)
	for FW(I) and to resend the SPI(R) in I2 message for FW(R).
	The second problem is to secure the SPI signalling message from the
	end host to the FW. Since the endhosts authenticate and authorize to
	the FW that lets outgoing packets, they share keys only with them.
	However, they need to signal the SPI value to the FW on the other end
	which forwards incoming packets . For the sake of securing the SPI
	value, it might be necessary that the end hosts have to run a E2M
	exchange with the firewalls on the receiving end also.
	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 33, line 41 ¶		skipping to change at page 32, 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 (2004). This document is subject		Copyright (C) The Internet Society (2005). 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. 85 change blocks.
	422 lines changed or deleted		422 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/