Internet DRAFT - draft-stiemerling-nsis-natfw-mrm

draft-stiemerling-nsis-natfw-mrm







NSIS Working Group                                        M. Stiemerling
Internet-Draft                                                       NEC
Expires: January 18, 2006                                  July 17, 2005


            Loose End Message Routing Method for NATFW NSLP
                  draft-stiemerling-nsis-natfw-mrm-02

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 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo describes the use cases and solution for a new NTLP message
   routing method (MRM) that is used by the NATFW NSLP protocol to
   locate Network Address Translators (NAT) on the upstream data path.
   This message routing method is used by NSIS NATFW nodes behind a NAT
   to allocate a public reachable IP address and/or port number.  The
   current way to do so has been named as "signaling the wrong way" and
   should be replaced by the proposed message routing method.  The scope
   of this memo is limited to the usage of locating upstream Network
   Address Translator.



Stiemerling             Expires January 18, 2006                [Page 1]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Signaling the Wrong Way  . . . . . . . . . . . . . . . . . . .  5

   3.  Loose End Message Routing Method . . . . . . . . . . . . . . .  8

   4.  GIMPS Message Routing Method . . . . . . . . . . . . . . . . . 11
     4.1   Signaling Destination Address  . . . . . . . . . . . . . . 11

   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 12

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13

   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 14
     7.2   Informative References . . . . . . . . . . . . . . . . . . 14

       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14

   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15

       Intellectual Property and Copyright Statements . . . . . . . . 16



























Stiemerling             Expires January 18, 2006                [Page 2]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


1.  Introduction

   The NATFW NSIS Signaling Layer Protocol (NATFW NSLP) [4] describes a
   path-coupled protocol to configure Network Address Translators (NATs)
   and firewalls to let subsequent data traffic traverse these devices.
   The NSIS Transport Layer Protocol (NTLP) [3] is used to route those
   NATFW NSLP signaling messages on the data path.  Typically, the NATFW
   NSLP signaling messages are initially sent downstream, meaning from
   data sender to data receiver, and responses are sent upstream, from
   receiver to sender.  In this case, the data sender, and the NATFW
   NSLP, know the final receiver of the data flow.  Commonly, this
   scenario is referred to sender behind NAT or firewall (see Section
   2.3 of [4]).

   Another scenario, described in Section 2.4 of [4], describes a data
   receiver behind a NAT.  Data receivers located in a network that is
   separated by a NAT from the public network are not directly
   addressable by means of IP addresses.  These data receivers are using
   private IP addresses, only meaningful in their private network.  To
   receive data from outside this private network, data receivers must
   first obtain a globally routable IP address (public IP address).
   This public IP address is located at the NAT of the network and is
   usually used in application level signaling exchanges to inform the
   data sender where to send its data.  Note that there may be several
   NATs connecting this private network to the public network, NATs can
   be placed in parallel or NATs can be placed in sequence.  Figure 1
   shows such a network configuration.  The local network can consist of
   several other Firewalls or NATs located on the data path and NSIS
   signaling path.

              //------\\    +------+     /----------\
        DR ---|  Local |----| edge |----|  Internet |---- DS
              | Network|    | NAT  |     \----------/
              \\------//    +------+

                private                     public


             DS: Data sender
             DR: Data receiver

                    Figure 1: Data Receiver behind NAT

   When a data receiver knows the data sender's IP address (at least),
   it will send its NSIS NATFW NSLP signaling message upstream towards
   this address.  The NTLP must forward this signaling message upstream
   and the NATFW NSLP will stop the forwarding process a the outermost
   NAT, the so-called edge-NAT.  The NATFW NSLP message type to be used



