< draft-aoun-nsis-nslp-natfw-migration-00.txt		draft-aoun-nsis-nslp-natfw-migration-01.txt >
	NSIS Working Group C. Aoun		NSIS Working Group C. Aoun
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: April 19, 2004 M. Brunner		Expires: August 16, 2004 M. Brunner
	M. Stiemerling		M. Stiemerling
	M. Martin		M. Martin
	NEC		NEC
	H. Tschofenig		H. Tschofenig
	Siemens		Siemens
	October 20, 2003		February 16, 2004
	NATFirewall NSLP migration and intra-realm communication		NAT/Firewall NSLP Migration Considerations
	considerations		draft-aoun-nsis-nslp-natfw-migration-01
	draft-aoun-nsis-nslp-natfw-migration-00
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 36 ¶
	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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 19, 2004.		This Internet-Draft will expire on August 16, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document discusses NAT/FW migration to support the NSIS NAT/FW		This document discusses migration issues towards NSIS NAT/FW NSLP
	NSLP as well as intra-realm communications considerations. The		enabled NATs and Firewalls. The document will serve as input to the
	document will serve as input to the NSIS NATFW NSLP document.		NSIS NATFW NSLP document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. NSIS Responder address selection for intra realm
	communications optimization . . . . . . . . . . . . . . . 4
	2.1 Potential solutions to the problem . . . . . . . . . . . . 5
	2.1.1 Intra realm solution protocol operation impacts . . . . . 6
	2.1.2 Intra realm solution application protocols impacts . . . . 7
	3. NATFW NSLP migration analysis . . . . . . . . . . . . . . 8
	3.1 Global scoped address determination with NSIS unaware
	NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2 Analysis of unilateral NSIS signaling . . . . . . . . . . 13
	3.3 Co-existence with existing NAT traversal mechanisms . . . 19
	3.4 NSIS protocol traversal of NSIS Unaware Firewalls and
	NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	3.4.1 NSIS protocol traversal of NSIS Unaware Firewalls . . . . 20
	3.4.1.1 NSIS protocol traversal of a mix of NSIS Unaware
	Firewalls and NSIS aware NATs . . . . . . . . . . . . . . 20
	3.4.1.2 NSIS protocol traversal of NSIS Unaware NATs . . . . . . . 21
	4. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . . 22
	5. Security Considerations . . . . . . . . . . . . . . . . . 23
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . 24
	7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 25
	Normative References . . . . . . . . . . . . . . . . . . . 26
	Informative References . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 28
	Intellectual Property and Copyright Statements . . . . . . 30
	1. Introduction
	Whether interim NAT and Firewall traversal mechanisms will already be
	deployed in networks or not, it is important to understand NSIS NATFW
	NSLP co-existence with non-NSIS aware NATs and Firewalls until their
	migration to NSIS would have been accomplished. The NSIS NATFW NSLP
	responder provides the NSIS NATFW NSLP Initiator with its address, in
	some cases the NSIS responder may have several addresses: a (or
	several) global scoped address and its locally scoped address(es).
	Which address does it provide to the NSIS initiator? This document
	will cover both the above issues and serve as input to the NSIS NATFW
	NSLP main document.
	2. NSIS Responder address selection for intra realm communications
	optimization
	An NSIS Element hosting an NSIS NATFW NSLP may have more than one
	address, its local scoped address(es) and global scoped address(es).
	A default address selection that priorities arbitrarily a global
	scoped address over a local scoped address may imply none optimal
	routing for communications between NSIS elements hosted within the
	same addressing realm.
	In Figure 1 the arbitrary selection of the global scoped address,
	works properly to receive NSIS signaling from Host B. However in
	deployment scenario shown in Figure 2, host A and host C end-up
	communicating through their local MB1 middlebox resulting in a non
	optimal data path with all its implications (additional delay,
	additional bandwidth in certain parts of the network infrastructure,
	etc ...).
	+---------------------+ +--------------------+
	| | | |
	| Host A | ,-----------. | Host B |
	| +-----+| ,-'The NET `-. | |
	| | MB1 |+-- --+ |
	| +-----+| `-. ,-' | |
	| | `-----------' | |
	| | | |
	+---------------------+ +--------------------+
	MB: Middle box (NAT or Firewall or a combination)
	Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Figure 1
	+---------------------+ +--------------------+
	| | | |
	| Host A`-. | ,-----------. | Host B |
	| `. +-----+| ,-'The NET `-. | |
	| i.. MB1 |+-- --+ |
	| Host C_.-'' +-----+| `-. ,-' | |
	| | `-----------' | |
	| | | |
	+---------------------+ +--------------------+
	MB: Middle box (NAT or Firewall or a combination)
	Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Host C: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Figure 2
	2.1 Potential solutions to the problem
	There are two ways to deal with this non-optimal routing of packets
	for intra-realm communications between NSIS entities. The NSIS
	Responder should either:
	1. Decide based on local decision, which address to provide to the
	NI to signal it or,
	2. Let the far end NSIS Initiator decide which address to select
	based on the NSIS Responder's provided addresses
	(1) lets the NSIS Responder decide on its own, which address to
	provide based on certain hints, which may not be the most optimal
	decision since the NSIS Responder may not have sufficient knowledge
	about the NSIS Initiator at the time of delivering its address to the
	responder. In most cases none arbitrary local decision for address
	selection requires to know about the far end host, which is not
	always practical.
	An example of such local based address selection is the IPv6 default
	address selection mechanism ([2]) where an IPv6 (or IPv6/v4) node has
	to select which source and destination address to pick in order to
	communicate with a far end node. The mechanism relies on receiving
	input from the local resolver (DNS client or local hosts file) about
	the far end node . In the context of multimedia applications (and
	probably others as well), the NSIS Initiator is provided the NSIS
	Responder contact information (includes IP address and transport port
	[1] via the user application protocols (example: SIP, H.323 etc ...).
	Within that specific context, the NSIS Responder does not have
	sufficient information about the NSIS Initiator to provide it a valid
	address.
	Hence it can not decide successfully in all cases which address to
	provide to the NSIS Initiator. Hence (2) is more efficient as it
	requires the NSIS Responder to provide all its addresses (local
	scoped and global scoped ones) to the NSIS Initiator. As a result,
	the NSIS Initiator will need to decide on which address to signal the
	NSIS Responder among all the provided ones. One possible way for the
	NSIS Initiator to decide from which address it will send NSIS
	signaling to the NSIS Responder and which NSIS Responder address to
	use is to check on which address the NSIS responder will reply back.
	An existing proposal [3] discusses the usage of (2) for SIP User
	Agents (SIP UA), the SIP UA will probe the far end SIP UA to see from
	which address it will response back. In [3], the STUN protocol [7] is
	used to check the responsiveness of the far end host. In [6], the
	reverse routability used to check which address to respond to
	counters RTP DOS attacks. The same required reverse routability could
	be achieved by the NSIS NATFW NSLP.
	****Include message sequences in the next iteration of the
	discussion*******
	In the context of NSIS, the NSIS protocol itself should be used as
	the probing mechanism.
	Consequently the NSIS Initiator will send simultaneously several NSIS
	messages towards the NSIS Responder, one message per provided
	address.
	The following occur during the process:
	o In case the NSIS Responder and Initiator are located within the
	same addressing realm, the NSIS Responder should receive a
	response from all the addresses to which it has sent NSIS
	messages. The NSIS Initiator will then choose the local scoped
	address as the destination address for messages destined to the
	NSIS Responder.
	o In case the NSIS Responder and Initiator are not located within		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	the same addressing realm, the NSIS Initiator would only receive a
	response from the valid global scope address. In event that there
	is another NE within the network that has the same local scoped
	address as the originally targeted NSIS Responder, the wrongly
	targeted NSIS Responder should send back an error or discard the
	message (the later would be preferable).
	2.1.1 Intra realm solution protocol operation impacts		3. NSIS unaware NAT Traversal . . . . . . . . . . . . . . . . . . 5
	As opposed to the normal NSIS mode of operation, an NI that has		4. Unilateral NSIS signaling . . . . . . . . . . . . . . . . . . 8
	already a security association with the neighboring NE on the path to
	a specific NR would need to verify that the target local scoped NR
	address is the same as one already cached in its NSIS neighbor table
	cache (association of Next hop NE with the target NR table).This
	would be required to avoid any confusion with an NSIS node that could
	be hosted within the same addressing realm and that would have the
	same local scoped address.
	There is a potential threat where an malicious NE with the same local
	scoped address as the target NR respond back positively to the NSIS
	message and consequently hijack the data flow. This threat could be
	counter-measured by proper cryptographic authentication of the NSIS
	Responder response by using keying material provided by the
	application signaling (assuming that it was secured).
	The procedure requiring an NSIS Initiator to send NSIS messages to		5. NSIS unaware Firewall Traversal . . . . . . . . . . . . . . . 13
	several NR addresses, requires that the NI sends his NSIS messages at
	the same time to avoid impacting real-time sensitive applications. In
	case the response to the message sent to the global scoped is
	received first, it could potentially be used as a hint that no
	response will be received from the NR's local scoped address. Hence
	there is no point to continue to delay the address selection process
	and proceed with the NSIS protocol operations. In case the first
	response is received from a local scoped address and has been
	authenticated with the keying material provided by the application
	signaling protocol then the address selection process ends, and the
	NSIS protocol operations continue.
	2.1.2 Intra realm solution application protocols impacts		6. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . . . . 14
	The proposed intra realm path optimization proposal requiring an NR		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	to provide several data recipient addresses within the application
	protocol, has obviously a certain impact on the application protocol.
	[5] discusses the impact to SDP [8] and should be used by all the
	application protocols using SDP. A similar approach should be
	followed by other protocols, not using SDP, including H.323 [9] and
	others requiring usage of NSIS with multiple addresses for the NR.
	3. NATFW NSLP migration analysis		8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
	This section goes through a detailed analysis of the NATFW NSLP		Normative References . . . . . . . . . . . . . . . . . . . . . 17
	transition challenges and its possible solutions. The conception of
	the NSIS NATFW NSLP MUST ensure that upon its deployments in
	networks, it should not disrupt applications using interim NAT and
	Firewall traversal mechanisms.
	In addition:
	o The NATFW NSLP should ensure that an NR would not always be		Informative References . . . . . . . . . . . . . . . . . . . . 18
	required to have minimal service, particularly when the NI has a
	simple network configuration without asymmetric route issues. In
	the early phases of the NSIS NATFW NSLP migration, this situation
	will be quite frequent and hence this scenario must be supported.
	o The NSIS protocol should be designed to traverse non-NSIS aware		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
	NATs and Firewalls, to allow usage of non NAT and Firewall related
	NSLP (Qos NSLP for example). As the reader will notice in the
	subsequent sections NRs behind
	o It is advised for an NSIS aware NAT and Firewall implementation to		Intellectual Property and Copyright Statements . . . . . . . . 20
	keep its existing currently used stateful behavior (depending on
	its applicability) until the transition to NSIS has ended (in
	order to have a smoother transition).
	Several deployment scenario will be considered within this analysis,		1. Introduction
	for simplicity the discussed scenario cover at most two Middleboxes
	on the path between the NI and NR. In Figure 3, a total of 144
	deployment scenario could be possible only the ones having an NI or
	NR (only when there is a NAT) are considered. Implied but not shown
	scenario within Figure 5 are ones in the NI column or NR row.
	Obviously not all the scenario will be covered in this section, only
	the most interesting scenario are discussed in the next sections. A
	check list will be added later on in the annex of the next iteration
	of the analysis.
	`.-----+------+-------+-------+--------+------+-------+		The overall NSIS protocol suite (including the NATFW NSLP) is
	| `NR | NAT | FW |NATFW | NAT++ |FW++ |NATFW++|		impacted by NSIS NATFW NSLP unaware NATs and Firewalls, this document
	|NI `. |NE+NAT|NE+FW |NE+NATFW NE |NE | NE |		covers impacts as well as some suggestions to ease the deployments of
	|``````|``````|```````|```````|````````|``````|```````|		the NSIS protocol suite until the installed base on NATs and
	| |Sc2 | |Sc10 |Sc14 | |Sc22 |		Firewalls migrates to NSIS.
	|NAT |Sc3 |Sc7 |Sc11 |Sc15 |Sc19 |Sc23 |
	|NE+NAT|Sc4 |Sc8 |Sc12 |Sc16 |Sc20 |Sc24 |
	|`````````````````````````````````````````````````````
	| |Sc26 | |Sc34 |Sc38 | |Sc46 |
	| FW |Sc27 |Sc31 |Sc35 |Sc39 |Sc43 |Sc47 |
	| NE+FW|Sc28 |Sc32 |Sc36 |Sc40 |Sc44 |Sc48 |
	'''''''''''''''''''''''''''''''''''''''''''''''''''''''
	| |Sc50 | |Sc58 |Sc62 | |Sc70 |
	|NATFW |Sc51 |Sc55 |Sc59 |Sc63 |Sc67 |Sc71 |
	NE+NATFW Sc52 |Sc56 |Sc60 |Sc64 |Sc68 |Sc72 |
	'''''''''''''''''''''''''''''''''''''''''''''''''''''''
	| |Sc74 | |Sc82 |Sc86 | |Sc94 |
	| NAT++|Sc75 |Sc79 |Sc83 |Sc87 |Sc91 |Sc95 |
	| NE |Sc76 |Sc80 |Sc84 |Sc88 |Sc92 |Sc96 |
	+------+------+-------+-------+--------+------+-------+
	| |Sc98 | |Sc106 |Sc110 | | Sc118 |
	|FW++ |Sc99 | Sc103 |Sc107 |Sc111 |Sc115 | Sc119 |
	|NE |Sc100 | Sc104 |Sc108 |Sc112 |Sc116 | Sc120 |
	+------+------+-------+-------+--------+------+-------+
	| |Sc122 | |Sc130 | Sc134 | | Sc142 |
	|NATFW++ Sc123| Sc127 |Sc131 | Sc135 | Sc139| Sc143 |
	| NE | Sc124| Sc128 |Sc132 | Sc136 | Sc140| Sc144 |
	+------+------+-------+-------+--------+------+-------+
	Figure 3		The NATFW NSLP should allow an end host supporting NSIS to operate
			properly without the need of supporting true end-to-end NSIS
			signaling to its application correspondent. This is very practical
			during the initial phases of the NSIS migration and is applicable in
			simple network configurations not affected by asymmetric routing. In
			the early phases of the NSIS NATFW NSLP migration, this situation
			will occur quite frequent and hence this scenario must be supported.
	Scxyz: Scenario number xyz		The NSIS protocol should traverse NSIS unaware NATs (and possibly
	NAT : NSIS Unaware NAT		Firewalls) to allow a smoother deployment of, for example, Qos NSLP
	NE : NSIS Entity with NI and NR functions		in today's networks. To provide a smooth migration it is necessary to
	NE+NAT: NE hosted within a network connected to the NSIS unaware		understand the coexistence of NSIS aware and unware NATs and
	NAT FW : NSIS Unaware Firewall		Firewalls.
	NE+FW: NE hosted within a network protected by an NSIS Unaware FW
	NATFW: NSIS Unaware NAT and Firewall hosted within the same Middlebox
	NE+NATFW: NE hosted within a network protected by an NSIS Unaware
	NATFW
	NAT++: NSIS Aware NAT
	NAT++NE: NE hosted within a network connected to an NAT++
	FW++ : NSIS Aware FW
	FW++NE: NE hosted within a network connected to a FW++
	NATFW++: NSIS Aware NATFW
	NATFW++NE: NE hosted within a network connected to a NATFW++
	Every cell in Figure 3 is the combination of the NI's network and the
	NR's network. Deployments scenario, where there are no NI and NR, no
	NI (without an NR with a NAT), are not shown. For example:
	`.-----+------+		2. Terminology
	| `NR | NAT |
	|NI `. |NE+NAT|
	|````` :``````|
	| NAT |Sc2 |
	|NE+NAT|Sc3 |
	| |Sc4 |
	Figure 4		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [1].
	Scenario 1: NAT x NAT is not considered as there is no NI and no NR		The terminology used in this document is defined in [2].
	with a NAT
	Scenario 2: NAT x NE+NAT is considered as there is an NR with a NAT
	(even if it is not NSIS aware)
	Scenario 3: NE+NAT x NAT, is considered since there is an NI as part
	of the NE functions
	Scenario 4: NE+NAT x NE+NAT, is considered since there is an NI as
	part of the NE functions
	The same logic is applicable to all the cells in Figure 3
	For simplicity only network deployments are shown with a maximum of 2
	MBs on the path between the NI and the NR. Handled scenario within
	the NI column or NR raw are the ones having an NI or NR. In the next
	sections, we shall go through the various issues that are specific to
	the scenario mentioned in Figure 3.
	3.1 Global scoped address determination with NSIS unaware NATs		3. NSIS unaware NAT Traversal
	This section discusses the potentional role that an NE with a NATFW		This section discusses how an NE with any NSLP could still operate
	NSLP could still have to determine a global scoped address translated		when an NSIS unaware NAT is on the data path. The detection of an
	by a none NSIS aware NAT. Upon detection that the NE is attached to a		NSIS unaware NAT could be a feature of the NTLP [3], allowing its
	network hosting an NSIS unaware NAT, it could have the two		usage on any NE regardless of the supported NSLPs.
	alternatives, either:
	1. The NSIS API could invoke the services of a STUN client [7] as		Several NSIS independent approaches could be used by the NE to learn
	shown is Figure 7, this would allow applications using UDP		its global scoped address in order to use it for its hosted NSLPs. In
	transport to work (only applicable for cone NAT [7]).		this version of the document, only the STUN protocol [5] is
			considered as means to acquire the global scoped address; the next
			versions will consider other approaches.
	+---------------------------------------+		+---------------------------------------+
	| | +--------+		| | +--------+
	| +----------+ | | STUN |		| +----------+ | | STUN |
	| |Apps | | | Server |		| |Apps | | | Server |
	| +----------+ +---+| +--------+		| +----------+ +---+| +--------+
	| | STUN | |NAT||		| | STUN | |NAT||
	| | CLIENT | | ||		| | CLIENT | | ||
	| |__________| +---+|		| |__________| +---+|
	| |NATFW NSLP| |		| |ANY_NSLP | |
	| | NI/NR | |		| | NI/NR | |
	| +----------+ |		| +----------+ |
	| Host A |		| Host A |
	+---------------------------------------+		+---------------------------------------+
	Figure 5
	2. The NE could send, through the NSIS unaware NAT, a bind request
	message towards a network entity hosting a simplified NR function
	responding to the message with the translated address. The
	translated address and port would correspond to the translated
	source address and port of the received NSIS message by the NE.
	This translated address and port information would only be useful
	for UDP transported data, and would imply that the NSIS protocol
	would be sent from the same address and port as the data flows.
	This behavior implies a change to the protocol operations, since
	the NTLP does not normally require transport protocol changes for
	a given NSLP (at least for now); the other implied modification
	is to support a minimum set of operations on the responding NE
	hosting the NATFW NSLP. The minimum set of operations would
	consist of the ability to authenticate the NE, providing the
	translated address and port, and support of UDP transport (as
	well as TCP if certificates need to be sent first). This
	mechanism would only be applicable to cone NATs [7].
	+---------------------------------------+		Figure 1: STUN usage for NSIS unaware NATs
	| | +--------+
	+ +----------+ | |NATFW |
	| |Apps | | | NSLP-NR|
	| +----------+ +---+| +--------+
	| |NATFW NSLP| |NAT||
	| | NI/NR | | ||
	| +----------+ +---+|
	| Host A |
	| |
	+---------------------------------------+
	Figure 6		Within the initial stages of the NSIS migration, NE functions will be
			co-hosting a STUN client that was already present on the application
			end-host. Within Host A, shown in Figure 1, the NSIS API could invoke
			the services of the STUN client (as shown in Figure 2) upon
			determination that an NSIS unaware NAT was on the path.This would
			allow applications using UDP transport to work (only applicable for
			cone NAT variants [5]).
	+-----------------+		+-----------------+
	___________| NSIS aware NAT |_________		___________| NSIS aware NAT |_________
	| | Determination | |		| | Determination | |
	NSIS | +-----------------+ | NSIS		NSIS | +-----------------+ | NSIS
	Aware | | Unaware		Aware | | Unaware
	| |		| |
	| |		| |
	V V		V V
	+-------------------+ +------------+		+-------------------+ +------------+
	|Proceed with | If not UDP |Used data |		|Proceed with | If not UDP |Used data |
	|normal NR operation| +--------|transport |		|normal NR operation| +--------|transport |
	+-------------------+ | |protocol |		+-------------------+ | |protocol |
	| +------------+		| +------------+
	| | If UDP		| | If UDP
	V |		V |
	+-------------+ |		+-------------+ |
	|Log error | |		|Log error | |
	|to app layer | |		|to app layer | |
	+-------------+ V		+-------------+ V
	+-------------+		+-------------+
	| Invoke STUN |		| Invoke STUN |
	| Client |		| Client |
	+------+------+		+------+------+
	|		|
	|		|
	|		|
	V		V
	+------------+		+------------+
	| Send STUN |		| Send STUN |
	| binding |		| binding |
	| request |		| request |
	+-----+------+		+-----+------+
	|		|
	V		V
	+-------------------------+		+-------------------------+
	|Standard STUN operations |		|Standard STUN operations |
	+-------------------------+		+-------------------------+
	Figure 7		Figure 2: Interactions with a STUN client
	+-----------------+		NSLPs would use the STUN returned global scoped address for the flow
	___________| NSIS aware NAT |_________		id [3].To allow NSIS signaling to be received by the NR on host A,
	| | Determination | |		without impacting existing applications (i.e. without explicitly
	NSIS | +-----------------+ | NSIS		providing the address and port of the NSIS recipient in the
	Aware | | Unaware		application signaling), the NSIS protocols would need to use NTLP
	| |		datagram mode transport (as defined in [3]). This would imply that
	| |		the NTLP will be using the same port as the data flows, this might
	V +------------+		complicate the proposed mode of operations (and might not meet the
	+-------------------+ If not UDP |Used data |		expected performance). The next version of the draft will discuss
	|Proceed with | +--------|transport |		whether this approach would be practical based on received feedback
	|normal NR operation| | |protocol |		from implementors.
	+-------------------+ | +------------+
	| | If UDP
	V |
	+-------------+ |
	|Log error | V
	|to app layer | +------------+
	+-------------+ |Send bind |
	|create msg |
	|over UDP |
	+-----+------+
	|
	|
	V
	+-------+------------+-----+
	| Simplified NE to respond |
	| with observed translated |
	| address and port |
	+--------------+-----------+
	|
	|
	|
	+---------------------+
	| NR to provide |
	| translated address |
	| to app layer |
	+---------------------+
	Figure 8		Subsequently we discuss how the NATFW NSLP could co-exist with
			interim NAT traversal mechanisms described in [8]. In Figure 3, a
			STUN client (Host A) [5], an NE (Host B), a host using a Media Proxy
			[8] and host using a TURN client [9] co-exist in the same network
			with a NATFW NSLP aware NAT. There are no reasons for the existing
			mechanisms to be mutually exclusive every host could continue using
			the existing interim solutions, meanwhile the unilateral NSIS
			signaling would be used until both ends support the NSIS NATFW NSLP.
	3.2 Analysis of unilateral NSIS signaling		+---------------------------+
			| _|__1______.STUN Server
			|STUN Client ----'''''''''' |
			| Host A | App server
			| 2 _..NAT++ | .-'
			| NI/NR __.--'' | 3 .'+
			| Host B -'' | Media Proxy.-'
			| |
			| |
			| Host C |
			| 4 |
			| Turn Client---------------+---------- TURN Server
			| Host D |
			| |
			+---------------------------+
			Figure 3: Coexistence of NSIS NATFW NSLP and existing NAT traversal
			mechanisms
			4. Unilateral NSIS signaling
	When NSIS NAT/FW signaling will start to be deployed, it is quite		When NSIS NAT/FW signaling will start to be deployed, it is quite
	possible that an NI sends an NSIS message without having an NR to		possible that an NI sends an NSIS message without having an NR to
	respond to it. The NATFW NSLP should have the ability to have a		respond to it. The NATFW NSLP should be able to handle this type of
	mechanism that would allow it to handle this type of deployments.		deployments. NSIS NATFW NSLP signaling for NAT binds is already local
	NSIS NATFW NSLP signaling for NAT binds is already local within the		within the trust domain (the Reserve External Address is intercepted
	trust domain, however this is not the case with firewall signaling		by the edge NAT, ref [2], however this is not the case with firewall
	that should be end to end.		signaling that should be end to end.
	There are three interesting cases to be analyzed:		Since the purpose of this section is to discuss how are end to end
			signaled messages handled when no NRs are available on the end-host
			only Firewalls (the NFs) are discussed within the example networks.
	1. The local trust domain (from an NI perspective) has at least one		There are two interesting cases to be analyzed:
	NSIS aware Firewall, there is no NR on the far end as well as no
	NSIS aware NAT or Firewall.		Approach 1: Implicit (not explicitly scoped) localized signaling: The
			local trust domain (from an NI perspective) has at least one NSIS
			aware Firewall, there is no NR on the far end as well as no NSIS
			aware NAT or Firewall. This approaches is similar to [13], however
			the NSIS messages do not included any scoping information. Figure
			4 shows this scenario graphically.
	+-----------------------+ +--------------------+		+-----------------------+ +--------------------+
	|+----------+ | | +----------+		|+----------+ | | +----------+
	||App client| | | |App client|		||App client| | | |App client|
	||NI/NR | FW++ | ,---------. | +----------+		||NI/NR | FW++ | ,---------. | +----------+
	|+----------+ ''''''' The net ---. Host B |		|+----------+ ''''''' The net ---. Host B |
	| Host A | `---------' | |		| Host A | `---------' | |
	| | | |		| | | |
	| Net A | | Net B |		| Net A | | Net B |
	+-----------------------+ +--------------------+		+-----------------------+ +--------------------+
	Figure 9		Figure 4: Implicit localized signaling
	2. The local trust domain has no NSIS aware Firewall, there is no NR		Approach 2: Missing trust with far end host's NFs: The local trust
	at the far end but there is at least an NSIS aware firewall with		domain has no NSIS aware Firewall, there is no NR at the far end
	which the local NI has no direct trust relation (which implies an		but there is at least an NSIS aware firewall with which the local
	authorization issue and possibly authentication issues).		NI has no direct trust relation (which implies an authorization
			issue and possibly authentication issues). The main addition to
			the issue discussed in the localized signaling case above
			(determination of the last NE on the path and response to the NSIS
			message by the last NE) is the lack of trust relations with the
			NI. Figure 5 shows this scenario graphically.
	+-----------------------+ +--------------------+		+-----------------------+ +--------------------+
	|+----------+ | | +----------+		|+----------+ | | +----------+
	||App client| | | |App client|		||App client| | | |App client|
	||NI/NR | | ,---------. | FW++ +----------+		||NI/NR | | ,---------. | FW++ +----------+
	|+----------+ ''''''' The net ---. Host B |		|+----------+ ''''''' The net ---. Host B |
	| Host A | `---------' | |		| Host A | `---------' | |
	| | | |		| | | |
	| Net A | | Net B |		| Net A | | Net B |
	+-----------------------+ +--------------------+		+-----------------------+ +--------------------+
	Figure 10		Figure 5: Missing trust with the remote host's network
	3. The local trust domain (from an NI perspective) has at least one
	Firewall, there is no NR on the far end but there is at least one
	NSIS aware Firewall with which the local NI has no direct trust
	relation (which implies an authorization issue and possibly
	authentication issues).
	+-----------------------+ +--------------------+
	|+----------+ | | +----------+
	||App client| | | |App client|
	||NI/NR | FW++ | ,---------. | FW++ +----------+
	|+----------+ ''''''' The net ---. Host B |
	| Host A | `---------' | |
	| | | Net B |
	| Net A | | |
	+-----------------------+ +--------------------+
	Figure 11
	In 1), the NI sends its firewall policy rule creation message, it		In approach (1), the NI sends its firewall policy rule creation
	traverses the first NF (its own firewall) but there is no NR to		message, it traverses the first NF (its own firewall) but there is no
	respond back. If we consider to have a response timer on the last NF		NR to respond back. If we consider to have a response timer on the
	being traversed by an NATFW NSLP message then if no response is		last NF being traversed by an NATFW NSLP message then if no response
	received to the NSIS message, the last NF will respond back to the NI		is received to the NSIS message, the last NF will respond back to the
	with a notification of no far end NR response. This will imply that		NI with a notification of no far end NR response. This will imply
	the signaling will be scoped to the last NF on the path that		that the signaling will be scoped to the last NF on the path that
	responded back. Using the network deployment shown in Figure 9, the		responded back. Using the network deployment shown in Figure 4, the
	following mode of operation would apply:		following mode of operation would apply:
	Host A Host B		Host A Host B
	NI FW++ Expected NR		NI FW++ Expected NR
	| | |		| | |
	|1-NSIS Init msg | |		|1-NSIS Init msg | |
	|----------------> | |		|----------------> | |
	| |2-NSIS Init msg |		| |2-NSIS Init msg |
	| | +---------------> |		| | +---------------> |
	| | |NATFW NSLP ON |		| | |NATFW NSLP ON |
	| | | |		| | | |
	| | | |		| | | |
	| | | |		| | | |
	| | | Timeout |		| | | Timeout |
	3-NSIS Init msg Ack| V |		3-NSIS Init msg Ack| V |
	|No NR | |		|No NR | |
	|<.................| |		|<.................| |
	Figure 12		Figure 6: Detecting the last NSIS peer
	When more than one NSIS aware NAT or Firewall is deployed within the		Figure 7 provides the message sequences when more than one NSIS aware
	same trust domain, upon determination of a previous NSIS hop, an NSIS		NAT or Firewall is deployed within the same trust domain. Upon
	aware node will notify the previous NSIS hop of its existence to		determination of a previous NSIS hop, an NSIS aware node will notify
	avoid launching the timer that triggers the sending of an NSIS		the previous NSIS hop of its existence to avoid launching the timer
	message back to the NI. The last NF on the path will launch the timer		that triggers sending of an NSIS message back to the NI. The current
	since no valid NSIS neighbor was sent to it.		NTLP message association establishment procedures supports this
			behavior. The last NF on the path will launch the timer since no
			valid downstream NSIS neighbor responded back.
	Trust domain A Trust domain B		Trust domain A Trust domain B
	<..........................................> <-------->		<..........................................> <-------->
	Host A Host B		Host A Host B
	NI FW++ FW++ Expected NR		NI FW++ FW++ Expected NR
	| | | |		| | | |
	| NSIS Init msg | | |		| NSIS Init msg | | |
	| ----------------> | NSIS Init msg | |		| ----------------> | NSIS Init msg | |
	| | ---------------> | NSIS Init msg |		| | ---------------> | NSIS Init msg |
	| | NATFW NSLP ON |---------------->|		| | NATFW NSLP ON |---------------->|
	skipping to change at page 16, line 27 ¶		skipping to change at page 10, line 32 ¶
	| | | | |		| | | | |
	| | | | |		| | | | |
	| | | | |		| | | | |
	| | | V |		| | | V |
	| | <................+ |		| | <................+ |
	| | NSIS Init msg Ack| |		| | NSIS Init msg Ack| |
	| NSIS Init msg Ack | No NR | |		| NSIS Init msg Ack | No NR | |
	| No NR | | |		| No NR | | |
	| <.................| | |		| <.................| | |
	Figure 13		Figure 7: Detecting the last NSIS peer (multiple FWs)
	In 2), the NI sends its firewall policy rule creation message, it		In approach (2), the NI sends its firewall policy rule creation
	traverses the FW hosted in Host B's network, but host A is not		message, it traverses the FW hosted in Host B's network, but host A
	authorized to install a policy rule unless the policy rule creation		is not authorized to install a policy rule unless the policy rule
	is approved by a trusted entity within Net B. Unfortunately Host B		creation is approved by a trusted entity within Net B. Unfortunately
	was not yet upgraded to support the NATFW NSLP, another entity needs		Host B was not yet upgraded to support the NATFW NSLP, another entity
	to authorize the policy rule installation.		needs to authorize the policy rule installation.
	Potentially a trusted third party already aware of the application		Potentially a trusted third party already aware of the application
	session held between Host A and Host B could provide an authorization		session held between Host A and Host B could provide an authorization
	token to Host A [13], the token would be encapsulated within the		token to Host A [11], the token would be encapsulated within the
	NATFW NSLP message and would allow the NSIS aware Firewall in Net B		NATFW NSLP message and would allow the NSIS aware Firewall in Net B
	to authorize Host A's requested policy rule to be installed. This		to authorize Host A's requested policy rule to be installed. This
	approach would obviously require to put in place a mechanism to		approach would obviously require to put in place a mechanism to
	provide the authorization token to Host A. The token could be		provide the authorization token to Host A. The token could be
	requested by the NI and included in the NSLP signaling by default or		requested by the NI and included in the NSLP signaling by default or
	after receiving an error message from the far end NSIS aware Firewall		after receiving an error message from the far end NSIS aware Firewall
	indicating that authorization data is required. The authorization		indicating that authorization data is required. The authorization
	token would need to be associated with the identity of the NI,		token would need to be associated with the identity of the NI,
	associating the authorization token with an IP address is not		associating the authorization token with an IP address is not
	sufficient, a proper mechanism should be put in place to allow proper		sufficient, and could lead to issues if the IP address was not valid
	authentication of the legal token user. The next revision of the		due to address translation occurring on the path, a proper mechanism
	discussion will cover in more details this aspect.		should be put in place to allow proper authentication of the entitled
			token user.
			Figure 8 shows the architecture with two different networks and the
			trusted third party which creates the authorization. Figure 9
			provides a message flow for authorization token handling.
	+---------------+		+---------------+
	| Authorization|1-Generate Token		| Authorization|1-Generate Token
	| mediator |		| mediator |
	.'--------------+		.'--------------+
	.' \		.' \
	2-Provide .-' \		2-Provide .-' \
	Token .' \		Token .' \
	.' \		.' \
	.' \4-Check token		.' \4-Check token
	.-' \ validity		.-' \ validity
	+-----------.'----------+ ++----------------+		+-----------.'----------+ ++----------------+
	|+--------.'+ | | \ +----------+		|+--------.'+ | | \ +----------+
	||App client| | | \ |App client|		||App client| | | \ |App client|
	||NI/NR +-------. | ,-=.----.-. | FW++ +----------+		||NI/NR +-------. | ,-=.----.-. | FW++ +----------+
	|+----------+ `---------'The net `-------- Host B |		|+----------+ `---------'The net `-------- Host B |
	| Host A | `---------' | |		| Host A | `---------' | |
	| | 3-Send | |		| | 3-Send | |
	| | NSLP msg with | |		| Network A | NSLP msg with | Network B |
	+-----------------------+ Token +-----------------+		+-----------------------+ Token +-----------------+
	Figure 14		Figure 8: Authorization Token Handling
	Trust domain A Trust domain B		Trust domain A Trust domain B
	<........................> <--------------------->		<........................> <--------------------->
	Host A Host B		Host A Host B
	NI FW FW++ Expected NR		NI FW FW++ Expected NR
	| | | |		| | | |
	| NSIS Init msg | | |		| NSIS Init msg | | |
	| ------------------+----------------> | |		| ------------------+----------------> | |
	| | | NSIS Init msg |		| | | NSIS Init msg |
	| | | +-------------->|		| | | +-------------->|
	skipping to change at page 18, line 11 ¶		skipping to change at page 12, line 33 ¶
	| | | | with Token |		| | | | with Token |
	| | Valid + | NATFW NSLP ON |		| | Valid + | NATFW NSLP ON |
	| | NSIS Neighbor | | |		| | NSIS Neighbor | | |
	| |<-----------------| | Timeout |		| |<-----------------| | Timeout |
	| |----------------->| | |		| |----------------->| | |
	| NSIS Init msg Ack | Ack | | |		| NSIS Init msg Ack | Ack | | |
	| No NR | <................| V |		| No NR | <................| V |
	| <.................| NSIS Init msg Ack| |		| <.................| NSIS Init msg Ack| |
	| | No NR | |		| | No NR | |
	Figure 15		Figure 9: Authorization Token Message Flow
	In 3),the NI sends its message to the non-existing NR at host B, it
	traverses the first NSIS aware Firewall, the policy rule installation
	succeeds; the message continues to be forwarded until it reaches the
	2nd NATFW NSLP aware firewall.
	In case no authorization material is provided in the NSLP message,
	the Firewall will send an error message notifying the NI to send
	authorization data. If the NI can't send any authorization data, then
	it will decide to scope the NSIS signaling message to the last NF on
	which the state installation succeeded.
	Trust domain A Trust domain B
	<........................> <--------------------->
	Host A Host B
	NI FW++ FW++ Expected NR
	| | | |
	| NSIS Init msg | | |
	| ----------------> | NSIS Init msg | |
	| | +--------------> | |
	| | NATFW NSLP ON | |
	| | | |
	| | NSIS ERROR . |
	| |<.................| |
	| |Need Authorization| |
	| NSIS Init msg | | |
	| ----------------> | | |
	| Scoped to last | | |
	| succeeded state | | |
	|installation hop | | |
	| | | |
	| | | |
	| NSIS Init msg Ack | | |
	| No NR | | |
	| <.................| | |
	Figure 16
	Since the signaling is unilateral (no NI available to do the
	installation for the other direction), the installed policy rules
	should be bi-directional. Although bi-directional policy rules could
	be problematic as discussed in [1], it is the only solution available
	when no remote NI would be available.
	3.3 Co-existence with existing NAT traversal mechanisms
	Section 3.1 discussed how a NATFW NE could be used when an NSIS
	un-aware NAT is deployed within the network infrastructure. This
	section discusses how the NATFW NSLP could co-exist with interim NAT
	traversal mechanisms [10]. In Figure 17, a STUN client (Host A) [7],
	an NE (host B), a host using a Media Proxy [10] and host using a TURN
	client [11] co-exist in the same network with a NATFW NSLP aware NAT.
	There are no reasons for the existing mechanisms to be mutually
	exclusive every host could continue using the existing interim
	solutions, meanwhile the unilateral NSIS signaling would be used
	until both ends support the NSIS NATFW NSLP.
	+---------------------------+
	| _|__1______.STUN Server
	|STUN Client ----'''''''''' |
	| Host A | App server
	| 2 _..NAT++ | .-'
	| NI/NR __.--'' | 3 .'+
	| Host B -'' | Media Proxy.-'
	| |
	| |
	| Host C |
	| 4 |
	| Turn Client---------------+---------- TURN Server
	| Host D |
	| |
	+---------------------------+
	Figure 17
	3.4 NSIS protocol traversal of NSIS Unaware Firewalls and NATs
	3.4.1 NSIS protocol traversal of NSIS Unaware Firewalls		5. NSIS unaware Firewall Traversal
	In case an NSIS unaware firewall is traversed by NSIS messages, NSIS		In case an NSIS unaware firewall is traversed by NSIS messages, NSIS
	messages should be allowed to go through it, as well as the exchanged		messages should be allowed to go through it, as well as the exchanged
	data flows between the user application clients. This is not		data flows between the user application clients. This is not
	necessarily an obvious task to perform in case the NSIS messages		necessarily an obvious task to perform in case the NSIS messages
	can't be identified by the NSIS unaware firewall. Same applies for		cannot be identified by the NSIS unaware firewall. Same applies for
	the user application data flows.		the user application data flows.
	NSIS message identification should be supported by existing		NSIS message identification should be supported by existing
	firewalls.		firewalls.
	Currently firewalls support flow identification by using the 5 tuple		Currently firewalls support flow identification by using the 5 tuple
	or a sub-set of it. We can not assume that the firewall will support		or a sub-set of it. The authors are still expecting feedback from
	the router alert option [14], hence it should not be the only element		firewall vendors to see if we can assume that existing firewalls will
	of the used identification filter.		not drop packets including the the Router Alert Option (RAO) [12]. In
			case existing firewalls drop packets having the router alert option,
			then the RAO should not be the only element of the used
			identification filter.
	User application data flow identification, should be deterministic at		User application data flow identification, should be deterministic at
	a specific address and port range level. This means that the		a specific address and port range level. This means that the
	application clients uses a combination of an address and specific		application clients uses a combination of an address and specific
	transport port range. This combination should be configured on the		transport port range.This combination should be configured on the
	firewall.		firewall.
	+-----------------------+ ++-------------------+
	| | | +-----+
	|+------+ | | | AC |
	||AC | | ,-=.----.-. | |NI/NR|
	||NI/NR + Qos++ -----'The net ----Qos++ FW +-----+
	|+------+ | `---------' | Host B |
	| Host A | | |
	| | | |
	+-----------------------+ +--------------------+
	FW: NSIS unaware FW
	Qos++: NE with Qos NSLP
	Figure 18
	3.4.1.1 NSIS protocol traversal of a mix of NSIS Unaware Firewalls and
	NSIS aware NATs
	In case a NAT is deployed on the path and it is NSIS-NATFW, the		In case a NAT is deployed on the path and it is NSIS-NATFW, the
	assigned bind should be consistent with policy rules configured with		assigned bind should be consistent with policy rules configured with
	the NSIS unaware firewall.		the NSIS unaware firewall.
	+-----------------------+ ++-------------------+		Even though the deployed Firewall is not NSIS aware, the application
	| | | +-----+		data would still be forwarded if existing interim solutions were used
	|+------+ | | | AC |		such as a mix of stateless policy rules and flow based states with
	||AC | | ,-=.----.-. | |NI/NR|		initial packets sent in the outbound direction (inside to outside a
	||NI/NR + NATFW++ Qos++------'The net `----Qos++ FW +-----+		trust domain).
	|+------+ | `---------' | Host B |
	| Host A | | |
	| | | |
	+-----------------------+ +--------------------+
	FW: NSIS unaware FW
	Qos++: NE with Qos NSLP
	NATFW++: NSIS aware NATFW
	Policy rules configured on the NSIS unaware FW to allow
	specific filters for NSIS signaling and user Application data flows
	Figure 19
	Even though the deployed FW is not NSIS aware, the application data
	would still be forwarded if existing interim solutions were used such
	as a mix of stateless policy rules and flow based states with initial
	packets sent in the outbound direction (inside to outside a trust
	domain).
	3.4.1.2 NSIS protocol traversal of NSIS Unaware NATs		6. NATFW NSLP NTLP requirements
	NATs create an address bind state for flows having well known		In this section we list two requirements for the NTLP raised by this
	patterns part of a predefined filter matching expression. In most		document.
	cases the patterns consist of the protocol number within the IP
	header and transport port numbers. When a packet flow has different
	paterns within in its filter matching expression, not all NATs will
	be able to forward the packets. When several NEs are deployed behind
	NATs, a mandatory demultiplexing field is required for the NSIS
	protocol in order to match a source or destination to another source
	or destination. Prior to the NSIS protocol, NATs had to work with
	IPSEC before IPSEC UDP encapsulation was used ([4]), the SPI
	parameter was used as demultiplexing field, but this capability was
	not native in all NATs. Hence IPSEC had to wait for UDP encapsulation
	to be be forwarded through consumer market NATs. The learned lesson
	is that the best approach for the NSIS protocol to be backward
	compatible with existing NATs, would be to be transported over
	existing transport protocols and not to be sent as raw IP payload.
	4. NATFW NSLP NTLP requirements		o When NSIS signaling is used in presence of NSIS unware NATs then
			raw IP MUST NOT be used. Network address and port translation
			requires transport layer identifiers as mean to direct inbound
			traffic to the right recipient.
	The NATFW NSLP transition requires the NTLP to change transport		o If IPsec is used to secure NSIS signaling messages then UDP
	protocol to UDP when the data is transported over UDP, as discussed		encapsulation for IPsec protected packets (see [4]) MUST be used
	in Section 3.1.		to ensure that IPsec does not break. IKE with extensions or IKEv2
			is able to detect the presence of a NAT along the path.
	If the valid next neighbor determination described in Section 3.2, is		7. Security Considerations
	applicable to other NSLPs it would potentially make sense to have a
	part of it incorporated in the NTLP. Further investigation would be
	required to define what should be done in the NTLP (NSLP independent)
	and what should be done within the NSLP.
	The NATFW NSLP does not have any next NSIS hop failure detection		This document discusses various security issues for NAT/Firewall
	mechanism, the NSLP relies on the the NTLP layer for this capability.		signaling in migration scenarios.
	NTLP security requirements: TBD		Further security considerations can be found in [2].
	5. Security Considerations		8. Open issues
	Section Section 3.2 and [1] discuss the security considerations for		Working on this document we identified to the following open issues
	the NSIS NATFW NSLP.		and actions that need to be taken:
	6. IANA Considerations		o Add a network centric solution to address interim deployment
			phases where the end host doesn't support yet the NSIS protocol
			suite.
	There are no IANA considerations defined in this document.		o Provide updates on the RAO firewall issues
	7. Open Issues		o Update Section 3 with regards to the multiplexing/demultiplexing
			of NSIS messages and user data on the same socket.
	Need to close on: the intra-realm security issues, the editorial		o Move the mediated authorization discussion in Section 4 to [2]
	issues, linking the authorization token with the NI cryptographic
	authentification mechanisms, NTLP required NAT handling capabilities.
	Normative References		Normative References
	[1] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H.,		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Schulzrinne, H. and C. Aoun, "A NAT/Firewall NSIS Signaling		Levels", March 1997.
	Layer Protocol (NSLP)", DRAFT draft-ietf-nsis-nslp-natfw-00.txt,
	October 2003.
	Informative References		[2] Stiemerling, M., Martin, M., Tschofenig, H. and C. Aoun, "A NAT/
			Firewall NSIS Signaling Layer Protocol (NSLP)", DRAFT
			draft-ietf-nsis-nslp-natfw-01.txt, February 2004.
	[2] Draves, R., "Default Address Selection for Internet Protocol		[3] "GIMPS: General Internet Messaging Protocol for Signaling",
	version 6 (IPv6)", RFC 3484, February 2003.		draft-draft-ietf-nsis-ntlp-00 (work in progress), October 2003.
	[3] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A		Informative References
	Methodology for Network Address Translator (NAT) Traversal for
	the Session Initiation Protocol (SIP)", DRAFT
	draft-rosenberg-sipping-ice-01.txt, June 2003.
	[4] A. Huttunen et all, A., "UDP Encapsulation of IPsec Packets",		[4] A. Huttunen et all, A., "UDP Encapsulation of IPsec Packets",
	DRAFT draft-camarillo-mmusic-alt-01.txt, Jan 2003.		DRAFT draft-ietf-ipsec-udp-encaps-07.txt, Jan 2003.
	[5] Camarillo, J. and J. Rosenberg, "The Alternative Semantics for
	the Session Description Protocol Grouping Framework", DRAFT
	draft-camarillo-mmusic-alt-01.txt, June 2003.
	[6] Rosenberg, J., "The Real Time Transport Protocol (RTP) Denial
	of Service (Dos) Attack and its Prevention", DRAFT
	draft-camarillo-mmusic-alt-01.txt, June 2003.
	[7] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -		[5] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN -
	Simple Traversal of User Datagram Protocol (UDP) Through		Simple Traversal of User Datagram Protocol (UDP) Through
	Network Address Translators (NATs)", RFC 3489, March 2003.		Network Address Translators (NATs)", RFC 3489, March 2003.
	[8] Handley, M. and V. Jacobson, "SDP: Session Description		[6] Handley, M. and V. Jacobson, "SDP: Session Description
	Protocol", RFC 2327, April 1998.		Protocol", RFC 2327, April 1998.
	[9] ITU-T SG16, "Packet-based multimedia communications systems",		[7] ITU-T SG16, "Packet-based multimedia communications systems",
	ITU-T H.323, November 2000.		ITU-T H.323, November 2000.
	[10] Rosenberg, J., "NAT and Firewall Scenarios and Solutions for		[8] Rosenberg, J., "NAT and Firewall Scenarios and Solutions for
	SIP", draft-rosenberg-sipping-nat-scenarios-00 (work in		SIP", draft-rosenberg-sipping-nat-scenarios-00 (work in
	progress), November 2001.		progress), November 2001.
	[11] Rosenberg, J., "Traversal Using Relay NAT (TURN)",		[9] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
	draft-rosenberg-midcom-turn-01 (work in progress), March 2003.		draft-rosenberg-midcom-turn-01 (work in progress), March 2003.
	[12] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore,		[10] Swale, R., Mart, P., Sijben, P., Brim, S. and M. Shore,
	"Middlebox Communications (midcom) Protocol Requirements", RFC		"Middlebox Communications (midcom) Protocol Requirements", RFC
	3304, August 2002, <reference.RFC.3304.xml>.		3304, August 2002.
	[13] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session		[11] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session
	Set-up with Media Authorization", RFC 3521, April 2003,		Set-up with Media Authorization", RFC 3521, April 2003.
	<reference.RFC.3521.xml>.
	[14] Katz, D., "IP Router Alert Option", RFC 2113, February 1997,		[12] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
	<reference.RFC.2113.xml>.
			[13] Manner, J., "Localized RSVP", draft-manner-lrsvp-03 (work in
			progress), January 2004.
	Authors' Addresses		Authors' Addresses
	Cedric Aoun		Cedric Aoun
	Nortel Networks		Nortel Networks
	France		France
	EMail: cedric.aoun@nortelnetworks.com		EMail: cedric.aoun@nortelnetworks.com
	Marcus Brunner		Marcus Brunner
	Network Laboratories, NEC Europe Ltd.		Network Laboratories, NEC Europe Ltd.
	Kurfuersten-Anlage 36		Kurfuersten-Anlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 (0) 6221 905 11 29		Phone: +49 (0) 6221 905 11 29
	EMail: brunner@ccrle.nec.de		EMail: brunner@ccrle.nec.de
	URI: http://www.brubers.org/marcus		URI: http://www.brubers.org/marcus
	skipping to change at page 30, line 29 ¶		skipping to change at page 20, line 29 ¶
	be obtained from the IETF Secretariat.		be obtained from the IETF Secretariat.
	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 which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 91 change blocks.
	669 lines changed or deleted		244 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/