Network Working Group D. Saucez Internet-Draft O. Bonaventure Intended status: Informational Universite catholique de Louvain Expires: October 23, 2011 April 21, 2011 LISP Iterable Mappings draft-saucez-lisp-iterable-mapping-02 Abstract The Mapping System is a key component of the Locator Identifier Separation Protocol (LISP). In this document, we describe Iterable Mappings allowing the mappings to point to Map-Server addresses instead of ETR addresses. Iterable mappings open the possibility of performing iterative queries that could be used to deploy mapping systems without requiring overlays or to optimize current mapping systems. 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 October 23, 2011. Copyright Notice Copyright (c) 2011 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 (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 Saucez & Bonaventure Expires October 23, 2011 [Page 1] Internet-Draft LISP Iterable Mappings April 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Additional LISP Packet Type Allocation . . . . . . . . . . . . 7 3. Extension to Map-Request Message Format . . . . . . . . . . . 7 4. Iterable-Mapping Message Format . . . . . . . . . . . . . . . 8 5. Message Processing . . . . . . . . . . . . . . . . . . . . . . 9 6. Map-Server Deployment and Adaptations . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Informative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Saucez & Bonaventure Expires October 23, 2011 [Page 2] Internet-Draft LISP Iterable Mappings April 2011 1. Introduction LISP Mapping systems can be decomposed in three components: the querier, the resolver and the server. First, the querier initiates a request for a mapping resolution by querying a resolver. Second, the resolver sends a Map-Request to a server. Third, the server returns a Map-Reply containing the mapping to the resolver. The Map-Reply gives the mapping for the identifier present in the Map-Request. Finally, the resolver can return the mapping to the requester. Depending on the mapping system, there can exist intermediate elements between the resolver and the server. It is also possible to have redundant resolvers or servers. When the querier is not able to send the Map-Request directly to a server that can provide a mapping for the identifier in the request, the Map-Request must be transmitted to intermediate elements. Three options can be followed to transmit Map-Request when going through intermediate elements: o Forwardable queries: when an intermediate element receives a Map- Request, it transmits it as-is to another intermediate element that, at its turn, transmits the Map-Request to another intermediate element and so on until the Map-Request can be transmitted to the server. o Recursive queries: when an intermediate element receives a Map- Request, it interprets the Map-Request and acts as a resolver. It then generates a new Map-Request and sends it to another intermediate element, and so on until the server is reached. o Iterative queries: when an intermediate element receives a Map- Request, it sends back the address of the next intermediate element to the resolver. The resolver then sends the Map-Request to this other intermediate element until a server is reached. A mapping system working with forwardable queries can be seen as a routing overlay. The intermediate elements are overlay routers that forward Map-Request messages step by step on the overlay to reach a server that can provide a mapping for the identifier in the Map- Request. LISP+ALT [I-D.ietf-lisp-alt] is an example of such mapping system. The figure below presents an example of messages exchanged in LISP+ ALT. In LISP+ALT, the ITRs are at the same time the queriers and the resolvers (an ITR is its own resolver). Labels postfixed by a ? represent Map-Requests and those postfixed with a ! are the Map- Replies. Intermediate elements are operated by ALT routers (depicted as ALTx in the figure) and the server role is supported by the ETRs. Saucez & Bonaventure Expires October 23, 2011 [Page 3] Internet-Draft LISP Iterable Mappings April 2011 The figure shows that messages are sent step-by-step through the ALT routers until an ETR that can return a mapping is reached. The ETR directly returns the mapping to the ITR without traversing the ALT routers. We can see that troubleshoot a problem occurring at an ALT router is an issue for the ITR as it does not control the ALT routers the Map-Request traverses. In addition, the ITRs do not even know the ALT routers that are traversed. e + 1.(ITR, e)? 2.(ITR,e)? 3.(ITR,e)? + ITR ---------------> ALT1 ----------------> ALT2 --------------->ETR --. ^ | | 4.(R,e)! | `<--------------------------------------------------------------------' LEGEND: (x,e)?: Map-Request sent by x for EID e (x,e)!: Map-Reply sent to x with the mapping for EID e ALTx: ALT router Figure 1: Example of message exchanged in a forwarding mode mapping system: the LISP+ALT case The operation of mapping systems working in recursive mode can be abstracted as a directed graph of resolvers, each node being a resolver for its predecessor. The figure below shows that when an intermediate element receives a Map-Request, it originates a new Map- Request for the same EID. When the server receives the request, it replies to the intermediate element that, at its turn can return a reply to the node that it receives a request from and so on until the mapping arrives the resolver. In the figure, we omitted the requester to start directly at the resolver (R). e + 1.(R,e)? 2.(I1,e)? 3.(I2,e)? + R -------------> I1 --------------> I2 -------------> ETR --. ^ |^ |^ | | 6.(R,e)! || 5.(I1,e)! || 4.(I2,e)! | `<---------------'`<----------------'`<---------------------' LEGEND: (x,e)?: Map-Request sent by x for EID e (x,e)!: Map-Reply sent to x with the mapping for EID e R: resolver Ix: intermediate element x Figure 2: Example of message exchanged in a recursive mapping system Saucez & Bonaventure Expires October 23, 2011 [Page 4] Internet-Draft LISP Iterable Mappings April 2011 In mapping systems operating in iterative mode, the intermediate elements do not exchange requests among themselves. As presented in the figure below, when an intermediate element receives a request, it replies with the address of another intermediate element that can potentially provide the mapping (labels postfixed with a @). When the resolver receives this address, it sends it a Map-Request for the identifier. This operation is repeated until a server is reached. At a first glance, the iterative mode is the option that is likely to present the longer delay. However, the resolver can cache the intermediate elements and servers and for any subsequent Map-Request, it can directly contact the server or intermediate element close to the server. .----. e | | + | \/ 1.(R,e)? + | ,.R -------------> I1 I2 ETR-. | |^|^ | ^| ^ | | |||| 2(e,I2)@ | || | | | |||`<--------------' 3.(R,e)? || | | | ||`-----------------------------------'| | | | || | | | | || 4.(e,S)@ | | | | |`<------------------------------------' 5.(R,e)? | | | `------------------------------------------------------>' | | | | 6.(R,e)! | `<-----------------------------------------------------------' LEGEND: (x,e)?: Map-Request sent by x for EID e (x,e)!: Map-Reply sent to x with the mapping for EID e (e,x)@: the Map-Request for EID e has to be sent to x R: resolver Ix: intermediate element Figure 3: Example of messages exchanged in an iterative mapping system An advantage of using the iterative mode is for the troubleshooting. The figure below presents a case where the intermediate element I2 is replicated with intermediate element I2'. The resolver first tries to contact I2, but as no answer arrives within a given time frame, it contacts the replicas I2' instead. Similar troubleshooting exists in recursive mode but the recovery is done locally at the intermediate element suppressing any control from the resolver. In forwarding mode, and particularly in LISP+ALT, the troubleshooting is performed locally but relies on the routing layer. Therefore, if an Saucez & Bonaventure Expires October 23, 2011 [Page 5] Internet-Draft LISP Iterable Mappings April 2011 intermediate element is overloaded but present on the network, i.e., the routing layer does not detect any failure, requests will continue to be forwarded to the overloaded intermediate element. .----. e | | + | \/ 1.(R,e)? + | ,,.R ----------------> I1 I2 I2' ETR-. | ||||^ | ^| | | | ||||| 2(e,[I2,I2'])@ | X || | | | ||||`<------------------' 3.(R,e)? | || | | | |||`---------------------------------->' || | | | ||| || | | | ||| 4.(R,e)? || | | | ||`---------------------------------------------->'| | | | || | | | | || 5.(e,S)@ | | | | ||`<-----------------------------------------------' | | | | | | | | 6.(R,e)? | | | `----------------------------------------------------->' | | | | 7.(R,e)! | `<----------------------------------------------------------' LEGEND: (x,e)?: Map-Request sent by x for EID e (x,e)!: Map-Reply sent to x with the mapping for EID e (e,[x,y])@: the Map-Request for EID e has to be sent to x or y R: resolver Ix: intermediate node Figure 4: Intermediate node failure troubleshooting example with the iterative mode The analogy can be done with DNS that supports both iterative and recursive modes. Experience with the DNS on the Internet showed that using redundant servers coupled with iterative mode has been key in handling various types of failures. This memo presents the new Iterable-Mapping LISP message. We also propose a one bit modification of the Map-Request for supporting the iterative mode. Because of security and scalability issues, we do not discuss the recursive mode even if it could be implemented by using our solution. Saucez & Bonaventure Expires October 23, 2011 [Page 6] Internet-Draft LISP Iterable Mappings April 2011 2. Additional LISP Packet Type Allocation Mappings, as defined in the LISP specifications [I-D.ietf-lisp], associate locator lists to EID prefixes. To associate Map-Server addresses to EID, we propose a new LISP control plane message: the LISP Iterable-Mapping. We suggest the following type allocation: LISP Iterable-Reply: 5 b'0101' 3. Extension to Map-Request Message Format To support iterable mappings, we propose to add the I-bit flag in the Map-Request message. When this bit is at 1, the ITR (or the Map- Resolver) indicates that it accepts iterable mappings. If the I-bit is at zero, the ITR (or the Map-Resolver) does not accept iterable mappings meaning that the only acceptable answer to the request is a Map-Reply. 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=1 |A|M|P|S|I| Reserved | IRC | Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-EID-AFI | Source EID Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ITR-RLOC-AFI n | ITR-RLOC Address n ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Reserved | EID mask-len | EID-prefix-AFI | Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ | EID-prefix ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Map-Reply Record ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mapping Protocol Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Saucez & Bonaventure Expires October 23, 2011 [Page 7] Internet-Draft LISP Iterable Mappings April 2011 4. Iterable-Mapping 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=5 | Reserved | Record Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nonce . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . Nonce | +--> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R | Locator Count | EID mask-len | EID-AFI | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c | EID-prefix | o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r L--| Unused Flags | Loc-AFI | d o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c--| Locator | +--> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Type: 5 (Iterable-Reply) Reserved: Set to 0 on transmission and ignored on receipt. Record Count: The number of records in this reply message. A record is comprised of that portion of the packet labeled 'Record' above and occurs the number of times equal to Record count. Nonce: A 64-bit value from the Map-Request is echoed in this Nonce field of the Map-Reply. Record TTL: The time in minutes the recipient of the Iterable- Mapping will store the mapping. If the TTL is 0, the entry SHOULD be removed from the cache immediately. If the value is 0xffffffff, the recipient can decide locally how long to store the mapping. Locator Count: The number of Locator entries. A locator entry comprises what is labeled above as 'Loc'. The locator count can be 0 indicating there are no locators for the EID-prefix. Locators are Map-Server addresses. Saucez & Bonaventure Expires October 23, 2011 [Page 8] Internet-Draft LISP Iterable Mappings April 2011 EID mask-len: Mask length for EID prefix. EID-AFI: Address family of EID-prefix according to [RFC5226]. EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 address-family. Loc-AFI: Address family of locator according to [RFC5226]. Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) assigned to a Map-Server. 5. Message Processing When an ITR (or a Map-Resolver) needs to retrieve a Mapping for an EID, it sends a Map-Request as specified in the LISP specifications [I-D.ietf-lisp]. If the ITR (or Map-Resolver) desires to operate in the iterable mode, it sends the Map-Request with the I-bit set to one. When the Map-Request is processed, two possible replies are possible, either a Map-Reply or an Iterable-Mapping. A Map-Reply is returned if the node that processed the Map-Request has a mapping for the EID in the Map-Request. If the node knows a list of Map-Servers associated to the requested EID, an Iterable-Mapping is returned. When an Iterable-Mapping arrives the ITR (or Map-Resolver), it extracts one locator. The ITR (or Map-Resolver) then sends a Map- Request to the selected Map-Server and follows the same procedure until a Map-Reply is received. To speed-up further requests, the ITR (or Map-Resolver) can cache the Iterable-Mappings. It is also possible to imagine the ITR (or Map-Resolver) to send the Map-Request to several Map-Server in parallel. 6. Map-Server Deployment and Adaptations With the iterable mappings, it is no longer required to have an overlay deployed to ensure the forwarding. Indeed, one could imagine to have a hierarchy of Map-Server exclusively storing iterable mappings that eventually point to ETRs. Such a general tree-based deployment of EID is presented in LISP-TREE [lisptree] Deploying a mapping system in iterative mode does not require to maintain an overlay with its tunnels (e.g., GRE) and routing scheme (e.g., BGP) making it more flexible, simple and cost effective than LISP+ALT. Saucez & Bonaventure Expires October 23, 2011 [Page 9] Internet-Draft LISP Iterable Mappings April 2011 7. Security Considerations An attacker controlling a Map-Server can provide an iterable mapping pointing to a less specific EID that it should and thus control the mapping to reply for EIDs it is not responsible for. This problem is a variation of the same case for "normal" mappings. Globally, the security issues are not different than those presented in [I-D.saucez-lisp-security]. 8. Conclusion This draft presents the iterable mappings that, at the contrary of "normal" mappings, do not point to ETR RLOCs but to Map-Server RLOCs. The existence of such pointers to Map-Server permit to deploy mapping system relying on iterative querying of Map-Requests. The iterative way of querying the mapping system helps in troubleshooting mapping system failures and can be used to optimize current mapping systems. 9. Acknowledgments This work is partially funded by the European Commission funded ECODE ICT- 223936 project. 10. Informative References [I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-08 (work in progress), August 2010. [I-D.ietf-lisp-alt] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-04 (work in progress), April 2010. [I-D.ietf-lisp-ms] Fuller, V. and D. Farinacci, "LISP Map Server", draft-ietf-lisp-ms-05 (work in progress), April 2010. [I-D.saucez-lisp-security] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Security Threats", draft-saucez-lisp-security-02 (work in progress), January 2011. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an Saucez & Bonaventure Expires October 23, 2011 [Page 10] Internet-Draft LISP Iterable Mappings April 2011 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [lisptree] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System.", JSAC 2010, October 2010. Authors' Addresses Damien Saucez Universite catholique de Louvain Place St. Barbe 2 Louvain-la-Neuve, B-1348 Belgium Email: damien.saucez@uclouvain.be URI: http://inl.info.ucl.ac.be Olivier Bonaventure Universite catholique de Louvain Place St. Barbe 2 Louvain-la-Neuve, B-1348 Belgium Email: olivier.bonaventure@uclouvain.be URI: http://inl.info.ucl.ac.be Saucez & Bonaventure Expires October 23, 2011 [Page 11]