draft-aoun-nsis-nslp-natfw-migration-01.txt		draft-aoun-nsis-nslp-natfw-migration-02.txt
	NSIS Working Group C. Aoun		NSIS Working Group C. Aoun
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: August 16, 2004 M. Brunner		Expires: January 17, 2005 H. Tschofenig
			Siemens
	M. Stiemerling		M. Stiemerling
	M. Martin
	NEC		NEC
	H. Tschofenig		July 19, 2004
	Siemens
	February 16, 2004
	NAT/Firewall NSLP Migration Considerations		NATFW NSLP Migration Considerations
	draft-aoun-nsis-nslp-natfw-migration-01		draft-aoun-nsis-nslp-natfw-migration-02
	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 16, 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 migration issues towards NSIS NAT/FW NSLP		This document discusses migration issues towards NSIS NAT/FW NSLP
	enabled NATs and Firewalls. The document will serve as input to the		enabled NATs and Firewalls. In particular traversal of NSIS unaware
	NSIS NATFW NSLP document.		NATs and NSIS proxy scenarios are addressed. This document will
			serve as input to the NSIS NATFW NSLP document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. NSIS unaware NAT Traversal . . . . . . . . . . . . . . . . . . 5		3. Traversal of NSIS unaware NATs . . . . . . . . . . . . . . . . 5
			3.1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . 5
			3.2 Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
			3.3 Class 1 NAT Handling . . . . . . . . . . . . . . . . . . . 6
			3.4 Class 2 NAT Handling . . . . . . . . . . . . . . . . . . . 6
			3.5 Class 3 NAT Handling . . . . . . . . . . . . . . . . . . . 7
			3.6 Class 4 NAT Handling . . . . . . . . . . . . . . . . . . . 9
			3.7 Dealing with NSIS unaware NATs (Class 4 NAT Handling) . . 10
	4. Unilateral NSIS signaling . . . . . . . . . . . . . . . . . . 8		4. NSIS Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . 14
	5. NSIS unaware Firewall Traversal . . . . . . . . . . . . . . . 13		5. NSIS unaware Firewall Traversal . . . . . . . . . . . . . . . 17
	6. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . . . . 14		6. NATFW NSLP NTLP requirements . . . . . . . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	Normative References . . . . . . . . . . . . . . . . . . . . . 17		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
	Informative References . . . . . . . . . . . . . . . . . . . . 18		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
			11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
			11.2 Informative References . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
			Intellectual Property and Copyright Statements . . . . . . . . 25
	1. Introduction		1. Introduction
	The overall NSIS protocol suite (including the NATFW NSLP) is		This document discusses migration issues which are caused by the
	impacted by NSIS NATFW NSLP unaware NATs and Firewalls, this document		incremental deployment of NSIS NAT/Firewall NSLP nodes. As such, it
	covers impacts as well as some suggestions to ease the deployments of		is not only relevant for the NAT/FW NSLP but also for other NSLPs,
	the NSIS protocol suite until the installed base on NATs and		such as the QoS NSLP.
	Firewalls migrates to NSIS.
	The NATFW NSLP should allow an end host supporting NSIS to operate		o The overall NSIS protocol suite (including the NAT/FW NSLP) is
	properly without the need of supporting true end-to-end NSIS		impacted by NSIS unaware NATs and Firewalls. This document covers
	signaling to its application correspondent. This is very practical		the impacts as well as some suggestions to ease the deployments of
	during the initial phases of the NSIS migration and is applicable in		the NSIS protocol suite until the installed base of NATs and
	simple network configurations not affected by asymmetric routing. In		Firewalls migrates to NSIS. Section 3 addresses this issue.
	the early phases of the NSIS NATFW NSLP migration, this situation
	will occur quite frequent and hence this scenario must be supported.
	The NSIS protocol should traverse NSIS unaware NATs (and possibly		o The NAT/FW NSLP should allow an end host supporting NSIS to
	Firewalls) to allow a smoother deployment of, for example, Qos NSLP		operate properly without the need for supporting true end-to-end
	in today's networks. To provide a smooth migration it is necessary to		NSIS signaling to its application correspondent. This is very
	understand the coexistence of NSIS aware and unware NATs and		practical during the initial phases of the NSIS migration and is
	Firewalls.		applicable in simple network topologies. In the early phases of
			the NSIS NAT/FW NSLP migration, this situation will occur quite
			frequently, and hence this scenario must be supported. Section 4
			is addresses this scenario.
	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 [1].		document are to be interpreted as described in [RFC2119].
	The terminology used in this document is defined in [2].		The terminology used in this document is defined in [NSISNATFW].
	3. NSIS unaware NAT Traversal		3. Traversal of NSIS unaware NATs
	This section discusses how an NE with any NSLP could still operate		3.1 Abstract
	when an NSIS unaware NAT is on the data path. The detection of an
	NSIS unaware NAT could be a feature of the NTLP [3], allowing its
	usage on any NE regardless of the supported NSLPs.
	Several NSIS independent approaches could be used by the NE to learn		This section aims to describe different NAT handling classes in NSIS,
	its global scoped address in order to use it for its hosted NSLPs. In		and the relationship between different solutions provided in various
	this version of the document, only the STUN protocol [5] is		NSIS documents. After a short introduction in Section 3.2, different
	considered as means to acquire the global scoped address; the next		NAT classes are discussed in Section 3.2. Various NAT scenarios are
	versions will consider other approaches.		described in Section 3.3, in Section 3.4, in Section 3.5, and in
			Section 3.6. Section 3.7 covers the details of addressing NSIS
			unaware NATs.
			3.2 Introduction
			In the past, mainly two approaches have been used for establishing
			NAT bindings:
			Static configuration This type of NAT bindings is typically used to
			allow inbound initiated communications. Ephemeral binds are often
			not established or required.
			Dynamic configuration: Dynamic NAT binding creation can be
			categorized into one of the following three categories:
			* Implicit creation by outbound initiated communications. In
			this case, the translated address and port are selected from a
			configured address and port pool.
			* Explicit creation by an Application Layer Gateway (ALG) either
			via an API call (if the NAT and the ALG are co-located) or
			otherwise via a separate protocol.
			* Separate signaling protocols which request the creation of a
			NAT binding.
			An alternative classification can be done by considering the trigger
			for the creation of a NAT binding. In many cases an outbound data
			packet itself is used to cause the allocation of a NAT binding.
			Alternatively, a signaling protocol can be used to establish the same
			goal by directly addressing the NAT itself. The Midcom and the NSIS
			working group are trying to develop protocols of the latter category.
			To address the broad scope of NAT handling, this document tries to
			describe the design considerations for the work in the NSIS WG. An
			important impact for the design is caused by the introduction of the
			two layer architecture, by intermediaries, and by NSIS unaware NATS.
			Four classes of NAT functionality can be distinguished in NSIS.
			These are described in the following sub-sections.
			3.3 Class 1 NAT Handling
			We refer to Class 1 NAT handling if NATs or Firewalls implement the
			NAT/Firewall NSLP.
			Router 2+
			Host A NAT Firewall
			+--------+ +--------+ +--------+
			| NE | | NE | | NE |
			|+------+| |+------+| |+------+|
			||QoS+ || ||QoS+ || ||QoS+ ||
			||NAT-FW|| ||NAT-FW|| ||NAT-FW||
			||NSLP || ||NSLP || ||NSLP ||
			|+------+| |+------+| |+------+|
			| || | | || | | || |
			|+------+| |+------+| |+------+|
			==||NTLP ||=========||NTLP ||=======||NTLP ||====>
			|+------+| |+------+| |+------+|
			+--------+ +--------+ +--------+
			Figure 1: Class 1 NAT Handling
			The NSIS working group decided to work on two NSLP client layer
			applications: QoS and NAT/Firewall NSLP. The NAT/Firewall NSLP
			assumes that a NAT or a Firewall implements the signaling application
			(i.e., NTLP and NAT/Firewall NSLP implementation). [NSISNATFW]
			describes the signaling mechanisms in more detail.
			3.4 Class 2 NAT Handling
			In Figure 2, a number of QoS NSLP nodes are shown, with one of the
			NSIS nodes being a NAT device. In this scenario, we assume that the
			NAT device does not contain a NAT/Firewall NSLP implementation.
			Incremental deployment can lead to such a configuration. A question
			raised by this scenario is whether the NSIS implementation (the NTLP
			for example) should offer a minimal NAT implementation which would
			allow it to request a NAT binding to update the flow identifier.
			Host A NAT Router 2
			+--------+ +--------+ +--------+
			| NE | | NE | | NE |
			|+------+| |+------+| |+------+|
			||QoS || ||QoS || ||QoS ||
			||NSLP || ||NSLP || ||NSLP ||
			|| || || || || ||
			|+------+| |+------+| |+------+|
			| || | | || | | || |
			|+------+| |+------+| |+------+|
			==||NTLP ||=========||NTLP ||=======||NTLP ||====>
			|+------+| |+------+| |+------+|
			+--------+ +--------+ +--------+
			Figure 2: Class 2 NAT Handling
			There is some desire to allow an NSLP signaling message exchange
			(e.g., QoS signaling) to work properly even in the presence of NAT.
			In this scenario, no NAT/Firewall NSLP implementation is available at
			the NAT, and the end host might not trigger an NAT/Firewall NSLP
			exchange. For some cases, the signaling message contains sufficient
			information to create a NAT binding based on the flow identifier in
			the NTLP layer. If additional security mechanisms have to be
			provided by the NAT/Firewall NSLP, then that approach will fail
			since, for example, a QoS NSLP will not be able to provide those
			mechanisms.
			Another question of interest is whether it is possible to combine a
			NAT/Firewall signaling message with a QoS signaling message into a
			single protocol message (or to at least combine them using a shared
			session identifier). Error handling might be more complex because in
			addition to dealing with errors of the individual signaling
			applications, it will be necessary to deal with errors resulting from
			the combined applications.
			3.5 Class 3 NAT Handling
			We refer to Class 3 NAT handling if there is a NAT along the path
			which intercepts all NSIS signaling messages, but which does not
			contain the desired NSLP implementation. In Figure 3a, Host A
			signals for a QoS NSLP, but NAT 2 only offers an NTLP implementation.
			This NTLP could modify a flow identifier, if it is not integrity
			protected or encrypted. NAT 1 was already considered in Section 3.4.
			Host A NAT 1 Router 2
			+--------+ +--------+ +--------+
			| NE | | NE | | NE |
			|+------+| |+------+| |+------+|
			||QoS || ||QoS || ||QoS ||
			||NSLP || ||NSLP || NAT 2 ||NSLP ||
			|| || || || +--------+ || ||
			|+------+| |+------+| | NE | |+------+|
			| || | | || | | | | || |
			|+------+| |+------+| |+------+| |+------+|
			==||NTLP ||===||NTLP ||===||NTLP ||===||NTLP ||==>
			|+------+| |+------+| |+------+| |+------+|
			+--------+ +--------+ +--------+ +--------+
			Figure 3: Class 3a NAT Handling
			Intermediaries make NSIS signaling message handling more complex. To
			avoid these problems it is possible to build functionality into the
			NTLP to make intermediate nodes to be invisible for NSIS signaling.
			As a solution, it is suggested to make the discovery message (C-Mode)
			or the D-Mode in general cleverer to "discover" only those nodes
			which implement the desired NSLP functionality. (This was already
			discussed in the past.)
			This requires indicating which NSLP functionality the signaling
			message is looking for along the path. A discovery message might,
			for example, want to know the next NSIS node along the path which
			supports a QoS NSLP implementation. It is for further study, whether
			a more fine-granular discovery is required (e.g., a QoS NSLP node
			which supports a certain QoS model). IANA registration would be
			required for the NSLPs as well as for QoS models.
			Efficiency is an important issue here. An NSIS node which does not
			implement a certain NSLP application must be able to quickly
			distinguish whether it is interested in a message or not. Whether to
			encode the necessary information into a router alert option, into UDP
			port numbers, the Time-to-Live field, or into an IP protocol number
			was discussed in the past.
			As a minor variation of the scenario described in Figure 3, it is
			possible that the end host does not contain a NAT/Firewall
			implementation, but the network itself provides a NAT/Firewall
			solution as shown in Figure 4.
			+----------------------------------------+
			| Edge |
			Host A | Router 1 Router 2 NAT/FW |
			+--------+ +--------+ +--------+ +--------+
			| NE | | NE | | NE | | NE |
			|+------+| |+------+| |+------+| |+------+|
			||QoS || ||QoS+ || ||QoS+ || ||[QoS+]||
			||NSLP || ||NAT-FW|| ||NSLP || ||NAT-FW||
			|| || ||NSLP || || || ||NSLP ||
			|+------+| |+------+| |+------+| |+------+|
			| || | | || | | || | | || |
			|+------+| |+------+| |+------+| |+------+|
			=||NTLP ||==||NTLP ||======||NTLP ||======||NTLP ||=>
			|+------+| |+------+| |+------+| |+------+|
			+--------+ +--------+ +--------+ +--------+
			| Administrative Domain |
			+----------------------------------------+
			Figure 4: Class 3b NAT Handling
			The main advantage of the approach described in Figure 4 is the
			incremental deployment meaning that an administrative domain equips
			its NATs/Firewalls with NAT/Firewall NSLP implementations even though
			the end host might not support it. Note that the NAT/FW device might
			not offer the QoS NSLP implementation. The NAT/Firewall NSLP enabled
			Edge Router 1 might create a NAT binding or open a firewall pinhole
			based on an incoming QoS signaling message (even though the end host
			is not NAT/Firewall NSLP aware). It is also able to create NAT/
			Bindings at the NAT/FW device independently of a signaling exchange.
			Such a signaling exchange might be necessary if the NAT/Firewall is
			not equipped with the NSLP application signaled by the end host - in
			our example this would mean that the NAT/FW would not run a QoS NSLP
			implementation.
			3.6 Class 4 NAT Handling
			We refer to a scenario as Class 4 NAT handling scenario if a NAT is
			within the path which does not understand NSIS at all.
			Host A Router 2
			+--------+ +--------+
			| NE | | NE |
			|+------+| |+------+|
			||QoS || ||QoS ||
			||NSLP || ||NSLP ||
			|| || NAT || ||
			|+------+| +--------+ |+------+|
			| || | |+------+| | || |
			|+------+| ||Plain || |+------+|
			==||NTLP ||=========||NAT ||=======||NTLP ||====
			|+------+| |+------+| |+------+|
			+--------+ +--------+ +--------+
			Figure 5: Class 4 NAT Handling
			To allow NSIS signaling messages to traverse an NSIS unaware NAT, it
			is required that they are sent in non-raw IP mode. This is necessary
			to allow NAPT to perform modification of the transport protocol port
			numbers. For an IPsec protected signaling message, UDP encapsulation
			MUST be used. If IKE or IKEv2 [I-D.ietf-ipsec-ikev2] is used, then
			NAT traversal functionality is necessary to dynamically detect the
			presence of a NAT. The relevant work in this area can be found in
			[I-D.ietf-ipsec-nat-t-ike], in [I-D.ietf-ipsec-ikev2] and in
			[IPSECNAT].
			3.7 Dealing with NSIS unaware NATs (Class 4 NAT Handling)
			This section describes NSIS signaling in a Class 4 NAT handling
			scenario. It is in general not possible to reuse the NAT binding
			created with the NSIS signaling also for the data traffic. An
			exception is a NAT which maps the source IP address of all outgoing
			IP packets to the same external public IP address (without modifying
			the port number). In order to update the flow identifier, the NSIS
			NSLP daemon has to interact with a NAT in a non-NSIS fashion (such as
			STUN [STUN] or a MIDCOM protocol), or to reuse an "NSIS-STUN-alike"
			mechanism. We will describe the "NSIS-STUN-alike" mechanism in this
			section.
			In many cases it might be sufficient to detect the presence of an
			NSIS unaware NAT. This might be useful for those cases where the
			NSLP would break in such cases. The NSIS unaware NAT discovery
			functionality could be a built-in feature of the NTLP [NTLP],
			allowing its usage on any NE regardless of the supported NSLPs. In
			order to discover a NAT the following procedure can be applied to
			D-mode messages (which includes also discovery messages).
			The initiator of the discovery message includes the source IP address
			and the source port of the transmitted message into the signaling
			message payload.
			An NSIS unaware NAT then modifies the source IP address (and possibly
			the source port) of the NSIS signaling message. This procedure
			represents typical NAT handling. The responder of the discovery
			message will notice the modification by comparing information in the
			IP header with the content of the discovery message. If both are
			equal then no NAT was present. If the responder sees a deviation,
			then an NSIS unaware NAT was located along the path. The responder
			returns the source IP address and port number as a payload in the
			discovery reply message. Unfortunately, the information found does
			not help to update the flow identifier for the data traffic.
			Traversing an NSIS unaware NAT (from inside to outside) dynamically
			creates a NAT binding. Please note that only a NAT binding for the
			signaling traffic is created. More complexity is introduced by
			creating NAT bindings for data traffic. It seems to be reasonable
			that neighboring NSIS nodes control the NAT and also the Firewall (of
			the same administrative domain) via MIDCOM protocols, such as SNMPv3.
			The usage of SNMPv3 for this purpose is simple but requires the NSIS
			unaware NAT to implement this protocol.
			Another option is to include an "NSIS-STUN-alike" mechanism into NSIS
			which has the property of an in-band signaling mechanism. Ideally
			NSIS signaling messages should look like regular data traffic to
			experience the same treatment as data traffic. The discovery
			mechanisms is thereby an important part which we will investigate in
			more detail. Discovery messages are addressed to the same IP address
			as the data traffic. The source IP address can, however, be the
			source IP address of the data traffic, or the source IP address of
			the signaling message, in which case it would be equal to the IP
			address of the NSIS node transmitting it. The source port can be
			either equal to the source port number of the transmitted data
			traffic, or to the source port of the transmitting NSIS daemon.
			Setting the source port to the port number of the application traffic
			makes it very difficult for the NSIS daemon to intercept the response
			to a discovery message. Further investigations are required to
			verify its practicability. But this step would be very important
			since responses need to be addressed to the port number which was
			modified by the NAT (see symmetric NATs). It is suggested to set the
			destination port number to the port number of the data traffic
			destination. The Router Alert Option will allow an NSIS node to
			intercept the message and to distinguish it from a regular data
			packet. But note that this is only true for D-mode messages. For
			C-Mode messages, an additional problem is created if the transport
			layer protocol of the data traffic does not match the transport
			protocol of the signaling traffic. Furthermore, it seems to be very
			difficult for an end host to distinguish the data traffic from the
			signaling traffic. If we can assume that the discovery message
			exchange is (for most parts) indistinguishable from data traffic,
			then this exchange can be used by NSIS signaling messages and data
			traffic to traverse an NSIS unaware NAT. This, however, additionally
			assumes that only flows are signaled, rather than aggregates.
			If no means of controling the NAT are available, then the STUN
			protocol [STUN] can be used. The usage of STUN and other protocols
			(such as TURN [I-D.rosenberg-midcom-turn]) should be investigated in
			future versions of this document.
			In Figure 6, we consider a scenario where an NSIS aware initiator
			also hosts a STUN implementation. Note that more complex topologies
			are possible but not investigated in detail in this section.
	+---------------------------------------+		+---------------------------------------+
	| | +--------+		| | +--------+
	| +----------+ | | STUN |		| +----------+ | | STUN |
	| |Apps | | | Server |		| |Apps | | | Server |
	| +----------+ +---+| +--------+		| +----------+ +---+| +--------+
	| | STUN | |NAT||		| | STUN | |NAT||
	| | CLIENT | | ||		| | CLIENT | | ||
	| |__________| +---+|		| |__________| +---+|
	| |ANY_NSLP | |		| |ANY_NSLP | |
	| | NI/NR | |		| | NI/NR | |
	| +----------+ |		| +----------+ |
	| Host A |		| Host A |
	+---------------------------------------+		+---------------------------------------+
	Figure 1: STUN usage for NSIS unaware NATs		Figure 6: STUN usage for NSIS unaware NATs
	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 |_________
	| | Determination | |
	NSIS | +-----------------+ | NSIS
	Aware | | Unaware
	| |
	| |
	V V
	+-------------------+ +------------+
	|Proceed with | If not UDP |Used data |
	|normal NR operation| +--------|transport |
	+-------------------+ | |protocol |
	| +------------+
	| | If UDP
	V |
	+-------------+ |