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, . [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: 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]