--- 1/draft-ietf-lisp-ddt-07.txt 2016-09-08 13:16:08.403351928 -0700 +++ 2/draft-ietf-lisp-ddt-08.txt 2016-09-08 13:16:08.475353727 -0700 @@ -1,24 +1,24 @@ Network Working Group V. Fuller Internet-Draft Intended status: Experimental D. Lewis -Expires: December 2, 2016 V. Ermagan +Expires: March 12, 2017 V. Ermagan Cisco Systems A. Jain Juniper Networks A. Smirnov Cisco Systems - May 31, 2016 + September 8, 2016 LISP Delegated Database Tree - draft-ietf-lisp-ddt-07 + draft-ietf-lisp-ddt-08 Abstract This document 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 @@ -32,21 +32,21 @@ 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 December 2, 2016. + This Internet-Draft will expire on March 12, 2017. Copyright Notice Copyright (c) 2016 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 @@ -73,23 +73,23 @@ 6.4. Map-Referral Message Format . . . . . . . . . . . . . . . 10 6.4.1. SIG section . . . . . . . . . . . . . . . . . . . . . 12 7. DDT network elements and their operation . . . . . . . . . . 13 7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 14 7.1.2. Missing delegation from an authoritative prefix . . . 14 7.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 14 7.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 15 7.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 15 7.3.2. Receiving and following referrals . . . . . . . . . . 16 - 7.3.3. Handling referral errors . . . . . . . . . . . . . . 17 + 7.3.3. Handling referral errors . . . . . . . . . . . . . . 18 7.3.4. Referral loop detection . . . . . . . . . . . . . . . 18 - 8. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 18 + 8. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 19 8.1. Map Resolver processing of ITR Map-Request . . . . . . . 19 8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 8.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 19 8.2. Map Resolver processing of Map-Referral message . . . . . 20 8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 20 8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 22 8.3. DDT Node processing of DDT Map-Request message . . . . . 24 8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 24 8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 25 9. Example topology and request/referral following . . . . . . . 25 @@ -209,21 +209,22 @@ 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. + delegated prefixes. Map Server functions including proxying Map- + Replies are described in [RFC6833]. 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- @@ -319,23 +320,25 @@ 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. 4.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. + no configured XEID-prefix will be referred to the root node (see + Section 8 for formal description of conditions when DDT Request is + forwarded to the root node). The root node in a particular + instantiation of LISP-DDT therefore MUST be configured with + delegations for at least all defined IIDs and AFIs. 5. DDT Map-Request A DDT client (usualy a Map Resolver) uses LISP Encapsulated Control Message (ECM) to send Map-Request to a DDT node. Format of the ECM is defined by [RFC6830]. This specification adds to ECM flag "DDT- originated". 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 @@ -410,31 +413,31 @@ See Section 7.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. 6.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 node MUST include in the Map-Referral message a list of RLOCs for 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. 6.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: + 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. 6.4. Map-Referral Message Format 0 1 2 3 @@ -514,51 +517,50 @@ 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. + of all Map Servers that serve the prefix. It MUST be set when the + Map Server has not encoded the complete 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 Section 6.4.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. Note that bits occupied by + end of the Record MUST match the SigCnt. Note that bits occupied by SigCnt were Reserved in Records embedded into messages defined by [RFC6830] and were required to be set to zero. - 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 + Loc/LCAF-AFI: If this is a Loc AFI, keys SHOULD NOT be 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 [I-D.ietf-lisp-lcaf]. All other fields and their descriptions are equivalent to those in the Map-Reply message, as defined in LISP [RFC6830]. 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. 6.4.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. + SigCnt counts the number of signature sections that appear at the end + of the Record. Format of the signature section is described below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /| Original Record TTL | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Signature Expiration | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ s | Signature Inception | i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ g | Key Tag | Sig Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -580,21 +582,21 @@ 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. This specification defines only one algorithm: Sig- Algorithm type 1 is RSA-SHA1 (see [RFC3447]). - Reserved: This field must be set to 0 on transmit and must be ignored + Reserved: This field MUST be set to 0 on transmit and MUST be ignored on receipt. 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. 7. 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 @@ -607,85 +609,85 @@ XEID against its list of XEID-prefix delegations and its list of authoritative XEID-prefixes and acts as follows: 7.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 10 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. + be a DDT Map Server, then the Map-Referral message SHOULD be 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 + SHOULD be 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. 7.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 + match an authoritative XEID-prefix, then the DDT node MUST return 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. + an authoritative XEID-prefix, then negative Map-Referral with action + code NOT-AUTHORITATIVE MUST be returned. 7.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 + Reply service) and a Map-Referral with the MS-ACK action MUST be 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. + with action code MS-NOT-REGISTERED MUST be returned to the sender + of the DDT Map-Request. 7.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 (see [RFC6836]), 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. 7.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. + then the destination is not in the database; a negative Map-Reply + MUST be 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- @@ -719,75 +721,81 @@ 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 7.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. + original Map-Request SHOULD NOT be 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- + manner as a NODE-REFERRAL except that security information saved + with the original Map-Request MUST be included in the new Map- Request sent to a Map Server (see Section 10 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. + XEID and the request has been forwarded to one of them (or if the + Map Server is doing proxy service for the prefix then reply has + been sent to the querying ITR). 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; processing of the request stops and all request state + can be discarded. Otherwise, LISP-SEC information is required and + has not yet been sent to the authoritative DDT Map-Server; the DDT + Map Resolver MUST re-send 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 queried 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. + and is unreachable. The DDT Map Resolver MUST return a negative + Map-Reply to the original Map-Request sender; this Map-Reply + contains the non-registered XEID-prefix whose TTL value SHOULD be + set to one minute. A negative referral cache entry is created for + the prefix (whose TTL also SHOULD be set to one minute) and + processing of the request stops. 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 + exist in the mapping database. The DDT Map Resolver MUST return 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. + Reply SHOULD indicate the least-specific XEID-prefix matching the + requested XEID for which no delegations exist and SHOULD have a + TTL value of 15 minutes. A negative referral cache entry is + created for the prefix (which also SHOULD have TTL of 15 minutes) + and processing of the pending request stops. 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 did not use a 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. + error. The pending request is silently discarded, i.e. all state + for the request that caused this answer is removed and no answer + is returned to the original requestor. 7.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 @@ -1395,22 +1403,22 @@ 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. 10.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 + node signs its Map-Referrals. Every signed Map-Referral MUST also + include 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 @@ -1447,56 +1455,56 @@ 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 + 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 advertised the key, starting from the time that the advertisement of the key was stopped by removal from the parent DDT node. 10.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. 10.4. Map Resolver operation - Upon receiving a Map-Referral, the Map Resolver must first verify the + 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 + 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 + 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 + record is considered corrupted and MUST be discarded. This may be + due to expired keys. The Map Resolver MAY 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 + 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. @@ -1568,27 +1576,27 @@ [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013, . 14.2. Informative References [I-D.ietf-lisp-lcaf] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical - Address Format (LCAF)", draft-ietf-lisp-lcaf-12 (work in - progress), March 2016. + Address Format (LCAF)", draft-ietf-lisp-lcaf-13 (work in + progress), May 2016. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. - Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-09 - (work in progress), October 2015. + Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-10 + (work in progress), April 2016. [LISP-TREE] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, "LISP-TREE: a DNS hierarchy to support the lisp mapping system", Selected Areas in Communications, IEEE Journal , 2010, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,