< draft-pashalidis-nsis-gimps-nattraversal-01.txt   draft-pashalidis-nsis-gimps-nattraversal-02.txt >
NSIS A. Pashalidis NSIS A. Pashalidis
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Expires: April 27, 2006 Siemens Expires: August 5, 2006 Siemens
October 24, 2005 February 2006
NAT Traversal for GIST GIST NAT Traversal
draft-pashalidis-nsis-gimps-nattraversal-01.txt draft-pashalidis-nsis-gimps-nattraversal-02.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 April 27, 2006. This Internet-Draft will expire on August 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes how different types of Network Address This document describes a number of mechanisms for the implementation
Translator (NAT) interact with the General Internet Signalling of the General Internet Signalling Transport (GIST) protocol [1] on
Transport (GIST) protocol. The purpose of this interaction is for different types of Network Address Translator (NAT). The focus of
signalling traffic to traverse the NATs in a way that preserves its these mechanisms is the interaction of GIST with the address
semantics with respect to the data flows it corresponds to. translation function of the NAT, and their purpose is to enable GIST
hosts that are located on either side of the NAT to correctly
interpret signalling messages with respect to the data traffic they
refer to. The purpose of this document is to provide guidance to
people that implement GIST and NSLPs on both NAT and non-NAT nodes.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Transparent NAT traversal for GIST . . . . . . . . . . . . . . 13 5. Transparent NAT traversal for GIST . . . . . . . . . . . . . . 13
5.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 13 5.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 13
5.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 18 5.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 19
5.3. NSLP-aware GaNATs . . . . . . . . . . . . . . . . . . . . 21 5.3. NSLP-aware GaNATs . . . . . . . . . . . . . . . . . . . . 21
5.4. Combination of NSLP-aware and NSLP-unaware GaNATs . . . . 25 5.4. Combination of NSLP-aware and NSLP-unaware GaNATs . . . . 25
6. Non-transparent NAT traversal . . . . . . . . . . . . . . . . 26 6. Non-transparent NAT traversal for GIST . . . . . . . . . . . . 27
6.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 26 6.1. NI-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 27
6.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 30 6.2. NR-side NSLP-unaware GaNATs . . . . . . . . . . . . . . . 32
6.3. GIST peer processing . . . . . . . . . . . . . . . . . . . 34 6.3. GIST peer processing . . . . . . . . . . . . . . . . . . . 38
7. GIST-unaware NATs . . . . . . . . . . . . . . . . . . . . . . 36 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41
8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 7.1. Service Denial Attacks . . . . . . . . . . . . . . . . . . 41
8.1. Service Denial Attacks . . . . . . . . . . . . . . . . . . 39 7.2. Network Intrusions . . . . . . . . . . . . . . . . . . . . 42
8.2. Network Intrusions . . . . . . . . . . . . . . . . . . . . 40 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 44
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 42 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 10. Normative References . . . . . . . . . . . . . . . . . . . . . 45
11. Normative References . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 45
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 packets that traverse them. In the context of and transport layer header of the packets that traverse them. In the
signalling as specified by the General Internet Signalling Transport context of signalling as specified by the General Internet Signalling
(GIST) protocol [1], this behaviour may lead to the installation of Transport (GIST) protocol [1], this behaviour may lead to the
state at network nodes that may be inconsistent and meaningless with installation of state at network nodes that may be inconsistent and
respect to the actual traffic that traverses these nodes. meaningless with respect to the data traffic that traverses these
nodes.
This document describes how GIST signalling messages traverse NATs in This document describes mechanisms that can be used in order for GIST
a way that preserves the consistency of state that is installed in signalling messages to traverse NATs in a way that preserves the
the network with respect to the data flows to which the signalling consistency of state that is installed in the network with respect to
messages refer. As the mechanisms that are described in this the data flows to which the signalling messages refer. As the
document exclusively operate at the GIST layer, they are transparent mechanisms that are described in this document exclusively operate at
to signalling applications. The document is organised as follows. the GIST layer, they are transparent to signalling applications. The
The next section introduces the terminology that is used throughout document is organised as follows. The next section introduces the
this document. Section 3 provides a detailed discussion of the NAT terminology that is used throughout this document. Section 3
traversal problem and highlights certain design decisions that have provides a detailed discussion of the NAT traversal problem and
to be taken when addressing the problem. Section 4 lists the highlights certain design decisions that have to be taken when
assumptions on which the proposed mechanisms are based. Section 5 addressing the problem. Section 4 lists the assumptions on which the
presents the proposed mechanisms for "transparent" NAT traversal, and subsequently proposed mechanisms are based. The mechanisms are
??? presents the proposed mechanisms where such protection is described in Section 5 and Section 6. Finally, Section 7 presents
required. some security issues that arise in conjunction with the mechanisms
described in this document.
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]
skipping to change at page 4, line 26 skipping to change at page 4, line 26
o GIST: General Internet Messaging Protocol for Signalling [1] o GIST: General Internet Messaging Protocol for Signalling [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: The name of the IETF working group o NSIS: Next Steps in Signalling: The name of the IETF working group
that specified the family of signalling protocols of which this that specified the family of signalling protocols of which this
specification is also a member. The term NSIS is also used to document is also a member. The term NSIS is also used to refer to
refer to this family of signalling protocols as a whole. this family of signalling protocols as a whole.
o GIST-aware: Implements GIST and MAY also implement a number of o GIST-aware: Implements GIST and MAY also implement a number of
NSLPs. NSLPs.
o GIST-unaware: GIST-unaware, does not implement any NSLP. o GIST-unaware: GIST-unaware, does not implement any NSLP. The term
is synonymous to NSIS-unaware.
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 Information o NLI.IA: Interface Address field of the Network Layer Information
header field, as defined in [1] object, as defined in [1]
o <- : Assignment operator. The quantity to the right of the o <- : Assignment operator. The quantity to the right of 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 single o [data item]: This notation indicates that "data item" is a single
identifier of a data structure. (Square brackets do not denote identifier of a data structure. (Square brackets do not denote
skipping to change at page 6, line 22 skipping to change at page 6, line 22
boundary, say from addressing space S1 to S2, have the IP addresses 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 GIST in the IP header translated from space S1 to S2 by the NAT; if GIST
payloads are not translated in a consistent manner, the MRI in a GIST payloads are not translated in a consistent manner, the MRI in a GIST
packet that crosses the boundary, e.g. from address space S1 to S2, 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 may be refers to a flow that does not exist in S2. In fact, the flow may be
invalid in S2 because at the IP address that belongs to S1 may not be invalid in S2 because at the IP address that belongs to S1 may not be
routable or invalid in S2. Moreover, the IP address of the sending 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 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 the receiving peer. The purpose of this document is to describe a
way for GIST messages to be translated in a way that is consistent way for GIST messages to be translated in a way that is consistent
with the translation that NATs apply to the IP headers of both with the translation that NATs apply to the IP headers of the data
signalling and data traffic. traffic.
A NAT may either be GIST-unaware or GIST-aware. We denote a GIST- A NAT may either be GIST-unaware or GIST-aware. We refer to a GIST-
aware NAT as a GaNAT in the sequel. A GaNAT MAY also support at aware NAT as a "GaNAT" in the sequel. A GaNAT MAY also support at
least one NSLP. Note that there exists an NSLP, namely the NATFW least one NSLP. Note that there exists an NSLP, namely the NATFW
NSLP [2], that specifically addresses NAT traversal for data flows. NSLP [2], that specifically addresses NAT traversal for data flows.
Inevitably, the NATFW NSLP also provides the necessary mechanisms for Inevitably, the NATFW NSLP also provides the necessary mechanisms for
the related signalling to traverse the NATs involved. Consider a the related signalling to traverse the involved NATs. Consider a
GaNAT that supports both the NATFW NSLP, and the NAT traversal GaNAT that supports both the NATFW NSLP, and the NAT traversal
extension to GIST that is specified in this document. Suppose now mechanism that is described in this document (which operates at the
that a GIST QUERY message arrives at this GaNAT that contains the GIST layer). Suppose now that a GIST QUERY message arrives at this
NSLP identifier (NSLPID) of the NATFW NSLP. A question that arises GaNAT that contains the NSLP identifier (NSLPID) of the NATFW NSLP.
is whether the GaNAT should use the GIST NAT traversal extension A question that arises is whether the GaNAT should use the GIST-layer
defined in this document, or the NATFW NSLP mechanism, in order to NAT traversal mechanism (described in this document), or the NATFW
provide "NAT traversal" for both the signalling message and the data NSLP mechanism, in order to provide "NAT traversal" for both the
flow to which it refers. The answer to this question is that such a signalling message and the data flow to which it refers. The answer
GaNAT MUST implement a policy according to which method is used in to this question is that a GaNAT should implement a policy according
preference to the other. Note, however, that, should the GaNAT to which one method is used in preference to the other. Note that,
prefer the GIST NAT traversal to NATFW NSLP, then it will happen, if however, if the GaNAT prefers GIST-layer NAT traversal, then it may
no on-path GaNATs exist that prefer the NATFW NSLP, that the happen, if no on-path GaNATs exist that prefer the NATFW NSLP, that
downsteam NATFW peer will be unable to discover any downstream NATFW no downstream NATFW NSLP peers are discovered. This may make the
NSLP peers. This may make the entire NATFW session obsolete. entire NATFW session obsolete. It is therefore anticipated that the
NATFW NSLP will be the preferred NAT traversal mechanism in most
circumstances.
Clearly, if a GaNAT does not implement the NATFW NSLP, then the only However, in certain cicumstances it may be desirable for GIST
way for the signalling and the data flow to traverse that GaNAT, is signalling messages to traverse a NAT, and not desirable or possible
for the necessary mechanisms to operate on the GIST layer. The same to use the NATFW NSLP for this purpose. Examples of such
holds when the NSLP that is being signalled is an NSLP other than the circumstances are the following.
NATFW NSLP. Enabling NAT traversal in presicely these circumstances
is the motivation of this specification. o GaNATs that do not implement the NATFW NSLP are on the path taken
by GIST signalling messages. This situation may arise during
incremental deployment of the signalling protocols that are
developed by the NSIS working group.
o GaNATs that implement the NATFW NSLP are on the path taken by GIST
signalling messages that refer to a given data flow. However, the
NSLP that is being signalled is *not* the NATFW NSLP and there
exists no NATFW signalling session for the data flow in question.
Describing NAT traversal for GIST signalling messages in the above
circumstances is the subject matter of this document.
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 GIST-and-NATFW-aware, some may be GIST-aware, and some may be may be GIST-and-NATFW-aware, some may be GIST-aware, and some may be
GIST-unaware. Additionally, NSLP signalling for such a data flow may GIST-unaware. Additionally, NSLP signalling for such a data flow may
be required to traverse through a subset of those NATs. Whether or be required to traverse through a subset of those NATs. Whether or
not the routing inftrastructure and state of the network causes the not the routing infrastructure and state of the network causes the
signalling for such a data flow to traverse the same NATs as the flow signalling for such a data flow to traverse the same NATs as the flow
depends, among other things, on which NSLP is being signalled. While depends, among other things, on which NSLP is being signalled. While
signalling of the QoS NSLP, for example, might not traverse any of signalling of the QoS NSLP, for example, might not traverse any of
the NATs that are traversed by the data flow, the signalling of the the NATs that are traversed by the data flow, the signalling of the
NATFW NSLP traverses at least those NATs that implement the NATFW 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 GIST QUERY/RESPONSE data path, as this coupling is defined by the GIST QUERY/RESPONSE
discovery mechanism for the "path coupled" Message Routing Method). discovery mechanism for the "path coupled" Message Routing Method).
It is desirable that the NAT traversal extension for GIST provides It is desirable that the GIST-layer NAT traversal provides NAT
NAT traversal for every possible combination of NATs, either on the traversal for every possible combination of NATs, either on the data
data or the signalling path, in a secure manner. or the signalling path, in a secure manner.
Due to the GIST 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 GIST nodes typically identify not support the required NSLP), two GIST nodes typically identify
themselves as NSLP peers only if they both implement the same NSLP. themselves as NSLP peers only if they both implement the same NSLP.
This means that, if one or more NATs that are unaware of this NSLP If one or more NATs that are unaware of this NSLP are between them,
are between them, then the two NSLP peers are not able to discover then the two NSLP peers are not able to discover each other at all.
each other at all. This is because, even in the unlikely event that This is because, even in the unlikely event that the NAT bindings
the NAT bindings that are necessary for the GIST traffic to traverse that are necessary for the GIST traffic to traverse the in-between
the in-between NAT(s) exist, the NLI.IA field included in the NAT(s) exist, the NLI.IA field included in the RESPONSE message sent
RESPONSE message sent by the downstream GIST peer is invalid (or the by the downstream peer is invalid (or the IP address is unreachable)
IP address is unreachable) in the address space of the upstream GIST in the address space of the upstream peer. In order to overcome this
peer. In order to overcome this limitation, either the two peers limitation, either the two peers need to cope with the in-between
need to cope with the in-between NAT(s), or, if the NAT(s) are NAT(s), or, if the NAT(s) are GaNATs, they (the GaNATs) need to apply
GaNATs, they (the GaNATs) need to apply additional processing in additional processing in order to transparently create and maintain
order to transparently create and maintain consistency between the consistency between the information in the header of GIST signalling
information in the header of GIST signalling messages and the messages and the information in the IP header of the data traffic.
information in the IP header of the data traffic. Additionally, if Additionally, if NSLP-aware NATs are on the data path, then these
NSLP-aware NATs are on the data path, then these NATs should process NATs should process NSLP traffic in a way the preserves consistency
NSLP traffic in a way that preserves consistency after address after address translation. This processing deviates from the
translation. This processing deviates from the processing of NSLP- processing of NSLP-aware non-NAT nodes. The following sections
aware non-NAT nodes. In the following sections we specify mechanisms describe how to overcome the limitation of two adjacent NSLP peers
that aim to overcome the limitation of two adjacent GIST peers not not being able to execute the NSLP in the presence of in-between
being able to execute an NSLP in the presence of in-between NAT(s). NAT(s).
Note that a number of different situations has to be dealt with,
depending on the 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 A number of different variations are possible, depending on the level
of NSIS support by the in-between NAT(s). The following combinations
of NATs that are located between two adjacent NSLP peers are
considered.
o all NAT(s) are (NSLP-unaware) GaNAT(s) o all NAT(s) are NSLP-unaware GaNAT(s)
o all NAT(s) are NSLP-aware 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 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 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 belong to multiple types exist on the path between two adjacent NSLP
peers, the proposed mechanisms should work in combination. Thus, peers, the proposed mechanisms should work in combination. Thus,
traversal of multiple NATs of different types should not require traversal of multiple NATs of different types should not require
further specification from a functional perspective. However, further specification from a functional perspective. However,
security issues that arise due to the combination of NAT types may security issues that arise due to the combination of NAT types may
have to be considered. have to be considered.
A GIST-unaware NAT cannot tell data and signalling traffic apart. A GIST-unaware NAT cannot tell data and signalling traffic apart.
The installation of the NAT binding for the signalling traffic in The installation of the NAT binding for the signalling traffic in
such a NAT occurs typically independently from the installation of such a NAT occurs typically independently from the installation of
the NAT binding for the data traffic. Furthermore, as the NAT cannot the NAT binding for the data traffic. Furthermore, as the NAT cannot
associate the signalling and the data traffic in any way, it cannot associate the signalling and the data traffic, it cannot indicate
indicate that an association exists between the two NAT bindings. that an association exists between the two NAT bindings. Therefore,
Therefore, in the presence of such a NAT, GIST nodes that are located in the presence of such a NAT, non-NAT GIST nodes that are located on
on either side of the NAT have to cope with the NAT without either side of the NAT have to cope with the NAT without assistance
assistance from the NAT. This would typically require initially from the NAT. This would typically require initially discovering the
discovering the NAT and subsequently establishing an association NAT and subsequently establishing an association between between the
between between the MRI in the signalling messages and the translated MRI in the signalling messages and the translated IP header in the
IP header in the data traffic. Due to the variety of behaviours that data traffic. Due to the variety of behaviours that a GIST-unaware
a GIST-unaware NAT may exhibit, establishing this association is a NAT may exhibit, establishing this association is a non-trivial task.
non-trivial task. Therefore, traversal of such (i.e. GIST-unaware) Therefore, traversal of such (i.e. GIST-unaware) NATs is considered
NATs is considered a special case and is further discussed in a special case and is outside the scope of this version of this
Section 7. document.
Traversal of GaNAT(s) is comperatively more straightforward. This is Traversal of GaNAT(s) is comparatively more straightforward. This is
because, based on the MRI in a given incoming GIST message, a GaNAT 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 can identify the data flow to which the message refers. It can then
check its NAT binding cache and determine the translation that is 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 (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 the IP header of the data flow. The GaNAT can then include
sufficient information about this translation into the signalling sufficient information about this translation into the signalling
message, such that its receiver (i.e. the GIST peer that receives the message, such that its receiver (i.e. the GIST peer that receives the
data traffic after network address translation has been applied) can data traffic after network address translation has been applied) can
map the signalling message to the data flow. map the signalling message to the data flow.
There exist a variety of ways for a GaNAT to encode the There exist a variety of ways for a GaNAT to encode the above-
abovementioned information into signalling messages. In this mentioned information into signalling messages. In this document the
document the following two ways are considered. following two ways are considered.
1. Non-transparent apprach: The GaNAT includes an additional "NAT 1. Non-transparent approach: The GaNAT includes an additional "NAT
Traversal" payload (see section A.3.8 of [1]) into the GIST Traversal" payload (see section A.3.8 of [1]) into the GIST
header of the GIST QUERY message. This "NAT Traversal" payload header of the GIST QUERY message. This "NAT Traversal" payload
is echoed by the GIST responder on the other side of the NAT. 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 The responder (which is assumed to be located on the "other side"
of the NAT) uses the information in this payload in order to map
subsequent signalling messages to the data flows they refer to. subsequent signalling messages to the data flows they refer to.
2. Transparent approach: The GaNAT replaces GIST header fields in a 2. Transparent approach: The GaNAT replaces GIST header fields in a
way that is consistent with the translation it applies to the way that is consistent with the translation it applies to the
data traffic, as necessary. The GaNAT does this GIST QUERY and data traffic, as necessary. The GaNAT does this for GIST QUERY
RESPONSE messages, for D-mode as well as for C-mode messages and RESPONSE messages, for D-mode as well as for C-mode messages
throughout the duration of the signalling session. throughout the duration of the signalling session.
The second approach being "transparent" means that a GaNAT that The second approach being "transparent" means that a GaNAT that
follows this approach remains completely transparent to the GIST follows this approach remains completely transparent to the GIST
peers that are located either side of it. Thus, this approach works 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 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 GIST (as described in [1]). Unfortunately though, the transparent
transparent approach does not work if the GaNAT is NSLP-unaware and approach does not work if the signalling traffic is to be
if signalling traffic is to be cryptographically protected between cryptographically protected between the two GIST peers that are
the two GIST peers that are located either side of the GaNAT. If, located either side of the GaNAT, and the GaNAT is NSLP-unaware. If,
however, the GaNAT is NSLP-aware, then cryptographic protection is however, the GaNAT is NSLP-aware, then cryptographic protection is
terminated at the GaNAT (i.e. the GaNAT is a GIST peer itself). In 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 this scenario, it is clearly preferable for the GaNAT to follow the
transparent approach, rather than to include a NAT Traversal object. transparent approach, rather than to include a NAT Traversal object.
Thus, if a GaNAT acts as a GIST peer for a signalling session, it 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. MUST follow the transparent approach, as described in Section 5.3.
However, due to the fact that the transparent approach does not work However, due to the fact that the transparent approach does not work
if signalling is to be cryptographically protected, a GaNAT MUST also if signalling is to be cryptographically protected, a GaNAT MUST also
implement the non-transparent approach (for the case where an NSLP is implement the non-transparent approach (for the case where an NSLP is
signalled that the GaNAT does not support), unless the GaNAT is going signalled that the GaNAT does not support), unless the GaNAT is going
to be used only in deployments where cryptographic protection of to be used only in deployments where cryptographic protection of
signalling traffic is not a requirement. signalling traffic is not a requirement.
Note that a GaNAT MAY implement both approaches. If such a GaNAT is Note that a GaNAT MAY implement both approaches. If such a GaNAT is
NSLP-unaware, it can then adopt the correct behaviour, based on NSLP-unaware, it can then adopt the desired behaviour, based on
whether or not cryptographic protection is required for the whether or not cryptographic protection is required for the
signalling traffic between two GIST peers. If such protection is signalling traffic between two GIST peers. If such protection is
required, the GaNAT MUST adopt the mechanisms that follow the non- required, the GaNAT MUST adopt the mechanisms that follow the non-
transparent approach; if it is not, it MAY follow the mechanisms transparent approach; if it is not, it MAY follow the mechanisms
implementing the transparent approach. The GaNAT can tell whether or implementing the transparent approach. The GaNAT can tell whether or
not cryptographic protection is required from the stack proposals not cryptographic protection is required from the stack proposal in
that are exchanged in the GIST QUERY and RESPONSE messages; inclusion the GIST QUERY and RESPONSE messages; inclusion of IPsec or TLS
of IPsec or TLS proposals amounts to cryptographic protection being proposals amounts to cryptographic protection being required.
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. assumptions.
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
an NSLP. an NSLP. If this is not the case, then the NSLP has to provide
additional mechanisms for the traversal of (Ga)NATs. These
mechanisms must be compatible the mechanisms described in this
document. Note that the NATFW NSLP is an exception to this rule
in that it does not need to be compatible with the mechanisms
described in this document. This is because the GIST-layer NAT
traversal mechanisms described in this document and the NATFW
NSLP are mutually exclusive (i.e. it is not permissible that a
given (Ga)NAT applies both GIST-layer NAT traversal and NATFW
NSLP processing to the messages that belong to the same
signalling session).
2. The path taken by the signalling traffic between those GIST 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 a 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 GIST peers, as far as the in-between GaNATs are concerned. two GIST peers, as far as the in-between GaNATs are concerned.
That is, we assume that signalling traffic traverses the same That is, we assume that signalling traffic traverses the same
GaNAT(s) 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 GIST peers * The NSIS state that is installed at the two GIST peers
expires. expires.
skipping to change at page 11, line 37 skipping to change at page 11, line 47
refreshed using a GIST QUERY. refreshed using a GIST QUERY.
* A new GIST 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 decide to act as GIST peers. the data traffic at nodes that decide to act as GIST peers.
Thus, under "normal" path coupled signalling, it is not an error Thus, under "normal" path coupled signalling, it is not an error
condition (e.g. a reason to trigeer a "route change"), for condition (e.g. a reason to trigger a "route change"), for
example, if the set of on-path nodes, which do not act as GIST 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. 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 GIST QUERY/RESPONSE procedure is executed. next GIST QUERY/RESPONSE procedure is executed.
+-----+ +-----+
+----+GaNAT|-----+ +----+GaNAT|-----+
| | A | | | | A | |
skipping to change at page 12, line 32 skipping to change at page 12, line 33
been setup between the two adjacent GIST peers 1 and 2 and that both been setup between the two adjacent GIST peers 1 and 2 and that both
signalling and data traffic follows the path GIST peer 1 -> IP router signalling and data traffic follows the path GIST peer 1 -> IP router
-> GaNAT A -> IP router -> GIST peer 2. Suppose now that, after some -> GaNAT A -> IP router -> GIST peer 2. Suppose now that, after some
time, GIST peer 1 decides to set up a C-mode connection with peer 2. time, 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 Suppose moreover that the left IP router decides to forward 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 GIST peer 1 -> IP signalling traffic now follows the alternative path GIST peer 1 -> IP
router -> GaNAT B -> IP router -> GIST peer 2. Note that this change router -> GaNAT B -> IP router -> GIST peer 2. Note that this change
in forwarding between the two adjacent GIST peers does not trigger a in forwarding between the two adjacent GIST peers does not trigger a
"route change" at the GIST layer because (a) it does not necessarily "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 necassarily destroy the adjacency of peer 1 and 2 and (b) it does not necessarily
destroy the coupling of the path taken by signalling traffic to that destroy the coupling of the path taken by signalling traffic to that
taken by data traffic (at GIST nodes). Nevertheless, assumptions (3) taken by data traffic (at GIST nodes). Nevertheless, assumptions (3)
and (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 mechanisms described in this document such a situation occurs, the mechanisms described in this document
may still work as state expires after a certain timeout period. may still work as state expires after a certain timeout period.
If assumption (1) does not hold, the NSLP has to provide additional Assumptions (2), (3) and (4) hold if, at an addressing boundary, only
mechanisms for the traversal of (Ga)NATs. These mechanisms must be one NAT exists. Due to security and management reasons, this is
compatible with the mechanisms employed by GIST. Assumptions (2), likely to be the case in many settings.
(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. Transparent NAT traversal for GIST 5. Transparent NAT traversal for GIST
This section describes the operation of GaNATs that implement the This section describes the operation of GaNATs that implement the
transparent approach listed in Section 3. Note that the GaNAT may transparent approach listed in Section 3. An NSLP-aware GaNAT MUST
follow this approach only if it is unaware of the NSLP that is being follow this approach, as described in Section 5.3. An NSLP-unaware
signalled, and when no cryptographic protection of signalling data is GaNAT MAY follow this approach, as described in Section 5.1 and
requested by the two NSLP peers. Section 5.2, only if 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 two types of NSLP-unaware GaNAT have to be dealt with,
are located at the NSIS initiator (NI-side), and those that are namely those that are located at the NSIS initiator (NI-side), and
located at the NSIS responder (NR-side). This distinction arises due those that are located at the NSIS responder (NR-side). This
to the fact that NI-side and NR-side GaNATs obtain the destination IP distinction arises due to the fact that NI-side and NR-side GaNATs
address for forwarded packets in different ways. obtain the destination IP address of the downstream GIST peer in
different ways.
5.1. NI-side NSLP-unaware GaNATs 5.1. NI-side NSLP-unaware GaNATs
This section describes the "transparent" operation of an NI-side, This section describes the "transparent" operation of an NI-side,
NSLP-unaware GaNAT. 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 GIST 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 GIST QUERY. In this case is not supported, and if P is identified as a GIST QUERY, the
the GaNAT performs the following. GaNAT performs the following.
1. We denote P as GQ. It looks at the stack proposal ST in GQ. 1. We denote P by GQ. The GaNAT looks at the stack proposal in
If it indicates that cryptographic protection is required, GQ. If it includes a proposal with cryptographic protection,
the mechanism that is applies is the one described in ???. the mechanism that is applied is the one described
Section 6.1.
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 + 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
port numbers, etc) are translated according to this NAT port numbers) are translated according to this NAT
binding. We denote [IP header].SourceIPAddress used on binding. We denote the source IP address of translated
the downstream link as IPGaNATds, and the source port data packets by IPds, and their [Transport layer
number used to forward the data traffic as SPNDTGaNATds. header].SourcePort by SPDTds.
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, + If no matching entry is found, the GaNAT determines, based
based on its routing table, the link on which packets on its routing table, the link on which packets that match
that match GQ.MRI (excluding GQ.MRI.SourceIPAddress) GQ.MRI (excluding GQ.MRI.SourceIPAddress) would be
would be forwarded. We call this link the "downstream forwarded. We call this link the "downstream" link.
link". Then, the GaNAT acquires an IP address for itself Then, the GaNAT acquires an IP address and source port for
on the downstream link. (This address could be dynamic itself on the downstream link, denoted by IPds and SPDTds
or static.) This address will be used to forward both respectively. This address and port could be dynamic or
signalling and data traffic on the downstream link. If static, and will be used (among other things) for the
it also performs port translation, the GaNAT also installation of a NAT binding for the data traffic in the
acquires a source port number for the data traffic on the future.
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.
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 4. The GaNAT aquires a source port number for the version of the
different source port number to the signalling traffic, GIST QUERY that will be forwarded over the downstream link.
is to enable the GaNAT to demultiplex (i.e. forward to We denote this port by SPSTds. (There is no requirement that
the correct internal address) the signalling responses SPSTds must be different from GQ.[UDP Header].SourcePort.)
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 GIST
session 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 GIST QUERY packet GQ', as follows. 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
the downstream direction. Of course, a GaNAT does not need
to actually change the source port of signalling traffic; it
can always use SPSTds the same port as in the incoming
packet. Such a GaNAT may use the GIST session ID in order to
demultiplex (i.e. forward to the correct internal address)
the traffic that arrives from the downstream direction. It
is unclear which of the two approaches is preferable.
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 <- IPds
3. GQ'.MRI.SourcePortNumber <- SPNDTGaNATds 3. GQ'.MRI.SourcePortNumber <- SPDTds
4. GQ'.[IP header].SourceIPAddress <- IPGaNATds 4. GQ'.[IP header].SourceIPAddress <- IPds
5. GQ'.[UDP HEADER].SourcePort <- SPNSTGaNATds 5. GQ'.[UDP header].SourcePort <- SPSTds
6. GQ'.NLI.IA <- IPds
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, 6. 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. 7. It forwards GQ' on the downstream link.
2. Otherwise, if P carries an [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 GIST 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 by 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 GQ' is said
to match a GQ' if they carry the same cookie value. If none to match a GR 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 fail, GR is discarded.
constructs a new GIST response GR', as follows. Otherwise, the GaNAT 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
matches the received GR. that matches the received GR.
3. GR'.[IP header].SourceIPAddress <- IPGaNATus, where 3. GR'.[IP header].SourceIPAddress <- IPus, where IPus is an
IPGaNATus = GQ.[IP header].DestinationIPAddress. IP address that is bound to the upstream link.
4. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA 4. GR'.[IP header].DestinationIPAddress <- GQ.NLI.IA
5. GP'.S <- true. 5. GR'.[UDP header].DestinationPort <- GQ.[UDP
header].SourcePort
6. It inspects the stack proposals in GR' and the 6. GR'.NLI.IA <- IPus
corresponding GQ' to see if the upstream GIST peer has a
choice of more than one possible stack. If such a choice 7. GR'.S <- true
exists, the GaNAT removes as many stack proposals from
GR' as necessary, until only one stack can be chosen by 8. The GaNAT inspects the Stack-Configuration-Data object in
the upstream peer for the messaging association. We GR' and the corresponding GQ' in order to check whether
denote this stack as ST. The GaNAT remembers this ST and or not the upstream NSLP peer can select one of multiple
its association with GQ, GQ', GR, GR'. We say that, in transport layer protocol/destination port number
this case, the GaNAT "installs" the ST. combinations for the establishment of a messaging
association. If multiple choices exist, the GaNAT
invalidates as many transport layer protocol/port number
combination proposals from GR' as necessary, until the
upstream NSLP peer can only initiate the establishment of
a messaging association with the downstream NSLP peer
using a single transport layer protocol/destination port
number combination. This invalidation is done by setting
the D-flag in those MA-Protocol-Options fields that carry
the port number proposals that are to be invalidated.
Note that, by setting the D-flag in a particular MA-
Protocol-Option field, the GaNAT may also invalidate the
associated transport layer protocol and security (e.g.
TLS) proposal. The actions of the GaNAT MUST NOT result
in the strongest, in terms of security, proposal to be
invalidated. In the end, the NAT will expect the
upstream NSLP peer to use a particular combination of
transport layer protocol and destination port (and
possibly other details that are associated with the valid
proposal) for the establishment of the messaging
association. We call this combination the "stack
proposal expected by the NAT" and denote it by ST. The
GaNAT remembers this ST, its association with GQ, GQ',
GR, GR', and the upstream and downstream links. By doing
so, the GaNAT is said to "install" 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
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.MRI.DestinationIPAddress, header].DestinationIPAddress=GQ.MRI.DestinationIPAddress,
+ K.[IP header].Protocol=GQ.MRI.Protocol, and + K.[IP header].Protocol=GQ.MRI.Protocol, and
+ K.[TCP/UDP header].SourcePort=GQ.MRI.SourcePort + K.[Transport layer header].PortNumbers=GQ.MRI.PortNumbers
should be forwarded on the downstream link, with [IP should be forwarded on the downstream link, with [IP
header].SourceIPAddress = IPGaNATds. header].SourceIPAddress = IPds and [Transport layer
header].SourcePort=SPDTds".
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 GIST session refers, is a separate flow for to which this GIST session refers, is a separate flow for
which, depending 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. Moreover, security
arise when traffic, for which no signalling exists, is issues may arise when traffic, for which no signalling
allowed to traverse a GaNAT. exists, is 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 GIST signalling binding that was established as a result of GIST signalling
should remain in place for as long as the associated GIST should remain in place for as long as the associated GIST
state in the GaNAT remains valid. If GIST signalling refers state in the GaNAT remains valid. If GIST signalling refers
to a NAT binding that already exists, then the timeout of the to a NAT binding that already exists, then the timeout of the
NAT binding should occur according to the NAT policy, in a NAT binding should occur according to the NAT policy, in a
manner independent from GIST processing. (If signalling manner independent from GIST processing. (If signalling
persists after the deletion of a NAT binding, then the NAT persists after the deletion of a NAT binding, then the NAT
binding may be re-installed and then timed out together with binding may be re-installed and then timed out together with
GIST state). 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 carries the transport protocol and port numbers GaNAT, and if P carries the transport protocol and destination
indicated by some stack proposal ST that has previously been port number indicated by some stack ST that has previously been
installed by the GaNAT, and if P has arrived on either the installed by the GaNAT, and if P has arrived on either the
upstream or the downstream interface that is associated with ST, upstream or the downstream interface that is associated with ST,
then P is said to "match" ST. For such a packet, the GaNAT does then P is said to "match" ST. For such a packet, the GaNAT does
the following. If P is expected to contain a GIST header, then the following. If P is expected to contain a GIST header, then
the GaNAT check whether or not the bits where the GIST header is the GaNAT checks whether or not the bits where the GIST header is
expected, consitute a valid GIST header. If not, P is silently expected, constitute a valid GIST header. If they do not, P is
discarded. Otherwise, the GaNAT constructs an outgoing packet P' silently discarded. If all is in order, the GaNAT constructs an
as follows (the variables used below refer to those stored outgoing packet P' as follows (the variables used below refer to
together with ST). those stored in association 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 <- IPds
2. P'.MRI <- GQ'.MRI 2. P'.[IP header].DestinationIPAddress <- GR.NLI.IA
3. P'.NLI.IA <- IPGaNATus 3. P'.MRI <- GQ'.MRI
4. The GaNAT forwards P' on the downstream link. 4. P'.NLI.IA <- IPds
5. The GaNAT forwards P' on the downstream link.
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 <- IPus
2. P'.MRI <- GQ.MRI 2. P'.[IP header].DestinationIPAddress <- GQ.NLI.IA
3. P'.NLI.IA <- IPGaNATus 3. P'.MRI <- GQ.MRI
4. The GaNAT forwards P' on the upstream link. 4. P'.NLI.IA <- IPus
5. The GaNAT forwards P' on the upstream link.
Note that the GaNAT can determine the location in a packet Note that the GaNAT can determine the location in a packet
where a GIST header is expected. If, for example, the packet where a GIST header is expected. If, for example, the packet
is a UDP packet, then the GIST header should follow is a UDP packet, then the GIST header should follow
immediately after the UDP header. If the packet is a TCP immediately after the UDP header. If the packet is a TCP
packet, then the GaNAT can determine the location where the packet, then the GaNAT can determine the location where the
GIST heaer should start by counting the number of NSLP GIST header should start by counting the number of NSLP
payload bits that followed the end of the previous GIST payload bits that followed the end of the previous GIST
header. The start of the next GIST header is expected at the header. The start of the next GIST header is expected at the
position where the previous GIST message, including NSLP position where the previous GIST message, including NSLP
payload, ends. The GaNAT can tell where this message ends payload, ends. The GaNAT can tell where this message ends
from the LENGTH field inside the previous GIST header. It from the LENGTH field inside the previous GIST header. It
should be noted here that, in order to correctly count the should be noted here that, in order to correctly count the
bits, the GaNAT may have to keep track of TCP sequence bits, the GaNAT may have to keep track of TCP sequence
numbers, and thereby be aware of the correct ordering of numbers, and thereby be aware of the correct ordering of
packets. However, the GaNAT only has to keep buffers that packets. However, the GaNAT only has to keep buffers that
are as long as the LENGTH field inside the previous GIST are as long as the LENGTH field inside the previous GIST
header (and possibly up to one MTU size more than that). header (and possibly up to one MTU size more than that).
Also note that some TCP packets P may not be expected to Also note that some TCP packets P may not be expected to
contain any GIST header (this happens when the NSLP payload contain any GIST header (this happens when the NSLP payload
from a previous packet stretches over several packets). For from a previous packet stretches over several packets). For
those packets, the GaNAT only applies the transformation in those packets, the GaNAT only applies the transformation in
the IP header. Finally, note that a GIST header may start a the IP header. Finally, note that a GIST header may start a
packet but finish in another. If such a packet is received packet but finish in another. If such a packet is received,
by the GaNAT, it MUST buffer the entire packet, until the the GaNAT MUST buffer that packet, until the packet is
packet is received where the GIST header completes. It can received where the GIST header completes. It can then apply
then apply the required processing and forward both packets. 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 subjected to normal NAT processing. That is, P
is either silently discarded or it causes the installation of a
(data) NAT binding.
Brief discussion of the algorithm: The fact that the GaNAT replaces Brief discussion of the algorithm: The fact that the GaNAT replaces
the NSLP peer's NLI.IA with its own IP address (in both directions), the NSLP peers' NLI.IA with its own IP address (in both directions),
causes the two GIST peers to send subsequent signalling messages to causes the GIST peers to send subsequent signalling messages to the
the GaNAT, in the belief that they talk to the their adjacent peer. GaNAT, in the belief that they talk to their adjacent NSLP peer. The
The GaNAT transparently forwards the signalling traffic and GaNAT transparently forwards the signalling traffic and appropriately
appropriately translates the fields in the GIST header, in a way that translates the fields in the GIST header, in a way that is consistent
is consistent with the translation it applies to the data traffic. with the translation it applies to the data traffic.
Note that, according to this mechanism, the size of an outgoing GIST Note that, according to this mechanism, the size of outgoing GIST
message is always the same as the size of its corresponding incoming messages is always the same as the size of corresponding incoming
GIST message. Finally note that the MRI that the NR sees indicates GIST messages. Also note that the MRI that the NR sees indicates as
as destination address the IP address of the DR (as expected), but 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 source address it sees indicates the IPds of the GaNAT that is
closest to the NR. closest to the NR.
5.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 GIST peers, a priori knows a side GaNAT that is in between two GIST peers, a priori knows a
routable IP address of the downstream GaNAT. The last GaNAT of this routable IP address of the next downstream GaNAT. The last GaNAT of
chain is assumed to know the IP address of the DR. In order to 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, 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 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 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 know the IP address of the DR. A given GaNAT that knows such an
address, in effect anticipates to receive a signalling message from address, in effect anticipates to receive a signalling message from
the upstream direction that refers to a data flow that terminates in the upstream direction that refers to a data flow that terminates in
a downstream node. In other words, such a GaNAT may typically have 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 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 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 the chain, the address of the DR) the "pending" IP address and denote
following description it is denoted by IPNext. How IPNext is made it by IPNext. The GaNAT may also have a destination port associated
known to each GaNAT (e.g. how the NAT binding for the data traffic is with IPNext. If IPNext is derived from an existing data traffic NAT
installed in the GaNAT) is outside the scope of this document. binding, then this port is typically the destination port after
translation from that binding. This port, if known, is denoted
PortNext. How IPNext and PortNext are 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+--+ GIST +---+GaNAT+---+GaNAT+---+GaNAT+---+ GIST +--+NR+--+DR| +NI+--+ NSLP +---+GaNAT+---+GaNAT+---+GaNAT+---+ NSLP +--+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 GIST peer 1) to be between NI and NSLP peer 1)
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 GIST header with the NSLP ID 1. If P has a RAO followed by the GIST header with the NSLP ID
indicates an unsupported NSLP, it is identified as a GIST QUERY. indicates an unsupported NSLP, and if it is identified as a GIST
In this case the GaNAT does the following. QUERY, the GaNAT does the following.
1. We denote P as GQ. The GaNAT looks at the stack proposal ST 1. We denote P by GQ. The GaNAT looks at the stack proposal in
in GQ. If it indicates that cryptographic protection is 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 GIST QUERY is 3. The GaNAT determines whether or not this GIST QUERY is
anticipated, i.e. if a pending IPNext exists that matches anticipated, i.e. if a pending IPNext (and possibly PortNext)
this GIST QUERY. A pending IPNext is said to "match" a GIST exists that matches this GIST QUERY. A pending IPNext is
QUERY, if [this condition is an open issue!] If no pending said to "match" a GIST QUERY, if [this condition is an open
IPNext is also matching, P is discarded (it is a question issue!] If no pending IPNext is matching, P is discarded (it
whether or not an error message should be sent). Otherwise, is a question whether or not an error message should be
additional checks may be performed (e.g. a DSInfo object may sent). Otherwise, additional checks may be performed (e.g.
have to be checked against the GQ). If these checks fail, P something like a DSInfo object may have to be checked against
is discarded. Otherwise, the GaNAT performs the following. 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 IP and transport layer headers of the data
port numbers, etc) are translated according to this NAT flow are translated according to this NAT binding. Note
binding. We denote [IP header].SourceIPAddress used on that the [IP header].DestinationIPAddress and [Transport
the downstream link as IPGaNATds, and the source port layer header].DestinationPort of this NAT binding should
number as SPNDTGaNATds. Note that the [IP be equal to IPNext and PortNext respectively. If they are
header].DestinationIPAddress of this NAT binding should be not, this should be handled as an auditive error
equal to IPNext. If it is not, this should be handled as condition.
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 + 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 (excluding GQ.MRI.SourceIPAddress and where
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
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 GIST QUERY packet GQ', as follows. 5. 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 a UDP source port
number for the version of the GIST QUERY that will be
forwarded to the downstream direction. We denote the
acquired IP address and source port number by IPds SPSTds
respectively. The GaNAT then constructs a new GIST QUERY
packet GQ', as follows.
1. GQ' <- GQ 1. GQ' <- GQ
2. GQ'.MRI.SourceIPAddress <- IPGaNATds 2. GQ'.MRI.DestinationIPAddress <- IPNext.
3. GQ'.MRI.DestinationIPAddress <- IPNext.
4. GQ'.MRI.SourcePort <- SPNDTGaNATds. 3. GQ'.MRI.DestinationPort <- PortNext.
5. GQ'.[IP header].SourceIPAddress <- IPGaNATds 4. GQ'.NLI.IA <- IPds.
6. GQ'.[UDP HEADER].SourcePort <- SPNSTGaNATds 5. GQ'.[IP header].SourceIPAddress <- IPds.
7. GQ'.[IP header].Destination_IP_Address <- IPNext 6. GQ'.[IP header].DestinationIPAddress <- IPNext.
8. GQ'.NLI.IA <- IPGaNATds. 7. GQ'.[UDP header].SourcePort <- SPSTds.
9. GQ'.S <- true 8. 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 The remaining steps of the algorithm are analogous to the
corresponding steps of the algorithm executed by NSLP-unaware, NI- corresponding steps of the algorithm executed by NSLP-unaware, NI-
side GaNATs, which was described in Section 5.1. side GaNATs, which was described in Section 5.1.
5.3. NSLP-aware GaNATs 5.3. NSLP-aware GaNATs
The difference of NSLP-aware GaNATs and NSLP-unaware GaNATs is that The difference of NSLP-aware GaNATs and NSLP-unaware GaNATs is that
the former perform NSLP processing in addition to the processing of the former perform NSLP processing in addition to the processing of
the NSLP-unaware GaNATs. Another way to see this is by observing the NSLP-unaware GaNATs. Another way to see this is by observing
that NSLP-aware GaNATs should provide an "MRI translation service" that NSLP-aware GaNATs should provide an "MRI translation service"
(MRITS) in addition to normal GIST and NSLP processing. The (MRITS) in addition to normal GIST and NSLP processing. The MRITS
motivation behind the MRITS is for GIST to hide from the NSLP that operates at the GIST layer. The motivation behind this is to hide
signalling messages traverse an addressing boundary. In other words, from the NSLP that signalling messages traverse an addressing
the purpose of the MRITS is to make the NSLP believe that it is boundary. In other words, the purpose of the MRITS is to make the
operating in a single IP addressing space. When and how the MRITS is NSLP believe that it is operating in a single IP addressing space.
invoked for a particular packet depends on (i) the direction of the When and how the MRITS is invoked for a particular packet depends on
packet (i.e. downstream or upstream) and (ii) the location of the (i) the direction of an incoming message (i.e. downstream or
GaNAT (i.e. NI-side or NR-side). It should also be noted that upstream) and (ii) the location of the GaNAT (i.e. NI-side or NR-
certain NSLP layer tasks must be carried out in consistency with the side). It should also be noted that certain NSLP layer tasks must be
placement of the MRITS. This is to prevent events triggered by the carried out in consistency with the placement of the MRITS. This is
NSLP to cause installation of inconsistent state. In order to to prevent events triggered by the NSLP to cause installation of
clarify this, consider the scenario of the QoS NSLP running in a inconsistent state. In order to clarify this, consider the scenario
GaNAT that operates according to the mechanisms described in this of the QoS NSLP running in a GaNAT that operates according to the
section. Since the GaNAT only presents a single addressing space to mechanisms described in this section. Since the GaNAT only presents
the NSLP (say, the internal addressing space), the packet classifier a single addressing space to the NSLP (say, the internal addressing
of the GaNAT's QoS provisioning subsystem should classify packets space), the packet classifier of the GaNAT's QoS provisioning
based on internal addresses only (i.e. it should first translate subsystem should classify data packets based on internal addresses
packets that carry external addresses and then classify them). only (i.e. it should first translate packets that carry external
Whether the MRITS presents internal-only or external-only addresses addresses and then classify them). Whether the MRITS presents
to the NSLP is not significant, as long as NSLP layer operations are internal-only or external-only addresses to the NSLP is not
carried out consistently. In the remainder of this section we significant, as long as NSLP layer operations are carried out
present the case where internal addresses are presented to the NSLP. 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 GIST packets that carry an The MRITS is obviously invoked only on GIST packets that carry an
NSLP identifier that corresponds to an NSLP that the GaNAT actually NSLP identifier that corresponds to an NSLP that the GaNAT
supports. Also, for non-GIST packets, normal NAT behaviour applies. implements. For non-GIST packets, normal NAT behaviour applies.
Although the MRITS is part of GIST processing, in order to clarify Although the MRITS is part of GIST processing, in order to clarify
our discussion, we view it as a somewhat separate processing step the exposition, we view it as a somewhat separate processing step
(i.e. like a subroutine). For NI-side, NSLP-aware GaNATs, it holds (i.e. like a subroutine) that is executed in addition to GIST, as
this is specified in [1]. For NI-side, NSLP-aware GaNATs, it holds
that that
o for a GIST/NSLP packet that is to be forwarded on the downstream 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 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 has been processed by the NSLP and before it is given to GIST, and
o for a GIST/NSLP packet that is received on the downstream link, o for a GIST/NSLP packet that is received on the downstream link,
the MRITS is invoked after GIST processing and before the packet the MRITS is invoked after GIST processing and before the packet
is given to the NSLP. is given to the NSLP.
The converse holds for NR-side NSLP-aware GaNATs. In particular, The converse holds for NR-side NSLP-aware GaNATs. In particular,
skipping to change at page 22, line 33 skipping to change at page 23, line 20
+----------------+ +----------------+ +----------------+ +----------------+
| +------+ | | +------+ | | +------+ | | +------+ |
| | NSLP | | | | NSLP | | | | NSLP | | | | NSLP | |
| +-+---++ | | +-+--+-+ | | +-+---++ | | +-+--+-+ |
| | | | | | | | | | | | | | | |
| | +-+---+ | | +----++ | | | | +-+---+ | | +----++ | |
| | |MRITS| | | |MRITS| | | | | |MRITS| | | |MRITS| | |
| | +---+-+ | | ++----+ | | | | +---+-+ | | ++----+ | |
| | | | | | | | | | | | | | | |
| +-+-----+-+ | | ++------+-+ | | +-+-----+-+ | | ++------+-+ |
| | GIST | | | | GIST | | | | 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
NSLP-aware NSLP-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 the NSLP the impression The reason for this construction is to give the NSLP the impression
that it works only with flows that originate and terminate in the that it works only with flows that originate and terminate in the
internal address space. We now describe the operation of the MRITS internal address space. We now describe the operation of the MRITS
and GIST in NSLP-aware GaNATs. An NI-side NSLP-aware GaNAT operates and GIST in NSLP-aware GaNATs. An NI-side NSLP-aware GaNAT operates
according to the following rules. according to the following rules.
1. When the NSLP asks for a message to be sent towards the 1. When the NSLP asks for a message to be sent towards the
downstream GIST peer, the MRITS does the following (IPGaNATds and downstream GIST peer, the MRITS does the following (IPds and
SPNDTGaNATds are obtained similarly to the case of an NSLP- SPDTds are obtained similarly to the case of an NSLP-unaware
unaware GaNAT). GaNAT).
1. MRI.SourceIPAddress <- IPGaNATds 1. MRI.SourceIPAddress <- IPds
2. MRI.SourcePort <- SPNDTGaNATds 2. MRI.SourcePort <- SPDTds
2. Additionally, GIST performs the following on the resulting packet 2. Additionally, GIST performs the following on the resulting packet
before it is forwarded on the downstream link (SPNSTGaNATds is before it is forwarded on the downstream link (SPSTds is obtained
obtained similarly to the case of an NSLP-unaware GaNAT). similarly to the case of an NSLP-unaware GaNAT).
1. [IP header].SourceIPAddress <- IPGaNATds
2. [UDP/TCP header].SourcePort <- SPNSTGaNATds 1. [IP header].SourceIPAddress <- IPds
2. [UDP/TCP header].SourcePort <- SPSTds
3. NLI.IA <- IPGaNATds 3. NLI.IA <- IPds
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 the NSLP 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 <- SPDTus, where IPflow is the IP address of
address of the DS (as seen by the GaNAT) and SPNDTGaNATus is the DS (as seen by the GaNAT) and SPDTus is the destination
the destination port number used in the original MRI. port number used in the original MRI.
4. If, after NSLP processing, a message is to be forwarded on the 4. If, after NSLP processing, a message is to be forwarded on the
upstream link, GIST 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 <- IPus
2. [IP header].DestinationIPAddress <- IPpeer 2. [IP header].DestinationIPAddress <- IPpeer
3. NLI.IA <- IPGaNATus 3. NLI.IA <- IPus
4. S <- true, where IPGaNATus is the GaNATs IP address for the 4. S <- true, where IPus is the GaNATs IP address for the
upstream link, IPpeer is the IPaddress of the NI (or the next upstream link, IPpeer is the IP address of the NI (or the
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 (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 IPus and IPpeer from
previous communications and in cooperation with GIST. previous communications and in cooperation with GIST.
[Issue: how exactly should IPGaNATus, IPpeer and IPflow be [Issue: how exactly should IPus, 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 NSLP-aware GaNAT operates according to the following An NR-side NSLP-aware GaNAT operates according to the following
rules. 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 the NSLP is notified. the following, before the NSLP is notified.
1. P.MRI.SourceIPAddress <- IPGaNATds 1. P.MRI.SourceIPAddress <- IPds
2. P.MRI.DestinationIPAddress <- IPNext, where IPGaNATds is the 2. P.MRI.DestinationIPAddress <- IPNext, where IPds 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 NSLP processing, a message is to be forwarded on the 2. If, after NSLP processing, a message is to be forwarded on the
downstream link, GIST 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 <- IPds
2. [IP header].DestinationIPAddress <- IPNext 2. [IP header].DestinationIPAddress <- IPNext
3. NLI.IA <- IPGaNATds 3. NLI.IA <- IPds
4. S <- true, where IPGaNATds is the GaNATs IP address for the 4. S <- true, where IPds 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 the NSLP asks for a message to be sent towards the upstream 3. When the NSLP asks for a message to be sent towards the upstream
GIST peer, the MRITS does the following. 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 <- IPus
4. Additionally, GIST performs the following on the resulting packet 4. Additionally, GIST performs the following on the resulting 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 <- IPus
2. [IP header].DestinationIPAddress <- IPpeer 2. [IP header].DestinationIPAddress <- IPpeer
3. NLI.IA <- IPGaNATus 3. NLI.IA <- IPus
4. S <- true, where IPGaNATus is the GaNATs IP address for the 4. S <- true, where IPus 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 IPus and IPpeer fields from previous communications
communications and in cooperation with GIST. [question: how and in cooperation with GIST. [question: how exactly should
exactly should IPGaNATus and IPpeer be resolved; i.e. what IPus and IPpeer be resolved; i.e. what exactly should the
exactly should the GaNAT remember]? GaNAT remember]?
5.4. 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 NSLP-aware or all NSLP-unaware. either all NSLP-aware or all NSLP-unaware.
6. Non-transparent NAT traversal 6. Non-transparent NAT traversal for GIST
This section discusses the "non-transparent" operation for GaNAT This section discusses the "non-transparent" operation for GaNAT
traversal at the GIST layer, i.e. the first approach listed in traversal at the GIST layer, i.e. the first approach listed in
Section 3. For this approach, the behaviour of both the GaNAT and Section 3. For this approach the behaviour of both the GaNAT and the
the GIST peers is defined. As with the transparent approach, the GIST peers is defined. As with the transparent approach, the case of
case of the in-between GaNAT(s) being located at the NI-side is the in-between GaNAT(s) being located at the NI-side is different
different from that of NR-side GaNATs. Note that the mechanisms in from that of NR-side GaNATs. Note that the mechanisms in this
this section apply only to NSLP-unware GaNATs. section apply only to NSLP-unware GaNATs.
The GaNAT informs the NSLP peers about its presence during the GIST The GaNAT informs the NSLP peers about its presence during the GIST
discovery process. This information enables the NSLP peers to map discovery process. This information enables the NSLP peers to map
the translated data flow to the signalling messages, and to the translated data flow to the signalling messages, and to
consistently translate the MRI, so that the NSLP only "sees" the consistently translate the MRI, so that the NSLP only "sees" the
correct MRI. Cryptographic protection of signalling messages can be correct MRI. Cryptographic protection of signalling messages can be
supported with this approach because the GaNAT only modifies the GIST supported with this approach because the GaNAT only modifies the GIST
QUERY and REPONSE messages, which are never cryptographically QUERY and RESPONSE messages, which are never cryptographically
protected in their entirety. protected in their entirety.
In this approach, the GaNAT embeds a new GIST payload type into the In this approach, the GaNAT embeds a "NAT Traversal Object" (NTO)
GIST QUERY. This payload encodes the aforementioned information, and payload type into the GIST QUERY. The NTO encodes the aforementioned
we call this payload type the "NAT Traversal Object" (NTO). The NTO information and is an optional payload in the GIST header of a GIST
is an optional payload in the GIST header of a GIST QUERY, and is QUERY. It is added, and processed, by the GaNAT(s) through which the
added, and processed, by the GaNAT(s) through which the QUERY QUERY traverses. The information in the NTO enables the two NSLP
traverses. The information in the NTO must enable the two NSLP peers peers to locally translate the MRI in the same way as if it were
to locally translate the MRI in the same way as if it were
consistently and transparently translated by the in-between GaNAT(s). consistently and transparently translated by the in-between GaNAT(s).
Note that there may be more than one GaNAT between the two NSLP 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 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 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 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. 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 The type value is TBD. The NTO is defined as in section A.3.8 of
[1]. [1].
6.1. NI-side NSLP-unaware GaNATs 6.1. NI-side NSLP-unaware GaNATs
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 an algorithm that is equivalent to the following. executes an algorithm that is equivalent to the following.
1. If P has a RAO followed by the GIST 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 GIST QUERY. In this case is not supported, and if it is identified as a GIST QUERY, the
the GaNAT does the following. GaNAT does the following.
1. We denote P as GQ. The GaNAT looks at the stack proposal ST 1. We denote P by GQ. The GaNAT looks at the stack proposal in
in GQ. If it does not include a proposal with cryptographic GQ. If it does not include any proposal with cryptographic
protection, the GaNAT MAY choose to follow the approach protection, the GaNAT MAY choose to follow the approach
described in Section 5.1 above. described in Section 5.1 above.
2. We call the link on which GQ arrived the "upstream" link. 2. The GaNAT remembers GQ along with the link on which it
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 and checks how the headers of the data flow (IP addresses and
port numbers) are translated according to this NAT port numbers) are translated according to this NAT
binding. binding. We denote the source IP address of translated
data packets by IPds, and their [Transport layer
header].SourcePort by SPDTds.
+ 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 and source port for Then, the GaNAT acquires an IP address and source port for
itself on the downstream link. (This address and port itself on the downstream link, denoted by IPds and SPDTds
could be dynamic or static.) respectively. This address and port could be dynamic or
static, and will be used (among other things) for the
installation of a NAT binding for the data traffic in the
future.
4. We denote [IP header].SourceIPAddress used on the downstream 4. The GaNAT aquires a source port number for the version of the
link as IPGaNATds, and the source port number for the data GIST QUERY that will be forwarded over the downstream link.
and signalling traffic as SPNDTGaNATds and SPNSTGaNATds We denote this port by SPSTds. (There is no requirement that
respectively. SPSTds must be different from GQ.[UDP Header].SourcePort.)
5. It creates a new GIST 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.SourceAddress <- IPGaNATds. 2. GQ'.MRI.SourceIPAddress <- IPds
3. GQ'.MRI.SourcePort <- SPNDTGaNATds. 3. GQ'.MRI.SourcePortNumber <- SPDTds
4. GQ'.NLI.IA.<- IPGaNATds. 4. GQ'.NLI.IA.<- IPds.
5. GQ'.[IP header].SourceIPAddress <- IPGaNATds. 5. GQ'.[IP header].SourceIPAddress <- IPds.
6. GQ'.[UDP header].SourcePort <- SPNSTGaNATds. 6. GQ'.[UDP header].SourcePort <- SPSTds.
7. GQ'.S <- true. 7. GQ'.S <- true.
8. It checks whether or not an NTO was included in GQ. 8. It checks whether or not an NTO was included in GQ.
- If none was included, it creates a new NTO as follows - If none was included, it creates a new NTO as follows
and adds it to GQ'. and adds it to GQ'. Note that the MRI field of the
NTO is taken from GQ.
o NTO.[NAT Count] <- 1. o NTO.[NAT Count] <- 1.
o NTO.MRI <- GQ.MRI. o NTO.MRI <- GQ.MRI.
o NTO.[List of translated objects] <- [type of MRI], o NTO.[List of translated objects] <- [type of NLI]
[type of NLI], [type of SCD]
o NTO.opaque information for NAT 1 <- GQ.[IP o NTO.opaque information replaced by NAT 1 <-
header].SourceAddress, [link identifier of upstream GQ.NLI.IA, GQ.[UDP header].SourcePort, LinkID,
link]. where LinkID represents the upstream link.
- If one was included, it replaces certain fields and - If one was included, it replaces certain fields and
appends new fields into the NTO, as follows, and adds appends new fields into the NTO, as follows, and adds
the resulting object to GQ'. the resulting object to GQ'. Note that the MRI field
of the NTO is not modified.
o NTO.[NAT Count] <- i, where i is the current [NAT o NTO.[NAT Count] <- i, where i is the current [NAT
count] value increased by one. count] value increased by one.
o NTO.[List of translated objects] <- [type of MRI], o NTO.[List of translated objects] <- [type of NLI]
[type of NLI], [type of STD]
o NTO.[opaque information replaced by NAT i] <- o NTO.opaque information replaced by NAT i <-
GQ.[IP header].SourceAddress, [LinkID of upstream GQ.NLI.IA, GQ.[UDP header].SourcePort, LinkID,
link]. where LinkID represents the upstream link.
9. It forwards GQ' on the downstream link. Note: The 9. It remembers GQ, GQ', the fact that they are associated,
encoding of the information that the GaNAT encodes into and the associated upstream and downstream links.
the NTO.[opaque information replaced by NAT i] field is a
local implementation issue. 10. It forwards GQ' on the downstream link.
2. Otherwise, if P carries an [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 GIST RESPONSE 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, with an NSLP ID that is not supported, the GaNAT does the
the GaNAT does the following (P is denoted as GR). following (P is denoted by GR).
1. If P does not contain an NTO, the GaNAT forwards it as usual 1. If P does not contain an NTO, the GaNAT discards it without
without further processing. Otherwise, the GaNAT selects the further processing. Otherwise, it searches for a matching
information encoded by it in the [opaque information replaced GQ' in its buffer. A GQ' is said to be matching if it
by NAT] field of the embedded NTO, denoted by IPAddressToSend carries the same cookie value. If none is found, GR is
and LinkID. If multiple [opaque information replaced by NAT] discarded. Otherwise, the GaNAT should also make sure that
fields are present in the NTO, the GaNAT uses the last one in the session ID in GR is the same as in GQ', that the NSLP IDs
the list. It then constructs a new GIST response GR', as match, and that GR arrived on the downstream link. If these
follows (note that no changes are made to the MRI). consistency checks fail, GR should be discarded. Otherwise,
the GaNAT 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].DestinationIPAddress <- IPAddressToSend. 2. The GaNAT selects the information that it encoded in the
[opaque information replaced by NAT i] field of the
embedded NTO, denoted by IPAddressToSend,
PortAddressToSend and LinkID, where i is the current
value of [NAT Count] as indicated in the NTO.
3. GR'.NTO.[NAT Count] <- current value minus one. 3. GR'.[IP header].DestinationIPAddress <- IPAddressToSend.
4. Remove the last [opaque information replaces by NAT i] 4. GR'.[UDP header].DestinationPort=PortAddressToSend.
field from GR'.NTO
5. GR'.S <- true. 5. GR'.NTO.[NAT Count] <- reduce by one.
2. It forwards GR' on the upstream link, i.e. the link 6. GR'.S <- true.
identified by LinkID.
3. The GaNAT SHOULD now invalidate all but one stack 2. The GaNAT inspects the Stack-Configuration-Data object in GR
configuration objects in the stack proposal in GR'. This is and the corresponding GQ' in order to check whether or not
done so that the quering node can only chose that one the upstream NSLP peer can select one of multiple transport
proposal, and that therefore only one NAT binding must be layer protocol/destination port number combinations for the
installed for the signalling traffic to traverse the GaNAT. establishment of a messaging association. If multiple
The GaNAT SHOULD keep valid the strongest, in terms of choices exist, the GaNAT invalidates as many transport layer
security, stack proposal. We denote this proposal as PR. protocol/port number combination proposals from GR' as
necessary, until the upstream NSLP peer can only initiate the
establishment of a messaging association with the downstream
NSLP peer using a single transport layer protocol/destination
port number combination. This invalidation is done by
setting the D-flag in those MA-Protocol-Options fields that
carry the port number proposals that are to be invalidated.
Note that, by setting the D-flag in a particular MA-Protocol-
Option field, the GaNAT may also invalidate the associated
transport layer and security protocol (e.g. TCP/TLS)
proposal. The actions of the GaNAT MUST NOT result in the
strongest, in terms of security, proposal to be invalidated.
In the end, the NAT will expect the upstream NSLP peer to use
a particular combination of transport layer protocol and
destination port (and possibly other details that are
associated with the valid proposal) for the establishment of
the messaging association. We call this combination the
"stack proposal expected by the NAT" and denote it by ST.
The GaNAT remembers this ST, its association with GQ, GQ',
GR, GR', and the upstream and downstream links. By doing so,
the GaNAT is said to "install" ST.
3. It forwards GR' on the link identified by LinkID.
4. The GaNAT now installs a NAT binding for the signalling 4. The GaNAT now installs a NAT binding for the signalling
traffic which says that "a packet K that arrives on the traffic that is exchanged over a messaging association which
upstream link and for which it holds that says that "a packet K that arrives on the upstream link and
for which it holds that
+ K.[IP header].SourceIPAddress=IPAddressToSend, + K.[IP header].DestinationIPAddress=GR.NLI.IA,,
+ K.[IP header].Protocol=PR.Protocol, and + K.[IP header].Protocol=ST.Protocol, and
+ K.[TCP/UDP header].DestinationPort=PR.[Destination Port] + K.[Transport layer
header].DestinationPort=ST.DestinationPort
should be forwarded on the downstream link (i.e. on the link should be forwarded on the downstream link, with [IP
on which GR arrived), with [IP header].SourceIPAddress = header].SourceIPAddress = IPds and [UDP/TCP
IPGaNATds. header].DestinationPort=SIGPort, where SIGPort is a port that
the GaNAT allocates for use as a source port for signalling
traffic.
5. If no NAT binding for the data traffic was found in step 5. The GaNAT now installs a NAT binding for the UDP-encapsulated
signalling traffic which says that "a packet M that arrives
on the upstream link and for which it holds that
+ M.[IP header].DestinationIPAddress=GR.NLI.IA,
+ M.[IP header].Protocol=UDP, and
+ M.[UDP header].DestinationPort=GIST well-known port
should be forwarded on the downstream link, with [IP
header].SourceIPAddress = IPds. Note that this is a special
type of NAT binding, in that the source port in M may vary
from one incoming message to another. This is why each
packet M may be mapped by the GaNAT to a different source
port. Translation in the upstream direction must be applied
consistently, and timeouts must also be selected
appropriately. That is, the overall binding must be timed
out together with the GIST state that is associated with this
session. However, each incoming packet M that matches this
binding causes the installation of a "sub"-binding (in the
sense that a new port mapping may occur) that will typically
time out faster.
6. 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 L that
arrives on the upstream link and for which it holds that arrives on the upstream link and for which it holds that
+ L.[IP
header].DestinationIPAddress=GQ.MRI.DestinationIPAddress,
+ K.[IP header].DestinationIPAddress=GQ'.NTO.MRI.Destination + L.[IP header].Protocol=GQ.MRI.Protocol, and
IPAddress,
+ K.[IP header].Protocol=GQ'.NTO.MRI.Protocol, and
+ K.[TCP/UDP header].PortNumbers=GQ'.NTO.MRI.PortNumbers + L.[Transport layer header].PortNumbers=GQ.MRI.PortNumbers
should be forwarded on the downstream link (i.e. the link on should be forwarded on the downstream link, with [IP
which GR arrived), with [IP header].SourceIPAddress = header].SourceIPAddress = IPds and [UDP/TCP
IPGaNATds and [UDP/TCP header].SourcePort=SPDTGaNATds. header].SourcePort=SPDTds.
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 GIST 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, session. Thus, during the processing of this signalling care
care has to be taken not to establish a NAT binding for a has to be taken not to establish a NAT binding for a flow for
flow for which a NAT binding already exists. Finally, which a NAT binding already exists. Finally, security issues
security issues may arise when traffic, for which no arise when traffic, for which no signalling exists, is
signalling exists, is allowed to traverse a GaNAT. allowed to traverse a GaNAT.
3. 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.
4. Otherwise, P is silently discarded. 4. Otherwise, P is subjected to normal NAT processing. That is, P
is either silently discarded or it causes the installation of a
(data) NAT binding.
6.2. NR-side NSLP-unaware GaNATs 6.2. NR-side NSLP-unaware GaNATs
As is the case with NR-side NSLP-unaware GaNATs that follow the As is the case with NR-side NSLP-unaware GaNATs that follow the
"transparent" approach, an NR-side NSLP-unaware GaNAT that follows "transparent" approach, an NR-side NSLP-unaware GaNAT that follows
the "non-transparent" approach must know a "pending" IP address and, the "non-transparent" approach must know a "pending" IP address and
depending on the scenario, also a destination port number, as optionally destination port number, as described in Section 5.2.
described in Section 5.2. This IP address and destination port This IP address and destination port number are denoted by IPNext and
number are denoted as IPNext and PortNext respectively. How they are PortNext respectively. How they are made known to the GaNAT is
made known to the GaNAT is outside the scope of this document. Note, outside the scope of this document. Note, however, that a typical
however, that a typical scenario would be that the GaNAT has an scenario would be that the GaNAT has an existing NAT binding in place
existing NAT binding for the data flow in place from where this from where this information can be derived.
information can be derived.
For every arriving IP packet P, an NSLP-unaware, NR-side GaNAT For every incoming 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 a GIST header with an unsupported 1. If P carries an [IP header].DestinationIPAddress that belongs to
NSLPID, and is identified as a GIST QUERY, the GaNAT does the the GaNAT, if it has a RAO followed by the GIST header with an
following. unsupported NSLPID, and if it is identified as a GIST QUERY, the
GaNAT does the following.
1. We denote P as GQ. The GaNAT looks at the stack proposal ST 1. We denote P by GQ. The GaNAT looks at the stack proposal in
in GQ. If it indicates that no cryptographic protection is GQ. If it does not include any proposal with cryptographic
required, the GaNAT MAY choose to follow the "transparent" protection, the GaNAT MAY choose to follow the "transparent"
approach as described in Section 5.2 above. approach as described in Section 5.2 above.
2. If GQ.[IP header].[Destination Address] is not bound to the 2. If GQ.[IP header].DestinationIPAddress, denoted by IPus in
link on which GQ arrived, the GaNAT silently discards the the sequel, is not bound to the link on which GQ arrived, the
packet. GaNAT silently discards the packet. Otherwise, it 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 GIST QUERY is 3. The GaNAT determines whether or not this GIST QUERY is
anticipated, i.e. if a pending IPNext and PortNext exists. anticipated, i.e. if a pending IPNext and PortNext exists.
One way of determining whether or not a pending IPNext and One way of determining whether or not a pending IPNext and
PortNext exists is checking whether or not a NAT binding for PortNext exists is checking whether or not a NAT binding for
the data traffic, as this is defined by the MRI in the GIST the data traffic, as this is defined by the MRI in the GIST
QUERY, exists in the NAT binding cache. If one exists, then QUERY, exists in the NAT binding cache. If one exists, then
IPNext and PortNext is the address and port number to which IPNext and PortNext is the address and destination port
the data traffic is sent after translation. If no pending number on which this traffic is forwarded. If no pending
IPNext is found, GQ is discarded (it is an open issue whether IPNext is found, then GQ is discarded (it is a question
or not an error message should be sent). Otherwise, whether or not an error message should be sent). Otherwise,
additional checks may be performed (e.g. a DSInfo object may additional checks may be performed (e.g. a DSInfo object may
have to be checked against the GQ). If these checks fail, GQ have to be checked against the GQ). If these checks fail, GQ
is discarded. Otherwise, the GaNAT performs the following. is discarded. Otherwise, the GaNAT performs the following.
4. We call the link on which GQ arrived the "upstream" link. 4. It searches its table of existing NAT bindings against
The GaNAT aquires an IP address for itself for the upstream entries that match GQ.MRI. A matching entry means that the
link (this could be a static or a dynamic IP address). This data flow, to which the signalling refers, already exists.
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 determines the + If a matching entry is found, the GaNAT looks at which
link on which the packets of the data flow are forwarded; link the packets of the data flow are forwarded; we call
we call this link the "downstream" link. Further, the this link the "downstream" link. Further, the GaNAT
GaNAT checks how the headers of the data flow (IP checks how the headers of the data flow (IP addresses,
addresses, port numbers) are translated according to this port numbers) are translated according to this NAT
NAT binding. Note that the [IP binding. Note that the [IP header].DestinationIPAddress
header].DestinationIPAddress of this NAT binding should be and DestinationPort in this NAT binding should be equal to
equal to IPNext. If it is not, this should be handled as IPNext and PortNext respectively. If they are not, this
an auditive error condition. (This check is done as a should be handled as an auditive error condition. (This
consistency check.) 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 (where GQ.MRI.DestinationIPAddress is replaced with GQ.MRI (where GQ.MRI.DestinationIPAddress is replaced with
IPNext) would be forwarded. We call this link the IPNext) would be forwarded. We call this link the
"downstream" link. "downstream" link.
6. It creates a new GIST 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.DestinationAddress <- IPNext. 2. GQ'.MRI.DestinationIPAddress <- IPnext
3. GQ'.MRI.DestinationPort <- PortNext. 3. GQ'.MRI.DestinationPortNumber <- PortNext
4. GQ'.[IP header].DestinationIPAddress <- IPNext. 4. GQ'.[IP header].DestinationIPAddress <- IPnext
5. It checks whether or not an NTO was included in GQ. 5. GQ'.[UDP header].DestinationPort <- GIST well-known port
(TBD)
6. It checks whether or not an NTO was included in GQ.
- If none was included, it creates a new NTO as follows - If none was included, it creates a new NTO as follows
and adds it to GQ'. and adds it to GQ'. Note that the MRI field of the
NTO is taken from GQ.
o NTO.[NAT Count] <- 1. o NTO.[NAT Count] <- 1.
o NTO.MRI <- GQ.MRI. o NTO.MRI <- GQ.MRI.
o NTO.[List of translated objects] <- [type of MRI], o NTO.opaque information for NAT 1 <- LinkID of
[type of NLI], [type of SCD] upstream link.
o NTO.opaque information for NAT 1 <- IPGaNATus,
[link identifier of upstream link].
- If one was included, it replaces certain fields and - If one was included, it replaces certain fields and
appends new fields into the NTO, as follows, and adds appends new fields into the NTO, as follows, and adds
the resulting object to GQ'. the resulting object to GQ'. Note that the MRI field
of the NTO is not modified.
o NTO.[NAT Count] <- i, where i is the current [NAT o NTO.[NAT Count] <- i, where i is the current [NAT
count] value increased by one. count] value increased by one.
o NTO.[List of translated objects] <- [type of MRI], o NTO.opaque information replaced by NAT i <- LinkID
[type of NLI], [type of SCD] of upstream link.
o NTO.[opaque information replaced by NAT i] <- 7. It remembers GQ, GQ', the fact that they are associated,
IPGaNATus, [LinkID of upstream link]. and the associated upstream and downstream links.
6. It forwards GQ' on the downstream link. Note: The 8. It forwards GQ' on the downstream link.
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 is identified as a GIST RESPONSE packet in 2. Otherwise, if P is identified as a GIST RESPONSE packet with an
datagram mode with an NSLP ID that is not supported, the GaNAT NSLP ID that is not supported, the GaNAT does the following (P is
does the following (P is denoted as GR). denoted by GR).
1. If P does not contain an NTO, the GaNAT forwards it as usual 1. It searches for a matching GQ' in its buffer. A GQ' is said
without further processing. Otherwise, the GaNAT selects the to be matching if it carries the same cookie value. If none
information encoded by it in the [opaque information replaced is found, GR is discarded. Otherwise, the GaNAT should also
by NAT] field of the embedded NTO, denoted by IPGaNATus and make sure that the session ID in GR is the same as in GQ',
LinkID. If multiple [opaque information replaced by NAT] that the NSLP IDs match, and that GR arrived on the
fields are present in the NTO, the GaNAT uses the last one in downstream link. If these consistency checks fail, GR should
the list. The GaNAT then constructs a new GIST response GR', be discarded. Otherwise, the GaNAT constructs a new GIST
as follows (note that no changes are made to the MRI). RESPONSE GR', as follows.
1. GR' <- GR 2. If P does not contain an NTO, the GaNAT discards it without
further processing. Otherwise, the GaNAT constructs a new
GIST RESPONSE GR', as follows (note that no changes are made
to the MRI).
2. GR'.[IP header].SourceIPAddress <- IPGaNATus. 1. GR' <- GR.
3. GR'.MRI.NLI.IA <- IPGaNATus. 2. The GaNAT selects the information that it encoded in the
[opaque information replaced by NAT i] field of the
embedded NTO, denoted by LinkID, where i is the current
value of [NAT Count] as indicated in the NTO.
4. Remove the last [opaque information replaced by NAT i] 3. GR'.NLI.IA <- IPus
field from GR'.NTO.
5. GR'.S <- true. 4. GR'.NTO.[List of translated objects by NAT i] <- [type of
NLI], where i is the current value of [NAT Count] as
indicated in the NTO.
2. The GaNAT SHOULD now invalidate all but one stack 5. GR'.NTO.[NAT Count] <- reduce by one.
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.
3. It forwards GR' on the upstream link, i.e. the link 6. GR'.[IP header].SourceIPAddress <- IPus (this is the IP
identified by LinkID. address that is bound to the link identified by LinkID
and must be equal to GQ.[IP header].DestinationIPAddress,
where GQ is the GIST QUERY associated with GQ').
4. The GaNAT now installs a NAT binding for the signalling 7. GR'.[UDP header].DestinationPort <- GQ.[UDP
traffic which says that "a packet K that arrives on the header].SourcePort, where GQ is the GIST QUERY associated
upstream link and for which it holds that with GQ'.
+ K.[IP header].DestinationIPAddress=IPGaNATus, 8. GR'.S <- true.
+ K.[IP header].Protocol=PR.Protocol, and 3. The GaNAT inspects the Stack-Configuration-Data object in GR
and the corresponding GQ' in order to check whether or not
the upstream NSLP peer can select one of multiple transport
layer protocol/destination port number combinations for the
establishment of a messaging association. If multiple
choices exist, the GaNAT invalidates as many transport layer
protocol/port number combination proposals from GR' as
necessary, until the upstream NSLP peer can only initiate the
establishment of a messaging association with the downstream
NSLP peer using a single transport layer protocol/destination
port number combination. This invalidation is done by
setting the D-flag in those MA-Protocol-Options fields that
carry the port number proposals that are to be invalidated.
Note that, by setting the D-flag in a particular MA-Protocol-
Option field, the GaNAT may also invalidate the associated
transport layer and security protocol (e.g. TCP/TLS)
proposal. The actions of the GaNAT MUST NOT result in the
strongest, in terms of security, proposal to be invalidated.
In the end, the NAT will expect the upstream NSLP peer to use
a particular combination of transport layer protocol and
destination port (and possibly other details that are
associated with the valid proposal) for the establishment of
the messaging association. We call this combination the
"stack proposal expected by the NAT" and denote it by ST.
The GaNAT remembers this ST, its association with GQ, GQ',
GR, GR', and the upstream and downstream links. By doing so,
the GaNAT is said to "install" ST. If ST.DestinationPort is
already used by the GaNAT as a destination port in order to
demultiplex an existing flow, the GaNAT reserves a
destination port SIGPORT and modifies the valid port proposal
in GR' such that SIGPORT will be used by the upstream GIST
peer. Otherwise it sets SIGPORT=ST.DestinationPort.
+ K.[TCP/UDP header].DestinationPort=SIGPORT 4. It forwards GR' on the link identified by LinkID (i.e. the
should be forwarded on the downstream link (i.e. on the link upstream 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 data traffic was found in step 5. The GaNAT now installs a NAT binding for the signalling
1.3.2, the GaNAT may now install a NAT binding (for the traffic that is exchanged over a messaging association which
says that "a packet K that arrives on the upstream link and
for which it holds that
+ K.[IP header].DestinationIPAddress=IPus (which is equal to
GQ.MRI.DestinationIPAddress and GQ.[IP
header].DestinationIPAddress),
+ K.[IP header].Protocol=ST.Protocol, and
+ K.[Transport layer header].DestinationPort=SIGPORT
should be forwarded on the downstream link, with [IP
header].DestinationIPAddress = GR.NLI.IA and [Transport layer
header].DestinationPort=ST.DestinationPort.
6. The GaNAT now installs a NAT binding for the UDP-encapsulated
signalling traffic which says that "a packet M that arrives
on the upstream link and for which it holds that
+ M.[IP header].DestinationIPAddress=IPus,
+ M.[IP header].Protocol=UDP, and
+ M.[UDP header].DestinationPort=GIST well-known port
should be forwarded on the downstream link, with [IP
header].SourceIPAddress = GR.NLI.IA". Note that this is a
special type of NAT binding, in that the source port in M may
vary from one incoming message to another. This is why each
packet M may be mapped by the GaNAT to a different source
port. Translation in the upstream direction must be applied
consistently, and timeouts must also be selected
appropriately. That is, the overall binding must be timed
out together with the GIST state that is associated with this
session. However, each incoming packet M that matches this
binding causes the installation of a "sub"-binding (in the
sense that a new port mapping may occur) that will typically
time out faster.
7. 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 L that unidirectional data traffic) which says that "a packet L that
arrives on the upstream link and for which it holds that arrives on the upstream link and for which it holds that
+ L.[IP header].DestinationIPAddress=GR'.NTO.MRI.Destination + L.[IP header].DestinationIPAddress=IPus (which is equal to
IPAddress, GQ.MRI.DestinationIPAddress and GQ.[IP
header].DestinationIPAddress),
+ L.[IP header].Protocol=GR'.NTO.MRI.Protocol, and + L.[IP header].Protocol=GQ.MRI.Protocol, and
+ L.[TCP/UDP + L.[Transport layer header].PortNumbers=GQ.MRI.PortNumbers
header].DestinationPortNumbers=GR'.NTO.MRI.DestinationPort
should be forwarded on the downstream link, with [IP should be forwarded on the downstream link, with [IP
header].DestinationIPAddress = IPNext and [UDP/TCP header].DestinationIPAddress = IPNext and [Transport layer
header].DestinationPort=PortNext. header].DestinationPort=PortNext.
Note: If the GaNAT also allows data traffic to traverse in
the other direction (i.e. in the upstream direction), then
the IP packets of this data traffic MUST have
SourceIPAddress=IPus, SourcePort=GQ.MRI.DestinationPort,
DestinationPort=GQ.MRI.SourcePort, and must be forwarded on
the upstream link. (This applies anyway for GaNATs with only
two links and where each link is bound to a single IP
address. However, for other types of GaNAT care has to be
taken that this restriction is enforced.)
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 multiplex 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 GIST 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 NI-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
may 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.
3. 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.
4. Otherwise, P is silently discarded. 4. Otherwise, P is subjected to normal NAT processing. That is, P
is either silently discarded or it causes the installation of a
(data) NAT binding.
The remaining steps of the algorithm are analogous to the algorithm
of NSLP-unaware, NR-side GaNATs, which was described in the previous
section.
6.3. GIST peer processing 6.3. GIST peer processing
In the presence of GaNATs on the signalling path between two NSLP In the presence of GaNATs on the signalling path between two NSLP
peers, and if the GaNATs follow the "non-transparent" approach (which peers, and if the GaNATs follow the "non-transparent" approach (which
they have to follow in the context of cryptographically protected they have to follow in the context of cryptographically protected
signalling), the consistent translation of the GIST header fields signalling), the consistent translation of the GIST header fields
must be carried out by the NSLP peers. The GIST processing that must be carried out by the NSLP peers. The GIST processing that
performs this task, is described in section 7.2 of [1]. performs this task, is described next. Note that this processing is
in addition to the processing described in [1]. Also note that the
7. GIST-unaware NATs processing described in this section applies only to non-NAT nodes.
The following may serve as indications for the existence of an GIST-
unaware NAT between two GIST peers. These indications can only be
detected by the receiver of a GIST message. The first occasion these
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
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 field does not belong to the
addressing space of the receiving peer.
o The D flag of a received 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 GIST packet denotes upstream direction
and the S flag is not set and [IP header].SourceIPAddress !=
MRI.DestinationIPAddress.
o This is a GIST QUERY and [IP header].DestinationIPAddress !=
MRI.DestinationIPAddress.
Note that these are only indications. In the presence of an
adversary, a GIST peer may be tricked into believing that an GIST-
unaware NAT exists between itself and one of its neighbouring peers,
while in reality this may not be the case.
When a downstream 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 GIST packet
in such a way that, after it traverses the GIST-unaware NAT, the IP
addresses in the MRI field and the NLI.IA 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 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 A GIST peer that receives a GIST QUERY that carries an NSLP ID for a
established and then (1) happens, or supported NSLP and an NTO, constructs a GIST RESPONSE according to
[1]. This response is sent to the public address of the last in-
between GaNAT. This address appeared as NLI.NI in the GIST QUERY
(and also as the source address in the IP header).
3. is discarded because neither (1) nor (2) applies. If local policy allows the installation of state without the
reception of a GIST CONFIRM message, then the responder stores the
NTO carried with the QUERY together with the routing state
information about the querying GIST peer. In particular, the MRI
field of the NTO must be saved in order for the peer to be able to
map subsequently received signalling messages to this signalling
session.
With GIST-unaware NATs it is a matter of local policy (i.e. the rules Note that it is not sufficient for the NSLP to exclusively rely on
that exist in case (2) above) whether or not traffic will be allowed the NTO.MRI for this purpose. In order to see this, consider two
to traverse the NAT. This obviously applies to both signalling and private addressing domains, A and B, each with a GaNAT at its border,
data traffic, as an GIST-unaware NAT is unable to distinguish the two and a node N in the public internet. In domain A, node N1 has a
types of traffic. It may be the case that GIST node A is unable to communication session with N, and in domain B, node N2 also has a
contact GIST node B which is "behind" a NAT, even if communication in communication session with N. Suppose that the (private) IP addresses
from B to A may be possible because such communication would match a of N1 and N2 are equal (e.g. 192.168.0.3), and that they both
policy rule; typically, in a scenarios where A is towards the NI and communicate with N using the same source and destination ports. If
B is towards the NR, the NAT would have this behaviour. they both have an NSIS signalling session for this data traffic, the
NTO.MRI field in the GIST QUERY of their respective signalling
sessions are identical. If these signalling sessions meet at an NSLP
node that is located "after" the GaNATs, then this NSLP node sees the
same MRI in signalling messages that are received over a messaging
association. In this case, the node must use other information in
the signalling messages (e.g. session ID, source IP address) in order
to map subsequently received signalling messages to existing
sessions.
Another approach to deal with GIST-unaware NATs is similar to the NAT If local policy demands that no session-specific state is installed
traversal approach taken by IKEv2, i.e. by encapsulating GIST before the reception of a GIST CONFIRM message, then the responder
messages into UDP datagrams, rather than directly into IP datagrams. must encode the information in NTO.MRI and NLI.IA from the GIST QUERY
This technique requires the inclusion of additional fields into a (and possibly other values such as NSLP ID and an identifier of the
GIST QUERY, as follows. The sender adds (a hash of) its own IP link on which the GIST QUERY arrived) in the responder cookie. Since
address and the IP address of what it believes to be the DR into the this cookie is echoed in the GIST CONFIRM message, the responder can
GIST payload. The receiver of this GIST messages compares these then delay the installation of the relevant state until it receives
addresses to the [IP header].SourceIPAddress and the [IP the GIST CONFIRM. The construction of the responder cookie is
header].DestinationIPAddress respectively. If at least one of them implementation-specific, in the sense that it does not raise
is unequal, the receiver deduces that a NAT is between sender and interoperability issues. Nevertheless, the cookie must be generated
receiver. After the detection of a NAT, the remainder of the in a way that meets the requirements listed in section 8.5 of [1],
communication is encapsulated into UDP datagrams that are addressed and in a way that does not introduce additional attacks against the
to a specified port. system.
Unfortunately, the IKEv2 NAT traversal mechanism cannot be used "as Two responder cookie construction mechanisms are described in the
is" for NAT traversal in GIST. This is because of a number of sequel. These methods are in addition to those described in section
reasons, including the following. 8.5 of [1], and meet the requirements listed in that section.
Additionally, they enable the responder to authenticate the contents
of the cookie, i.e. to ensure that the cookie was not tampered with
while in transit. This feature is not provided by the cookie
construction mechanisms described in [1].
o The NAT may use an IP address for the forwarding of data traffic Responder cookie generation mechanism 1: Responder cookie = (gennum
that is different from the IP address it uses to forward GIST || cookie-left || cookie-right), where || denotes concatenation,
traffic. Since the NAT is GIST-unaware it cannot update the MRI cookie-left is computed as ENC (Q-Node NLI, MRI, NSLPID, reception
in the GIST messages such that it matches the translation applies interface, [timestamp]), and cookie-right is computed as MAC (cookie-
to the data traffic. Moreover, neither the GIST sending, nor the left). ENC denotes a semantically secure symmetric encryption
GIST receiving peer can perform this update; the sending peer scheme, and MAC denotes an unforgeable message authentication code
cannot predict the translation that the NAT will apply, and the scheme. The responder must use a key with ENC that has been selected
receiving peer does not have enough information to associate data independently from the one used with MAC. Whenever these keys are
flows to signalling messages. refreshed, they MUST be refreshed together. Gennum is the generation
number of the ENC and MAC keys. The timestamp is an optional field.
Policy dictates whether or not it is included in the construction of
the cookie. For example, responders that have a fast enough key
rollover may omit the timestamp. Example algorithms for ENC and MAC
are AES-128 in CBC mode [3], and HMAC-SHA1 [4].
o It is unclear whether or not the IKEv2 NAT traversal mechanism Responder cookie generation mechanism 2: Responder cookie = (Gennum
supports cascades of NATs. || AUTHENC (Q-Node NLI, MRI, NSLPID, reception interface,
[timestamp])) AUTHENC denotes a symmetric authenticated encryption
scheme. Gennum is the generation number of the key used with
AUTHENC. The timestamp is an optional element for the same reason as
above. Example AUTHENC algorithms include the one specified in
RFC3610.
o It seems to be inappropriate to use UDP encapsulation for certain The version of the MRI that the NSLP peers pass to the NSLP is the
C-mode scenarios. For example, using UDP encapsulation for TCP one in the header of the GIST QUERY (not the one in the NTO, if one
C-mode would result in GIST to appear in TCP over UDP over IP. is present). Whether or not this is a translated MRI depends on the
location of the peer with respect to the in-between GaNAT(s). Note
that the same MRI is used by the responder in signalling messages
that are sent towards the downstream direction.
8. Security Considerations 7. 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, some of these
threats is mentioned. threats is mentioned.
8.1. Service Denial Attacks 7.1. Service Denial Attacks
As described above, NSLP-unaware GaNATs create some state whenever As described above, NSLP-unaware GaNATs create some state whenever
they receive a GIST QUERY message. This state is necessary in order they receive a GIST QUERY message. This state is necessary in order
for the GaNAT to be able to map a GIST RESPONSE that arrives from the for the GaNAT to be able to map a GIST RESPONSE that arrives from the
downstream direction to the corresponding GIST QUERY and thereby to downstream direction to the corresponding GIST QUERY and thereby to
perform the required translation. perform the required translation.
The threat here is an attacker flooding the GaNAT with maliciously The threat here is an attacker flooding the GaNAT with maliciously
constructed GIST 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
skipping to change at page 39, line 38 skipping to change at page 41, line 38
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 variety of factors, including the following.
o The amount of state allocated at the receipt of a GIST 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 acquires 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 GIST 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 GIST 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 GIST REPONSE traverses the NAT. until the correct GIST RESPONSE 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 7.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
GIST 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 to 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 might 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-conscious decisions regarding the operation of the GaNAT.
NSLP-aware GaNAT, on the other hand, follows an NSLP policy which An 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. IAB Considerations 8. IAB Considerations
None. None.
10. Acknowledgements 9. Acknowledgements
The authors would like to thank Cedric Aoun, Christian Dickmann, The authors would like to thank Cedric Aoun, Christian Dickmann,
Robert Hancock, and Martin Stiemerling for their insightful comments. Robert Hancock, and Martin Stiemerling for their insightful comments.
Furthermore, we would like to mention that this document builds on Furthermore, we would like to mention that this document builds on
top of a previous document regarding migration scenarios. top of a previous document regarding migration scenarios.
11. Normative References 10. Normative References
[1] Schulzrinne, H. and R. Hancock, "GIST: General Internet [1] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-06 (work in Signalling Transport", draft-ietf-nsis-ntlp-09 (work in
progress), May 2005. progress), February 2006.
[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-09
(work in progress), May 2005. (work in progress), February 2006.
[3] "Advanced Encryption Standard (AES)", FIPS PUB 197,
November 2001.
[4] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
Authors' Addresses Authors' Addresses
Andreas Pashalidis Andreas Pashalidis
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Andreas.Pashalidis@siemens.com Email: Andreas.Pashalidis@siemens.com
skipping to change at page 45, line 41 skipping to change at page 47, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 242 change blocks. 
751 lines changed or deleted 890 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/