Internet Draft                                                C.Aoun
   Category Informational                               Nortel Networks
   Expires on September 2003                             March 1st 2003

               NSIS Network Address Translator implications

                   < draft-aoun-nsis-nat-imps-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   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-

   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
   The list of Internet-Draft Shadow Directories can be accessed at


   This Internet draft discusses Network Address Translators impacts on
   in path directed signaling. The purpose of this memo is to provide
   inputs to the NSIS WG on Middlebox specific considerations.

Table of Contents

   Status of this Memo................................................1
   1  Overview.......................................................2
   2  Conventions used in this document..............................2
   3  Used terminology...............................................2
   4  In path signaling NAT complications............................3
   5  Proposed solution..............................................3
   6  Peer to peer application applicability.........................7

   Aoun                     Informational        Expires April 2003 1

                        NSIS NAT implications              March 2003

   7  NSIS NAT and Firewall transitions issues.......................7
   8  Security Considerations........................................9
   9  Summary.......................................................10
   10 References....................................................10
   11 Acknowledgments...............................................10
   12 AuthorÆs Addresses............................................10
   13 Full Copyright Statement......................................11

1  Overview

   In path directed signaling is used in the Internet to allocate
   resources from network nodes. The allocated resources could be
   bandwidth, packet filter pinhole, network address translator binds
   and other resource types.

   When an NSIS Initiator (NI) ([NSISFW]) sends an in path signaling
   message to the NSIS Responder (NR) ([NSISFW]), it needs to know the
   address of the NR. When a NAT is not in the path between the NI and
   NR there is no issue for the NI to guess the NR address, however
   when one of the NSIS NF co-hosts a NAT function it is a complicated

   This Internet draft will address the above-mentioned matter by
   providing dynamic means of discovering the ôcontact informationö of
   NR behind NATs.

   In addition the document covers generic NAT implications on NSIS for
   both NSIS aware NATs and non NSIS aware NATs and their coexistence.

2  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC-2119.

3  Used terminology

   All the used NSIS terminology is consistent with [NSISFW]

   NF: NSIS Forwarder

   NI: NSIS Initiator

   NR: NSIS Responder

   NE: NSIS Element, one of the above 3 components

   CASP: Common Application Signaling Protocol

    Aoun                     Informational   Expires September 2003 2

                        NSIS NAT implications              March 2003

   ALSP: Application Layer Signaling Protocol
4  In path signaling NAT complications

   We shall discuss the in path signaling NAT complications by looking
   at a simple network deployment.
   The NI and NR are co-hosting an application client.

   +-----------------------+    +------------+  +---------------------+
   + NI/AC1 ---------MB1/NF+----+The Internet+--+ MB2/NF-------NI/AC2 +
   +                       +    +------------+  +             a.b.c.d +
   +-----------------------+                    +---------------------+
      Network x                                         Network y
                                Application Server 1

                                 Figure 1

   In the used example Application Client 1 (AC1) and AC2 use
   Application server 1 (AS 1) as their server for registration and
   location purposes as well as to proxy their application messages.

   MB1 and MB2 are Middle boxes, as defined in [MDCMFW], that apply NAT
   functions and behave as an NSIS Forwarder as specified in [NSISFW].

   When AC1 wants to establish an application session with AC2, it will
   need to request from the Middleboxes on the data path an address and
   port bind.

   In order to do so it needs to know to which address and transport
   port it needs to send the in path signalling message.
   The Middleboxes on the path prevents that, unless having an existing
   static bind already configured on the Middlebox and known by all NIs
   that would communicate with the specified NR. This would introduce a
   lot of operational complexity and would not scale.

