wdiff draft-pashalidis-nsis-gimps-nattraversal-00.txt draft-pashalidis-nsis-gimps-nattraversal-01.txt

NSIS A. Pashalidis
Internet-Draft H. Tschofenig
Expires: January 12, April 27, 2006 Siemens
July 11,
October 24, 2005

NAT Traversal for GIMPS
draft-pashalidis-nsis-gimps-nattraversal-00.txt GIST
draft-pashalidis-nsis-gimps-nattraversal-01.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 12, April 27, 2006.

Abstract

This document contains a number describes how different types of mechanisms that may be used in
order to enable Network Address
Translator (NAT) interact with the General Internet Messaging Protocol Signalling
Transport (GIST) protocol. The purpose of this interaction is for Signaling
(GIMPS) messages
signalling traffic to traverse different types of Network Address
Translators the NATs in a way that may be located along preserves its
semantics with respect to the path between two adjecent
NSLP hosts. data flows it corresponds to.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 6
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 7 11
5. Traversal of GaNATs in the absence TLS or IPsec . . . . . . . 9
5.1 NSLP-unaware GaNATs . . . . . Transparent NAT traversal for GIST . . . . . . . . . . . . . . 9
5.1.1 13
5.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . 9
5.1.2 . . 13
5.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . 14
5.2 . . 18
5.3. NSLP-aware GaNATs . . . . . . . . . . . . . . . . . . . . 17
5.3 21
5.4. Combination of NSLP-aware and NSLP-unaware GaNATs . . . . 20 25
6. GaNATs in the presence of TLS or IPSec . . . . . . . . . . . . 22
6.1 NSLP-unaware GaNATs . . . Non-transparent NAT traversal . . . . . . . . . . . . . . . . 22
6.1.1 26
6.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . 22
6.1.2 . . 26
6.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . 26
6.1.3 Additional GIMPS peer processing . . . . . . . . . . . 28
6.2 NSLP-aware GaNATs . 30
6.3. GIST peer processing . . . . . . . . . . . . . . . . . . . 30 34
7. NSIS-unaware GIST-unaware NATs . . . . . . . . . . . . . . . . . . . . . . 31 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8.1 39
8.1. Service Denial Attacks . . . . . . . . . . . . . . . . . . 34
8.2 39
8.2. Network Intrusions . . . . . . . . . . . . . . . . . . . . 35 40
9. Acknowledgments . IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 37 42
10. IAB Considerations Acknowledgements . . . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39
12. 43
11. Normative References . . . . . . . . . . . . . . . . . . . . 39 . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 . . 44
Intellectual Property and Copyright Statements . . . . . . . . 40 . . 45

1. Introduction

Network Address Translators (NATs) modify certain fields in the IP
header of the IP packets that traverse them. In the context of
signalling as defined specified by the NSIS group, General Internet Signalling Transport
(GIST) protocol [1], this behaviour, if not
properly addressed, behaviour may lead to the installation of inconsistent and
meaningless
state at network nodes that may be inconsistent and meaningless with
respect to the actual traffic that traverses these nodes.

This document proposes a collection of algorithms that have to be
implemented in order to enable GIMPS signalling, and the data flows
to which this describes how GIST signalling refers, to messages traverse NATs in
a way that preserves the consistency of state that is installed in
the network,
and network with respect to the data flows to which the signalling
messages refer. As the mechanisms that are described in a manner this
document exclusively operate at the GIST layer, they are transparent
to signalling applications. The document is organised as follows.
The next section introduces the terminology that is used throughout
this document. Section 3 provides a detailed discussion of the problems NAT
traversal problem and highlights certain design decisions that are addressed by this document. have
to be taken when addressing the problem. Section 4 list lists the
assumptions on which the proposed mechanisms are based. Section 5
presents the proposed mechanisms for the case where
no TLS or IPsec protection is required for the signalling traffic
between two NSLP peers, "transparent" NAT traversal, and Section 6
??? presents the proposed mechanisms where such protection is
required.

2. Terminology

The terminology, abbreviations and notational conventions that are
used throughout the document are as follows.

o DR: Data Responder, as defined in [1]

o DS: Data Sender, as defined in [1]

o GaNAT: GIMPS-aware GIST-aware NAT - A a GaNAT may MAY implement a number of NSLPs, but does not implement the NATFW NSLP. NSLPs.

o GIMPS: GIST: General Internet Messaging Protocol for Signalling [1]

o NAT: Network Address Translator

o NI: NSIS Initiator, as defined in [1]

o NR: NSIS Responder, as defined in [1]

o NSIS: Next Steps in Signalling, 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 defined in [1] a whole.

o NSIS-aware: GIST-aware: Implements GIMPS GIST and zero or more MAY also implement a number of
NSLPs.

o NSIS-unaware: GIMPS-unaware, GIST-unaware: GIST-unaware, does not implement any NSLP.

o NSLP: NSIS Signalling Layer Protocol, as defined in [1]

o downstream: as defined in [1]

o upstream: as defined in [1]

o MRI: Message Routing Information, as defined in [1]

o NLI.IA: Interface Address field of the Network Layer Information
header field, as defined in [1]

o <- : Assignment operator. The quantity to the right of the
operator is assigned to the variable to its left.

o A.B: Element B of structure A. Example: [IP
header].SourceIPAddress denotes the source IP address of an IP
header.

o [data item]: This notation indicates that "data item" is a single
identifier of a data structure. (Square brackets do not denote
optional arguments in this document.)

3. Problem Statement

According to [1], all GIMPS GIST messages between two peers carry IP
addresses in order to define the data flow to which the signalling
refers. Moreover, certain GIMPS GIST messages also carry the IP address of
the sending peer, in order to enable the receiving peer to address
subsequent traffic to the sender. Packets that cross an addressing
boundary, say from addressing space S1 to S2, have the IP addresses
in the IP header translated from space S1 to S2 by the NAT; if GIMPS GIST
payloads are not translated in a consistent manner, the MRI in a GIMPS GIST
packet that crosses the boundary, e.g. from address space S1 to S2,
refers to a flow that does not exist in S2. In fact, the flow is may be
invalid in S2 because at least one of the involved IP addresses address that belongs to S1. S1 may not be
routable or invalid in S2. Moreover, the IP address of the sending
peer may also be not routable or invalid in the addressing space of
the receiving peer. The purpose of this document is to describe a
way for GIMPS GIST messages to be translated in a way that is consistent
with the translation that NATs apply to the IP headers of both
signalling and data traffic.

A NAT may either be NSIS-unaware GIST-unaware or NSIS-aware. The case of NSIS-
unaware NATs is discussed GIST-aware. We denote a GIST-
aware NAT as a GaNAT in Section 7. If the NAT is NSIS-aware, it
is typically sequel. A GaNAT MAY also able to support at
least one NSLP. Note that there exists an NSLP, namely the NATFW
NSLP [2], that specifically addresses NAT traversal for data flows.
Inevitably, the NATFW NSLP also provides the necessary mechanisms for
the related signalling to traverse the NATs involved. Therefore, we can further divide NSIS-
aware NATs into two categories, namely GIMPS-and-NATFW-aware NATs and
GIMPS-aware-and-NATFW-unaware NATs. In Consider a
GaNAT that supports both the sequel, we call NATFW NSLP, and the
latter simply GIMPS-aware NATs (GaNATs). A GIMPS-and-NATFW-aware NAT
performs NAT traversal according
extension to GIST that is specified in this document. Suppose now
that a GIST QUERY message arrives at this GaNAT that contains the
NSLP identifier (NSLPID) of the NATFW NSLP; NSLP. A question that arises
is whether the case of GaNAT should use the GIST NAT traversal extension
defined in this document, or the presence of such NATs is therefore beyond NATFW NSLP mechanism, in order to
provide "NAT traversal" for both the scope
of signalling message and the data
flow to which it refers. The answer to this document.

As question is natural, that such a
GaNAT MUST implement a NATFW-aware policy according to which method is used in
preference to the other. Note, however, that, should the GaNAT
prefer the GIST NAT only translates traversal to NATFW NSLP, then it will happen, if
no on-path GaNATs exist that prefer the relevant fields
for NATFW NSLP, that the
downsteam NATFW signalling traffic in peer will be unable to discover any downstream NATFW
NSLP peers. This may make the entire NATFW session obsolete.

