f. maino cisco systems, inc. nat traversal for lisp …...internet-draft nat traversal for lisp...

Network Working Group V. ErmaganInternet-Draft D. FarinacciIntended status: Experimental D. LewisExpires: September 5, 2012 J. Skriver F. Maino Cisco Systems, Inc. C. White Logicalelegance, Inc. March 4, 2012

NAT traversal for LISP draft-ermagan-lisp-nat-traversal-00.txt

Abstract

This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by a new network element, the LISP Re-encapsulating Tunnel Router (RTR), which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT.

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 September 5, 2012.

Copyright Notice

Copyright (c) 2012 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

Ermagan, et al. Expires September 5, 2012 []

Internet-Draft NAT traversal for LISP March 2012

(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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4. LISP RTR Message Details . . . . . . . . . . . . . . . . . . . 7 4.1. Info-Request Message . . . . . . . . . . . . . . . . . . . 7 4.2. LISP Info-Reply . . . . . . . . . . . . . . . . . . . . . 8 4.3. LISP Map-Register Message . . . . . . . . . . . . . . . . 9 4.4. LISP Map-Notify . . . . . . . . . . . . . . . . . . . . . 10 4.5. LISP Data-Map-Notify Message . . . . . . . . . . . . . . . 11 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 13 5.1. xTR Processing . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. ETR Registration . . . . . . . . . . . . . . . . . . . 13 5.1.2. Map-Request and Map-Reply Handling . . . . . . . . . . 15 5.1.3. xTR Sending and Receiving Data . . . . . . . . . . . 16 5.2. Map-Server Processing . . . . . . . . . . . . . . . . . . 16 5.3. RTR Processing . . . . . . . . . . . . . . . . . . . . . . 17 5.3.1. RTR Data Forwarding . . . . . . . . . . . . . . . . . 18 5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. Normative References . . . . . . . . . . . . . . . . . . . . . 26 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27



1. Introduction

The Locator/ID Separation Protocol [LISP] defines a set of functions for encapsulating routers to exchange information used to map from Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs). The assumption that the LISP Tunnel Routers are reachable at their RLOC breaks when a LISP device is behind a NAT. LISP relies on the xTR being able to receive traffic at its RLOC on destination port 4341. However nodes behind a NAT are only reachable through the NAT’s public address and in most cases only after the appropriate mapping state is set up in the NAT. A NAT traversal mechanism is needed to make the LISP device behind a NAT reachable.

This document introduces a NAT traversal mechanism for LISP. Two new LISP control messages - LISP Info-Request and LISP Info-Reply - are introduced in order to detect whether a LISP device is behind a NAT, and discover the global IP address and global ephemeral port used by the NAT to forward LISP packets sent by the LISP device. A new LISP component, the LISP Re-encapsulating Tunnel Router (RTR), acts as a re-encapsulating LISP tunnel router [LISP] to pass traffic through the NAT, to and from the LISP device. A modification to how the LISP Map-Register messages are sent allows LISP device to initialize NAT state to use the RTR services. This mechanism addresses the scenario where the LISP device is behind the NAT, but the associated Map- Server is on the public side of the NAT.



2. Definition of Terms

LISP Info-Request: A LISP control packet sent by a LISP device to its Map-Server.

LISP Info-Reply: A LISP control packet sent by a Map Server to a LISP device in response to an Info-Request.

LISP Re-encapsulating Tunnel Router (RTR): An RTR is a re- encapsulating LISP Router (see section 8 of the main LISP specification) [LISP]. An RTR provides a LISP device the ability to traverse NATs.

LISP Data-Map-Notify: A LISP Map-Notify message encapsulated in a LISP data header.

LISP xTR-ID A 128 bit field that can be appended at the end of a Map-Register or Map-Notify message. An xTR-ID is used as a unique identifier of the xTR that is sending the Map-Register and is especially useful for identifying multiple xTRs serving the same site/EID-prefix.

NAT: "Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end hosts". "Traditional NAT would allow hosts within a private network to transparently access hosts in the external network, in most cases. In a traditional NAT, sessions are uni-directional, outbound from the private network." --RFC 2663[NAT]. Basic NAT and NAPT are two varieties of traditional NAT.

Basic NAT: "With Basic NAT, a block of external addresses are set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. For packets outbound from the private network, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. For inbound packets, the destination IP address and the checksums as listed above are translated." --RFC 2663[NAT].

NAPT: "NAPT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address. NAPT allows a set of hosts to share a single external address. Note that NAPT can be combined with Basic NAT so that a pool of external addresses are used in conjunction with port translation." --RFC 2663[NAT]. Transport identifiers of the destination hosts



are not modified by the NAPT.

In this document the general term NAT is used to refer to both Basic NAT and NAPT.

While this document specifies LISP NAT Traversal for LISP tunnel routers, a LISP-MN can also use the same procedure for NAT traversal. The modifications attributed to a LISP-Device, xTR, ETR, and ITR must be supported by a LISP-MN where applicable, in order to achieve NAT traversal for such a LISP node.

For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please consult the LISP specification [LISP].



3. Basic Overview

There are two attributes of a LISP device behind a typical NAT that requires special consideration in LISP protocol behavior in order to make the device reachable. First, the RLOC assigned to the device is typically not globally unique nor globally routable. Second, the NAT likely has a restrictive translation table and forwarding policy, requiring outbound packets to create state before the NAT accepts inbound packets. This section provides an overview of the LISP NAT traversal mechanism which deals with these conditions. The following sections specify the mechanism in more detail.

When a LISP device receives a new RLOC and wants to register it with the mapping system, it needs to first discover whether it is behind a NAT. To do this, an ETR uses its Map-Server to discover its translated global RLOC and port via the two new LISP messages: Info- Request and Info-Reply. Once an ETR detects that it is behind a NAT, it uses a new LISP entity, a LISP Re-encapsulating Tunnel Router (RTR) as a data plane ’anchor point’ to send and receive traffic through the NAT device. The ETR registers the RTR RLOC(s) to its Map-Server using the RTR as a proxy for the Map-Register message. The ETR encapsulates the Map-Register message in a LISP ECM header destined to the RTR’s RLOC. The RTR strips the LISP ECM header, reoriginates the Map-Register message, and sends it to the Map-Server. This initializes state in the NAT device so the ETR can receive traffic on port 4341 from the RTR. It also registers the RTR RLOC as the RLOC where the ETR EID prefix is reachable. As a result, all packets destined to the ETR’s EID will go to its RTR. The RTR will then re-encapsulates and forwards the ETR’s traffic via the existing NAT state to the ETR.

Outbound LISP data traffic from the xTR is also encapsulated to the RTR, where the RTR re-encapsulated the LISP packets based on their destination EIDs.

In the next sections the procedure is discussed in more detail.



4. LISP RTR Message Details

The main modifications in the LISP protocol to enable LISP NAT traversal via an RTR include: (1) two new messages used for NAT discovery (Info-Request and Info-Reply), and (2) encapsulation of two LISP control messages (Map-Register and Map-Notify) between the xTR and the RTR. Map-Register is encapsulated in an ECM header while Map-Notify is encapsulated in a LISP data header (Data-Map-Notify). This section describes the message formats and details of the Info- Request, Info-Reply, and Data-Map-Notify messages, as well as encapsulation details and minor changes to Map-Register and Map- Notify messages.

4.1. Info-Request Message

An ETR sends an Info-Request message to its Map-Server in order to

1. detect whether there is a NAT on the path to its Map-Server

2. obtain a list of RTR RLOCs that can be used for LISP data plane NAT traversal.

An Info-Request message is a LISP control message, its source port is chosen by the xTR and its destination port is set to 4342. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=7 |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ˜ Authentication Data ˜ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | EID mask-len | EID-prefix-AFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EID-prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI = 0 | <Nothing Follows AFI=0> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LISP Info-Request Message Format



Type: 7 (Info-Request)

R: R bit indicates this is a reply to an Info-Request (Info- Reply). R bit is set to 0 in an Info-Request. When R bit is set to 0, the AFI field (following the EID-prefix field) must be set to 0. When R bit is set to 1, the packet contents follow the format for an Info-Reply as described below.

Reserved: Must be set to 0 on transmit and must be ignored on receipt.

TTL: The time in minutes the recipient of the Info-Reply will store the RTR Information.

Nonce: An 8-byte random value created by the sender of the Info- Request. This nonce will be returned in the Info-Reply. The nonce SHOULD be generated by a properly seeded pseudo-random (or strong random) source.

Descriptions for other fields can be found in the Map-Register section of the main LISP draft [LISP]. Field descriptions for the LCAF AFI = 0 can be found in the LISP LCAF draft [LCAF] .

4.2. LISP Info-Reply

When a Map-Server receives an Info-Request message, it responds with an Info-Reply message. The Info-Reply message source port is 4342, and destination port is taken from the source port of the triggering Info-Request. Map-Server fills the NAT LCAF (LCAF Type = 7) fields according to their description. The Map-Server uses AFI=0 for the Private ETR RLOC Address field in the NAT LCAF.



0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=7 |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | Authentication Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ˜ Authentication Data ˜ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | EID mask-len | EID-prefix-AFI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EID-prefix | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AFI = 16387 | Rsvd1 | Flags | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Type = 7 | Rsvd2 | 4 + n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N | MS UDP Port Number | ETR UDP Port Number | A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T | AFI = x | Global ETR RLOC Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L | AFI = x | MS RLOC Address ... | C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A | AFI = x | Private ETR RLOC Address ... | F +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AFI = x | RTR RLOC Address 1 ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AFI = x | RTR RLOC Address n ... | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LISP Info-Reply Message Format

Type: 7 , R = 1, (Info-Reply)

The format is similar to the Info-Request message. See Info-Request section for field descriptions. Field descriptions for the NAT LCAF section can be found in the LISP LCAF draft [LCAF] .

4.3. LISP Map-Register Message

The fourth bit after the Type field in the Map-Register message is allocated as "R" bit. R bit indicates that the Map-Register is built



for an RTR. R bit must be set in a Map-Register that a LISP device sends to an RTR.

The third bit after the Type field in the Map-Register message is allocated as "I" bit. I bit indicates that a xTR-ID field is present at the end of the Map-Register message. If an xTR is configured with an xTR-ID, it MUST set the I bit to 1 and include its xTR-ID in the Map-Register messages it generates. If the R bit in the Map-Register is set to 1, the I bit must also be set to 1, and an xTR-ID must be included in the Map-Register message sent to an RTR.

xTR-ID is a 128 bit field at the end of the Map-Register message, starting after the final Record in the message. The xTR-ID is used to identify the intended recipient xTR for a Map-Notify message, especially in the case where a site has more than one xTR. When a Map-Server receives a Map-Register with the I bit set, it MUST copy the XTR-ID from the Map-Register to the associated Map-Notify message. When a Map-Server is sending an unsolicited Map-Notify to an xTR to notify the xTR of a change in locators, the Map-Server must include the xTR-ID for the intended recipient xTR, if it has one stored locally.

A LISP device that sends a Map-Register to an RTR must encapsulate the Map-Register message using an Encapsulated Control Message (ECM) [LISP]. The outer header source RLOC of the ECM is set to the LISP device’s local RLOC, and the outer header source port is set to 4341. The outer header destination RLOC and port are set to RTR RLOC and 4342 respectively. The inner header source RLOC is set to LISP device’s local RLOC, and the inner source port is picked at random. The inner header destination RLOC is set to the xTR’s Map-Server RLOC, and inner header destination port is set to 4342.

4.4. LISP Map-Notify

The first bit after the Type field in a Map-Notify message is allocated as the "I" bit. I bit indicates that a 128 bit xTR-ID field is present at the end of the Map-Notify message, following the final Record in the Map-Notify (See Section 4.3 for details on xTR-ID). A Map-Server MUST set the I bit in a Map-Notify and include the xTR-ID of the intended recipient xTR if the associated Map- Register has the I bit set, or when the Map-Server has previously cached an xTR-ID for the destination xTR.

The second bit after the Type field in Map-Notify is allocated as the "R" bit. R bit in Map-Notify indicates that additional authentication data is appended at the end of the Map-Notify message. If the I bit is also set in the Map-Notify, the additional MS-RTR authentication data must be appended after the xTR-ID field. If a



Map-Server receiving a Map-Register with the R bit set, has a shared key associated with the sending RTR, it must generate a Map-Notify message with the R bit set to 1, and with the additional MS-RTR authentication related fields described below.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MS-RTR Key ID | MS-RTR Auth. Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ˜ MS-RTR Authentication Data ˜ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Changes to LISP Map-Notify Message

MS-RTR Key ID: A configured ID to find the configured Message Authentication Code (MAC) algorithm and key value used for the authentication function. See [LISP] section 14.4 for codepoint assignments.

MS-RTR Authentication Data Length: The length in bytes of the MS-RTR Authentication Data field that follows this field. The length of the Authentication Data field is dependent on the Message Authentication Code (MAC) algorithm used. The length field allows a device that doesn’t know the MAC algorithm to correctly parse the packet.

MS-RTR Authentication Data: The message digest used from the output of the Message Authentication Code (MAC) algorithm. The entire Map- Notify payload is authenticated with this field preset to 0. After the MAC is computed, it is placed in this field. Implementations of this specification MUST support HMAC-SHA-1-96 [RFC2404] and SHOULD support HMAC-SHA-256-128 [RFC6234].

For a full description of all fields in the Map-Notify message refer to Map-Notify section in the main LISP draft [LISP].

4.5. LISP Data-Map-Notify Message

When an RTR receives a Map-Notify message, it has to relay that message to the registering LISP device. After processing the Map- Notify message as described in Section 5.3, the RTR encapsulates the Map-Notify in a LISP data header and sends it to the associated LISP device. This Map-Notify inside a LISP data header is referred to as a Data-Map-Notify message.



0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = 4342 | Dest Port = xxxx | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L | LISP Header ˜ | I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ S / | ˜ LISP Header | P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = 4342 | Dest Port = 4342 | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Map-Notify Message ˜ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LISP Data-Map-Notify Message

In a Data-Map-Notify, the outer header source RLOC is set to the RTR’s RLOC that was used in the associated Map-Register. This is previously cached by the RTR. The outer header source port is set to 4342. The outer header destination RLOC and port are filled based on the translated global RLOC and port of the registering LISP device previously stored locally at the RTR. The inner header source address is Map-Server’s RLOC, and inner header source port is 4342. The inner header destination address is set to the LISP device’s local RLOC also previously cached by the RTR (See Section 5.3 for details.). The inner header destination port is 4342.

Since a Data-Map-Notify is a control message encapsulated in a LISP data header, a special Instance ID is used as a signal for the xTR to trigger processing of the control packet inside the data header. The Instance ID value 0xFFFFFF is reserved for this purpose. The Instance ID field in a Data-Map-Notify must be set to 0xFFFFFF.



5. Protocol Operations

There are two main steps in the NAT traversal procedure. First, the ETR’s translated global RLOC must be discovered. Second, the NAT translation table must be primed to accept incoming connections. At the same time, the Map-Server and the RTR must be informed of the ETR’s translated global RLOC including the translated ephemeral port number(s) at which the Map-Server and RTR can reach the LISP device.

5.1. xTR Processing

Upon receiving a new RLOC, an ETR first has to detect whether the new RLOC is behind a NAT device. For this purpose the ETR sends an Info- Request message to its Map-Server in order to discover the ETR’s translated global RLOC visible to the Map-Server. The ETR uses the new RLOC as the source RLOC of the message. The Map-Server, after authenticating the message, responds with an Info-Reply message. The Map-Server includes the source RLOC and port from the Info-Request message in the Global ETR RLOC Address and ETR UDP Port Number fields of the Info-Reply. The Map Server also includes the destination RLOC and port number of the Info-Request message in the MS RLOC Address and MS UDP Port Number fields of the Info-Reply. In addition, the Map-Server provides a list of RTR RLOCs that the ETR may use in case it needs NAT traversal services. The source port of the Info-Reply is set to 4342 and the destination port is copied from the source port of the triggering Info-Request message.

Upon receiving the Info-Reply message, the ETR compares the source RLOC and source port used for the Info-Request message with the Global ETR RLOC Address and ETR UDP Port Number fields of the Info- Reply message. If the two are not identical, the ETR concludes that the new RLOC is behind a NAT and that it requires an RTR for NAT traversal services in order to be reachable at that RLOC. An ETR behind other stateful devices (e.g. stateful firewalls) may also use an RTR and the procedure specified here for traversing the stateful device. Detecting existence of such devices are beyond scope of this document.

If there is no NAT on the path, the ETR registers to its Map-Server as described in the main LISP draft [LISP].

5.1.1. ETR Registration

Once an ETR has detected that it is behind a NAT, based on local policy the ETR selects one (or more) RTR(s) from the RTR RLOCs provided in the Info-Reply and initializes state in the NAT device in order to receive LISP data traffic on UDP port 4341 from the selected RTR. To do so, the ETR sends a Map-Register encapsulated in an ECM



header to the selected RTR(s). The Map-Register message is created as specified in [LISP]. More specifically, the source RLOC of the Map-Register is set to ETR’s local RLOC, while the destination RLOC is set to the ETR’s Map-Server RLOC, and destination port is set to 4342. The ETR sets both the R bit and M bit in Map-Register to 1, and it includes the selected RTR RLOC(s) as the locators in the Map- Register message. The ETR must also set the I bit in the Map- Register message to 1 and include its xTR-ID in the corresponding field. In the ECM header of this Map-Register the source RLOC is set to ETR’s local RLOC and the source port is set to 4341, while the destination RLOC is the RTR’s RLOC and the destination port is set to LISP control port 4342.

This ECM-ed Map-Register is then sent to the RTR. The RTR reoriginates the Map-Register message and sends it to the associated Map-Server. The RTR then encapsulates the corresponding Map-Notify message in a LISP data header (Data-Map-Notify) and sends it back to the xTR.

Upon receiving a Data-Map-Notify from the RTR, the ETR must strip the outer LISP data header, and process the inner Map-Notify message as described in [LISP]. Since outer header destination port in Data- Map-Notify is set to LISP data port 4341, the Instance ID 0xFFFFFF in the LISP header of the Data-Map-Notify is used by the ETR to detect and process the Data-Map-Notify as a control message encapsulated in a LISP data header. While processing the Data-Map-Notify, the xTR also stores the RTR RLOC(s) as its data plane proxy, by storing a default map-cache entry with the RTR RLOC(s) as its locator set. The xTR may map the EID prefix 0/0 to this RTR RLOC(s). This results in the xTR encapsulating all LISP data plane traffic to this RTR. At this point the registration and state initialization is complete and the xTR can use the RTR services. The state created in the NAT device based on the ECM-ed Map-Register and corresponding Data-Map- Notify is used by the xTR behind the NAT to send and receive LISP control packets to/from the RTR, as well as for receiving LISP data packets form the RTR.

If ETR receives a Data-Map-Notify with the I bit set, but with an xTR-ID that is not equal to its local xTR-ID, it must log this as an error. The ETR should discard such Data-Map-Notify message.

The ETR must periodically send ECM-ed Map-Register messages to its RTR in order to both refresh its registration to the RTR and the Map- Server, and as a keepalive in order to preserve the state in the NAT device. Per recommendation in RFC 2663 [NAT] the period for sending the keepalives can be set to default value of two minutes, however since shorter timeouts may exist in some NAT deployments, the interval for sending periodic ECM-ed Map-Registers must be



configurable.

5.1.2. Map-Request and Map-Reply Handling

The ETR is in control of how to handle the Map-Requests and Map- Replies. If the ETR wants the Map-Server to proxy-reply as described in [LISP], it can register the RTR RLOC(s) as its locator via the ECM-ed Map-Register message. In this case, if the proxy bit is set in the Map-Register, the Map-Server will proxy reply with RTR’s RLOC to all Map-Requests for the ETR. As a result all traffic for the ETR is encapsulated to its RTR(s).

If the proxy bit in the ECM-ed Map-Register message is not set, and the ETR chooses to receive Map-Requests, the ETR must also initiate and preserve state in the NAT device to receive LISP control packets from its Map-Server. To do this, the ETR must periodically send Info-Request messages to its Map-Server, and receive Info-Reply messages from the Map-Server. Per recommendation in RFC 2663 [NAT] the period for sending the keepalives can be set to default value of two minutes, however since shorter timeouts may exist in some NAT deployments, the interval for sending periodic Info-Requests must be configurable. Furthermore, the ETR must also provide its Map-Server with the ETR’s translated global RLOC and port as visible to the Map- Server. To do this, ETR includes a copy of the NAT LCAF section of the Info-Reply message as one of the locators in its Map-Register along with the RTR(s) RLOC(s). The ETR can set the priorities of RTR RLOC(s) in this Map-Register to 255, resulting in the Map Server encapsulating Map-Requests to the ETR’s translated global RLOC and port so it can receive them through the NAT device.

If an ETR behind a NAT chooses to receive Map-Requests from the Map- Server, it must send Map-Replies to requesting ITRs. Note that this configuration will result in excessive state in the NAT device and is not recommended. ETR must include its RTR RLOC(s) as its locator set in the Map-Reply in order to receive data through the NAT device.

When an ITR behind a NAT is encapsulating outbound LISP traffic, it must use its RTR RLOC as the locator for all destination EIDs that it wishes to send data to. As such, the ITR does not need to send Map- Requests for the purpose of finding EID-to-RLOC mappings. For RLOC- probing, the periodic ECM-ed Map-Register and Data-Map-Notify messages between xTR and RTR can also serve the purpose of RLOC probes. However, if RLOC-probing is used, no changes are required to the RLOC-probing specification in [LISP], and the LISP device only needs to probe the RTR’s RLOC.



5.1.3. xTR Sending and Receiving Data

When a Map-Request for a LISP device behind a NAT is received by its Map-Server or the LISP device itself, the Map-Server, or the LISP device (ETR), responds with a Map-Reply including RTR’s RLOC as the locator for the requested EID. As a result, all LISP data traffic destined for the ETR’s EID behind the NAT is encapsulated to its RTR. The RTR re-encapsulates the LISP data packets to the ETR’s translated global RLOC and port number so the data can pass through the NAT device and reach the ETR. As a result the ETR receives LISP data traffic with outer header destination port set to 4341 as specified in [LISP].

For sending outbound LISP data, an ITR behind a NAT must use the RTR RLOC as the locator for all EIDs that it wishes to send data to according to the installed default map-cache entry. The ITR then encapsulates the LISP traffic in a LISP data header with outer header destination set to RTR RLOC and outer header destination port set to 4341. This may create a secondary state in the NAT device. ITR must set the outer header source port in all egress LISP data packets to a random but static port number in order to avoid creating excessive state in the NAT device.

If the ITR and ETR of a site are not collocated, the RTR RLOC must be configured in the ITR via an out-of-band mechanism. Other procedures specified here would still apply.

5.2. Map-Server Processing

Upon receiving an Info-Request message a Map-Server first verifies the authenticity of the message. Next the Map-Server creates an Info-Reply message and copies the source RLOC and port number of the Info-Request message to the Global ETR RLOC Address and ETR UDP Port Number fields of the Info-Reply message. The Map-Server also includes a list of RTR RLOCs that the ETR may use for NAT traversal services. The Map-Server sends the Info-Reply message to the ETR, by setting the destination RLOC and port of the Info-Reply to the source RLOC and port of the triggering Info-Request. The Map-Server sets the source port of the Info-Reply to 4342.

Upon receiving a Map-Register message with the M bit set, the Map- Server processes the Map-Register message and generates the resulting Map-Notify as described in [LISP]. If the R bit is set in the Map- Register message and the Map-Server has a shared secret configured with the RTR sending the Map-Register, the Map-Server also sets the R bit in the Map-Notify and includes the MS-RTR authentication data. See Security Considerations Section for more details. If the I bit is set in the Map-Register message, the Map-Server also locally



stores the xTR-ID from the Map-Register, and sets the I bit in the corresponding Map-Notify message and includes the same xTR-ID in the Map-Notify. The Map-Notify is sent to the RTR sending the corresponding Map-Register.

If a Map-Server is forwarding Map-Requests to an ETR which has registered its RLOC in a NAT LCAF, Map-Server must use the ETR Global RLOC Address and ETR UDP Port as the destination RLOC and port for outer header of the encapsulated Map-Requests. If more than one NAT LCAF is registered for the same EID prefix, the Map-Server must use the NAT LCAF corresponding to the RLOC of this Map-Server.

5.3. RTR Processing

Upon receiving an ECM-encapsulated Map-Register, the RTR creates a map-cache entry for the EID-prefix that was specified in the Map- Register message. The RTR stores the outer header source RLOC and outer header source port, the outer header destination RLOC (RTR’s own RLOC), the inner header source RLOC (xTR’s local RLOC), the xTR-ID, and the nonce field of the Map-Register in this local map- cache entry. The outer header source RLOC and outer header source port is the ETR’s translated global RLOC and port number visible to the RTR. Once the registration process is complete, this map-cache entry can be used to send LISP data traffic to the ETR. The inner header destination RLOC is the RTR’s RLOC, and the inner header source RLOC is the ETR’s local RLOC behind the NAT, and the RTR can later use these fields as the inner header source RLOC and destination RLOC correspondingly, for sending data-encapsulated control messages (Data-Map-Notify) back to the ETR. The nonce field is used for security purposes and is matched with the nonce field in the corresponding Map-Notify message. This map-cache entry is stored as an "unverified" mapping, until the corresponding Map-Notify message is received.

After filling the local map-cache entry, the RTR strips the outer header and extracts the Map-Register message, re-originates the message by rewriting the source RLOC of the Map-Register to RTR’s RLOC, and sends the Map-Register to destination Map-Server.

Map-Server responds with a Map-Notify message to the RTR.