5  Proposed solution

   As shown in figure 1, several applications require an application
   server for registration purposes or for continuous message proxying

   We could use this applicationÆs specificities to solve the above

   When AC1 registers with AS1, AS1 would have a softstate giving the
   status of AC1Æs reachability, which includes the last source address
   and source port that brought the application Protocol Data Unit
   The same applies to AC2.

   When AC1 wishes to establish an application session with AC2, AS1
   would provide AC2Æs ôcontact informationö. This contact information

    Aoun                     Informational   Expires September 2003 3

                        NSIS NAT implications              March 2003

   will be the address and source port on which AC2 could receive
   application signalling.

   As AC2 is deployed behind MB2, a bind already exists in MB2Æs NAT
   mapping table.

   Sample from MB2 NAT mapping table:

   Protocol  int address  int port  ext address  ext port
   UDP          a.b.c.d         w       e.f.g.h         x

   AC2 ôcontact informationö consists of e.f.g.h and port x.

   When AC1 receives AC2Æs contact information it will request the NI
   API to send an in path signalling message to e.f.g.h as well as to
   provide AC2Æs contact information within the messageÆs SDU.

   When an NSIS NF receives the in path signalling message it will look
   at the ôcontact informationö and then look at its NAT mapping table.
   Based on the mapping it will find out that the destination of the
   signalling message is a.b.c.d.
   The NF will then forward the message to a.b.c.d which is the real
   recipient of the NSIS message.

   Figures 2 and 3, shows message sequences of the mode of operation
   for the proposed method of signalling NEs when NATs are in the path.

   Figure 2 shows how the æContact InformationÆ is gathered.

   Figure 3 shows how an NE discovers the next hop NE in the path
   towards the end destination, more information on next hop NE
   discovery could be found in [CASP] within the SCOUT related
   Analysis done in [CASP] and [CASP-NATFW] show that in order to
   secure NSIS signalling, the discovery of the next hop peer NE needs
   to be separate from installing policy rules on the NSIS aware NATs
   and firewalls.
   Once the next hop peer NE is discovered, a security association is
   established with it as specified in [CASP] and then policy rule
   installation will proceed as discussed in [CASP-NATFW].

    Aoun                     Informational   Expires September 2003 4

                        NSIS NAT implications              March 2003

   NE1/AC1              NF1             AS1             NF2     NE2/AC2
                                                        User apps
                                                        NAT bind
                                           User apps
                                        User apps message
                                        Came from e.f.g.h:x, it
                                        Is linked to AC2,
                                        AC2 æContact InformationÆ =
                                        e.f.g.h:x UDP
                                        .Same done with AC1

                                   Figure 2

   Initiate user app
        With AC2
                        Initiate user app
                        With AC2
   NE1/AC1              NF1             AS1             NF2     NE2/AC2
                        AC2 æContact InformationÆ
                        e.f.g.h:x UDP
                        < ---------------

   AC2 æContact InformationÆ
   e.f.g.h:x UDP
   < ---------------

   NSIS Nxt hop discovery msg
   AC2 æContact InformationÆ
   e.f.g.h:x UDP
   -------------------- >
                        NF1 will keep a state
                        Related to the msg originator

                        NSIS Nxt hop discovery msg
                        AC2 æContact InformationÆ
                        e.f.g.h:x UDP
                                                   InformationÆ maps to
                                                   a.b.c.d host.

    Aoun                     Informational   Expires September 2003 5

                        NSIS NAT implications              March 2003

   NE1/AC1              NF1             AS1             NF2     NE2/AC2

                                                   Need to transfer
                                                   message to
                                                   a.b.c.dNF2 keeps an
                                                   associated state to
                                                   the received message
                                                   including from where
                                                   message came from

                                                NSIS Nxt hop discovery
                                                msg AC2 æContact
                                                InformationÆ a.b.c.d:w

                                                        < ----------
                                        < ---------------


   < ---------------
                                Figure 3

   RESPONSE message in figure 3, provides information on the next hop
   NE, this may include the NE capabilities.

5.1 Proposed methodÆs implications on the NSIS framework

    The integration of the proposed solution within NSIS would only
    impact the Middlebox specific CASP client [CASP] or ALSP [2level].

    Only NFs supporting the Middlebox specific client will need to
    apply the operation depicted above.

5.2 Multi-homing considerations

   In case there are several NATs a the edge of local network, it is
   quite possible that the discovery phase of the æContact InformationÆ
   was based on traversal of a specific NAT that is not the one in the
   natural path of the remote application end point. Hence NSIS
   signaling could traverse a different NAT than the one traversed by
   the data flows exchange between the user application clients.

    Aoun                     Informational   Expires September 2003 6

                        NSIS NAT implications              March 2003

   To solve the multi-homing problem, proper anchoring mechanisms
   should be used to ensure that the data flows will be traversing the
   same NFs as the one traversed by the signaling.

   Current known packet anchoring mechanisms:

                a) Twice NAT, as defined in [NAT], translates both the
                source and destination addresses (and transport ports)

                b) Source routing

    Option a) is quite controversial as the Internet architecture
    evolution is going towards of getting rid of NATs.

    Option b) is also controversial as source routing is not much
    supported in the Internet today, but it could be less controversial
    as the source routing is required within the local network.

    In case a) is used, it implied that the NSIS-NATFW client supports
    the concept of a local destination address/port pair.
    When the NSIS-NAT/FW client provides an address/port pair to the
    application client it will need to also provide a local destination
    address/port pair. That local destination address/port pair will be
    a recipient on a specific NSIS aware NAT. That NAT will obviously
    be the same one as the one traversed by the NSIS signaling and the
    used message to discover the æContact InformationÆ.

    In case b) is used, the NSIS-NATFW will need to have the capability
    to specify the next hop in a source route specific object. This
    next hop will be specified within a source route option for data
    packets being transmitted between the 2 user application clients.

6  Peer to peer application applicability

   The proposed method is also applicable to peer to peer applications.
   When an application client is peering with another one, it could
   provide to its NSIS NI API the address and port from which it has
   received the application signaling from the remote peer.
   This information will be formatted as the ôcontact informationö and
   sent within the CASP Middlebox specific client or the Middlebox
   specific ALSP.

7  NSIS NAT and Firewall transitions issues

   As there is no D day where all deployed NATs and Firewalls will
   support NSIS, proper analysis should be done to understand how we
   could minimize the co-existence issues between NSIS-NATFW clients
   and existing none NSIS aware NATs and firewalls.

    Aoun                     Informational   Expires September 2003 7

                        NSIS NAT implications              March 2003