Clearly, if a GaNAT does not implement the NATFW NSLP, then the only
way consistent with for the
relevant data flow. Consequently, GIMPS signalling in the presence
of NATFW-unaware NATs and the data flow to traverse that GaNAT, is
for NSLPs other than the NATFW NSLP remains
an open problem. This document precisely addresses this problem, by
proposing necessary mechanisms that to operate at on the GIMPS GIST layer. The same
holds when the NSLP that is being signalled is an NSLP other than the
NATFW NSLP. Enabling NAT traversal in presicely these circumstances
is the motivation of this specification.

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
may be GIMPS-and-NATFW-aware, GIST-and-NATFW-aware, some may be GIMPS-aware, GIST-aware, and some may be NSIS-unaware.
GIST-unaware. Additionally, NSLP signalling for such a data flow may
be required to traverse through a subset of those NATs. Whether or
not the routing inftrastructure and state of the network causes the
signalling for such a data flow to traverse the same NATs as the flow
depends, among other things, on the signalling application. which NSLP is being signalled. While
signalling of a the QoS NSLP, for example, might not traverse any of
the NATs that are traversed by the data flow, the signalling of the
NATFW NSLP traverses at least those NATs that implement the NATFW
NSLP (otherwise the signalling path would no longer be coupled to the
data path, as this coupling is defined by the GIMPS GIST QUERY/RESPONSE
discovery mechanism). mechanism for the "path coupled" Message Routing Method).
It is desirable that the NAT traversal extension for GIST provides
NAT traversal for every possible combination of NATs, either on the
data or the signalling path, to be functional
and secure. in a secure manner.

Due to the GIMPS GIST QUERY/RESPONSE discovery mechanism (according to
which QUERY messages are simply forwarded if the current node does
not support the required NSLP), two GIMPS GIST nodes typically identify
themselves as NSLP peers only if they both implement the same NSLP, say NSLP X. NSLP.
This means that, if one or more X-unaware NATs that are unaware of this NSLP
are between them, then the two X NSLP peers are not able to discover
each other at all. This is because, even in the unlikely event that
the NAT bindings that are necessary for the GIMPS GIST traffic to traverse
the in-between NAT(s) exist, the NLI.IA
Object field included in the
RESPONSE message sent by the downstream
X-aware GIST peer will be is invalid (i.e. (or the
IP address will be is unreachable) in the address space of the upstream X GIST
peer. In order to overcome this limitation, either the two X peers
need to cope with the in-between NAT(s), or, if the NAT(s) are
GaNATs, they (the GaNATs) need to apply additional processing in
order to transparently create and maintain consistency between the required consistency.
information in the header of GIST signalling messages and the
information in the IP header of the data traffic. Additionally, if
X-aware
NSLP-aware NATs are on the data path (where X is any NSLP except NATFW), path, then these NATs should process X
NSLP traffic in a way the that preserves consistency after address
translation. This processing deviates from the processing of X-aware NSLP-
aware non-NAT nodes. In the following sections we propose certain processing rules specify mechanisms
that aim to overcome the limitation of two adjacent X GIST peers not
being able to execute X an NSLP in the presence of in-between NAT(s). We do not consider

Note that a number of different situations has to be dealt with,
depending on the case where
X=NATFW and level of NSIS support by a NAT. The following
combinations of NATs that are located between two adjacent GIST peers
are considered.

o all NAT(s) are GIST-unaware

o all NAT(s) are (NSLP-unaware) GaNAT(s)

o all NAT(s) are NSLP-aware

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 NATFW-aware. 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
handled by further discussed in
Section 7.

Traversal of GaNAT(s) is comperatively more straightforward. This is
because, based on the NATFW NSLP.

Note 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 we have is
(or, if no NAT binding for the flow exists yet, will be) applied to deal with
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 number variety of different situations,
depending on whether X 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 supported echoed by the GaNATs. Thus, we have GIST responder on the
following three subcases.

o all GaNAT(s) 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 X-unaware

o all GaNAT(s) 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 X-aware (and X 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 NATFW NSLP)

o GaNAT is going
to be used only in deployments where cryptographic protection of
signalling traffic is not a combination 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 X-aware 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 X-unaware GaNATs 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 between 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 X
peers. 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 following sections, we discuss probability that
cryptographic protection is going to used, the GaNAT MUST follow the three cases separately.
non-transparent approach in this case.

4. Assumptions

The discussion in this document is based on the following
assumptions. Note that X denotes a fixed NSLP, other than the NATFW
NSLP.

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 GIST peers
that have GaNATs in between is such that the responses to packets
that a GaNAT sends on given interface arrive on the same
interface (if such responses are sent at all).

3. The path taken by signalling traffic remains fixed between the
two X GIST peers, as far as the in-between GaNATs are concerned.
That is, we assume that signalling traffic traverses the same
GaNAT(s) until at least one of the following conditions is met.

* The NSIS state that is installed at the two X GIST peers
expires.

* The NSIS state that is installed at the two X GIST peers is
refreshed using a GIMPS GIST QUERY.

* A new GIMPS GIST QUERY/RESPONSE exchange takes place due to other
reasons, e.g. a detected route change.

Note that this assumption is not necessarily met by "normal" data
path coupled signalling. This is because, under "normal" data
path coupled signalling, the signalling traffic is "coupled" to
the data traffic at nodes that implement X. decide to act as GIST peers.
Thus, under "normal" path coupled signalling, it is not an error
condition (e.g. a reason to trigeer a "route change"), for
example, if the set of on-path (non-X) GIMPS
nodes nodes, which do not act as GIST
peers, changes, as long as adjacent X GIST peers remain the same.

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
next GIMPS GIST QUERY/RESPONSE procedure is executed.

+-----+
+----+GaNAT|-----+
| | A | |
| +-----+ |
+------+ +------+ +--+---+ +------+
+--+ |X NSLP| | GIST | | IP | | IP | |X NSLP| | GIST | +--+
|DS+-+peer +--+router| 1+--+router| |router+--+peer 2+-+DR|
+--+ +------+ +---+--+ +--+---+ +------+ +--+
| +-----+ |
| |GaNAT| |
+----+ B +-----+
+-----+

Figure 1: Network with more than one NAT at an addressing boundary

Figure 1 illustrates the importance of assumptions (3) and (4). With
regard to that figure, suppose that a (D-mode) signalling session has
been setup between the two adjacent X NSLP GIST peers 1 and 2 and that both
signalling and data traffic follows the path X NSLP GIST peer 1 -> IP router
-> GaNAT A -> IP router -> X NSLP GIST peer 2. Suppose now that, after some
time, X GIST peer 1 decides to set up a C-mode connection with peer 2.
Suppose moreover that the left IP router decides to forward the
C-mode signalling traffic on the link towards GaNAT B. Thus,
signalling traffic now follows the alternative path X NSLP GIST peer 1 -> IP
router -> GaNAT B -> IP router -> X NSLP GIST peer 2. Note that this change
in forwarding between the two adjacent X NSLP GIST peers does not trigger a
"route change" at the GIMPS GIST layer because (a) it does not necessarily
destroy the adjacency of peer 1 and 2 and (b) it does not necassarily
destroy the coupling of the path taken by signalling traffic to that
taken by data traffic (at X-aware GIST nodes). Nevertheless, assumptions (3)
and (4) mandate that this situation does not occur. However, even if
such a situation occurs, the proposals mechanisms described in this document
may still work. work as state expires after a certain timeout period.

If assumption (1) does not hold, X the NSLP has to provide additional
mechanisms for the traversal of (Ga)NATs. These mechanisms must be
compatible with the mechanisms described in this document. employed by GIST. Assumptions (2),
(3) and (4) hold if, at an addressing boundary, only one NAT exists.
Due to security and management reasons, this is likely to be the case
in many settings.

5. Traversal of GaNATs in the absence TLS or IPsec Transparent NAT traversal for GIST

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 GaNATs 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
transparent approach listed in between. Section 3. Note that X the GaNAT may be
any NSLP including
follow this approach only if it is unaware of 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), being
signalled, and (c) the case where a
combination when no cryptographic protection of X-aware and X-unaware GaNATs are between to X peers.
We discuss the three cases separately.

5.1 NSLP-unaware GaNATs

