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

Versions: 00

Internet Engineering Task Force                                 D. Klein
Internet-Draft                                               M. Hartmann
Expires: January 6, 2011                                        M. Menth
                                                 University of Wuerzburg
                                                            July 5, 2010


                   NAT Traversal for LISP Mobile Node
                  draft-klein-lisp-mn-nat-traversal-00

Abstract

   The Locator/Identifier Separation Protocol (LISP) is a new naming and
   addressing architecture to solve the Internet's routing scaling
   problem.  It separates global routing in the Internet from local
   routing and naming in end-user networks.  The basic LISP architecture
   does not support mobility.  The mobility extension LISP Mobile Node
   (LISP-MN) describes a mechanism that extends LISP to support mobile
   nodes and enables them to roam into LISP and non-LISP networks while
   being reachable under the same address.  Currently, LISP-MN does not
   support networks that use network address translation (NAT).  This
   document presents an extension for LISP-MN that makes LISP mobile
   nodes behind a NAT globally reachable.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 6, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Klein, et al.            Expires January 6, 2011                [Page 1]


Internet-Draft            LISP-MN NAT Traversal                July 2010


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Architecture Overview  . . . . . . . . . . . . . . . . . . . .  6
   5.  NAT Traversal Mechanism  . . . . . . . . . . . . . . . . . . .  7
     5.1.  Control Plane Operations . . . . . . . . . . . . . . . . .  7
     5.2.  Data Plane Operations  . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

























Klein, et al.            Expires January 6, 2011                [Page 2]


Internet-Draft            LISP-MN NAT Traversal                July 2010


1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Introduction

   The Locator/Identifier Separation Protocol (LISP) [LISP] separates
   naming and local routing in edge networks from global routing in the
   Internet.  Special endpoint identifiers (EIDs), which are independent
   of the global routing, are used to distinguish end-hosts on a global
   scale.

   The basic LISP architecture does not support mobility of end-hosts.
   The extension LISP Mobile Node (LISP-MN) [LISP-MN] describes a
   mechanism that enables MNs to roam into LISP sites and non-LISP
   networks while being reachable under the same EID.  The operation of
   LISP-MN is illustrated and analyzed for different networking
   scenarios in [MEKL10].  When a MN roams into a network, it receives a
   new address from the network, e.g., from DHCP.  To be reachable as a
   LISP node by its EID, it registers this address in the global LISP
   mapping system.

   In a non-LISP network without NAT, the assigned address serves as
   globally reachable routing locator (RLOC).  When packets are sent to
   the EID of the MN, the RLOC of the MN is requested from the mapping
   system and the packets are encapsulated and tunneled to this RLOC.
   The MN acts like an ETR, decapsulates the traffic, and receives the
   actual packets.  When the MN wants to send traffic to another node,
   it acts like an ITR.  If the other node is in a LISP site, it
   encapsulates the traffic towards the RLOC of this LISP site.  If the
   other node has a globally reachable IP address, the MN encapsulates
   the traffic towards its configured proxy ETR.  This proxy ETR
   decapsulates the traffic and forwards it to the other node.  If the
   MN roams into a LISP network, the operation is more complex, but the
   details are not relevant in this draft.

   If the MN roams into a network using network address translation
   (NAT), the MN is assigned a private address which is not routable in
   the Internet.  Thus, packets tunneled to that address from the
   Internet cannot reach the MN.  Therefore, LISP-MN does not work
   behind NAT boxes.

   In this document we present an extension to LISP-MN which allows NAT
   traversal for LISP-MNs by utilizing special NAT traversal routers
   (NTRs) whose functionality may be integrated in a MN's MS.  In the



Klein, et al.            Expires January 6, 2011                [Page 3]


Internet-Draft            LISP-MN NAT Traversal                July 2010


   following, we assume that a NAT box not only translates IP addresses
   but also ports (NAPT).  Section 3 introduces the most important terms
   and definitions used in this document.  Section 4 gives a short
   overview of the NAT traversal technique and Section 5 describes the
   NAT traversal mechanism in detail.  Section 6 discusses some security
   issues which arise due to the NAT traversal mechanism and finally,
   Section 7 gives a short conclusion.  A paper version of this draft is
   provided in [KLHA10].