7.1 Traversed Firewall is not NSIS aware

   In case a NSIS unaware firewall is traversed by NSIS messages, NSIS
   messages should be allowed to go through it, as well as the data
   flows exchanged between the user application clients. This is not
   necessarily an obvious task to perform in case the NSIS messages
   canÆt be identified by the NSIS unaware firewall. Same applies for
   the user application data flows.

7.1.1 NSIS message identification

        NSIS message identification should be supported by existing
        firewall. Currently firewalls support flow identification by
        using the 5 tuple or a sub-set of it. We canÆt assume that the
        firewall will support router alert option ([Ralert]) and even
        if it did support it, it may mean something else.

7.1.2 User application Data flow identification

        User application data flow identification, should be
        deterministic at some level. Normally this means that the
        application clients uses a combination of an address and
        specific transport port range. This combination should be
        configured on the firewall.

   NE1/AC1      NSIS-unaware FW                 NSIS-NATFW FW   NE2/AC2

                                Figure 5
7.1.3 NSIS-NATFW aware NF is deployed in the path

        In case a NAT is deployed on the path and it is NSIS-NATFW
        client aware ([CASP-NATFW]), then assigned bind should be
        consistent with policy rules configured with the NSIS unaware

   NE1/AC1      NSIS-unaware FW                 NSIS-NATFW NAT  NE2/AC2

                Policy rules configured
                To allow specific filters
                For NSIS signaling and user
                Application data flows

                                Figure 6

    Aoun                     Informational   Expires September 2003 8

                        NSIS NAT implications              March 2003

7.2 Traversed NAT is not NSIS-NATFW aware

   NE1/AC1                              NSIS unaware NAT        NE2/AC2
                                Figure 7

   In case an NSIS unaware NAT is on the path of packets from AC2
   towards AC1, the following could be applicable.

   NE2 sends an NSIS message towards NE1, we assume that æContact
   InformationÆ method is used. When the NSIS message reaches the NSIS
   unaware NAT the NAT doesnÆt translate the filter attribute [CASP-
   NATFW]. When NE1 receives the NSIS message it will know that there
   is an NSIS unware NAT in the path, and will provide this information
   within  the response to NE2. All consequent NSIS messages between
   NE1 and NE2 will now include this information.

   NE2 will then provide the filter matching the data flows to be
   exchanged between AC1 and AC2 and send this information within an
   NSIS message to NE1. That NSIS message will be sent by using the
   same transport protocol than the data flows to be exchanged between
   the user application client (AC1 and AC2).

   When NE1 will receive the NSIS message it will replace the filter
   attribute with the source address and source transport port

   This implies that the NSIS-NATFW implementation on NE1 and NE2
   supports the same transport protocol as the one used for the data

   The generic requirement on NSIS will be that it should be
   transported on several transport protocols, changing from one
   transport protocol to the other should be based on specific events
   as shown above.

8  Security Considerations

   As the ôcontact informationö is provided by the application
   protocol, proper authentication mechanisms MUST be put in place to
   avoid having false ôcontact informationö that would generate man in
   the Middle attacks.
   The NSIS security mechanisms will not be required any modifications.

    Aoun                     Informational   Expires September 2003 9

                        NSIS NAT implications              March 2003

9  Summary

   This draft proposes a realistic solution that will allow NSIS NR to
   be deployed behind NSIS NF co-hosting NAT functions.
   This draft doesnÆt discuss all the specificities of the Middlebox
   ALSP ([2level],[CASP-NATFW]), other implications should be
   considered as the ones discussed in [CASP-NATFW].
   In addition the draft provides inputs on transition issues when
   deploying NSIS-NATFW signaling application with existing NAT and
   Firewalls in the path.

10 References

        [NSISFW] Ilya Freytsis et all, Next Steps in Signaling:
        Framework, draft-ietf-nsis-fw-00.txt, work in progress

        [2level] R. Braden and B. Lindell, A Two-Level Architecture for
        Internet Signaling, draft-braden-2level-signaling-01.txt, work
        in progress

        [CASP] H. Schulzrinne et all, CASP - Cross-Application
        Signaling Protocol, draft-schulzrinne-nsis-casp-01.txt, work in

        [CASP-NATFW] H. Tschofenig et all, A Firewall/NAT Traversal
        Client for CASP, draft-tschofenig-nsis-casp-midcom-01.txt, work
        in progress

        [MDCMFW] P.Srisuresh et all, Middlebox communication
        architecture and framework, RFC 3303,August 2002

        [NAT] P. Srisuresh, ôIP Network Address Translator (NAT)
        Terminology and Considerationsö, RFC 2663, Internet Engineering
        Task Force, Aug. 1999

        [Ralert] D. Katz, ôIP Router Alert optionö, RFC 2113, IETF,
        February 1997

11 Acknowledgments

   The authors would like to thank Louis-Nicolas Hamer for his
   comments related to this draft.

12 AuthorÆs Addresses

   Cedric Aoun
   Nortel Networks

    Aoun                     Informational   Expires September 2003 10

                        NSIS NAT implications              March 2003


13 Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.  The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its successors or
   assigns.  This document and the information contained
   herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND

    Aoun                     Informational   Expires September 2003 11