Stiemerling             Expires January 18, 2006                [Page 3]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


   for this upstream signaling is RESERVE-EXTERNAL-ADDRESS (REA).

   The above described assumes that the data receiver knows the IP
   address of the data sender in advance.  However, in many applications
   the IP address of the data sender is not known in advance, such as
   SIP.  In this case the NATFW NSLP signaling message for REA cannot be
   sent upstream towards the ultimately IP address of the data sender.
   Nevertheless, to get a public reachable IP address the data receiver
   must somehow find the external NAT and allocated an IP address or
   port number, depending on the NAT type.

   This document focuses on NATs only and does not consider firewalls.
   Limiting the scope of this document to NATs only has a simple but
   compelling reason:  Locating upstream firewalls and NATs is not a
   simple task to be performed by NSIS.  Other working groups, such as
   IETF's ICMP traceback, trying to find the path of data streams
   upstream, from  data receivers to data senders.  This seems to be a
   non-trivial task for the regular Internet with a single IP address
   space.  This applies to networks with firewall deployments too.
   Networks using a private IP address space are easier to handle in
   this case:  NSIS just needs to find an edge-NAT that is the border
   between the public Internet and the private network.  The IP address
   and port number allocated at the edge-NAT by means of NATFW NSLP's
   REA message is in fact a route pinning and thus  all traffic will
   traverse this single edge-NAT.

   Section 2 describes the current proposed way of locating the external
   NAT and requesting an external IP address and port number (as
   described in in [4]).  The new proposed way of locating the NAT is
   described in Section 3.

   The terminology used throughout this memo is aligned to the NSIS
   terminology.


















Stiemerling             Expires January 18, 2006                [Page 4]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


2.  Signaling the Wrong Way

   The NATFW NSLP protocol specification defines a mechanism to locate
   upstream NATs;  This mechanism is commonly referred to as signaling
   the wrong way (see Section 5.4.2 in [4].)  This way of signaling uses
   a faked data sender's address and sends the RESERVE-EXTERNAL-ADDRESS
   (REA) message against the intended direction of the data stream
   towards the faked address.  This REA messages uses the standard
   downstream message routing method (MRM) defined in NTLP [3].



                              edge NAT
                              +------+
                              |NATFW |                  +----+
                            .'+NSLP  `.                 ' OA |
                           /  |w/ NAT| \   ,-----.      +----+
               +------+  .'   +------+  `./       .       NR+
     +----+    |NATFW | /                /         \
     | NR |----+NSLP  |+                (  Internet )
     +----+    |w/ NAT| \                \         /
       NI+     +------+  `.   +------+   .'       `.
                           \  |NATFW | .'  `-----'  `.  +----+
                            `.+NSLP  .'               `.| NI |
                              |w/ NAT|                  +----+
                              +------+
                              edge NAT



                       Figure 2: NATFW NSLP elements

   Figure 2 shows a typical network topology for data receivers behind
   NATs.  The figure denotes the data receiver as NSIS NATFW NSLP
   receiver (NR) and the data sender as NSIS NATFW NSLP initiator (NI).
   NR+ denotes an arbitrary IP address, named as Opportunistic Address
   (OA).  The naming convention NR/NI refers to the CREATE signaling
   where the data sender is initiating the signaling.  The naming
   convention printed below the particular boxes (NI+ and NR+) refer to
   the REA signaling where the data receiver is initiating the NATFW
   NSLP signaling.

   The data receiver acting as NI+ sets the NTLP message routing
   information (MRI) for the REA message as follows

   o  the NTLP signaling destination address is set to the faked data
      sender's address (Opportunistic Address, NR+),