3.  Terminology

   This section lists the most important terms and definitions used
   throughout this document.

   Endpoint Identifier (EID):  IPv4 or IPv6 address of an end-host that
         is used to identify the end-host on a global scale.  EIDs are
         only routable within a LISP site.  Transport connections
         between end-hosts are bound to EIDs.  Therefore, EIDs must not
         change due to a roaming event because otherwise, existing
         transport connections would fail.

   Routing Locator (RLOC):  Globally routable IPv4 or IPv6 address which
         is used to reach LISP end-hosts in another LISP site.

   Ingress Tunnel Router (ITR):  An ITR is the gateway of a LISP site
         and receives outgoing packets from LISP nodes within its LISP
         site destined to nodes in other LISP or non-LISP sites.  The
         (inner) header (IH) of outgoing packets remains unchanged and
         the ITR adds an additional outer header (OH) that contains RLOC
         addresses to make the packet globally routable.  The ITR uses
         its own RLOC as source address in the OH and for the
         destination address, it obtains an RLOC for the destination EID
         from the mapping system.  The ITR also adds a special UDP LISP-
         header between the outer and inner IP header.  UDP port 4341 is
         used as destination port for data packets and UDP port 4342 is
         used as destination port for signaling packets.  The source
         port for both packet types is randomly chosen and has no
         special purpose.

   Egress Tunnel Router (ETR):  An ETR of a LISP site receives LISP-
         encapsulated IP packets from the Internet which are addressed
         to one of its own RLOCs.  The ETR decapsulates the packet,
         removes the additional UDP header, and forwards the packet to
         the destination node within its own LISP site according to the
         EID in the inner header.





Klein, et al.            Expires January 6, 2011                [Page 4]


Internet-Draft            LISP-MN NAT Traversal                July 2010


   Stationary Node (SN):  A non-mobile end-host which resides in a LISP
         or non-LISP site and has a relatively fixed IP address.  SNs
         inside a LISP site do not need to be upgraded to communicate
         via LISP with other LISP nodes within or in a different LISP
         site.

   Mobile Node (MN):  A mobile end-host which implements LISP mobile
         node operations [LISP-MN].  It acts as a lightweight LISP site
         and has ITR and ETR functionality.  It has a fixed EID for
         transport connections and uses a care-of-address which is
         dynamically assigned from the hosting domain as locator.
         Packets to and from mobile nodes are always LISP-encapsulated
         and carry the current care-of-address in the outer header and
         the fixed EID in the inner header.

   Proxy ITR (PITR):  PITRs enable SNs inside LISP sites to be reachable
         from the non-LISP part of the Internet.  PITRs advertise highly
         aggregated anycast EID-prefixes via BGP in the Internet.  IP
         packets sent from non-LISP sites addressed to EIDs are then
         routed to the next PITR.  The PITR performs ITR functionality
         on behalf of the non-LISP site and applies the necessary steps
         to encapsulate and forward a packet to its destination's ETR.
         The interworking architecture and PITRs are described in
         [LISP-IW].

   Proxy ETR (PETR):  PETRs are also part of the interworking
         architecture [LISP-IW].  They are required by LISP sites to
         reach non-LISP sites if one of the LISP site's upstream
         providers performs source address filtering.  Normally, ITRs
         would send IP packets to non-LISP sites without an additional
         header and with the EID of the sending node as source address.
         If an upstream provider utilizes source address filtering, it
         drops packets with an EID source address because EIDs are
         usually not part of the provider's address range.  To
         circumvent this, ITRs tunnel packets to a pre-configured PETR
         which acts as ETR on behalf of non-LISP sites.

   Map-Server (MS):  MSs act as interface for the mapping system and
         ease the communication between ETRs and different mapping
         systems [LISP-MS].  A MS learns EID-to-RLOC mappings from
         authoritative sources like ETRs or MNs via Map-Register
         messages described in [LISP] and distributes these mappings on
         behalf of the ETR or MN in the mapping system.  For a MN, the
         MS also acts as proxy-ETR so that non-LISP networks can be
         reached by the MN.






Klein, et al.            Expires January 6, 2011                [Page 5]


Internet-Draft            LISP-MN NAT Traversal                July 2010


   NAT Traversal Router (NTR):  A specific MS which implements the NAT
         traversal technique proposed in this document.  It thereby
         allows MNs to be reachable behind a NAT-gateway although the MN
         has only received a non-globally routable private IPv4
         [RFC1918] or private IPv6 [RFC4193] address as care-of-address.