Upon receiving a Map-Notify message from the Map-Server, if the R bit in Map-Notify is set to 1, RTR uses the MS-RTR Key ID to verify the MS-RTR Authentication Data included in the Map-Notify. If the MS-RTR authentication fails, the RTR must drop the packet. Once the authenticity of the message is verified, RTR can confirm that the Map-Register message for the ETR with the matching xTR-ID was accepted by the Map-Server. At this point the RTR can change the



state of the associated map-cache entry to verified for the duration of the Map-Register TTL.

The RTR then uses the information in the associated map-cache entry to create a Data-Map-Notify message according to the following procedure: RTR rewrites the inner header destination RLOC of the Map- Notify message to ETR’s local RLOC. Inner header destination port is 4342. The RTR encapsulates the Map-Notify in a LISP data header, where the outer header destination RLOC and port number are set to the ETR’s translated global RLOC and port number. If more than one ETR translated RLOC and port exists in the map-cache entry for the same EID prefix specified in the Map-Notify, the RTR can use the xTR-ID from the Map-Notify to identify which ETR is the correct destination for the Data-Map-Notify. The RTR sets the outer header source RLOC to RTR’s RLOC from the map-cache entry and the outer header source port is set to 4342. The RTR also sets the Instance ID field in the LISP header of the Data-Map-Notify to 0xFFFFFF. The RTR then sends the Data-Map-Notify to the ETR.

If the R bit is set to 0, and the RTR has a shared key configured locally with the sending Map-Server, the RTR must drop the packet. If the R bit is set to 0, and the RTR does not have a shared key configured with the associated Map-Server, according to local policy, the RTR may drop the packet. If the Map-Notify with R bit set to 0 is processed, the RTR must match the nonce field from this Map-Notify with the nonce stored in the local map-cache entry with the matching xTR-ID. If the nonces do not match, the RTR must drop the packet.

5.3.1. RTR Data Forwarding

For all LISP data packets encapsulated to RTR’s RLOC and outer header destination port 4341, the RTR first verifies whether the source or destination EID is a previously registered EID. If so, the RTR must process the packet according to the following. If the destination or source EID is not a registered EID, the RTR can drop or process the packet based on local policy.

In the case where the destination EID is a previously registered EID, the RTR must strip the LISP data header and re-encapsulate the packet in a new LISP data header. The outer header RLOCs and UDP ports are then filled based on the matching map-cache entry for the associated destination EID prefix. The RTR uses the RTR RLOC from the map-cache entry as the outer header source RLOC. The outer header source port is set to 4342. The RTR sets the outer header destination RLOC and outer header destination port based on the ETR translated global RLOC and port stored in the map-cache entry. Then the RTR forwards the LISP data packet.



In the case where the source EID is a previously registered EID, the RTR process the packet as if it is a Proxy ETR (PETR). The RTR must strip the LISP data header, and process the packet based on its inner header destination address. The packet may be forwarded natively, it may be LISP encapsulated to the destination ETR, or it may trigger the RTR to send a LISP Map-Request.

5.4. Example

What follows is an example of an ETR initiating a registration of a new RLOC to its Map-Server, when there is a NAT device on the path between the ETR and the Map-Server.

In this example, the ETR (site1-ETR) is configured with the local RLOC of 192.168.1.2. The NAT’s global (external) addresses are from 2.0.0.1/24 prefix. The Map-Server is at 3.0.0.1. And one potential RTR has an IP address of 1.0.0.1. The site1-ETR has an EID Prefix of 128.1.0.0/16.

An example of the registration process follows:

1. The Site1-ETR receives the private IP address, 192.168.1.2 as its RLOC via DHCP.

2. The Site1-ETR sends an Info-Request message with the destination RLOC of the Map-Server, 3.0.0.1, and source RLOC of 192.168.1.2. This packet has the destination port set to 4342 and the source port is set to (for example) 5001.

3. The NAT device translates the source IP from 192.168.1.2 to 2.0.0.1, and source port to (for example) 20001 global ephemeral source port.

4. The Map-Server receives and responds to this Info-Request with an Info-Reply message. This Info-Reply has the destination address set to ETR’s translated address of 2.0.0.1 and the source address is the Map-Server’s RLOC, namely 3.0.0.1. The destination port is 20001 and the source port is 4342. Map- Server includes a copy of the source address and port of the Info-Request message (2.0.0.1:20001), and a list of RTR RLOCs including RTR RLOC 1.0.0.1 in the Info-Reply contents.

5. The NAT translates the Info-Reply packet’s destination IP from 2.0.0.1 to 192.168.1.2, and translates the destination port from 20001 to 5001, and forwards the Info-Reply to site1-ETR at 192.168.1.2.



6. The Site1-ETR detects that it is behind a NAT by comparing its local RLOC (192.168.1.2) with the Global ETR RLOC Address in the Info-Reply (2.0.0.2) . Then site1-ETR picks the RTR 1.0.0.1 from the list of RTR RLOCs in the Info-Reply. ETR stores the RTR RLOC in a default map-cache entry to periodically send ECM-ed Map-Registers to.

7. The ETR sends an ECM encapsulated Map-Register to RTR at 1.0.0.1. The outer header source RLOC of this Map-Register is set to 192.168.1.2 and the outer header source port is set to 4341. The outer header destination RLOC and port are set to RTR RLOC at 1.0.0.1 and 4342 respectively. The inner header destination RLOC is set to ETR’s Map-Server 3.0.0.1, and the inner header destination port is set to 4342. The inner header source RLOC is set to ETR’s local RLOC 192.168.1.2. In the Map- Register message the R bit is set to 1, and the RTR RLOC 1.0.0.1 appears as the locator set for the ETR’s EID prefix (128.1.0.0/16). In this example ETR also sets the Proxy bit in the Map-Register to 1, and sets I bit to 1, and includes its xTR-ID in the Map-Register.

8. The NAT translates the source RLOC in the ECM header of the Map- Register, by changing it from 192.168.1.2 to 2.0.0.2, and translates the source port in the ECM header from 4341 to (for example) 20002, and forwards the Map-Register to RTR.

9. The RTR receives the Map-Register and creates a map-cache entry with the ETR’s xTR-ID, EID prefix, and the source RLOC and port of the ECM header of the Map-Register as the locator (128.1.0.0/16 is mapped to 2.0.0.2:20002). RTR also caches the inner header source RLOC of the Map-Register namely 192.168.1.2, and the outer header destination RLOC of the ECM header in the Map-Register (this would be RTR’s RLOC 1.0.0.1 ) to use for sending back a Data-Map-Notify. RTR then removes the outer header, re-writes the source RLOC of the Map-Register message to its own RLOC 1.0.0.1 and forwards the Map-Register to the destination Map-Server.

10. The Map-Server receives the Map-Register and processes it according to [LISP]. Since the R bit is set in the Map-Register and Map-Server has a shared secret with the sending RTR, after registering the ETR, Map-Server responds with a Map-Notify with the R bit set and including the MS-RTR authentication data. Since the I bit is set in the Map-Register, the Map-Server also sets the I bit in the Map-Notify and copies the xTR-ID from the Map-Register to the Map-Notify. The source address of this Map- Notify is set to 3.0.0.1. The destination is RTR 1.0.0.1, and both source and destination ports are set to 4342.



11. The RTR receives the Map-Notify and verifies the MS-RTR authentication data. The RTR data-encapsulates the Map-Notify and sends the resulting Data-Map-Notify to site1-ETR with a matching xTR-ID. The outer header source RLOC and port of the Data-Map-Notify are set to 1.0.0.1:4342. The outer header destination RLOC and port are retrieved from previously cached map-cache entry in step 9 namely 2.0.0.2:20002. RTR also sets the inner header destination address to site1-ETR’s local address namely 192.168.1.2. RTR sets the Instance ID in the LISP header to 0xFFFFFF. At this point RTR marks ETR’s EID prefix as "Registered" status and forwards the Data-Map-Notify to ETR.

12. The NAT device translates the destination RLOC and port of the Data-Map-Notify to 192.168.1.2:4341 and forwards the packet to ETR.

13. The Site1-ETR receives the packet with a destination port 4341, and processes the packet as a control packet after observing the Instance ID value 0xFFFFFF in the LISP header. At this point ETR’s registration to the RTR is complete.

Assume a requesting ITR in a second LISP (site2-ITR) site has an RLOC of 74.0.0.1. The following is an example process of an EID behind site2-ITR sending a data packet to an EID behind the site1-ETR:

1. The ITR sends a Map-Request which arrives via the LISP mapping system to the ETR’s Map Server.

2. The Map-Server sends a Map-Reply on behalf of the ETR, using the RTR’s RLOC (1.0.0.1) in the Map-Reply’s Locator Set.

3. The ITR encapsulates a LISP data packet with ITR’s local RLOC (74.0.0.1) as the source RLOC and the RTR as the destination RLOC (1.0.0.1) in the outer header.

4. The RTR decapsulates the packet, evaluates the inner header against its map-cache and then re-encapsulates the packet. The new outer header’s source RLOC is the RTR’s RLOC 1.0.0.1 and the new outer header’s destination RLOC is the Global NAT address 2.0.0.2. The destination port of the packet is set to 20002 (discovered above during the registration phase) and the source port is 4342.

5. The NAT translates the LISP data packet’s destination IP from to 2.0.0.2 to 192.168.1.2, and translates the destination port from 20002 to 4341, and forwards the LISP data packet to the ETR at 192.168.1.2.



6. For the reverse path the ITR uses its local map-cache entry with the RTR RLOC as the default locator and encapsulates the LISP data packets using RTR RLOC, and 4341 as destination RLOC and port. The ITR must pick a random source port to use for all outbound LISP data traffic in order to avoid creating excessive state in the NAT.



6. Security Considerations

By having the RTR relay the ECM-ed Map-Register message from an ETR to its Map-Server, the RTR can restrict access to the RTR services, only to those ETRs that are registered with a given Map-Server. To do so, the RTR and the Map-Server may be configured with a shared key that is used to authenticate the origin and to protect the integrity of the Map-Notify messages sent by the Map Server to the RTR. This prevents an on-path attacker from impersonating the Map-Server to the RTR, and allows the RTR to cryptographically verify that the ETR is properly registered with the Map-Server.

Having the RTR re-encapsulate traffic only when the source or the destination are registered EIDs, protects against the adverse use of an RTR for EID spoofing.

Upon receiving a Data-Map-Notify, an xTR can authenticate the origin of the Map-Notify message using the key that the ETR shares with the Map-Server. This enables the ETR to verify that the ECM-ed Map- Register was indeed forwarded by the RTR to the Map-Server, and was accepted by the Map-Server.



7. Acknowledgments

The authors would like to thank Noel Chiappa, Alberto Rodriguez Natal, Lorand Jakab, and Albert Cabellos for their feedback and helpful suggestions.



8. IANA Considerations

This document does not request any IANA actions.



9. Normative References