Stiemerling             Expires January 18, 2006                [Page 5]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


   o  the NTLP signaling source address is set to data receiver's
      address (NI+), and

   o  the signaling direction is set to downstream.

   Further information like port numbers, transport protocol, etc might
   be set in the MRI, too.  The NSLP uses the RESERVE-EXTERNAL-ADDRESS
   (REA) request message.  The signaling message is sent downstream to
   NR+, intercepted and processed by NATFW NSLP nodes implementing
   Network Address Translation (NAT).  NATFW NSLP nodes implementing
   just firewall functionality, forward the message, unless they are
   edge-firewalls.  Edge-firewalls stop the message forwarding and do
   reply with an error response 'no NAT here' to indicate that there is
   no NAT on this path.  Each NAT on the path takes the message and
   processes it.  An IP address/port is reserved at the NAT, but not
   enabled, and the translation is prepared for future use.  Reserved
   and prepared refers to getting all necessary configurations done at
   the NAT to enable later translations immediately.  The message is
   forwarded until it reaches an edge-NAT.  The edge-NAT stops the
   message forwarding and replies with a response message indicating the
   reserved external IP address/port number.  This IP address and port
   number can now be used by the application at the NR to indicate its
   reachable address to other parties.

   To enable data transmission, a real NSIS initiator (NI) must now send
   a CREATE request message to the allocated IP address/port number at
   the edge-NAT.  This CREATE request message enables the NATs and
   firewalls to forward the data packets.  The defined rules for
   processing and forwarding CREATE apply, meaning that these messages
   are sent from NI to NR and install NSIS state and firewall/NAT rules
   in the NATFW NSLP nodes.  Note that the NSIS initiator of this CREATE
   message is not necessary the same as used by the REA message noted as
   NI+.

   This method of locating upstream NATs on the data path installs
   several states on NTLP and NSLP level.  First of all, state is
   installed on the NTLP level from NR to the edge-NAT with the final
   destination address set to NR+ at each NATFW NSLP node.  This state
   must be maintained with REA refresh messages, since it is subject to
   the regular timeout handling.  Second, with the arrival of the CREATE
   message at NR, the state for REA must be removed since it is no
   longer used.  Instead of this, the state for CREATE must be
   maintained.  The state built during the REA phase is probably never
   used by any incoming CREATE request message and is to a certain
   degree misleading, since NI+ is not the real NSIS initiator.
   Figure 3 shows the state installed for REA and CREATE in a mixed
   firewall and NAT environment.




