--- 1/draft-ietf-lisp-ddt-01.txt 2014-10-13 14:14:42.362003318 -0700 +++ 2/draft-ietf-lisp-ddt-02.txt 2014-10-13 14:14:42.430004978 -0700 @@ -1,21 +1,22 @@ Network Working Group V. Fuller -Internet-Draft D. Lewis -Intended status: Experimental V. Ermagan -Expires: September 29, 2013 cisco Systems +Internet-Draft +Intended status: Experimental D. Lewis +Expires: April 16, 2015 V. Ermagan + Cisco Systems A. Jain Juniper Networks - March 28, 2013 + October 13, 2014 LISP Delegated Database Tree - draft-ietf-lisp-ddt-01.txt + draft-ietf-lisp-ddt-02.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 @@ -29,25 +30,25 @@ 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 29, 2013. + This Internet-Draft will expire on April 16, 2015. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 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 the Trust Legal Provisions and are provided without warranty as @@ -56,65 +57,65 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Database organization . . . . . . . . . . . . . . . . . . . . 6 3.1. EID-prefix tree structure and instance IDs . . . . . . . 6 3.2. Configuring prefix delegation . . . . . . . . . . . . . . 7 3.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7 4. The Map-Referral message . . . . . . . . . . . . . . . . . . 7 4.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 8 - 4.2. Referral Set . . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 9 5. DDT network elements and their operation . . . . . . . . . . 9 5.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 9 5.1.2. Missing delegation from an authoritative prefix . . . 10 5.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 10 5.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 10 5.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 10 5.3.2. Receiving and following referrals . . . . . . . . . . 11 5.3.3. Handling referral errors . . . . . . . . . . . . . . 13 5.3.4. Referral loop detection . . . . . . . . . . . . . . . 13 - 6. Psuedo Code and Decision Tree diagrams . . . . . . . . . . . 14 + 6. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 14 6.1. Map Resolver processing of ITR Map-Request . . . . . . . 14 6.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 14 6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 14 - 6.2. Map Resolver processing of Map-Referral message . . . . . 16 - 6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 16 - 6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 18 - 6.3. DDT Node processing of DDT Map-Request message . . . . . 20 - 6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 20 - 6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 20 - 7. Example topology and request/referral following . . . . . . . 21 - 7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 23 - 7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . 24 - 7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 25 - 7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . 25 - 7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 . . . . 26 - 8. Securing the database and message exchanges . . . . . . . . . 27 - 8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 27 - 8.2. DDT node operation . . . . . . . . . . . . . . . . . . . 28 - 8.2.1. DDT public key revocation . . . . . . . . . . . . . . 28 - 8.3. Map Server operation . . . . . . . . . . . . . . . . . . 28 - 8.4. Map Resolver operation . . . . . . . . . . . . . . . . . 29 - 9. Open Issues and Considerations . . . . . . . . . . . . . . . 29 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 30 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 12.2. Informative References . . . . . . . . . . . . . . . . . 31 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 - Appendix B. Map-Referral Message Format . . . . . . . . . . . . 32 - B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 34 - Appendix C. Encapsulated Control Message Format . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 + 6.2. Map Resolver processing of Map-Referral message . . . . . 15 + 6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 15 + 6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 17 + 6.3. DDT Node processing of DDT Map-Request message . . . . . 19 + 6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 + 6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 19 + 7. Example topology and request/referral following . . . . . . . 20 + 7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 22 + 7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . 23 + 7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 24 + 7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . 24 + 7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 . . . . 25 + 8. Securing the database and message exchanges . . . . . . . . . 25 + 8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 26 + 8.2. DDT node operation . . . . . . . . . . . . . . . . . . . 26 + 8.2.1. DDT public key revocation . . . . . . . . . . . . . . 27 + 8.3. Map Server operation . . . . . . . . . . . . . . . . . . 27 + 8.4. Map Resolver operation . . . . . . . . . . . . . . . . . 27 + 9. Open Issues and Considerations . . . . . . . . . . . . . . . 28 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 29 + 12.2. Informative References . . . . . . . . . . . . . . . . . 30 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 30 + Appendix B. Map-Referral Message Format . . . . . . . . . . . . 31 + B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 33 + Appendix C. Encapsulated Control Message Format . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction LISP [RFC6830] 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. @@ -149,24 +150,24 @@ 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 [RFC6833] 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. + sub-prefix. See [RFC6833] 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- @@ -225,45 +226,45 @@ 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 [RFC6833]. - 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. + 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 + 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). + 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 @@ -369,21 +370,21 @@ 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 +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 @@ -626,25 +628,25 @@ 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 +6. Pseudo 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. + "pseudo-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 @@ -1332,22 +1331,22 @@ 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 12.1. Normative References [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical - Address Format", draft-ietf-lisp-lcaf-02.txt (work in - progress), March 2013. + Address Format", + . [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. @@ -1359,23 +1358,28 @@ Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013. 12.2. Informative References [LISP-SEC] - Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. - Bonaventure, "LISP-Security", draft-ietf-lisp-sec-04.txt - (work in progress), October 2012. + Maino, F., Ermagan, V., Cabellos, A., and D. Sanchez, + "LISP-Security", + . + + [LISP-TREE] + Jakab, L., Cabellos, A., Coras, F., and D. Sauceez, "LISP- + TREE", 10 2010, + . [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. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical @@ -1574,31 +1580,23 @@ indicate that the receiver can and should return Map-Referral messages as appropriate. Authors' Addresses Vince Fuller Email: vaf@vaf.net Darrel Lewis - cisco Systems - Tasman Drive - San Jose, CA 95134 - USA + Cisco Systems Email: darlewis@cisco.com + Vina Ermagan - cisco Systems - Tasman Drive - San Jose, CA 95134 - USA + Cisco Systems Email: vermagan@cisco.com Amit Jain Juniper Networks - 1133 Innovation Way - Sunnyvale, CA 94089 - USA Email: atjain@juniper.net