This section describes the algorithm that an X-unaware GaNAT must
execute in order to enable the signalling traffic of two X peers to
traverse the GaNAT in a transparent (for data is
requested by the two peers) manner. The
notation A.B denotes the field B of data structure A. NSLP peers.

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
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
address for forwarded packets in different ways.

5.1.1

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
executes the following algorithm.

1. If P has a RAO followed by the GIMPS GIST header with an NSLP ID that
is not supported, it is identified as a GIMPS GIST QUERY. In this case
the GaNAT performs the following.

1. We denote P as GQ. It looks at the stack proposal ST in GQ.
If it indicates that cryptographic protection is required,
the algorithm mechanism that is executed applies is the one described in
Section 6. ???.

2. The GaNAT remembers GQ along with the interface on which it
arrived. We call this interface the "upstream link".

3. It searches its table of existing NAT bindings against
entries that match the GQ.MRI. A matching entry means that
the data flow, to which the signalling refers, already
exists.

1. If a matching entry is found, the GaNAT looks at which
link the packets of the data flow are forwarded; we call
this link the "downstream" link. Further, the GaNAT
checks how the headers of the data flow (IP addresses,
port numbers, etc) are translated according to this NAT
binding. We denote [IP header].SourceIPAddress used on
the downstream link as IPGaNATds, and the source port
number used to forward the data traffic as SPNDTGaNATds.
The NAT may also use a different source port number when
forwarding signalling traffic. This port number is
denoted as SPNSTGaNATds.

2. If no matching entry is found, the GaNAT determines,
based on its routing table, the link on which packets
that match GQ.MRI (excluding GQ.MRI.SourceIPAddress)
would be forwarded. We call this link the "downstream
link". Then, the GaNAT acquires an IP address for itself
on the downstream link. (This address could be dynamic
or static.) This address will be used to forward both
signalling and data traffic on the downstream link. If
it also performs port translation, the GaNAT also
acquires a source port number for the data traffic on the
downstream link. This will be used with the NAT binding,
if such a binding will be established for the data
traffic at a later stage, and is denoted as SPNDTGaNATds
. SPNDTGaNATds.
The signalling traffic packets may also be forwarded
using the a different source port number as the incoming
packets. We denote the acquired IP address as IPGaNATds
and the source port number for the signalling traffic as
SPNSTGaNATds.

Issues: The reason why the GaNAT may also assign a
different source port number to the signalling traffic,
is to enable the GaNAT to demultiplex (i.e. forward to
the correct internal address) the signalling responses
that arrive from downstream. Of course, a GaNAT does not
need to actually change the source port of signalling
traffic; it can always use SPNSTGaNATds the same port as
in the incoming packet. Such a GaNAT may use the GIMPS GIST
session id ID in order to demultiplex the traffic that
arrives from the downstream direction. It is unclear
which of the two approaches is preferable.

4. It creates a new GIMPS GIST QUERY packet GQ', as follows.

1. GQ' <- GQ

2. GQ'.MRI.SourceIPAddress <- IPGaNATds

3. GQ'.MRI.SourcePortNumber <- SPNDTGaNATds

4. GQ'.[IP header].SourceIPAddress <- IPGaNATds

5. GQ'.[TRANSPORT_LAYER_HEADER].SourcePort GQ'.[UDP HEADER].SourcePort <- SPNSTGaNATds

6. GQ'.NLI.IA <- IPGaNATds
7. GQ'.S <- true

5. It remembers GQ and GQ', the fact that they are associated,
and the associated upstream and downstream links. (Note: The
GaNAT does not have to remember the entire packets; for
simplicity of exposition, however, we assume it does. An
implementation SHOULD discard at this point all information
that is not used later.)

6. It forwards GQ' on the downstream link.

2. Otherwise, if P carries a an [IP header].DestinationIPAddress that
belongs to the GaNAT, and if it is identified as a GIMPS GIST response
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 GR is said
to match a GQ' if they carry the same cookie value. If none
is found, GR is discarded. Otherwise, the GaNAT may also
perform further consistency checks on a matching GR/GQ' pair,
such as checking that they contain the same session IDs,
MRIs, NSLP IDs. If consistency checks succeed, the GaNAT
constructs a new GIMPS GIST response GR', as follows.

1. GR' <- GR

2. GR'.MRI <- GQ.MRI, where GQ is the packet associated with
GQ'(as remembered previously), and GQ' is the packet that
matches the received GR.

3. GR'.[IP header].SourceIPAddress <- IPGaNATus, where
IPGaNATus = GQ.[IP header].DestinationIPAddress.

4. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA

5. GP'.S <- true.

6. It inspects the stack proposals in GR' and the
corresponding GQ' to see if the upstream X GIST peer has a
choice of more than one possible stack. If such a choice
exists, the GaNAT removes as many stack proposals from
GR' as necessary, until only one stack can be chosen by
the upstream peer for the messaging association. We
denote this stack as ST. The GaNAT remembers this ST and
its association with GQ, GQ', GR, GR'. We say that, in
this case, the GaNAT "installs" the ST.

2. It forwards GR' on the upstream link.

3. If no NAT binding for the data traffic was found in step
1.3.2, the GaNAT now installs a NAT binding (for the
unidirectional data traffic) which says that "a packet K that
arrives on the upstream link and for which it holds that

+ K.[IP
header].DestinationIPAddress=GQ.MRI.DestinationIPAddress,

+ K.[IP header].Protocol=GQ.MRI.Protocol, and

+ K.[TCP/UDP header].SourcePort=GQ.MRI.SourcePort

should be forwarded on the downstream link, with [IP
header].SourceIPAddress = IPGaNATds.

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 demultiplex 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 GIMPS GIST session refers, is a separate flow for
which, dependent depending 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 NR-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
arise when traffic, for which no signalling exists, is
allowed to traverse a GaNAT.

Another issue is about refreshing the NAT binding. A NAT
binding that was established as a result of GIMPS GIST signalling
should remain in place for as long as the associated GIMPS GIST
state in the GaNAT remains valid. If GIMPS GIST signalling refers
to a NAT binding that already exists, then the timeout of the
NAT binding should occur according to the NAT policy, in a
manner
independing independent from GIMPS GIST processing. (If signalling
persists after the deletion of a NAT binding, then the NAT
binding may be re-installed and then timeout timed out together with GIMPS
GIST state).

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),
the GaNAT does the following. If P does not match an existing
installed ST, P is silently discarded. (A packet P is said to
"match" an installed ST, if it carries the transport protocol and port numbers
indicated by ST.) Otherwise, some stack proposal ST that has previously been
installed by the GaNAT, and if P has not arrived on either the downstream or
upstream link of some or the downstream interface that is associated with ST, it
then P is
silently discarded. Otherwise, said to "match" ST. For such a packet, the GaNAT does
the following. If P has arrived either on is expected to contain a GIST header, then
the
upstream GaNAT check whether or not the bits where the GIST header is
expected, consitute a valid GIST header. If not, P is silently
discarded. Otherwise, the downstream of some ST. The GaNAT constructs an outgoing packet P'
as follows (the variables used below refer to those stored
together with the ST in question). ST).

1. P' <- P

2. If P has arrived on the upstream link, then

1. P'.[IP header].SourceIPAddress <- IPGaNATds

2. P'.MRI <- GQ'.MRI

3. P'.NLI.IA <- IPGaNATus

4. The GaNAT forwards P' on the downstream link.

3. else (if P has arrived on the downstream link)

1. P'.[IP header].SourceIPAddress <- IPGaNATus

2. P'.MRI <- GQ.MRI

3. P'.NLI.IA <- IPGaNATus

4. The GaNAT forwards P' on the upstream link.

Note:

Note that the above step will fail if ST indicates security.
That is, if traffic GaNAT can determine the location in a packet
where a GIST header is expected. If, for example, the packet
is encrypted, a UDP packet, then the GIST header should follow
immediately after the UDP header. If the packet is a TCP
packet, then the GaNAT cannot
construct P', and if traffic can determine the location where the
GIST heaer should start by counting the number of NSLP
payload bits that followed the end of the previous GIST
header. The start of the next GIST header is integrity-protected,
performing this step will cause an error expected at the receiving X
peer. However, recall
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 this section, we 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 discuss has to keep buffers that
are as long as the scenario where 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 cryptographic protection a packet is not
required. 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
normal NAT processing and forwards the packet on the
corresponding link.

5. Otherwise, P is silently discarded.

