< draft-pashalidis-nsis-gimps-nattraversal-00.txt		draft-pashalidis-nsis-gimps-nattraversal-01.txt >
	NSIS A. Pashalidis		NSIS A. Pashalidis
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Expires: January 12, 2006 Siemens		Expires: April 27, 2006 Siemens
	July 11, 2005		October 24, 2005
	NAT Traversal for GIMPS		NAT Traversal for GIST
	draft-pashalidis-nsis-gimps-nattraversal-00.txt		draft-pashalidis-nsis-gimps-nattraversal-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 12, 2006.		This Internet-Draft will expire on April 27, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document contains a number of mechanisms that may be used in		This document describes how different types of Network Address
	order to enable General Internet Messaging Protocol for Signaling		Translator (NAT) interact with the General Internet Signalling
	(GIMPS) messages to traverse different types of Network Address		Transport (GIST) protocol. The purpose of this interaction is for
	Translators that may be located along the path between two adjecent		signalling traffic to traverse the NATs in a way that preserves its
	NSLP hosts.		semantics with respect to the data flows it corresponds to.
	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 . . . . . . . . . . . . . . . . . . . . . . 6
	4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Traversal of GaNATs in the absence TLS or IPsec . . . . . . . 9		5. Transparent NAT traversal for GIST . . . . . . . . . . . . . . 13
	5.1 NSLP-unaware GaNATs . . . . . . . . . . . . . . . . . . . 9		5.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 13
	5.1.1 NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . 9		5.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 18
	5.1.2 NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . 14		5.3. NSLP-aware GaNATs . . . . . . . . . . . . . . . . . . . . 21
	5.2 NSLP-aware GaNATs . . . . . . . . . . . . . . . . . . . . 17		5.4. Combination of NSLP-aware and NSLP-unaware GaNATs . . . . 25
	5.3 Combination of NSLP-aware and NSLP-unaware GaNATs . . . . 20		6. Non-transparent NAT traversal . . . . . . . . . . . . . . . . 26
	6. GaNATs in the presence of TLS or IPSec . . . . . . . . . . . . 22		6.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 26
	6.1 NSLP-unaware GaNATs . . . . . . . . . . . . . . . . . . . 22		6.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 30
	6.1.1 NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . 22		6.3. GIST peer processing . . . . . . . . . . . . . . . . . . . 34
	6.1.2 NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . 26		7. GIST-unaware NATs . . . . . . . . . . . . . . . . . . . . . . 36
	6.1.3 Additional GIMPS peer processing . . . . . . . . . . . 28		8. Security Considerations . . . . . . . . . . . . . . . . . . . 39
	6.2 NSLP-aware GaNATs . . . . . . . . . . . . . . . . . . . . 30		8.1. Service Denial Attacks . . . . . . . . . . . . . . . . . . 39
	7. NSIS-unaware NATs . . . . . . . . . . . . . . . . . . . . . . 31		8.2. Network Intrusions . . . . . . . . . . . . . . . . . . . . 40
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 34		9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 42
	8.1 Service Denial Attacks . . . . . . . . . . . . . . . . . . 34		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
	8.2 Network Intrusions . . . . . . . . . . . . . . . . . . . . 35		11. Normative References . . . . . . . . . . . . . . . . . . . . . 43
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
	10. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 38		Intellectual Property and Copyright Statements . . . . . . . . . . 45
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39
	12. Normative References . . . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
	Intellectual Property and Copyright Statements . . . . . . . . 40
	1. Introduction		1. Introduction
	Network Address Translators (NATs) modify certain fields in the IP		Network Address Translators (NATs) modify certain fields in the IP
	header of the IP packets that traverse them. In the context of		header of the packets that traverse them. In the context of
	signalling as defined by the NSIS group, this behaviour, if not		signalling as specified by the General Internet Signalling Transport
	properly addressed, may lead to the installation of inconsistent and		(GIST) protocol [1], this behaviour may lead to the installation of
	meaningless state at network nodes with respect to the actual traffic		state at network nodes that may be inconsistent and meaningless with
	that traverses these nodes.		respect to the actual traffic that traverses these nodes.
	This document proposes a collection of algorithms that have to be		This document describes how GIST signalling messages traverse NATs in
	implemented in order to enable GIMPS signalling, and the data flows		a way that preserves the consistency of state that is installed in
	to which this signalling refers, to traverse NATs in a way that		the network with respect to the data flows to which the signalling
	preserves the consistency of state that is installed in the network,		messages refer. As the mechanisms that are described in this
	and in a manner transparent to signalling applications. The document		document exclusively operate at the GIST layer, they are transparent
	is organised as follows. The next section introduces the terminology		to signalling applications. The document is organised as follows.
	that is used throughout this document. Section 3 provides a detailed		The next section introduces the terminology that is used throughout
	discussion of the problems that are addressed by this document.		this document. Section 3 provides a detailed discussion of the NAT
	Section 4 list the assumptions on which the proposed mechanisms are		traversal problem and highlights certain design decisions that have
	based. Section 5 presents the proposed mechanisms for the case where		to be taken when addressing the problem. Section 4 lists the
	no TLS or IPsec protection is required for the signalling traffic		assumptions on which the proposed mechanisms are based. Section 5
	between two NSLP peers, and Section 6 presents the proposed		presents the proposed mechanisms for "transparent" NAT traversal, and
	mechanisms where such protection is required.		??? presents the proposed mechanisms where such protection is
			required.
	2. Terminology		2. Terminology
	The terminology, abbreviations and notational conventions that are		The terminology, abbreviations and notational conventions that are
	used throughout the document are as follows.		used throughout the document are as follows.
	o DR: Data Responder, as defined in [1]		o DR: Data Responder, as defined in [1]
	o DS: Data Sender, as defined in [1]		o DS: Data Sender, as defined in [1]
	o GaNAT: GIMPS-aware NAT - A GaNAT may implement a number		o GaNAT: GIST-aware NAT - a GaNAT MAY implement a number of NSLPs.
	of NSLPs, but does not implement the NATFW NSLP.
	o GIMPS: General Internet Messaging Protocol for Signalling		o GIST: General Internet Messaging Protocol for Signalling [1]
	[1]
	o NAT: Network Address Translator		o NAT: Network Address Translator
	o NI: NSIS Initiator, as defined in [1]		o NI: NSIS Initiator, as defined in [1]
	o NR: NSIS Responder, as defined in [1]		o NR: NSIS Responder, as defined in [1]
	o NSIS: Next Steps in Signalling, as defined in [1]		o NSIS: Next Steps in Signalling: The name of the IETF working group
			that specified the family of signalling protocols of which this
			specification is also a member. The term NSIS is also used to
			refer to this family of signalling protocols as a whole.
	o NSIS-aware: Implements GIMPS and zero or more NSLPs.		o GIST-aware: Implements GIST and MAY also implement a number of
			NSLPs.
	o NSIS-unaware: GIMPS-unaware, does not implement any NSLP.		o GIST-unaware: GIST-unaware, does not implement any NSLP.
	o NSLP: NSIS Signalling Layer Protocol, as defined in [1]		o NSLP: NSIS Signalling Layer Protocol, as defined in [1]
	o downstream: as defined in [1]		o downstream: as defined in [1]
	o upstream: as defined in [1]		o upstream: as defined in [1]
	o MRI: Message Routing Information, as defined in [1]		o MRI: Message Routing Information, as defined in [1]
	o NLI.IA: Interface Address field of the Network Layer		o NLI.IA: Interface Address field of the Network Layer Information
	Information header field, as defined in [1]		header field, as defined in [1]
	o <- : Assignment operator. The quantity to the right of		o <- : Assignment operator. The quantity to the right of the
	the operator is assigned to the variable to its left.		operator is assigned to the variable to its left.
	o A.B: Element B of structure A. Example: [IP		o A.B: Element B of structure A. Example: [IP
	header].SourceIPAddress denotes the source IP address of an IP		header].SourceIPAddress denotes the source IP address of an IP
	header.		header.
	o [data item]: This notation indicates that "data item" is a		o [data item]: This notation indicates that "data item" is a single
	single identifier of a data structure. (Square brackets do not		identifier of a data structure. (Square brackets do not denote
	denote optional arguments in this document.)		optional arguments in this document.)
	3. Problem Statement		3. Problem Statement
	According to [1], all GIMPS messages carry IP addresses in order to		According to [1], all GIST messages between two peers carry IP
	define the data flow to which the signalling refers. Moreover,		addresses in order to define the data flow to which the signalling
	certain GIMPS messages also carry the IP address of the sending peer,		refers. Moreover, certain GIST messages also carry the IP address of
	in order to enable the receiving peer to address subsequent traffic		the sending peer, in order to enable the receiving peer to address
	to the sender. Packets that cross an addressing boundary, say from		subsequent traffic to the sender. Packets that cross an addressing
	addressing space S1 to S2, have the IP addresses in the IP header		boundary, say from addressing space S1 to S2, have the IP addresses
	translated from space S1 to S2 by the NAT; if GIMPS payloads are not		in the IP header translated from space S1 to S2 by the NAT; if GIST
	translated in a consistent manner, the MRI in a GIMPS packet that		payloads are not translated in a consistent manner, the MRI in a GIST
	crosses the boundary, e.g. from address space S1 to S2, refers to a		packet that crosses the boundary, e.g. from address space S1 to S2,
	flow that does not exist in S2. In fact, the flow is invalid in S2		refers to a flow that does not exist in S2. In fact, the flow may be
	because at least one of the involved IP addresses belongs to S1.		invalid in S2 because at the IP address that belongs to S1 may not be
	Moreover, the IP address of the sending peer may also be invalid in		routable or invalid in S2. Moreover, the IP address of the sending
	the addressing space of the receiving peer. The purpose of this		peer may also be not routable or invalid in the addressing space of
	document is to describe a way for GIMPS messages to be translated in		the receiving peer. The purpose of this document is to describe a
	a way consistent with the translation that NATs apply to the IP		way for GIST messages to be translated in a way that is consistent
	headers of both signalling and data traffic.		with the translation that NATs apply to the IP headers of both
			signalling and data traffic.
	A NAT may either be NSIS-unaware or NSIS-aware. The case of NSIS-		A NAT may either be GIST-unaware or GIST-aware. We denote a GIST-
	unaware NATs is discussed in Section 7. If the NAT is NSIS-aware, it		aware NAT as a GaNAT in the sequel. A GaNAT MAY also support at
	is typically also able to support at least one NSLP. Note that there		least one NSLP. Note that there exists an NSLP, namely the NATFW
	exists an NSLP, namely the NATFW NSLP [2], that specifically		NSLP [2], that specifically addresses NAT traversal for data flows.
	addresses NAT traversal for data flows. Inevitably, the NATFW NSLP		Inevitably, the NATFW NSLP also provides the necessary mechanisms for
	also provides the necessary mechanisms for the related signalling to		the related signalling to traverse the NATs involved. Consider a
	traverse the NATs involved. Therefore, we can further divide NSIS-		GaNAT that supports both the NATFW NSLP, and the NAT traversal
	aware NATs into two categories, namely GIMPS-and-NATFW-aware NATs and		extension to GIST that is specified in this document. Suppose now
	GIMPS-aware-and-NATFW-unaware NATs. In the sequel, we call the		that a GIST QUERY message arrives at this GaNAT that contains the
	latter simply GIMPS-aware NATs (GaNATs). A GIMPS-and-NATFW-aware NAT		NSLP identifier (NSLPID) of the NATFW NSLP. A question that arises
	performs NAT traversal according to the NATFW NSLP; the case of NAT		is whether the GaNAT should use the GIST NAT traversal extension
	traversal in the presence of such NATs is therefore beyond the scope		defined in this document, or the NATFW NSLP mechanism, in order to
	of this document.		provide "NAT traversal" for both the signalling message and the data
			flow to which it refers. The answer to this question is that such a
			GaNAT MUST implement a policy according to which method is used in
			preference to the other. Note, however, that, should the GaNAT
			prefer the GIST NAT traversal to NATFW NSLP, then it will happen, if
			no on-path GaNATs exist that prefer the NATFW NSLP, that the
			downsteam NATFW peer will be unable to discover any downstream NATFW
			NSLP peers. This may make the entire NATFW session obsolete.
	As is natural, a NATFW-aware NAT only translates the relevant fields		Clearly, if a GaNAT does not implement the NATFW NSLP, then the only
	for the NATFW signalling traffic in a way consistent with the		way for the signalling and the data flow to traverse that GaNAT, is
	relevant data flow. Consequently, GIMPS signalling in the presence		for the necessary mechanisms to operate on the GIST layer. The same
	of NATFW-unaware NATs and for NSLPs other than the NATFW NSLP remains		holds when the NSLP that is being signalled is an NSLP other than the
	an open problem. This document precisely addresses this problem, by		NATFW NSLP. Enabling NAT traversal in presicely these circumstances
	proposing mechanisms that operate at the GIMPS layer.		is the motivation of this specification.
	In general, a given data flow between a data sender (DS) and a data		In general, a given data flow between a data sender (DS) and a data
	receiver (DR) may have to traverse a number of NATs, some of which		receiver (DR) may have to traverse a number of NATs, some of which
	may be GIMPS-and-NATFW-aware, some may be GIMPS-aware, and some may		may be GIST-and-NATFW-aware, some may be GIST-aware, and some may be
	be NSIS-unaware. Additionally, NSLP signalling for such a data flow		GIST-unaware. Additionally, NSLP signalling for such a data flow may
	may be required to traverse through a subset of those NATs. Whether		be required to traverse through a subset of those NATs. Whether or
	or not the routing inftrastructure and state of the network causes		not the routing inftrastructure and state of the network causes the
	the signalling for such a data flow to traverse the same NATs as the		signalling for such a data flow to traverse the same NATs as the flow
	flow depends, among other things, on the signalling application.		depends, among other things, on which NSLP is being signalled. While
			signalling of the QoS NSLP, for example, might not traverse any of
	While signalling of a QoS NSLP, for example, might not traverse any		the NATs that are traversed by the data flow, the signalling of the
	of the NATs that are traversed by the data flow, the signalling of		NATFW NSLP traverses at least those NATs that implement the NATFW
	the NATFW NSLP traverses at least those NATs that implement the NATFW
	NSLP (otherwise the signalling path would no longer be coupled to the		NSLP (otherwise the signalling path would no longer be coupled to the
	data path, as this coupling is defined by the GIMPS QUERY/RESPONSE		data path, as this coupling is defined by the GIST QUERY/RESPONSE
	discovery mechanism). It is desirable for every possible combination		discovery mechanism for the "path coupled" Message Routing Method).
	of NATs, either on the data or the signalling path, to be functional		It is desirable that the NAT traversal extension for GIST provides
	and secure.		NAT traversal for every possible combination of NATs, either on the
			data or the signalling path, in a secure manner.
	Due to the GIMPS QUERY/RESPONSE discovery mechanism (according to		Due to the GIST QUERY/RESPONSE discovery mechanism (according to
	which QUERY messages are simply forwarded if the current node does		which QUERY messages are simply forwarded if the current node does
	not support the required NSLP), two GIMPS nodes identify themselves		not support the required NSLP), two GIST nodes typically identify
	as NSLP peers only if they both implement the same NSLP, say NSLP X.		themselves as NSLP peers only if they both implement the same NSLP.
	This means that, if one or more X-unaware NATs are between them, then		This means that, if one or more NATs that are unaware of this NSLP
	the two X peers are not able to discover each other at all. This is		are between them, then the two NSLP peers are not able to discover
	because, even in the unlikely event that the bindings necessary for		each other at all. This is because, even in the unlikely event that
	the GIMPS traffic to traverse the in-between NAT(s) exist, the NLI.IA		the NAT bindings that are necessary for the GIST traffic to traverse
	Object included in the RESPONSE message sent by the downstream		the in-between NAT(s) exist, the NLI.IA field included in the
	X-aware peer will be invalid (i.e. the IP address will be		RESPONSE message sent by the downstream GIST peer is invalid (or the
	unreachable) in the address space of the upstream X peer. In order		IP address is unreachable) in the address space of the upstream GIST
	to overcome this limitation, either the two X peers need to cope with		peer. In order to overcome this limitation, either the two peers
	the in-between NAT(s), or, if the NAT(s) are GaNATs, they (the		need to cope with the in-between NAT(s), or, if the NAT(s) are
	GaNATs) need to apply additional processing in order to transparently		GaNATs, they (the GaNATs) need to apply additional processing in
	create and maintain the required consistency. Additionally, if		order to transparently create and maintain consistency between the
	X-aware NATs are on the data path (where X is any NSLP except NATFW),		information in the header of GIST signalling messages and the
	then these NATs should process X traffic in a way the preserves		information in the IP header of the data traffic. Additionally, if
	consistency after address translation. This processing deviates from		NSLP-aware NATs are on the data path, then these NATs should process
	the processing of X-aware non-NAT nodes. In the following sections		NSLP traffic in a way that preserves consistency after address
	we propose certain processing rules that aim to overcome the		translation. This processing deviates from the processing of NSLP-
	limitation of two adjacent X peers not being able to execute X in the		aware non-NAT nodes. In the following sections we specify mechanisms
	presence of in-between NAT(s). We do not consider the case where		that aim to overcome the limitation of two adjacent GIST peers not
	X=NATFW and all NAT(s) on the path are NATFW-aware. This case is		being able to execute an NSLP in the presence of in-between NAT(s).
	handled by the NATFW NSLP.
	Note that we have to deal with a number of different situations,		Note that a number of different situations has to be dealt with,
	depending on whether X is supported by the GaNATs. Thus, we have the		depending on the level of NSIS support by a NAT. The following
	following three subcases.		combinations of NATs that are located between two adjacent GIST peers
			are considered.
	o all GaNAT(s) are X-unaware		o all NAT(s) are GIST-unaware
	o all GaNAT(s) are X-aware (and X is not the NATFW NSLP)		o all NAT(s) are (NSLP-unaware) GaNAT(s)
	o a combination of X-aware and X-unaware GaNATs are between to X		o all NAT(s) are NSLP-aware
	peers.
	In the following sections, we discuss the three cases separately.		o a combination of the above NAT types.
			The approach taken in this document is to propose separate mechanisms
			for the traversal of each of the above type of NAT. If NATs that
			belong to multiple types exist on the path between two adjacent NSLP
			peers, the proposed mechanisms should work in combination. Thus,
			traversal of multiple NATs of different types should not require
			further specification from a functional perspective. However,
			security issues that arise due to the combination of NAT types may
			have to be considered.
			A GIST-unaware NAT cannot tell data and signalling traffic apart.
			The installation of the NAT binding for the signalling traffic in
			such a NAT occurs typically independently from the installation of
			the NAT binding for the data traffic. Furthermore, as the NAT cannot
			associate the signalling and the data traffic in any way, it cannot
			indicate that an association exists between the two NAT bindings.
			Therefore, in the presence of such a NAT, GIST nodes that are located
			on either side of the NAT have to cope with the NAT without
			assistance from the NAT. This would typically require initially
			discovering the NAT and subsequently establishing an association
			between between the MRI in the signalling messages and the translated
			IP header in the data traffic. Due to the variety of behaviours that
			a GIST-unaware NAT may exhibit, establishing this association is a
			non-trivial task. Therefore, traversal of such (i.e. GIST-unaware)
			NATs is considered a special case and is further discussed in
			Section 7.
			Traversal of GaNAT(s) is comperatively more straightforward. This is
			because, based on the MRI in a given incoming GIST message, a GaNAT
			can identify the data flow to which the message refers. It can then
			check its NAT binding cache and determine the translation that is
			(or, if no NAT binding for the flow exists yet, will be) applied to
			the IP header of the data flow. The GaNAT can then include
			sufficient information about this translation into the signalling
			message, such that its receiver (i.e. the GIST peer that receives the
			data traffic after network address translation has been applied) can
			map the signalling message to the data flow.
			There exist a variety of ways for a GaNAT to encode the
			abovementioned information into signalling messages. In this
			document the following two ways are considered.
			1. Non-transparent apprach: The GaNAT includes an additional "NAT
			Traversal" payload (see section A.3.8 of [1]) into the GIST
			header of the GIST QUERY message. This "NAT Traversal" payload
			is echoed by the GIST responder on the other side of the NAT.
			Both peers use the information in this payload in order to map
			subsequent signalling messages to the data flows they refer to.
			2. Transparent approach: The GaNAT replaces GIST header fields in a
			way that is consistent with the translation it applies to the
			data traffic, as necessary. The GaNAT does this GIST QUERY and
			RESPONSE messages, for D-mode as well as for C-mode messages
			throughout the duration of the signalling session.
			The second approach being "transparent" means that a GaNAT that
			follows this approach remains completely transparent to the GIST
			peers that are located either side of it. Thus, this approach works
			even if these GIST peers do not support the NAT traversal object for
			GIST (as described in section 7.2 of [1]). Unfortunately though, the
			transparent approach does not work if the GaNAT is NSLP-unaware and
			if signalling traffic is to be cryptographically protected between
			the two GIST peers that are located either side of the GaNAT. If,
			however, the GaNAT is NSLP-aware, then cryptographic protection is
			terminated at the GaNAT (i.e. the GaNAT is a GIST peer itself). In
			this scenario, it is clearly preferable for the GaNAT to follow the
			transparent approach, rather than to include a NAT Traversal object.
			Thus, if a GaNAT acts as a GIST peer for a signalling session, it
			MUST follow the transparent approach, as described in Section 5.3.
			However, due to the fact that the transparent approach does not work
			if signalling is to be cryptographically protected, a GaNAT MUST also
			implement the non-transparent approach (for the case where an NSLP is
			signalled that the GaNAT does not support), unless the GaNAT is going
			to be used only in deployments where cryptographic protection of
			signalling traffic is not a requirement.
			Note that a GaNAT MAY implement both approaches. If such a GaNAT is
			NSLP-unaware, it can then adopt the correct behaviour, based on
			whether or not cryptographic protection is required for the
			signalling traffic between two GIST peers. If such protection is
			required, the GaNAT MUST adopt the mechanisms that follow the non-
			transparent approach; if it is not, it MAY follow the mechanisms
			implementing the transparent approach. The GaNAT can tell whether or
			not cryptographic protection is required from the stack proposals
			that are exchanged in the GIST QUERY and RESPONSE messages; inclusion
			of IPsec or TLS proposals amounts to cryptographic protection being
			required.
			Regardless of which approach is taken, after a GIST response passes
			through an NSLP-unaware GaNAT, the GaNAT should expect a messaging
			association to be set up between the two involved GIST peers. For
			this to happen, the GaNAT has to allow traffic to traverse it. From
			a security perspective, the GaNAT should allow the minimum necessary
			traffic types to traverse. Additionally, the amount of per
			signalling session state that is allocated at a GaNAT should be
			minimised for reasons of efficiency and resistance to service denial
			attacks. For these reasons, it makes sense for the GaNAT to be able
			to predict with certainty which of the GIST responder's stack
			proposal will be used by the initiator for the establishement of a
			messaging association. This can be accomplished by having the GaNAT
			modify the stack configuration object in the GIST RESPONSE as it
			passes though it such that the initiator is forced to use a
			particular stack proposal and, if applicable, a particular transport
			layer destination port.
			The reason why it is preferable for the GaNAT to modify only the
			stack configuration data object (as opposed to the stack proposal
			object) is that the GIST responder expects its original stack
			proposal to be included in the GIST CONFIRM message. The initiator
			would not be able to echo that object as it would not have seen it
			and, if signalling messages are cryptographically protected, then the
			GaNAT cannot replace the stack proposal in the GIST CONFIRM message
			with the one the responder expects, without causing cryptographic
			checks to fail at the responder. Thus, the approach taken in this
			document is for the GaNAT to render invalid all but one stack
			configuration data objects in the GIST RESPONSE message. How this is
			done depends on the format of this object. If, for example, it
			contains transport layer port numbers, it is rendered invalid by
			setting these numbers to zero.
			A question arises due to the fact that the stack proposal carried by
			a GIST QUERY may include multiple proposals of which some provide
			cryptographic protection for signalling traffic and some do not.
			Which behaviour should a GaNAT that supports both approaches assume
			in this case? In order to provide maximise the probability that
			cryptographic protection is going to used, the GaNAT MUST follow the
			non-transparent approach in this case.
	4. Assumptions		4. Assumptions
	The discussion in this document is based on the following		The discussion in this document is based on the following
	assumptions. Note that X denotes a fixed NSLP, other than the NATFW		assumptions.
	NSLP.
	1. No IP addresses and port numbers are carried in the payloads of		1. No IP addresses and port numbers are carried in the payloads of
	X.		an NSLP.
	2. The path taken by the signalling traffic between those X peers		2. The path taken by the signalling traffic between those GIST peers
	that have GaNATs in between is such that the responses to packets		that have GaNATs in between is such that the responses to packets
	that a GaNAT sends on given interface arrive on the same		that a GaNAT sends on given interface arrive on the same
	interface (if such responses are sent at all).		interface (if such responses are sent at all).
	3. The path taken by signalling traffic remains fixed between the		3. The path taken by signalling traffic remains fixed between the
	two X peers, as far as the in-between GaNATs are concerned. That		two GIST peers, as far as the in-between GaNATs are concerned.
	is, we assume that signalling traffic traverses the same GaNAT(s)		That is, we assume that signalling traffic traverses the same
	until at least one of the following conditions is met.		GaNAT(s) until at least one of the following conditions is met.
	* The NSIS state that is installed at the two X peers expires.		* The NSIS state that is installed at the two GIST peers
			expires.
	* The NSIS state that is installed at the two X peers is		* The NSIS state that is installed at the two GIST peers is
	refreshed using a GIMPS QUERY.		refreshed using a GIST QUERY.
	* A new GIMPS QUERY/RESPONSE exchange takes place due to other		* A new GIST QUERY/RESPONSE exchange takes place due to other
	reasons, e.g. a detected route change.		reasons, e.g. a detected route change.
	Note that this assumption is not necessarily met by "normal" data		Note that this assumption is not necessarily met by "normal" data
	path coupled signalling. This is because, under "normal" data		path coupled signalling. This is because, under "normal" data
	path coupled signalling, the signalling traffic is "coupled" to		path coupled signalling, the signalling traffic is "coupled" to
	the data traffic at nodes that implement X. Thus, under "normal"		the data traffic at nodes that decide to act as GIST peers.
	path coupled signalling, it is not an error condition (e.g. a		Thus, under "normal" path coupled signalling, it is not an error
	"route change"), for example, if the set of on-path (non-X) GIMPS		condition (e.g. a reason to trigeer a "route change"), for
	nodes changes, as long as adjacent X peers remain the same.		example, if the set of on-path nodes, which do not act as GIST
			peers, changes, as long as adjacent GIST peers remain the same.
	4. The data flow traverses the same set of GaNATs as the signalling		4. The data flow traverses the same set of GaNATs as the signalling
	traffic. By assumption 3, this set of GaNATs is fixed until the		traffic. By assumption 3, this set of GaNATs is fixed until the
	next GIMPS QUERY/RESPONSE procedure is executed.		next GIST QUERY/RESPONSE procedure is executed.
	+-----+		+-----+
	+----+GaNAT|-----+		+----+GaNAT|-----+
	| | A | |		| | A | |
	| +-----+ |		| +-----+ |
	+------+ +------+ +--+---+ +------+		+------+ +------+ +--+---+ +------+
	+--+ |X NSLP| | IP | | IP | |X NSLP| +--+		+--+ | GIST | | IP | | IP | | GIST | +--+
	|DS+-+peer +--+router| |router+--+peer 2+-+DR|		|DS+-+peer 1+--+router| |router+--+peer 2+-+DR|
	+--+ +------+ +---+--+ +--+---+ +------+ +--+		+--+ +------+ +---+--+ +--+---+ +------+ +--+
	| +-----+ |		| +-----+ |
	| |GaNAT| |		| |GaNAT| |
	+----+ B +-----+		+----+ B +-----+
	+-----+		+-----+
	Figure 1: Network with more than one NAT at an addressing boundary		Figure 1: Network with more than one NAT at an addressing boundary
	Figure 1 illustrates the importance of assumptions (3) and (4). With		Figure 1 illustrates the importance of assumptions (3) and (4). With
	regard to that figure, suppose that a (D-mode) signalling session has		regard to that figure, suppose that a (D-mode) signalling session has
	been setup between the two adjacent X NSLP peers 1 and 2 and that		been setup between the two adjacent GIST peers 1 and 2 and that both
	both signalling and data traffic follows the path X NSLP peer 1 -> IP		signalling and data traffic follows the path GIST peer 1 -> IP router
	router -> GaNAT A -> IP router -> X NSLP peer 2. Suppose now that,		-> GaNAT A -> IP router -> GIST peer 2. Suppose now that, after some
	after some time, X peer 1 decides to set up a C-mode connection with		time, GIST peer 1 decides to set up a C-mode connection with peer 2.
	peer 2. Suppose moreover that the left IP router decides to forward		Suppose moreover that the left IP router decides to forward the
	the C-mode signalling traffic on the link towards GaNAT B. Thus,		C-mode signalling traffic on the link towards GaNAT B. Thus,
	signalling traffic now follows the alternative path X NSLP peer 1 ->		signalling traffic now follows the alternative path GIST peer 1 -> IP
	IP router -> GaNAT B -> IP router -> X NSLP peer 2. Note that this		router -> GaNAT B -> IP router -> GIST peer 2. Note that this change
	change in forwarding between the two adjacent X NSLP peers does not		in forwarding between the two adjacent GIST peers does not trigger a
	trigger a "route change" at the GIMPS layer because (a) it does not		"route change" at the GIST layer because (a) it does not necessarily
	destroy the adjacency of peer 1 and 2 and (b) it does not destroy the		destroy the adjacency of peer 1 and 2 and (b) it does not necassarily
	coupling of the path taken by signalling traffic to that taken by		destroy the coupling of the path taken by signalling traffic to that
	data traffic (at X-aware nodes). Nevertheless, assumptions (3) and		taken by data traffic (at GIST nodes). Nevertheless, assumptions (3)
	(4) mandate that this situation does not occur. However, even if		and (4) mandate that this situation does not occur. However, even if
	such a situation occurs, the proposals in this document still work.		such a situation occurs, the mechanisms described in this document
			may still work as state expires after a certain timeout period.
	If assumption (1) does not hold, X has to provide additional		If assumption (1) does not hold, the NSLP has to provide additional
	mechanisms for the traversal of (Ga)NATs. These mechanisms must be		mechanisms for the traversal of (Ga)NATs. These mechanisms must be
	compatible with the mechanisms described in this document.		compatible with the mechanisms employed by GIST. Assumptions (2),
	Assumptions (2), (3) and (4) hold if, at an addressing boundary, only		(3) and (4) hold if, at an addressing boundary, only one NAT exists.
	one NAT exists. Due to security and management reasons, this is		Due to security and management reasons, this is likely to be the case
	likely to be the case in many settings.		in many settings.
	5. Traversal of GaNATs in the absence TLS or IPsec
	This section describes the operation of GIMPS-aware NATs when no
	cryptographic protection of signalling data is requested by two NSLP
	peers. The situation when such protection is required is discussed
	in Section 6.
	Recall that by GaNAT we mean a NAT that implements GIMPS but does not
	implement the NATFW NSLP. In this section we discuss the possibility
	of two NSIS peers that implement a given NSLP, denoted as X, to
	discover each other and subsequently exchange signalling messages in
	the presence of one or more GaNATs in between. Note that X may be
	any NSLP including the NATFW NSLP (however, if X=NATFW we do not
	consider X-aware GaNATs).
	Note that we have to deal with three subcases, namely (a) the case
	where all GaNAT(s) are X-unaware, (b) the case where all GaNAT(s) are
	X-aware (and X is not the NATFW NSLP), and (c) the case where a
	combination of X-aware and X-unaware GaNATs are between to X peers.
	We discuss the three cases separately.
	5.1 NSLP-unaware GaNATs		5. Transparent NAT traversal for GIST
	This section describes the algorithm that an X-unaware GaNAT must		This section describes the operation of GaNATs that implement the
	execute in order to enable the signalling traffic of two X peers to		transparent approach listed in Section 3. Note that the GaNAT may
	traverse the GaNAT in a transparent (for the two peers) manner. The		follow this approach only if it is unaware of the NSLP that is being
	notation A.B denotes the field B of data structure A.		signalled, and when no cryptographic protection of signalling data is
			requested by the two NSLP peers.
	Note that we have to deal with two types of GaNATs, namely those that		Note that we have to deal with two types of GaNATs, namely those that
	are located at the NSIS initiator (NI-side), and those that are		are located at the NSIS initiator (NI-side), and those that are
	located at the NSIS responder (NR-side). This distinction arises due		located at the NSIS responder (NR-side). This distinction arises due
	to the fact that NI-side and NR-side GaNATs obtain the destination IP		to the fact that NI-side and NR-side GaNATs obtain the destination IP
	address for forwarded packets in different ways.		address for forwarded packets in different ways.
	5.1.1 NI-side NSLP-unaware GaNATs		5.1. NI-side NSLP-unaware GaNATs
			This section describes the "transparent" operation of an NI-side,
			NSLP-unaware GaNAT.
	For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT		For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT
	executes the following algorithm.		executes the following algorithm.
	1. If P has a RAO followed by the GIMPS header with an NSLP ID that		1. If P has a RAO followed by the GIST header with an NSLP ID that
	is not supported, it is identified as a GIMPS QUERY. In this		is not supported, it is identified as a GIST QUERY. In this case
	case the GaNAT performs the following.		the GaNAT performs the following.
	1. We denote P as GQ. It looks at the stack proposal ST in GQ.		1. We denote P as GQ. It looks at the stack proposal ST in GQ.
	If it indicates that cryptographic protection is required,		If it indicates that cryptographic protection is required,
	the algorithm that is executed is the one described in		the mechanism that is applies is the one described in ???.
	Section 6.
	2. The GaNAT remembers GQ along with the interface on which it		2. The GaNAT remembers GQ along with the interface on which it
	arrived. We call this interface the "upstream link".		arrived. We call this interface the "upstream link".
	3. It searches its table of existing NAT bindings against		3. It searches its table of existing NAT bindings against
	entries that match the GQ.MRI. A matching entry means that		entries that match the GQ.MRI. A matching entry means that
	the data flow, to which the signalling refers, already		the data flow, to which the signalling refers, already
	exists.		exists.
	1. If a matching entry is found, the GaNAT looks at which		1. If a matching entry is found, the GaNAT looks at which
	skipping to change at page 10, line 37 ¶		skipping to change at page 14, line 18 ¶
	that match GQ.MRI (excluding GQ.MRI.SourceIPAddress)		that match GQ.MRI (excluding GQ.MRI.SourceIPAddress)
	would be forwarded. We call this link the "downstream		would be forwarded. We call this link the "downstream
	link". Then, the GaNAT acquires an IP address for itself		link". Then, the GaNAT acquires an IP address for itself
	on the downstream link. (This address could be dynamic		on the downstream link. (This address could be dynamic
	or static.) This address will be used to forward both		or static.) This address will be used to forward both
	signalling and data traffic on the downstream link. If		signalling and data traffic on the downstream link. If
	it also performs port translation, the GaNAT also		it also performs port translation, the GaNAT also
	acquires a source port number for the data traffic on the		acquires a source port number for the data traffic on the
	downstream link. This will be used with the NAT binding,		downstream link. This will be used with the NAT binding,
	if such a binding will be established for the data		if such a binding will be established for the data
	traffic at a later stage, and is denoted as SPNDTGaNATds		traffic at a later stage, and is denoted as SPNDTGaNATds.
	. The signalling traffic packets may also be forwarded		The signalling traffic packets may also be forwarded
	using the a different source port number as the incoming		using the a different source port number as the incoming
	packets. We denote the acquired IP address as IPGaNATds		packets. We denote the acquired IP address as IPGaNATds
	and the source port number for the signalling traffic as		and the source port number for the signalling traffic as
	SPNSTGaNATds.		SPNSTGaNATds.
	Issues: The reason why the GaNAT may also assign a		Issues: The reason why the GaNAT may also assign a
	different source port number to the signalling traffic,		different source port number to the signalling traffic,
	is to enable the GaNAT to demultiplex (i.e. forward to		is to enable the GaNAT to demultiplex (i.e. forward to
	the correct internal address) the signalling responses		the correct internal address) the signalling responses
	that arrive from downstream. Of course, a GaNAT does not		that arrive from downstream. Of course, a GaNAT does not
	need to actually change the source port of signalling		need to actually change the source port of signalling
	traffic; it can always use SPNSTGaNATds the same port as		traffic; it can always use SPNSTGaNATds the same port as
	in the incoming packet. Such a GaNAT may use the GIMPS		in the incoming packet. Such a GaNAT may use the GIST
	session id in order to demultiplex the traffic that		session ID in order to demultiplex the traffic that
	arrives from the downstream direction. It is unclear		arrives from the downstream direction. It is unclear
	which of the two approaches is preferable.		which of the two approaches is preferable.
	4. It creates a new GIMPS QUERY packet GQ', as follows.		4. It creates a new GIST QUERY packet GQ', as follows.
	1. GQ' <- GQ		1. GQ' <- GQ
	2. GQ'.MRI.SourceIPAddress <- IPGaNATds		2. GQ'.MRI.SourceIPAddress <- IPGaNATds
	3. GQ'.MRI.SourcePortNumber <- SPNDTGaNATds		3. GQ'.MRI.SourcePortNumber <- SPNDTGaNATds
	4. GQ'.[IP header].SourceIPAddress <- IPGaNATds		4. GQ'.[IP header].SourceIPAddress <- IPGaNATds
	5. GQ'.[TRANSPORT_LAYER_HEADER].SourcePort <- SPNSTGaNATds		5. GQ'.[UDP HEADER].SourcePort <- SPNSTGaNATds
	6. GQ'.NLI.IA <- IPGaNATds		6. GQ'.NLI.IA <- IPGaNATds
	7. GQ'.S <- true		7. GQ'.S <- true
	5. It remembers GQ and GQ', the fact that they are associated,		5. It remembers GQ and GQ', the fact that they are associated,
	and the associated upstream and downstream links. (Note: The		and the associated upstream and downstream links. (Note: The
	GaNAT does not have to remember the entire packets; for		GaNAT does not have to remember the entire packets; for
	simplicity of exposition, however, we assume it does. An		simplicity of exposition, however, we assume it does. An
	implementation SHOULD discard at this point all information		implementation SHOULD discard at this point all information
	that is not used later.)		that is not used later.)
	6. It forwards GQ' on the downstream link.		6. It forwards GQ' on the downstream link.
	2. Otherwise, if P carries a [IP header].DestinationIPAddress that		2. Otherwise, if P carries an [IP header].DestinationIPAddress that
	belongs to the GaNAT, and if it is identified as a GIMPS response		belongs to the GaNAT, and if it is identified as a GIST response
	in D-mode with an NSLP ID that is not supported, the GaNAT does		in D-mode with an NSLP ID that is not supported, the GaNAT does
	the following (P is denoted as GR).		the following (P is denoted as GR).
	1. It searches for a matching GQ' in its buffer. A GR is said		1. It searches for a matching GQ' in its buffer. A GR is said
	to match a GQ' if they carry the same cookie value. If none		to match a GQ' if they carry the same cookie value. If none
	is found, GR is discarded. Otherwise, the GaNAT may also		is found, GR is discarded. Otherwise, the GaNAT may also
	perform further consistency checks on a matching GR/GQ' pair,		perform further consistency checks on a matching GR/GQ' pair,
	such as checking that they contain the same session IDs,		such as checking that they contain the same session IDs,
	MRIs, NSLP IDs. If consistency checks succeed, the GaNAT		MRIs, NSLP IDs. If consistency checks succeed, the GaNAT
	constructs a new GIMPS response GR', as follows.		constructs a new GIST response GR', as follows.
	1. GR' <- GR		1. GR' <- GR
	2. GR'.MRI <- GQ.MRI, where GQ is the packet associated with		2. GR'.MRI <- GQ.MRI, where GQ is the packet associated with
	GQ'(as remembered previously), and GQ' is the packet that		GQ'(as remembered previously), and GQ' is the packet that
	matches the received GR.		matches the received GR.
	3. GR'.[IP header].SourceIPAddress <- IPGaNATus, where		3. GR'.[IP header].SourceIPAddress <- IPGaNATus, where
	IPGaNATus = GQ.[IP header].DestinationIPAddress.		IPGaNATus = GQ.[IP header].DestinationIPAddress.
	4. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA		4. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA
	5. GP'.S <- true.		5. GP'.S <- true.
	6. It inspects the stack proposals in GR' and the		6. It inspects the stack proposals in GR' and the
	corresponding GQ' to see if the upstream X peer has a		corresponding GQ' to see if the upstream GIST peer has a
	choice of more than one possible stack. If such choice		choice of more than one possible stack. If such a choice
	exists, the GaNAT removes as many stack proposals from		exists, the GaNAT removes as many stack proposals from
	GR' as necessary, until only one stack can be chosen by		GR' as necessary, until only one stack can be chosen by
	the upstream peer for the messaging association. We		the upstream peer for the messaging association. We
	denote this stack as ST. The GaNAT remembers this ST and		denote this stack as ST. The GaNAT remembers this ST and
	its association with GQ, GQ', GR, GR'. We say that, in		its association with GQ, GQ', GR, GR'. We say that, in
	this case, the GaNAT "installs" the ST.		this case, the GaNAT "installs" the ST.
	2. It forwards GR' on the upstream link.		2. It forwards GR' on the upstream link.
	3. If no NAT binding for the data traffic was found in step		3. If no NAT binding for the data traffic was found in step
	skipping to change at page 12, line 46 ¶		skipping to change at page 16, line 29 ¶
	should be forwarded on the downstream link, with [IP		should be forwarded on the downstream link, with [IP
	header].SourceIPAddress = IPGaNATds.		header].SourceIPAddress = IPGaNATds.
	Issues: there is a question of whether this NAT binding		Issues: there is a question of whether this NAT binding
	should also enable data traffic in the opposite direction to		should also enable data traffic in the opposite direction to
	traverse the NAT; in order to be able to demultiplex upstream		traverse the NAT; in order to be able to demultiplex upstream
	traffic that carries data that belongs to different flows,		traffic that carries data that belongs to different flows,
	the GaNAT should keep the necessary per-flow state. From a		the GaNAT should keep the necessary per-flow state. From a
	signalling point of view, however, upstream data traffic that		signalling point of view, however, upstream data traffic that
	corresponds (on the application level) to the downstream flow		corresponds (on the application level) to the downstream flow
	to which this GIMPS session refers, is a separate flow for		to which this GIST session refers, is a separate flow for
	which, dependent on the application, there may or there may		which, depending on the application, there may or there may
	not exist a signalling session. If such a signalling session		not exist a signalling session. If such a signalling session
	exists, then the GaNAT acts as an NR-side GaNAT for this		exists, then the GaNAT acts as an NR-side GaNAT for this
	session. Thus, during the processing of this signalling care		session. Thus, during the processing of this signalling care
	has to be taken not to establish a NAT binding for a flow for		has to be taken not to establish a NAT binding for a flow for
	which a NAT binding already exists. Finally, security issues		which a NAT binding already exists. Finally, security issues
	arise when traffic, for which no signalling exists, is		arise when traffic, for which no signalling exists, is
	allowed to traverse a GaNAT.		allowed to traverse a GaNAT.
	Another issue is about refreshing the NAT binding. A NAT		Another issue is about refreshing the NAT binding. A NAT
	binding that was established as a result of GIMPS signalling		binding that was established as a result of GIST signalling
	should remain in place as long as the associated GIMPS state		should remain in place for as long as the associated GIST
	in the GaNAT remains valid. If GIMPS signalling refers to a		state in the GaNAT remains valid. If GIST signalling refers
	NAT binding that already exists, then the timeout of the NAT		to a NAT binding that already exists, then the timeout of the
	binding should occur according to the NAT policy, in a manner		NAT binding should occur according to the NAT policy, in a
	independing from GIMPS processing. (If signalling persists		manner independent from GIST processing. (If signalling
	after the deletion of a NAT binding, then the NAT binding may		persists after the deletion of a NAT binding, then the NAT
	be re-installed and then timeout together with GIMPS state).		binding may be re-installed and then timed out together with
			GIST state).
	3. Otherwise, if P.[IP header].DestinationIPAddress belongs to the		3. Otherwise, if P.[IP header].DestinationIPAddress belongs to the
	GaNAT, and if P is a GIMPS packet (either in D-mode or C-mode),		GaNAT, and if P carries the transport protocol and port numbers
	the GaNAT does the following. If P does not match an existing		indicated by some stack proposal ST that has previously been
	installed ST, P is silently discarded. (A packet P is said to		installed by the GaNAT, and if P has arrived on either the
	"match" an installed ST, if it carries the transport protocol and		upstream or the downstream interface that is associated with ST,
	port numbers indicated by ST.) Otherwise, if P has not arrived		then P is said to "match" ST. For such a packet, the GaNAT does
	on either the downstream or upstream link of some ST, it is		the following. If P is expected to contain a GIST header, then
	silently discarded. Otherwise, P has arrived either on the		the GaNAT check whether or not the bits where the GIST header is
	upstream or the downstream of some ST. The GaNAT constructs an		expected, consitute a valid GIST header. If not, P is silently
	outgoing packet P' as follows (the variables used below refer to		discarded. Otherwise, the GaNAT constructs an outgoing packet P'
	those stored together with the ST in question).		as follows (the variables used below refer to those stored
			together with ST).
	1. P' <- P		1. P' <- P
	2. If P has arrived on the upstream link, then		2. If P has arrived on the upstream link, then
	1. P'.[IP header].SourceIPAddress <- IPGaNATds		1. P'.[IP header].SourceIPAddress <- IPGaNATds
	2. P'.MRI <- GQ'.MRI		2. P'.MRI <- GQ'.MRI
	3. P'.NLI.IA <- IPGaNATus		3. P'.NLI.IA <- IPGaNATus
	skipping to change at page 14, line 5 ¶		skipping to change at page 17, line 36 ¶
	3. else (if P has arrived on the downstream link)		3. else (if P has arrived on the downstream link)
	1. P'.[IP header].SourceIPAddress <- IPGaNATus		1. P'.[IP header].SourceIPAddress <- IPGaNATus
	2. P'.MRI <- GQ.MRI		2. P'.MRI <- GQ.MRI
	3. P'.NLI.IA <- IPGaNATus		3. P'.NLI.IA <- IPGaNATus
	4. The GaNAT forwards P' on the upstream link.		4. The GaNAT forwards P' on the upstream link.
	Note: the above step will fail if ST indicates security.		Note that the GaNAT can determine the location in a packet
	That is, if traffic is encrypted, then the GaNAT cannot		where a GIST header is expected. If, for example, the packet
	construct P', and if traffic is integrity-protected,		is a UDP packet, then the GIST header should follow
	performing this step will cause an error at the receiving X		immediately after the UDP header. If the packet is a TCP
	peer. However, recall that, in this section, we only discuss		packet, then the GaNAT can determine the location where the
	the scenario where such cryptographic protection is not		GIST heaer should start by counting the number of NSLP
	required.		payload bits that followed the end of the previous GIST
			header. The start of the next GIST header is expected at the
			position where the previous GIST message, including NSLP
			payload, ends. The GaNAT can tell where this message ends
			from the LENGTH field inside the previous GIST header. It
			should be noted here that, in order to correctly count the
			bits, the GaNAT may have to keep track of TCP sequence
			numbers, and thereby be aware of the correct ordering of
			packets. However, the GaNAT only has to keep buffers that
			are as long as the LENGTH field inside the previous GIST
			header (and possibly up to one MTU size more than that).
			Also note that some TCP packets P may not be expected to
			contain any GIST header (this happens when the NSLP payload
			from a previous packet stretches over several packets). For
			those packets, the GaNAT only applies the transformation in
			the IP header. Finally, note that a GIST header may start a
			packet but finish in another. If such a packet is received
			by the GaNAT, it MUST buffer the entire packet, until the
			packet is received where the GIST header completes. It can
			then apply the required processing and forward both packets.
	4. Otherwise, if P matches a (data) NAT binding, the GaNAT applies		4. Otherwise, if P matches a (data) NAT binding, the GaNAT applies
	normal NAT processing and forwards the packet on the		normal NAT processing and forwards the packet on the
	corresponding link.		corresponding link.
	5. Otherwise, P is silently discarded.		5. Otherwise, P is silently discarded.
	Brief discussion of the algorithm: The fact that the GaNAT replaces		Brief discussion of the algorithm: The fact that the GaNAT replaces
	the X peer's NLI.IA with its own IP address (in both directions),		the NSLP peer's NLI.IA with its own IP address (in both directions),
	causes the peers to send subsequent signalling messages to the GaNAT,		causes the two GIST peers to send subsequent signalling messages to
	in the belief that they talk to the their adjacent X peer. The GaNAT		the GaNAT, in the belief that they talk to the their adjacent peer.
	transparently forwards the signalling traffic and appropriately		The GaNAT transparently forwards the signalling traffic and
	translates the fields in the GIMPS header, by making use of the state		appropriately translates the fields in the GIST header, in a way that
	it creates bindings.		is consistent with the translation it applies to the data traffic.
	Due to the presence of the GaNATs, no data traffic can be sent from		Note that, according to this mechanism, the size of an outgoing GIST
	DS to DR until all necessary bindings are in place. The MRI that the		message is always the same as the size of its corresponding incoming
	NR sees includes as destination address the IP address of the DR (as		GIST message. Finally note that the MRI that the NR sees indicates
	expected), but as source address the IPGaNATds of the GaNAT that is		as destination address the IP address of the DR (as expected), but as
			source address it indicates the is IPGaNATds of the GaNAT that is
	closest to the NR.		closest to the NR.
	5.1.2 NR-side NSLP-unaware GaNATs		5.2. NR-side NSLP-unaware GaNATs
	The case of NR-side GaNATs is more subtle, since, in this setting,		The case of NR-side GaNATs is more subtle, since, in this setting,
	the DS does not learn the IP address of the DR (which is assumed to		the DS does not learn the IP address of the DR (which is assumed to
	be on the same side of the GaNATs as the NR) and the NI does not		be on the same side of the GaNATs as the NR) and the NI does not
	learn the address of the NR. In this setting we assume that each NR-		learn the address of the NR. In this setting we assume that each NR-
	side GaNAT that is in between two X peers, a priori knows the IP		side GaNAT that is in between two GIST peers, a priori knows a
	address of the downstream GaNAT. The last GaNAT of this chain is		routable IP address of the downstream GaNAT. The last GaNAT of this
	assumed to know the IP address of the DR. In order to clarify this		chain is assumed to know the IP address of the DR. In order to
	assumption, see, for example, Figure 2. In this figure, GaNAT A is		clarify this assumption, see, for example, Figure 2. In this figure,
	assumed to know the IP address of GaNAT B, GaNAT B is assumed to know		GaNAT A is assumed to know the IP address of GaNAT B, GaNAT B is
	the IP address of GaNAT C, and GaNAT C is assumed to know the IP		assumed to know the IP address of GaNAT C, and GaNAT C is assumed to
	address of the DR. A given GaNAT that knows such an address, in		know the IP address of the DR. A given GaNAT that knows such an
	effect anticipates to receive a signalling message from the upstream		address, in effect anticipates to receive a signalling message from
	direction that refers to a data flow that terminates in a downstream		the upstream direction that refers to a data flow that terminates in
	node. In other words, such a GaNAT may typically have already a NAT		a downstream node. In other words, such a GaNAT may typically have
	binding in place for the data traffic. We call the IP address of the		already a NAT binding in place for the data traffic. We call the IP
	next downstream GaNAT (or, if the GaNAT is the last in the chain, the		address of the next downstream GaNAT (or, if the GaNAT is the last in
	DR) the "pending" IP address. In the following description it is		the chain, the address of the DR) the "pending" IP address. In the
	denoted by IPNext. How IPNext is made known to each GaNAT (e.g. how		following description it is denoted by IPNext. How IPNext is made
	the NAT binding for the data traffic is installed in the GaNAT) is		known to each GaNAT (e.g. how the NAT binding for the data traffic is
	outside the scope of this document.		installed in the GaNAT) is outside the scope of this document.
	+--+ +------+ +-----+ +-----+ +-----+ +------+ +--+ +--+		+--+ +------+ +-----+ +-----+ +-----+ +------+ +--+ +--+
	+NI+--+X NSLP+---+GaNAT+---+GaNAT+---+GaNAT+---+X NSLP+--+NR+--+DR|		+NI+--+ GIST +---+GaNAT+---+GaNAT+---+GaNAT+---+ GIST +--+NR+--+DR|
	+--+ |peer 1| | A | | B | | C | |peer 2| +--+ +--+		+--+ |peer 1| | A | | B | | C | |peer 2| +--+ +--+
	+------+ +-----+ +-----+ +-----+ +------+		+------+ +-----+ +-----+ +-----+ +------+
	Figure 2: Network with NR-side GaNATs (the public Internet is assumed		Figure 2: Network with NR-side GaNATs (the public Internet is assumed
	to be between NI and X NSLP peer 1)		to be between NI and GIST peer 1)
	For every arriving IP packet P, an X-unaware, NR-side GaNAT executes		For every arriving IP packet P, an NSLP-unaware, NR-side GaNAT
	the following algorithm.		executes the following algorithm.
	1. If P has a RAO followed by the GIMPS header with NSLP ID = X, it		1. If P has a RAO followed by the GIST header with the NSLP ID
	is identified as a GIMPS QUERY. In this case the GaNAT does the		indicates an unsupported NSLP, it is identified as a GIST QUERY.
	following.		In this case the GaNAT does the following.
	1. We denote P as GQ. The GaNAT looks at the stack proposal ST		1. We denote P as GQ. The GaNAT looks at the stack proposal ST
	in GQ. If it indicates that cryptographic protection is		in GQ. If it indicates that cryptographic protection is
	required, the algorithm that is executed is the one described		required, the algorithm that is executed is the one described
	in section Section 6 below.		in section Section 6 below.
	2. The GaNAT remembers GQ along with the link on which it		2. The GaNAT remembers GQ along with the link on which it
	arrived. We call this link the "upstream" link.		arrived. We call this link the "upstream" link.
	3. The GaNAT determines whether or not this GIMPS QUERY is		3. The GaNAT determines whether or not this GIST QUERY is
	anticipated, i.e. if a pending IPNext exists. If no IPNext		anticipated, i.e. if a pending IPNext exists that matches
	is pending, P is discarded (it is a question whether or not		this GIST QUERY. A pending IPNext is said to "match" a GIST
	an error message should be sent). Otherwise, additional		QUERY, if [this condition is an open issue!] If no pending
	checks may be performed (e.g. a DSInfo object may have to be		IPNext is also matching, P is discarded (it is a question
	checked against the GQ). If these checks fail, P is		whether or not an error message should be sent). Otherwise,
	discarded. Otherwise, the GaNAT performs the following.		additional checks may be performed (e.g. a DSInfo object may
			have to be checked against the GQ). If these checks fail, P
			is discarded. Otherwise, the GaNAT performs the following.
	4. It searches its table of existing NAT bindings against		4. It searches its table of existing NAT bindings against
	entries that match the GQ.MRI. A matching entry means that		entries that match the GQ.MRI. A matching entry means that
	the data flow, to which the signalling refers, already		the data flow, to which the signalling refers, already
	exists.		exists.
	+ If a matching entry is found, the GaNAT looks at which		+ If a matching entry is found, the GaNAT looks at which
	link the packets of the data flow are forwarded; we call		link the packets of the data flow are forwarded; we call
	this link the "downstream" link. Further, the GaNAT		this link the "downstream" link. Further, the GaNAT
	checks how the headers of the data flow (IP addresses,		checks how the headers of the data flow (IP addresses,
	skipping to change at page 16, line 24 ¶		skipping to change at page 20, line 32 ¶
	GQ.MRI.DestinationIPAddress is replaced with IPNext) would		GQ.MRI.DestinationIPAddress is replaced with IPNext) would
	be forwarded. We call this link the "downstream" link.		be forwarded. We call this link the "downstream" link.
	Then, the GaNAT acquires an IP address for itself on the		Then, the GaNAT acquires an IP address for itself on the
	downstream link. (This address could be dynamic or		downstream link. (This address could be dynamic or
	static.) Depending on its type, the GaNAT may also		static.) Depending on its type, the GaNAT may also
	acquire source port numbers for the translation of data		acquire source port numbers for the translation of data
	traffic. We denote the acquired IP address as IPGaNATds		traffic. We denote the acquired IP address as IPGaNATds
	and the source port numbers for data and signalling		and the source port numbers for data and signalling
	traffic as SPNDTGaNATds and SPNSTGaNATds respectively.		traffic as SPNDTGaNATds and SPNSTGaNATds respectively.
	5. It creates a new GIMPS QUERY packet GQ', as follows.		5. It creates a new GIST QUERY packet GQ', as follows.
	1. GQ' <- GQ		1. GQ' <- GQ
	2. GQ'.MRI.SourceIPAddress <- IPGaNATds		2. GQ'.MRI.SourceIPAddress <- IPGaNATds
	3. GQ'.MRI.DestinationIPAddress <- IPNext.		3. GQ'.MRI.DestinationIPAddress <- IPNext.
	4. GQ'.MRI.SourcePort <- SPNDTGaNATds.		4. GQ'.MRI.SourcePort <- SPNDTGaNATds.
	5. GQ'.[IP header].SourceIPAddress <- IPGaNATds		5. GQ'.[IP header].SourceIPAddress <- IPGaNATds
	6. GQ'.[TRANSPORT_LAYER_HEADER].SourcePort <- SPNSTGaNATds		6. GQ'.[UDP HEADER].SourcePort <- SPNSTGaNATds
	7. GQ'.[IP header].Destination_IP_Address <- IPNext		7. GQ'.[IP header].Destination_IP_Address <- IPNext
	8. GQ'.NLI.IA <- IPGaNATds.		8. GQ'.NLI.IA <- IPGaNATds.
	9. GQ'.S <- true		9. GQ'.S <- true
	6. It remembers GQ, GQ' the fact that they are associated, and		6. It remembers GQ, GQ' the fact that they are associated, and
	the associated upstream and downstream links (interfaces).		the associated upstream and downstream links (interfaces).
	7. It forwards GQ' on the downstream link.		7. It forwards GQ' on the downstream link.
	Steps 2,3, 4 and 5 of the algorithm are analogous to the		Steps 2,3, 4 and 5 of the algorithm are analogous to the
	corresponding steps of the algorithm executed by X-unaware, NI-side		corresponding steps of the algorithm executed by NSLP-unaware, NI-
	GaNATs, which was described in Section 5.1.1		side GaNATs, which was described in Section 5.1.
	5.2 NSLP-aware GaNATs		5.3. NSLP-aware GaNATs
	Recall that X may be any NSLP except NATFW. The difference of		The difference of NSLP-aware GaNATs and NSLP-unaware GaNATs is that
	X-aware GaNATs and X-unaware GaNATs is that the former perform X		the former perform NSLP processing in addition to the processing of
	processing in addition to the processing of the X-unaware GaNATs.		the NSLP-unaware GaNATs. Another way to see this is by observing
	Another way to see this is by observing that X-aware GaNATs should		that NSLP-aware GaNATs should provide an "MRI translation service"
	provide an "MRI translation service" (MRITS) in addition to normal		(MRITS) in addition to normal GIST and NSLP processing. The
	GIMPS and X processing. The motivation behind the MRITS is for GIMPS		motivation behind the MRITS is for GIST to hide from the NSLP that
	to hide from the NSLP that signalling messages traverse an addressing		signalling messages traverse an addressing boundary. In other words,
	boundary. In other words, the purpose of the MRITS it to make X		the purpose of the MRITS is to make the NSLP believe that it is
	believe that it is operating in a single IP addressing space. When		operating in a single IP addressing space. When and how the MRITS is
	and how the MRITS is invoked for a particular packet depends on (i)		invoked for a particular packet depends on (i) the direction of the
	the direction of the packet (i.e. downstream or upstream) and (ii)		packet (i.e. downstream or upstream) and (ii) the location of the
	the location of the GaNAT (i.e. NI-side or NR-side). It should also		GaNAT (i.e. NI-side or NR-side). It should also be noted that
	be noted that certain NSLP layer tasks must be carried out in		certain NSLP layer tasks must be carried out in consistency with the
	consistency with the placement of the MRITS. This is to prevent		placement of the MRITS. This is to prevent events triggered by the
	events triggered by X to cause installation of inconsistent state.		NSLP to cause installation of inconsistent state. In order to
	In order to clarify this, consider the scenario of the QoS NSLP		clarify this, consider the scenario of the QoS NSLP running in a
	running in a GaNAT that operates according to the mechanisms		GaNAT that operates according to the mechanisms described in this
	described in this section. Since the GaNAT only presents a single		section. Since the GaNAT only presents a single addressing space to
	addressing space to the NSLP (say, the internal addressing space),		the NSLP (say, the internal addressing space), the packet classifier
	the packet classifier of the GaNAT's QoS provisioning subsystem		of the GaNAT's QoS provisioning subsystem should classify packets
	should classify packets based on internal addresses only (i.e. it		based on internal addresses only (i.e. it should first translate
	should first translate packets that carry external addresses and then		packets that carry external addresses and then classify them).
	classify them). Whether the MRITS presents internal-only or		Whether the MRITS presents internal-only or external-only addresses
	external-only addresses to the NSLP is not significant, as long as		to the NSLP is not significant, as long as NSLP layer operations are
	NSLP layer operations are carried out consistently. In the remainder		carried out consistently. In the remainder of this section we
	of this section we present the case where internal addresses are		present the case where internal addresses are presented to the NSLP.
	presented to the NSLP.
	The MRITS is obviously invoked only on GIMPS packets that carry NSLP		The MRITS is obviously invoked only on GIST packets that carry an
	identifier = X. (For other GIMPS packets the GaNAT may adopt the role		NSLP identifier that corresponds to an NSLP that the GaNAT actually
	of an X-unaware GaNAT. Also, for non-GIMPS packets, normal NAT		supports. Also, for non-GIST packets, normal NAT behaviour applies.
	behaviour applies - whatever "normal" may mean.) Although the MRITS		Although the MRITS is part of GIST processing, in order to clarify
	is part of GIMPS processing, in order to clarify our discussion, we		our discussion, we view it as a somewhat separate processing step
	view it as a somewhat separate processing step (i.e. like a		(i.e. like a subroutine). For NI-side, NSLP-aware GaNATs, it holds
	subroutine). For NI-side, X-aware GaNATs, it holds that		that
			o for a GIST/NSLP packet that is to be forwarded on the downstream
			link of an NI-side GaNAT, the MRITS is invoked after the packet
			has been processed by the NSLP and before it is given to GIST, and
	o if a GIMPS/X packet is to be forwarded on the downstream link of		o for a GIST/NSLP packet that is received on the downstream link,
	an NI-side GaNAT, the MRITS is invoked after the packet has been		the MRITS is invoked after GIST processing and before the packet
	processed by X and before it is given to GIMPS, and		is given to the NSLP.
	o if a GIMPS/X packet is received on the downstream link, then the		The converse holds for NR-side NSLP-aware GaNATs. In particular,
	MRITS is invoked after GIMPS processing and before the packet is
	given to X.
	The converse holds for NR-side X-aware GaNATs. In particular,		o for a GIST/NSLP packet that is to be forwarded on the upstream
	o if a GIMPS/X packet is to be forwarded on the upstream link of an		link of an NI-side GaNAT, the MRITS is invoked after the packet
	NI-side GaNAT, the PTS is invoked after the packet has been		has been processed by the NSLP and before it is given to GIST, and
	processed by X and before it is given to GIMPS, and
	o if a GIMPS/X packet is received on the upstream link, then the PTS		o for a GIST/NSLP packet that is received on the upstream link, the
	is invoked after GIMPS processing and before X processing.		MRITS is invoked after GIST processing and before NSLP processing.
	Figure 3 illustrates this idea.		Figure 3 illustrates this idea.
	+----------------+ +----------------+		+----------------+ +----------------+
	| +------+ | | +------+ |		| +------+ | | +------+ |
	| |NSLP X| | | |NSLP X| |		| | NSLP | | | | NSLP | |
	| +-+---++ | | +-+--+-+ |		| +-+---++ | | +-+--+-+ |
	| | | | | | | |		| | | | | | | |
	| | +-+---+ | | +----++ | |		| | +-+---+ | | +----++ | |
	| | |MRITS| | | |MRITS| | |		| | |MRITS| | | |MRITS| | |
	| | +---+-+ | | ++----+ | |		| | +---+-+ | | ++----+ | |
	| | | | | | | |		| | | | | | | |
	| +-+-----+-+ | | ++------+-+ |		| +-+-----+-+ | | ++------+-+ |
	| | GIMPS | | | | GIMPS | |		| | GIST | | | | GIST | |
	u/s | +-+-----+-+ | d/s u/s | ++------+-+ | d/s		u/s | +-+-----+-+ | d/s u/s | ++------+-+ | d/s
	-----+----+ +-----+----- -----+---+ +-----+-----		-----+----+ +-----+----- -----+---+ +-----+-----
	link +----------------+ link link +----------------+ link		link +----------------+ link link +----------------+ link
	NI-side NR-side		NI-side NR-side
	X-aware X-aware		NSLP-aware NSLP-aware
	GaNAT GaNAT		GaNAT GaNAT
	Figure 3: Operation of the MRI Translation Service		Figure 3: Operation of the MRI Translation Service
	The reason for this construction is to give X the impression that it		The reason for this construction is to give the NSLP the impression
	works only with flows that originate and terminate in the internal		that it works only with flows that originate and terminate in the
	address space. We now describe the operation of the MRITS and GIMPS		internal address space. We now describe the operation of the MRITS
	in X-aware GaNATs. An NI-side X-aware GaNAT operates according to		and GIST in NSLP-aware GaNATs. An NI-side NSLP-aware GaNAT operates
	the following rules.		according to the following rules.
	1. When X asks for a message to be sent towards the downstream X		1. When the NSLP asks for a message to be sent towards the
	peer, the MRITS does the following (IPGaNATds and SPNDTGaNATds		downstream GIST peer, the MRITS does the following (IPGaNATds and
	are obtained similarly to the case of an NSLP-unaware GaNAT).		SPNDTGaNATds are obtained similarly to the case of an NSLP-
			unaware GaNAT).
	1. MRI.SourceIPAddress <- IPGaNATds		1. MRI.SourceIPAddress <- IPGaNATds
	2. MRI.SourcePort <- SPNDTGaNATds		2. MRI.SourcePort <- SPNDTGaNATds
	2. Additionally, GIMPS performs the following on the resulting		2. Additionally, GIST performs the following on the resulting packet
	packet before it is forwarded on the downstream link		before it is forwarded on the downstream link (SPNSTGaNATds is
	(SPNSTGaNATds is obtained similarly to the case of an NSLP-		obtained similarly to the case of an NSLP-unaware GaNAT).
	unaware GaNAT).
	1. [IP header].SourceIPAddress <- IPGaNATds		1. [IP header].SourceIPAddress <- IPGaNATds
	2. [UDP/TCP header].SourcePort <- SPNSTGaNATds		2. [UDP/TCP header].SourcePort <- SPNSTGaNATds
	3. NLI.IA < IPGaNATds		3. NLI.IA <- IPGaNATds
	4. S <- true		4. S <- true
	3. If a message is received on the downstream link, the MRITS does		3. If a message is received on the downstream link, the MRITS does
	the following before X is invoked.		the following before the NSLP is invoked.
	1. MRI.SourceIPAddress <- IPflow		1. MRI.SourceIPAddress <- IPflow
	2. MRI.SourcePort <- SPNDTGaNATus, where IPflow is the IP		2. MRI.SourcePort <- SPNDTGaNATus, where IPflow is the IP
	address of the DS (as seen by the GaNAT) and SPNDTGaNATus is		address of the DS (as seen by the GaNAT) and SPNDTGaNATus is
	the destination port number used in the original MRI.		the destination port number used in the original MRI.
	4. If, after X processing, a message is to be forwarded on the		4. If, after NSLP processing, a message is to be forwarded on the
	upstream link, GIMPS performs the following processing (note that		upstream link, GIST performs the following processing (note that
	no MRITS processing takes place in this case).		no MRITS processing takes place in this case).
	1. [IP header].SourceIPAddress <- IPGaNATus		1. [IP header].SourceIPAddress <- IPGaNATus
	2. [IP header].DestinationIPAddress <- IPpeer		2. [IP header].DestinationIPAddress <- IPpeer
	3. NLI.IA <- IPGaNATus		3. NLI.IA <- IPGaNATus
	4. S <- true, where IPGaNATus is the GaNATs IP address for the		4. S <- true, where IPGaNATus is the GaNATs IP address for the
	upstream link, IPpeer is the IPaddress of the NI (or the next		upstream link, IPpeer is the IPaddress of the NI (or the next
	GaNAT in the upstream direction), and IPflow is the IP		GaNAT in the upstream direction), and IPflow is the IP
	address of the DS (as seen by the GaNAT). The GaNAT is		address of the DS (as seen by the GaNAT). The GaNAT is
	assumed to determine the correct IPGaNATus and IPpeer from		assumed to determine the correct IPGaNATus and IPpeer from
	previous communications and in cooperation with GIMPS.		previous communications and in cooperation with GIST.
	[Issue: how exactly should IPGaNATus, IPpeer and IPflow be		[Issue: how exactly should IPGaNATus, IPpeer and IPflow be
	resolved; i.e. what exactly should the GaNAT remember?]		resolved; i.e. what exactly should the GaNAT remember?]
	An NR-side X-aware GaNAT operates according to the following rules.		An NR-side NSLP-aware GaNAT operates according to the following
			rules.
	1. If the packet is received on the upstream link, the MRITS does		1. If the packet is received on the upstream link, the MRITS does
	the following, before X is notified.		the following, before the NSLP is notified.
	1. P.MRI.SourceIPAddress <- IPGaNATds		1. P.MRI.SourceIPAddress <- IPGaNATds
	2. P.MRI.DestinationIPAddress <- IPNext, where IPGaNATds is the		2. P.MRI.DestinationIPAddress <- IPNext, where IPGaNATds is the
	GaNAT's IP address for the downstream link and IPNext is the		GaNAT's IP address for the downstream link and IPNext is the
	address of the DR. IPNext is obtained in a way similar to		address of the DR. IPNext is obtained in a way similar to
	the case of an NSLP-unaware GaNAT.		the case of an NSLP-unaware GaNAT.
	2. If, after X processing, a message is to be forwarded on the		2. If, after NSLP processing, a message is to be forwarded on the
	downstream link, GIMPS performs the following processing (note		downstream link, GIST performs the following processing (note
	that no MRITS processing takes place in this case).		that no MRITS processing takes place in this case).
	1. [IP header].SourceIPAddress <- IPGaNATds		1. [IP header].SourceIPAddress <- IPGaNATds
	2. [IP header].DestinationIPAddress <- IPNext		2. [IP header].DestinationIPAddress <- IPNext
	3. NLI.IA <- IPGaNATds		3. NLI.IA <- IPGaNATds
	4. S <- true, where IPGaNATds is the GaNATs IP address for the		4. S <- true, where IPGaNATds is the GaNATs IP address for the
	downstream link, IPNext is the IP address of the DR (or the		downstream link, IPNext is the IP address of the DR (or the
	next GaNAT in the downstream direction). The GaNAT is		next GaNAT in the downstream direction). The GaNAT is
	assumed to determine the correct IPNext in a way similar to		assumed to determine the correct IPNext in a way similar to
	the case of an NSLP-unaware GaNAT.		the case of an NSLP-unaware GaNAT.
	3. When X asks for a message to be sent towards the upstream X peer,		3. When the NSLP asks for a message to be sent towards the upstream
	the MRITS does the following.		GIST peer, the MRITS does the following.
	1. MRI.SourceIPAddress <- IPflow		1. MRI.SourceIPAddress <- IPflow
	2. MRI.Destination_IP_Address <- IPGaNATus		2. MRI.Destination_IP_Address <- IPGaNATus
	4. Additionally, GIMPS performs the following on the resulting		4. Additionally, GIST performs the following on the resulting packet
	packet before it is forwarded on the downstream link.		before it is forwarded on the downstream link.
	1. [IP header].SourceIPAddress <- IPGaNATus		1. [IP header].SourceIPAddress <- IPGaNATus
	2. [IP header].DestinationIPAddress <- IPpeer		2. [IP header].DestinationIPAddress <- IPpeer
	3. NLI.IA <- IPGaNATus		3. NLI.IA <- IPGaNATus
	4. S <- true, where IPGaNATus is the GaNATs IP address for the		4. S <- true, where IPGaNATus is the GaNATs IP address for the
	upstream link, IPpeer is the IP_address of the NI (or the		upstream link, IPpeer is the IP address of the NI (or the
	next GaNAT in the upstream direction), and IPflow is the IP		next GaNAT in the upstream direction), and IPflow is the IP
	address of the DS. The GaNAT is assumed to determine the		address of the DS. The GaNAT is assumed to determine the
	correct IPGaNATus and IPpeer fields from previous		correct IPGaNATus and IPpeer fields from previous
	communications and in cooperation with GIMPS. [question: how		communications and in cooperation with GIST. [question: how
	exactly should IPGaNATus and IPpeer be resolved; i.e. what		exactly should IPGaNATus and IPpeer be resolved; i.e. what
	exactly should the GaNAT remember]?		exactly should the GaNAT remember]?
	5.3 Combination of NSLP-aware and NSLP-unaware GaNATs		5.4. Combination of NSLP-aware and NSLP-unaware GaNATs
	In the absence of an adversary, a combination of NSLP-aware and NSLP-		In the absence of an adversary, a combination of NSLP-aware and NSLP-
	unaware GaNATs should work without further specification. However,		unaware GaNATs should work without further specification. However,
	in the presence of an adversary, additional security issues may arise		in the presence of an adversary, additional security issues may arise
	from the combination. These issues may introduce opportunities for		from the combination. These issues may introduce opportunities for
	attack that do not exist in setting where the on-path GaNATs are		attack that do not exist in setting where the on-path GaNATs are
	either all X-aware or all X-unaware.		either all NSLP-aware or all NSLP-unaware.
	6. GaNATs in the presence of TLS or IPSec
	This section discusses GaNAT traversal for GIMPS in the case where
	two peers that run a particular NSLP, say NSLP X, require
	cryptographic protection of the signalling traffic they exchange. As
	with the case where no cryptographic protection of signalling traffic
	is required, the case of the in-between GaNAT(s) being X-unaware is
	different from the case of them being X-aware.
	6.1 NSLP-unaware GaNATs		6. Non-transparent NAT traversal
	If the two X peers require a C-mode protocol stack that indicates		This section discusses the "non-transparent" operation for GaNAT
	cryptographic protection, then, after the stack has been agreed by		traversal at the GIST layer, i.e. the first approach listed in
	both peers and the underlying cryptographic protection is applied to		Section 3. For this approach, the behaviour of both the GaNAT and
	messages, the GaNAT will be unable to translate the GIMPS header		the GIST peers is defined. As with the transparent approach, the
	fields, in a way similar to the way described in Section 5.1.1. An		case of the in-between GaNAT(s) being located at the NI-side is
	approach to cope with this, is to inform the X peers about the		different from that of NR-side GaNATs. Note that the mechanisms in
	presence of the NAT during discovery. This information will enable		this section apply only to NSLP-unware GaNATs.
	the X peers, rather than the GaNAT(s) to perform the translation of
	the fields involved, after the necessary cryptographic operations
	have been completed. In this scenario, the burden imposed on the
	GaNAT is considerably less, as the only type of GIMPS messages that
	it needs to process in a special way, are the GIMPS QUERY and GIMPS
	RESPONSE messages.
	In order to support the scenario of X-unaware GaNATs, a new GIMPS		The GaNAT informs the NSLP peers about its presence during the GIST
	payload type has to be defined that encodes the aforementioned		discovery process. This information enables the NSLP peers to map
	information. We call this payload type the "NAT Traversal Object"		the translated data flow to the signalling messages, and to
	(NTO). The NTO is an optional payload in the GIMPS header of a GIMPS		consistently translate the MRI, so that the NSLP only "sees" the
	QUERY, and is added, and processed, by the GaNAT(s) through which the		correct MRI. Cryptographic protection of signalling messages can be
	QUERY traverses. The information in the NTO must enable the two X		supported with this approach because the GaNAT only modifies the GIST
	peers to locally translate the MRI in the same way as it would have		QUERY and REPONSE messages, which are never cryptographically
	been translated by the in-between GaNAT(s) if no cryptographic		protected in their entirety.
	protection was applied to the signalling traffic. Note that there
	may be more than one GaNAT between the two X peers. We now describe
	the algorithm that an X-unaware GaNAT must execute in order to enable
	the two X peers to reach this goal.
	The two types of GaNATs, namely those at the NSIS initiator (NI)		In this approach, the GaNAT embeds a new GIST payload type into the
	side, and those at the NSIS responder (NR) side, follow different		GIST QUERY. This payload encodes the aforementioned information, and
	algorithms.		we call this payload type the "NAT Traversal Object" (NTO). The NTO
			is an optional payload in the GIST header of a GIST QUERY, and is
			added, and processed, by the GaNAT(s) through which the QUERY
			traverses. The information in the NTO must enable the two NSLP peers
			to locally translate the MRI in the same way as if it were
			consistently and transparently translated by the in-between GaNAT(s).
			Note that there may be more than one GaNAT between the two NSLP
			peers. The format of the NTO follows the format of the object in the
			GIST common header. In particular, the NTO is preceded by a TLV
			common header, as defined in [1]. The A and B flags are both set to
			0 in this header, indicating that support for the NTO is mandatory.
			The type value is TBD. The NTO is defined as in section A.3.8 of
			[1].
	6.1.1 NI-side NSLP-unaware GaNATs		6.1. NI-side NSLP-unaware GaNATs
	For every arriving IP packet P, an X-unaware, NI-side GaNAT executes		For every arriving IP packet P, an NSLP-unaware, NI-side GaNAT
	the following algorithm.		executes an algorithm that is equivalent to the following.
	1. If P has a RAO followed by the GIMPS header with an NSLP ID that		1. If P has a RAO followed by the GIST header with an NSLP ID that
	is not supported, it is identified as a GIMPS QUERY. In this		is not supported, it is identified as a GIST QUERY. In this case
	case the GaNAT does the following.		the GaNAT does the following.
	1. We denote P as GQ. The GaNAT looks at the stack proposal ST		1. We denote P as GQ. The GaNAT looks at the stack proposal ST
	in GQ. If it does not indicate that cryptographic protection		in GQ. If it does not include a proposal with cryptographic
	is required, the algorithm that is executed is the one		protection, the GaNAT MAY choose to follow the approach
	described in Section 5.1.1 above.		described in Section 5.1 above.
	2. The GaNAT remembers GQ along with the link on which it		2. We call the link on which GQ arrived the "upstream" link.
	arrived. We call this link the "upstream" link.
	3. The GaNAT searches its table of existing NAT bindings against		3. The GaNAT searches its table of existing NAT bindings against
	entries that match the GQ.MRI. A matching entry means that		entries that match the GQ.MRI. A matching entry means that
	the data flow, to which the signalling refers, already		the data flow, to which the signalling refers, already
	exists.		exists.
	+ If a matching entry is found, the GaNAT looks at which		+ If a matching entry is found, the GaNAT looks at which
	link the packets of the data flow are forwarded; we call		link the packets of the data flow are forwarded; we call
	this link the "downstream" link. Further, the GaNAT		this link the "downstream" link. Further, the GaNAT
	checks how the headers of the data flow (IP addresses,		checks how the headers of the data flow (IP addresses and
	source port number, etc) are translated according to this		port numbers) are translated according to this NAT
	NAT binding.		binding.
	+ If no matching entry is found, the GaNAT determines, based		+ If no matching entry is found, the GaNAT determines, based
	on its routing table, the link on which packets that match		on its routing table, the link on which packets that match
	GQ.MRI (excluding GQ.MRI.SourceIPAddress) would be		GQ.MRI (excluding GQ.MRI.SourceIPAddress) would be
	forwarded. We call this link the "downstream" link.		forwarded. We call this link the "downstream" link.
	Then, the GaNAT acquires an IP address for itself on the		Then, the GaNAT acquires an IP address and source port for
	downstream link. (This address could be dynamic or		itself on the downstream link. (This address and port
	static.)		could be dynamic or static.)
	4. We denote [IP header].SourceIPAddress used on the downstream		4. We denote [IP header].SourceIPAddress used on the downstream
	link as IPGaNATds, and the source port number for the data		link as IPGaNATds, and the source port number for the data
	and signalling traffic as SPNDTGaNATds and SPNSTGaNATds		and signalling traffic as SPNDTGaNATds and SPNSTGaNATds
	respectively.		respectively.
	5. It creates a new GIMPS QUERY packet GQ', as follows (note		5. It creates a new GIST QUERY packet GQ', as follows.
	that the new packet contains the same MRI as GQ).
	1. GQ' <- GQ		1. GQ' <- GQ
	2. GQ'.[IP header].SourceIPAddress <- IPGaNATds.		2. GQ'.MRI.SourceAddress <- IPGaNATds.
	3. GQ'.[UDP].SourcePort <- SPNSTGaNATds.		3. GQ'.MRI.SourcePort <- SPNDTGaNATds.
	4. GQ'.S <- true		4. GQ'.NLI.IA.<- IPGaNATds.
	5. It checks whether or not a NTO is included in the GQ.
	- If none is included, it adds a new one to GQ' such		5. GQ'.[IP header].SourceIPAddress <- IPGaNATds.
	that GQ'.NTO=[ IPGaNATds || SPNDTGaNATds]
	- If one is included, it replaces it as GQ'.NTO=[		6. GQ'.[UDP header].SourcePort <- SPNSTGaNATds.
	IPGaNATds || SPNDTGaNATds]
	6. It remembers GQ, GQ' the fact that they are associated,		7. GQ'.S <- true.
	and the associated upstream and downstream links.
	7. It forwards GQ' on the downstream link.		8. It checks whether or not an NTO was included in GQ.
	2. Otherwise, if P carries a [IP header].DestinationIPAddress that		- If none was included, it creates a new NTO as follows
	belongs to the GaNAT, and if it is identified as a GIMPS response		and adds it to GQ'.
	in D-mode with an NSLP ID that is not supported, the GaNAT does
	the following (P is denoted as GR).
	1. It searches for a matching GQ' in its buffer. A GQ' is said		o NTO.[NAT Count] <- 1.
	to be matching if it carries the same cookie value. If none
	is found, GR is discarded. Otherwise, the GaNAT should also		o NTO.MRI <- GQ.MRI.
	make sure that the session ID in GR is the same as in GQ' and
	that the NSLP IDs match. If these consistency checks fail,		o NTO.[List of translated objects] <- [type of MRI],
	GR should be discarded. Otherwise, the GaNAT constructs a		[type of NLI], [type of SCD]
	new GIMPS response GR', as follows (note that no changes are
	made to the MRI).		o NTO.opaque information for NAT 1 <- GQ.[IP
			header].SourceAddress, [link identifier of upstream
			link].
			- If one was included, it replaces certain fields and
			appends new fields into the NTO, as follows, and adds
			the resulting object to GQ'.
			o NTO.[NAT Count] <- i, where i is the current [NAT
			count] value increased by one.
			o NTO.[List of translated objects] <- [type of MRI],
			[type of NLI], [type of STD]
			o NTO.[opaque information replaced by NAT i] <-
			GQ.[IP header].SourceAddress, [LinkID of upstream
			link].
			9. It forwards GQ' on the downstream link. Note: The
			encoding of the information that the GaNAT encodes into
			the NTO.[opaque information replaced by NAT i] field is a
			local implementation issue.
			2. Otherwise, if P carries an [IP header].DestinationIPAddress that
			belongs to the GaNAT, and if it is identified as a GIST RESPONSE
			packet in datagram mode with an NSLP ID that is not supported,
			the GaNAT does the following (P is denoted as GR).
			1. If P does not contain an NTO, the GaNAT forwards it as usual
			without further processing. Otherwise, the GaNAT selects the
			information encoded by it in the [opaque information replaced
			by NAT] field of the embedded NTO, denoted by IPAddressToSend
			and LinkID. If multiple [opaque information replaced by NAT]
			fields are present in the NTO, the GaNAT uses the last one in
			the list. It then constructs a new GIST response GR', as
			follows (note that no changes are made to the MRI).
	1. GR' <- GR		1. GR' <- GR
	2. GR'.[IP header].SourceIPAddress <- IPGaNATus, where		2. GR'.[IP header].DestinationIPAddress <- IPAddressToSend.
	IPGaNATus = GQ.[IP header].DestinationIPAddress.
	3. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA		3. GR'.NTO.[NAT Count] <- current value minus one.
	4. GP'.S <- true.		4. Remove the last [opaque information replaces by NAT i]
			field from GR'.NTO
	5. It checks whether or not a NTO is included in the GQ.		5. GR'.S <- true.
	- If none is included, it adds a new one to GQ' such		2. It forwards GR' on the upstream link, i.e. the link
	that GQ'.NTO=[ IPGaNATus || PNGaNATus]		identified by LinkID.
	- If one is included, it replaces it such that GQ'.NTO=[		3. The GaNAT SHOULD now invalidate all but one stack
	IPGaNATus || PNGaNATus]		configuration objects in the stack proposal in GR'. This is
			done so that the quering node can only chose that one
			proposal, and that therefore only one NAT binding must be
			installed for the signalling traffic to traverse the GaNAT.
			The GaNAT SHOULD keep valid the strongest, in terms of
			security, stack proposal. We denote this proposal as PR.
	6. It remembers GQ, GQ' the fact that they are associated,		4. The GaNAT now installs a NAT binding for the signalling
	and the associated upstream and downstream links.		traffic which says that "a packet K that arrives on the
			upstream link and for which it holds that
	7. It forwards GQ' on the downstream link.		+ K.[IP header].SourceIPAddress=IPAddressToSend,
	2. It forwards GR' on the upstream link.		+ K.[IP header].Protocol=PR.Protocol, and
	3. If no NAT binding for the data traffic was found in step		+ K.[TCP/UDP header].DestinationPort=PR.[Destination Port]
			should be forwarded on the downstream link (i.e. on the link
			on which GR arrived), with [IP header].SourceIPAddress =
			IPGaNATds.
			5. If no NAT binding for the data traffic was found in step
	1.3.2, the GaNAT now installs a NAT binding (for the		1.3.2, the GaNAT now installs a NAT binding (for the
	unidirectional data traffic) which says that "a packet K that		unidirectional data traffic) which says that "a packet K that
	arrives on the upstream link and for which it holds that		arrives on the upstream link and for which it holds that
	+ K.[IP		+ K.[IP header].DestinationIPAddress=GQ'.NTO.MRI.Destination
	header].DestinationIPAddress=GQ.MRI.DestinationIPAddress,		IPAddress,
	+ K.[IP header].Protocol=GQ.MRI.Protocol, and		+ K.[IP header].Protocol=GQ'.NTO.MRI.Protocol, and
	+ K.[TCP/UDP header].PortNumbers=GQ.MRI.PortNumbers		+ K.[TCP/UDP header].PortNumbers=GQ'.NTO.MRI.PortNumbers
	should be forwarded on the upstream link, with [IP		should be forwarded on the downstream link (i.e. the link on
	header].SourceIPAddress = IPGaNATus.		which GR arrived), with [IP header].SourceIPAddress =
			IPGaNATds and [UDP/TCP header].SourcePort=SPDTGaNATds.
	Issues: there is a question of whether this NAT binding		Issues: there is a question of whether this NAT binding
	should also enable data traffic in the opposite direction to		should also enable data traffic in the opposite direction to
	traverse the NAT; in order to be able to demultiplex upstream		traverse the NAT; in order to be able to demultiplex upstream
	traffic that carries data that belongs to different flows,		traffic that carries data that belongs to different flows,
	the GaNAT should keep the necessary per-flow state. From a		the GaNAT should keep the necessary per-flow state. From a
	signalling point of view, however, upstream data traffic that		signalling point of view, however, upstream data traffic that
	corresponds (on the application level) to the downstream flow		corresponds (on the application level) to the downstream flow
	to which this GIMPS session refers, is a separate flow for		to which this GIST session refers, is a separate flow for
	which, dependent on the application, there may or there may		which, dependent on the application, there may or there may
	not exist a signalling session. If such a signalling session		not exist a signalling session. If such a signalling session
	exists, then the GaNAT acts as an NR-side GaNAT for this		exists, then the GaNAT acts as an NR-side GaNAT for this
	session. Thus, during the processing of this signalling care		session. Thus, during the processing of this signalling,
	has to be taken not to establish a NAT binding for a flow for		care has to be taken not to establish a NAT binding for a
	which a NAT binding already exists. Finally, security issues		flow for which a NAT binding already exists. Finally,
	arise when traffic, for which no signalling exists, is		security issues may arise when traffic, for which no
	allowed to traverse a GaNAT.		signalling exists, is allowed to traverse a GaNAT.
	3. Otherwise, if P carries a [IP header].DestinationIPAddress that
	belongs to the GaNAT, and if it is identified as a GIMPS CONFIRM
	in D-mode with an NSLP ID that is not supported, the GaNAT does
	the following (P is denoted as GC).
	1. It creates a new GIMPS CONFIRM packet GC', as follows (note
	that the variables below refer to the variables that were
	used in the translation of the GIMPS QUERY that corresponds
	to GC.
	1. GC' <- GC
	2. GC'.[IP header].SourceIPAddress <- IPGaNATds.
	3. GC'.NLI.IA <- IPGaNATds
	4. GC'.S <- true
	5. It checks whether or not a NTO is included in the GC.
	- If none is included, it adds a new one to GC' such
	that GC'.NTO=[ IPGaNATds || SPNDTGaNATds]
	- If one is included, it replaces it as GC'.NTO=[
	IPGaNATds || SPNDTGaNATds]
	6. It forwards GC' on the downstream link.
	4. Otherwise, if P matches an existing NAT binding, normal NAT		3. Otherwise, if P matches an existing NAT binding, normal NAT
	processing is applied.		processing is applied.
	5. Otherwise, P is silently discarded.		4. Otherwise, P is silently discarded.
	6.1.2 NR-side NSLP-unaware GaNATs		6.2. NR-side NSLP-unaware GaNATs
	As is the case with NR-side NSLP-unaware GaNATs without security, an		As is the case with NR-side NSLP-unaware GaNATs that follow the
	NR-side NSLP-unaware GaNAT must know a "pending" IP address, as		"transparent" approach, an NR-side NSLP-unaware GaNAT that follows
	described in Section 5.1.2. This IP address is denoted as IPNext.		the "non-transparent" approach must know a "pending" IP address and,
			depending on the scenario, also a destination port number, as
			described in Section 5.2. This IP address and destination port
			number are denoted as IPNext and PortNext respectively. How they are
			made known to the GaNAT is outside the scope of this document. Note,
			however, that a typical scenario would be that the GaNAT has an
			existing NAT binding for the data flow in place from where this
			information can be derived.
	For every arriving IP packet P, an NSLP-unaware, NR-side GaNAT		For every arriving IP packet P, an NSLP-unaware, NR-side GaNAT
	executes the following algorithm.		executes the following algorithm.
	1. If P has a RAO followed by the GIMPS header with an unsupported		1. If P has a RAO followed by a GIST header with an unsupported
	NSLPID, it is identified as a GIMPS QUERY. In this case the		NSLPID, and is identified as a GIST QUERY, the GaNAT does the
	GaNAT does the following.		following.
	1. We denote P as GQ. The GaNAT looks at the stack proposal ST		1. We denote P as GQ. The GaNAT looks at the stack proposal ST
	in GQ. If it indicates that no cryptographic protection is		in GQ. If it indicates that no cryptographic protection is
	required, the algorithm that is executed is the one described		required, the GaNAT MAY choose to follow the "transparent"
	in Section 5.1.2 above.		approach as described in Section 5.2 above.
	2. The GaNAT remembers GQ along with the link on which it		2. If GQ.[IP header].[Destination Address] is not bound to the
	arrived. We call this link the "upstream" link.		link on which GQ arrived, the GaNAT silently discards the
			packet.
	3. The GaNAT determines whether or not this GIMPS QUERY is		3. The GaNAT determines whether or not this GIST QUERY is
	anticipated, i.e. if a pending IPNext exists. If no IPNext		anticipated, i.e. if a pending IPNext and PortNext exists.
	is pending, GQ is discarded (it is a question whether or not		One way of determining whether or not a pending IPNext and
	an error message should be sent). Otherwise, additional		PortNext exists is checking whether or not a NAT binding for
	checks may be performed (e.g. a DSInfo object may have to be		the data traffic, as this is defined by the MRI in the GIST
	checked against the GQ). If these checks fail, GQ is		QUERY, exists in the NAT binding cache. If one exists, then
	discarded. Otherwise, the GaNAT performs the following.		IPNext and PortNext is the address and port number to which
			the data traffic is sent after translation. If no pending
			IPNext is found, GQ is discarded (it is an open issue whether
			or not an error message should be sent). Otherwise,
			additional checks may be performed (e.g. a DSInfo object may
			have to be checked against the GQ). If these checks fail, GQ
			is discarded. Otherwise, the GaNAT performs the following.
	4. It searches its table of existing NAT bindings against		4. We call the link on which GQ arrived the "upstream" link.
			The GaNAT aquires an IP address for itself for the upstream
			link (this could be a static or a dynamic IP address). This
			address is denoted IPGaNATus. The GaNAT will use this
			address as a source IP address in order to send subsequent
			signalling messages to the upstream direction. If the GaNAT
			is an edge NAT, IPGaNATus will typically coincide with the
			destination IP address of the (original) MRI in the GIST
			QUERY.
			5. The GaNAT searches its table of existing NAT bindings against
	entries that match the GQ.MRI. A matching entry means that		entries that match the GQ.MRI. A matching entry means that
	the data flow, to which the signalling refers, already		the data flow, to which the signalling refers, already
	exists.		exists.
	+ If a matching entry is found, the GaNAT looks at which		+ If a matching entry is found, the GaNAT determines the
	link the packets of the data flow are forwarded; we call		link on which the packets of the data flow are forwarded;
	this link the "downstream" link. Further, the GaNAT		we call this link the "downstream" link. Further, the
	checks how the headers of the data flow (IP addresses,		GaNAT checks how the headers of the data flow (IP
	port numbers, etc) are translated according to this NAT		addresses, port numbers) are translated according to this
	binding. We denote [IP header].SourceIPAddress used on		NAT binding. Note that the [IP
	the downstream link as IPGaNATds, and the port numbers as		header].DestinationIPAddress of this NAT binding should be
	PNGaNATds. Note that the [IP header].DestinationIPAddress		equal to IPNext. If it is not, this should be handled as
	of this NAT binding should be equal to IPNext. If it is		an auditive error condition. (This check is done as a
	not, this should be handled as an auditive error		consistency check.)
	condition. (This check is done as a consistency check.)
	+ If no matching entry is found, the GaNAT determines, based		+ If no matching entry is found, the GaNAT determines, based
	on its routing table, the link on which packets that match		on its routing table, the link on which packets that match
	GQ.MRI (excluding GQ.MRI.SourceIPAddress and where		GQ.MRI (where GQ.MRI.DestinationIPAddress is replaced with
	GQ.MRI.DestinationIPAddress is replaced with IPNext) would		IPNext) would be forwarded. We call this link the
	be forwarded. We call this link the "downstream" link.		"downstream" link.
	Then, the GaNAT acquires an IP address for itself on the
	downstream link. (This address could be dynamic or
	static.) Depending on its type, the GaNAT may also
	acquire (UDP) port numbers for the translation of GQ. We
	denote the acquired IP address as IPGaNATds and the
	associated port numbers as PNGaNATds.
	5. It creates a new GIMPS QUERY packet GQ', as follows (note		6. It creates a new GIST QUERY packet GQ', as follows.
	that the new packet contains the same MRI as GQ).
	1. GQ' <- GQ		1. GQ' <- GQ
	2. GQ'.[IP header].SourceIPAddress <- IPGaNATds.		2. GQ'.MRI.DestinationAddress <- IPNext.
	3. GQ'.S <- true		3. GQ'.MRI.DestinationPort <- PortNext.
	4. It checks whether or not a NTO is included in the GQ.		4. GQ'.[IP header].DestinationIPAddress <- IPNext.
	- If none is included, it adds a new one to GQ' such		5. It checks whether or not an NTO was included in GQ.
	that GQ'.NTO=[ IPGaNATds || SPNDTGaNATds]
	- If one is included, it replaces it as GQ'.NTO=[		- If none was included, it creates a new NTO as follows
	IPGaNATds || SPNDTGaNATds]		and adds it to GQ'.
	5. It remembers GQ, GQ' the fact that they are associated,		o NTO.[NAT Count] <- 1.
	and the associated upstream and downstream links.
	6. It forwards GQ' on the downstream link.		o NTO.MRI <- GQ.MRI.
	The remaining steps of the algorithm are analogous to the algorithm		o NTO.[List of translated objects] <- [type of MRI],
	of NSLP-unaware, NI-side GaNATs, which was described in the previous		[type of NLI], [type of SCD]
	section.
	6.1.3 Additional GIMPS peer processing		o NTO.opaque information for NAT 1 <- IPGaNATus,
			[link identifier of upstream link].
	In the presence of GaNATs on the signalling path between two NSLP		- If one was included, it replaces certain fields and
	peers, and if cryptographic protection of the signalling traffic		appends new fields into the NTO, as follows, and adds
	between these two peers is required, the translation of the GIMPS		the resulting object to GQ'.
	header fields that need to be translated for consistency, must be
	carried out by the X peers. The GIMPS processing that performs this
	task, is described next. Note that this processing is in addition to
	the processing described in [1] and that we assume that the in-
	between GaNATs adopt the behaviour described in the two preceding
	sections.
	A GIMPS peer that receives a GIMPS packet that carries (a) an NSLPID		o NTO.[NAT Count] <- i, where i is the current [NAT
	for a supported NSLP, and (b) an NTO in its header, executes the		count] value increased by one.
	following algorithm, before the processing described in [1] takes
	place.
	1. If the packet is a GIMPS QUERY or CONFIRM in D-mode, denoted G,		o NTO.[List of translated objects] <- [type of MRI],
	the peer constructs a new packet, denoted G', as follows.		[type of NLI], [type of SCD]
	1. G' <- G		o NTO.[opaque information replaced by NAT i] <-
			IPGaNATus, [LinkID of upstream link].
	2. G'.MRI.Source_IP_Address <- G.NTO.IPGaNATds		6. It forwards GQ' on the downstream link. Note: The
			encoding of the information that the GaNAT encodes into
			the NTO.[opaque information replaced by NAT i] field is a
			local implementation issue.
	3. G'.MRI.SourcePort <- G.NTO.SPNDTGaNATds		2. Otherwise, if P is identified as a GIST RESPONSE packet in
			datagram mode with an NSLP ID that is not supported, the GaNAT
			does the following (P is denoted as GR).
	4. G'.NLI.IA <- G.NTO.IPGaNATds		1. If P does not contain an NTO, the GaNAT forwards it as usual
			without further processing. Otherwise, the GaNAT selects the
			information encoded by it in the [opaque information replaced
			by NAT] field of the embedded NTO, denoted by IPGaNATus and
			LinkID. If multiple [opaque information replaced by NAT]
			fields are present in the NTO, the GaNAT uses the last one in
			the list. The GaNAT then constructs a new GIST response GR',
			as follows (note that no changes are made to the MRI).
	5. G'.NTO is removed.		1. GR' <- GR
	and forwards G' to GIMPS for further processing. If G is a GIMPS		2. GR'.[IP header].SourceIPAddress <- IPGaNATus.
	QUERY and local policy demands the installation of state without
	the reception of a GIMPS CONFIRM message, then the peer must
	store the NTO carried by G together with the routing state
	information about the sending GIMPS peer. If G is a GIMPS
	CONFIRM and local policy demands the installation of state only
	after reception of a valid CONFIRM, then the peer stores, after
	validating the cookie in the CONFIRM, the NTO carried by G
	together with the routing state information about the sending
	GIMPS peer.
	2. Otherwise, if the packet is a GIMPS RESPONSE in D-mode, denoted		3. GR'.MRI.NLI.IA <- IPGaNATus.
	GR, the peer constructs a new packet, denoted GR', as follows.
	1. GR' <- G		4. Remove the last [opaque information replaced by NAT i]
			field from GR'.NTO.
	2. GR'.MRI.Source_IP_Address <- GR.NTO.IPGaNATus		5. GR'.S <- true.
	3. GR'.MRI.SourcePort <- GR.NTO.PNGaNATus		2. The GaNAT SHOULD now invalidate all but one stack
			configuration objects in the stack proposal in GR'. This is
			done so that the quering node can only chose that one
			proposal, and that therefore only one NAT binding must be
			installed for the signalling traffic to traverse the GaNAT.
			The GaNAT SHOULD keep valid the strongest, in terms of
			security, stack proposal. We denote this proposal as PR. If
			PR.[Destination Port] is already used by the GaNAT as a port
			in order to demultiplex an existing signalling flow, the
			GaNAT reserves a port SIGPORT (that it will use as a source
			port for UDP/TCP signalling traffic that it will send on the
			upstream link) and replaces PR.[Destination Port] with
			SIGPORT. Otherwise it sets SIGPORT=PR.[Destination Port].
			It then sets GR'.[UDP header].SourcePort <- SIGPORT.
	4. GR'.NLI.IA <- GR.NTO.IPGaNATus		3. It forwards GR' on the upstream link, i.e. the link
			identified by LinkID.
	5. GR'.NTO is removed.		4. The GaNAT now installs a NAT binding for the signalling
			traffic which says that "a packet K that arrives on the
			upstream link and for which it holds that
	and forwards GR' to GIMPS for further processing. If the cookie		+ K.[IP header].DestinationIPAddress=IPGaNATus,
	in GR' is verified sucessfully, the peer stores the NTO carried
	by GR together with the routing state information about the
	sending GIMPS peer.
	A peer that receives a GIMPS packet P (in this case, the packet will		+ K.[IP header].Protocol=PR.Protocol, and
	be a cryptographically protected GIMPS packet) the peer does the
	following substitutions after the cryptographic processing is
	(successfully) completed and before the processing described in [1]
	takes place.
	1. P.MRI.SourceIPAddress <- P.NTO.IPGaNATds		+ K.[TCP/UDP header].DestinationPort=SIGPORT
			should be forwarded on the downstream link (i.e. on the link
			on which GR arrived), with [IP header].DestinationIPAddress =
			GR.MRI.NLI.IA and [UDP/TCP
			header].DestinationPort=PR.[Destination Port].
	2. P.MRI.SourcePort <- P.NTO.SPNDTGaNATds		5. If no NAT binding for the data traffic was found in step
			1.3.2, the GaNAT may now install a NAT binding (for the
			unidirectional data traffic) which says that "a packet L that
			arrives on the upstream link and for which it holds that
	3. P.NLI.IA <- P.NTO.IPGaNATds		+ L.[IP header].DestinationIPAddress=GR'.NTO.MRI.Destination
			IPAddress,
	4. P.NTO is removed.		+ L.[IP header].Protocol=GR'.NTO.MRI.Protocol, and
	A peer that intends to send a GIMPS packet (in this case,		+ L.[TCP/UDP
	cryptographic protection will be required for the packet), the peer		header].DestinationPortNumbers=GR'.NTO.MRI.DestinationPort
	does the following after the processing described in [1] and before
	the packet is passed to the process that applies the cryptographic
	protection. Note that the NTO refers to the NTO that is stored
	together with the routing state information of the peer that is to
	receive the packet.
	1. P.MRI.Source_IP_Address <- NTO.IPGaNATds		should be forwarded on the downstream link, with [IP
			header].DestinationIPAddress = IPNext and [UDP/TCP
			header].DestinationPort=PortNext.
	2. P.MRI.SourcePort <- NTO.PNGaNATds		Issues: there is a question of whether this NAT binding
			should also enable data traffic in the opposite direction to
			traverse the NAT; in order to be able to multiplex upstream
			traffic that carries data that belongs to different flows,
			the GaNAT should keep the necessary per-flow state. From a
			signalling point of view, however, upstream data traffic that
			corresponds (on the application level) to the downstream flow
			to which this GIST session refers, is a separate flow for
			which, dependent on the application, there may or there may
			not exist a signalling session. If such a signalling session
			exists, then the GaNAT acts as an NI-side GaNAT for this
			session. Thus, during the processing of this signalling care
			has to be taken not to establish a NAT binding for a flow for
			which a NAT binding already exists. Finally, security issues
			may arise when traffic, for which no signalling exists, is
			allowed to traverse a GaNAT.
	3. P.NLI.IA <- NTO.IPGaNATds		3. Otherwise, if P matches an existing NAT binding, normal NAT
			processing is applied.
	6.2 NSLP-aware GaNATs		4. Otherwise, P is silently discarded.
	The cryptographic protection applies to of signalling messages		6.3. GIST peer processing
	terminates at NSLP-aware GaNATs. The processing performed by such
	GaNATs is therefore identical to the processing described in
	Section 5.2, with the exception that the GaNATs additionally perform
	cryptographic operations. In this case, there is no requirement for
	the NSLP to perform any translation for the purposes of NAT
	traversal.
	7. NSIS-unaware NATs		In the presence of GaNATs on the signalling path between two NSLP
			peers, and if the GaNATs follow the "non-transparent" approach (which
			they have to follow in the context of cryptographically protected
			signalling), the consistent translation of the GIST header fields
			must be carried out by the NSLP peers. The GIST processing that
			performs this task, is described in section 7.2 of [1].
	The following may serve as indications for the existence of an NSIS-		7. GIST-unaware NATs
	unaware NAT between two GIMPS peers. These indications can only be
	detected by the receiver of a GIMPS message. The first occasion		The following may serve as indications for the existence of an GIST-
	these indications may be detected is with the reception of a GIMPS		unaware NAT between two GIST peers. These indications can only be
	QUERY, typically by the downstream peer. (Note that != denotes		detected by the receiver of a GIST message. The first occasion these
	inequality).		indications may be detected is with the reception of a GIST QUERY,
			typically by the downstream peer. (Note that != denotes inequality).
	o The MRI.SourceIPAddress does not belong to the addressing space of		o The MRI.SourceIPAddress does not belong to the addressing space of
	the receiving peer.		the receiving peer.
	o The MRI.DestinationIPAddress does not belong to the addressing		o The MRI.DestinationIPAddress does not belong to the addressing
	space of the receiving peer.		space of the receiving peer.
	o The IP address in the NLI.IA object does not belong to the		o The IP address in the NLI.IA field does not belong to the
	addressing space of the receiving peer.		addressing space of the receiving peer.
	o The D flag of a received GIMPS packet denotes downstream direction		o The D flag of a received GIST packet denotes downstream direction
	and the S flag is not set and [IP header].SourceIPAddress !=		and the S flag is not set and [IP header].SourceIPAddress !=
	MRI.SourceIPAddress.		MRI.SourceIPAddress.
	o The D flag of a received GIMPS packet denotes upstream direction		o The D flag of a received GIST packet denotes upstream direction
	and the S flag is not set and [IP header].SourceIPAddress !=		and the S flag is not set and [IP header].SourceIPAddress !=
	MRI.DestinationIPAddress.		MRI.DestinationIPAddress.
	o This is a GIMPS QUERY and [IP header].DestinationIPAddress !=		o This is a GIST QUERY and [IP header].DestinationIPAddress !=
	MRI.DestinationIPAddress.		MRI.DestinationIPAddress.
	Note that these are only indications. In the presence of an		Note that these are only indications. In the presence of an
	adversary, a GIMPS peer may be tricked into believing that an NSIS-		adversary, a GIST peer may be tricked into believing that an GIST-
	unaware NAT exists between itself and one of its neighbouring peers,		unaware NAT exists between itself and one of its neighbouring peers,
	while in reality this may not be the case.		while in reality this may not be the case.
	When a downstream GIMPS peer detects such an indication, it may		When a downstream GIST peer detects such an indication, it may notify
	notify the upstream peer about the error. It may include additional		the upstream peer about the error. It may include additional
	information that enables the upstream peer to construct a GIMPS		information that enables the upstream peer to construct a GIST packet
	packet in such a way that, after it traverses the NSIS-unaware NAT,		in such a way that, after it traverses the GIST-unaware NAT, the IP
	the IP addresses in the MRI field and the NLI.IA object are		addresses in the MRI field and the NLI.IA field are consistent with
	consistent with those in the IP header (which match the addressing		those in the IP header (which match the addressing space of the
	space of the receiving peer). However, this requires the		receiving peer). However, this requires the specification of new
	specification of new data structures and formats, processing rules,		data structures and formats, processing rules, and requires the peers
	and requires the peers to maintain additional state.		to maintain additional state.
	Unfortunately, this approach is likely to fail in many circumstances.		Unfortunately, this approach is likely to fail in many circumstances.
	In order to see this, consider the behaviour of an NSIS-unaware NAT		In order to see this, consider the behaviour of an GIST-unaware NAT
	when it receives an IP packet. The packet either		when it receives an IP packet. The packet either
	1. matches an existing NAT binding in which case its IP header is		1. matches an existing NAT binding in which case its IP header is
	translated and the packet it is forwarded on another link, or		translated and the packet it is forwarded on another link, or
	2. matches an existing policy rule which causes a new binding to be		2. matches an existing policy rule which causes a new binding to be
	established and then (1) happens, or		established and then (1) happens, or
	3. is discarded because neither (1) nor (2) applies.		3. is discarded because neither (1) nor (2) applies.
	With NSIS-unaware NATs it is a matter of local policy (i.e. the rules		With GIST-unaware NATs it is a matter of local policy (i.e. the rules
	that exist in case (2) above) whether or not traffic will be allowed		that exist in case (2) above) whether or not traffic will be allowed
	to traverse the NAT. This obviously applies to both signalling and		to traverse the NAT. This obviously applies to both signalling and
	data traffic, as an NSIS-unaware NAT is unable to distinguish the two		data traffic, as an GIST-unaware NAT is unable to distinguish the two
	types of traffic. It may be the case that GIMPS node A is unable to		types of traffic. It may be the case that GIST node A is unable to
	contact GIMPS node B which is "behind" a NAT, even if communication		contact GIST node B which is "behind" a NAT, even if communication in
	in from B to A may be possible because such communication would match		from B to A may be possible because such communication would match a
	a policy rule; typically, in a scenarios where A is towards the NI		policy rule; typically, in a scenarios where A is towards the NI and
	and B is towards the NR, the NAT would have this behaviour.		B is towards the NR, the NAT would have this behaviour.
	Another approach to deal with NSIS-unaware NATs is similar to the NAT		Another approach to deal with GIST-unaware NATs is similar to the NAT
	traversal approach taken by IKEv2, i.e. by encapsulating GIMPS		traversal approach taken by IKEv2, i.e. by encapsulating GIST
	messages into UDP datagrams, rather than directly into IP datagrams.		messages into UDP datagrams, rather than directly into IP datagrams.
	This technique requires the inclusion of additional fields into a		This technique requires the inclusion of additional fields into a
	GIMPS QUERY, as follows. The sender adds (a hash of) its own IP		GIST QUERY, as follows. The sender adds (a hash of) its own IP
	address and the IP address of what it believes to be the DR into the		address and the IP address of what it believes to be the DR into the
	GIMPS payload. The receiver of this GIMPS messages compares these		GIST payload. The receiver of this GIST messages compares these
	addresses to the [IP header].SourceIPAddress and the [IP		addresses to the [IP header].SourceIPAddress and the [IP
	header].DestinationIPAddress respectively. If at least one of them		header].DestinationIPAddress respectively. If at least one of them
	is unequal, the receiver deduces that a NAT is between sender and		is unequal, the receiver deduces that a NAT is between sender and
	receiver. After the detection of a NAT, the remainder of the		receiver. After the detection of a NAT, the remainder of the
	communication is encapsulated into UDP datagrams that are addressed		communication is encapsulated into UDP datagrams that are addressed
	to a specified port.		to a specified port.
	Unfortunately, the IKEv2 NAT traversal mechanism cannot be used "as		Unfortunately, the IKEv2 NAT traversal mechanism cannot be used "as
	is" for NAT traversal in GIMPS. This is because of a number of		is" for NAT traversal in GIST. This is because of a number of
	reasons, including the following.		reasons, including the following.
	o The NAT may use an IP address for the forwarding of data traffic		o The NAT may use an IP address for the forwarding of data traffic
	that is different from the IP address it uses to forward GIMPS		that is different from the IP address it uses to forward GIST
	traffic. Since the NAT is NSIS-unaware it cannot update the MRI		traffic. Since the NAT is GIST-unaware it cannot update the MRI
	in the GIMPS messages such that it matches the translation applies		in the GIST messages such that it matches the translation applies
	to the data traffic. Moreover, neither the GIMPS sending, nor the		to the data traffic. Moreover, neither the GIST sending, nor the
	GIMPS receiving peer can perform this update; the sending peer		GIST receiving peer can perform this update; the sending peer
	cannot predict the translation that the NAT will apply, and the		cannot predict the translation that the NAT will apply, and the
	receiving peer does not have enough information to associate data		receiving peer does not have enough information to associate data
	flows to signalling messages.		flows to signalling messages.
	o It is unclear whether or not the IKEv2 NAT traversal mechanism		o It is unclear whether or not the IKEv2 NAT traversal mechanism
	supports cascades of NATs.		supports cascades of NATs.
	o It seems to be inappropriate to use UDP encapsulation for certain		o It seems to be inappropriate to use UDP encapsulation for certain
	C-mode scenarios. For example, using UDP encapsulation for TCP		C-mode scenarios. For example, using UDP encapsulation for TCP
	C-mode would result in GIMPS to appear in TCP over UDP over IP.		C-mode would result in GIST to appear in TCP over UDP over IP.
	8. Security Considerations		8. Security Considerations
	The mechanisms proposed in this document give rise to a number of		The mechanisms proposed in this document give rise to a number of
	threats that must be considered. In the following, a subset of these		threats that must be considered. In the following, a subset of these
	threats is mentioned.		threats is mentioned.
	8.1 Service Denial Attacks		8.1. Service Denial Attacks
	As described in Section 5.1 and Section 6.1, NSLP-unaware GaNATs		As described above, NSLP-unaware GaNATs create some state whenever
	create some state whenever they receive a GIMPS QUERY message. This		they receive a GIST QUERY message. This state is necessary in order
	state is necessary in order for the GaNAT to be able to map a GIMPS		for the GaNAT to be able to map a GIST RESPONSE that arrives from the
	RESPONSE that arrives from the downstream direction to the		downstream direction to the corresponding GIST QUERY and thereby to
	corresponding GIMPS QUERY and thereby to perform the required		perform the required translation.
	translation.
	The threat here is an attacker flooding the GaNAT with maliciously		The threat here is an attacker flooding the GaNAT with maliciously
	constructed GIMPS QUERIES with the aim of exhausting the GaNAT's		constructed GIST QUERIES with the aim of exhausting the GaNAT's
	memory. The attacker might use a variety of methods to construct		memory. The attacker might use a variety of methods to construct
	such GIMPS QUERIES, including the following.		such GIST QUERIES, including the following.
	1. Use as [IP header].SourceIPAddress the address of some other node		1. Use as [IP header].SourceIPAddress the address of some other node
	or an unallocated IP address. This method is also known as IP		or an unallocated IP address. This method is also known as IP
	spoofing.		spoofing.
	2. Use an invalid NSLPID, in order to make sure that all on-path		2. Use an invalid NSLPID, in order to make sure that all on-path
	GaNAT(s) will behave like NSLP-unaware GaNATs.		GaNAT(s) will behave like NSLP-unaware GaNATs.
	3. For each packet, use a different value for the cookie field.		3. For each packet, use a different value for the cookie field.
	4. For each packet, use a different value for the session ID field.		4. For each packet, use a different value for the session ID field.
	5. Combinations of the above.		5. Combinations of the above.
	How vulnerable a GaNAT is to the above service denial attack depends		How vulnerable a GaNAT is to the above service denial attack depends
	on a variaty of factors, including the following.		on a variaty of factors, including the following.
	o The amount of state allocated at the receipt of a GIMPS QUERY.		o The amount of state allocated at the receipt of a GIST QUERY.
	This amount may vary depending on whether or not the data flow to		This amount may vary depending on whether or not the data flow to
	which the signalling refers, already exists (i.e. whether or not		which the signalling refers, already exists (i.e. whether or not
	the GaNAT already maintains a NAT binding for it).		the GaNAT already maintains a NAT binding for it).
	o The mechanism that the GaNAT uses to map RESPONSEs to QUERIEs.		o The mechanism that the GaNAT uses to map RESPONSEs to QUERIEs.
	o Whether or not the GaNAT acriques dynamic IP addresses and ports		o Whether or not the GaNAT acriques dynamic IP addresses and ports
	for the downstream link.		for the downstream link.
	In order to decrease the exposure of a GaNAT to service denial		In order to decrease the exposure of a GaNAT to service denial
	attacks, the following recommendations are made.		attacks, the following recommendations are made.
	o The GaNAT should perform ingress filtering. This limits the		o The GaNAT should perform ingress filtering. This limits the
	amount of locations from which an attacker can perform IP spoofing		amount of locations from which an attacker can perform IP spoofing
	without being detected.		without being detected.
	o The GaNAT should allocate the minimum amount of state required at		o The GaNAT should allocate the minimum amount of state required at
	the reception of a GIMPS QUERY.		the reception of a GIST QUERY.
	o All state allocated by the GaNAT should timeout according to a		o All state allocated by the GaNAT should timeout according to a
	local policy. If the GaNAT detects heavy loads (which may		local policy. If the GaNAT detects heavy loads (which may
	indicate a service denial attack in progress), the GaNAT should		indicate a service denial attack in progress), the GaNAT should
	timeout the state allocated as a result of a received GIMPS QUERY		timeout the state allocated as a result of a received GIST QUERY
	quicker, proportionally to the experienced load.		quicker, proportionally to the experienced load.
	o The installation of a NAT binding for the data traffic (if such a		o The installation of a NAT binding for the data traffic (if such a
	binding does not exist prior to signalling) should be postponed		binding does not exist prior to signalling) should be postponed
	until the correct GIMPS REPONSE traverses the NAT.		until the correct GIST REPONSE traverses the NAT.
	The service denial threats mentioned in this section do not apply to		The service denial threats mentioned in this section do not apply to
	an NSLP-aware GaNAT, as such a GaNAT is required, in accordance with		an NSLP-aware GaNAT, as such a GaNAT is required, in accordance with
	its local policy, to verify the validity of the cookie(s) before		its local policy, to verify the validity of the cookie(s) before
	allocating any state, including the state required by the mechanisms		allocating any state, including the state required by the mechanisms
	in this document.		in this document.
	8.2 Network Intrusions		8.2. Network Intrusions
	Although the primary goal of a NAT is to perform address translation		Although the primary goal of a NAT is to perform address translation
	between two addressing spaces, NATs are sometimes also used to		between two addressing spaces, NATs are sometimes also used to
	provide a security service similar to the security service provided		provide a security service similar to the security service provided
	by firewalls. That is, a NAT can be configured so that it does not		by firewalls. That is, a NAT can be configured so that it does not
	forward packets from the external into the internal network, unless		forward packets from the external into the internal network, unless
	it determines that the packets belong to a communication session that		it determines that the packets belong to a communication session that
	was originally initiated from an internal node and are, as such,		was originally initiated from an internal node and are, as such,
	solicited.		solicited.
	If an NSLP-unaware GaNAT performs the above security-relevant		If an NSLP-unaware GaNAT performs the above security-relevant
	function in addition to address translation, then the presence of		function in addition to address translation, then the presence of
	GIMPS signalling and, in particular the mechanisms described in this		GIST signalling and, in particular the mechanisms described in this
	document, might allow an adversary cause the installation of NAT		document, might allow an adversary cause the installation of NAT
	bindings in the GaNAT using these mechansisms. These NAT bindings		bindings in the GaNAT using these mechansisms. These NAT bindings
	would then enable the adversary to inject unsolicited traffic into		would then enable the adversary to inject unsolicited traffic into
	the internal network, a capability that it may not have in the		the internal network, a capability that it may not have in the
	absence of the mechanisms described in this document.		absence of the mechanisms described in this document.
	The administrator of an NSLP-unaware GaNAT should therefore make		The administrator of an NSLP-unaware GaNAT should therefore make
	security-concious decisions regarding the operation of the GaNAT. An		security-concious decisions regarding the operation of the GaNAT. An
	NSLP-aware GaNAT, on the other hand, follows an NSLP policy which		NSLP-aware GaNAT, on the other hand, follows an NSLP policy which
	indicates the required security mechanisms. This policy should		indicates the required security mechanisms. This policy should
	account for the fact that this NSLP-aware node performs also NAT and		account for the fact that this NSLP-aware node performs also NAT and
	the associated packet filtering.		the associated packet filtering.
	9. Acknowledgments		9. IAB Considerations
	The authors would like to thank Robert Hancock, Cedric Aoun and
	Martin Stiemerling for their feedback. Furthermore, we would like to
	mention that this document builds on top of a previous document
	regarding migration scenarios.
	10. IAB Considerations
	[Editor's Note: A future version of this document will provide		None.
	information regarding IAB considerations.
	11. IANA Considerations		10. Acknowledgements
	This document does not require actions by the IANA.		The authors would like to thank Cedric Aoun, Christian Dickmann,
			Robert Hancock, and Martin Stiemerling for their insightful comments.
			Furthermore, we would like to mention that this document builds on
			top of a previous document regarding migration scenarios.
	12. Normative References		11. Normative References
	[1] Schulzrinne, H. and R. Handcock, "GIMPS: General Internet		[1] Schulzrinne, H. and R. Hancock, "GIST: General Internet
	Messaging Protocol for Signalling", draft-ietf-nsis-ntlp-06		Signalling Transport", draft-ietf-nsis-ntlp-06 (work in
	(work in progress), May 2005.		progress), May 2005.
	[2] Stiemerling, M., Tschofenig, H., and C. Aoun, "NAT/Firewall NSIS		[2] Stiemerling, M., Tschofenig, H., and C. Aoun, "NAT/Firewall NSIS
	Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06		Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06
	(work in progress), May 2005.		(work in progress), May 2005.
	Authors' Addresses		Authors' Addresses
	Andreas Pashalidis		Andreas Pashalidis
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
End of changes. 226 change blocks.
	721 lines changed or deleted		902 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/