[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", draft-farinacci-lisp-lcaf-06 (work in progress), October 2011.

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

[NAT] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", Request for Comments: 2663, August 1999.

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

[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.



Authors’ Addresses

Vina Ermagan Cisco Systems, Inc.

Email: [email protected]

Dino Farinacci Cisco Systems, Inc.


Darrel Lewis Cisco Systems, Inc.


Jesper Skriver Cisco Systems, Inc.


Fabio Maino Cisco Systems, Inc.


Chris White Logicalelegance, Inc.



Network Working Group V. FullerInternet-Draft D. LewisIntended status: Experimental D. FarinacciExpires: May 31, 2012 cisco Systems November 28, 2011

LISP Delegated Database Tree draft-fuller-lisp-ddt-00.txt

Abstract

This draft describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured with an EID-prefix that it "owns" plus information, including the RLOCs for Map Servers or other DDT nodes for each defined more-specific EID-prefix of the "owned" prefix.

Status of this Memo




This Internet-Draft will expire on May 31, 2012.

Copyright Notice


This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents

Fuller, et al. Expires May 31, 2012 [Page 1]

Internet-Draft LISP Delegated Database Tree November 2011

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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. EID-prefix tree structure and instance IDs . . . . . . . . . . 7 4. Configuring XEID-prefix delegation . . . . . . . . . . . . . . 8 4.1. Example DDT node configuration . . . . . . . . . . . . . . 8 4.2. The root DDT node . . . . . . . . . . . . . . . . . . . . 8 5. DDT node operation - sending referrals . . . . . . . . . . . . 10 5.1. Match of a delegated prefix (or sub-prefix) . . . . . . . 10 5.2. Missing delegation from an authoritative prefix . . . . . 10 6. DDT Map Server operation . . . . . . . . . . . . . . . . . . . 11 7. DDT Map Resolver operation . . . . . . . . . . . . . . . . . . 12 7.1. Queuing, Sending, and Retransmitting DDT Map-Requests . . 12 7.2. Receiving and following referrals . . . . . . . . . . . . 12 7.2.1. Handling referral errors . . . . . . . . . . . . . . . 13 7.2.2. Referral loop detection . . . . . . . . . . . . . . . 14 8. Example message flow . . . . . . . . . . . . . . . . . . . . . 15 8.1. ITR sends a Map-Request to a DDT Map Resolver . . . . . . 15 8.2. DDT Map Resolver receives and processes Map-Request . . . 15 8.3. DDT Map Resolver searches referral cache for XEID . . . . 15 8.4. DDT Map Resolver creates and sends DDT Map-Request . . . . 16 8.5. DDT node receives and processes DDT Map-Request . . . . . 16 8.6. DDT Map Resolver processes Map-Referral . . . . . . . . . 16 8.7. DDT Map Server receives Map-Request . . . . . . . . . . . 17 8.8. DDT Map Resolver finished . . . . . . . . . . . . . . . . 17 8.9. DDT Map Server receives LISP-SEC-enabled Map-Request . . . 17 8.10. ETR sends Map-Reply to ITR . . . . . . . . . . . . . . . . 18 9. Open Issues and Considerations . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 Appendix B. Map-Referral Message Format . . . . . . . . . . . . . 24 Appendix C. Encapsulated Control Message Format . . . . . . . . . 25 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26



1. Introduction

[LISP] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: relatively static Endpoint Identifiers (EIDs), used end-to-end for terminating transport-layer associations, and Routing Locators (RLOCs), which are more dynamic, are bound to topological location, and are used for routing and forwarding through the Internet infrastructure.

LISP offers a general-purpose mechanism for mapping between EIDs and RLOCs. In organizing a database of EID to RLOC mappings, this specification extends the definition of the EID numbering space by logically prepending and appending several fields for purposes of defining the database index key: Key-ID (16 bits), Instance Identifier (IID, 32-bits), Address Family Identifier (16 bits), and EID-prefix (variable, according to AFI value). The resulting concatenation of these fields is termed an "Extended EID prefix" or XEID-prefix.

The term "Extended EID" (XEID) is also used to for an individual LISP EID that is further qualified through the use of an Instance ID. See [LCAF] for further discussion of the use of Instance IDs.

The Key-ID is provided for possible use in case a need evolves for another, higher level in the hierarchy, to allow the creation of multiple, separate database trees.

LISP-DDT is a hierarchical distributed database which embodies the delegation of authority to provide mappings, i.e. its internal structure mirrors the hierarchical delegation of address space. It also provides delegation information to Map-Resolvers, which use the information to locate EID-to-RLOC mappings. A Map-Resolver which needs to locate a given mapping will follow a path through the tree- structured database, contacting, one after another, the DDT nodes along that path until it reaches the leaf DDT node(s) authoritative for the mapping it is seeking.

LISP-DDT defines a new device type, the DDT node, that is configured with one or more XEID-prefix which it "owns" (for which it is termed to be "authoritative") and the set of more-specific sub-prefixes of the prefix(es) that are further delegated to other DDT nodes. To delegate a sub-prefix, the "parent" DDT node is configured with the RLOCs of each "child" DDT node that is authoritative for the sub- prefix. Each RLOC is either for a Map Server (sometimes termed a "terminal DDT node") that is responsible for contacting the Egress Tunnel Routers (ETRs) for that sub-prefix or is for another DDT node in the database tree that provides further sub-prefix delegation.



See [LISP-MS] for a description of the functionality of the Map Server and Map Resolver. Note that the target of a delegation must always be an RLOC (not an EID) to avoid any circular dependency.

To provide a mechanism for traversing the database tree, LISP-DDT defines a new LISP message type, the Map-Referral, which is returned to the sender of a Map-Request when the receiving DDT node can refer the sender to another DDT node that has more detailed information.

A DDT client uses LISP-DDT to find an EID-to-RLOC mapping by first sending a Map-Request to the RLOC of a DDT node. The initial choice of DDT node is configured on the client. If the receiving DDT node is also a Map Server that is responsible for the XEID queried, the Map-Request is handled as described in [LISP-MS], with the DDT Map Server also returning a Map-Referral message with the "done" flag set to the Map-Request sender. Otherwise, the DDT node answers the Map- Request with a Map-Referral; the DDT client then re-sends its DDT Map-Request to one of the RLOCs listed in the Map-Referral. This iterative process of sending requests and following referrals continues until the client receives a Map-Referral with the "done" flag set. This is an indication that the terminal DDT Map-Server has either answered the Map-Request (if offering proxy service) or has forwarded it to the correct ETR which will answer it. Conceptually, this is similar to the way that a client of the Domain Name System (DNS) follows referrals (DNS responses that contain only NS records) from a series of DNS servers until it finds an answer.




Extended EID (XEID): a LISP EID, optionally extended with a non- zero Instance ID (IID) if the EID is intended for use in a context where it may not be a unique value, such as on a Virtual Private Network where "private" address space is used. See "Using Virtualization and Segmentation with LISP" in [LISP] for more discussion of Instance IDs.

XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT Key-ID (provided to allow the definition of multiple databases; currently always zero in this version of DDT, with other values reserved for future use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used as a key index into the database.

DDT node: a network infrastructure component responsible for specific XEID-prefix and for delegation of more-specific sub- prefixes to other DDT nodes.

DDT client: a network infrastructure component that sends Map- Request messages and implements the iterative following of Map- Referral results. Typically, a DDT client will be a Map Resolver but it is also possible for an ITR to implement DDT client functionality.

DDT Map Server: a DDT node that also implements Map Server functionality (forwarding Map-Requests and/or returning Map- Replies if offering proxy-mode service) for a subset of its delegated prefixes.

DDT Map Resolver: a network infrastructure element that accepts a Map-Request, adds the XEID to its lookup queue, then queries one or more DDT nodes for the requested EID, following returned referrals until it receives one with the "done" flag. This indicates that the Map-Request has been sent to a Map-Server that will forward it to an ETR that, in turn, will provide a Map-Reply to the original sender. A DDT Map Resolver maintains both a cache of Map-Referral message results containing RLOCs for DDT nodes responsible for XEID-prefixes of interest (termed the "referral cache") plus a lookup queue of XEIDs that are being resolved through iterative querying of DDT nodes.

Encapsulated Map-Request: a LISP Map-Request carried within an Encapsulated Control Message, which has an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are globally-routable IP addresses, also known as RLOCs. Used by an ITR when sending to a Map-Resolver and by a Map-Server when forwarding a Map-Request to an ETR as documented in



[LISP-MS].

DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to a DDT node. The "DDT-originated" flag is set in the encapsulation header indicating that the DDT node should return Map-Referral messages if the Map-Request EID matches a delegated XEID-prefix known to the DDT node. Section 7.1 describes how DDT Map-Requests are sent.

Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node and for which the DDT node may provide further delegations of more-specific sub-prefixes.

Map-Referral: a LISP message sent by a DDT node when it receives a DDT Map-Request for an XEID that matches a configured XEID-prefix delegation. The Map-Referral message includes a "referral", a set of RLOCs for DDT nodes that have more information about the sub- prefix; a DDT client "follows the referral" by sending another DDT Map-Request to one of those RLOCs to obtain either an answer or another referral to DDT nodes responsible for a more-specific XEID-prefix. See Section 5 and Section 7.2 for details on the sending and processing of Map-Referral messages.

negative Map-Referral: a LISP message sent by a DDT node when it receives a DDT Map-Request for an EID that matches a configured authoritative XEID-prefix but for which no delegation (or registration if the DDT node is also a Map Server) is configured.

For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, and Map Resolver, please consult the LISP specification [LISP] and the LISP Mapping Service specification [LISP-MS].



3. EID-prefix tree structure and instance IDs

LISP-DDT defines a tree structure that is indexed by a binary encoding of five fields, in order of significance: Key-ID (16 bits), Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, 16 bits), and EID-prefix (variable, according to AFI value). The fields are concatenated, with the most significant fields as listed above. The index into this structure is also referred to as an Extended EID-prefix (XEID-prefix).

It is important to note that LISP-DDT does not store actual EID-to- RLOC mappings; it is, rather, a distributed index that can be used to find the devices (Map Servers and their registered EIDs) that can be queried with LISP to obtain those mappings. Changes to EID-to-RLOC mappings are made on the ETRs which define them, not to any DDT node configuration. DDT node configuration changes are only required when branches of the database hierarchy are added, removed, or modified.



4. Configuring XEID-prefix delegation

Every DDT node is configured with one or more authoritative XEID- prefixes that it "owns" along with a list of delegations of XEID- prefixes that are known to other DDT nodes. A DDT node is required to maintain a list of delegations for all sub- prefixes of its authoritative XEID-prefixes but also may list "hints", which are prefixes that it knows about that belong to its parents, to the root, or to any other point in the XEID-prefix hierarchy. A delegation (or hint) consists of an XEID-prefix and a set of RLOCs for DDT nodes that have more detailed knowledge of the XEID-prefix. Those RLOCs are returned in Map-Referral messages when the DDT node receives a DDT Map-Request with an xEID that matches a delegation. A DDT Map Server will also have a set of sub-prefixes for which it accepts ETR mapping registrations and for which it will forward (or answer, if it implements proxy mode) Map-Requests.

4.1. Example DDT node configuration

The following is an example of parent and child DDT nodes, where the parent has all of 10.0.0.0/8 and delegates two sub-prefixes, 10.0.0.0/12 and 10.0.16.0/12 to two child DDT nodes. All of these prefixes are within the DDT sub-tree Key-ID=0, IID=223, and AFI=1 (IPv4).

lisp ddt authoritative-prefix instance-id 223 10.0.0.0/8 lisp ddt child 192.168.1.100 instance-id 223 eid-prefix 10.0.0.0/12 lisp ddt child 192.168.1.200 instance-id 223 eid-prefix 10.16.0.0/12

One of the child nodes is a DDT Map Server, configured to allow ETRs to register the sub-prefixes 10.18.0.0/16 and 10.17.0.0/16:

lisp ddt authoritative-prefix instance-id 223 eid-prefix 10.16.0.0/12 lisp site site-1 eid-prefix 10.18.0.0/16 instance-id 223 lisp site site-2 eid-prefix 10.17.0.0/16 instance-id 223

4.2. The root DDT node

The root DDT node is the logical "top" of the database hierarchy: Key-ID=0, EID=0, AFI=0, EID-prefix=0/0. A DDT Map-Request that matches no configured XEID-prefix will be referred to the root node. The root node in a particular instantiation of LISP-DDT must therefore be configured with delegations for at least all defined IIDs and AFIs.



To aid in defining a "sub-root" DDT node that is responsible for all EID-prefixes within multiple IIDs (say, for using LISP to create virtual networks that use overlapping address space), it may be useful to implement configuration language that allows for a range of IIDs to be delegated together. Additional configuration shorthand for delegating of a range of IIDs (and all of the EIDs under them) may also be helpful.



5. DDT node operation - sending referrals

When a DDT node receives a DDT Map-Request, it compares the requested XEID against its list of XEID-prefix delegations and its list of authoritative XEID-prefixes and acts as follows:

5.1. Match of a delegated prefix (or sub-prefix)

If the requested XEID matches one of the DDT node’s delegated prefixes, then a Map-Referral message is returned with the matching more-specific XEID-prefix and the set of RLOCs for the referral target DDT nodes.

Note that a matched delegation does not have to be for a sub-prefix of an authoritative prefix; in addition to being configured to delegate sub-prefixes of an authoritative prefix, a DDT node may also be configured with other XEID-prefixes for which it can provide referrals to DDT nodes anywhere in the database hierarchy. This capability to define "shortcut hints" is never required to be configured but may be a useful heuristic for reducing the number of iterations needed to find an EID, particular for private network deployments.

5.2. Missing delegation from an authoritative prefix

If the requested XEID did not match a configured delegation but does match an authoritative XEID-prefix, then the DDT node returns a negative Map-Referral that includes the least-specific XEID-prefix that does not match any of the DDT node’s authoritative XEID- prefixes. This indicates that the XEID is not a LISP destination.

If the requested XEID did not match either a configured delegation or an authoritative XEID-prefix, then the request is dropped. This should only happen if either a DDT Map Resolver or DDT Map Server is misconfigured. Logging an error message may be a good idea to assist in detecting and resolving such configuration problems.



6. DDT Map Server operation

When a DDT Map Server receives a DDT Map-Request, its operation is similar to that of a DDT node with one exception: if the requested XEID matches a registered XEID-prefix, then the Map-Request is forwarded to one of the destination ETR RLOCs (or the Map-Server sends a Map-Reply, if it is providing proxy service) and a Map- Referral with the "done" flag is returned to the sender of the DDT Map-Request.



7. DDT Map Resolver operation

Just as any other Map Resolver, a DDT Map Resolver accepts Map- Requests from its clients (typically, ITRs) and ensures that those Map-Requests are forwarded to the correct ETR, which generates Map- Replies. Unlike a Map Resolver that uses the ALT mapping system [LISP-ALT], however, a DDT Map Resolver needs to maintain more state as it uses an iterative process of following referrals to find the correct ETR to answer a Map-Request.

7.1. Queuing, Sending, and Retransmitting DDT Map-Requests

When a DDT Map Resolver receives an encapsulated Map-Request, it first does a longest-match search for the XEID in its referral cache. If nothing is found or if a negative cache entry is found, then the destination is not in the database; a negative Map-Reply is returned and no further processing is done by the DDT Map Resolver.

Next, the DDT Map Resolver creates a lookup queue entry for the XEID and saves the original Map-Request along with other information, such as the longest XEID-prefix matched so far, needed for tracking progress through the iterative referral process. The Map Resolver then creates a DDT Map-Request (an encapsulated Map-Request with the "DDT-originated" flag set in the message header) for the XEID but without any authentication data that may have been included in the original Map-Request. It sends the DDT Map-Request to one of the RLOCs in the chosen referral cache entry. The referral cache is initially populated with one or more statically-configured entries; additional entries are added when referrals are followed, as described below. A DDT Map Resolver is not absolutely required to cache referrals but it not doing so will significantly increase latency and cause lookup delays.

Note that in normal use on the public Internet, the statically- configured initial referral cache for a DDT Map Resolver should include a "default" entry with RLOCs for one or more DDT nodes that can reach the DDT root node. If a Map Resolver does not have such configuration, it will return a Negative Map-Reply if it receives a query for an EID outside the subset of the mapping database known to it. While this may be desirable on private network deployments or during early transition to LISP when few sites are using it, this behavior is not appropriate when LISP is in general use on the Internet.

7.2. Receiving and following referrals

After sending a DDT Map-Request, a DDT Map Resolver can expect one of the following to occur:



o No response. The DDT Map Resolver retransmits the request, choosing a different RLOC from the referral cache entry if one is available. If the maximum number of retransmissions has occurred, then the lookup queue entry is dequeued and a negative Map-Reply is returned to the original Map-Request sender.

o A negative Map-Referral from the DDT node. This indicates that the destination XEID is not in the mapping database. The lookup queue entry is dequeued and a negative Map-Reply is returned to the original Map-Request sender. A negative referral cache entry is also created for the XEID-prefix and TTL value in the negative Map-Referral message.

o A Map-Referral with the "done" indication from the DDT node (see Section 6). This indicates that the Map-Request has been sent to a Map Server that has ETR RLOCs for the destination XEID. If the original Map-Request included a LISP-SEC ECM Authentication Data field (saved in Section 7.1, Paragraph 2) then the request is re- sent, with the Authentication Data included, to the Map Server. The Map Server will forward the request to an ETR that can provide a Map-Reply to the original Map-Request sender. This is a successful completion of the DDT iteration process, so the lookup queue entry is is dequeued. A referral cache entry is also created (or updated) for the XEID-prefix, RLOC set, and TTL value in the Map-Referral message.

o A Map-Referral from the DDT node. The DDT Map-Request is updated with the RLOCs contained in the Map-Referral, the referred prefix is updated in the lookup queue entry, and the DDT Map-Request is sent to one of the new destination DDT node RLOCs. A referral cache entry is also created (or updated) for the XEID-prefix, RLOC set, and TTL value in the Map-Referral message.

7.2.1. Handling referral errors

Other states are possible, such as a misconfigured DDT node (acting as a proxy Map Server, for example) returning a Map-Reply to the DDT Map Resolver; they should be considered errors and logged as such. It is not clear exactly what else the DDT Map-Resolver should do in such cases; one possibility is to dequeue the lookup queue entry and send a negative Map-Reply to the original Map-Request sender. Alternatively, if a DDT Map Resolver detects unexpected behavior by a DDT node, it could mark that node as unusable in its referral cache and update the lookup queue entry to try a different DDT node if more than one is listed in the referral cache.



7.2.2. Referral loop detection

With any iterative process, there is always the danger of an iteration loop. To prevent this, a DDT Map Resolver must check that it does not receive and follow a referral that is for a less-specific XEID-prefix than it has received in a previous referral. For this reason, it stores the most recent XEID-prefix received by referral in each lookup queue entry; if it receives a referral that is a less- specific match for the XEID than the last referral received, then a loop has occurred and the Map-Resolver handles the request as described in Section 7.2.1. As an extra measure to prevent referral loops, it is probably also wise to limit the total number of referrals for any request to some reasonable number; the exact value of that number will be determined during experimental deployment of LISP-DDT.

Note that when a Map-Request is originally received and an entry has been added to the lookup queue, the new request has no previous referral XEID-prefix; this means that the first DDT node contacted by a DDT Map Resolver may provide a referral to anywhere in the DDT hierarchy. This, in turn, allows a DDT Map Resolver to use essentially any DDT node RLOCs for its initial cache entries and depend on the initial referral to provide a good starting point for Map-Requests; there is no need to configure the same set of root DDT nodes in all DDT Map Resolvers.



8. Example message flow

The following describes the message flows among an ITR, a DDT Map Resolver, a number of DDT nodes, a DDT Map Server, and an ETR. It assumes no security associations between the DDT nodes but does show how [LISP-SEC] can be used between the ITR, Map Resolver, Map Server, and ETR.

8.1. ITR sends a Map-Request to a DDT Map Resolver

The first step in using LISP-DDT is the same as for any other Map- Request using the Map Server interface: an ITR sends an encapsulated Map-Request to one of its configured Map Resolvers, in this case a DDT Map Resolver. The outer header source IP address is the ITR and the outer header destination IP address is the DDT Map Resolver. If [LISP-SEC] is in use, then LISP-SEC ECM Authentication Data field is included.

8.2. DDT Map Resolver receives and processes Map-Request

The DDT Map Resolver receives and processes the encapsulated Map- Request by stripping the encapsulation header and creating a lookup queue entry for the XEID, saving the resulting, non-encapsulated Map- Request for later retransmission and re-use during the referral process. The lookup queue entry will be dequeued when the DDT Map Resolver is finished with the request (see Section 8.8).

Note that if a lookup queue entry already exists for the destination XEID and the requesting ITR (which could happen if an ITR has retransmitted a Map-Request), the Map-Request is replaced to ensure that the ITR-generated nonce and OTK are updated.

8.3. DDT Map Resolver searches referral cache for XEID

Next, the DDT Map Resolver searches its referral cache for the XEID. If none is found or if a negative cache entry is found, then the XEID does not exist in the database; a negative Map-Reply is returned to the original sender and the lookup queue entry is dequeued.

If the referral cache entry found is for a DDT Map Server, then the DDT Map Resolver has found the appropriate terminal node in the DDT hierarchy. It finishes processing the lookup queue entry as described in Section 8.8.

At this point, the referral cache entry must be for a DDT node that can provide more-specific information for the requested XEID so a DDT Map-Request is created and sent (see below).



8.4. DDT Map Resolver creates and sends DDT Map-Request

To follow a referral and query the next DDT node, the DDT Map Resolver creates a new DDT Map-Request, an encapsulated Map-Request using one of the RLOCs of the target DDT node as the outer header destination IP address and itself as the outer header source IP address. The "DDT-originated" flag is set in the encapsulation header to inform the target DDT node that it should return referrals. The original Map-Request LISP-SEC information, if any, is NOT included. The original Map-Request destination XEID is used in the new Map-Request while the source is one of the DDT Map Resolver’s RLOCs.

The new "DDT Map-Request" is transmitted to the destination DDT node. If no response is received within a timeout, it is re-transmitted, preferably using a different destination DDT node RLOC. If the maximum number of retransmissions is exceeded, the request is dequeued and a negative Map-Reply is returned to the ITR that sent the original Map-Request.

8.5. DDT node receives and processes DDT Map-Request

The destination DDT node searches its configured delegations and authoritative prefixes for the XEID in the received encapsulated Map- Request. If no match is found, then the DDT Map-Request is silently discarded and, optionally, an error is logged.

If a delegation is found, the DDT node sends a Map-Referral message back to the DDT Map Resolver with the matched XEID-prefix and the set of RLOCs for DDT nodes that can be used to resolve XEIDs within that prefix.

If no matching delegation was found and the XEID matches one of the DDT node’s authoritative prefixes, then the destination is not a LISP XEID (or a configuration error has occurred); the DDT node returns a negative Map-Referral message to the DDT Map Resolver as described in Section 5.2.

8.6. DDT Map Resolver processes Map-Referral

When the DDT Map Resolver receives a Map-Referral from a DDT-node, it first verifies that it has a corresponding lookup queue entry; if none can be found, then the Map-Referral is silently ignored, with optional error logging.

If the received Map-Referral was negative, then the destination XEID is not in the database; a negative Map-Reply is returned to the original Map-Request sender, a negative referral cache entry is



created for the returned XEID-prefix (with TTL from the Map-Referral message), and the lookup queue entry is dequeued.

For a non-negative Map-Referral, the lookup queue entry is updated with the new referral XEID-prefix and new DDT-node RLOCs. At this point, it also checks to make sure that a referral loop has not occurred (see Section 7.2.2).

To speed processing of future Map-Requests for the same XEID-prefix, the DDT Map Resolver adds a new entry (or updates an existing, matching entry) in its referral cache for the XEID-prefix, RLOC set, and TTL value in the Map-Referral message. Finally, processing continues to Section 8.4 to query the new destination DDT-node.

8.7. DDT Map Server receives Map-Request

At this point, the DDT Map Resolver has found the DDT Map Server responsible for the destination XEID-prefix and has sent its Map- Request there. The DDT Map Server receives the DDT Map-Request, strips the encapsulation header, and searches for the destination XEID in its set of configured XEID-prefixes. If the XEID is found and an ETR has registered for it, then DDT Map Server returns a Map- Referral to the DDT Map Resolver indicating (by setting the "done" flag) that it has found the terminal DDT node. If no LISP-SEC header was included in the original Map-Request, then the Map-Request is forwarded to one of the registered ETRs for further processing (Section 8.10); otherwise, the Map-Request is discarded so that the DDT Map Resolver can re-send it to the DDT Map Server with LISP-SEC information included.

8.8. DDT Map Resolver finished

At this point, the DDT Map Resolver has finished the referral iteration process. If security processing was requested, the DDT Map Resolver now re-sends the DDT Map-Request to the DDT Map Server with the LISP-SEC information included in the encapsulation header. The DDT Map Resolver dequeues the lookup queue entry for the XEID and cleans-up any other saved state.

8.9. DDT Map Server receives LISP-SEC-enabled Map-Request

When the DDT Map Server receives the re-sent DDT Map-Request, with LISP-SEC information included, it decrypts the LISP-SEC information, performs normal LISP-SEC processing, and forwards the resulting Map- Request to the target ETR.



8.10. ETR sends Map-Reply to ITR

The ETR receives a Map-Request as documented in [LISP], performs any necessary processing of security information, as documented in [LISP-SEC], and sends a Map-Reply to the ITR that sent the original Map-Request.



9. Open Issues and Considerations

There are a number of issues with the organization of the mapping database that need further investigation. Among these are:

o Unlike in [LISP-ALT], DDT does not currently define a mechanism for propagating ETR-to-Map Server registration state. This requires DDT Map Servers to suppress returning negative Map-Reply messages for defined but unregistered XEID-prefixes to avoid loss of connectivity during partial ETR registration failures. Suppressing these messages may cause a delay for an ITR obtaining a mapping entry when such a failure is occurring.

o Defining an interface to implement interconnection and/or interoperability with other ased mapping databases, such as LIST+ ALT.

o Additional key structures for use with LISP-DDT, such as to support additional EID formats as defined in [LCAF].

o Authentication of delegations between DDT nodes.

o Possibility of a new, more general format for the Map-Referral messages to facilitate the use of LISP-DDT with additional Key-ID/ IID/EID combinations. Currently-defined packet formats should be considered to be preliminary and provisional until this issue has received greater attention.

o Management of the DDT Map Resolver referral cache, in particular, detecting and removing outdated entries.

The authors expect that experimentation on the LISP pilot network will help answer open questions surrounding these and other issues.




This document makes no request of the IANA.




Future revisions of this document will add public/private key pairing and use between DDT nodes. DDT will not rely on external security infrastructure.



12. References

12.1. Normative References

[LCAF] Farinacci, D. and J. Snijders, "LISP Canonical Address Format", draft-ietf-lisp-lcaf-06.txt (work in progress), October 2011.

[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-16.txt (work in progress), October 2011.

[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface", draft-ietf-lisp-ms-12.txt (work in progress), October 2011.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.

[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.

12.2. Informative References

[LISP-ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-10.txt (work in progress), October 2011.

[LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. Bonaventure, "LISP-Security", draft-maino-lisp-sec-00.txt (work in progress), July 2011.



Appendix A. Acknowledgments

The authors with to express their thanks to Damien Saucez, Lorand Jakab, and Olivier Bonaventure for work on LISP-TREE and LISP iterable mappings that inspired the hierarchical database structure and lookup iteration approach described in this document. Special thanks also go to Vina Ermagan, Amit Jain, Isidor Kouvelas, Jesper Skriver, Andrew Partan, and Noel Chiappa, all of whom have participated in (and put up with) seemingly endless hours of discussion of LISP mapping database ideas and issues.



Appendix B. Map-Referral Message Format

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=6 |D|M| Reserved | Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | ACT |A| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | Reserved | EID-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix ... | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator ... | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D (the "done flag") is set when a DDT Map Server sends a Map-Referral to indicate that processing is "done". M (the "DDT Map Server flag") indicates that the a DDT Map Server has found a matching, registered XEID-prefix for the XEID in the original Map-Request.

All the field descriptions are equivalent to those in the Map-Reply message, as defined in [LISP]. Note, though, that the set of RLOCs correspond to the DDT node to be queried as a result of the referral not the RLOCs for an actual EID-to-RLOC mapping.



Appendix C. Encapsulated Control Message Format

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = 4342 | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=8 |S|D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = yyyy | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"D" is the "DDT-originated" flag and is set by a DDT client to indicate that the receiver can and should return Map-Referral messages as appropriate.




Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA


Darrel Lewis cisco Systems Tasman Drive San Jose, CA 95134 USA


Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA



Network Working Group V. FullerInternet-Draft D. LewisIntended status: Experimental V. ErmaganExpires: April 2, 2013 A. Jain cisco Systems September 29, 2012

LISP Delegated Database Tree draft-fuller-lisp-ddt-04.txt

Abstract

This draft describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.

Status of this Memo




This Internet-Draft will expire on April 2, 2013.

Copyright Notice


This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents

Fuller, et al. Expires April 2, 2013 [Page 1]

Internet-Draft LISP Delegated Database Tree September 2012

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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 3. Database organization . . . . . . . . . . . . . . . . . . . . 8 3.1. EID-prefix tree structure and instance IDs . . . . . . . . 8 3.2. Configuring prefix delegation . . . . . . . . . . . . . . 8 3.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 8 4. The Map-Referral message . . . . . . . . . . . . . . . . . . . 10 4.1. Action codes . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Referral Set . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 11 5. DDT network elements and their operation . . . . . . . . . . . 12 5.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 12 5.1.2. Missing delegation from an authoritative prefix . . . 12 5.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . . 13 5.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Queuing and sending DDT Map-Requests . . . . . . . . . 13 5.3.2. Receiving and following referrals . . . . . . . . . . 14 5.3.3. Handling referral errors . . . . . . . . . . . . . . . 15 5.3.4. Referral loop detection . . . . . . . . . . . . . . . 16 6. Psuedo Code and Decision Tree diagrams . . . . . . . . . . . . 17 6.1. Map Resolver processing of ITR Map-Request . . . . . . . . 17 6.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 17 6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 18 6.2. Map Resolver processing of Map-Referral message . . . . . 19 6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 21 6.3. DDT Node processing of DDT Map-Request message . . . . . . 22 6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 22 6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 23 7. Example topology and request/referral following . . . . . . . 24 7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 25 7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . . 26 7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 27 7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . . 27 7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 . . . . 28 8. Securing the database and message exchanges . . . . . . . . . 29 8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . . 29 8.2. DDT node operation . . . . . . . . . . . . . . . . . . . . 30



8.2.1. DDT public key revocation . . . . . . . . . . . . . . 30 8.3. Map Server operation . . . . . . . . . . . . . . . . . . . 30 8.4. Map Resolver operation . . . . . . . . . . . . . . . . . . 31 9. Open Issues and Considerations . . . . . . . . . . . . . . . . 32 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 11. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 12.2. Informative References . . . . . . . . . . . . . . . . . . 35 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36 Appendix B. Map-Referral Message Format . . . . . . . . . . . . . 37 B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix C. Encapsulated Control Message Format . . . . . . . . . 41 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42



1. Introduction

[LISP] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: relatively static Endpoint Identifiers (EIDs), used end-to-end for terminating transport-layer associations, and Routing Locators (RLOCs), which are more dynamic, are bound to topological location, and are used for routing and forwarding through the Internet infrastructure.

LISP offers a general-purpose mechanism for mapping between EIDs and RLOCs. In organizing a database of EID to RLOC mappings, this specification extends the definition of the EID numbering space by logically prepending and appending several fields for purposes of defining the database index key: Database-ID (DBID, 16 bits), Instance dentifier (IID, 32-bits), Address Family Identifier (16 bits), and EID-prefix (variable, according to AFI value). The resulting concatenation of these fields is termed an "Extended EID prefix" or XEID-prefix.

The term "Extended EID" (XEID) is also used for an individual LISP EID that is further qualified through the use of an Instance ID. See [LCAF] for further discussion of the use of Instance IDs.

The DBID is provided for possible use in case a need evolves for another, higher level in the hierarchy, to allow the creation of multiple, separate database trees.

LISP-DDT is a hierarchical distributed database which embodies the delegation of authority to provide mappings, i.e. its internal structure mirrors the hierarchical delegation of address space. It also provides delegation information to Map Resolvers, which use the information to locate EID-to-RLOC mappings. A Map Resolver which needs to locate a given mapping will follow a path through the tree- structured database, contacting, one after another, the DDT nodes along that path until it reaches the leaf DDT node(s) authoritative for the mapping it is seeking.

LISP-DDT defines a new device type, the DDT node, that is configured as authoritative for one or more XEID-prefixes. It also is configured with the set of more-specific sub-prefixes that are further delegated to other DDT nodes. To delegate a sub-prefix, the "parent" DDT node is configured with the RLOCs of each child DDT node that is authoritative for the sub-prefix. Each RLOC either points to a Map Server (sometimes termed a "terminal DDT node") to which an Egress Tunnel Routers (ETRs) has registered that sub-prefix or points to another DDT node in the database tree that further delegates the sub-prefix. See [LISP-MS] for a description of the functionality of



the Map Server and Map Resolver. Note that the target of a delegation must always be an RLOC (not an EID) to avoid any circular dependency.

To provide a mechanism for traversing the database tree, LISP-DDT defines a new LISP message type, the Map-Referral, which is returned to the sender of a Map-Request when the receiving DDT node can refer the sender to another DDT node that has more detailed information. See Section 4 for the definition of the Map-Referral message.

To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map Resolver, starts by sending an Encapsulated Map-Request to a preconfigured DDT node RLOC. The DDT node responds with a Map- Referral message that either indicates that it will find the requested mapping to complete processing of the request or that the DDT client should contact another DDT node that has more-specific information; in the latter case, the DDT node then sends a new Encapsulated Map-Request to the next DDT node and the process repeats in an iterative manner.

Conceptually, this is similar to the way that a client of the Domain Name System (DNS) follows referrals (DNS responses that contain only NS records) from a series of DNS servers until it finds an answer.




Extended EID (XEID): a LISP EID, optionally extended with a non- zero Instance ID (IID) if the EID is intended for use in a context where it may not be a unique value, such as on a Virtual Private Network where [RFC1918] address space is used. See "Using Virtualization and Segmentation with LISP" in [LISP] for more discussion of Instance IDs.

XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided to allow the definition of multiple databases; currently always zero in this version of DDT, with other values reserved for future use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used as a key index into the database.


DDT client: a network infrastructure component that sends Map- Request messages and implements the iterative following of Map- Referral results. Typically, a DDT client will be a Map Resolver but it is also possible for an ITR to implement DDT client functionality.

DDT Map Server: a DDT node that also implements Map Server functionality (forwarding Map-Requests and/or returning Map- Replies if offering proxy Map-Reply service) for a subset of its delegated prefixes.

DDT Map Resolver: a network infrastructure element that accepts a Map-Request, adds the XEID to its pending request list, then queries one or more DDT nodes for the requested EID, following returned referrals until it receives one with action code MS-ACK (or an error indication). MS-ACK indicates that the Map-Request has been sent to a Map Server that will forward it to an ETR that, in turn, will provide a Map-Reply to the original sender. A DDT Map Resolver maintains both a cache of Map-Referral message results containing RLOCs for DDT nodes responsible for XEID- prefixes of interest (termed the "referral cache") a pending request list of XEIDs that are being resolved through iterative querying of DDT nodes.

Encapsulated Map-Request: a LISP Map-Request carried within an Encapsulated Control Message, which has an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are globally-routable IP addresses, also known as RLOCs. Used by an ITR when sending to a Map Resolver and by a Map Server



when forwarding a Map-Request to an ETR as documented in [LISP-MS].

DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to a DDT node. The "DDT-originated" flag is set in the encapsulation header indicating that the DDT node should return Map-Referral messages if the Map-Request EID matches a delegated XEID-prefix known to the DDT node. Section 5.3.1 describes how DDT Map-Requests are sent.

Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node and for which the DDT node may provide further delegations of more-specific sub-prefixes.

Map-Referral: a LISP message sent by a DDT node in response to a DDT Map-Request for an XEID that matches a configured XEID-prefix delegation. A non-negative Map-Referral includes a "referral", a set of RLOCs for DDT nodes that have more information about the sub-prefix; a DDT client "follows the referral" by sending another DDT Map-Request to one of those RLOCs to obtain either an answer or another referral to DDT nodes responsible for a more-specific XEID-prefix. See Section 5.1 and Section 5.3.2 for details on the sending and processing of Map-Referral messages.

negative Map-Referral: a Map-Referral sent in response to a DDT Map-Request that matches an authoritative XEID-prefix but for which there is no delegation configured (or no ETR registration if sent by a DDT Map-Server).

Pending Request List: the set of outstanding requests for which a DDT Map Resolver has received encapsulated Map-Requests from a DDT client for an XEID. Each entry in the list contains additional state needed by the referral following process, including the requestor(s) of the XEID (typically, one or more ITRs), saved information about the last referral received and followed (matching XEID-prefix, action code, RLOC set, index of last RLOC queried in the RLOC set), and any [LISP-SEC] information that was included in the DDT client Map-Request. An entry in the list may be interchangeably termed a "pending request list entry" or simply a "pending request".

For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, and Map Resolver, please consult the LISP specification [LISP] and the LISP Mapping Service specification [LISP-MS].



3. Database organization

3.1. EID-prefix tree structure and instance IDs

LISP-DDT defines a tree structure that is indexed by a binary encoding of five fields, in order of significance: DBID (16 bits), Instance Identifier (IID, 32 bits), Address Family Identifier (AFI, 16 bits), and EID-prefix (variable, according to AFI value). The fields are concatenated, with the most significant fields as listed above. The index into this structure is also referred to as an Extended EID-prefix (XEID-prefix).

It is important to note that LISP-DDT does not store actual EID-to- RLOC mappings; it is, rather, a distributed index that can be used to find the devices (Map Servers and their registered EIDs) that can be queried with LISP to obtain those mappings. Changes to EID-to-RLOC mappings are made on the ETRs which define them, not to any DDT node configuration. DDT node configuration changes are only required when branches of the database hierarchy are added, removed, or modified.

3.2. Configuring prefix delegation

Every DDT node is configured with one or more XEID-prefixes for which it is authoritative along with a list of delegations of XEID-prefixes to other DDT nodes. A DDT node is required to maintain a list of delegations for all sub-prefixes of its authoritative XEID-prefixes; it also may list "hints", which are prefixes that it knows about that belong to its parents, to the root, or to any other point in the XEID-prefix hierarchy. A delegation (or hint) consists of an XEID- prefix, a set of RLOCs for DDT nodes that have more detailed knowledge of the XEID-prefix, and accompanying security information. Those RLOCs are returned in Map-Referral messages when the DDT node receives a DDT Map-Request with an xEID that matches a delegation. A DDT Map Server will also have a set of sub-prefixes for which it accepts ETR mapping registrations and for which it will forward (or answer, if it provides proxy Map-Reply service) Map-Requests. For details of security infomation in Map-Referrals see Section 8.

3.2.1. The root DDT node

The root DDT node is the logical "top" of the database hierarchy: DBID=0, IID=0, AFI=0, EID-prefix=0/0. A DDT Map-Request that matches no configured XEID-prefix will be referred to the root node. The root node in a particular instantiation of LISP-DDT must therefore be configured with delegations for at least all defined IIDs and AFIs.

To aid in defining a "sub-root" DDT node that is responsible for all EID-prefixes within multiple IIDs (say, for using LISP to create



virtual networks that use overlapping address space), it may be useful to implement configuration language that allows for a range of IIDs to be delegated together. Additional configuration shorthand for delegating a range of IIDs (and all of the EIDs under them) may also be helpful.



4. The Map-Referral message

A Map-Referral message is sent by a DDT node to a DDT client in response to a DDT Map-Request message. The message consists of an action code along with delegation information about the XEID-prefix that matches the XEID requested.

See Appendix B for a detailed layout of the Map-Referral message fields.

4.1. Action codes

The action codes are as follows:

NODE-REFERRAL (0): indicates that the replying DDT node has delegated an XEID-prefix that matches the requested XEID to one or more other DDT nodes. The Map-Referral message contains a "map- record" with additional information, most significantly the set of RLOCs to which the prefix has been delegated, that is used by a DDT Map Resolver to "follow" the referral.

MS-REFERRAL (1): indicates that the replying DDT node has delegated an XEID-prefix that matches the requested XEID to one or more DDT Map Servers. It contains the same additional information as a NODE-REFERRAL but is handled slightly differently by the receiving DDT client (see Section 5.3.2).

MS-ACK (2): indicates that a replying DDT Map Server received a DDT Map-Request that matches an authoritative XEID-prefix for which is has one or more registered ETRs. This means that the request can be forwarded to one of those ETRs to provide an answer to the querying ITR.

MS-NOT-REGISTERED (3): indicates that the replying DDT Map Server received a Map-Request for one of its configured XEID-prefixes which has no ETRs registered.

DELEGATION-HOLE (4): indicates that the requested XEID matches a non-delegated sub-prefix of the XEID space. This is a non-LISP "hole", which has not been delegated to any DDT Map Server or ETR. See Section 5.1.2 for details.

NOT-AUTHORITATIVE (5): indicates that the replying DDT node received a Map-Request for an XEID-request for which it is not authoritative. This can occur if a cached referral has become invalid due to a change in the database hierarchy.



4.2. Referral Set

For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a DDT node includes in the Map-Referral message a list of RLOCs for all DDT nodes that are authoritative for the XEID-prefix being returned; a DDT Map Resolver uses this information to contact one of those DDT nodes as it "follows" a referral.

4.3. Incomplete flag

A DDT node sets the "Incomplete" flag in a Map-Referral message if the Referral Set is incomplete; this is intended to prevent a DDT Map Resolver from caching a referral with incomplete information. A DDT node must set the "incomplete" flag in the following cases:

o If it is setting action code MS-ACK or MS-NOT-REGISTERED but does not have configuration for other "peer" DDT nodes that are also authoritative for the matched XEID-prefix.

o If it is setting action code NOT-AUTHORITATIVE.



5. DDT network elements and their operation

As described above, DDT introduces a new network element, the "DDT node", extends the functionality of Map Servers and Map Resolvers to send and receive Map-Referral messages. The operation of each of these devices is described as follows.

5.1. DDT node

When a DDT node receives a DDT Map-Request, it compares the requested XEID against its list of XEID-prefix delegations and its list of authoritative XEID-prefixes and acts as follows:

5.1.1. Match of a delegated prefix (or sub-prefix)

If the requested XEID matches one of the DDT node’s delegated prefixes, then a Map-Referral message is returned with the matching more-specific XEID-prefix and the set of RLOCs for the referral target DDT nodes including associated security information (see Section 8 for details on security). If the delegation is known to be a DDT Map Server, then the Map-Referral message is sent with action code MS-REFERRAL to indicate to the receiver that LISP-SEC information (if saved in the pending request) should be included in the next DDT Map-Request; otherwise, the action code NODE-REFERRAL is used.

Note that a matched delegation does not have to be for a sub-prefix of an authoritative prefix; in addition to being configured to delegate sub-prefixes of an authoritative prefix, a DDT node may also be configured with other XEID-prefixes for which it can provide referrals to DDT nodes anywhere in the database hierarchy. This capability to define "shortcut hints" is never required to be configured but may be a useful heuristic for reducing the number of iterations needed to find an EID, particular for private network deployments.

5.1.2. Missing delegation from an authoritative prefix

If the requested XEID did not match a configured delegation but does match an authoritative XEID-prefix, then the DDT node returns a negative Map-Referral that uses the least-specific XEID-prefix that does not match any XEID-prefix delegated by the DDT node. The action code is set to DELEGATION-HOLE; this indicates that the XEID is not a LISP destination.

If the requested XEID did not match either a configured delegation or an authoritative XEID-prefix, then the request is dropped and a negative Map-Referral with action code NOT-AUTHORITATIVE is returned.



5.2. DDT Map Server

When a DDT Map Server receives a DDT Map-Request, its operation is similar to that of a DDT node with additional processing as follows:

o If the requested XEID matches a registered XEID-prefix, then the Map-Request is forwarded to one of the destination ETR RLOCs (or the Map Server sends a Map-Reply, if it is providing proxy Map- Reply service) and a Map-Referral with the MS-ACK action is returned to the sender of the DDT Map-Request.

o If the requested XEID matches a configured XEID-prefix for which no ETR registration has been received then a negative Map-Referral with action code MS-NOT-REGISTERED is returned to the sender of the DDT Map-Request.

5.3. DDT Map Resolver

Just as any other Map Resolver, a DDT Map Resolver accepts Map- Requests from its clients (typically, ITRs) and ensures that those Map-Requests are forwarded to the correct ETR, which generates Map- Replies. Unlike a Map Resolver that uses the ALT mapping system [LISP-ALT], however, a DDT Map Resolver uses an iterative process of following referrals to find the correct ETR to answer a Map-Request; this requires a DDT Map Resolver to maintain additional state: a Map- Referral cache and pending request list of XEIDs that are going through the iterative referral process.

5.3.1. Queuing and sending DDT Map-Requests

When a DDT Map Resolver receives an encapsulated Map-Request, it first performs a longest-match search for the XEID in its referral cache. If no match is found or if a negative cache entry is found, then the destination is not in the database; a negative Map-Reply is returned and no further processing is performed by the DDT Map Resolver.

If a match is found, the DDT Map Resolver creates a pending request list entry for the XEID and saves the original Map-Request (minus the encapsulation header) along with other information needed to track progress through the iterative referral process; the "referral XEID- prefix" is also initialized to the null value since no referral has yet been received. The Map Resolver then creates a DDT Map-Request (which is an encapsulated Map-Request with the "DDT-originated" flag set in the message header) for the XEID but without any authentication data that may have been included in the original Map- Request. It sends the DDT Map-Request to one of the RLOCs in the chosen referral cache entry. The referral cache is initially



populated with one or more statically-configured entries; additional entries are added when referrals are followed, as described below. A DDT Map Resolver is not absolutely required to cache referrals but it doing so decreases latency and reduces lookup delays.

Note that in normal use on the public Internet, the statically- configured initial referral cache for a DDT Map Resolver should include a "default" entry with RLOCs for one or more DDT nodes that can reach the DDT root node. If a Map Resolver does not have such configuration, it will return a Negative Map-Reply if it receives a query for an EID outside the subset of the mapping database known to it. While this may be desirable on private network deployments or during early transition to LISP when few sites are using it, this behavior is not appropriate when LISP is in general use on the Internet.

5.3.2. Receiving and following referrals

After sending a DDT Map-Request, a DDT Map Resolver expects to receive a Map-Referral response. If none occurs within the timeout period, the DDT Map Resolver retransmits the request, sending to the next RLOC in the referral cache entry if one is available. If the maximum number of retransmissions has occurred and all RLOCs have been tried, then the pending request list entry is dequeued.

A DDT Map Resolver processes a received Map-Referral message according to each action code:

NODE-REFERRAL: The DDT Map Resolver checks for a possible referral loop as as described in Section 5.3.4. If no loop is found, the DDT Map Resolver saves the prefix returned in the Map-Referral message in the referral cache, updates the saved prefix and saved RLOCs in the pending request list entry, and follows the referral by sending a new DDT Map-Request to one of the DDT node RLOCs listed in the Referral Set; security information saved with the original Map-Request is not included.

MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same manner as a NODE-REFERRAL except that that security information saved with the original Map-Request is included in the new Map- Request sent to a Map Server (see Section 8 for details on security).

MS-ACK: This is returned by a DDT Map Server to indicate that it has one or more registered ETRs that can answer a Map-Request for the XEID. If the pending request did not include saved LISP-SEC information or if that information was already included in the previous DDT Map-Request (sent by the DDT Map Resolver in response



to either an MS-REFERRAL or a previous MS-ACK referral), then the pending request for the XEID is complete and is dequeued. Otherwise, LISP-SEC information is required and has not yet been sent to the authoritative DDT Map-Server; the DDT Map Resolver re- sends the DDT Map-Request with LISP-SEC information included and the pending request queue entry remains until another Map-Referral with MS-ACK action code is received. If the "incomplete" flag is not set, the prefix is saved in the referral cache.

MS-NOT-REGISTERED: The DDT Map Server qurieed could not process the request because it did not have any ETRs registered for a matching, authoritative XEID-prefix. If the DDT Map Resolver has not yet tried all of the RLOCs saved with the pending request, then it sends a Map-Request to the next RLOC in that list. If all RLOCs have been tried, then the destination XEID is not registered and is unreachable. The DDT Map Resolver returns a negative Map- Reply to the original Map-Request sender; this Map-Reply contains the non-registered XEID-prefix with TTL value of one minute. A negative referral cache entry is created for the prefix (also with TTL of one minute) and the pending request is dequeued.

DELEGATION-HOLE: The DDT Map Server queried did not have an XEID- prefix defined that matched the requested XEID so it does not exist in the mapping database. The DDT Map Resolver returns a negative Map-Reply to the original Map-Request sender; this Map- Reply will indicate the least-specific XEID-prefix matching the requested XEID for which no delegations exist and will have a TTL value of 15 minutes. A negative referral cache entry is created for the prefix (also with TTL of 15 minutes) and the pending request is dequeued.

NOT-AUTHORITATIVE: The DDT Map Server queried is not authoritative for the requested XEID. This can occur if a cached referral has become invalid due to a change in the database hierarchy. If the DDT Map Resolver receiving this message can determine that it is using old cached information, it may choose to delete that cached information and re-try the original Map-Request, starting from its "root" cache entry. If this action code is received in response to a query that was not to cached referral information, then it indicates a database synchronization problem or configuration error. The pending request list entry that caused this answer is removed, with no answer returned to the original requestor.

5.3.3. Handling referral errors

Other states are possible, such as a misconfigured DDT node (acting as a proxy Map Server, for example) returning a Map-Reply to the DDT Map Resolver; they should be considered errors and logged as such.



It is not clear exactly what else the DDT Map Resolver should do in such cases; one possibility is to remove the pending request list entry and send a negative Map-Reply to the original Map-Request sender. Alternatively, if a DDT Map Resolver detects unexpected behavior by a DDT node, it could mark that node as unusable in its referral cache and update the pending request to try a different DDT node if more than one is listed in the referral cache. In any case, any prefix contained in a Map-Referral message that causes a referral error (including a referral loop) is not saved in the DDT Map- Resolver referral cache.

5.3.4. Referral loop detection

In response to a Map-Referral message with action code NODE-REFERRAL or MS-REFERRAL, a DDT Map Resolver is directed to query a new set of DDT node RLOCs that are expected to have more-specific XEID-prefix information for the requested XEID. To prevent a possible "iteration loop" (following referrals back-and-forth among a set of DDT nodes without ever finding an answer), a DDT Map Resolver saves the last received referral XEID-prefix for each pending request and checks that a newly received NODE-REFERRAL or MS-REFERRAL message contains a more-specific referral XEID-prefix; an exact or less-specific match of the saved XEID-prefix indicates a referral loop. If a loop is detected, the DDT Map Resolver handles the request as described in Section 5.3.3. Otherwise, the Map Resolver saves the most recently received referral XEID-prefix with the pending request when it follows the referral.

As an extra measure to prevent referral loops, it is probably also wise to limit the total number of referrals for any request to some reasonable number; the exact value of that number will be determined during experimental deployment of LISP-DDT but is bounded by the maximum length of the XEID.

Note that when a DDT Map Resolver adds an entry to its lookup queue and sends an initial Map-Request for an XEID, the queue entry has no previous referral XEID-prefix; this means that the first DDT node contacted by a DDT Map Resolver may provide a referral to anywhere in the DDT hierarchy. This, in turn, allows a DDT Map Resolver to use essentially any DDT node RLOCs for its initial cache entries and depend on the initial referral to provide a good starting point for Map-Requests; there is no need to configure the same set of root DDT nodes on all DDT Map Resolvers.



6. Psuedo Code and Decision Tree diagrams

To aid in implementation, each of the major DDT Map Server and DDT Map Resolver functions are described below, first using simple "psuedo-code" and then in the form of a decision tree.

6.1. Map Resolver processing of ITR Map-Request

6.1.1. Pseudo-code summary

if ( request pending i.e., (ITR,EID) of request same ) { replace old request with new & use new request nonce for future requests } else if ( no match in refcache ) { return negative map-reply to ITR } else if ( match type delegation hole ) { return negative map-reply to ITR } else if ( match type ms-ack ) { fwd DDT request to map-server } else { store & fwd DDT request w/o OTK to node delegation }



6.1.2. Decision tree diagram

+------------+ | Is Request | Yes | |----> Replace old request with | Pending? | new nonce for future requests +------------+ | |No | V +------------+ | Match In | No | Referral |----> Send Negative Map Reply | cache? | (not a likely event as root +------------+ configured on every MR) | |Yes | V +------------+ | Match Type | Yes | Delegation |----> Send Negative Map Reply | Hole ? | +------------+ | |No | V +------------+ | Match Type | Yes | MS-ACK? |----> Forward DDT Map-request to Map-Server | | +------------+ | |No | V Store request & Fwd DDT Request w/o OTK to DDT node delegation



6.2. Map Resolver processing of Map-Referral message


if ( no request pending matched by referral nonce ) { silently drop }

if ( pfx in referral less specific than last referral used ) { if ( gone through root ) { silently drop } else { goto root } }

switch (map_referral_type) {

case NOT_AUTHORITATIVE : if ( gone through root ) { return negative map-reply to ITR } else { goto root }

case DELEGATION_HOLE: cache & send negative map-reply to ITR

case MS_REFERRAL: if ( referral equal to last used ) { if ( gone through root ) { return negative map-reply to ITR } else { goto root } } else { cache & follow the referral }

case NODE_REFERRAL: if ( referral equal to last used ) { if ( gone through root ) { return negative map-reply to ITR } else { goto root } } else { cache & follow the referral



}

case MS_ACKNOWLEDGEMENT: if ( OTK stripped ) { if ( incomplete ) { resend request with OTK } else { cache & resend request with OTK } }

case MS_NOT_REGISTERED: if { all map-server delegations not tried } { follow delegations not tried if ( !incomplete ) { cache } } else { send negative map-reply to ITR if { !incomplete } { cache } }

case DEFAULT: drop

} }




+------------+ | Is Request | No | Pending? |----> Silently drop +------------+ | Yes V +------------------------------+ Yes | Pfx less specific than last? |----> Silently drop +------------------------------+ |No V +---------------------------------------------------+ | What is Map-Referral Type? |--UNKNOWN-+ +---------------------------------------------------+ | | | | | | | V | | | | | DEL_HOLE DROP | | | | MS_ACK | | | | | | V | | MS_REF NODE_REF | Cache & return | | | | V negative map-reply | | | | +---------+ | NOT_AUTH | | | Was OTK | Yes | | | | |Stripped?|----> Done | | V V +---------+ | | +------------+ | No | | Yes | Pfx equal | VMS_NOT_REGISTERED | +---| to last | +------------+ | | | | used? | | Incomplete | Yes | | | +------------+ | bit set? |---> Resend DDT | V V |No +------------+ request | +------------+ | |No with OTK | | Gone | V | | | Through | Cache & follow V | | Root? | the referral Cache & resend DDT | +------------+ request with OTK | |No |Yes | | | | V V | Goto root Send negative map-reply V +-----------+ Yes +-----------+ Yes | Other MS |-----Follow other MS-------->|Incomplete |----> Dont cache | not tried?| |bit set? | | |----Send negative map-reply->| |----> Cache +-----------+ No +-----------+ No



6.3. DDT Node processing of DDT Map-Request message


if ( I am not authoritative ) { send map-referral NOT_AUTHORITATIVE with incomplete bit set and ttl 0 } else if ( delegation exists ) { if ( delegated map-servers ) { send map-referral MS_REFERRAL with ttl ’Default_DdtNode_Ttl’ } else { send map-referral NODE_REFERRAL with ttl ’Default_DdtNode_Ttl’ } } else { if ( eid in site) { if ( site registered ) { forward map-request to etr if ( map-server peers configured ) { send map-referral MS_ACKNOWLEDGEMENT with ttl ’Default_Registered_Ttl’ } else { send map-referral MS_ACKNOWLEDGEMENT with ttl ’Default_Registered_Ttl’ and incomplete bit set } } else { if ( map-server peers configured ) { send map-referral MS_NOT_REGISTERED with ttl ’Default_Configured_Not_Registered_Ttl’ } else { send map-referral MS_NOT_REGISTERED with ttl ’Default_Configured_Not_Registered_Ttl’ and incomplete bit set } } } else { send map-referral DELEGATION_HOLE with ttl ’Default_Negative_Referral_Ttl’ } }



DDT nodes are configured for this "root" at IP addresses 192.0.2.1 and 192.0.2.2. DDT Map Resolvers are configured with default referral cache entries to these addresses.

The root DDT nodes delegate 10.0.0/8 to two DDT nodes with IP addresses 192.0.2.11 and 192.0.2.12.

The DDT nodes for 10.0.0.0/8 delegate 10.0.0.0/12 to a DDT Map Server with RLOC 192.0.2.101

The DDT Map Server for 10.0.0.0/12 is configured to allow ETRs to register the sub-prefixes 10.1.0.0/16 and 10.2.0.0/16

The DDT nodes for 10.0.0.0/8 also delegate 10.16.0.0/12 to a DDT node with RLOC 192.0.2.201

The DDT node for 10.16.0.0/12 is further configured to delegate 10.16.0.0/16 to a DDT Map Server with RLOC 192.0.2.211 and 10.17.0.0/16 to a DDT Map Server with RLOC 192.0.2.221



7.1. Lookup of 10.1.1.1/32 by ITR1

The first example shows a DDT Map Resolver following a delegation from the root to a DDT node followed by another delegation to a DDT Map Server.

ITR1 sends an Encapsulated Map-Request for 10.1.1.1 to one of its configured (DDT) Map Resolvers. The DDT Map Resolver proceeds as follows:

1. Send DDT Map-Request (for 10.1.1.1) to one of the root DDT nodes, 192.0.2.1 or 192.0.2.2

2. Receive (and save in referral cache) Map-Referral for EID-prefix 10.0.0.0/8, action code NODE-REFERRAL, RLOC set (192.0.2.11, 192.0.2.12)

3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12

4. Receive (and save in referral cache) Map-Referral for EID-prefix 10.0.0.0/12, action code MS-REFERRAL, RLOC set (192.0.2.101)



5. Send DDT Map-Request to 192.0.2.101; if the ITR-originated Encapsulated Map-Request had a LISP-SEC signature, it is included

6. DDT Map Server at 192.0.2.101 decapsulates the DDT Map-Request and forwards to a registered site1 ETR for 10.1.0.0/16

7. DDT Map Server at 192.0.2.101 sends a Map-Referral message for EID-prefix 10.1.0.0/16, action code MS-ACK to the DDT Map Resolver

8. DDT Map Resolver receives Map-Referral message and dequeues the pending request for 10.1.1.1

9. site1 ETR for 10.1.0.0/16 receives Map-Request forwarded by DDT Map Server and sends Map-Reply to ITR1

7.2. Lookup of 10.17.8.1/32 by ITR2

The next example shows a three-level delegation: root to first DDT node, first DDT node to second DDT node, second DDT node to DDT Map Server.

ITR2 sends an Encapsulated Map-Request for 10.17.8.1 to one of its configured (DDT) Map Resolvers, which are different from those for ITR1. The DDT Map Resolver proceeds as follows:

1. Send DDT Map-Request (for 10.17.8.1) to one of the root DDT nodes, 192.0.2.1 or 192.0.2.2

2. Receive (and save in referral cache) Map-Referral for EID-prefix 10.0.0.0/8, action code NODE-REFERRAL, RLOC set (192.0.2.11, 192.0.2.12)

3. Send DDT Map-Request to 192.0.2.11 or 192.0.2.12

4. Receive (and save in referral cache) Map-Referral for EID-prefix 10.16.0.0/12, action code NODE-REFERRAL, RLOC set (192.0.2.201)

5. Send DDT Map-Request to 192.0.2.201






9. DDT Map Server at 192.0.2.221 sends a Map-Referral message for EID-prefix 10.17.8.0/24, action code MS-ACK, to the DDT Map Resolver

10. DDT Map Resolver receives Map-Referral(MS-ACK) message and dequeues the pending request for 10.17.8.1

11. site5 ETR for 10.17.8.0/24 receives Map-Request forwarded by DDT Map Server and sends Map-Reply to ITR2

7.3. Lookup of 10.2.2.2/32 by ITR1

This example shows how a DDT Map Resolver uses a saved referral cache entry to skip the referral process and go directly to a DDT Map Server for a prefix that is similar to one previously requested.

In this case, ITR1 uses the same Map Resolver used in example Section 7.1. It sends an Encapsulated Map-Request for 10.2.2.2 to that (DDT) Map Resolver. The DDT Map-Resolver finds an MS-REFERRAL cache entry for 10.0.0.0/12 with RLOC set (192.0.2.101) and proceeds as follows:

1. Send DDT Map-Request (for 10.2.2.2) to 192.0.2.101; if the ITR- originated Encapsulated Map-Request had a LISP-SEC signature, it is included



4. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the pending request for 10.2.2.2

5. site2 ETR for 10.2.0.0/16 receives Map-Request and sends Map- Reply to ITR1

7.4. Lookup of 10.16.2.1/32 by ITR2

This example shows how a DDT Map Resolver uses a saved referral cache entry to start the referral process at a non-root, intermediate DDT node for a prefix that is similar to one previously requested.



In this case, ITR2 asks the same Map Resolver used in example Section 7.2. It sends an Encapsulated Map-Request for 10.16.2.1 to that (DDT) Map Resolver, which finds a NODE-REFERRAL cache entry for 10.16.0.0/12 with RLOC set (192.0.2.201). It proceeds as follows:

1. Send DDT Map-Request (for 10.16.2.1) to 192.0.2.201





6. DDT Map Resolver receives Map-Referral(MS-ACK) and dequeues the pending request for 10.16.2.1

7. site4 ETR for 10.16.2.0/24 receives Map-Request and sends Map- Reply to ITR2

7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2

This example uses the cached MS-REFERRAL for 10.16.0.0/16 learned above to start the lookup process at the DDT Map-Server at 192.0.2.211. The DDT Map Resolver proceeds as follows:

1. Send DDT Map-Request (for 10.16.0.1) to 192.0.2.211; if the ITR- originated Encapsulated Map-Request had a LISP-SEC signature, it is included

2. DDT Map Server at 192.0.2.211, which is authoritative for 10.16.0.0/16, does not have a matching delegation for 10.16.0.1. It respondes with a Map-Referral message for 10.16.0.0/24, action code DELEGATION-HOLE to the DDT Map Resolver. The prefix 10.16.0.0/24 is used because it is the least-specific prefix that does match the requested EID but does not match one of configured delegations (10.16.1.0/24 and 10.16.2.0/24).

3. DDT Map Resolver receives the delegation, adds a negative referral cache entry for 10.16.0.0/24, dequeues the pending request for 10.16.0.1, and returns a negative Map-Reply to ITR2.



8. Securing the database and message exchanges

This section specifies the DDT security architecture that provides data origin authentication, data integrity protection, and XEID- prefix delegation. Global XEID-prefix authorization is out of the scope of this document.

Each DDT node is configured with one or more public/private key pair(s) that are used to digitally sign referral records for XEID- prefix(es) that the DDT node is authoritative for. In other words, each public/private key pair is associated with the combination of a DDT node and the XEID-prefix that it is authoritative for. Every DDT node is also configured with the public keys of its children DDT nodes. By including public keys of target child DDT nodes in the Map-Referral records, and signing each record with the DDT node’s private key, a DDT node can securely delegate sub-prefixes of its authoritative XEID-prefixes to its children DDT nodes.

Map Resolvers are configured with one or more trusted public keys referred to as trust anchors. Trust anchors are used to authenticate the DDT security infrastructure. Map Resolvers can discover a DDT node’s public key either by having it configured as a trust anchor, or by obtaining it from the node’s parent as part of a signed Map- Referral. When a public key is obtained from a node’s parent, it is considered trusted if it is signed by a trust anchor, or if it is signed by a key that was previously trusted. Typically, in a Map Resolver, the root DDT node public keys should be configured as trust anchors. Once a Map Resolver authenticates a public key it locally caches the key along with the associated DDT node RLOC and XEID- prefix for future use.

8.1. XEID-prefix Delegation

In order to delegate XEID sub-prefixes to its children, a parent DDT node signs its Map-Referrals. Every signed Map-Referral also includes the public keys associated with each child DDT node. Such a signature indicates that the parent node is delegating the specified XEID -prefix to a given child DDT node. The signature is also authenticating the public keys associated with the children nodes, and authorizing them to be used by the children DDT nodes to provide origin authentication and integrity protection for further delegations and mapping information of the XEID-prefix allocated to the DDT node.

As a result, for a given XEID-prefix, a Map Resolver can form an authentication chain from a configured trust anchor (typically the root DDT node) to the leaf nodes (Map Servers). Map Resolvers leverage this authentication chain to verify the Map-Referral



signatures while walking the DDT tree until they reach a Map Server authoritative for the given XEID-prefix.

8.2. DDT node operation

Upon receiving a Map-Request, the DDT node responds with a Map- Referral as specified in Section 5. For every record present in the Map-Referral, the DDT node also includes the public keys associated with the record’s XEID-prefix and the RLOCs of the children DDT nodes. Each record contained in the Map-Referral is signed using the DDT node’s private key.

8.2.1. DDT public key revocation

The node that owns a public key can also revoke that public key. For instance if a parent node advertises a public key for one of its child DDT nodes, the child DDT node can at a later time revoke that key. Since DDT nodes do not keep track of the Map Resolvers that query them, revocation is done in a pull model, where the Map Resolver is informed of the revocation of a key only when it queries the node that owns that key. If the parent DDT is configured to advertise this key, the parent node must also be signaled to remove the key from the records it advertises for the child DDT node; this is necessary to avoid further distribution of the revoked key.

To securely revoke a key, the DDT node creates a new Record for the associated XEID-prefix and locator, including the revoked key with the R bit set. The DDT node must also include a signature in the Record that covers this record; this is computed using the private key corresponding to the key being revoked. Such a record is termed a "revocation record". By including this record in its Map- Referrals, the DDT node informs querying Map Resolvers about the revoked key. A digital signature computed with a revoked key can only be used to authenticate the revocation, and should not be used to validate any data. To prevent a compromised key from revoking other valid keys, a given key can only be used to sign a revocation for that specific key; it cannot be used to revoke other keys. This prevents the use of a compromised key to revoke other valid keys as described in [RFC5011]. A revocation record must be advertised for a period of time equal to or greater than the TTL value of the Record that initially advertisied the key, starting from the time that the advertisement of the key was stopped by removal from the parent DDT node.

8.3. Map Server operation

Similar to a DDT node, a Map Server is configured with one (or more) public/private key pairs that it must use to sign Map-Referrals.



However unlike DDT nodes, Map Servers do not delegate prefixes and as a result they do not need to include keys in the Map-Referrals they generate.

8.4. Map Resolver operation

Upon receiving a Map-Referral, the Map Resolver must first verify the signature(s) by using a trust anchor, or a previously authenticated public key, associated with the DDT node sending the Map-Referral. If multiple authenticated keys are associated with the DDT node sending this Map-Referral, the Key Tag field of the signature can be used to select the right public key for verifying the signature. If the key tag matches more than one key associated with that DDT node, the Map Resolver must try verifying the signature with all matching keys. For every matching key that is found the Map Resolver must also verify that the key is authoritative for the XEID-prefix in the Map-Referral record. If such a key is found, the Map Resolver must use it to verify the associated signature in the record. If no matching key is found, or if none of the matching keys is authoritative for the XEID-prefix in the Map-Referral record, or if such a key is found but the signature is not valid the Map-Referral record is considered corrupted and must be discarded. This may be due to expired keys. The Map Resolver can try other siblings of this node if there is an alternative node authoritative for the same prefix. If not, the Map Resolver can query the DDT node’s parent to retrieve a valid key. It is good practice to use a counter or timer to avoid repeating this process if the resolver cannot verify the signature after several trials.

Once the signature is verified, the Map Resolver has verified the XEID-prefix delegation in the Map-Referral, and authenticated the public keys of the children DDT nodes. The Map Resolver must add these keys to the authenticated keys associated with each child DDT node and XEID-prefix. These keys are considered valid for the duration specified in the record’s TTL field.



9. Open Issues and Considerations

There are a number of issues with the organization of the mapping database that need further investigation. Among these are:

o Unlike in [LISP-ALT], DDT does not currently define a mechanism for propagating ETR-to-Map Server registration state. This requires DDT Map Servers to suppress returning negative Map-Reply messages for defined but unregistered XEID-prefixes to avoid loss of connectivity during partial ETR registration failures. Suppressing these messages may cause a delay for an ITR obtaining a mapping entry when such a failure is occurring.

o Defining an interface to implement interconnection and/or interoperability with other mapping databases, such as LISP+ALT.

o Additional key structures for use with LISP-DDT, such as to support additional EID formats as defined in [LCAF].

o Authentication of delegations between DDT nodes.

o Possibility of a new, more general format for the Map-Referral messages to facilitate the use of LISP-DDT with additional DBID/ IID/EID combinations. Currently-defined packet formats should be considered to be preliminary and provisional until this issue has received greater attention.

o Management of the DDT Map Resolver referral cache, in particular, detecting and removing outdated entries.

The authors expect that experimentation on the LISP pilot network will help answer open questions surrounding these and other issues.




This document makes no request of the IANA.




Section 8 describes a DDT security architecture that provides data origin authentication, data integrity protection, and XEID-prefix delegation within the DDT Infrastructure.

Global XEID-prefix authorization is beyond the scope of this document, but the SIDR working group [RFC6480] is developing an infrastructure to support improved security of Internet routing. Further work is required to determine if SIDR’s public key infrastructure (PKI) and the distributed repository system it uses for storing and disseminating PKI data objects may also be used by DDT devices to verifiably assert that they are the legitimate holders of a set of XEID prefixes.

DDT security and [LISP-SEC] complement each other in securing the DDT infrastructure, Map-Referral messages and the Map-Request/Map-Reply protocol. In addition LISP-SEC can use the DDT public key infrastructure to secure the transport of LISP-SEC key material (the One-Time Key) from a Map-Resolver to the corresponding Map-Server. For this reason, when LISP-SEC is deployed in conjunction with a LISP-DDT mapping database and the path between Map-Resolver and Map- Server needs to be protected, DDT security should be enabled as well.



12. References


[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-ietf-lisp-lcaf-00.txt (work in progress), August 2012.

[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-23.txt (work in progress), May 2012.

[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface", draft-ietf-lisp-ms-16.txt (work in progress), March 2012.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.


[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006.

[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust Anchors", RFC 5011, September 2007.


[LISP-ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-10.txt (work in progress), December 2011.

[LISP-SEC] Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. Bonaventure, "LISP-Security", draft-ietf-lisp-sec-03.txt (work in progress), September 2012.

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

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.



Appendix A. Acknowledgments

The authors with to express their thanks to Damien Saucez, Lorand Jakab, and Olivier Bonaventure for work on LISP-TREE and LISP iterable mappings that inspired the hierarchical database structure and lookup iteration approach described in this document. Thanks also go to Dino Farinacci and Isidor Kouvelas for their implementation work; to Selina Heimlich and Srin Subramanian for testing; to Fabio Maino for work on security processing; and to Job Snijders, Glen Wiley, Neel Goyal, and Mike Gibbs for work on operational considerations and initial deployment of a prototype database infrastructure. Special thanks go to Jesper Skriver, Andrew Partan, and Noel Chiappa; all of whom have participated in (and put up with) seemingly endless hours of discussion of mapping database ideas, concepts, and issues.



Appendix B. Map-Referral Message Format

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=6 | Reserved | Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Referral Count| EID mask-len | ACT |A|I| Reserved | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c |SigCnt | Map Version Number | EID-AFI | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | EID-prefix ... | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |R| Loc/LCAF-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator ... | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ACT: The "action" field of the mapping record in a Map-Referral message encodes 6 action types. The values for the action types are:

NODE-REFERRAL (0): Sent by a DDT node with a child delegation which is authoritative for the EID.

MS-REFERRAL (1): Sent by a DDT node that has information about Map Server(s) for the EID but it is not one of the Map Servers listed, i.e. the DDT-Node sending the referral is not a Map Server.

MS-ACK (2): Sent by a DDT Map Server that has one or more ETR registered for the EID.

MS-NOT-REGISTERED (3): Sent by a DDT Map Server that is configured for the EID-prefix but for which no ETRs are registered.

DELEGATION-HOLE (4): Sent by an intermediate DDT node with authoritative configuration covering the requested EID but without any child delegation for the EID. Also sent by a DDT Map Server with authoritative configuration covering the requested EID but for which no specific site ETR is configured.



NOT-AUTHORITATIVE (5): Sent by a DDT node that does not have authoritative configuration for the requested EID. The EID-prefix returned MUST be the original requested EID and the TTL MUST be set to 0. However, if such a DDT node has a child delegation covering the requested EID, it may choose to return NODE-REFERRAL or MS-REFERRAL as appropriate. A DDT Map Server with site information may choose to return of type MS-ACK or MS-NOT- REGISTERED as appropriate.

Incomplete: The "I" bit indicates that a DDT node’s referral-set of locators is incomplete and the receiver of this message should not cache the referral. A DDT sets the "incomplete" flag, the TTL, and the Action Type field as follows:

------------------------------------------------------------------- Type (Action field) Incomplete Referral-set TTL values ------------------------------------------------------------------- 0 NODE-REFERRAL NO YES 1440

1 MS-REFERRAL NO YES 1440

2 MS-ACK * * 1440

3 MS-NOT-REGISTERED * * 1

4 DELEGATION-HOLE NO NO 15

5 NOT-AUTHORITATIVE YES NO 0 -------------------------------------------------------------------

*: The "Incomplete" flag setting on Map Server originated referral of MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map Server has the full peer Map Server configuration for the same prefix and has encoded the information in the mapping record. Incomplete bit is not set when the Map Server has encoded the information, which means the referral-set includes all the RLOCs of all Map Servers that serve the prefix. It is set when the Map Server has not encoded the Map Server set information.

SigCnt: Indicates the number of signatures (sig section) present in the Record. If SigCnt is larger than 0, the signature information captured in a sig section as described in Appendix B.1 will be appended to the end of the record. The number of sig sections at the end of the Record must match the SigCnt.

Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the record. If this is a LCAF AFI, the contents of the LCAF depend on



the Type field of the LCAF. Security material are stored in LCAF Type 11. DDT nodes and Map Servers can use this LCAF Type to include public keys associated with their Child DDT nodes for a XEID-prefix referral record. LCAF types and formats are defined in [LCAF].

All the field descriptions are equivalent to those in the Map-Reply message, as defined in [LISP]. Note, though, that the set of RLOCs correspond to the DDT node to be queried as a result of the referral not the RLOCs for an actual EID-to-RLOC mapping.

B.1. SIG section

If SigCnt field in the Map-Referral is not 0, the signature information is included at the end of captured in a sig section as described below. SigCnt counts the number of sig sections that appear at the end of the Record.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /| Original Record TTL | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Signature Expiration | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s | Signature Inception | i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ g | Key Tag | Sig Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | Sig-Algorithm | Reserved | Reserved | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ˜ Signature ˜ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Original Record TTL: The original Record TTL for this record that is covered by the signature. Record TTL is in minutes.

Key Tag: An identifier to specify which key is used for this signature if more than one valid key exists for the signing DDT node.

Sig Length: The length of the Signature field.

Sig-Algorithm: The identifier of the cryptographic algorithm used for the signature. Default value is RSA-SHA1.

Reserved: This field must be set to 0 on transmit and must be ignored on receipt.

Signature Expiration and Inception: Specify the validity period for the signature. Each specify a date and time in the form of a 32-bit



unsigned number of seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network byte order.

Signature: Contains the cryptographic signature that covers the entire record. The Record TTL and the sig fields are set to zero for the purpose of computing the Signature



Appendix C. Encapsulated Control Message Format

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | OH | (uses RLOC addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = 4342 | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LH |Type=8 |S|D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | IPv4 or IPv6 Header | IH | (uses RLOC or EID addresses) | \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Source Port = xxxx | Dest Port = yyyy | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LCM | LISP Control Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"D" is the "DDT-originated" flag and is set by a DDT client to indicate that the receiver can and should return Map-Referral messages as appropriate.




Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA


Darrel Lewis cisco Systems Tasman Drive San Jose, CA 95134 USA


Vina Ermagan cisco Systems Tasman Drive San Jose, CA 95134 USA


Amit Jain cisco Systems Tasman Drive San Jose, CA 95134 USA



Network Working Group L. JakabInternet-Draft A. Cabellos-AparicioIntended status: Informational F. CorasExpires: September 13, 2012 J. Domingo-Pascual Technical University of Catalonia D. Lewis Cisco Systems March 12, 2012

LISP Network Element Deployment Considerations draft-ietf-lisp-deployment-03.txt

Abstract

This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP).

Status of this Memo





Copyright Notice


This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (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

Jakab, et al. Expires September 13, 2012 [Page 1]

Internet-Draft LISP Deployment March 2012

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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Inter-Service Provider Traffic Engineering . . . . . . . . 8 2.5. Tunnel Routers Behind NAT . . . . . . . . . . . . . . . . 10 2.5.1. ITR . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11 3. Map-Resolvers and Map-Servers . . . . . . . . . . . . . . . . 11 3.1. Map-Servers . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Map-Resolvers . . . . . . . . . . . . . . . . . . . . . . 12 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16 5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19 6. Step-by-Step BGP to LISP Migration Procedure . . . . . . . . . 20 6.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 20 6.2. Customer Activating LISP Service . . . . . . . . . . . . . 21 6.3. Cut-Over Provider Preparation and Changes . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24



1. Introduction

The Locator/Identifier Separation Protocol (LISP) addresses the scaling issues of the global Internet routing system by separating the current addressing scheme into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The main protocol specification [I-D.ietf-lisp] describes how the separation is achieved, which new network elements are introduced, and details the packet formats for the data and control planes.

While the boundary between the core and edge is not strictly defined, one widely accepted definition places it at the border routers of stub autonomous systems, which may carry a partial or complete default-free zone (DFZ) routing table. The initial design of LISP took this location as a baseline for protocol development. However, the applications of LISP go beyond of just decreasing the size of the DFZ routing table, and include improved multihoming and ingress traffic engineering (TE) support for edge networks, and even individual hosts. Throughout the draft we will use the term LISP site to refer to these networks/hosts behind a LISP Tunnel Router. We formally define it as:

LISP site: A single host or a set of network elements in an edge network under the administrative control of a single organization, delimited from other networks by LISP Tunnel Router(s).

Since LISP is a protocol which can be used for different purposes, it is important to identify possible deployment scenarios and the additional requirements they may impose on the protocol specification and other protocols. The main specification [I-D.ietf-lisp] mentions positioning of tunnel routers, but without an in-depth discussion. This document fills that gap, by exploring the most common cases. While the theoretical combinations of device placements are quite numerous, the more practical scenarios are given preference in the following.

Additionally, this documents is intended as a guide for the operational community for LISP deployments in their networks. It is expected to evolve as LISP deployment progresses, and the described scenarios are better understood or new scenarios are discovered.

Each subsection considers an element type, discussing the impact of deployment scenarios on the protocol specification. For definition of terms, please refer to the appropriate documents (as cited in the respective sections).

Comments and discussions about this memo should be directed to the LISP working group mailing list: [email protected].



2. Tunnel Routers

LISP is a map-and-encap protocol, with the main goal of improving global routing scalability. To achieve its goal, it introduces several new network elements, each performing specific functions necessary to separate the edge from the core. The device that is the gateway between the edge and the core is called Tunnel Router (xTR), performing one or both of two separate functions:

1. Encapsulating packets originating from an end host to be transported over intermediary (transit) networks towards the other end-point of the communication

2. Decapsulating packets entering from intermediary (transit) networks, originated at a remote end host.

The first function is performed by an Ingress Tunnel Router (ITR), the second by an Egress Tunnel Router (ETR).

Section 8 of the main LISP specification [I-D.ietf-lisp] has a short discussion of where Tunnel Routers can be deployed and some of the associated advantages and disadvantages. This section adds more detail to the scenarios presented there, and provides additional scenarios as well.

2.1. Customer Edge

LISP was designed with deployment at the core-edge boundary in mind, which can be approximated as the set of DFZ routers belonging to non- transit ASes. For the purposes of this document, we will consider this boundary to be consisting of the routers connecting LISP sites to their upstreams. As such, this is the most common expected scenario for xTRs, and this document considers it the reference location, comparing the other scenarios to this one.

ISP1 ISP2 | | | | +----+ +----+ +--|xTR1|--|xTR2|--+ | +----+ +----+ | | | | LISP site | +------------------+

Figure 1: xTRs at the customer edge

From the LISP site perspective the main advantage of this type of



deployment (compared to the one described in the next section) is having direct control over its ingress traffic engineering. This makes it is easy to set up and maintain active/active, active/backup, or more complex TE policies, without involving third parties.

Being under the same administrative control, reachability information of all ETRs is easier to synchronize, because the necessary control traffic can be allowed between the locators of the ETRs. A correct synchronous global view of the reachability status is thus available, and the Loc-Status-Bits can be set correctly in the LISP data header of outgoing packets.

By placing the tunnel router at the edge of the site, existing internal network configuration does not need to be modified. Firewall rules, router configurations and address assignments inside the LISP site remain unchanged. This helps with incremental deployment and allows a quick upgrade path to LISP. For larger sites with many external connections, distributed in geographically diverse PoPs, and complex internal topology, it may however make more sense to both encapsulate and decapsulate as soon as possible, to benefit from the information in the IGP to choose the best path (see Section 2.3 for a discussion of this scenario).

Another thing to consider when placing tunnel routers are MTU issues. Since encapsulating packets increases overhead, the MTU of the end- to-end path may decrease, when encapsulated packets need to travel over segments having close to minimum MTU. Some transit networks are known to provide larger MTU than the typical value of 1500 bytes of popular access technologies used at end hosts (e.g., IEEE 802.3 and 802.11). However, placing the LISP router connecting to such a network at the customer edge could possibly bring up MTU issues, depending on the link type to the provider as opposed to the following scenario.

2.2. Provider Edge

The other location at the core-edge boundary for deploying LISP routers is at the Internet service provider edge. The main incentive for this case is that the customer does not have to upgrade the CE router(s), or change the configuration of any equipment. Encapsulation/decapsulation happens in the provider’s network, which may be able to serve several customers with a single device. For large ISPs with many residential/business customers asking for LISP this can lead to important savings, since there is no need to upgrade the software (or hardware, if it’s the case) at each client’s location. Instead, they can upgrade the software (or hardware) on a few PE routers serving the customers. This scenario is depicted in Figure 2.



+----------+ +------------------+ | ISP1 | | ISP2 | | | | | | +----+ | | +----+ +----+ | +--|xTR1|--+ +--|xTR2|--|xTR3|--+ +----+ +----+ +----+ | | | | | | +--<[LISP site]>---+-------+

Figure 2: xTR at the PE

While this approach can make transition easy for customers and may be cheaper for providers, the LISP site looses one of the main benefits of LISP: ingress traffic engineering. Since the provider controls the ETRs, additional complexity would be needed to allow customers to modify their mapping entries.

The problem is aggravated when the LISP site is multihomed. Consider the scenario in Figure 2: whenever a change to TE policies is required, the customer contacts both ISP1 and ISP2 to make the necessary changes on the routers (if they provide this possibility). It is however unlikely, that both ISPs will apply changes simultaneously, which may lead to inconsistent state for the mappings of the LISP site. Since the different upstream ISPs are usually competing business entities, the ETRs may even be configured to compete, either to attract all the traffic or to get no traffic. The former will happen if the customer pays per volume, the latter if the connectivity has a fixed price. A solution could be to have the mappings in the Map-Server(s), and have their operator give control over the entries to customer, much like in today’s DNS.

Additionally, since xTR1, xTR2, and xTR3 are in different administrative domains, locator reachability information is unlikely to be exchanged among them, making it difficult to set Loc-Status- Bits correctly on encapsulated packets.

Compared to the customer edge scenario, deploying LISP at the provider edge might have the advantage of diminishing potential MTU issues, because the tunnel router is closer to the core, where links typically have higher MTUs than edge network links.

2.3. Split ITR/ETR

In a simple LISP deployment, xTRs are located at the border of the LISP site (see Section 2.1). In this scenario packets are routed inside the domain according to the EID. However, more complex networks may want to route packets according to the destination RLOC.



This would enable them to choose the best egress point.

The LISP specification separates the ITR and ETR functionality and considers that both entities can be deployed in separated network equipment. ITRs can be deployed closer to the host (i.e., access routers). This way packets are encapsulated as soon as possible, and packets exit the network through the best egress point in terms of BGP policy. In turn, ETRs can be deployed at the border routers of the network, and packets are decapsulated as soon as possible. Again, once decapsulated packets are routed according to the EID, and can follow the best path according to internal routing policy.

In the following figure we can see an example. The Source (S) transmits packets using its EID and in this particular case packets are encapsulated at ITR_1. The encapsulated packets are routed inside the domain according to the destination RLOC, and can egress the network through the best point (i.e., closer to the RLOC’s AS). On the other hand, inbound packets are received by ETR_1 which decapsulates them. Then packets are routed towards S according to the EID, again following the best path.

+---------------------------------------+ | | | +-------+ +-------+ +-------+ | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | | +-------+ | +-------+ +-------+ | +-+ | | | | |S| | IGP | | | +-+ | | | | +-------+ | +-------+ +-------+ | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | | +-------+ +-------+ +-------+ | | +---------------------------------------+

Figure 3: Split ITR/ETR Scenario

This scenario has a set of implications:

o The site must carry at least partial BGP routes in order to choose the best egress point, increasing the complexity of the network. However, this is usually already the case for LISP sites that would benefit from this scenario.

o If the site is multihomed to different ISPs and any of the upstream ISPs is doing uRPF filtering, this scenario may become impractical. ITRs need to determine the exit ETR, for setting the correct source RLOC in the encapsulation header. This adds



complexity and reliability concerns.

o In LISP, ITRs set the reachability bits when encapsulating data packets. Hence, ITRs need a mechanism to be aware of the liveness of ETRs.

o ITRs encapsulate packets and in order to achieve efficient communications, the MTU of the site must be large enough to accommodate this extra header.

o In this scenario, each ITR is serving fewer hosts than in the case when it is deployed at the border of the network. It has been shown that cache hit ratio grows logarithmically with the amount of users [cache]. Taking this into account, when ITRs are deployed closer to the host the effectiveness of the mapping cache may be lower (i.e., the miss ratio is higher). Another consequence of this is that the site will transmit a higher amount of Map-Requests, increasing the load on the distributed mapping database.

2.4. Inter-Service Provider Traffic Engineering

With LISP, two LISP sites can route packets among them and control their ingress TE policies. Typically, LISP is seen as applicable to stub networks, however the LISP protocol can also be applied to transit networks recursively.

Consider the scenario depicted in Figure 4. Packets originating from the LISP site Stub1, client of ISP_A, with destination Stub4, client of ISP_B, are LISP encapsulated at their entry point into the ISP_A’s network. The external IP header now has as the source RLOC an IP from ISP_A’s address space and destination RLOC from ISP_B’s address space. One or more ASes separate ISP_A from ISP_B. With a single level of LISP encapsulation, Stub4 has control over its ingress traffic. However, ISP_B only has the current tools (such as BGP prefix deaggregation) to control on which of his own upstream or peering links should packets enter. This is either not feasible (if fine-grained per-customer control is required, the very specific prefixes may not be propagated) or increases DFZ table size.

_.--. Stub1 ... +-------+ ,-’’ ‘--. +-------+ ... Stub3 \ | R_A1|----,’ ‘. ---|R_B1 | / --| R_A2|---( Transit ) | |-- Stub2 .../ | R_A3|-----. ,’ ---|R_B2 | \... Stub4 +-------+ ‘--. _.-’ +-------+ ... ISP_A ‘--’’ ISP_B ...



Figure 4: Inter-Service provider TE scenario

A solution for this is to apply LISP recursively. ISP_A and ISP_B may reach a bilateral agreement to deploy their own private mapping system. ISP_A then encapsulates packets destined for the prefixes of ISP_B, which are listed in the shared mapping system. Note that in this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3 as source and R_B1 or R_B2 as destination in the example above). ISP_B’s ETR removes the outer, second layer of LISP encapsulation from the incoming packet, and routes it towards the original RLOC, the ETR of Stub4, which does the final decapsulation.

If ISP_A and ISP_B agree to share a private distributed mapping database, both can control their ingress TE without the need of disaggregating prefixes. In this scenario the private database contains RLOC-to-RLOC bindings. The convergence time on the TE policies updates is expected to be fast, since ISPs only have to update/query a mapping to/from the database.

This deployment scenario includes two important recommendations. First, it is intended to be deployed only between two ISPs (ISP_A and ISP_B in Figure 4). If more than two ISPs use this approach, then the xTRs deployed at the participating ISPs must either query multiple mapping systems, or the ISPs must agree on a common shared mapping system. Second, the scenario is only recommended for ISPs providing connectivity to LISP sites, such that source RLOCs of packets to be reencapsulated belong to said ISP. Otherwise the participating ISPs must register prefixes they do not own in the above mentioned private mapping system. Failure to follow these recommendations may lead to operational and security issues when deploying this scenario.

Besides these recommendations, the main disadvantages of this deployment case are:

o Extra LISP header is needed. This increases the packet size and, for efficient communications, it requires that the MTU between both ISPs can accommodate double-encapsulated packets.

o The ISP ITR must encapsulate packets and therefore must know the RLOC-to-RLOC binding. These bindings are stored in a mapping database and may be cached in the ITR’s mapping cache. Cache misses lead to an extra lookup latency, unless NERD [I-D.lear-lisp-nerd] is used for the lookups.

o The operational overhead of maintaining the shared mapping database.



o If an IPv6 address block is reserved for EID use, as specified in [I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first level) can avoid LISP processing altogether for non-LISP destinations. The ISP tunnel routers however will not be able to take advantage of this optimization, all RLOC-to-RLOC mappings need a lookup in the private database (or map-cache, once results are cached).

2.5. Tunnel Routers Behind NAT

NAT in this section refers to IPv4 network address and port translation.

2.5.1. ITR

Packets encapsulated by an ITR are just UDP packets from a NAT device’s point of view, and they are handled like any UDP packet, there are no additional requirements for LISP data packets.

Map-Requests sent by an ITR, which create the state in the NAT table have a different 5-tuple in the IP header than the Map-Reply generated by the authoritative ETR. Since the source address of this packet is different from the destination address of the request packet, no state will be matched in the NAT table and the packet will be dropped. To avoid this, the NAT device has to do the following:

o Send all UDP packets with source port 4342, regardless of the destination port, to the RLOC of the ITR. The most simple way to achieve this is configuring 1:1 NAT mode from the external RLOC of the NAT device to the ITR’s RLOC (Called "DMZ" mode in consumer broadband routers).

o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in the payload.

This setup supports a single ITR behind the NAT device.

2.5.2. ETR

An ETR placed behind NAT is reachable from the outside by the Internet-facing locator of the NAT device. It needs to know this locator (and configure a loopback interface with it), so that it can use it in Map-Reply and Map-Register messages. Thus support for dynamic locators for the mapping database is needed in LISP equipment.

Again, only one ETR behind the NAT device is supported.



An implication of the issues described above is that LISP sites with xTRs can not be behind carrier based NATs, since two different sites would collide on the port forwarding.

2.6. Summary and Feature Matrix

Feature CE PE Split Rec. -------------------------------------------------------- Control of ingress TE x - x x No modifications to existing int. network infrastructure x x - - Loc-Status-Bits sync x - x x MTU/PMTUD issues minimized - x - x

3. Map-Resolvers and Map-Servers

3.1. Map-Servers

The Map-Server learns EID-to-RLOC mapping entries from an authoritative source and publishes them in the distributed mapping database. These entries are learned through authenticated Map- Register messages sent by authoritative ETRs. Also, upon reception of a Map-Request, the Map-Server verifies that the destination EID matches an EID-prefix for which it is authoritative for, and then re- encapsulates and forwards it to a matching ETR. Map-Server functionality is described in detail in [I-D.ietf-lisp-ms].

The Map-Server is provided by a Mapping Service Provider (MSP). A MSP can be any of the following:

o EID registrar. Since the IPv4 address space is nearing exhaustion, IPv4 EIDs will come from already allocated Provider Independent (PI) space. The registrars in this case remain the current five Regional Internet Registries (RIRs). In the case of IPv6, the possibility of reserving a /16 block as EID space is currently under consideration [I-D.ietf-lisp-eid-block]. If granted by IANA, the community will have to determine the body responsible for allocations from this block, and the associated policies. For already allocated IPv6 prefixes the principles from IPv4 should be applied.

o Third parties. Participating in the LISP mapping system is similar to participating in global routing or DNS: as long as there is at least another already participating entity willing to forward the newcomer’s traffic, there is no barrier to entry. Still, just like routing and DNS, LISP mappings have the issue of trust, with efforts underway to make the published information



verifiable. When these mechanisms will be deployed in the LISP mapping system, the burden of providing and verifying trust should be kept away from MSPs, which will simply host the secured mappings. This will keep the low barrier of entry to become an MSP for third parties.

In all cases, the MSP configures its Map-Server(s) to publish the prefixes of its clients in the distributed mapping database and start encapsulating and forwarding Map-Requests to the ETRs of the AS. These ETRs register their prefix(es) with the Map-Server(s) through periodic authenticated Map-Register messages. In this context, for some LISP end sites, there is a need for mechanisms to:

o Automatically distribute EID prefix(es) shared keys between the ETRs and the EID-registrar Map-Server.

o Dynamically obtain the address of the Map-Server in the ETR of the AS.

The Map-Server plays a key role in the reachability of the EID- prefixes it is serving. On the one hand it is publishing these prefixes into the distributed mapping database and on the other hand it is encapsulating and forwarding Map-Requests to the authoritative ETRs of these prefixes. ITRs encapsulating towards EIDs under the responsibility of a failed Map-Server will be unable to look up any of their covering prefixes. The only exception are the ITRs that already contain the mappings in their local cache. In this case ITRs can reach ETRs until the entry expires (typically 24 hours). For this reason, redundant Map-Server deployments are desirable. A set of Map-Servers providing high-availability service to the same set of prefixes is called a redundancy group. ETRs are configured to send Map-Register messages to all Map-Servers in the redundancy group. To achieve fail-over (or load-balancing, if desired), current known BGP practices can be used on the LISP+ALT BGP overlay network.

Additionally, if a Map-Server has no reachability for any ETR serving a given EID block, it should not originate that block into the mapping system.

3.2. Map-Resolvers

A Map-Resolver a is a network infrastructure component which accepts LISP encapsulated Map-Requests, typically from an ITR, and finds the appropriate EID-to-RLOC mapping by either consulting its local cache or by consulting the distributed mapping database. Map-Resolver functionality is described in detail in [I-D.ietf-lisp-ms].

Anyone with access to the distributed mapping database can set up a



Map-Resolver and provide EID-to-RLOC mapping lookup service. In the case of the LISP+ALT mapping system, the Map-Resolver needs to become part of the ALT overlay so that it can forward packets to the appropriate Map-Servers. For more detail on how the ALT overlay works, see [I-D.ietf-lisp-alt]

For performance reasons, it is recommended that LISP sites use Map- Resolvers that are topologically close to their ITRs. ISPs supporting LISP will provide this service to their customers, possibly restricting access to their user base. LISP sites not in this position can use open access Map-Resolvers, if available. However, regardless of the availability of open access resolvers, the MSP providing the Map-Server(s) for a LISP site should also make available Map-Resolver(s) for the use of that site.

In medium to large-size ASes, ITRs must be configured with the RLOC of a Map-Resolver, operation which can be done manually. However, in Small Office Home Office (SOHO) scenarios a mechanism for autoconfiguration should be provided.

One solution to avoid manual configuration in LISP sites of any size is the use of anycast RLOCs for Map-Resolvers similar to the DNS root server infrastructure. Since LISP uses UDP encapsulation, the use of anycast would not affect reliability. LISP routers are then shipped with a preconfigured list of well know Map-Resolver RLOCs, which can be edited by the network administrator, if needed.

The use of anycast also helps improving mapping lookup performance. Large MSPs can increase the number and geographical diversity of their Map-Resolver infrastructure, using a single anycasted RLOC. Once LISP deployment is advanced enough, very large content providers may also be interested running this kind of setup, to ensure minimal connection setup latency for those connecting to their network from LISP sites.

While Map-Servers and Map-Resolvers implement different functionalities within the LISP mapping system, they can coexist on the same device. For example, MSPs offering both services, can deploy a single Map-Resolver/Map-Server in each PoP where they have a presence.

4. Proxy Tunnel Routers

4.1. P-ITR

Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP transition mechanism, allowing non-LISP sites to reach LISP sites.



They announce via BGP certain EID prefixes (aggregated, whenever possible) to attract traffic from non-LISP sites towards EIDs in the covered range. They do the mapping system lookup, and encapsulate received packets towards the appropriate ETR. Note that for the reverse path LISP sites can reach non-LISP sites simply by not encapsulating traffic. See [I-D.ietf-lisp-interworking] for a detailed description of P-ITR functionality.

The success of new protocols depends greatly on their ability to maintain backwards compatibility and inter-operate with the protocol(s) they intend to enhance or replace, and on the incentives to deploy the necessary new software or equipment. A LISP site needs an interworking mechanism to be reachable from non-LISP sites. A P-ITR can fulfill this role, enabling early adopters to see the benefits of LISP, similar to tunnel brokers helping the transition from IPv4 to IPv6. A site benefits from new LISP functionality (proportionally with existing global LISP deployment) when going LISP, so it has the incentives to deploy the necessary tunnel routers. In order to be reachable from non-LISP sites it has two options: keep announcing its prefix(es) with BGP, or have a P-ITR announce prefix(es) covering them.

If the goal of reducing the DFZ routing table size is to be reached, the second option is preferred. Moreover, the second option allows LISP-based ingress traffic engineering from all sites. However, the placement of P-ITRs significantly influences performance and deployment incentives. Section Section 5 is dedicated to the migration to a LISP-enabled Internet, and includes deployment scenarios for P-ITRs.

4.2. P-ETR

In contrast to P-ITRs, P-ETRs are not required for the correct functioning of all LISP sites. There are two cases, where they can be of great help:

o LISP sites with unicast reverse path forwarding (uRPF) restrictions, and

o LISP sites without native IPv6 communicating with LISP nodes with IPv6-only locators.

In the first case, uRPF filtering is applied at their upstream PE router. When forwarding traffic to non-LISP sites, an ITR does not encapsulate packets, leaving the original IP headers intact. As a result, packets will have EIDs in their source address. Since we are discussing the transition period, we can assume that a prefix covering the EIDs belonging to the LISP site is advertised to the



global routing tables by a P-ITR, and the PE router has a route towards it. However, the next hop will not be on the interface towards the CE router, so non-encapsulated packets will fail uRPF checks.

To avoid this filtering, the affected ITR encapsulates packets towards the locator of the P-ETR for non-LISP destinations. Now the source address of the packets, as seen by the PE router is the ITR’s locator, which will not fail the uRPF check. The P-ETR then decapsulates and forwards the packets.

The second use case is IPv4-to-IPv6 transition. Service providers using older access network hardware, which only supports IPv4 can still offer IPv6 to their clients, by providing a CPE device running LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP sites, with IPv6-only locators. Packets originating from the client LISP site for these destinations would be encapsulated towards the P-ETR’s IPv4 locator. The P-ETR is in a native IPv6 network, decapsulating and forwarding packets. For non-LISP destination, the packet travels natively from the P-ETR. For LISP destinations with IPv6-only locators, the packet will go through a P-ITR, in order to reach its destination.

For more details on P-ETRs see the [I-D.ietf-lisp-interworking] draft.

P-ETRs can be deployed by ISPs wishing to offer value-added services to their customers. As is the case with P-ITRs, P-ETRs too may introduce path stretch. Because of this the ISP needs to consider the tradeoff of using several devices, close to the customers, to minimize it, or few devices, farther away from the customers, minimizing cost instead.

Since the deployment incentives for P-ITRs and P-ETRs are different, it is likely they will be deployed in separate devices, except for the CDN case, which may deploy both in a single device.

In all cases, the existence of a P-ETR involves another step in the configuration of a LISP router. CPE routers, which are typically configured by DHCP, stand to benefit most from P-ETRs. To enable autoconfiguration of the P-ETR locator, a DHCP option would be required.

As a security measure, access to P-ETRs should be limited to legitimate users by enforcing ACLs.



5. Migration to LISP

This section discusses a deployment architecture to support the migration to a LISP-enabled Internet. The loosely defined terms of "early transition phase", "late transition phase", and "LISP Internet phase" refer to time periods when LISP sites are a minority, a majority, or represent all edge networks respectively.

5.1. LISP+BGP

For sites wishing to go LISP with their PI prefix the least disruptive way is to upgrade their border routers to support LISP, register the prefix into the LISP mapping system, but keep announcing it with BGP as well. This way LISP sites will reach them over LISP, while legacy sites will be unaffected by the change. The main disadvantage of this approach is that no decrease in the DFZ routing table size is achieved. Still, just increasing the number of LISP sites is an important gain, as an increasing LISP/non-LISP site ratio will slowly decrease the need for BGP-based traffic engineering that leads to prefix deaggregation. That, in turn, may lead to a decrease in the DFZ size in the late transition phase.

This scenario is not limited to sites that already have their prefixes announced with BGP. Newly allocated EID blocks could follow this strategy as well during the early LISP deployment phase, depending on the cost/benefit analysis of the individual networks. Since this leads to an increase in the DFZ size, the following architecture should be preferred for new allocations.

5.2. Mapping Service Provider (MSP) P-ITR Service

In addition to publishing their clients’ registered prefixes in the mapping system, MSPs with enough transit capacity can offer them P-ITR service as a separate service. This service is especially useful for new PI allocations, to sites without existing BGP infrastructure, that wish to avoid BGP altogether. The MSP announces the prefix into the DFZ, and the client benefits from ingress traffic engineering without prefix deaggregation. The downside of this scenario is path stretch, which may be greater than 1.

Routing all non-LISP ingress traffic through a third party which is not one of its ISPs is only feasible for sites with modest amounts of traffic (like those using the IPv6 tunnel broker services today), especially in the first stage of the transition to LISP, with a significant number of legacy sites. When the LISP/non-LISP site ratio becomes high enough, this approach can prove increasingly attractive.



Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix deaggregation for traffic engineering purposes, resulting in slower routing table increase in the case of new allocations and potential decrease for existing ones. Moreover, MSPs serving different clients with adjacent aggregable prefixes may lead to additional decrease, but quantifying this decrease is subject to future research study.

5.3. Proxy-ITR Route Distribution (PITR-RD)

Instead of a LISP site, or the MSP, announcing their EIDs with BGP to the DFZ, this function can be outsourced to a third party, a P-ITR Service Provider (PSP). This will result in a decrease of the operational complexity both at the site and at the MSP.

The PSP manages a set of distributed P-ITR(s) that will advertise the corresponding EID prefixes through BGP to the DFZ. These P-ITR(s) will then encapsulate the traffic they receive for those EIDs towards the RLOCs of the LISP site, ensuring their reachability from non-LISP sites.

While it is possible for a PSP to manually configure each client’s EID routes to be announced, this approach offers little flexibility and is not scalable. This section presents a scalable architecture that offers automatic distribution of EID routes to LISP sites and service providers.

The architecture requires no modification to existing LISP network elements, but it introduces a new (conceptual) network element, the EID Route Server, defined as a router that either propagates routes learned from other EID Route Servers, or it originates EID Routes. The EID-Routes that it originates are those that it is authoritative for. It propagates these routes to Proxy-ITRs within the AS of the EID Route Server. It is worth to note that a BGP capable router can be also considered as an EID Route Server.

Further, an EID-Route is defined as a prefix originated via the Route Server of the mapping service provider, which should be aggregated if the MSP has multiple customers inside a single netblock. This prefix is propagated to other P-ITRs both within the MSP and to other P-ITR operators it peers with. EID Route Servers are operated either by the LISP site, MSPs or PSPs, and they may be collocated with a Map- Server or P-ITR, but are a functionally discrete entity. They distribute EID-Routes, using BGP, to other domains, according to policies set by participants.



MSP (AS64500) RS ---> P-ITR | / | _.--./ ,-’’ /‘--. LISP site ---,’ | v ‘. ( | DFZ )----- Mapping system non-LISP site ----. | ^ ,’ ‘--. / _.-’ | ‘--’’ v / P-ITR PSP (AS64501)

Figure 5: The P-ITR Route Distribution architecture

The architecture described above decouples EID origination from route propagation, with the following benefits:

o Can accurately represent business relationships between P-ITR operators

o More mapping system agnostic (no reliance on ALT)

o Minor changes to P-ITR implementation, no changes to other components

In the example in the figure we have a MSP providing services to the LISP site. The LISP site does not run BGP, and gets an EID allocation directly from a RIR, or from the MSP, who may be a LIR. Existing PI allocations can be migrated as well. The MSP ensures the presence of the prefix in the mapping system, and runs an EID Route Server to distribute it to P-ITR service providers. Since the LISP site does not run BGP, the prefix will be originated with the AS number of the MSP.

In the simple case depicted in Figure 5 the EID-Route of LISP Site will be originated by the Route Server, and announced to the DFZ by the PSP’s P-ITRs with AS path 64501 64500. From that point on, the usual BGP dynamics apply. This way, routes announced by P-ITR are still originated by the authoritative Route Server. Note that the peering relationships between MSP/PSPs and those in the underlying forwarding plane may not be congruent, making the AS path to a P-ITR shorter than it is in reality.

The non-LISP site will select the best path towards the EID-prefix, according to its local BGP policies. Since AS-path length is usually an important metric for selecting paths, a careful placement of P-ITR



could significantly reduce path-stretch between LISP and non-LISP sites.

The architecture allows for flexible policies between MSP/PSPs. Consider the EID Route Server networks as control plane overlays, facilitating the implementation of policies necessary to reflect the business relationships between participants. The results are then injected to the common underlying forwarding plane. For example, some MSP/PSPs may agree to exchange EID-Prefixes and only announce them to each of their forwarding plane customers. Global reachability of an EID-prefix depends on the MSP the LISP site buys service from, and is also subject to agreement between the mentioned parties.

In terms of impact on the DFZ, this architecture results in a slower routing table increase for new allocations, since traffic engineering will be done at the LISP level. For existing allocations migrating to LISP, the DFZ may decrease since MSPs may be able to aggregate the prefixes announced.

Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix deaggregation for traffic engineering purposes, resulting in slower routing table increase in the case of new allocations and potential decrease for existing ones. Moreover, MSPs serving different clients with adjacent aggregable prefixes may lead to additional decrease, but quantifying this decrease is subject to future research study.

The flexibility and scalability of this architecture does not come without a cost however: A PSP operator has to establish either transit or peering relationships to improve their connectivity.

5.4. Migration Summary

The following table presents the expected effects of the different transition scenarios during a certain phase on the DFZ routing table size:

Phase | LISP+BGP | MSP P-ITR | PITR-RD -----------------+--------------+-----------------+---------------- Early transition | no change | slower increase | slower increase Late transition | may decrease | slower increase | slower increase LISP Internet | considerable decrease

It is expected that PITR-RD will co-exist with LISP+BGP during the migration, with the latter being more popular in the early transition phase. As the transition progresses and the MSP P-ITR and PITR-RD ecosystem gets more ubiquitous, LISP+BGP should become less attractive, slowing down the increase of the number of routes in the



DFZ.

6. Step-by-Step BGP to LISP Migration Procedure

6.1. Customer Pre-Install and Pre-Turn-up Checklist

1. Determine how many current physical service provider connections the customer has and their existing bandwidth and traffic engineering requirements.

This information will determine the number of routing locators, and the priorities and weights that should be configured on the xTRs.

2. Make sure customer router has LISP capabilities.

* Obtain output of ’show version’ from the CE router.

This information can be used to determine if the platform is appropriate to support LISP, in order to determine if a software and/or hardware upgrade is required.

* Have customer upgrade (if necessary, software and/or hardware) to be LISP capable.

3. Obtain current running configuration of CE router. A suggested LISP router configuration example can be customized to the customer’s existing environment.

4. Verify MTU Handling

* Request increase in MTU to (1556) on service provider connections. Prior to MTU change verify that 1500 byte packet from P-xTR to RLOC with do not fragment (DF-bit) bit set.

* Ensure they are not filtering ICMP unreachable or time- exceeded on their firewall or router.

LISP, like any tunneling protocol, will increase the size of packets when the LISP header is appended. If increasing the MTU of the access links is not possible, care must be taken that ICMP is not being filtered in order to allow for Path MTU Discovery to take place.

5. Validate member prefix allocation.

This step is to check if the prefix used by the customer is a



direct (Provider Independent), or if it is a prefix assigned by a physical service provider (Provider Allocated). If the prefixes are assigned by other service provivers then a Letter of Agreement is required to announce prefixes through the Proxy Service Provider.

6. Verify the member RLOCs and their reachability.

This step ensures that the RLOCs configured on the CE router are in fact reachable and working.

7. Prepare for cut-over.

* If possible, have a host outside of all security and filtering policies connected to the console port of the edge router or switch.

* Make sure customer has access to the router in order to configure it.

6.2. Customer Activating LISP Service

1. Customer configures LISP on CE router(s) from service provider recommended configuration.

The LISP configuration consists of the EID prefix, the locators, and the weights and priorities of the mapping between the two values. In addition, the xTR must be configured with Map- Resolver(s), Map-Server(s) and the shared key for registering to Map-Server(s). If required, Proxy-ETR(s) may be configured as well.

In addition to the LISP configuration, the following:

* Ensure default route(s) to next-hop external neighbors are included and RLOCs are present in configuration.

* If two or more routers are used, ensure all RLOCs are included in the LISP configuration on all routers.

* It will be necessary to redistribute default route via IGP between the external routers.

2. When transition is ready perform a soft shutdown on existing eBGP peer session(s)

* From CE router, use LIG to ensure registration is successful.



* To verify LISP connectivity, ping LISP connected sites. See http://www.lisp4.net/ and/or http://www.lisp6.net/ for potential candidates.

* To verify connectivity to non-LISP sites, try accessing major Internet sites via a web browser.

6.3. Cut-Over Provider Preparation and Changes

1. Verify site configuration and then active registration on Map- Server(s)

* Authentication key

* EID prefix

2. Add EID space to map-cache on proxies

3. Add networks to BGP advertisement on proxies

* Modify route-maps/policies on P-xTRs

* Modify route policies on core routers (if non-connected member)

* Modify ingress policers on core routers

* Ensure route announcement in looking glass servers, RouteViews

4. Perform traffic verification test

* Ensure MTU handling is as expected (PMTUD working)

* Ensure proxy-ITR map-cache population

* Ensure access from traceroute/ping servers around Internet

* Use a looking glass, to check for external visibility of registration via several Map-Resolvers (e.g., http://lispmon.net/).


Security implications of LISP deployments are to be discussed in separate documents. [I-D.saucez-lisp-security] gives an overview of LISP threat models, while securing mapping lookups is discussed in [I-D.ietf-lisp-sec].




This memo includes no request to IANA.

9. Acknowledgements

Many thanks to Margaret Wasserman for her contribution to the IETF76 presentation that kickstarted this work. The authors would also like to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller, Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, and everyone else who provided input.

10. References


[I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-15 (work in progress), July 2011.

[I-D.ietf-lisp-alt] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09 (work in progress), September 2011.

[I-D.ietf-lisp-interworking] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-02 (work in progress), June 2011.

[I-D.ietf-lisp-ms] Fuller, V. and D. Farinacci, "LISP Map Server Interface", draft-ietf-lisp-ms-12 (work in progress), October 2011.

[I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-00 (work in progress), July 2011.

[I-D.saucez-lisp-security] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Security Threats", draft-saucez-lisp-security-03 (work in progress), March 2011.




[I-D.ietf-lisp-eid-block] Lewis, D., Meyer, D., Iannone, L., and V. Fuller, "LISP EID Block", draft-ietf-lisp-eid-block-01 (work in progress), October 2011.

[I-D.lear-lisp-nerd] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-08 (work in progress), March 2010.

[cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS performance and the effectiveness of caching", 2002.


Lorand Jakab Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain


Albert Cabellos-Aparicio Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain


Florin Coras Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain




Jordi Domingo-Pascual Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain


Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA



Network Working Group L. IannoneInternet-Draft Telekom Innovation LaboratoriesIntended status: Informational D. LewisExpires: May 3, 2012 D. Meyer V. Fuller Cisco Systems, Inc. October 31, 2011

LISP EID Block draft-ietf-lisp-eid-block-01.txt

Abstract

This is a direction to IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used by sites deploying LISP as EID (Endpoint IDentifier) addressing space for local intra-domain routing and global endpoint identification.

Status of this Memo




This Internet-Draft will expire on May 3, 2012.

Copyright Notice



Iannone, et al. Expires May 3, 2012 [Page 1]

Internet-Draft LISP EID Block October 2011


Table of Contents

1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 4. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 5 5. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 6 7. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 9 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10



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

This document directs the IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP - [I-D.ietf-lisp]), LISP Map Server ([I-D.ietf-lisp-ms]), LISP Alternative Topology (LISP+ALT - [I-D.ietf-lisp-alt]) (or other) mapping system, and LISP Interworking ([I-D.ietf-lisp-interworking]).

This block will be used as global Endpoint IDentifier (EID) space (Section 3).


LISP operates on two name spaces and introduces several new network elements. This section provides high-level definitions of the LISP name spaces and network elements and as such, it MUST NOT be considered as an authoritative source. The reference to the authoritative document for each term is included in every term description.

Legacy Internet: The portion of the Internet which does not run LISP and does not participate in LISP+ALT or any other mapping system.

LISP site: A LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network. See [I-D.ietf-lisp] for more details.

Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of the first (most inner) LISP header of a packet. A packet that is emitted by a system contains EIDs in its headers and LISP headers are prepended only when the packet reaches an Ingress Tunnel Router (ITR) on the data path to the destination EID. The source EID is obtained via existing mechanisms used to set a host’s "local" IP address. An EID is allocated to a host from an EID- prefix block associated with the site where the host is located. See [I-D.ietf-lisp] for more details.



EID-prefix: A power-of-two block of EIDs that are allocated to a site by an address allocation authority. See [I-D.ietf-lisp] for more details.

EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable in the [RFC4632] sense. That is, an EID-Prefix aggregate is defined to be a single contiguous power-of-two EID-prefix block. Such a block is characterized by a prefix and a length. See [I-D.ietf-lisp] for more details.

Routing LOCator (RLOC): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC is the output of an EID-to- RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider Aggregatable (PA) addresses. See [I-D.ietf-lisp] for more details.

EID-to-RLOC Mapping: A binding between an EID-Prefix and the RLOC- set that can be used to reach the EID-Prefix. The general term "mapping" always refers to an EID-to-RLOC mapping. See [I-D.ietf-lisp] for more details.

Ingress Tunnel Router (ITR): An Ingress Tunnel Router (ITR) is a router that accepts receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. The router treats the "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of its globally-routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. See [I-D.ietf-lisp] for more details.

Egress Tunnel Router (ETR): An Egress Tunnel Router (ETR) receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. An ETR router accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. See [I-D.ietf-lisp] for more details.

Proxy ITR (PITR): A Proxy-ITR (PITR) acts like an ITR but does so on behalf of non-LISP sites which send packets to destinations at LISP sites. See [I-D.ietf-lisp-interworking] for more details.



Proxy ETR (PETR): A Proxy-ETR (PETR) acts like an ETR but does so on behalf of LISP sites which send packets to destinations at non- LISP sites. See [I-D.ietf-lisp-interworking] for more details.

Map Server (MS): A network infrastructure component that learns EID- to-RLOC mapping entries from an authoritative source (typically an ETR). A Map-Server publishes these mappings in the distributed mapping system. See [I-D.ietf-lisp-ms] for more details.

Map Resolver (MR): A network infrastructure component that accepts LISP Encapsulated Map-Requests, typically from an ITR, quickly determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is immediately returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting the distributed mapping database system. See [I-D.ietf-lisp-ms] for more details.

The LISP Alternative Logical Topology (ALT): The virtual overlay network made up of tunnels between LISP+ALT Routers. The Border Gateway Protocol (BGP) runs between ALT Routers and is used to carry reachability information for EID-prefixes. The ALT provides a way to forward Map-Requests toward the ETR that "owns" an EID- prefix. See [I-D.ietf-lisp-alt] for more details.

ALT Router: The device on which runs the ALT. The ALT is a static network built using tunnels between ALT Routers. These routers are deployed in a roughly-hierarchical mesh in which routers at each level in the topology are responsible for aggregating EID- Prefixes learned from those logically "below" them and advertising summary prefixes to those logically "above" them. Prefix learning and propagation between ALT Routers is done using BGP. When an ALT Router receives an ALT Datagram, it looks up the destination EID in its forwarding table (composed of EID-Prefix routes it learned from neighboring ALT Routers) and forwards it to the logical next-hop on the overlay network. The primary function of LISP+ALT routers is to provide a lightweight forwarding infrastructure for LISP control-plane messages (Map-Request and Map-Reply), and to transport data packets when the packet has the same destination address in both the inner (encapsulating) destination and outer destination addresses ((i.e., a Data Probe packet). See [I-D.ietf-lisp-alt] for more details.

4. Rationale and Intent

With the current specifications, if an ITR is sending to all types of destinations (i.e., non-LISP destinations, LISP destinations not in the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the



only way to understand whether or not to encapsulate the traffic is to perform a cache lookup and, in case of cache-miss, send a Map- Request to the mapping system. In the meanwhile, packets can be dropped.

By defining an IPv6 EID Block is possible to configure the router so to natively forward all packets that have not a destination address in the block, without performing any lookup whatsoever. This will give a tighter control over the traffic in the initial experimental phase, while facilitating its large-scale deployment.

The EID Block will be used only at configuration level, it is RECOMMENDED not to hard-code in any way the IPv6 EID Block in the router hardware. This allows to avoid locking out sites that may want to switch to LISP while keeping their own IPv6 prefix, which is not in the IPv6 EID Block.

5. Expected use

Sites planning to deploy LISP may request a prefix in the IPv6 EID Block. Such prefix will be used for routing and endpoint identification inside the site requesting it. Mappings related to such prefix, or part of it, will be made available through the mapping system in use or registered to one or more Map-Server(s). Too guarantee reachability from the Legacy Internet the prefix could be announced in the BGP routing infrastructure by one or more PITR(s), possibly as part of a larger prefix, aggregating several prefixes of several sites.

6. Block Dimension

The working group reached consensus on an initial allocation of a /16 prefix out of a /12 block which is asked to remain reserved for future use as EID b space. The reason of such consensus is manifold:

o A /16 prefix is suffiently large to cover initial allocation and requests for prefoxes in the EID space in the next few years for very large scale experimentation and deployment. As a comparison is worth to mention that the current LISP Beta Network ([BETA]) is using a /32 prefix, hence a /16 should be sufficiently large to accomodate growth in the near future.

o The request to reserve the /12 prefix covering the initial /16 allocation is in line with IANA policies that fix to /12 the minimum IPv6 allocation.



o The proposed alignment provides as well a natural support for DNS. In particular, reverse DNS for IPv6 in the special ip6.arpa domain is represented as sequence of nibbles. A different alignment would force to a binary representation.

7. Action Plan

This document requests IANA to initially allocate a /16 prefix out of the IPv6 addressing space for use as EID in LISP (Locator/ID Separation protocol). It is suggested to IANA to temporarily avoid allocating any other address block the same /12 prefix the EID /16 prefix belongs to. This is to accommodate future requests of EID space without fragmenting the EID addressing space. This will also help from an operational point of view, since it will be sufficient to change the subnet mask length in existing deployments.

If in the future there will be need for a larger EID Block the address space adjacent the EID Block could be allocate by IANA according to the current policies.

8. Routing Considerations

In order to provide connectivity between the Legacy Internet and LISP sites, PITRs announcing large aggregates of the IPv6 EID Block could be deployed. By doing so, PITRs will attract traffic destined to LISP sites in order to encapsulate and forward it toward the specific destination LISP site. Routers in the Legacy Internet MUST treat announcements of prefixes from the IPv6 EID Block as normal announcements, applying best current practice for traffic engineering and security.

Even in a LISP site, not all routers need to run LISP elements. In particular, routers that are not at the border of the local domain, used only for intra-domain routing, do not need to provide any specific LISP functionality but MUST be able to route traffic using addresses in the IPv6 EID Block.

For the above-mentioned reasons, routers that do not run any LISP element, MUST NOT include any special handling code or hardware for addresses in the IPv6 EID Block. In particular, it is RECOMMENDED that the default router configuration does not handle such addresses in any special way. Doing differently could prevent communication between the Legacy Internet and LISP sites or even break local intra- domain connectivity.




This document does not introduce new security threats in the LISP architecture nor in the Legacy Internet architecture.

10. Acknowledgments

Special thanks to Roque Gagliano for his suggestions and pointers to the IANA allocation policies. Thanks to Marla Azinger, Chris Morrow, and Peter Schoenmaker, all made insightful comments on early versions of this draft.


This document instructs the IANA to assign a /16 IPv6 prefix for use as the global LISP EID space using an hierarchical allocation as outlined in [RFC2434]. During the discussion related to this document, the LISP Working Group agreed in suggesting to IANA to reserve adjacent addressing space for future use as EID space if needs come. Following the policies outlined in [RFC2434], such space will be assigned only upon IETF Consensus. This document does not specify any specific value for the requested address block.

12. References


[I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-15 (work in progress), July 2011.

[I-D.ietf-lisp-alt] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-06 (work in progress), March 2011.


[I-D.ietf-lisp-ms] Fuller, V. and D. Farinacci, "LISP Map Server Interface",



draft-ietf-lisp-ms-12 (work in progress), October 2011.

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

[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.


[BETA] LISP Beta Network, "http://www.lisp4.net", 2008-2011.

Appendix A. Document Change Log

Version 01 Posted October 2011.

o Added Section 6.

Version 00 Posted July 2011.

o Updated section "IANA Considerations"

o Added section "Rationale and Intent" explaining why the EID block allocation is useful.

o Added section "Expected Use" explaining how sites can request and use a prefix in the IPv6 EID Block.

o Added section "Action Plan" suggesting IANA to avoid allocating address space adjacent the allocated EID block in order to accommodate future EID space requests.

o Added section "Routing Consideration" describing how routers not running LISP deal with the requested address block.

o Added the present section to keep track of changes.

o Rename of draft-meyer-lisp-eid-block-02.txt.




Luigi Iannone Telekom Innovation Laboratories


Darrel Lewis Cisco Systems, Inc.


David Meyer Cisco Systems, Inc.


Vince Fuller Cisco Systems, Inc.



Network Working Group F. MainoInternet-Draft V. ErmaganIntended status: Experimental Cisco SystemsExpires: July 4, 2012 A. Cabellos Technical University of Catalonia D. Saucez O. Bonaventure Universite catholique de Louvain January 1, 2012

LISP-Security (LISP-SEC) draft-ietf-lisp-sec-01.txt

Abstract

This memo specifies LISP-SEC, a set of security mechanisms that provide origin authentication, integrity and anti-replay protection to LISP’s EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages.

Requirements Language

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

Status of this Memo




This Internet-Draft will expire on July 4, 2012.

Copyright Notice

Maino, et al. Expires July 4, 2012 [Page 1]

Internet-Draft LISP-SEC January 2012


This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 4 5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7 5.1. Encapsulated Control Message LISP-SEC Extensions . . . . . 7 5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 9 5.3. ITR Processing . . . . . . . . . . . . . . . . . . . . . . 10 5.3.1. Map-Reply Record Validation . . . . . . . . . . . . . 12 5.3.2. PITR Processing . . . . . . . . . . . . . . . . . . . 13 5.4. Encrypting and Decrypting an OTK . . . . . . . . . . . . . 13 5.5. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14 5.6. Map-Server Processing . . . . . . . . . . . . . . . . . . 14 5.6.1. Map-Server Processing in Proxy mode . . . . . . . . . 15 5.7. ETR Processing . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 16 6.2. Random Number Generation . . . . . . . . . . . . . . . . . 16 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7.1. HMAC functions . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Key Wrap Functions . . . . . . . . . . . . . . . . . . . . 17 7.3. Key Derivation Functions . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19



1. Introduction

The Locator/ID Separation Protocol [I-D.ietf-lisp] defines a set of functions for routers to exchange information used to map from non- routable Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs). If these EID-to-RLOC mappings, carried through Map-Reply messages, are transmitted without integrity protection, an adversary can manipulate them and hijack the communication, impersonate the requested EID or mount Denial of Service or Distributed Denial of Service attacks. Also, if the Map-Reply message is transported unauthenticated, an adversarial LISP entity can overclaim an EID- prefix and maliciously redirect traffic directed to a large number of hosts. A detailed description of "overclaiming" attack is provided in [I-D.ietf-lisp-threats].

This memo specifies LISP-SEC, a set of security mechanisms that provide origin authentication, integrity and anti-replay protection to LISP’s EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages, ensuring that the sender of a Map-Reply that provides the location for a given EID-prefix is entitled to do so according to the EID prefix registered in the associated Map Server. Map-Register security, including the right for a LISP entity to register an EID-prefix or to claim presence at an RLOC, is out of the scope of LISP-SEC. Additional security considerations are described in Section 6.


One-Time Key (OTK): An ephemeral randomly generated key that must be used for a single Map-Request/Map-Reply exchange.

ITR-OTK: The One-Time Key generated at the ITR.

MS-OTK: The One-Time Key generated at the Map-Server.

Encapsulated Control Message (ECM): A LISP control message that is prepended with an additional LISP header. ECM is used by ITRs to send LISP control messages to a Map-Resolver, by Map-Resolvers to forward LISP control messages to a Map-Server, and by Map- Resolvers to forward LISP control messages to an ETR.

Authentication Data (AD): Metadata that is included either in a LISP ECM header or in a Map-Reply message to support confidentiality, integrity protection, and verification of EID-



prefix authorization.

OTK-AD: The portion of ECM Authentication Data that contains a One-Time Key.

EID-AD: The portion of ECM and Map-Reply Authentication Data used for verification of EID-prefix authorization.

PKT-AD: The portion of Map-Reply Authentication Data used to protect the integrity of the Map-Reply message.

For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS) and Map-Resolver (MR) please consult the LISP specification [I-D.ietf-lisp].

3. LISP-SEC Threat Model

LISP-SEC addresses the control plane threats, described in [I-D.ietf-lisp-threats], that target EID-to-RLOC mappings, including manipulations of Map-Request and Map-Reply messages, and malicious xTR EID overclaiming. However LISP-SEC makes two main assumptions that are not part of [I-D.ietf-lisp-threats]. First, the LISP Mapping System is expected to deliver Map-Request messages to their intended destinations as identified by the EID. Second, no man-in- the-middle attack can be mounted within the LISP Mapping System. Furthermore, while LISP-SEC enables detection of EID prefix over claiming attacks, it assumes that Map Servers can verify the EID prefix authorization at time of registration.

Accordingly to the threat model described in [I-D.ietf-lisp-threats] LISP-SEC assumes that any kind of attack, including MITM attacks, can be mounted in the access network, outside of the boundaries of the LISP mapping system. An on-path attacker, outside of the LISP mapping service system can, for instance, hijack mapping requests and replies, spoofing the identity of a LISP node. Another example of on-path attack, called over claiming attack, can be mounted by a malicious Egress Tunnel Router (ETR), by over claiming the EID- prefixes for which it is authoritative. In this way the ETR can maliciously redirect traffic directed to a large number of hosts.

4. Protocol Operations

The goal of the security mechanisms defined in [I-D.ietf-lisp] is to



prevent unauthorized insertion of mapping data, by providing origin authentication and integrity protection for the Map-Registration, and by using the nonce to detect unsolicited Map-Reply sent by off-path attackers.

LISP-SEC builds on top of the security mechanisms defined in [I-D.ietf-lisp] to address the threats described in Section 3 by leveraging the trust relationships existing among the LISP entities participating to the exchange of the Map-Request/Map-Reply messages. Those trust relationships are used to securely distribute a One-Time Key (OTK) that provides origin authentication, integrity and anti- replay protection to mapping data conveyed via the mapping lookup process, and that effectively prevent over claiming attacks. The processing of security parameters during the Map-Request/Map-Reply exchange is as follows:

o The ITR-OTK is generated and stored at the ITR, and securely transported to the Map-Server.

o The Map-Server uses the ITR-OTK to compute an HMAC that protects the integrity of the mapping data provided by the Map-Server to prevent overclaiming attacks. The Map-Server also derives a new OTK (MS-OTK) that is passed to the ETR, by applying a Key Derivation Function (KDF) to the ITR-OTK.

o The ETR uses the MS-OTK to compute an HMAC that protects the integrity of the Map-Reply sent to the ITR.

o Finally, the ITR uses the stored ITR-OTK to verify the integrity of the mapping data provided by both the Map-Server and the ETR, and to verify that no overclaiming attacks were mounted along the path between the Map-Server and the ITR.

Section 5 provides the detailed description of the LISP-SEC control messages and their processing, while the rest of this section describes the flow of protocol operations at each entity involved in the Map-Request/Map-Reply exchange:

o The ITR, upon transmitting a Map-Request message, generates and stores an OTK (ITR-OTK). This key is included into the Encapsulated Control Message (ECM) that contains the Map-Request sent to the Map-Resolver. To provide confidentiality to the ITR- OTK over the path between the ITR and its Map-Resolver, the ITR- OTK SHOULD be encrypted using a preconfigured key shared between the ITR and the Map-Resolver, similar to the key shared between the ETR and the Map-Server in order to secure ETR registration [I-D.ietf-lisp-ms].



o The Map-Resolver decapsulates the ECM message, decrypts the ITR- OTK, if needed, and forwards through the Mapping System the received Map-Request and the ITR-OTK, as part of a new ECM message. As described in Section 5.5, the LISP Mapping System delivers the ECM to the appropriate Map-Server, as identified by the EID destination address of the Map-Request.

o The Map-Server is configured with the location mappings and policy information for the ETR responsible for the destination EID address. Using this preconfigured information the Map-Server, after the decapsulation of the ECM message, finds the longest match EID-prefix that covers the requested EID in the received Map-Request. The Map-Server adds this EID-prefix, together with an HMAC computed using the ITR-OTK, to a new Encapsulated Control Message that contains the received Map-Request.

o The Map-Server derives a new OTK (MS-OTK) by applying a Key Derivation Function (KDF) to the ITR-OTK. MS-OTK is included in the Encapsulated Control Message sent to the ETR. To provide MS- OTK confidentiality over the path between the Map-Server and the ETR, the MS-OTK should be encrypted using the key shared between the ETR and the Map-Server in order to secure ETR registration [I-D.ietf-lisp-ms].

o If the Map-Server is acting in proxy mode, as specified in [I-D.ietf-lisp], the ETR is not involved in the generation of the Map-Reply. In this case the Map-Server generates the Map-Reply on behalf of the ETR as described below.

o The ETR, upon receiving the Encapsulated Map-Request from the Map- Server, decrypts the MS-OTK, if needed, and originates a Map-Reply that contains the EID-to-RLOC mapping information as specified in [I-D.ietf-lisp].

o The ETR computes an HMAC over the original LISP Map-Reply, keyed with MS-OTK to protect the integrity of the whole Map-Reply. The ETR also copies the EID-prefix authorization data that the Map- Server included in the Encapsulated Map-Request into the Map-Reply message.

o The ITR, upon receiving the Map-Reply, uses the locally stored ITR-OTK to verify the integrity of the EID-prefix authorization data included in the Map-Reply by the Map-Server. The ITR computes the MS-OTK by applying the same KDF used by the Map- Server, and verifies the integrity of the Map-Reply. If the integrity checks fail, the Map-Reply MUST be discarded. Also, if the EID-prefixes claimed by the ETR in the Map-Reply are not equal or less specific than the EID-prefix authorization data inserted



by the Map-Server, the ITR MUST discard the Map-Reply.

5. LISP-SEC Control Messages Details

LISP-SEC metadata associated with a Map-Request is transported within the Encapsulated Control Message that contains the Map-Request.

LISP-SEC metadata associated with the Map-Reply is transported within the Map-Reply itself.

5.1. Encapsulated Control Message LISP-SEC Extensions

LISP-SEC uses the ECM (Encapsulated Control Message) defined in [I-D.ietf-lisp] with Type set to 8, and S bit set to 1 to indicate that the LISP header includes Authentication Data (AD). The format of the LISP-SEC ECM Authentication Data is defined in the following figure. OTK-AD stands for One-Time Key Authentication Data and EID-AD stands for EID Authentication Data.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type |V| Reserved | Requested HMAC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | OTK Length | OTK Encryption ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | One-Time-Key Preamble ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OTK-AD | ... One-Time-Key Preamble | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ˜ One-Time Key (128 bits) ˜/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ | EID-AD Length | KDF ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record Count | Reserved | EID HMAC ID | EID-AD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | | Reserved | EID mask-len | EID-AFI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | ˜ EID-prefix ... ˜ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | ˜ EID HMAC ˜ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+

LISP-SEC ECM Authentication Data



AD Type: 1 (LISP-SEC Authentication Data)

V: Key Version bit. This bit is toggled when the sender switches to a new OTK wrapping key

Reserved: Set to 0 on transmission and ignored on receipt.

Requested HMAC ID: The HMAC algorithm requested by the ITR. See Section 5.3 for details.

OTK Length: The length (in bytes) of the OTK Authentication Data (OTK-AD), that contains the OTK Preamble and the OTK.

OTK Encryption ID: The identifier of the key wrapping algorithm used to encrypt the One-Time-Key. When a 128-bit OTK is sent unencrypted by the Map-Resolver, the OTK Encryption ID is set to NULL_KEY_WRAP_128. See Section 5.4 for more details.

One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When the OTK is encrypted, this field may carry additional metadata resulting from the key wrapping operation. When a 128-bit OTK is sent unencrypted by Map-Resolver, the OTK Preamble is set to 0x0000000000000000 (64 bits). See Section 5.4 for details.

One-Time-Key: the OTK encrypted (or not) as specified by OTK Encryption ID. See Section 5.4 for details.

EID-AD Length: length (in bytes) of the EID Authentication Data (EID-AD). The ITR MUST set EID-AD Length to 4 bytes, as it only fills the KDF ID field, and all the remaining fields part of the EID-AD are not present. An EID-AD MAY contain multiple EID- records. Each EID-record is 4-byte long plus the length of the AFI-encoded EID-prefix.

KDF ID: Identifier of the Key Derivation Function used to derive the MS-OTK. The ITR SHOULD use this field to indicate the recommended KDF algorithm, according to local policy. The Map- Server can overwrite the KDF ID if it does not support the KDF ID recommended by the ITR. See Section 5.4 for more details.

Record Count: The number of records in this Map-Request message. A record is comprised of the portion of the packet that is labeled ’Rec’ above and occurs the number of times equal to Record Count.


EID HMAC ID: Identifier of the HMAC algorithm used to protect the integrity of the EID-AD. This field is filled by Map-Server that



computed the EID-prefix HMAC. See Section 5.4 for more details.

EID mask-len: Mask length for EID-prefix.

EID-AFI: Address family of EID-prefix according to [RFC5226]

EID-prefix: The Map-Server uses this field to specify the EID- prefix that the destination ETR is authoritative for, and is the longest match for the requested EID.

EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server. Before computing the HMAC operation the EID HMAC field MUST be set to 0. The HMAC covers the entire EID-AD.

5.2. Map-Reply LISP-SEC Extensions

LISP-SEC uses the Map-Reply defined in [I-D.ietf-lisp], with Type set to 2, and S bit set to 1 to indicate that the Map-Reply message includes Authentication Data (AD). The format of the LISP-SEC Map- Reply Authentication Data is defined in the following figure. PKT-AD is the Packet Authentication Data that covers the Map-Reply payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AD Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ | EID-AD Length | KDF ID | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record Count | Reserved | EID HMAC ID | EID-AD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | | Reserved | EID mask-len | EID-AFI | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | ˜ EID-prefix ... ˜ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | ˜ EID HMAC ˜ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ | PKT-AD Length | PKT HMAC ID |\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ˜ PKT HMAC ˜ PKT-AD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

LISP-SEC Map-Reply Authentication Data

AD Type: 1 (LISP-SEC Authentication Data)

EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY contain multiple EID-records. Each EID-record is 4-byte long plus the length of the AFI-encoded EID-prefix.



KDF ID: Identifier of the Key Derivation Function used to derive MS-OTK. See Section 5.6 for more details.

Record Count: The number of records in this Map-Reply message. A record is comprised of the portion of the packet that is labeled ’Rec’ above and occurs the number of times equal to Record Count.


EID HMAC ID: Identifier of the HMAC algorithm used to protect the integrity of the EID-AD. See Section 5.6 for more details.

EID mask-len: Mask length for EID-prefix.

EID-AFI: Address family of EID-prefix according to [RFC5226].

EID-prefix: This field contains an EID-prefix that the destination ETR is authoritative for, and is the longest match for the requested EID.

EID HMAC: HMAC of the EID-AD, as computed by the Map-Server. Before computing the HMAC operation the EID HMAC field MUST be set to 0. The HMAC covers the entire EID-AD.

PKT-AD Length: length (in bytes) of the Packet Authentication Data (PKT-AD).

PKT HMAC ID: Identifier of the HMAC algorithm used to protect the integrity of the Map-reply Location Data.

PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP- SEC Authentication Data. The scope of the authentication goes from the Map-Reply Type field to the PKT HMAC field included. Before computing the HMAC operation the PKT HMAC field MUST be set to 0. See Section 5.7 for more details.

5.3. ITR Processing

Upon creating a Map-Request, the ITR generates a random ITR-OTK that is stored locally, together with the nonce generated as specified in [I-D.ietf-lisp].

The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 1, to indicate the presence of Authentication Data. If the ITR and the Map-Resolver are configured with a shared key, the ITR-OTK confidentiality SHOULD be protected by wrapping the ITR-OTK with the algorithm specified by the OTK Encryption ID field. See Section 5.4 for further details on OTK encryption.



The Requested HMAC ID field contains the suggested HMAC algorithm to be used by the Map-Server and the ETR to protect the integrity of the ECM Authentication data and of the Map-Reply.

The KDF ID field, specifies the suggested key derivation function to be used by the Map-Server to derive the MS-OTK.

The EID-AD length is set to 4 bytes, since the Authentication Data does not contain EID-prefix Authentication Data, and the EID-AD contains only the KDF ID field.

In response to an encapsulated Map-Request that has the S-bit set, an ITR MUST receive a Map-Reply with the S-bit set, that includes an EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the ITR MUST discard it. In response to an encapsulated Map-Request with S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and the ITR SHOULD discard the Map-Reply if the S-bit is set.

Upon receiving a Map-Reply, the ITR must verify the integrity of both the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of the integrity checks fails.

The integrity of the EID-AD is verified using the locally stored ITR- OTK to re-compute the HMAC of the EID-AD using the algorithm specified in the EID HMAC ID field. If the EID HMAC ID field does not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply and send, at the first opportunity it needs to, a new Map-Request with a different Requested HMAC ID field, according to ITR’s local policy. The ITR MUST set the EID HMAC ID field to 0 before computing the HMAC.

To verify the integrity of the PKT-AD, first the MS-OTK is derived from the locally stored ITR-OTK using the algorithm specified in the KDF ID field. This is because the PKT-AD is generated by the ETR using the MS-OTK. If the KDF ID in the Map-Reply does not match the KDF ID requested in the Map-Request, the ITR SHOULD discard the Map- Reply and send, at the first opportunity it needs to, a new Map- Request with a different KDF ID, according to ITR’s local policy. The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD using the Algorithm specified in the PKT HMAC ID field. If the PKT HMAC ID field does not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply and send, at the first opportunity it needs to, a new Map-Request with a different Requested HMAC ID according to ITR’s local policy.

Each individual Map-Reply EID-record is considered valid only if: (1) both EID-AD and PKT-AD are valid, and (2) the intersection of the EID-prefix in the Map-Reply EID-record with one of the EID-prefixes



contained in the EID-AD is not empty. After identifying the Map- Reply record as valid, the ITR sets the EID-prefix in the Map-Reply record to the value of the intersection set computed before, and adds the Map-Reply EID-record to its EID-to-RLOC cache, as described in [I-D.ietf-lisp]. An example of Map-Reply record validation is provided in Section 5.3.1.

The ITR SHOULD send SMR triggered Map Requests over the mapping system in order to receive a secure Map-Reply. If an ITR accepts piggybacked Map-Replies, it SHOULD also send a Map-Request over the mapping system in order to securely verify the piggybacked Map-Reply.

5.3.1. Map-Reply Record Validation

The payload of a Map-Reply may contain multiple EID-records. The whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide integrity protection and origin authentication to the EID-prefix records claimed by the ETR. The Authentication Data field of a Map- Reply may contain multiple EID-records in the EID-AD. The EID-AD is signed by the Map-Server, with the EID HMAC, to provide integrity protection and origin authentication to the EID-prefix records inserted by the Map-Server.

Upon receiving a Map-Reply with the S-bit set, the ITR first checks the validity of both the EID HMAC and of the PKT-AD HMAC. If either one of the HMACs is not valid, a log message is issued and the Map- Reply is not processed any further. If both HMACs are valid, the ITR proceeds with validating each individual EID-record claimed by the ETR by computing the intersection of each one of the EID-prefix contained in the payload of the Map-Reply with each one of the EID- prefixes contained in the EID-AD. An EID-record is valid only if at least one of the intersections is not the empty set.

For instance, the Map-Reply payload contains 3 mapping record EID- prefixes:

1.1.1.0/24

1.1.2.0/24

1.2.0.0/16

The EID-AD contains two EID-prefixes:

1.1.2.0/24

1.2.3.0/24



The EID-record with EID-prefix 1.1.1.0/24 is not processed since it is not included in any of the EID-ADs signed by the Map-Server. A log message is issued.

The EID-record with EID-prefix 1.1.2.0/24 is stored in the map-cache because it matches the second EID-prefix contained in the EID-AD.

The EID-record with EID-prefix 1.2.0.0/16 is not processed since it is not included in any of the EID-ADs signed by the Map-Server. A log message is issued. In this last example the ETR is trying to over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized only 1.2.3.0/24, hence the EID-record is discarded.

5.3.2. PITR Processing

The processing performed by a PITR is equivalent to the processing of an ITR. However, if the PITR is directly connected to the ALT, the PITR performs the functions of both the ITR and the Map-Resolver forwarding the Map-Request encapsulated in an ECM header that includes the Authentication Data fields as described in Section 5.5.

5.4. Encrypting and Decrypting an OTK

MS-OTK confidentiality is required in the path between the Map-Server and the ETR, the MS-OTK SHOULD be encrypted using the preconfigured key shared between the Map-Server and the ETR for the purpose of securing ETR registration [I-D.ietf-lisp-ms]. Similarly, if ITR-OTK confidentiality is required in the path between the ITR and the Map- Resolver, the ITR-OTK SHOULD be encrypted with a key shared between the ITR and the Map-Resolver.

The OTK is encrypted using the algorithm specified in the OTK Encryption ID field. When the AES Key Wrap algorithm is used to encrypt a 128-bit OTK, according to [RFC3339], the AES Key Wrap Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). The output of the AES Key Wrap operation is 192-bit long. The most significant 64-bit are copied in the One-Time Key Preamble field, while the 128 less significant bits are copied in the One-Time Key field of the LISP-SEC Authentication Data.

When decrypting an encrypted OTK the receiver MUST verify that the Initialization Value resulting from the AES Key Wrap decryption operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails the receiver MUST discard the entire message.

When a 128-bit OTK is sent unencrypted the OTK Encryption ID is set to NULL_KEY_WRAP_128, and the OTK Preamble is set to 0x0000000000000000 (64 bits).



5.5. Map-Resolver Processing

Upon receiving an encapsulated Map-Request with the S-bit set, the Map-Resolver decapsulates the ECM message. The ITR-OTK, if encrypted, is decrypted as specified in Section 5.4.

The Map-Resolver, as specified in [I-D.ietf-lisp-ms], originates a new ECM header with the S-bit set, that contains the unencrypted ITR- OTK, as specified in Section 5.4, and the other data derived from the ECM Authentication Data of the received encapsulated Map-Request.

The Map-Resolver then forwards the received Map-Request, encapsulated in the new ECM header that includes the newly computed Authentication Data fields.

5.6. Map-Server Processing

Upon receiving an ECM encapsulated Map-Request with the S-bit set, the Map-Server process the Map-Request according to the value of the S-bit contained in the Map-Register sent by the ETR during registration.

If the S-bit contained in the Map-Register was clear the Map-Server decapsulates the ECM and generates a new ECM encapsulated Map-Request that does not contain an ECM Authentication Data, as specified in [I-D.ietf-lisp]. The Map-Server does not perform any further LISP- SEC processing.

If the S-bit contained in the Map-Register was set the Map-Server decapsulates the ECM and generates a new ECM Authentication Data. The Authentication Data includes the OTK-AD and the EID-AD, that contains EID-prefix authorization information, that are ultimately sent to the requesting ITR.

The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from the ITR-OTK received with the Map-Request. MS-OTK is derived applying the key derivation function specified in the KDF ID field. If the algorithm specified in the KDF ID field is not supported, the Map-Server uses a different algorithm to derive the key and updates the KDF ID field accordingly.

The Map-Server and the ETR MUST be configured with a shared key for mapping registration according to [I-D.ietf-lisp-ms]. If MS-OTK confidentiality is required, then the MS-OTK SHOULD be encrypted, by wrapping the MS-OTK with the algorithm specified by the OTK Encryption ID field as specified in Section 5.4.

The Map-Server includes in the EID-AD the longest match registered



EID-prefix for the destination EID, and an HMAC of this EID-prefix. The HMAC is keyed with the ITR-OTK contained in the received ECM Authentication Data, and the HMAC algorithm is chosen according to the Requested HMAC ID field. If The Map-Server does not support this algorithm, the Map-Server uses a different algorithm and specifies it in the EID HMAC ID field. The scope of the HMAC operation covers the entire EID-AD, from the EID-AD Length field to the EID HMAC field, which must be set to 0 before the computation.

The Map-Server then forwards the updated ECM encapsulated Map- Request, that contains the OTK-AD, the EID-AD, and the received Map- Request to an authoritative ETR as specified in [I-D.ietf-lisp].

5.6.1. Map-Server Processing in Proxy mode

If the Map-Server is in proxy mode, it generates a Map-Reply, as specified in [I-D.ietf-lisp], with the S-bit set to 1. The Map-Reply includes the Authentication Data that contains the EID-AD, computed as specified in Section 5.6, as well as the PKT-AD computed as specified in Section 5.7.

5.7. ETR Processing

Upon receiving an encapsulated Map-Request with the S-bit set, the ETR decapsulates the ECM message. The OTK field, if encrypted, is decrypted as specified in Section 5.4 to obtain the unencrypted MS- OTK.

The ETR then generates a Map-Reply as specified in [I-D.ietf-lisp] and includes an Authentication Data that contains the EID-AD, as received in the encapsulated Map-Request, as well as the PKT-AD.

The EID-AD is copied from the Authentication Data of the received encapsulated Map-Request.

The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed with the MS-OTK and computed using the HMAC algorithm specified in the Requested HMAC ID field of the received encapsulated Map-Request. If the ETR does not support the Requested HMAC ID, it uses a different algorithm and updates the PKT HMAC ID field accordingly. The scope of the HMAC operation covers the entire PKT-AD, from the Map-Reply Type field to the PKT HMAC field, which must be set to 0 before the computation.

Finally the ETR sends the Map-Reply to the requesting ITR as specified in [I-D.ietf-lisp].




6.1. Mapping System Security

The LISP-SEC threat model described in Section 3, assumes that the LISP Mapping System is working properly and eventually delivers Map- Request messages to a Map-Server that is authoritative for the requested EID.

Security is not yet embedded in LISP+ALT but BGP route filtering SHOULD be deployed in the ALT infrastructure to enforce proper routing in the mapping system. The SIDR working group is currently addressing prefix and route advertisement authorization and authentication for BGP. While following SIDR recommendations in the global Internet will take time, applying these recommendations to the ALT, which relies on BGP, should be less complex, as ALT is currently small and with a limited number of operators. Ultimately, deploying the SIDR recommendations in ALT further ensures that the fore mentioned assumption is true.

It is also assumed that no man-in-the-middle attack can be carried out against the ALT router to ALT router tunnels, and that the information included into the Map-Requests, in particular the OTK, cannot be read by third-party entities. It should be noted that the integrity of the Map-Request in the ALT is protected by BGP authentication, and that in order to provide OTK confidentiality in the ALT mapping system the ALT router to ALT router tunnels MAY be deployed using IPsec (ESP).

Map-Register security, including the right for a LISP entity to register an EID-prefix or to claim presence at an RLOC, is out of the scope of LISP-SEC.

6.2. Random Number Generation

The ITR-OTK MUST be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security-sensitive random data

6.3. Map-Server and ETR Colocation

If the Map-Server and the ETR are colocated, LISP-SEC does not provide protection from overclaiming attacks mounted by the ETR. However, in this particular case, since the ETR is within the trust boundaries of the Map-Server, ETR’s overclaiming attacks are not included in the threat model.




7.1. HMAC functions

The following HMAC ID values are defined by this memo for use as Requested HMAC ID, EID HMAC ID, and PKT HMAC ID in the LISP-SEC Authentication Data:

Name Number Defined In ------------------------------------------------- NONE 0 AUTH-HMAC-SHA-1-96 1 [RFC2104] AUTH-HMAC-SHA-256-128 2 [RFC4634]

values 2-65535 are reserved to IANA.

HMAC Functions

AUTH-HMAC-SHA-1-96 MUST be supported, AUTH-HMAC-SHA-256-128 should be supported.

7.2. Key Wrap Functions

The following OTK Encryption ID values are defined by this memo for use as OTK key wrap algorithms ID in the LISP-SEC Authentication Data:

Name Number Defined In ------------------------------------------------- NULL-KEY-WRAP-128 1 AES-KEY-WRAP-128 2 [RFC3394]

values 0 and 3-65535 are reserved to IANA.

Key Wrap Functions

NULL-KEY-WRAP-128, and AES-KEY-WRAP-128 MUST be supported.

NULL-KEY-WRAP-128 is used to carry an unencrypted 128-bit OTK, with a 64-bit preamble set to 0x0000000000000000 (64 bits).

7.3. Key Derivation Functions

The following KDF ID values are defined by this memo for use as KDF ID in the LISP-SEC Authentication Data:



Name Number Defined In ------------------------------------------------- NONE 0 HKDF-SHA1-128 1 [RFC5869]

values 2-65535 are reserved to IANA.

Key Derivation Functions

HKDF-SHA1-128 MUST be supported

8. Acknowledgements

The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt Noll for their valuable suggestions provided during the preparation of this document.

9. Normative References

[I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-18 (work in progress), December 2011.


[I-D.ietf-lisp-ms] Fuller, V. and D. Farinacci, "LISP Map Server Interface", draft-ietf-lisp-ms-14 (work in progress), December 2011.

[I-D.ietf-lisp-threats] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Analysis", draft-ietf-lisp-threats-00 (work in progress), July 2011.





[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.

[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010.


Fabio Maino Cisco Systems 170 Tasman Drive San Jose, California 95134 USA


Vina Ermagan Cisco Systems 170 Tasman Drive San Jose, California 95134 USA


Albert Cabellos Technical University of Catalonia c/ Jordi Girona s/n Barcelona, 08034 Spain




Damien Saucez Universite catholique de Louvain Place St. Barbe 2 Louvain-la-Neuve, Belgium


Olivier Bonaventure Universite catholique de Louvain Place St. Barbe 2 Louvain-la-Neuve, Belgium



This Internet-Draft, draft-ietf-lisp-threats-00.txt, has expired, and hasbeen deleted from the Internet-Drafts directory. An Internet-Draftexpires 185 days from the date that it is posted unless it is replaced byan updated version, or the Secretariat has been notified that thedocument is under official review by the IESG or has been passed to theRFC Editor for review and/or publication as an RFC. This Internet-Draftwas not published as an RFC.

Internet-Drafts are not archival documents, and copies of Internet-Draftsthat have been deleted from the directory are not available. TheSecretariat does not have any information regarding the future plans ofthe authors or working group, if applicable, with respect to this deletedInternet-Draft. For more information, or to request a copy of thedocument, please contact the authors directly.

Draft Authors:Damien Saucez<[email protected]>Luigi Iannone<[email protected]>Olivier Bonaventure<[email protected]>

Network Working Group G. Wiley, Ed.Internet-Draft Verisign, Inc.Intended status: Experimental March 12, 2012Expires: September 13, 2012

LISP-DDT Database Transfer draft-wiley-lisp-ddtxfer-01

Abstract

This draft describes a protocol for transferring a LISP Delegated Database Tree (LISP-DDT) between DDT nodes and for notifying DDT nodes that the database has changed. In the absence of a formally defined protocol the LISP-DDT database is transferred using files containing device configuration commands. This protocol provides for transferring a complete database or the deltas between two versions of the database. This document does not describe the use of DDT as part of the LISP mapping service.

Status of this Memo





Copyright Notice



Wiley Expires September 13, 2012 [Page 1]

Internet-Draft LISP DDT Database Transfer March 2012


1. Introduction

References to the LISP-DDT database in this document are intended to refer specifically to the portion of the LISP-DDT database that has been delegated to the DDT node, not the entire database.

An operator that offers a LISP-DDT service faces a few problems (similar to those faces by the operator of a DNS resolution service):

o How to replicate the LISP-DDT database from one host/device to another to support redundant platforms or to support operational maintenance.

o Transfering the LISP-DDT between dissimilar platforms, for example between network devices offered by competing network device vendors that rely on different configuration commands.

o How to transfer portions of the LISP-DDT database rather than the entire database (to deal with the eventual large database).

o How to notify an interested DDT node that the LISP-DDT database has changed

The focus for this document is to define a protocol for the transfer of the LISP-DDT database between DDT XFR nodes that addresses these problems. The local representation of the data in the LISP-DDT database on the DDT node is outside the scope of this document.

In the absence of a well described line protocol an operator might send a list of OS commands to run on the DDT node that would populate the LISP DDT database, however even this approach requires an operational protocol to ensure a reliable/repeatable transfer of the LISP DDT database.

There are two types of transfers, both are limited to only the portion of the database that has been delegated to the DDT node. A full transfer sends the entire set of entries in the database for which the DDT node is authoritative. An incremental transfer sends only the portion of that set of entries in the database that has changed (based on the version of the database on the receiving node).

LISP-DDT bears some resemblance to the Domain Name Service (DNS) in the sense that it provides an indirect vector to the target data.



Think of a LISP-DDT query as the analog to a DNS name server (NS) query, and a LISP map request as the analog to a DNS address (A) query (LISP-DDT does not store the EID to RLOC mappings returned in a map request).

DDT XFR clients that need to be notified of changes to the DDT database may subscribe to the appropriate DDT XFR server and are asynchronously notified of changes. A DDT XFR client always initiates a transfer by sending a request to the authoritative DDT XFR server.

LISP-DDT database transfer introduces the use of a monotonically increasing 64-bit serial number that identifies a version of a portion of a LISP-DDT database. Each delegated portion of the database (identified by a unique Extended EID-prefix) has a distinct serial number which is maintained by the authoritative DDT XFR server. One or more changes to the contents of the LISP-DDT database increments the serial number. Once a serial number is used it may never be reused. This feature ensures that a DDT XFR client can reliably determine whether its copy of the LISP-DDT database is consistent with the one offered by the DDT XFR server. This serial number is analogous to the DNS SOA serial number.

1.1. LISP-DDT

LISP-DDT defines a database key for identifying EID mappings to RLOCs in the EID numbering space. This key (the Extended EID prefix) is comprised of the following fields:

+---------------------------------+-------------------------+ | Field | Size | +---------------------------------+-------------------------+ | Key-ID | 16 bits | | Instance Identifier (IID) | 32 bits | | Address Family Identifier (AFI) | 16 bits | | EID-prefix | variable length per AFI | +---------------------------------+-------------------------+

See [LISP-DDT] for a more complete discussion of the key fields.

The root DDT XFR server is the apex of the hierarchy and is identified by the key: Key-ID=0, IID=0, AFI=0, EID-prefix=0/0

It is useful to note that a DDT node does not necessarily imply a single host, in fact it is more likely implemented as a collection of hosts operating behind a VIP or via some other mechanism that allows for active redundant components.



1.2. Network Transport

TCP is used exclusively as the transport for LISP-DDT transfer sessions as opposed to other LISP messages which are sent via UDP.

1.3. Terminology

Note that for the sake of consistency many of these definitions were lifted directly from [LISP-DDT].

Extended EID (XEID): a LISP EID, optionally extended with a non- zero Instance ID (IID) if the EID is intended for use in a context where it may not be a unique value, such as on a Virtual Private Network where "private" address space is used. See "Using Virtualization and Segmentation with LISP" in [LISP] for more discussion of Instance IDs.

XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT Key-ID (provided to allow the definition of multiple databases; currently always zero in this version of DDT, with other values reserved for future use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used as a key index into the database.


Authoritative DDT node: The DDT map server that is authoritative for a portion of the LISP-DDT database is identified as an "authoritative DDT node/server" and is the exclusive source for an authoritative copy of the portion of the LISP-DDT database that has been delegated to that DDT map server.

DDT XFR client: The DDT node that is requesting a LISP-DDT database transfer from a DDT XFER server. A DDT XFR client would likely be a device/host that may serve as a DDT server following the transfer.

DDT XFR server: The DDT node that receives a request for a LISP-DDT database transfer and functions as the source of the LISP-DDT database is the DDT XFR server. DDT XFR servers never initiate a transfer, however they may send notification messages to DDT XFR clients that have subscribed to the portion of the database for which the DDT server is authoritative.



Full Transfer: A full LISP-DDT database transfer (FDDTXFR) describes the transfer of the entire portion of the LISP-DDT database for which a DDT-node is authoritative. The transfer does not include portions of the database that are delegated to other DDT nodes.

Incremental Transfer: An incremental LISP-DDT database transfer (IDDTXFR) is a transfer of the differences between two serial numbers of the LISP-DDT database for which a DDT XFR server is authoritative. The current serial number and the serial number provided by the DDT XFR client determine the context of the differences.

serial number: A monotonically increasing number that indicates a specific version of the portion of the LISP-DDT database identified by a unique Extended EID-prefix. There may be more than one material difference between versions of the database even though the serial number is incremented once.

session: A LISP-DDT database transfer session ("session") includes all communication between the DDT XFR client and DDT XFR server involved in requesting and responding to a request for the transfer of a portion of the LISP-DDT database.

For definitions of other acronyms (EID, RLOC, etc.) see [LISP] and [LISP-DDT].

1.4. Requirements Language

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 RFC 2119 [RFC2119].

2. LISP-DDT Database Transfer Request

Immediately after the network connection is established from a DDT XFR client to a DDT XFR server the DDT XFR client sends a transfer request message. The LISP-DDT transfer message is very similar to the LISP Map-Request.



0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=9 |F|I|N| Reserved | EID mask-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Key ID | MAC Digest Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ˜ MAC Digest Data ˜ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial number . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Serial number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key-ID | Instance Identifier ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Instance Identifier | Address Family Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EID-prefix . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . EID-prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LISP-DDT Transfer Request Message Format

Packet field descriptions:

Type=9: DDT Transfer request, this four bit value identifies the packet type (other LISP packet types are defined in the respective Internet Drafts).

F (bit flag): If this bit is set then this is a full transfer request.

I (bit flag): If this bit is set then this is an incremental transfer request.

N (bit flag): If this bit is set then this is a notification that the serial number for the portion of the database identified by the Extended EID has changed.

EID mask-len: The EID mask length (in bits) of the EID-prefix, not including the three fields that prefix the EID-prefix.



MAC Key ID: Identifies the Message Authentication Code (MAC) digest algorithm per [LISP].

MAC Digest length: Length in bytes of the following MAC digest data.

MAC Digest Data: The MAC digest data depends on the MAC Key ID specified and is calculated on all of the fields that follow in this message.

Serial number: In the case of an incremental transfer the DDT XFR client populates this 64-bit value with the current serial number so that the DDT XFR server can attempt to determine which database changes must be sent. This field is ignored for full transfers.

Key-ID: 16 bit Key-ID for the X-EID prefix being requested.

Instance Identifier: 32 bit Instance Identifier for the X-EID prefix being requested.

AFI: 16 bit Address Family Identifier for the X-EID prefix being requested.

EID-prefix: The variable length EID-prefix (per AFI) for the XEID prefix being requested. This length is also available in the header of the packet.

3. Full LISP-DDT Database Transfer

A full LISP-DDT database transfer is initiated by a DDT XFR client as a FDDTXFR request sent to a DDT XFR server. A DDT XFR server may choose to ignore full transfer requests received from the same DDT XFR client more than once in a 12 hour period.

This request is answered by successive DDTDAT messages until the entire portion of the database is sent from the DDT XFR server.

4. Incremental LISP-DDT Database Transfer

An incremental LISP-DDT database transfer is initiated by a DDT XFR client as a IDDTXFER request sent to a DDT XFR server. The DDT XFR client specifies a serial number which is used by the DDT XFR server to determine which changes must be sent in the reply.

The DDT XFR server should respond to the IDDTXFER request with an IDDTXFER reply that includes only the changes between the specified serial number and the current serial number. The DDT XFR server may



choose to respond with an FDDTXFER reply if the changes between the serial numbers are no longer available to the DDT XFR server.

The DDT XFR client must be prepared to receive an FDDTXFER reply in response to a IDDTXFER request.

5. LISP-DDT Transfer Data Message

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=11|F|I|H|N| Reserved | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | MAC Key ID | MAC Digest Length | H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ˜ MAC Digest Data ˜ b +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i | Initial Serial number . . . | t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Initial Serial number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Current Serial number . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Current Serial number | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |A|R|L|Reserved | Record TTL . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R |...Record TTL | Locator Count | EID mask-len | DB Key-ID... | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | ...DB Key-ID | Instance Identifier . . . | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r |...Instance ID | EID-AFI | Reserved | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | EID-prefix . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o| Unused Flags |R| Loc-AFI | | c+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator ... | +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LISP-DDT Transfer Data Message Format

Packet field descriptions are identical to those for the LISP Map



Reply, new fields are described below:

Type=11: DDT Transfer Data Message, this four bit value identifies the packet type (other LISP packet types are defined in the respective Internet Drafts).

F (bit flag): If this bit is set then this is a response to a full transfer request.

I (bit flag): If this bit is set then this is a response to an incremental transfer request.

H (bit flag): If this bit is set then the data header is included in the message. This header includes the message digest and serial numbers of the versions of the database. The header typically is included only in the first data message sent in response to a request.

N (bit flag): NXDB, this bit is set in a response if the portion of the database requested is not delegated to the DDT XFR server responding to the request. If this bit is set then the Extended EID-prefix is populated with the values specified in the original request.

MAC Key ID: Identifies the Message Authentication Code (MAC) digest algorithm per [LISP].

MAC Digest length: Length in bytes of the following MAC digest data.

MAC Digest Data: The MAC digest data depends on the MAC Key ID specified and is calculated on all of the fields that follow in this message.

Initial Serial number: In an IDDTXFER reply, the initial serial number is the serial number specified in the IDDTXFER request provided that serial number was used to generate the changes specified in the data messages. In a FDDTXFER request or in the case that the DDT XFR server could not determine the changes between the specified and current serial numbers then this field is filled with 0’s. If the H bit is not set then this serial number is not present and the Extended EID prefix begins at this location in the packet.

Current Serial number: In both the IDDTXFER and FDDTXFER reply, the current serial number is provided in this field. If the H bit is not set then this serial number is not present.



A (bit flag): For incremental transfers this bit is set to indicate that the Extended EID prefix is to be added to the database. If this bit is not set then the Extended EID prefix is to be removed from the database. In cases where the Extended EID prefix is duplicated by the add, the record is replaced in the database.

R (bit flag): For incremental transfers this bit is set to indicate that the Extended EID prefix is to be removed from the database. The A and R bits are mutually exclusive.

L (bit flag): This bit is set only in the last record of the DDTXFER reply to indicate that no more records follow.

6. LISP-DDT Database Transfer Notify

A DDT XFR server maintains a list of DDT XFR clients that have subscribed to the portion of the LISP-DDT database tree delegated to that DDT XFR server. A DDT XFR client subscribes to a DDT XFR server by communicating with the DDT XFR server operator who then configures the DDT XFR server to send notifications. When the DDT XFR server increments the serial number for the delegated portion of the database, all DDT XFR clients are notified of the change via a DDTNTFY message which is identical to a DDTXFER request message with the N bit set.

Notifications are sent to DDT XFR clients within five minutes of the change to the serial number. A DDT XFR server may choose to only send the most recent/current serial number rather than all of the serial numbers that were used between notifications to a DDT XFR client.

Notifications are delivered via a reliable transport (TCP) and the DDT XFR server must attempt to connect with the DDT XFR client and send the notification at least three times within a three minute window no more frequently than once per minute. The DDT XFR server may choose a higher number of attempts at sending the notification, but not more frequently than once per minute.

7. Acknowledgments

Special thanks to folks that offered their considerable experience in building and operating large scale DNS platforms and helping translate this experience to LISP-DDT database transfers including Dave Blacka, Piet Barber and Sean Mountcastle. I also appreciate the time that Neel Goyal and Ramin Ali Dousti have put into this effort.




This memo includes no request to IANA.


There are a few Security considerations specific to LISP-DDT Database Transfers that are incremental to the LISP-DDT specification. Most of the security related requirements are satisfied by the use of TLS. Although TLS as described in RFC 5246 [RFC5246] is intended to be transparent to the application protocol, certain details should be addressed to ensure consistent implementation of LISP-DDT Transfer. These details are addressed in a separate document.

Two of the approaches to implementing security related features in the protocol are to offer the secure service on an alternate port or to allow session endpoints to upgrade an existing session via TLS.

The preferred approach to securing LISP-DDT Transfer is to offer the secure service on an alternate port from the "un-secure" service. The primary motivation for this approach is to improve operational efficiency, for example this makes it easier to deploy a footprint that efficiently allocates hardware used to accelerate TLS termination.

An alternative to offering the secure service on an different network port is to support session upgrades. In this case either endpoint of a LISP-DDT transfer session may upgrade that session via TLS similar to the approach taken to upgrade an HTTP session via TLS as described in RFC 2817 [RFC2817].

The use of TLS provides for the three primary security considerations:

o Host authentication, both DDT XFR server and DDT XFR client can be reasonably confident of the identity of the other endpoint.

o Transfer integrity, the contents of the transfer can be reasonably assured to be unadulterated. The use of a message digest as is currently specified for the protocol affords message integrity as well.

o Transfer confidentiality, the contents of the transfer will be essentially opaque to hosts outside the session.

10. References




[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP), draft-ietf-lisp-22.txt", February 2012.

[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface, draft-ietf-lisp-ms-12.txt (work in progress)", October 2011.


[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.


[LISP-DDT] Fuller, V., "LISP Delegated Database Tree, draft-ietf-lisp-ddt-01.txt (work in progress)", October 2011.

Appendix A. Open Issues

o A subscription message to manage DDT XFR client subscriptions to DDT XFR servers for portions of the database would be very useful. This requires a robust mechanism for authenticating subscribe/ unsubscribe requests as part of the application protocol rather than relying entirely on TLS.

o Compression should be included in the specification as an optional feature. This will become more important as LISP is more widely adopted and the size of the LISP-DDT increases.

o Do we need to support some sort of discovery protocol, for example should a DDT XFR client be able to not specify some portion of the extended EID prefix so that a DDT XFR server can reply with a "default" database or offer some means to walk the portion of the tree delegated to the DDT XFR server?



Author’s Address

Glen Wiley (editor) Verisign, Inc. 12061 Bluemont Way Reston, Va 20190 USA

Phone: Email: [email protected]