Brief discussion of the algorithm: The fact that the GaNAT replaces
the X NSLP peer's NLI.IA with its own IP address (in both directions),
causes the two GIST peers to send subsequent signalling messages to
the GaNAT, in the belief that they talk to the their adjacent X peer.
The GaNAT transparently forwards the signalling traffic and
appropriately translates the fields in the GIMPS GIST header, by making use of in a way that
is consistent with the state translation it creates bindings.

Due applies to the presence of the GaNATs, no data traffic can be sent from
DS traffic.

Note that, according to DR until all necessary bindings are in place. The this mechanism, the size of an outgoing GIST
message is always the same as the size of its corresponding incoming
GIST message. Finally note that the MRI that the NR sees includes indicates
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.

5.1.2

5.2. NR-side NSLP-unaware GaNATs

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
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-
side GaNAT that is in between two X GIST peers, a priori knows the a
routable IP address of the downstream GaNAT. The last GaNAT of this
chain is assumed to know the IP address of the DR. In order to
clarify this assumption, see, for example, Figure 2. In this figure,
GaNAT A is assumed to know the IP address of GaNAT B, GaNAT B is
assumed to know the IP address of GaNAT C, and GaNAT C is assumed to
know the IP address of the DR. A given GaNAT that knows such an
address, in effect anticipates to receive a signalling message from
the upstream direction that refers to a data flow that terminates in
a downstream node. In other words, such a GaNAT may typically have
already a NAT binding in place for the data traffic. We call the IP
address of the next downstream GaNAT (or, if the GaNAT is the last in
the chain, the address of the DR) the "pending" IP address. In the
following description it is denoted by IPNext. How IPNext is made
known to each GaNAT (e.g. how the NAT binding for the data traffic is
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| +--+ +--+
+------+ +-----+ +-----+ +-----+ +------+

Figure 2: Network with NR-side GaNATs (the public Internet is assumed
to be between NI and X NSLP GIST peer 1)

For every arriving IP packet P, an X-unaware, NSLP-unaware, NR-side GaNAT
executes the following algorithm.

1. If P has a RAO followed by the GIMPS GIST header with the NSLP ID = X,
indicates an unsupported NSLP, it is identified as a GIMPS GIST QUERY.
In this case the GaNAT does the following.

1. We denote P as GQ. The GaNAT looks at the stack proposal ST
in GQ. If it indicates that cryptographic protection is
required, the algorithm that is executed is the one described
in section Section 6 below.

2. The GaNAT remembers GQ along with the link on which it
arrived. We call this link the "upstream" link.

3. The GaNAT determines whether or not this GIMPS GIST QUERY is
anticipated, i.e. if a pending IPNext exists. exists that matches
this GIST QUERY. A pending IPNext is said to "match" a GIST
QUERY, if [this condition is an open issue!] If no pending
IPNext is pending, also matching, P is discarded (it is a question
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, P
is discarded. Otherwise, the GaNAT performs the following.

4. It searches its table of existing NAT bindings against
entries that match the GQ.MRI. A matching entry means that
the data flow, to which the signalling refers, already
exists.

+ If a matching entry is found, the GaNAT looks at which
link the packets of the data flow are forwarded; we call
this link the "downstream" link. Further, the GaNAT
checks how the headers of the data flow (IP addresses,
port numbers, etc) are translated according to this NAT
binding. We denote [IP header].SourceIPAddress used on
the downstream link as IPGaNATds, and the source port
number as SPNDTGaNATds. Note that the [IP
header].DestinationIPAddress of this NAT binding should be
equal to IPNext. If it is not, this should be handled as
an auditive error condition. The GaNAT may also assign a
new source port number to signalling traffic, which is
denoted as SPNSTGaNATds.

+ If no matching entry is found, the GaNAT determines, based
on its routing table, the link on which packets that match
GQ.MRI (excluding GQ.MRI.SourceIPAddress and where
GQ.MRI.DestinationIPAddress is replaced with IPNext) would
be forwarded. We call this link the "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 source port numbers for the translation of data
traffic. We denote the acquired IP address as IPGaNATds
and the source port numbers for data and signalling
traffic as SPNDTGaNATds and SPNSTGaNATds respectively.

5. It creates a new GIMPS GIST QUERY packet GQ', as follows.

1. GQ' <- GQ

2. GQ'.MRI.SourceIPAddress <- IPGaNATds

3. GQ'.MRI.DestinationIPAddress <- IPNext.

4. GQ'.MRI.SourcePort <- SPNDTGaNATds.

5. GQ'.[IP header].SourceIPAddress <- IPGaNATds

6. GQ'.[TRANSPORT_LAYER_HEADER].SourcePort GQ'.[UDP HEADER].SourcePort <- SPNSTGaNATds

7. GQ'.[IP header].Destination_IP_Address <- IPNext

8. GQ'.NLI.IA <- IPGaNATds.

9. GQ'.S <- true

6. It remembers GQ, GQ' the fact that they are associated, and
the associated upstream and downstream links (interfaces).

7. It forwards GQ' on the downstream link.

Steps 2,3, 4 and 5 of the algorithm are analogous to the
corresponding steps of the algorithm executed by X-unaware, NI-side NSLP-unaware, NI-
side GaNATs, which was described in Section 5.1.1

5.2 5.1.

5.3. NSLP-aware GaNATs

Recall that X may be any NSLP except NATFW.

The difference of
X-aware NSLP-aware GaNATs and X-unaware NSLP-unaware GaNATs is that
the former perform X NSLP processing in addition to the processing of
the X-unaware NSLP-unaware GaNATs. Another way to see this is by observing
that X-aware NSLP-aware GaNATs should provide an "MRI translation service"
(MRITS) in addition to normal
GIMPS GIST and X NSLP processing. The
motivation behind the MRITS is for GIMPS GIST to hide from the NSLP that
signalling messages traverse an addressing boundary. In other words,
the purpose of the MRITS it is to make X the NSLP believe that it is
operating in a single IP addressing space. When and how the MRITS is
invoked for a particular packet depends on (i) the direction of the
packet (i.e. downstream or upstream) and (ii) the location of the
GaNAT (i.e. NI-side or NR-side). It should also be noted that
certain NSLP layer tasks must be carried out in consistency with the
placement of the MRITS. This is to prevent events triggered by X the
NSLP to cause installation of inconsistent state. In order to
clarify this, consider the scenario of the QoS NSLP running in a
GaNAT that operates according to the mechanisms described in this
section. Since the GaNAT only presents a single addressing space to
the NSLP (say, the internal addressing space), the packet classifier
of the GaNAT's QoS provisioning subsystem should classify packets
based on internal addresses only (i.e. it should first translate
packets that carry external addresses and then classify them).
Whether the MRITS presents internal-only or external-only addresses
to the NSLP is not significant, as long as NSLP layer operations are
carried out consistently. In the remainder of this section we
present the case where internal addresses are presented to the NSLP.

The MRITS is obviously invoked only on GIMPS GIST packets that carry an
NSLP identifier = X. (For other GIMPS packets that corresponds to an NSLP that the GaNAT may adopt the role
of an X-unaware GaNAT. actually
supports. Also, for non-GIMPS non-GIST packets, normal NAT behaviour applies - whatever "normal" may mean.) applies.
Although the MRITS is part of GIMPS GIST processing, in order to clarify
our discussion, we view it as a somewhat separate processing step
(i.e. like a subroutine). For NI-side, X-aware NSLP-aware GaNATs, it holds
that
o if for a GIMPS/X 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 X the NSLP and before it is given to GIMPS, GIST, and

o if for a GIMPS/X GIST/NSLP packet that is received on the downstream link, then
the MRITS is invoked after GIMPS GIST processing and before the packet
is given to X. the NSLP.

The converse holds for NR-side X-aware NSLP-aware GaNATs. In particular,

o if for a GIMPS/X GIST/NSLP packet that is to be forwarded on the upstream
link of an NI-side GaNAT, the PTS MRITS is invoked after the packet
has been processed by X the NSLP and before it is given to GIMPS, GIST, and

o if for a GIMPS/X GIST/NSLP packet that is received on the upstream link, then the PTS
MRITS is invoked after GIMPS GIST processing and before X NSLP processing.

Figure 3 illustrates this idea.

+----------------+ +----------------+
| +------+ | | +------+ |
| |NSLP X| | NSLP | | | | NSLP | |NSLP X| |
| +-+---++ | | +-+--+-+ |
| | | | | | | |
| | +-+---+ | | +----++ | |
| | |MRITS| | | |MRITS| | |
| | +---+-+ | | ++----+ | |
| | | | | | | |
| +-+-----+-+ | | ++------+-+ |
| | GIMPS GIST | | | | GIMPS GIST | |
u/s | +-+-----+-+ | d/s u/s | ++------+-+ | d/s
-----+----+ +-----+----- -----+---+ +-----+-----
link +----------------+ link link +----------------+ link
NI-side NR-side
X-aware X-aware
NSLP-aware NSLP-aware
GaNAT GaNAT

Figure 3: Operation of the MRI Translation Service

The reason for this construction is to give X the NSLP the impression
that it works only with flows that originate and terminate in the
internal address space. We now describe the operation of the MRITS
and GIMPS GIST in X-aware NSLP-aware GaNATs. An NI-side X-aware NSLP-aware GaNAT operates
according to the following rules.

1. When X the NSLP asks for a message to be sent towards the
downstream X GIST peer, the MRITS does the following (IPGaNATds and
SPNDTGaNATds are obtained similarly to the case of an NSLP-unaware NSLP-
unaware GaNAT).

1. MRI.SourceIPAddress <- IPGaNATds

2. MRI.SourcePort <- SPNDTGaNATds

2. Additionally, GIMPS GIST performs the following on the resulting packet
before it is forwarded on the downstream link (SPNSTGaNATds is
obtained similarly to the case of an NSLP-
unaware NSLP-unaware GaNAT).

1. [IP header].SourceIPAddress <- IPGaNATds

2. [UDP/TCP header].SourcePort <- SPNSTGaNATds

3. NLI.IA < <- IPGaNATds

4. S <- true

3. If a message is received on the downstream link, the MRITS does
the following before X the NSLP is invoked.

1. MRI.SourceIPAddress <- IPflow

2. MRI.SourcePort <- SPNDTGaNATus, where IPflow is the IP
address of the DS (as seen by the GaNAT) and SPNDTGaNATus is
the destination port number used in the original MRI.

4. If, after X NSLP processing, a message is to be forwarded on the
upstream link, GIMPS GIST performs the following processing (note that
no MRITS processing takes place in this case).

1. [IP header].SourceIPAddress <- IPGaNATus

2. [IP header].DestinationIPAddress <- IPpeer

3. NLI.IA <- IPGaNATus

4. S <- true, where IPGaNATus is the GaNATs IP address for the
upstream link, IPpeer is the IPaddress of the NI (or the next
GaNAT in the upstream direction), and IPflow is the IP
address of the DS (as seen by the GaNAT). The GaNAT is
assumed to determine the correct IPGaNATus and IPpeer from
previous communications and in cooperation with GIMPS. GIST.
[Issue: how exactly should IPGaNATus, IPpeer and IPflow be
resolved; i.e. what exactly should the GaNAT remember?]

An NR-side X-aware NSLP-aware GaNAT operates according to the following
rules.

1. If the packet is received on the upstream link, the MRITS does
the following, before X the NSLP is notified.

1. P.MRI.SourceIPAddress <- IPGaNATds

2. P.MRI.DestinationIPAddress <- IPNext, where IPGaNATds 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
the case of an NSLP-unaware GaNAT.

2. If, after X NSLP processing, a message is to be forwarded on the
downstream link, GIMPS GIST performs the following processing (note
that no MRITS processing takes place in this case).

1. [IP header].SourceIPAddress <- IPGaNATds

2. [IP header].DestinationIPAddress <- IPNext

3. NLI.IA <- IPGaNATds

4. S <- true, where IPGaNATds is the GaNATs IP address for the
downstream link, IPNext is the IP address of the DR (or the
next GaNAT in the downstream direction). The GaNAT is
assumed to determine the correct IPNext in a way similar to
the case of an NSLP-unaware GaNAT.

3. When X the NSLP asks for a message to be sent towards the upstream X
GIST peer, the MRITS does the following.

1. MRI.SourceIPAddress <- IPflow

2. MRI.Destination_IP_Address <- IPGaNATus

4. Additionally, GIMPS GIST performs the following on the resulting packet
before it is forwarded on the downstream link.

1. [IP header].SourceIPAddress <- IPGaNATus

2. [IP header].DestinationIPAddress <- IPpeer

3. NLI.IA <- IPGaNATus

4. S <- true, where IPGaNATus is the GaNATs IP address for the
upstream link, IPpeer is the IP_address IP address of the NI (or the
next GaNAT in the upstream direction), and IPflow is the IP
address of the DS. The GaNAT is assumed to determine the
correct IPGaNATus and IPpeer fields from previous
communications and in cooperation with GIMPS. GIST. [question: how
exactly should IPGaNATus and IPpeer be resolved; i.e. what
exactly should the GaNAT remember]?

5.3

5.4. Combination of NSLP-aware and NSLP-unaware GaNATs

In the absence of an adversary, a combination of NSLP-aware and NSLP-
unaware GaNATs should work without further specification. However,
in the presence of an adversary, additional security issues may arise
from the combination. These issues may introduce opportunities for
attack that do not exist in setting where the on-path GaNATs are
either all X-aware NSLP-aware or all X-unaware. NSLP-unaware.

6. GaNATs in the presence of TLS or IPSec Non-transparent NAT traversal

This section discusses the "non-transparent" operation for GaNAT
traversal for GIMPS at the GIST layer, i.e. the first approach listed in
Section 3. For this approach, the case where
two peers that run a particular NSLP, say NSLP X, require
cryptographic protection behaviour of both the signalling traffic they exchange. GaNAT and
the GIST peers is defined. As with the case where no cryptographic protection of signalling traffic
is required, transparent approach, the
case of the in-between GaNAT(s) being X-unaware located at the NI-side is
different from the case that of them being X-aware.

6.1 NSLP-unaware GaNATs

If the two X peers require a C-mode protocol stack NR-side GaNATs. Note that indicates
cryptographic protection, then, after the stack has been agreed by
both peers and the underlying cryptographic protection is applied to
messages, the GaNAT will be unable to translate the GIMPS header
fields, in a way similar to the way described mechanisms in Section 5.1.1. An
approach to cope with this, is
this section apply only to inform NSLP-unware GaNATs.

The GaNAT informs the X NSLP peers about the its presence of the NAT during discovery. the GIST
discovery process. This information will enable enables the X peers, rather than NSLP peers to map
the GaNAT(s) translated data flow to perform the translation of signalling messages, and to
consistently translate the fields involved, after MRI, so that the necessary cryptographic operations
have been completed. In this scenario, NSLP only "sees" the burden imposed on
correct MRI. Cryptographic protection of signalling messages can be
supported with this approach because the GaNAT is considerably less, as the only type of GIMPS messages that
it needs to process in a special way, are modifies the GIMPS GIST
QUERY and GIMPS
RESPONSE messages. REPONSE messages, which are never cryptographically
protected in their entirety.

In order to support this approach, the scenario of X-unaware GaNATs, GaNAT embeds a new GIMPS GIST payload type has to be defined that into the
GIST QUERY. This payload encodes the aforementioned
information. We information, and
we call this payload type the "NAT Traversal Object" (NTO). The NTO
is an optional payload in the GIMPS GIST header of a GIMPS 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 X NSLP peers
to locally translate the MRI in the same way as if it would have
been were
consistently and transparently translated by the in-between GaNAT(s) if no cryptographic
protection was applied to the signalling traffic. GaNAT(s).
Note that there may be more than one GaNAT between the two X NSLP
peers. We now describe The format of the algorithm that an X-unaware GaNAT must execute NTO follows the format of the object in order to enable the two X peers
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 reach
0 in this goal. header, indicating that support for the NTO is mandatory.
The two types type value is TBD. The NTO is defined as in section A.3.8 of GaNATs, namely those at the NSIS initiator (NI)
side, and those at the NSIS responder (NR) side, follow different
algorithms.

6.1.1
[1].

6.1. NI-side NSLP-unaware GaNATs

For every arriving IP packet P, an X-unaware, NSLP-unaware, NI-side GaNAT
executes an algorithm that is equivalent to the following algorithm. following.

1. If P has a RAO followed by the GIMPS GIST header with an NSLP ID that
is not supported, it is identified as a GIMPS GIST QUERY. In this case
the GaNAT does the following.

1. We denote P as GQ. The GaNAT looks at the stack proposal ST
in GQ. If it does not indicate that include a proposal with cryptographic protection
is required,
protection, the algorithm that is executed is GaNAT MAY choose to follow the one approach
described in Section 5.1.1 5.1 above.

2. The GaNAT remembers GQ along with We call the link on which it
arrived. We call this link GQ arrived the "upstream" link.

3. The GaNAT searches its table of existing NAT bindings against
entries that match the GQ.MRI. A matching entry means that
the data flow, to which the signalling refers, already
exists.

+ If no matching entry is found, the GaNAT determines, based
on its routing table, the link on which packets that match
GQ.MRI (excluding GQ.MRI.SourceIPAddress) would be
forwarded. We call this link the "downstream" link.
Then, the GaNAT acquires an IP address and source port for
itself on the downstream link. (This address and port
could be dynamic or static.)

4. We denote [IP header].SourceIPAddress used on the downstream
link as IPGaNATds, and the source port number for the data
and signalling traffic as SPNDTGaNATds and SPNSTGaNATds
respectively.

5. It creates a new GIMPS GIST QUERY packet GQ', as follows (note
that the new packet contains the same MRI as GQ). follows.

1. GQ' <- GQ

2. GQ'.MRI.SourceAddress <- IPGaNATds.

3. GQ'.MRI.SourcePort <- SPNDTGaNATds.

4. GQ'.NLI.IA.<- IPGaNATds.

5. GQ'.[IP header].SourceIPAddress <- IPGaNATds.

3. GQ'.[UDP].SourcePort

6. GQ'.[UDP header].SourcePort <- SPNSTGaNATds.

7. GQ'.S <- true
5. true.

8. It checks whether or not a an NTO is was included in the GQ.

- If none is was included, it adds creates a new one NTO as follows
and adds it to GQ' such
that GQ'.NTO=[ IPGaNATds || SPNDTGaNATds] GQ'.

o NTO.[NAT Count] <- 1.

o NTO.MRI <- GQ.MRI.

o NTO.[List of translated objects] <- [type of MRI],
[type of NLI], [type of SCD]

o NTO.opaque information for NAT 1 <- GQ.[IP
header].SourceAddress, [link identifier of upstream
link].

- If one is was included, it replaces it as GQ'.NTO=[
IPGaNATds || SPNDTGaNATds]