4.  Architecture Overview

   The NAT traversal technique described in this document is implemented
   inside MSs and requires no new functionality in other entities.  In
   the remainder of this document, we call a modified MS that implements
   the NAT traversal mechanism a NAT Traversal Router (NTR).

                                         ___________________
              __________               ,' INTERNET          `.
            ,' Non-LISP `.            /                       \
           /     site    +---+       |           _________     |
        +--+             |NAT|       |  +-----+ /Traffic  |    |
        |MN|0==========================0| NTR |< for MN   |    |
        +--+             +---+       |  | (MS)| \_________|    |
         ^ \              /          |  +-----+                |
         |  `.__________,'            \    ^                  /
         |                             `.__|________________,'
         |                                 |
         |_________________________________|
             Tunnel between MN and NTR
             used to bypass NAT

                      Figure 1: Architecture overview

   When a MN roams into a network, it obtains a care-of-address and
   registers it as RLOC for its EID with its pre-configured NTR.  The
   Map-Register message also induces context inside the NAT-gateway
   which allows incoming reply packets from the NTR to the MN to
   traverse the NAT box.  The Map-Register message received by the NTR
   does not explicitly indicate wheter the MN is behind a NAT, but the
   NTR is able to determine whether the MN is behind a NAT with the
   information provided in the Map-Register message.  If the MN is
   behind a NAT, the NTR registers its own IP address as RLOC for the
   EID of the MN in the mapping system.  Thus, when traffic is sent to a
   MN behind a NAT, (P)ITRs tunnel the traffic to the NTR instead of to
   the care-of address of the MN.  The NTR relays that traffic to the MN
   and the traffic traverses the NAT due to the context established for
   the NTR during the registration process.  This essentially
   constitutes a tunnel between the NTR and the MN which is used to
   bypass the NAT gateway.  Figure 1 shows an overview of the
   architecture and the basic idea of the NAT traversal mechanism.



Klein, et al.            Expires January 6, 2011                [Page 6]


Internet-Draft            LISP-MN NAT Traversal                July 2010


5.  NAT Traversal Mechanism

   This section explains the control and data plane operations for NAT
   traversal by MNs.

5.1.  Control Plane Operations

   When a MN roams into a network, it receives a care-of-address, e.g.
   from the local DHCP service, and sends a Map-Register message to its
   MS using destination port 4342 without any LISP encapsulation.  In
   contrast to the current behavior in LISP-MN, which uses a randomly
   chosen source port without special purpose, our NAT traversal
   proposal requires that source port 4341 is used.  The collocated NTR
   compares the reported care-of-address with the source address of the
   Map-Register message.  If they are the same, the MN is not behind a
   NAT and the address is registered as RLOC for the EID of the MN in
   the mapping system.


































Klein, et al.            Expires January 6, 2011                [Page 7]


