draft-ietf-lisp-ddt-07.txt   draft-ietf-lisp-ddt-08.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft Internet-Draft
Intended status: Experimental D. Lewis Intended status: Experimental D. Lewis
Expires: December 2, 2016 V. Ermagan Expires: March 12, 2017 V. Ermagan
Cisco Systems Cisco Systems
A. Jain A. Jain
Juniper Networks Juniper Networks
A. Smirnov A. Smirnov
Cisco Systems Cisco Systems
May 31, 2016 September 8, 2016
LISP Delegated Database Tree LISP Delegated Database Tree
draft-ietf-lisp-ddt-07 draft-ietf-lisp-ddt-08
Abstract Abstract
This document describes the LISP Delegated Database Tree (LISP-DDT), This document describes the LISP Delegated Database Tree (LISP-DDT),
a hierarchical, distributed database which embodies the delegation of a hierarchical, distributed database which embodies the delegation of
authority to provide mappings from LISP Endpoint Identifiers (EIDs) authority to provide mappings from LISP Endpoint Identifiers (EIDs)
to Routing Locators (RLOCs). It is a statically-defined distribution to Routing Locators (RLOCs). It is a statically-defined distribution
of the EID namespace among a set of LISP-speaking servers, called DDT of the EID namespace among a set of LISP-speaking servers, called DDT
nodes. Each DDT node is configured as "authoritative" for one or nodes. Each DDT node is configured as "authoritative" for one or
more EID-prefixes, along with the set of RLOCs for Map Servers or more EID-prefixes, along with the set of RLOCs for Map Servers or
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
6.4. Map-Referral Message Format . . . . . . . . . . . . . . . 10 6.4. Map-Referral Message Format . . . . . . . . . . . . . . . 10
6.4.1. SIG section . . . . . . . . . . . . . . . . . . . . . 12 6.4.1. SIG section . . . . . . . . . . . . . . . . . . . . . 12
7. DDT network elements and their operation . . . . . . . . . . 13 7. DDT network elements and their operation . . . . . . . . . . 13
7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 14 7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 14
7.1.2. Missing delegation from an authoritative prefix . . . 14 7.1.2. Missing delegation from an authoritative prefix . . . 14
7.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 14 7.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 14
7.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 15 7.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 15
7.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 15 7.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 15
7.3.2. Receiving and following referrals . . . . . . . . . . 16 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 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. Map Resolver processing of ITR Map-Request . . . . . . . 19
8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19
8.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 19 8.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 19
8.2. Map Resolver processing of Map-Referral message . . . . . 20 8.2. Map Resolver processing of Map-Referral message . . . . . 20
8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 20 8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 20
8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 22 8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 22
8.3. DDT Node processing of DDT Map-Request message . . . . . 24 8.3. DDT Node processing of DDT Map-Request message . . . . . 24
8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 24 8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 24
8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 25 8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 25
9. Example topology and request/referral following . . . . . . . 25 9. Example topology and request/referral following . . . . . . . 25
skipping to change at page 5, line 35 skipping to change at page 5, line 35
DDT client: a network infrastructure component that sends Map- DDT client: a network infrastructure component that sends Map-
Request messages and implements the iterative following of Map- Request messages and implements the iterative following of Map-
Referral results. Typically, a DDT client will be a Map Resolver, Referral results. Typically, a DDT client will be a Map Resolver,
but it is also possible for an ITR to implement DDT client but it is also possible for an ITR to implement DDT client
functionality. functionality.
DDT Map Server: a DDT node that also implements Map Server DDT Map Server: a DDT node that also implements Map Server
functionality (forwarding Map-Requests and/or returning Map- functionality (forwarding Map-Requests and/or returning Map-
Replies if offering proxy Map-Reply service) for a subset of its 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 DDT Map Resolver: a network infrastructure element that accepts a
Map-Request, adds the XEID to its pending request list, then Map-Request, adds the XEID to its pending request list, then
queries one or more DDT nodes for the requested EID, following queries one or more DDT nodes for the requested EID, following
returned referrals until it receives one with action code MS-ACK returned referrals until it receives one with action code MS-ACK
(or an error indication). MS-ACK indicates that the Map-Request (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, 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 in turn, will provide a Map-Reply to the original sender. A DDT
Map Resolver maintains both a cache of Map-Referral message Map Resolver maintains both a cache of Map-Referral message
results containing RLOCs for DDT nodes responsible for XEID- results containing RLOCs for DDT nodes responsible for XEID-
skipping to change at page 7, line 48 skipping to change at page 7, line 50
the DDT node receives a DDT Map-Request with an XEID that matches a 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 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 for which it accepts ETR mapping registrations and for which it will
forward (or answer, if it provides proxy Map-Reply service) Map- forward (or answer, if it provides proxy Map-Reply service) Map-
Requests. Requests.
4.2.1. The root DDT node 4.2.1. The root DDT node
The root DDT node is the logical "top" of the database hierarchy: 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 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 no configured XEID-prefix will be referred to the root node (see
root node in a particular instantiation of LISP-DDT must therefore be Section 8 for formal description of conditions when DDT Request is
configured with delegations for at least all defined IIDs and AFIs. 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 5. DDT Map-Request
A DDT client (usualy a Map Resolver) uses LISP Encapsulated Control 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 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- is defined by [RFC6830]. This specification adds to ECM flag "DDT-
originated". originated".
0 1 2 3 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 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
skipping to change at page 9, line 45 skipping to change at page 9, line 48
See Section 7.1.2 for details. See Section 7.1.2 for details.
NOT-AUTHORITATIVE (5): indicates that the replying DDT node received NOT-AUTHORITATIVE (5): indicates that the replying DDT node received
a Map-Request for an XEID-request for which it is not a Map-Request for an XEID-request for which it is not
authoritative. This can occur if a cached referral has become authoritative. This can occur if a cached referral has become
invalid due to a change in the database hierarchy. invalid due to a change in the database hierarchy.
6.2. Referral set 6.2. Referral set
For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a 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; DDT nodes that are authoritative for the XEID-prefix being returned;
a DDT Map Resolver uses this information to contact one of those DDT a DDT Map Resolver uses this information to contact one of those DDT
nodes as it "follows" a referral. nodes as it "follows" a referral.
6.3. Incomplete flag 6.3. Incomplete flag
A DDT node sets the "Incomplete" flag in a Map-Referral message if 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 the Referral Set is incomplete; this is intended to prevent a DDT Map
Resolver from caching a referral with incomplete information. A DDT 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 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 not have configuration for other "peer" DDT nodes that are also
authoritative for the matched XEID-prefix. authoritative for the matched XEID-prefix.
o If it is setting action code NOT-AUTHORITATIVE. o If it is setting action code NOT-AUTHORITATIVE.
6.4. Map-Referral Message Format 6.4. Map-Referral Message Format
0 1 2 3 0 1 2 3
skipping to change at page 12, line 10 skipping to change at page 12, line 10
4 DELEGATION-HOLE NO NO 15 4 DELEGATION-HOLE NO NO 15
5 NOT-AUTHORITATIVE YES NO 0 5 NOT-AUTHORITATIVE YES NO 0
------------------------------------------------------------------- -------------------------------------------------------------------
*: The "Incomplete" flag setting on Map Server originated referral of *: The "Incomplete" flag setting on Map Server originated referral of
MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map
Server has the full peer Map Server configuration for the same Server has the full peer Map Server configuration for the same
prefix and has encoded the information in the mapping record. prefix and has encoded the information in the mapping record.
Incomplete bit is not set when the Map Server has encoded the Incomplete bit is not set when the Map Server has encoded the
information, which means the referral-set includes all the RLOCs information, which means the referral-set includes all the RLOCs
of all Map Servers that serve the prefix. It is set when the Map of all Map Servers that serve the prefix. It MUST be set when the
Server has not encoded the Map Server set information. Map Server has not encoded the complete Map Server set
information.
SigCnt: Indicates the number of signatures (sig section) present in SigCnt: Indicates the number of signatures (sig section) present in
the Record. If SigCnt is larger than 0, the signature information 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 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 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 SigCnt were Reserved in Records embedded into messages defined by
[RFC6830] and were required to be set to zero. [RFC6830] and were required to be set to zero.
Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the Loc/LCAF-AFI: If this is a Loc AFI, keys SHOULD NOT be included in
record. If this is a LCAF AFI, the contents of the LCAF depend on the record. If this is a LCAF AFI, the contents of the LCAF depend
the Type field of the LCAF. Security material are stored in LCAF 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 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 public keys associated with their Child DDT nodes for a XEID-prefix
referral record. LCAF types and formats are defined in referral record. LCAF types and formats are defined in
[I-D.ietf-lisp-lcaf]. [I-D.ietf-lisp-lcaf].
All other fields and their descriptions are equivalent to those in All other fields and their descriptions are equivalent to those in
the Map-Reply message, as defined in LISP [RFC6830]. Note, though, 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 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 result of the referral not the RLOCs for an actual EID-to-RLOC
mapping. mapping.
6.4.1. SIG section 6.4.1. SIG section
If SigCnt field in the Map-Referral is not 0, the signature SigCnt counts the number of signature sections that appear at the end
information is included at the end of captured in a sig section as of the Record. Format of the signature section is described below.
described below. SigCnt counts the number of sig sections that
appear at the end of the Record.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/| Original Record TTL | /| Original Record TTL |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Signature Expiration | / | Signature Expiration |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
s | Signature Inception | s | Signature Inception |
i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
g | Key Tag | Sig Length | g | Key Tag | Sig Length |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 39 skipping to change at page 13, line 39
Key Tag: An identifier to specify which key is used for this 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. signature if more than one valid key exists for the signing DDT node.
Sig Length: The length of the Signature field. Sig Length: The length of the Signature field.
Sig-Algorithm: The identifier of the cryptographic algorithm used for Sig-Algorithm: The identifier of the cryptographic algorithm used for
the signature. This specification defines only one algorithm: Sig- the signature. This specification defines only one algorithm: Sig-
Algorithm type 1 is RSA-SHA1 (see [RFC3447]). 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. on receipt.
Signature: Contains the cryptographic signature that covers the Signature: Contains the cryptographic signature that covers the
entire record. The Record TTL and the sig fields are set to zero for entire record. The Record TTL and the sig fields are set to zero for
the purpose of computing the Signature. the purpose of computing the Signature.
7. DDT network elements and their operation 7. DDT network elements and their operation
As described above, DDT introduces a new network element, the "DDT As described above, DDT introduces a new network element, the "DDT
node", extends the functionality of Map Servers and Map Resolvers to node", extends the functionality of Map Servers and Map Resolvers to
skipping to change at page 14, line 18 skipping to change at page 14, line 18
XEID against its list of XEID-prefix delegations and its list of XEID against its list of XEID-prefix delegations and its list of
authoritative XEID-prefixes and acts as follows: authoritative XEID-prefixes and acts as follows:
7.1.1. Match of a delegated prefix (or sub-prefix) 7.1.1. Match of a delegated prefix (or sub-prefix)
If the requested XEID matches one of the DDT node's delegated If the requested XEID matches one of the DDT node's delegated
prefixes, then a Map-Referral message is returned with the matching prefixes, then a Map-Referral message is returned with the matching
more-specific XEID-prefix and the set of RLOCs for the referral more-specific XEID-prefix and the set of RLOCs for the referral
target DDT nodes including associated security information (see target DDT nodes including associated security information (see
Section 10 for details on security). If the delegation is known to 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 be a DDT Map Server, then the Map-Referral message SHOULD be sent
action code MS-REFERRAL to indicate to the receiver that LISP-SEC with action code MS-REFERRAL to indicate to the receiver that LISP-
information (if saved in the pending request) should be included in SEC information (if saved in the pending request) SHOULD be included
the next DDT Map-Request; otherwise, the action code NODE-REFERRAL is in the next DDT Map-Request; otherwise, the action code NODE-REFERRAL
used. SHOULD be used.
Note that a matched delegation does not have to be for a sub-prefix Note that a matched delegation does not have to be for a sub-prefix
of an authoritative prefix; in addition to being configured to of an authoritative prefix; in addition to being configured to
delegate sub-prefixes of an authoritative prefix, a DDT node may also delegate sub-prefixes of an authoritative prefix, a DDT node may also
be configured with other XEID-prefixes for which it can provide be configured with other XEID-prefixes for which it can provide
referrals to DDT nodes anywhere in the database hierarchy. This referrals to DDT nodes anywhere in the database hierarchy. This
capability to define "shortcut hints" is never required to be capability to define "shortcut hints" is never required to be
configured, but may be a useful heuristic for reducing the number of configured, but may be a useful heuristic for reducing the number of
iterations needed to find an EID, particular for private network iterations needed to find an EID, particular for private network
deployments. deployments.
7.1.2. Missing delegation from an authoritative prefix 7.1.2. Missing delegation from an authoritative prefix
If the requested XEID did not match a configured delegation but does 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 negative Map-Referral that uses the least-specific XEID-prefix that
does not match any XEID-prefix delegated by the DDT node. The action 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 code is set to DELEGATION-HOLE; this indicates that the XEID is not a
LISP destination. LISP destination.
If the requested XEID did not match either a configured delegation or If the requested XEID did not match either a configured delegation or
an authoritative XEID-prefix, then the request is dropped and a an authoritative XEID-prefix, then negative Map-Referral with action
negative Map-Referral with action code NOT-AUTHORITATIVE is returned. code NOT-AUTHORITATIVE MUST be returned.
7.2. DDT Map Server 7.2. DDT Map Server
When a DDT Map Server receives a DDT Map-Request, its operation is 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: similar to that of a DDT node with additional processing as follows:
o If the requested XEID matches a registered XEID-prefix, then the o If the requested XEID matches a registered XEID-prefix, then the
Map-Request is forwarded to one of the destination ETR RLOCs (or 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- 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. returned to the sender of the DDT Map-Request.
o If the requested XEID matches a configured XEID-prefix for which o If the requested XEID matches a configured XEID-prefix for which
no ETR registration has been received then a negative Map-Referral no ETR registration has been received then a negative Map-Referral
with action code MS-NOT-REGISTERED is returned to the sender of with action code MS-NOT-REGISTERED MUST be returned to the sender
the DDT Map-Request. of the DDT Map-Request.
7.3. DDT Map Resolver 7.3. DDT Map Resolver
Just as any other Map Resolver, a DDT Map Resolver accepts Map- Just as any other Map Resolver, a DDT Map Resolver accepts Map-
Requests from its clients (typically, ITRs) and ensures that those Requests from its clients (typically, ITRs) and ensures that those
Map-Requests are forwarded to the correct ETR, which generates Map- Map-Requests are forwarded to the correct ETR, which generates Map-
Replies. Unlike a Map Resolver that uses the ALT mapping system (see Replies. Unlike a Map Resolver that uses the ALT mapping system (see
[RFC6836]), however, a DDT Map Resolver uses an iterative process of [RFC6836]), however, a DDT Map Resolver uses an iterative process of
following referrals to find the correct ETR to answer a Map-Request; following referrals to find the correct ETR to answer a Map-Request;
this requires a DDT Map Resolver to maintain additional state: a Map- this requires a DDT Map Resolver to maintain additional state: a Map-
Referral cache and pending request list of XEIDs that are going Referral cache and pending request list of XEIDs that are going
through the iterative referral process. through the iterative referral process.
7.3.1. Queuing and sending DDT Map-Requests 7.3.1. Queuing and sending DDT Map-Requests
When a DDT Map Resolver receives an encapsulated Map-Request, it When a DDT Map Resolver receives an encapsulated Map-Request, it
first performs a longest-match search for the XEID in its referral 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, 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 then the destination is not in the database; a negative Map-Reply
returned and no further processing is performed by the DDT Map MUST be returned and no further processing is performed by the DDT
Resolver. Map Resolver.
If a match is found, the DDT Map Resolver creates a pending request 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 list entry for the XEID and saves the original Map-Request (minus the
encapsulation header) along with other information needed to track encapsulation header) along with other information needed to track
progress through the iterative referral process; the "referral XEID- progress through the iterative referral process; the "referral XEID-
prefix" is also initialized to the null value since no referral has prefix" is also initialized to the null value since no referral has
yet been received. The Map Resolver then creates a DDT Map-Request yet been received. The Map Resolver then creates a DDT Map-Request
(which is an encapsulated Map-Request with the "DDT-originated" flag (which is an encapsulated Map-Request with the "DDT-originated" flag
set in the message header) for the XEID but without any set in the message header) for the XEID but without any
authentication data that may have been included in the original Map- authentication data that may have been included in the original Map-
skipping to change at page 16, line 35 skipping to change at page 16, line 35
A DDT Map Resolver processes a received Map-Referral message A DDT Map Resolver processes a received Map-Referral message
according to each action code: according to each action code:
NODE-REFERRAL: The DDT Map Resolver checks for a possible referral 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 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 DDT Map Resolver saves the prefix returned in the Map-Referral
message in the referral cache, updates the saved prefix and saved message in the referral cache, updates the saved prefix and saved
RLOCs in the pending request list entry, and follows the referral 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 by sending a new DDT Map-Request to one of the DDT node RLOCs
listed in the Referral Set; security information saved with the 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 MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same
manner as a NODE-REFERRAL except that that security information manner as a NODE-REFERRAL except that security information saved
saved with the original Map-Request is included in the new Map- with the original Map-Request MUST be included in the new Map-
Request sent to a Map Server (see Section 10 for details on Request sent to a Map Server (see Section 10 for details on
security). security).
MS-ACK: This is returned by a DDT Map Server to indicate that it has 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 one or more registered ETRs that can answer a Map-Request for the
XEID. If the pending request did not include saved LISP-SEC XEID and the request has been forwarded to one of them (or if the
information or if that information was already included in the Map Server is doing proxy service for the prefix then reply has
previous DDT Map-Request (sent by the DDT Map Resolver in response been sent to the querying ITR). If the pending request did not
to either an MS-REFERRAL or a previous MS-ACK referral), then the include saved LISP-SEC information or if that information was
pending request for the XEID is complete and is dequeued. already included in the previous DDT Map-Request (sent by the DDT
Otherwise, LISP-SEC information is required and has not yet been Map Resolver in response to either an MS-REFERRAL or a previous
sent to the authoritative DDT Map-Server; the DDT Map Resolver re- MS-ACK referral), then the pending request for the XEID is
sends the DDT Map-Request with LISP-SEC information included and complete; processing of the request stops and all request state
the pending request queue entry remains until another Map-Referral can be discarded. Otherwise, LISP-SEC information is required and
with MS-ACK action code is received. If the "incomplete" flag is has not yet been sent to the authoritative DDT Map-Server; the DDT
not set, the prefix is saved in the referral cache. 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 MS-NOT-REGISTERED: The DDT Map Server queried could not process the
request because it did not have any ETRs registered for a request because it did not have any ETRs registered for a
matching, authoritative XEID-prefix. If the DDT Map Resolver has matching, authoritative XEID-prefix. If the DDT Map Resolver has
not yet tried all of the RLOCs saved with the pending request, 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 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 RLOCs have been tried, then the destination XEID is not registered
and is unreachable. The DDT Map Resolver returns a negative Map- and is unreachable. The DDT Map Resolver MUST return a negative
Reply to the original Map-Request sender; this Map-Reply contains Map-Reply to the original Map-Request sender; this Map-Reply
the non-registered XEID-prefix with TTL value of one minute. A contains the non-registered XEID-prefix whose TTL value SHOULD be
negative referral cache entry is created for the prefix (also with set to one minute. A negative referral cache entry is created for
TTL of one minute) and the pending request is dequeued. 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- DELEGATION-HOLE: The DDT Map Server queried did not have an XEID-
prefix defined that matched the requested XEID so it does not 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- negative Map-Reply to the original Map-Request sender; this Map-
Reply will indicate the least-specific XEID-prefix matching the Reply SHOULD indicate the least-specific XEID-prefix matching the
requested XEID for which no delegations exist and will have a TTL requested XEID for which no delegations exist and SHOULD have a
value of 15 minutes. A negative referral cache entry is created TTL value of 15 minutes. A negative referral cache entry is
for the prefix (also with TTL of 15 minutes) and the pending created for the prefix (which also SHOULD have TTL of 15 minutes)
request is dequeued. and processing of the pending request stops.
NOT-AUTHORITATIVE: The DDT Map Server queried is not authoritative NOT-AUTHORITATIVE: The DDT Map Server queried is not authoritative
for the requested XEID. This can occur if a cached referral has for the requested XEID. This can occur if a cached referral has
become invalid due to a change in the database hierarchy. If the become invalid due to a change in the database hierarchy. If the
DDT Map Resolver receiving this message can determine that it is DDT Map Resolver receiving this message can determine that it is
using old cached information, it MAY choose to delete that cached using old cached information, it MAY choose to delete that cached
information and re-try the original Map-Request, starting from its information and re-try the original Map-Request, starting from its
"root" cache entry. If this action code is received in response "root" cache entry. If this action code is received in response
to a query that did not use a cached referral information, then it to a query that did not use a cached referral information, then it
indicates a database synchronization problem or configuration indicates a database synchronization problem or configuration
error. The pending request list entry that caused this answer is error. The pending request is silently discarded, i.e. all state
removed, with no answer returned to the original requestor. for the request that caused this answer is removed and no answer
is returned to the original requestor.
7.3.3. Handling referral errors 7.3.3. Handling referral errors
Other states are possible, such as a misconfigured DDT node (acting 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 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. 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 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 such cases; one possibility is to remove the pending request list
entry and send a negative Map-Reply to the original Map-Request entry and send a negative Map-Reply to the original Map-Request
sender. Alternatively, if a DDT Map Resolver detects unexpected sender. Alternatively, if a DDT Map Resolver detects unexpected
skipping to change at page 31, line 48 skipping to change at page 31, line 48
considered trusted if it is signed by a trust anchor, or if 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 signed by a key that was previously trusted. Typically, in a Map
Resolver, the root DDT node public keys should be configured as trust Resolver, the root DDT node public keys should be configured as trust
anchors. Once a Map Resolver authenticates a public key it locally anchors. Once a Map Resolver authenticates a public key it locally
caches the key along with the associated DDT node RLOC and XEID- caches the key along with the associated DDT node RLOC and XEID-
prefix for future use. prefix for future use.
10.1. XEID-prefix Delegation 10.1. XEID-prefix Delegation
In order to delegate XEID sub-prefixes to its children, a parent DDT In order to delegate XEID sub-prefixes to its children, a parent DDT
node signs its Map-Referrals. Every signed Map-Referral also node signs its Map-Referrals. Every signed Map-Referral MUST also
includes the public keys associated with each child DDT node. Such a include the public keys associated with each child DDT node. Such a
signature indicates that the parent node is delegating the specified signature indicates that the parent node is delegating the specified
XEID -prefix to a given child DDT node. The signature is also XEID-prefix to a given child DDT node. The signature is also
authenticating the public keys associated with the children nodes, authenticating the public keys associated with the children nodes,
and authorizing them to be used by the children DDT nodes to provide and authorizing them to be used by the children DDT nodes to provide
origin authentication and integrity protection for further origin authentication and integrity protection for further
delegations and mapping information of the XEID-prefix allocated to delegations and mapping information of the XEID-prefix allocated to
the DDT node. the DDT node.
As a result, for a given XEID-prefix, a Map Resolver can form an As a result, for a given XEID-prefix, a Map Resolver can form an
authentication chain from a configured trust anchor (typically the authentication chain from a configured trust anchor (typically the
root DDT node) to the leaf nodes (Map Servers). Map Resolvers root DDT node) to the leaf nodes (Map Servers). Map Resolvers
leverage this authentication chain to verify the Map-Referral leverage this authentication chain to verify the Map-Referral
skipping to change at page 33, line 4 skipping to change at page 33, line 4
Record that covers this record; this is computed using the private Record that covers this record; this is computed using the private
key corresponding to the key being revoked. Such a record is termed key corresponding to the key being revoked. Such a record is termed
a "revocation record". By including this record in its Map- a "revocation record". By including this record in its Map-
Referrals, the DDT node informs querying Map Resolvers about the Referrals, the DDT node informs querying Map Resolvers about the
revoked key. A digital signature computed with a revoked key can revoked key. A digital signature computed with a revoked key can
only be used to authenticate the revocation, and SHOULD NOT be used only be used to authenticate the revocation, and SHOULD NOT be used
to validate any data. To prevent a compromised key from revoking 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 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 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 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 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 that initially advertised the key, starting from the time that the
advertisement of the key was stopped by removal from the parent DDT advertisement of the key was stopped by removal from the parent DDT
node. node.
10.3. Map Server operation 10.3. Map Server operation
Similar to a DDT node, a Map Server is configured with one (or more) 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. public/private key pairs that it must use to sign Map-Referrals.
However unlike DDT nodes, Map Servers do not delegate prefixes and as 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 a result they do not need to include keys in the Map-Referrals they
generate. generate.
10.4. Map Resolver operation 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 signature(s) by using a trust anchor, or a previously authenticated
public key, associated with the DDT node sending the Map-Referral. public key, associated with the DDT node sending the Map-Referral.
If multiple authenticated keys are associated with the DDT node If multiple authenticated keys are associated with the DDT node
sending this Map-Referral, the Key Tag field of the signature can be 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 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 key tag matches more than one key associated with that DDT node,
the Map Resolver must try verifying the signature with all matching the Map Resolver MUST try verifying the signature with all matching
keys. For every matching key that is found the Map Resolver must 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 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 use it to verify the associated signature in the record. If no
matching key is found, or if none of the matching keys is matching key is found, or if none of the matching keys is
authoritative for the XEID-prefix in the Map-Referral record, or if 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 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 record is considered corrupted and MUST be discarded. This may be
due to expired keys. The Map Resolver can try other siblings of this due to expired keys. The Map Resolver MAY try other siblings of this
node if there is an alternative node authoritative for the same 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 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 to avoid repeating this process if the resolver cannot verify the
signature after several trials. signature after several trials.
Once the signature is verified, the Map Resolver has verified the Once the signature is verified, the Map Resolver has verified the
XEID-prefix delegation in the Map-Referral, and authenticated the XEID-prefix delegation in the Map-Referral, and authenticated the
public keys of the children DDT nodes. The Map Resolver must add public keys of the children DDT nodes. The Map Resolver must add
these keys to the authenticated keys associated with each child DDT these keys to the authenticated keys associated with each child DDT
node and XEID-prefix. These keys are considered valid for the node and XEID-prefix. These keys are considered valid for the
duration specified in the record's TTL field. duration specified in the record's TTL field.
skipping to change at page 35, line 30 skipping to change at page 35, line 30
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, Protocol (LISP) Map-Server Interface", RFC 6833,
DOI 10.17487/RFC6833, January 2013, DOI 10.17487/RFC6833, January 2013,
<http://www.rfc-editor.org/info/rfc6833>. <http://www.rfc-editor.org/info/rfc6833>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-lisp-lcaf] [I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-12 (work in Address Format (LCAF)", draft-ietf-lisp-lcaf-13 (work in
progress), March 2016. progress), May 2016.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-09 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-10
(work in progress), October 2015. (work in progress), April 2016.
[LISP-TREE] [LISP-TREE]
Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D.,
and O. Bonaventure, "LISP-TREE: a DNS hierarchy to support and O. Bonaventure, "LISP-TREE: a DNS hierarchy to support
the lisp mapping system", Selected Areas in the lisp mapping system", Selected Areas in
Communications, IEEE Journal , 2010, Communications, IEEE Journal , 2010,
<http://ieeexplore.ieee.org/xpls/ <http://ieeexplore.ieee.org/xpls/
abs_all.jsp?arnumber=5586446>. abs_all.jsp?arnumber=5586446>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
 End of changes. 38 change blocks. 
79 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/