6. It remembers GQ, GQ' certain fields and
appends new fields into the fact that they are associated, NTO, as follows, and adds
the associated 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 and downstream links.

7.
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 a an [IP header].DestinationIPAddress that
belongs to the GaNAT, and if it is identified as a GIMPS response GIST RESPONSE
packet in D-mode datagram 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
to be matching if it carries the same cookie value. If none
is found, GR is discarded. P does not contain an NTO, the GaNAT forwards it as usual
without further processing. Otherwise, the GaNAT should also
make sure that selects the session ID
information encoded by it in GR is the same as in GQ' and
that [opaque information replaced
by NAT] field of the NSLP IDs match. embedded NTO, denoted by IPAddressToSend
and LinkID. If these consistency checks fail,
GR should be discarded. Otherwise, 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 GIMPS GIST response GR', as
follows (note that no changes are made to the MRI).

1. GR' <- GR

2. GR'.[IP header].SourceIPAddress header].DestinationIPAddress <- IPGaNATus, where
IPGaNATus = GQ.[IP header].DestinationIPAddress. IPAddressToSend.

3. GR'.[IP header].DestinationIPAddress GR'.NTO.[NAT Count] <- GQ.NLI.IA current value minus one.

4. GP'.S Remove the last [opaque information replaces by NAT i]
field from GR'.NTO