Internet-Draft            LISP-MN NAT Traversal                July 2010


                                             EID->IP:Port   EID->RLOC
                    NAT-TABLE                   Mapping      Mapping
   +-------------+-------------+-----------+   +-------+   +---------+
   | Internal    |  External   |  Peer     |   | EID 1 |   |  EID 1  |
   | IP:Port     |  IP:Port    |  IP:Port  |   |  -->  |   |   -->   |
   |-------------|-------------|-----------|   |1.8.7.2|   |  RLOC N |
   |10.0.0.1:4341|1.8.7.2:20321|RLOC N:4342|   |:20321 |   +---------+
   +-------------+-------------+-----------+   +-------+        *
                                                    *         *
                                                  __*_______*_______
              __________                        ,'  *     *         `.
            ,' Non-LISP `.                     /    *   *    INTERNET \
    +--------+   site  +-------+              |   +------+             |
    |   MN   |         |  NAT  |              |   | NTR  |             |
    |  EID 1 |  -----> |1.8.7.2| ---------------> | (MS) |             |
    |10.0.0.1|    :    +-------+        :     |   |RLOC N|             |
    +--------+    :       /             :     |   +------+             |
            `.____:_____,'              :      \                      /
                  :                     :       `.__________________,'
                  :                     :
                  :                     :
            Src:     Dest:         Src:     Dest:
           +--------+------+      +--------+------+
       OH: |10.0.0.1|RLOC N|      |1.8.7.2 |RLOC N|
           +--------+------+      +--------+------+
      UDP: |4341    |4342  |      |20321   |4342  |
           +--------+------+      +--------+------+
     LISP: |REGISTRATION:  |      |REGISTRATION:  |
           |EID 1->10.0.0.1|      |EID 1->10.0.0.1|
           +--------+------+      +--------+------+

                      Figure 2: Registration process

   If the two addresses differ, the MN is behind a NAT and the new NAT
   traversal concept for MNs behind NATs is used.  The NAT traversal
   concept is explained using the packet flow sequence in Figure 2 as an
   example.  A MN with EID 1 has roamed into a private network and
   obtained the care-of-address 10.0.0.1.  It sends a Map-Register
   message from source port 4341 containing its care-of-address to the
   NTR with RLOC N. The intermediate NAT gateway translates the source
   IP/port combination 10.0.0.1:4341 into 1.8.7.2:20321 and stores this
   as context for packets to and from destination IP/port RLOC N:4342.
   The NTR detects that the care-of-address 10.0.0.1 differs from the
   source address of the Map-Register message (1.8.7.2) and, therefore,
   it stores its own IP address (RLOC N) as RLOC for EID 1 in the
   mapping system.  In addition, the NTR records the source address and
   port of the Map-Register message (1.8.7.2:20321) with the EID (EID 1)
   in an EID-to-IP:Port table.  The NTR needs this IP/port combination



Klein, et al.            Expires January 6, 2011                [Page 8]


Internet-Draft            LISP-MN NAT Traversal                July 2010


   to relay packets to the MN behind the NAT.  To make the mapping
   system robust against stale information, an expiration timer is
   associated with registered EID-to-RLOC mappings.  The same may be
   applied to the EID-to-IP:Port table.  The expiration timer should be
   set to a small value so that the established context in the NAT
   gateway is also refreshed in time.

5.2.  Data Plane Operations

                                             EID->IP:Port   EID->RLOC
                    NAT-TABLE                   Mapping      Mapping
   +-------------+-------------+-----------+   +-------+    +--------+
   | Internal    |  External   |  Peer     |   | EID 1 |    | EID 1  |
   | IP:Port     |  IP:Port    |  IP:Port  |   |  -->  |    |  -->   |
   |-------------|-------------|-----------|   |1.8.7.2|    | RLOC N |
   |10.0.0.1:4341|1.8.7.2:20321|RLOC N:4342|   |:20321 |    +--------+
   +-------------+-------------+-----------+  *+-------+   *
                                             *          *
                                        ____*________*
             __________               ,'   *      *  `.
           ,' Non-LISP `.            /    *    *       \   __________
   +--------+   site +-------+      |  +------+         | /LISP site \
   |   MN   |        |  NAT  |      |  | NTR  |     +------+    +-----+
   |  EID 1 | <------|1.8.7.2|<--------| (MS) |<----| ITR  |<---| SN  |
   |10.0.0.1|    :   +-------+   :  |  |RLOC N|  :  |RLOC B|  : |EID 2|
   +--------+    :       /       :  |  +------+  :  +------+  : +-----+
           `.____:_____,'        :   \                 /  \___:______/
                 :               :    `._________:___,'       :
                 :               :               :            :
                 :               :               :      Src:     Dest:
                 :               :               :     +--------+------+
                 :               :               : IH: |EID 2   |EID 1 |
                 :               :               :     +--------+------+
                 :               :               :
         Src:     Dest:     Src:     Dest:      Src:     Dest:
        +--------+------+  +--------+------+   +--------+------+
    OH: |10.0.0.1|RLOC N|  |1.8.7.2 |RLOC N|   |RLOC B  |RLOC N|
        +--------+------+  +--------+------+   +--------+------+
   UDP: |4341    |4342  |  |20321   |4342  |   |30369   |4342  |
        +--------+------+  +--------+------+   +--------+------+
    IH: |EID 2   |EID 1 |  |EID 2   |EID 1 |   |EID 2   |EID 1 |
        +--------+------+  +--------+------+   +--------+------+

                          Figure 3: Incomin flow

   When traffic is sent to a MN behind a NAT, a (P)ITR tunnels it to the
   NTR at which the MN has registered.  This is depicted in Figure 3.
   An NTR relays such traffic as follows.  It strips off the LISP and