Stiemerling             Expires January 18, 2006                [Page 6]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


                Firewall
                +------+
                |NATFW |                                +----+
       *********|NSLP  |********                        | OA |
       *        |w/ FW |       *           ,-----.      +----+
       *        +------+    +--*---+      /       \       NR+
     +-*--+                 |NATFW |     /         \
     | NR ++++              |NSLP  |    (  Internet )
     +----+  +            +++w/ NAT+++  \         /
       NI+   +  +------+  + +------+ +    \       /
             +  |NATFW |  + edge-NAT +     `-----'      +----+
             ++++NSLP  ++++          +++++++++++++++++++| NI |
                |w/ FW |                                +----+
                +------+
                Firewall


             ****: State created by REA
             ++++: State created by CREATE



                   Figure 3: Installed NATFW NSLP state

   The figure shows a scenario with routing asymmetry on the path
   between the edge-NAT and the NR.  This highlights that the path taken
   by REA signaling messages and CREATE signaling messages must not be
   the same and must be treated independently.  Keeping state involves
   the setup and maintenance of NTLP connection mode (C-MODE, most
   likely TCP based) between all neighboring NSIS peers running the
   NATFW NSLP.  Figure 3 shows that REA state is kept between NR and the
   firewall and the edge-NAT but is never used in subsequent signaling
   for CREATE.

   The 'signaling the wrong way' approach seems to be more a work around
   solution instead of a proper one that is well understood.  Therefore,
   the next section proposes a new way of spotting the NAT, minimizing
   state and giving a clean way of finding NATs even without knowing the
   data sender.












Stiemerling             Expires January 18, 2006                [Page 7]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


3.  Loose End Message Routing Method

   This section proposes a new message routing method (MRM) to find NATs
   on the network side of data receivers.  As described earlier, some
   applications require the retrieval of  a public reachable IP address/
   port number without knowing where the data traffic is coming from,
   meaning that data sender and thus the later NSIS initiator (NI) is
   unknown, and without being required to have knowledge about the
   network topology.  For the first reason, signaling messages must be
   sent to a faked address NR+, resulting in a loose end with respect to
   the signaling since this not the actual fixed sender's address but an
   imaginary IP address located in the public IP space.  This faked
   address of the NSIS sender NR+ is called signaling destination
   address (SDA) within this document.  The current NATFW NSLP
   specification uses the term Opportunistic Address, see also Section 2
   of this memo.

   The loose end message routing method (LEMRM) requires that the NTLP
   routes messages upstream from NI+ to NR+ and that NATFW NSLP nodes
   implementing NAT are processing these messages only.  All other NTLP
   nodes just forward the messages and NATFW NSLP nodes implementing
   firewall functionality do not process this messages at all.  The
   processing at NATs and edge-NATs regarding NAT configuration is
   performed as described in Section 2.  NTLP and NSLP state is kept at
   the NATs that intercepted and processed the REA message.  All other
   messages, such as responses and repeated REAs for state refresh, are
   exchanged directly between NATFW NSLP nodes involved.  Through this,
   state to be maintained is minimized and only the NR and NATFW NSLP
   nodes with NAT functionality are forced to keep this NTLP and NSLP
   state.

   A NR using the REA request message must set NTLP's MRI to signaling
   destination address (SDA, NR+) as destination-address and its own
   address NR as source-address.  A new field (yet to be defined)
   indicates to the NTLP that the destination-address is not the real
   NSIS initiator's (NI) address, but the SDA and that LEMRM must be
   used for routing this message.  The NTLP routes the REA message
   upstream to towards the SDA via D-MODE.  NATFW NSLPs implementing NAT
   functionality intercept and process the REA message according [4].
   Edge NATs stop the message forwarding.  NTLP C-MODE connections are
   being established between neighboring NATFW NSLP peers that implement
   NAT functionality.  Figure 4  shows the state installed for REA and
   CREATE in a mixed firewall and NAT environment when using LEMRM.








Stiemerling             Expires January 18, 2006                [Page 8]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


                Firewall
                +------+
                |NATFW |                                +-----+
                |NSLP  |                                | SDA |
                |w/ FW |                   ,-----.      +-----+
                +------+    +------+      /       \       NR+
     +----+******************NATFW |     /         \
     | NR ++++              |NSLP  |    (  Internet )
     +----+  +            +++w/ NAT+++   \         /
       NI+   +  +------+  + +------+ +    \       /
             +  |NATFW |  + edge-NAT +     `-----'      +----+
             ++++NSLP  ++++          +++++++++++++++++++| NI |
                |w/ FW |                                +----+
                +------+
                Firewall


             ****: State created by REA
             ++++: State created by CREATE



                Figure 4: LEMRM installed NATFW NSLP state

   This approach raises questions with respect to intermediate NATFW
   NSLP nodes implementing firewall functionality only.  Detecting
   neighboring NTLP nodes, and NSLP nodes, is done by using NTLP's
   D-MODE GIMPS-query and  GIMPS-response messages.  Assuming UDP as
   transport protocol, with router alert option set, intermediate
   firewalls need to forward these packets and remember firewall state
   locally (this is not NATFW state).  A NATFW NSLP aware edge-NAT on
   the data path will intercept this UDP packet and respond back to the
   particular signaling source.  This UDP packet is routed back to the
   signaling source and uses the regular standard routing.  The packet
   will reach the firewall with stored state with symmetric routes
   between the edge-NAT and the signaling source and is going to be
   forwarded further.  Asymmetric routing, as shown in Figure 4, will
   forward the packet to the wrong firewall that most likely drops the
   packet.  The LEMRM as described above makes these assumptions:

   o  Intermediate firewalls allow UDP packets of the NTLP D-MODE
      exchange to traverse in both directions, from internal to external
      and vice versa.  At least they allow UDP packets being initiated
      from internal side to external and back by storing state for this
      UDP packet.

   o  Symmetric routes are in place.