5. GR'.S <- true.

2. It checks whether or not a NTO is included forwards GR' on the upstream link, i.e. the link
identified by LinkID.

3. The GaNAT SHOULD now invalidate all but one stack
configuration objects in the GQ.

- If none stack proposal in GR'. This is included, it adds a new one to GQ' such
done so that the quering node can only chose that GQ'.NTO=[ IPGaNATus || PNGaNATus]

- If one is included, it replaces it such
proposal, and that GQ'.NTO=[
IPGaNATus || PNGaNATus]

6. It remembers GQ, GQ' therefore only one NAT binding must be
installed for the fact 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.

4. The GaNAT now installs a NAT binding for the signalling
traffic which says that they are associated,
and "a packet K that arrives on the associated
upstream link and downstream links.

7. It forwards GQ' for which it holds that

+ K.[IP header].SourceIPAddress=IPAddressToSend,

+ K.[IP header].Protocol=PR.Protocol, and

+ K.[TCP/UDP header].DestinationPort=PR.[Destination Port]

should be forwarded on the downstream link.

2. It forwards GR' link (i.e. on the upstream link.

3. 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
unidirectional data traffic) which says that "a packet K that
arrives on the upstream link and for which it holds that

+ K.[IP
header].DestinationIPAddress=GQ.MRI.DestinationIPAddress, header].DestinationIPAddress=GQ'.NTO.MRI.Destination
IPAddress,

+ K.[IP header].Protocol=GQ.MRI.Protocol, header].Protocol=GQ'.NTO.MRI.Protocol, and

+ K.[TCP/UDP header].PortNumbers=GQ.MRI.PortNumbers header].PortNumbers=GQ'.NTO.MRI.PortNumbers

should be forwarded on the upstream link, downstream link (i.e. the link on
which GR arrived), with [IP header].SourceIPAddress = IPGaNATus.
IPGaNATds and [UDP/TCP header].SourcePort=SPDTGaNATds.

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 demultiplex 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 GIMPS 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 NR-side GaNAT for this
session. Thus, during the processing of this signalling 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. 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
processing is applied.

4. Otherwise, P is silently discarded.

6.1.2

6.2. NR-side NSLP-unaware GaNATs

As is the case with NR-side NSLP-unaware GaNATs without security, that follow the
"transparent" approach, an NR-side NSLP-unaware GaNAT that follows
the "non-transparent" approach must know a "pending" IP address, address and,
depending on the scenario, also a destination port number, as
described in Section 5.1.2. 5.2. This IP address is and destination port
number are denoted as IPNext. 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
executes the following algorithm.

1. If P has a RAO followed by the GIMPS a GIST header with an unsupported
NSLPID, it and is identified as a GIMPS QUERY. In this case GIST QUERY, the GaNAT does the
following.

1. We denote P as GQ. The GaNAT looks at the stack proposal ST
in GQ. If it indicates that no cryptographic protection is
required, the algorithm that is executed is GaNAT MAY choose to follow the one "transparent"
approach as described in Section 5.1.2 5.2 above.

2. The GaNAT remembers GQ along with If GQ.[IP header].[Destination Address] is not bound to the
link on which it
arrived. We call this link GQ arrived, the "upstream" link. GaNAT silently discards the
packet.

3. The GaNAT determines whether or not this GIMPS GIST QUERY is
anticipated, i.e. if a pending IPNext and PortNext exists.
One way of determining whether or not a pending IPNext and
PortNext exists is checking whether or not a NAT binding for
the data traffic, as this is defined by the MRI in the GIST
QUERY, exists in the NAT binding cache. If one exists, then
IPNext and PortNext is the address and port number to which
the data traffic is sent after translation. If no pending
IPNext is pending, found, GQ is discarded (it is a question 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 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
the data flow, to which the signalling refers, already
exists.

+ If a matching entry is found, the GaNAT looks at which determines the
link on which the packets of the data flow are forwarded;
we call this link the "downstream" link. Further, the
GaNAT checks how the headers of the data flow (IP
addresses, port numbers, etc) numbers) are translated according to this
NAT binding. We denote [IP header].SourceIPAddress used on
the downstream link as IPGaNATds, and the port numbers as
PNGaNATds. Note that the [IP
header].DestinationIPAddress of this NAT binding should be
equal to IPNext. If it is not, this should be handled as
an auditive error condition. (This check is done as a
consistency check.)

+ If no matching entry is found, the GaNAT determines, based
on its routing table, the link on which packets that match
GQ.MRI (excluding GQ.MRI.SourceIPAddress and where (where GQ.MRI.DestinationIPAddress is replaced with
IPNext) would be forwarded. We call this link the
"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.

6. It creates a new GIMPS GIST QUERY packet GQ', as follows (note
that the new packet contains the same MRI as GQ). follows.