Klein, et al.            Expires January 6, 2011                [Page 9]


Internet-Draft            LISP-MN NAT Traversal                July 2010


   UDP header, uses the destination EID (EID 1) in the IH of the packet
   to look up the IP/port combination (1.8.7.2:20321) in the EID-to-
   IP:Port table, and encapsulates the packets to this IP/port
   combination using its own IP address and port 4342 as source IP/port
   combination (RLOC N:4342).  The NAT gateway recognizes the
   destination IP/port and translates it to the address:port of the MN
   which is 10.0.0.1:4341 in our example.  Eventually, the translated
   packet reaches the MN on the correct port 4341 for incoming LISP-
   encapsulated traffic.  The correct port number is achieved by
   requiring MNs to send Map-Register messages to the MS using source
   port 4341.  Regarding the behavior of a MN, this constitutes the only
   difference to the original LISP-MN architecture.


6.  Security Considerations

   The presented NAT traversal for LISP MN allows other nodes in the
   Internet to contact MNs behind a NAT gateway which is the intention
   of the proposal.  If the NAT is used as part of a firewall, external
   nodes can easily circumvent this security feature and contact MNs.
   However, this is a general concern of all NAT traversal mechanisms.
   Thus, any type of traffic can reach the MN behind a NAT/firewall.
   This may be avoided by making the NAT/firewall aware of the NAT
   traversal mechanism so that deep packet inspection for incoming LISP
   traffic can be used.


7.  Conclusion

   NAT traversal for LISP MNs allows MNs that roam into networks behind
   NATs to be globally reachable.  The presented mechanism does not
   require new architectural components and implements new "NAT
   Traversal Router" (NTR) functionality only in MSs.  The only change
   to a MN is that it must send Map-Register messages from source port
   4341 to its MS.


8.  Acknowledgements

   The authors thank David Meyer, Darrel Lewis, Dino Farinacci, and
   Vince Fuller for insightful comments.  They also acknowledge the
   support of G-LAB (support code 01 BK 0800, G-Lab,
   http://www.german-lab.de/).


9.  IANA Considerations

   This document makes no request on IANA namespaces [RFC2434].



Klein, et al.            Expires January 6, 2011               [Page 10]


Internet-Draft            LISP-MN NAT Traversal                July 2010


10.  References

10.1.  Normative References

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

10.2.  Informative References

   [KLHA10]   Klein, D., Hartmann, M., and M. Menth, "NAT Traversal for
              LISP Mobile Node", work in progress, April 2010, <http://
              www.menth.net/Publications/papers/Menth10-Sub-2.pdf>.

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-07 (work in progress), April 2010.

   [LISP-IW]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-01 (work in progress),
              March 2010.

   [LISP-MN]  Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Mobile Node", draft-meyer-lisp-mn-01 (work in progress),
              February 2010.

   [LISP-MS]  Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-05 (work in progress), April 2010.

   [MEKL10]   Menth, M., Klein, D., and M. Hartmann, "Improvements to
              LISP Mobile Node", in proceedings of the 22nd
              International Teletraffic Congress (ITC), Amsterdam, The
              Netherlands, Sep 2010.  Preprint available at:
              <http://www.menth.net/Publications/papers/Menth10k.pdf>






Klein, et al.            Expires January 6, 2011               [Page 11]


Internet-Draft            LISP-MN NAT Traversal                July 2010


Authors' Addresses

   Dominik Klein
   University of Wuerzburg
   Am Hubland
   Wuerzburg  D-97074
   Germany

   Phone: +49-931-31-88827
   Email: dominik.klein@informatik.uni-wuerzburg.de


   Matthias Hartmann
   University of Wuerzburg
   Am Hubland
   Wuerzburg  D-97074
   Germany

   Phone: +49-931-31-83381
   Email: hartmann@informatik.uni-wuerzburg.de


   Michael Menth
   University of Wuerzburg
   Am Hubland
   Wuerzburg  D-97074
   Germany

   Phone: +49-931-31-86644
   Email: menth@informatik.uni-wuerzburg.de





















Klein, et al.            Expires January 6, 2011               [Page 12]


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