draft-aoun-nsis-nslp-natfw-intrarealm-00.txt		draft-aoun-nsis-nslp-natfw-intrarealm-01.txt
	NSIS Working Group C. Aoun		NSIS Working Group C. Aoun
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: August 9, 2004 M. Brunner		Expires: January 17, 2005 H. Tschofenig
			Siemens
	M. Stiemerling		M. Stiemerling
			M. Brunner
	M. Martin		M. Martin
	NEC		NEC
	H. Tschofenig		July 19, 2004
	Siemens
	February 9, 2004
	NATFirewall NSLP Intra-realm considerations		NAT/Firewall NSLP Intra-Realm Considerations
	draft-aoun-nsis-nslp-natfw-intrarealm-00		draft-aoun-nsis-nslp-natfw-intrarealm-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		By submitting this Internet-Draft, I certify that any applicable
	all provisions of Section 10 of RFC2026.		patent or other IPR claims of which I am aware have been disclosed,
			and any of which I become aware will be disclosed, in accordance with
			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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as
			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 http://		The list of current Internet-Drafts can be accessed at
	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 August 9, 2004.		This Internet-Draft will expire on January 17, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document discusses NAT/FW NSLP intra-realm issues and solutions.		This document discusses NAT/FW NSLP issues and solutions for cases
	The document will serve as input to the NSIS NATFW NSLP document.		where NATFW NSLP NEs within the same addressing realm communicate
			with each other. The document will serve as input to the NSIS NAT/FW
			NSLP document to meet these intra-realm communications' requirements.
	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. Potential solutions to the problem . . . . . . . . . . . . . . 9		4. Solution Approaches . . . . . . . . . . . . . . . . . . . . 9
	4.1 Intra realm solution protocol operation impacts . . . . . . . 12
	4.2 Intra realm solution application protocols impacts . . . . . . 13
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 14		5. Security Considerations . . . . . . . . . . . . . . . . . . 14
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. Application Signaling Protocol Impacts . . . . . . . . . . . 15
	7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 16		7. NATFW NSLP required extensions . . . . . . . . . . . . . . . 16
	Normative References . . . . . . . . . . . . . . . . . . . . . 17		8. Perfomance considerations . . . . . . . . . . . . . . . . . 19
	Informative References . . . . . . . . . . . . . . . . . . . . 18		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19		10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . 21		11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 22
			12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 23
			13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
			13.1 Normative References . . . . . . . . . . . . . . . . . . . 24
			13.2 Informative References . . . . . . . . . . . . . . . . . . 24
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25
			Intellectual Property and Copyright Statements . . . . . . . 27
	1. Introduction		1. Introduction
	The NSIS NATFW NSLP responder provides the NSIS NATFW NSLP Initiator		The NSIS NATFW NSLP responder provides the NSIS NATFW NSLP Initiator
	with its address, in some cases the NSIS responder may have several		with its address, in some cases the NSIS responder may have several
	addresses: a (or several) global scoped address and its locally		addresses: one (or several) global scoped address and its locally
	scoped address(es). Which address does it provide to the NSIS		scoped address(es).
	initiator? This document will cover the NSIS Responder address
	selection as well as the impact on the applications and the NSIS		The following question arises: Which address does it provide to the
	protocol suite. The document will serve as input to the NSIS WG		NSIS initiator?
	documents.
			This document will cover the NSIS Responder address selection as well
			as the impact on applications and the NSIS protocol suite. The
			document will serve as input to the NSIS WG documents.
	2. Terminology		2. Terminology
	The terminology used in this document is defined in [1]		The terminology used in this document is defined in [1].
	3. Problem statement		3. Problem statement
	An NSIS Element hosting an NSIS NATFW NSLP may have more than one		An NSIS Element hosting an NSIS NATFW NSLP may have more than one
	address, its local scoped address(es) and global scoped address(es).		address, its local scoped address(es) and global scoped address(es).
	A default address selection that priorities arbitrarily a global		A default address selection that priorities a global scoped address
	scoped address over a local scoped address may imply none optimal		over a local scoped address arbitrarily may imply non-optimal routing
	routing for communications between NSIS elements hosted within the		for communication between NSIS elements hosted within the same
	same addressing realm.		addressing realm. For certain NAT/Firewall implementations it is not
			only a matter of path optimization: if a global scoped address is
			used to reach an internal host, the NSIS messages may get dropped due
			to a conflict with the anti-spoofing rules on the NAT/Firewall NE,
			hence no communication could be established.
	In Figure 1 the arbitrary selection of the global scoped address,		In Figure 1 the arbitrary selection of the global scoped address,
	works properly to receive NSIS signaling from Host B. However in		works properly to receive NSIS signaling from Host B. However in
	deployment scenario shown in Figure 2, host A and host C end-up		deployment scenario shown in Figure 2, host A and host C end-up
	communicating through their local MB1 middlebox resulting in a non		communicating through their local MB1 middlebox resulting in a non
	optimal data path with all its implications (additional delay,		optimal data path with all its implications (for example, additional
	additional bandwidth in certain parts of the network infrastructure,		delay or additional bandwidth consumption in certain parts of the
	etc ...).		network).
	+---------------------+ +--------------------+		+---------------------+ +--------------------+
	| | | |		| +------+ | | +------+ |
	| Host A | ,-----------. | Host B |		| |Host A| | ,-----------. | |Host B| |
	| +-----+| ,-'The NET `-. | |		| +------+ +-----+| ,-' Public `-. | +------+ |
	| | MB1 |+-- --+ |		| | MB1 |+-- Internet --+ |
	| +-----+| `-. ,-' | |		| +-----+| `-. ,-' | |
	| | `-----------' | |		| | `-----------' | |
	| | | |		|Network A | | Network B|
	+---------------------+ +--------------------+		+---------------------+ +--------------------+
	MB: Middle box (NAT or Firewall or a combination)		MB: Middle box (NAT or Firewall or a combination)
	Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities		Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities		Host B: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Figure 1		Figure 1: Intra-Realm Signaling Scenario
	+---------------------+ +--------------------+
	| | | |
	| Host A`-. | ,-----------. | Host B |
	| `. +-----+| ,-'The NET `-. | |
	| i.. MB1 |+-- --+ |
	| Host C_.-'' +-----+| `-. ,-' | |
	| | `-----------' | |
	| | | |
	+---------------------+ +--------------------+		+---------------------+ +--------------------+
			|+------+ | | +------+ |
			||Host A|-. | ,-----------. | |Host B| |
			|+------+ `. +-----+| ,-' Public `-. | +------+ |
			|+------+ i.. MB1 |+-- Internet --+ |
			||Host C|.-'' +-----+| `-. ,-' | |
			|+------+ | `-----------' | |
			| | | Network B|
			|Network A | +--------------------+
			+---------------------+
	MB: Middle box (NAT or Firewall or a combination)		MB: Middle box (NAT or Firewall or a combination)
	Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities		Host A: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Host B: 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		Host C: An NE hosting NSIS NATFW NSLP NI/NR capabilities
	Figure 2		Figure 2: Intra-Realm Signaling Scenario
	Figure 3 and Figure 4, show clearly the impact when the global scoped		Figure 3 and Figure 4, show clearly the impact when the global scoped
	address is used to signal an NE within the same addressing realm.		address is used to signal an NE within the same addressing realm.
	Figure 3 show how host A will use the Reserve External Address		Figure 3 show how host A will use the Reserve External Address
	(defined in [1] to get its global scoped address (i.e. the external		message (defined in [1] to get its global scoped address (i.e. the
	address), same happens to host B. Figure 4 shows how the CREATE/		external address), same happens to host B. Figure 4 shows how the
	CREATE ACK message (defined in [1]) are exchanged to host B/A global		CREATE/RESPONSE messages (defined in [1]) are exchanged to host B/A
	addresses and the impact on the data path.		global addresses and the impact on the data path.
	Host C Host A MB1 App server/proxy		Host C Host A MB1 App server/proxy
	10.1.2.3 10.1.2.2 a.b.c.e a.b.c.e		10.1.2.3 10.1.2.2 a.b.c.e a.b.c.d
	| | REA | |		| | REA | |
	| | -------------> | |		| | -------------> | |
	| | REA ACK | |		| | RESPONSE | |
	| | <------------- | |		| | <------------- | |
	| | a.b.c.e | |		| | External | |
	| | |		| |Address=a.b.c.e | |
	| | start-app with C |		| | start-app with C |
	| | ==============================> |		| | ==============================> |
	| | from A at a.b.c.e |		| | from A at a.b.c.e |
	| |		| | | |
	| start-app with C | |		| start-app with C | |
	| <============================================= |		| <============================================= |
	| from A at a.b.c.e |		| from A at a.b.c.e | |
	| |		| | |
	| REA | |		| REA | |
	| -----------------------> | |		| -----------------------> | |
	| REA ACK | |		| RESPONSE | |
	| <------------------------ | |		| <------------------------ | |
	| a.b.c.e | |		| External Address= a.b.c.e | |
	| | |		| | |
	| start-app with C ACK C:a.b.c.e |		| start-app with C ACK C:a.b.c.e |
	| ==========================================> |		| ==========================================> |
	| from A at a.b.c.e |		| from A at a.b.c.e |
	--- NATFW NSLP signaling		--- NATFW NSLP signaling
	=== User Application signaling (SIP, H323, MGCP, MEGACO etc)		=== User Application signaling (SIP, H323, MGCP, MEGACO etc)
	Figure 3		Figure 3: Message flow for routing via the Middlebox
	Host C Host A MB1 App server/proxy		Host C Host A MB1 App server/proxy
	10.1.2.3 10.1.2.2 a.b.c.e a.b.c.e		10.1.2.3 10.1.2.2 a.b.c.e a.b.c.d
	| | CREATE | |		| | CREATE | |
	| | -------------> |--, |		| | -------------> |--, |
	| | | | |		| | | | |
	| | | | |		| | | | |
	| | CREATE | | |		| | CREATE | | |
	| <---------------------------- |<-' |		| <---------------------------- |<-' |
	| CREATE ACK | | |		| RESPONSE | | |
	| ----------------------------> |--, |		| ----------------------------> |--, |
	| | CREATE ACK | | |		| | RESPONSE | | |
	| |<------------- |<-' |		| |<------------- |<-' |
	| | | |		| | | |
	| App signaling | |		| App signaling | |
	| continues ... |		| continues ... |
	| <==============================================> |		| <==============================================> |
	| <================================> |		| <================================> |
	|<+++++++++++++++++++++++++++++++\ |		|<+++++++++++++++++++++++++++++++++ |
	| | App data | | |		| | App data | | |
	| |<++++++++++++++++++ |		| |<++++++++++++++++++ |
	| | | |		| | | |
	| | | |		| | | |
	---- NATFW NSLP signaling		---- NATFW NSLP signaling
	==== User Application signaling (SIP, H323, MGCP, MEGACO etc)		==== User Application signaling (SIP, H323, MGCP, MEGACO etc)
	Figure 4		Figure 4: NSIS signaling for routing via the Middlebox
	4. Potential solutions to the problem		4. Solution Approaches
	There are two ways to deal with this non-optimal routing of packets		There are two ways to deal with this non-optimal routing of packets
	for intra-realm communications between NSIS entities. The NSIS		for intra-realm communications between NSIS entities. The NSIS
	Responder should either:		Responder could either:
			1. Use a local policy to decide which address to provide to the NSIS
	1. Decide based on local decision, which address to provide to the		Initiator
	NI to signal it or,		2. Make all addresses available to the NSIS Initiator to let it
			decide which address to use
	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		Approach (1) lets the NSIS Responder decide on its own, which address
	provide based on certain hints, which may not be the most optimal		to provide based on certain hints, which may not be the most optimal
	decision since the NSIS Responder may not have sufficient knowledge		decision since the NSIS Responder may not have sufficient knowledge
	about the NSIS Initiator at the time of delivering its address via		about the NSIS Initiator at the time of delivering its address via
	user applications. In most cases local decision for address selection		user applications. In most cases local decision for address
	requires to know about the far end host, which is not always		selection requires knowledge about the far end host. This might not
	practical.		always be practical.
	An example of such local based address selection is the IPv6 default		An example of such local based address selection is the IPv6 default
	address selection mechanism ([2]) where an IPv6 (or IPv6/v4) node has		address selection mechanism (see [6]) where an IPv6 (or IPv6/v4) node
	to select which source and destination address to pick in order to		has to select which source and destination address to pick in order
	communicate with a far end node. The mechanism relies on receiving		to communicate with a far end node. The mechanism relies on
	input from the local resolver (DNS client or local hosts file) about		receiving input from the local resolver (DNS client or local hosts
	the far end node. In the context of multimedia applications (and		file) about the far end node. In the context of multimedia
	probably others as well), this address selection mechanism will not		applications (and probably others as well), this address selection
	be sufficient since the far end application device is not necessarily		mechanism will not be sufficient since the far end application device
	known (the resolver client may return the address(es) of the		is not necessarily known (the resolver client may return the
	application signaling and not the addresses of the actual application		address(es) of the application signaling and not the addresses of the
	data flow recipient). Hence it can not decide successfully in all		actual application data flow recipient). Hence it can not decide
	cases which address to provide to the NSIS Initiator.		successfully in all cases which address to provide to the NSIS
			Initiator.
	(2) is more efficient as it requires the NSIS Responder to provide		Approach (2) is more efficient as it requires the NSIS Responder to
	all its addresses (local scoped and global scoped ones) to the NSIS		provide all its addresses (local scoped and global scoped ones) to
	Initiator. The NSIS Initiator will need to decide on which address to		the NSIS Initiator. The NSIS Initiator needs to decide which address
	signal the NSIS Responder among all the provided ones. One possible		to use. One possible way for the NSIS Initiator to decide which NSIS
	way for the NSIS Initiator to decide from which NSIS Responder		Responder address to use is to check which address the NSIS responder
	address to use is to check on which address the NSIS responder will		will reply back. This security mechanism is typically referred as
	reply back. An existing proposal [3] discusses the usage of (2) for		return-routability check. ICE [7] discusses the usage of approach
	SIP User Agents (SIP UA), the SIP UA will probe the far end SIP UA to		(2) for SIP User Agents (SIP UA) whereby the SIP UA will probe the
	see from which address it will response back. In [3], the STUN		far end SIP UA to see from which address it will send a response back
	protocol [7] is used to check the responsiveness of the far end host.		to the probe. ICE [7] uses the STUN protocol [14] for the
	In [6] the reverse routability, provided by the STUN response, is		return-routability check. In [9] the reverse routability, provided
	used to check which address to respond to counters RTP DOS attacks.		by the STUN response, is used to check which address to respond to
	The same reverse routability could be achieved by the NSIS NATFW		counter RTP Denial of Service attacks. The same reverse routability
	NSLP.		check could be achieved by the NSIS NATFW NSLP.
	In the context of NSIS, the NSIS protocol itself should be used as		In the context of NSIS, the NSIS protocol itself should be used as
	the probing mechanism. Consequently the NSIS Initiator will send		the probing mechanism. Consequently, the NSIS Initiator will
	simultaneously several NSIS messages towards the NSIS Responder, one		simultaneously send several NSIS messages towards the NSIS Responder,
	message per provided address. Figure 5 and Figure 6 provide a good		one message per provided address. Figure 5 and Figure 6 show
	view of method (2).		approach (2) graphically.
	Host C Host A MB1 App server/proxy		Host C Host A MB1 App server/proxy
	10.1.2.3 10.1.2.2 a.b.c.e a.b.c.e		10.1.2.3 10.1.2.2 a.b.c.e a.b.c.d
	| | REA | |		| | REA | |
	| | -------------> | |		| | -------------> | |
	| | REA ACK | |		| | RESPONSE | |
	| | <------------- | |		| | <------------- | |
			| |External Address| |
	| | a.b.c.e | |		| | a.b.c.e | |
	| | |
	| | start-app with C |		| | start-app with C |
	| | ==============================> |		| | ==============================> |
	| | from A at 10.1.2.2,a.b.c.e |		| | from A at 10.1.2.2,a.b.c.e |
	| |		| |
	| start-app with C | |		| start-app with C | |
	| <============================================= |		| <============================================= |
	| from A at 10.1.2.2,a.b.c.e |		| from A at 10.1.2.2,a.b.c.e |
	| |		| |
	| REA | |		| REA | |
	| -----------------------> | |		| -----------------------> | |
	| REA ACK | |		| RESPONSE | |
	| <------------------------ | |		| <------------------------ | |
	| a.b.c.e | |		| External Address=a.b.c.e | |
	| | |		| | |
	| start-app with C ACK C:10.1.2.3,a.b.c.e |		| start-app with C ACK C:10.1.2.3,a.b.c.e |
	| ==========================================> |		| ==========================================> |
	| from A at 10.1.2.2,a.b.c.e |		| from A at 10.1.2.2,a.b.c.e |
	' ' '		' ' '
	---- NATFW NSLP signaling		---- NATFW NSLP signaling
	==== User Application signaling (SIP, H323, MGCP, MEGACO etc)		==== User Application signaling (SIP, H323, MGCP, MEGACO etc)
	Figure 5		Figure 5: Message flow for optimal routing
	In Figure 5 Host A (same one as in Figure 2) a Reserve External		In Figure 5 Host A (same one as in Figure 2) uses a Reserve External
	Address (REA) message which is intercepted by the edge NAT (in this		Address (REA) message which is intercepted by the edge NAT (in this
	case MB1). The edge NAT responds with a REA ACK message providing the		case MB1). The edge NAT responds with a RESPONSE message providing
	External Address (the global scoped address) to host A. Once host A		the External Address (the global scoped address) to host A. Host A,
	has collected all the addresses where it could receive application		collects all available addresses where it could receive application
	data it informs its Application server about the remote application		data, and then informs its application server that it wishes to
	party as well as host A's data recipients addresses (and ports),		communicate with Host C while receiving data on the global and local
	10.1.2.2 and a.b.c.e. The same will happen with Host C, and Host C		scoped address (and ports), 10.1.2.2 and a.b.c.e. The same will
	will be able to respond with the application protocol to Host A about		happen with Host C, and Host C will be able to respond with the
	its data recipient addresses (local and global scoped ones). Figure 6		application protocol to Host A about its data recipient addresses
	shows how the CREATE messages are simulatenously sent by A to all the		(local and global scoped ones). Figure 6 shows how the CREATE
	returned addresses for C. Host A receives both CREATE ACKs, the local		messages are simultaneously sent by A to all the returned addresses
	scoped address will therefore be considered as the address to use to		for C. Host A receives both CREATE ACKs, the local scoped address
	send NSIS NATFW messages to C. Since no NSIS aware NAT and Firewalls		will therefore be considered as the address to use to send NSIS NATFW
	are on the path between host A and host C (when using local scoped		messages to C. The problem is that an NSIS host might not be able to
	addresses), host A would either send a DELETE message or let the NSIS		distinguish a global scoped address from a local scoped address. To
	state expire on its own.		cope with that problem, the following method is proposed:
			The NATFW NSLP will have a NAT counter object, inserted in CREATE
			messages and echoed back within CREATE responses. Every time an NSIS
			aware NAT is traversed the NAT counter object is incremented. When
			the NI host receives several RESPONSE messages, it will compare the
			received NAT counter objects, the NR that responded with the smallest
			NAT count will be the NR with which the NI will continue
			communicating with.
			In Figure 6, since no NSIS aware NAT (one returned NAT counter was 0)
			and no Firewalls (NTLP layer [2] confirmed that there was no NATFW
			NSLP intermediaries) are on the path between host A and host C (when
			using the local scoped addresses), host A would either send a DELETE
			message or let the NSIS state expire on its own; the NATFW NSLP
			protocol is sufficiently robust to handle both. The behavior is left
			to implementors and network administrators, since it has performance
			implications.
	Host C Host A MB1 App server/proxy		Host C Host A MB1 App server/proxy
	10.1.2.3 10.1.2.2 a.b.c.e a.b.c.e		10.1.2.3 10.1.2.2 a.b.c.e a.b.c.e
	| | CREATE 2 | |		| | CREATE 2 | |
	| CREATE 1 | -------------> |--, |		| CREATE 1 | -------------> |--, |
	| <------------| | | |		| <------------| NAT count=0 | | |
	| CREATE ACK 1 | | | |		|RESPONSE1 | | |NAT count=1 |
	| ------------>| CREATE 2 | | |		| ------------>| | | |
			|NAT count=0 | | | |
			| CREATE 2 | | |
	| <---------------------------- |<-' |		| <---------------------------- |<-' |
	| CREATE ACK 2| | |		| RESPONSE 2 | | |
	| ----------------------------> |--, |		| ----------------------------> |--, |
	| | CREATE ACK 2 | | |		| | RESPONSE 2 | | |
	| |<------------- |<-' |		| |<------------- |<-' |
	| | |		| | NAT count=1 | |
	| App signaling |		| App signaling |
	| continues ... |		| continues ... |
	<==============================================> |		<==============================================> |
	<================================> |		<================================> |
	|+++++++++++> | |		|+++++++++++> | |
	| App data | |		| App data | |
	|<+++++++++++ | |		|<+++++++++++ | |
	| exchanges | |		| exchanges | |
	| | |		| | |
	|		|
	---- NATFW NSLP signaling		---- NATFW NSLP signaling
	==== User Application signaling (SIP, H323, MGCP, MEGACO etc)		==== User Application signaling (SIP, H323, MGCP, MEGACO etc)
	Figure 6		Figure 6: NSIS signaling for optimal (intra realm) routing
	The following occur during the process:		With regard to the message flow in Figure 6 we can distinguish
			between the following cases:
			o In case that the NSIS Responder and the NSIS Initiator are located
			within the same addressing realm, the NSIS Responder should
			receive a response from all the addresses to which an NSIS message
			was sent. The NSIS Initiator will then choose the address from
			which RESPONSE message was returned with the smallest NAT counter,
			as the destination address for messages destined to the NSIS
			Responder.
			o In case that the NSIS Responder and the NSIS Initiator are not
			located within the same addressing realm, the NSIS Initiator would
			only receive a response from the valid global scope address. In
			case 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), Section 5
			discusses the related security implications for this behavior.
			This requires that the NR knows if it is the intended recipient,
			this knowledge could be provided by the user application which is
			aware of the application context requiring the establishment of an
			NSIS session. However this assumption is no longer valid during
			migration phases where a proxy operation mode is required ([1] and
			[10]).
	o In case the NSIS Responder and Initiator are located within the		5. Security Considerations
	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		Deployments having NRs with local scoped and global scoped address,
	the same addressing realm, the NSIS Initiator would only receive a		are subject to the same threats as the ones discussed in [4], [5] and
	response from the valid global scope address. In event that there		[3] as well as to the potential threat where a malicious NE with the
	is another NE within the network that has the same local scoped		same local scoped address as the target NR respond back positively to
	address as the originally targeted NSIS Responder, the wrongly		the NSIS message and consequently hijack the data flow.
	targeted NSIS Responder should send back an error or discard the
	message (the later would be preferable).
	4.1 Intra realm solution protocol operation impacts		This threat could be counter-measured by requiring the NR to respond
			back with a challenge response information communicated by the
			application signaling (assuming that the application was secured).
			This type of end-to-end security mechanism (irrespectively which
			degree of security it offers) have an impact on NSIS signaling
			protocol and on the application layer protocol. If the responding NE
			is not the application end host then the protocol operation is made
			more complicated since the NE would have to act on behalf of the
			application end host. This would be the case when the application
			end host does not yet support the NATFW NSLP (this is the case of the
			proxy mode scenario discussed in [1] and [10]).
	As opposed to the normal NSIS mode of operation, an NI that has		To avoid the leakage of network topology information, when the CREATE
	already a security association with the neighboring NE on the path to		message is leaving the network the network Edge NAT or Edge Firewall
	a specific NR would need to verify that the target local scoped NR		supporting the NATFW NSLP will need to remove the NAT count object.
	address is the same as the one already cached in its NSIS neighbor
	table cache (association of Next hop NE with the target NR		6. Application Signaling Protocol Impacts
	table).This would be required to avoid any confusion with an NSIS
	node that could be hosted within the same addressing realm and that		The proposed intra realm path optimization proposal requires that an
	would have the same local scoped address.		NR provides several data recipient addresses within the application
	There is a potential threat where a malicious NE with the same local		protocol, has obviously a certain impact on the application protocol.
	scoped address as the target NR respond back positively to the NSIS		In addition the application signaling needs to provide a challenge
	message and consequently hijack the data flow. This threat could be		response allowing the NR to respond back properly. This information
	counter-measured by requiring the NR to respond back with a challenge		either need to be added to the application protocols or existing
	response information communicated by the application signaling		protocol fields need to be used (preferred way).
	(assuming that the application was secured).
			Certain applications already provide the ability to advertise several
			recipient addresses, [8] discusses the impact to SDP [11] 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 [12] and others requiring usage of NSIS with multiple
			addresses for the NR.In addition [7] proposes the usage of a
			challenge response parameter within SDP in the context of
			applications using SIP, a similar approach should be used for other
			applications.
			7. NATFW NSLP required extensions
			As shown in Section 4, to solve the intra-realm problem a new object
			is required for the NATFW NSLP, a NAT count object. It is suggested
			that this parameter be used in all CREATE messages ([1]).
			Another required change for the NATFW NSLP are more of behavioral
			type:
			None Edge-NAT NATs traversed by REA messages: when the Edge NAT
			responds to REA messages, these NATs will add to the RESPONSE message
			an External Address object. This new behavior will allow the support