[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

NSIS                                                       A. Pashalidis
Internet-Draft                                                       NEC
Intended status: Informational                             H. Tschofenig
Expires: January 9, 2008                          Nokia Siemens Networks
                                                            July 8, 2007


                       GIST Legacy NAT Traversal
              draft-pashalidis-nsis-gist-legacynats-02.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on January 9, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes an extension to the General Internet
   Signalling Transport (GIST) protocol that enables the protocol to
   traverse different types of Network Address Translator (NAT).  These
   NATs are assumed to not support GIST, i.e. to be "legacy" NATs.  The
   purpose of this extension is to enable GIST hosts to correctly
   interpret signalling messages with respect to the data traffic they
   refer to, in the presence of such NATs.  Note that this extension



Pashalidis & Tschofenig  Expires January 9, 2008                [Page 1]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


   does not require changes to the format of GIST messages; it merely
   requires some new behaviour for non-NAT GIST nodes.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Legacy NAT Traversal Mechanism . . . . . . . . . . . . . . . .  7
     5.1.  Traversal of NI-side legacy NATs . . . . . . . . . . . . .  7
       5.1.1.  Treatment of Data Traffic  . . . . . . . . . . . . . . 10
       5.1.2.  Treatment of Signalling Traffic  . . . . . . . . . . . 12
       5.1.3.  Refreshing NSIS State  . . . . . . . . . . . . . . . . 12
     5.2.  Traversal of NR-side legacy NATs . . . . . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15




























Pashalidis & Tschofenig  Expires January 9, 2008                [Page 2]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


1.  Introduction

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

   This document describes an extension to GIST that can be used in
   order for GIST signalling messages to traverse GIST-unaware NATs in a
   way that preserves the consistency of state that is installed in the
   network with respect to the data flows to which the signalling
   messages refer.  As this extension exclusively operates at the GIST
   layer, it is transparent to signalling applications.  The document is
   organised as follows.  The next section introduces the terminology
   that is used throughout this document.  Section 3 provides a detailed
   discussion of the NAT traversal problem and highlights certain design
   decisions that have to be taken when addressing the problem.
   Section 4 lists the assumptions on which the subsequently proposed
   mechanisms are based.  The proposed extension is described in
   Section 5.


2.  Terminology

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

   o  DR: Data Receiver, same as Flow Receiver as defined in [1]
   o  DS: Data Sender, same as Flow Sender as defined in [1]
   o  GaNAT: GIST-aware NAT - a GaNAT MAY implement a number of NSLPs.
   o  GIST: General Internet Messaging Protocol for Signalling [1]
   o  NAT: Network Address Translator
   o  NI: NSIS Initiator; this is the GIST node (as defined in [1]) that
      initiates a signalling session for a given NSLP.  The NI may or
      may not be identical to the DS or the DR.
   o  NR: NSIS Responder; this is the GIST node (as defined in [1]) that
      acts as the last in a sequence of nodes that participate in a
      given signalling session.  The NR may or may not be identical to
      the DR or the DS.
   o  NSIS: Next Steps in Signalling: The name of the IETF working group
      that specified the family of signalling protocols of which this
      document is also a member.  The term NSIS is also used to refer to
      this family of signalling protocols as a whole.





Pashalidis & Tschofenig  Expires January 9, 2008                [Page 3]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


   o  GIST-aware: Implements GIST and MAY also implement a number of
      NSLPs.
   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  downstream: as defined in [1]
   o  upstream: as defined in [1]
   o  MRI: Message Routing Information, as defined in [1]
   o  NLI.IA: Interface Address field of the Network Layer Information
      object, as defined in [1]
   o  <- : Assignment operator.  The quantity to the right of the
      operator is assigned to the variable to its left.
   o  A.B: Element B of structure A. Example: [IP
      header].SourceIPAddress denotes the source IP address of an IP
      header.
   o  [data item]: This notation indicates that "data item" is a single
      identifier of a data structure.  (Square brackets do not denote
      optional arguments in this document.)


3.  Problem Statement

   According to [1], all GIST messages between two peers carry IP
   addresses in order to define the data flow to which the signalling
   refers.  Moreover, certain GIST messages also carry the IP address of
   the sending peer, in order to enable the receiving peer to address
   subsequent traffic to the sender.  Packets that cross an addressing
   boundary, say from addressing space S1 to S2, have the IP addresses
   in the IP header translated from space S1 to S2 by the NAT; if 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,
   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
   routable or invalid in S2.  Moreover, the IP address of the sending
   peer may also be not routable or invalid in the addressing space of
   the receiving peer.  The purpose of this document is to describe an
   extension that enables GIST messages to be translated in a way that
   is consistent with the translation that NATs apply to the IP headers
   of the data traffic.

   A NAT may be either GIST-unaware or GIST-aware.  The traversal of
   GIST-aware NATs is described in [2] and [3].  The subject matter of
   this document is the traversal of GIST-unaware NATs.

   A GIST-unaware NAT cannot tell data and signalling traffic apart.
   The installation of the NAT binding for the signalling traffic in
   such a NAT occurs typically independently from the installation of
   the NAT binding for the data traffic.  Furthermore, as the NAT cannot



Pashalidis & Tschofenig  Expires January 9, 2008                [Page 4]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


   associate the signalling and the data traffic, it cannot indicate
   that an association exists between the two NAT bindings.  Therefore,
   in the presence of such a NAT, non-NAT GIST nodes that are located on
   either side of the NAT have to cope with the NAT without assistance
   from the NAT.  This would typically require initially discovering the
   NAT and subsequently establishing an association between between the
   MRI in the signalling messages and the translated IP header in the
   data traffic.  Due to the variety of behaviours that a GIST-unaware
   NAT may exhibit, establishing this association is a non-trivial task.


4.  Assumptions

   The discussion in this document is based on the following
   assumptions.

   1.  No IP addresses and port numbers are carried in the payloads of
       the NSLP.  If this is not the case, then the NSLP has to provide
       additional mechanisms for the traversal of NATs.  These
       mechanisms must be compatible the mechanisms described in this
       document.
   2.  The path taken by the signalling traffic between those GIST peers
       that have GIST-unaware NATs in between is such that the responses
       to packets that a NAT sends on given interface arrive on the same
       interface (if such responses are sent at all).
   3.  The path taken by signalling traffic remains fixed between the
       two GIST peers, as far as the in-between NAT(s) are concerned.
       That is, we assume that signalling traffic traverses the same set
       of NATs until at least one of the following conditions is met.
       *  The NSIS state that is installed at the two GIST peers
          expires.
       *  The NSIS state that is installed at the two GIST peers is
          refreshed using a GIST QUERY.
       *  A new GIST QUERY/RESPONSE exchange takes place due to other
          reasons, e.g. a detected route change.
       Note that this assumption is not necessarily met by "normal" data
       path coupled signalling.  This is because, under "normal" data
       path coupled signalling, the signalling traffic is "coupled" to
       the data traffic at nodes that decide to act as GIST peers.
       Thus, under "normal" path coupled signalling, it is not always an
       error 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
       peers, changes, as long as adjacent GIST peers remain the same.
   4.  The data flow traverses the same set of NATs as the signalling
       traffic.  By assumption 3, this set of NATs is fixed until the
       next GIST QUERY/RESPONSE procedure is executed.





Pashalidis & Tschofenig  Expires January 9, 2008                [Page 5]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


   5.  The path-coupled routing method is used by the NSLP.  (Other
       routing methods are not considered in this version of this
       document.)
   6.  The legacy NAT does not drop IP packets with a Router Alert
       Option (RAO) or an IPv6 extensions header.  Furthermore, the RAO
       or extension header is also present in the forwarded packet.  If
       the NAT does not do this, then there is no way for a GIST QUERY
       to traverse the NAT, which is a prerequisite for the mechanisms
       described in this document.


                           +-----+
                      +----+ NAT |-----+
                      |    |  A  |     |
                      |    +-----+     |
        +------+  +------+          +--+---+  +------+
   +--+ | GIST |  |  IP  |          |  IP  |  | GIST | +--+
   |DS+-+peer 1+--+router|          |router+--+peer 2+-+DR|
   +--+ +------+  +---+--+          +--+---+  +------+ +--+
                      |    +-----+     |
                      |    | NAT |     |
                      +----+  B  +-----+
                           +-----+

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

   Figure 1 illustrates the importance of assumptions (3) and (4).  With
   regard to that figure, suppose that a (D-mode) signalling session has
   been setup between the two adjacent GIST peers 1 and 2 and that both
   signalling and data traffic follows the path GIST peer 1 -> IP router
   -> NAT 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.
   Suppose moreover that the left IP router decides to forward the
   C-mode signalling traffic on the link towards NAT B. Thus, signalling
   traffic now follows the alternative path GIST peer 1 -> IP router ->
   NAT B -> IP router -> GIST peer 2.  Note that this change in
   forwarding between the two adjacent GIST peers does not trigger a
   "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 necessarily
   destroy the coupling of the path taken by signalling traffic to that
   taken by data traffic (at GIST nodes).  Nevertheless, assumptions (3)
   and (4) mandate that this situation does not occur.  However, even if
   such a situation occurs, the mechanisms described in this document
   may still work as state expires after a certain timeout period.

   Assumptions (2), (3) and (4) hold if, at an addressing boundary, only
   one NAT exists.  Due to security and management reasons, this is
   likely to be the case in many settings.



Pashalidis & Tschofenig  Expires January 9, 2008                [Page 6]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


5.  Legacy NAT Traversal Mechanism

   GIST-unaware NATs do not distinguish between signalling traffic and
   data traffic.  Furthermore, the behaviour of a GIST-unaware NAT with
   respect to the establishment and the configuration of NAT bindings
   may vary significantly from one NAT to another [4].  There exists no
   means by which a GIST peer can predict how such a NAT will configure
   a future binding.  A GIST-unaware NAT allocates the binding that will
   be used for the data traffic independently from the binding that is
   used for the signalling traffic.  Thereby the mapping of signalling
   messages to data traffic is destroyed, and cannot be re-established
   by GIST nodes.

   The idea of enabling GIST traffic to traverse GIST-unaware NATs is
   somewhat similar to the mechanisms on which Teredo [6] and the STUN
   relay service [5], [7] are based.  The idea is to tunnel signalling
   and data traffic over UDP, such that both data and signalling traffic
   use a single NAT binding.  The GIST peer that is located on the other
   side of the NAT then removes the outer headers and also performs
   network address translation for both the signalling traffic
   (including GIST payloads) and the data traffic, in a consistent
   manner.

   Note that two types of GIST-unaware NATs have to be dealt with,
   namely those that are located at the NSIS initiator (NI-side), and
   those that are located at the NSIS responder (NR-side).  This
   distinction arises due to the fact that NR-side NATs are likely to
   drop traffic that does not match an existing binding.  By contrast,
   NI-side NATs typically create a new binding if no matching one is
   found.

5.1.  Traversal of NI-side legacy NATs



















Pashalidis & Tschofenig  Expires January 9, 2008                [Page 7]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


            +----+ QUERY +----------+ QUERY +----+
            |    |------>|          |------>|    |
            |    | RESP. |  LEGACY  | RESP. |    |
            |    |<------|   NAT    |<------|    |
    data    |GIST|       |          |       |GIST|    data
    -----+  |NODE|       |          |       |NODE|   +----
         |  |  1 | +----------------------+ |  2 |   |
         +--+----+-+      UDP TUNNEL      +----------+
   signl.|  |    | +----------------------+ |    |   |signl.
    -----+  +----+       +----------+       +----+   +----

                 internal              external
                   side                  side

       Figure 2: High level overview of NI-side legacy NAT traversal
                                 mechanism

   The following may serve as indications for the existence of one or
   more GIST-unaware NAT(s) between two GIST peers.  For the purposes of
   the discussion in this section, these peers are called the "upstream"
   GIST peer (which also happens to be the querying peer) and the
   "downstream" GIST peer (which also happens to be the responding
   peer).  These indications can only be detected by the receiver of a
   GIST message, i.e. by the downstream peer.  The first occasion these
   indications may be detected is with the reception of a GIST QUERY
   where the downstream peer assumes the role of the responder.  Note
   that, by assumption 6, the GIST QUERY is received by the responder.
   Also note that != denotes inequality.

   o  The MRI.SourceIPAddress does not belong to the addressing space of
      the responding peer.
   o  The MRI.DestinationIPAddress does not belong to the addressing
      space of the responding peer.
   o  The IP address in the NLI.IA field does not belong to the
      addressing space of the responding peer.
   o  The S flag is set and [IP header].SourceIPAddress != NLI.IA.
   o  This is a GIST QUERY and [IP header].DestinationIPAddress !=
      MRI.DestinationIPAddress.

   Suppose, after detecting one or more of the above, the downstream
   GIST peer believes that a NAT is located between itself and the
   sender of the GIST QUERY.  If this is indeed the case, then the NAT
   will have installed a UDP NAT binding as a result of the QUERY
   passing through it.  The downstream GIST node constructs a D-mode
   RESPONSE according to the following rules.






Pashalidis & Tschofenig  Expires January 9, 2008                [Page 8]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


   o  The [IP header].SourceAddress is set equal to the responder's IP
      address, i.e.  [IP header].SourceAddress is set equal to NLI.IA.
   o  As a result of the above, the S flag in the RESPONSE is set.
   o  The MRI.[Source IP Address] field is replaced with [IP
      header].SourceAddress of the QUERY, i.e. the public address of the
      NAT.
   o  One stack proposal is added to the end of the set of proposals
      that are included in the RESPONSE by default.  This last item is a
      proposal for UDP.  It will be used for UDP tunnelling.  The GIST
      node must be prepared to accept IP traffic that is tunneled over
      UDP on the advertised port.

   The first of the above measures ensure that, even if the NAT exhibits
   an "Address and Port Dependent Filtering" behaviour, as defined in
   [4], the RESPONSE is not dropped by the NAT.  Note that this is the
   most restrictive filtering behaviour, and that, therefore, the
   mechanism works also with less restrictive NATs.

   The upstream GIST peer, on reception of the RESPONSE can also deduce
   that a GIST-unaware NAT is likely to be located between itself and
   the downstream GIST peer.  This is possible because of the
   discrepancy of SourceAddress in the MRI sent in the QUERY and the one
   received in the RESPONSE.  From that point onwards the upstream GIST
   peer tunnels both the GIST messages that belong to the current
   signalling session, and the data traffic to which they refer, over a
   UDP tunnel that it sets up with the downstream GIST peer on the
   advertised port.  That is, the packets that the upstream GIST peer
   sends are such that the outer IP header is followed by a UDP header,
   which is in turn followed by an inner IP header.  The same applies to
   the downstream GIST peer.  In order to set up a messaging
   association, the upstream GIST node removes the last UDP proposal
   from the set of proposal received in the RESPONSE, and selects a
   profile as usual.

   For every packet that the downstream GIST peer receives on the
   advertised UDP port it checks that [Outer IP header].SourceAddress is
   equal to [IP header].SourceAddress of the QUERY in response to which
   the UDP port was advertised (i.e. the public address of the NAT).  If
   this check fails, the packet is silently discarded.  Note that, in
   order to perform this check, the peer needs to allocate some state
   before a CONFIRM message is received.  This state, however, is not
   necessarily per-session state, and various DoS exposure mitigation
   techniques can be applied if the peer finds itself heavily loaded.
   One such measure is to temporarily turn off the support of GIST-
   unaware NAT traversal.

   A packet that the downstream peer receives over the tunnel is either
   a GIST message or a data packet.  It is a GIST message if [inner IP



Pashalidis & Tschofenig  Expires January 9, 2008                [Page 9]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


   header].DestinationAddress belongs to the peer (i.e. is equal to the
   one advertised in the NLI.IA field), and a data packet otherwise.
   Note that, if the downstream peer is also the DR, then this
   distinction does not apply.  However, in this case the inner
   transport layer header can be used to unambiguously determine whether
   the packet belongs to an established GIST messaging association, or a
   data flow.

5.1.1.  Treatment of Data Traffic

   When the downstream GIST peer receives a data packet P from the
   upstream GIST peer over the UDP tunnel, it should ensure that the
   following conditions are met.

   o  The inner [IP header].[transport protocol] field and the inner
      [Transport layer header].DestinationPort of P matches the MRI of a
      GIST QUERY in response to which the UDP tunnel parameters were
      advertised.  Note that multiple such GIST queries may exist if the
      same tunnel is used for multiple signalling sessions (and
      therefore multiple data flows) between the upstream and the
      downstream GIST peers.
   o  If the signalling session is to run over a secure connection (e.g.
      IPsec, TLS), and if required by local policy, then the messaging
      association has been established.  That is, local policy may
      dictate that P MUST NOT be forwarded until the messaging
      association establishment has been completed sucessfully.

   The downstream GIST peer then removes the outer IP and UDP headers,
   replaces [inner IP header].SourceAddress with an IP address denoted
   IPTRANS.  This IP address must be chosen in a way that ensures that
   packets sent to IPTRANS will arrive at the downstream GIST peer.
   IPTRANS MUST thus be one of the GIST peer's own IP addresses
   (preferably, but not necessarily, bound to the interface over which P
   will be forwarded), unless in an exceptional situation, explained
   below.  The downstream GIST peer MAY also replace [inner transport
   header].SourcePort with a different source port, denoted PORTTRANS.
   The resulting data packet is forwarded according to the peer's
   routing table.

   A data packet K that arrives from the downstream direction, which
   belongs to same bidirectional data flow as P but flows in the
   opposite direction (i.e. from DR to DS), MUST be mapped to the
   correct UDP tunnel towards the upstream GIST peer.  Moreover, the
   upstream peer (which is the tunnel endpoint) MUST be able to
   demultiplex multiple data flows that may arrive over the same tunnel.
   To this end, the downstream GIST peer MUST use a unique (IPTRANS,
   PORTTRANS) pair for each tunelled data flow.  Note that, in the
   situation where the number of NATs over which the downstream GIST



Pashalidis & Tschofenig  Expires January 9, 2008               [Page 10]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


   node entertains tunnels, exceeds the number of IP addresses that the
   downstream peer may chose IPTRANS from, then the number of tunnels
   may exceed the number of available (IPTRANS,PORTTRANS) pairs (for a
   given transport layer protocol).  The same may happen in the presence
   of tunnels over which multiple data flows are tunnelled.  In such an
   exceptional situation, i.e. when the downstream GIST runs out of
   (IPTRANS, PORTTRANS) pairs (for a given transport layer protocol),
   then it MAY use the public address of the NAT, behind which the data
   flow originates, as IPTRANS.  It should be noted that, in this case,
   routing assymmetry on the path that the packet K takes on its way to
   the downstream GIST node may cause the mechanism to fail, because K
   may never arrive at the downstream GIST node.

   When the downstream GIST peer receives a data packet K, it looks at
   K.[IP header].DestinationAddress, K.[IP header].Protocol, and
   K.[Transport layer header].DestinationPort.  If the downstream GIST
   node behaves as explained above, this triple uniquely defines the
   tunnel, even in the presence of multiple NATs (possibly from multiple
   domains), and multiple tunnels per NAT, as explained above.  Before
   the downstream GIST node forwards K over the tunnel to the upstream
   GIST node, it MUST translate K.[IP header].DestinationAddress and, if
   applicable, K.[IP header].DestinationPort according to the
   translation applied to P. If the aforementioned triple does not match
   an existing tunnel, then normal processing applies to K (whatever
   that means at the downstream GIST node).

   Finally, note that, if the data flow exists before signalling is
   initiated, then the application may be adversely affected by the
   mechanism described in this section.  This is because, prior to
   signalling, the DR sees the public address of the NAT as the address
   of the DS.  However, subsequent to signalling (and the associated
   tunnelling), the DR will see IPTRANS as the address of the DS (and
   may therefore assume that the DS has changed).  In order to avoid
   this, the downstream GIST peer could use the public address of the
   NAT as IPTRANS if the data traffic already flows at the time that
   signalling is initiated.  In order, however, to select the correct
   value for PORTTRANS, the downstream GIST peer must be able to
   correlate the data traffic before tunneling and after tunnelling.
   The source port in the inner transport layer header of a tunneled
   data packet X that belongs to a given flow, is equal to the source
   port of an non-tunneled data packet X' that belongs to the same flow,
   if and only if the NAT binding over which X' travels is source port
   preserving.  Unfortunately, legacy NATs do not always install such
   bindings [4].  It is NOT RECOMMENDED for the downstream GIST peer to
   assume that NAT bindings are source port preserving.  Therefore, the
   mechanism described in this section assumes that data traffic flows
   after signalling state has been setup in the network.




Pashalidis & Tschofenig  Expires January 9, 2008               [Page 11]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


5.1.2.  Treatment of Signalling Traffic

   The processing of GIST messages that arrive over a UDP tunnel adheres
   to the usual rules once the outer IP and UDP headers are stripped
   off.  For GIST messages that the downstream GIST peer sends towards
   the upstream direction, the correct IP/UDP encapsulation must be
   used.  To this end, the peer must keep the necessary state in
   association with the routing state for the upstream GIST peer.  For
   GIST messages that are sent towards the downstream direction, the
   GIST peer must also change the MRI such that it reflects the
   translation for the data traffic.  That is, the peer MUST set
   MRI.SourceIPAddress = IPTRANS and, if applicable,
   MRI.SourcePort=PORTTRANS.

5.1.3.  Refreshing NSIS State

   According to [1], NSIS signalling state must be refreshed regularly.
   To this end, the NI periodically sends GIST QUERY messages which are
   forwarded along the data path.  When the upstream GIST peer receives
   such a QUERY (i.e. a QUERY that has the purpose of refreshing
   signalling state), and if a UDP tunnel already exists for the data
   traffic to which this QUERY refers to, then the upstream peer MUST
   send this QUERY as if no tunnel existed, i.e. as described above.
   This is in order to enable a new GIST node to be identified as the
   downstream peer.  However, the upstream GIST peer SHOULD use the same
   source port in the refreshing QUERY as in the outer UDP header of the
   tunnelled packets.  This is in order to turn the NSIS refresh
   mechanism into a mechanism that keeps the UDP NAT binding alive.
   This is important if no data traffic is sent for an extended period
   of time.

   If the downstream GIST peer receives a GIST QUERY for which a tunnel
   and a GIST messaging association already exists, then it send the
   response over the existing messaging association, in accordance with
   [1].  This involves tunnelling the RESPONSE over the tunnel, as
   descibed above.  If the downstream GIST peer receives a GIST QUERY
   for which a tunnel, but no messaging association exists yet, then, if
   policy permits, the peer sends the RESPONSE as if no tunnel existed.
   In this RESPONSE, the peer MAY propose the same tunnel parameters as
   in the original RESPONSE.

5.2.  Traversal of NR-side legacy NATs

   The traversal of NR-side legacy NATs is not as straight-forward as
   the case of NI-side legacy NAT traversal.  This is because an NR-side
   legacy NAT is likely to block all "unsolicited" incoming traffic.
   That is, such a NAT is unlikely to install a NAT binding on the basis
   of a packet that arrives on its public side.  Instead, such packets



Pashalidis & Tschofenig  Expires January 9, 2008               [Page 12]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


   are typically only forwarded towards the private side, if they match
   an already installed NAT binding.

   The NR-side legacy NAT traversal mechanism descibed in this document
   only works with a certain subset of legacy NATs, namely those that
   are configured with static NAT bindings.  In particular, it is
   assumed that the NR-side legacy NATs are configured to forward all
   incoming UDP packets that are destined to one of the NAT's public
   addresses, and which carry destination port number XXX (Editor's
   note: replace XXX with the well-known port number of GIST), to an
   internal IP address, denoted IPINT.  It is further assumed that IPINT
   is assigned to a GIST node, denoted INTGIST.  It is assumed that
   INTGIST knows the IP addresses assigned to the legacy NAT, and it is
   aware of fact that a static binding points to it.

   A GIST QUERY that arrives at the legacy NAT is now forwarded to
   INTGIST due to the static binding.  INTGIST


6.  Security Considerations

   Editor's note: this section will be completed after normative
   behaviour has been fully specified.


7.  Acknowledgements

   The authors would like to thank Robert Hancock and Martin Stiemerling
   for his insightful comments.


8.  References

8.1.  Normative References

   [1]  Schulzrinne, H. and R. Hancock, "GIST: General Internet
        Signalling Transport", draft-ietf-nsis-ntlp-13 (work in
        progress), April 2007.

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

   [3]  Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal",
        draft-pashalidis-nsis-gimps-nattraversal-03.txt (work in
        progress), June 2006.

   [4]  Audet, F. and C. Jennings, "NAT Behavioral Requirements for



Pashalidis & Tschofenig  Expires January 9, 2008               [Page 13]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


        Unicast UDP", draft-ietf-behave-nat-udp-07 (work in progress),
        May 2006.

   [5]  Rosenberg, J., Tschofenig, H., Huitema, C., Mahy, R., and D.
        Wing, "Simple Traversal of UDP Through Network Address
        Translators (NAT) (STUN))", draft-ietf-behave-rfc3489bis-03
        (work in progress), February 2006.

8.2.  Informative References

   [6]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network
        Address Translations (NATs)", RFC 4380, February 2006.

   [7]  Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
        Underneath NAT (STUN)", draft-ietf-behave-turn-03 (work in
        progress), March 2007.


Authors' Addresses

   Andreas Pashalidis
   NEC
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Email: Andreas.Pashalidis@netlab.nec.de


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

   Email: Hannes.Tschofenig@nsn.com















Pashalidis & Tschofenig  Expires January 9, 2008               [Page 14]

Internet-Draft        Legacy NAT traversal for GIST            July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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


Intellectual Property

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

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

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


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Pashalidis & Tschofenig  Expires January 9, 2008               [Page 15]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/