1. GQ' <- GQ

2. GQ'.[IP header].SourceIPAddress GQ'.MRI.DestinationAddress <- IPGaNATds. IPNext.

3. GQ'.S GQ'.MRI.DestinationPort <- true PortNext.

4. GQ'.[IP header].DestinationIPAddress <- IPNext.

5. It checks whether or not a an NTO is was included in the GQ.

- If none is was included, it adds creates a new one NTO as follows
and adds it to GQ' such
that GQ'.NTO=[ IPGaNATds || SPNDTGaNATds] GQ'.

o NTO.[NAT Count] <- 1.

o NTO.MRI <- GQ.MRI.

o NTO.[List of translated objects] <- [type of MRI],
[type of NLI], [type of SCD]

o NTO.opaque information for NAT 1 <- IPGaNATus,
[link identifier of upstream link].

- If one is was included, it replaces it as GQ'.NTO=[
IPGaNATds || SPNDTGaNATds]

5. It remembers GQ, GQ' certain fields and
appends new fields into the fact that they are associated, NTO, as follows, and adds
the associated 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 SCD]

o NTO.[opaque information replaced by NAT i] <-
IPGaNATus, [LinkID of upstream and downstream links. link].

6. It forwards GQ' on the downstream link. Note: The remaining steps of the algorithm are analogous to the algorithm
of NSLP-unaware, NI-side GaNATs, which was described in the previous
section.

6.1.3 Additional GIMPS peer processing

In the presence
encoding of GaNATs on the signalling path between two NSLP
peers, and if cryptographic protection of the signalling traffic
between these two peers is required, information that the translation of GaNAT encodes into
the GIMPS
header fields that need to be translated for consistency, must be
carried out NTO.[opaque information replaced by the X peers. The GIMPS processing that performs this
task, NAT i] field is described next. Note that this processing a
local implementation issue.

2. Otherwise, if P 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 identified as a GIMPS GIST RESPONSE packet that carries (a) an NSLPID
for a supported NSLP, and (b) an NTO in its header, executes the
following algorithm, before
datagram mode with an NSLP ID that is not supported, the processing described in [1] takes
place.

1. If GaNAT
does the packet following (P is a GIMPS QUERY or CONFIRM in D-mode, denoted G,
the peer constructs a new packet, denoted G', as follows. GR).

1. G' <- G

2. G'.MRI.Source_IP_Address <- G.NTO.IPGaNATds

3. G'.MRI.SourcePort <- G.NTO.SPNDTGaNATds

4. G'.NLI.IA <- G.NTO.IPGaNATds

5. G'.NTO is removed.

and forwards G' to GIMPS for further processing. If G is a GIMPS
QUERY and local policy demands P does not contain an NTO, the installation of state GaNAT forwards it as usual
without further processing. Otherwise, the reception of a GIMPS CONFIRM message, then the peer must
store GaNAT selects the NTO carried
information encoded by G together with it in the routing state [opaque information about the sending GIMPS peer. If G is a GIMPS
CONFIRM and local policy demands the installation of state only
after reception replaced
by NAT] field of a valid CONFIRM, then the peer stores, after
validating the cookie in the CONFIRM, the NTO carried embedded NTO, denoted by G
together with the routing state IPGaNATus and
LinkID. If multiple [opaque information about replaced by NAT]
fields are present in the sending
GIMPS peer.

2. Otherwise, if NTO, the packet is a GIMPS RESPONSE GaNAT uses the last one in D-mode, denoted
GR,
the peer list. The GaNAT then constructs a new packet, denoted GIST response GR',
as follows. follows (note that no changes are made to the MRI).

1. GR' <- G GR

2. GR'.MRI.Source_IP_Address GR'.[IP header].SourceIPAddress <- GR.NTO.IPGaNATus IPGaNATus.

3. GR'.MRI.SourcePort GR'.MRI.NLI.IA <- GR.NTO.PNGaNATus IPGaNATus.

4. GR'.NLI.IA <- GR.NTO.IPGaNATus Remove the last [opaque information replaced by NAT i]
field from GR'.NTO.

5. GR'.NTO GR'.S <- true.

2. The GaNAT SHOULD now invalidate all but one stack
configuration objects in the stack proposal in GR'. This is removed.
done so that the quering node can only chose that one
proposal, and forwards GR' to GIMPS that therefore only one NAT binding must be
installed for further processing. If the cookie
in GR' is verified sucessfully, signalling traffic to traverse the peer stores GaNAT.
The GaNAT SHOULD keep valid the NTO carried strongest, in terms of
security, stack proposal. We denote this proposal as PR. If
PR.[Destination Port] is already used by GR together with the routing state information about the
sending GIMPS peer.

A peer that receives GaNAT as a GIMPS packet P (in this case, port
in order to demultiplex an existing signalling flow, the packet
GaNAT reserves a port SIGPORT (that it will
be use as a cryptographically protected GIMPS packet) the peer does the
following substitutions after source
port for UDP/TCP signalling traffic that it will send on the cryptographic processing is
(successfully) completed
upstream link) and before the processing described in [1]
takes place.

1. P.MRI.SourceIPAddress <- P.NTO.IPGaNATds

2. P.MRI.SourcePort replaces PR.[Destination Port] with
SIGPORT. Otherwise it sets SIGPORT=PR.[Destination Port].
It then sets GR'.[UDP header].SourcePort <- P.NTO.SPNDTGaNATds SIGPORT.

3. P.NLI.IA <- P.NTO.IPGaNATds It forwards GR' on the upstream link, i.e. the link
identified by LinkID.

4. P.NTO is removed.

A peer that intends to send The GaNAT now installs a GIMPS NAT binding for the signalling
traffic which says that "a packet (in this case,
cryptographic protection will K that arrives on the
upstream link and for which it holds that

+ K.[IP header].DestinationIPAddress=IPGaNATus,

+ K.[IP header].Protocol=PR.Protocol, and

+ K.[TCP/UDP header].DestinationPort=SIGPORT
should be required 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].

5. If no NAT binding for the packet), data traffic was found in step
1.3.2, the peer
does GaNAT may now install a NAT binding (for the following after
unidirectional data traffic) which says that "a packet L that
arrives on the processing described in [1] upstream link and before for which it holds that

+ L.[IP header].DestinationIPAddress=GR'.NTO.MRI.Destination
IPAddress,

+ L.[IP header].Protocol=GR'.NTO.MRI.Protocol, and

+ L.[TCP/UDP
header].DestinationPortNumbers=GR'.NTO.MRI.DestinationPort

should be forwarded on the packet downstream link, with [IP
header].DestinationIPAddress = IPNext and [UDP/TCP
header].DestinationPort=PortNext.

Issues: there is passed a question of whether this NAT binding
should also enable data traffic in the opposite direction to
traverse the process NAT; in order to be able to multiplex upstream
traffic that applies the cryptographic
protection. Note carries data that the NTO refers belongs to different flows,
the NTO that is stored
together with GaNAT should keep the routing state information necessary per-flow state. From a
signalling point of the peer view, however, upstream data traffic that is
corresponds (on the application level) to
receive the packet.

1. P.MRI.Source_IP_Address <- NTO.IPGaNATds

2. P.MRI.SourcePort <- NTO.PNGaNATds

3. P.NLI.IA <- NTO.IPGaNATds

6.2 NSLP-aware GaNATs

The cryptographic protection applies downstream flow
to of which this GIST session refers, is a separate flow for
which, dependent on the application, there may or there may
not exist a signalling messages
terminates at NSLP-aware GaNATs. The processing performed by session. If such
GaNATs 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 therefore identical
allowed to the traverse a GaNAT.

3. Otherwise, if P matches an existing NAT binding, normal NAT
processing described in
Section 5.2, with the exception that is applied.

4. Otherwise, P is silently discarded.

6.3. GIST peer processing

In the presence of GaNATs additionally perform
cryptographic operations. In this case, there is no requirement for on the signalling path between two NSLP
peers, and if the GaNATs follow the "non-transparent" approach (which
they have to perform any follow in the context of cryptographically protected
signalling), the consistent translation for of the purposes 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 NAT
traversal. [1].

7. NSIS-unaware GIST-unaware NATs