Stiemerling             Expires January 18, 2006                [Page 9]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


   o  TCP connections initiated from the NSIS peer located internally
      (the upstream peer) are allowed to traverse towards the NSIS peer
      located externally (the downstream peer).  In the above figure NR
      is able to initiated a TCP connection to the edge-NAT.  This
      assumes TCP for C-MODE.

   Assuming other transport protocols than TCP and UDP will result in
   even more complicated problems, since firewalls usually understand
   TCP and UDP at best.

   The LEMRM may require intermediate NATFW NSLP peers implementing
   firewall functionality to store NTLP/NSLP state.

   A real NSIS initiator (NI) can use the via REA allocated IP address/
   port number to send its CREATE request message to.  The CREATE
   message is processed as in [4] and requires a new path discovery from
   edge NAT towards NR.  This path discovery will located all NATFW NSLP
   nodes (firewalls and NATs) along the data path and enable the data
   path from NI to NR.
































Stiemerling             Expires January 18, 2006               [Page 10]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


4.  GIMPS Message Routing Method

   This section describes the message routing method (MRM) definition
   for GIMPS of the LEMRM.  Section 3.3 of [3] outlines the elements
   need for a MRM definition.  The elements of the LEMRM are:

   o  Path-coupled transport is required.

   o  Flow-identifier as defined in Section 5.7.1.1 of [3].  The source-
      address field must be set to the data sender's address (NI), if
      known.  Otherwise, this field must be wildcarded.  The
      destination-address field must be set to data receiver's address
      (NR, NI+).  All other fields of the flow-identifier are set
      accordingly to the source or destination properties, for instance,
      the destination's port number.

   o  Signaling direction is upstream.

   o  A new object containing the signaling destination address (SDA).
      The signaling destination address must contain a publicly
      reachable IP address and must not contain a private IP address
      defined in [8].

   o  The QUERY encapsulation follows the same rules as defined in
      Section 5.7.1.2 of [3] with the exception of using the SDA as
      signaling destination.  The destination address must be set to the
      SDA and the source address must be set to NR's address.


4.1  Signaling Destination Address

   The signaling destination address (SDA) object contains the IP
   address of NR+.

      Type:   Signaling-Destination-Address

      Length: 1 for IPv4 and 4 for IPv6.



     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                        SDA                                  //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 5





Stiemerling             Expires January 18, 2006               [Page 11]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


5.  Conclusions

   This memo discusses a new message routing method for the NATFW NSLP.
   This new MRM is intended to replace the current proposed 'signaling
   the wrong way' approach.  Apparently, LEMRM concerns two layers of
   the NSIS stack, the NTLP and NATFW NSLP.  Message routing is part of
   the NTLP layer and state setup is part of the NATFW NSLP layer.  This
   separation is not yet fully described in this document.











































Stiemerling             Expires January 18, 2006               [Page 12]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


6.  Security Considerations

   Security considerations are to be done.
















































Stiemerling             Expires January 18, 2006               [Page 13]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


7.  References

7.1  Normative References

   [1]  Klensin, J., "Terminology for Describing Internet Connectivity",
        BCP 104, RFC 4084, May 2005.

   [2]  Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
        April 2004.

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

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

7.2  Informative References

   [5]  Srisuresh, P. and M. Holdrege, "IP Network Address Translator
        (NAT) Terminology and Considerations", RFC 2663, August 1999.

   [6]  Srisuresh, P. and K. Egevang, "Traditional IP Network Address
        Translator (Traditional NAT)", RFC 3022, January 2001.

   [7]  Tsirtsis, G. and P. Srisuresh, "Network Address Translation -
        Protocol Translation (NAT-PT)", RFC 2766, February 2000.

   [8]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
        Lear, "Address Allocation for Private Internets", BCP 5,
        RFC 1918, February 1996.


Author's Address

   Martin Stiemerling
   Network Laboratories, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 (0) 6221 905 11 13
   Email: stiemerling@netlab.nec.de
   URI:   http://www.stiemerling.org






Stiemerling             Expires January 18, 2006               [Page 14]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


Appendix A.  Acknowledgments

   The author would like to thank Robert Hancock, Hannes Tschofenig, and
   Cedric Aoun for discussing the LEMRM.















































Stiemerling             Expires January 18, 2006               [Page 15]

Internet-Draft             NSIS NATFW NSLP MRM                 July 2005


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

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


Acknowledgment

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




Stiemerling             Expires January 18, 2006               [Page 16]