The following may serve as indications for the existence of an NSIS- GIST-
unaware NAT between two GIMPS GIST peers. These indications can only be
detected by the receiver of a GIMPS GIST message. The first occasion these
indications may be detected is with the reception of a GIMPS GIST QUERY,
typically by the downstream peer. (Note that != denotes inequality).

o The MRI.SourceIPAddress does not belong to the addressing space of
the receiving peer.

o The MRI.DestinationIPAddress does not belong to the addressing
space of the receiving peer.

o The IP address in the NLI.IA object field does not belong to the
addressing space of the receiving peer.

o The D flag of a received GIMPS GIST packet denotes downstream direction
and the S flag is not set and [IP header].SourceIPAddress !=
MRI.SourceIPAddress.

o The D flag of a received GIMPS GIST packet denotes upstream direction
and the S flag is not set and [IP header].SourceIPAddress !=
MRI.DestinationIPAddress.

o This is a GIMPS GIST QUERY and [IP header].DestinationIPAddress !=
MRI.DestinationIPAddress.

Note that these are only indications. In the presence of an
adversary, a GIMPS GIST peer may be tricked into believing that an NSIS- GIST-
unaware NAT exists between itself and one of its neighbouring peers,
while in reality this may not be the case.

When a downstream GIMPS GIST peer detects such an indication, it may notify
the upstream peer about the error. It may include additional
information that enables the upstream peer to construct a GIMPS GIST packet
in such a way that, after it traverses the NSIS-unaware GIST-unaware NAT, the IP
addresses in the MRI field and the NLI.IA object field are consistent with
those in the IP header (which match the addressing space of the
receiving peer). However, this requires the specification of new
data structures and formats, processing rules, and requires the peers
to maintain additional state.

Unfortunately, this approach is likely to fail in many circumstances.
In order to see this, consider the behaviour of an NSIS-unaware GIST-unaware NAT
when it receives an IP packet. The packet either
1. matches an existing NAT binding in which case its IP header is
translated and the packet it is forwarded on another link, or

2. matches an existing policy rule which causes a new binding to be
established and then (1) happens, or

3. is discarded because neither (1) nor (2) applies.

With NSIS-unaware 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
to traverse the NAT. This obviously applies to both signalling and
data traffic, as an NSIS-unaware GIST-unaware NAT is unable to distinguish the two
types of traffic. It may be the case that GIMPS GIST node A is unable to
contact GIMPS GIST node B which is "behind" a NAT, even if communication in
from B to A may be possible because such communication would match a
policy rule; typically, in a scenarios where A is towards the NI and
B is towards the NR, the NAT would have this behaviour.

Another approach to deal with NSIS-unaware GIST-unaware NATs is similar to the NAT
traversal approach taken by IKEv2, i.e. by encapsulating GIMPS GIST
messages into UDP datagrams, rather than directly into IP datagrams.
This technique requires the inclusion of additional fields into a
GIMPS
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
GIMPS
GIST payload. The receiver of this GIMPS GIST messages compares these
addresses to the [IP header].SourceIPAddress and the [IP
header].DestinationIPAddress respectively. If at least one of them
is unequal, the receiver deduces that a NAT is between sender and
receiver. After the detection of a NAT, the remainder of the
communication is encapsulated into UDP datagrams that are addressed
to a specified port.

Unfortunately, the IKEv2 NAT traversal mechanism cannot be used "as
is" for NAT traversal in GIMPS. GIST. This is because of a number of
reasons, including the following.

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 GIST
traffic. Since the NAT is NSIS-unaware GIST-unaware it cannot update the MRI
in the GIMPS GIST messages such that it matches the translation applies
to the data traffic. Moreover, neither the GIMPS GIST sending, nor the
GIMPS
GIST receiving peer can perform this update; the sending peer
cannot predict the translation that the NAT will apply, and the
receiving peer does not have enough information to associate data
flows to signalling messages.

o It is unclear whether or not the IKEv2 NAT traversal mechanism
supports cascades of NATs.

o It seems to be inappropriate to use UDP encapsulation for certain
C-mode scenarios. For example, using UDP encapsulation for TCP
C-mode would result in GIMPS GIST to appear in TCP over UDP over IP.

8. Security Considerations

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 is mentioned.

8.1

8.1. Service Denial Attacks

As described in Section 5.1 and Section 6.1, above, NSLP-unaware GaNATs create some state whenever
they receive a GIMPS GIST QUERY message. This state is necessary in order
for the GaNAT to be able to map a GIMPS GIST RESPONSE that arrives from the
downstream direction to the corresponding GIMPS GIST QUERY and thereby to
perform the required translation.

The threat here is an attacker flooding the GaNAT with maliciously
constructed GIMPS GIST QUERIES with the aim of exhausting the GaNAT's
memory. The attacker might use a variety of methods to construct
such GIMPS GIST QUERIES, including the following.

1. Use as [IP header].SourceIPAddress the address of some other node
or an unallocated IP address. This method is also known as IP
spoofing.

2. Use an invalid NSLPID, in order to make sure that all on-path
GaNAT(s) will behave like NSLP-unaware GaNATs.

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.

5. Combinations of the above.

How vulnerable a GaNAT is to the above service denial attack depends
on a variaty of factors, including the following.

o The amount of state allocated at the receipt of a GIMPS GIST QUERY.
This amount may vary depending on whether or not the data flow to
which the signalling refers, already exists (i.e. whether or not
the GaNAT already maintains a NAT binding for it).

o The mechanism that the GaNAT uses to map RESPONSEs to QUERIEs.

o Whether or not the GaNAT acriques dynamic IP addresses and ports
for the downstream link.

In order to decrease the exposure of a GaNAT to service denial
attacks, the following recommendations are made.

o The GaNAT should perform ingress filtering. This limits the
amount of locations from which an attacker can perform IP spoofing
without being detected.

o The GaNAT should allocate the minimum amount of state required at
the reception of a GIMPS GIST QUERY.

o All state allocated by the GaNAT should timeout according to a
local policy. If the GaNAT detects heavy loads (which may
indicate a service denial attack in progress), the GaNAT should
timeout the state allocated as a result of a received GIMPS GIST QUERY
quicker, proportionally to the experienced load.

o The installation of a NAT binding for the data traffic (if such a
binding does not exist prior to signalling) should be postponed
until the correct GIMPS GIST REPONSE traverses the NAT.

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
its local policy, to verify the validity of the cookie(s) before
allocating any state, including the state required by the mechanisms
in this document.

8.2

8.2. Network Intrusions

Although the primary goal of a NAT is to perform address translation
between two addressing spaces, NATs are sometimes also used to
provide a security service similar to the security service provided
by firewalls. That is, a NAT can be configured so that it does not
forward packets from the external into the internal network, unless
it determines that the packets belong to a communication session that
was originally initiated from an internal node and are, as such,
solicited.

If an NSLP-unaware GaNAT performs the above security-relevant
function in addition to address translation, then the presence of
GIMPS
GIST signalling and, in particular the mechanisms described in this
document, might allow an adversary cause the installation of NAT
bindings in the GaNAT using these mechansisms. These NAT bindings
would then enable the adversary to inject unsolicited traffic into
the internal network, a capability that it may not have in the
absence of the mechanisms described in this document.

The administrator of an NSLP-unaware GaNAT should therefore make
security-concious decisions regarding the operation of the GaNAT. An
NSLP-aware GaNAT, on the other hand, follows an NSLP policy which
indicates the required security mechanisms. This policy should
account for the fact that this NSLP-aware node performs also NAT and
the associated packet filtering.

9. Acknowledgments IAB Considerations

None.

10. Acknowledgements

The authors would like to thank Cedric Aoun, Christian Dickmann,
Robert Hancock, Cedric Aoun and Martin Stiemerling for their feedback. insightful comments.
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
information regarding IAB considerations.

11. IANA Considerations

This document does not require actions by the IANA.

12. Normative References

[1] Schulzrinne, H. and R. Handcock, "GIMPS: Hancock, "GIST: General Internet
Messaging Protocol for Signalling",
Signalling Transport", draft-ietf-nsis-ntlp-06 (work in
progress), May 2005.

[2] Stiemerling, M., Tschofenig, H., and C. Aoun, "NAT/Firewall NSIS
Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06
(work in progress), May 2005.

Authors' Addresses

Andreas Pashalidis
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany

Email: Andreas.Pashalidis@siemens.com

Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany

Email: Hannes.Tschofenig@siemens.com

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.