I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments.
For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-lisp-ddt-08 Reviewer: Dale R. Worley Review Date: 2016-10-09 IETF LC End Date: 2016-10-17 IESG Telechat date: 2016-10-27 Summary: This draft is on the right track but has open issues, described in the review. I believe that the technical specifics in this draft have been settled, but in many places the wording is unclear and contradictory in minor ways to the point that I was uncertain whether I understood what is intended. The result is that this review is excessively long, as I can only point to the items that appear problematic, rather than pointing out the adjustments that would cure the problems. I suspect that as the design has evolved, the text has been revised many times, leading to incompletenesses and inconsistencies. The danger, in my opinion, is that no part of the document can be reliably understood without correlating it with many other parts of the document, that many implementers will make mistakes of interpretation, and that there may be points on which people believe consensus was reached, but that their understandings of the point were contradictory. I think that the document needs a careful final editing to bring the terminology and all parts of the document into sync. That will also reveal whether there are points on which people mistakenly believed there was consensus. I begin with a list of more global issues, then continue with comments on specific parts. * In regard to XEIDs: The concept of XEID unifies the treatment of DBID, IID, AFI, and EID. Essentially all of the processing in the draft is simplified by expressing processing in terms of XEIDs. For instance, delegation based on DBID, IID, or AF becomes just a special case of delegation based on XEID-prefix. However, it's not clear to me whether this concept is followed in the text. For example: In section 3, definition "XEID-prefix" seems to assume that an XEID-prefix will always contain a complete DBID, IID, and AFI. In section 4.2.1: The root DDT node is the logical "top" of the database hierarchy: DBID=0, IID=0, AFI=0, EID-prefix=0/0. But really, the condition of a root node is that it's authoritative for the *empty* XEID-prefix. There is also the suggestion here that an AFI of 0 is somehow a wildcard match for any AFI value. That is a special case that can be eliminated by considering the entire XEID to be prefixable. On the other hand, this text in 7.3.1 suggests that there is a "null prefix" which is (or is equivalent) to the XEID-prefix of 0 bits: the "referral XEID-prefix" is also initialized to the null value since no referral has yet been received. * In regard to the special fields in XEID, viz., DBID, IID, and AFI, those need to be described in a way that doesn't leave loose ends, by either describing how they are expected to be used or referring to a document that does so. In this document, a lot of that information is bundled into the definitions of "Extended EID (XEID)" and "XEID-prefix" in section 3. It would be best if this information appeared in its own paragraphs. It appears to me that it is expected that DBID will always be zero (see definition "XEID-prefix"), but the machinery is defined so that other values can be used. IID is presumably expected to be zero except when VPNs are used. (see definition "Extended EID (XEID)") Note that definition "Extended EID (XEID)" says "optionally extended with a non-zero Instance ID". Read literally, that means that zero IIDs aren't included in the XEID, which would be insanity. The text needs to clarify that IID is always present in the XEID, but is normally zero. AFI is taken from http://www.iana.org/numbers.html, but you have to go through the link to draft-ietf-lisp-lcaf to discover that; it should be stated in this draft. * For any given delegated prefix, there can be more than one "peer" DDT nodes that contain duplicated information about the prefix. But the term "peer" isn't defined in the lexicon, and there is no explicit statement that the peers (for a prefix) must contain the same information. * It appears that "Map Server" has been defined elsewhere (RFC 6833), and that Map Servers can automatically be DDT nodes. Or is it that some Map Servers are also equipped with DDT node functionality? If this draft places further requirements on Map Server DDT nodes, then this draft should be noted as updating RFC 6833. * There seems to be two meanings of "DDT node". One is a broad sense, and is any server that responds to Map-Request. The other is a narrow sense, and means any DDT node in the broad sense that is not a Map Server, and thus is allowed to contain prefix delegations. These terms need to be separated, and the uses of "DDT node" in the draft need to be revised to the correct term. However, the preceding paragraph assumes that a DDT node is not allowed to contain both prefix delegations and ETR registrations. That seems to be the case because in many places, those classes of nodes are required to behave differently (e.g., return different error codes for nonexistent prefixes) and be treated differently by other DDT nodes (e.g., referrals to them are given with different action codes). But there are a few places where the text suggests that a DDT node could contain both prefix delegations and ETR registrations. * Is it really true that two Map Servers that are authoritative for the same XEID prefix can contain different sets of ETR registrations? That is, the DDT client (the Map Resolver) may be required to query the entire set of peer Map Servers to find the right ETR registration? Perhaps the answer is defined in the RFC describing Map Servers, but it affects one's understanding of this draft enough that it should be stated in the overview. * The role of hints is not clear. Clearly, a DDT node can be configured with hints regarding some XEID-prefix, but what are the limitations on what RLOCs must be provided in a hint? This seems especially important because it seems in practice that the authoritative nodes for a prefix might be reconfigured without anyone realizing that the hints in nodes farther down the tree need to be updated. In particular, when should the DDT client follow a hint? Hints seem to provide the possibility of circular references. Given that this is an Experimental draft, perhaps the best use of hints is an "open issue and consideration", and by listing it in section 11, these questions need not be answered now. 1. Introduction LISP offers a general-purpose mechanism for mapping between EIDs and RLOCs. In organizing a database of EID to RLOC mappings, this specification extends the definition of the EID numbering space by logically prepending and appending several fields for purposes of defining the database index key: Database-ID (DBID, 16 bits), Instance identifier (IID, 32-bits), Address Family Identifier (16 bits), and EID-prefix (variable, according to AFI value). The resulting concatenation of these fields is termed an "Extended EID prefix" or XEID-prefix. This paragraph is undecided whether it is defining XEID or XEID-prefix. Better, I think is to define XEID first and then define XEID-prefix based on that: this specification extends the definition of the EID numbering space by logically concatenating several fields for purposes of defining the database index key: Database-ID (DBID, 16 bits), Instance identifier (IID, 32-bits), Address Family Identifier (16 bits), and EID (variable length, according to AFI value). The resulting concatenation of these fields is termed an "Extended EID" or XEID. Prefixes within the XEID space are thus "Extended EID prefixes" or XEID-prefixes. -- It also provides delegation information to Map Resolvers, which use the information to locate EID-to-RLOC mappings. There needs to be clarification regarding the relationship between "Map Resolver" and "DDT client". As far as I can tell, in all places in this document, "DDT client" is the correct term, though it is expected that most (but not all) DDT clients will be Map Resolvers. So this text should be something like It also provides delegation information to DDT clients (which are usually Map Resolvers, but may be ITRs), which use the information to locate EID-to-RLOC mappings. and approximately all uses of "Map Resolver" should be changed to "DDT client". LISP-DDT defines a new device type, the DDT node, that is configured as authoritative for one or more XEID-prefixes. Here would be a good place to lay out clearly the relationship between DDT node and Map Server: whether nodes that do delegation are disjoint from Map Server nodes, etc. 3. Definition of Terms Extended EID (XEID): a LISP EID, optionally extended with a non- zero Instance ID (IID) if the EID is intended for use in a context where it may not be a unique value, such as on a Virtual Private Network where [RFC1918] address space is used. See "Using Virtualization and Segmentation with LISP" in [RFC6830] for more discussion of Instance IDs. XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided to allow the definition of multiple databases; currently always zero in this version of DDT, with other values reserved for future use), 32-bit IID and 16-bit AFI prepended. Encoding of the prefix, its AFI and the instance ID (IID) are specified by [I-D.ietf-lisp-lcaf]. An XEID-prefix is used as a key index into the database. These can be simplified by moving the details of the XEID format and the values of the fields into separate paragraphs (as discussed above). DDT node: a network infrastructure component responsible for specific XEID-prefix and for delegation of more-specific sub- prefixes to other DDT nodes. A DDT node can be authoritative for more than one prefix (see section 4.2 and section 10, paragraph 2), so "specific XEID-prefix" should be "specific XEID-prefix(es)". DDT Map Resolver: a network infrastructure element that accepts a Map-Request, adds the XEID to its pending request list, then queries one or more DDT nodes for the requested EID, following returned referrals until it receives one with action code MS-ACK (or an error indication). MS-ACK indicates that the Map-Request has been sent to a Map Server that will forward it to an ETR that, in turn, will provide a Map-Reply to the original sender. A DDT Map Resolver maintains both a cache of Map-Referral message results containing RLOCs for DDT nodes responsible for XEID- prefixes of interest (termed the "referral cache") and a pending request list of XEIDs that are being resolved through iterative querying of DDT nodes. This isn't really a definition of what how Map Resolver fits into the overall scheme, but an outline of Map Resolver processing. The description of processing should be moved somewhere else. Also, any DDT client that is not a Map Resolver must do the same processing, so "DDT client" and "DDT Map Resolver" should be merged. 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 ... Given the importance of Map-Request messages, it might be worth mentioning that they are defined in RFC 6830. What is the need for the DDT-originated flag? It seems from the definition "Encapsulated Map-Request" that EMRs from ITRs to Map Resolvers never have the flag set, EMRs from Map Resolvers to DDT nodes (including Map Servers) always have the flag set, and EMRs from Map Servers to ETRs never have the flag set. But if that is so, no type of device can receive EMRs that both have the flag set and not. Hmmm, the exception is if an ITR acts as a DDT client sends a Map-Request directly to DDT nodes. But in that case, the DDT nodes would process the Map-Request in exactly the same way as a Map Resolver, so there is no need for a "D" flag. Also, the definition of the flag in section 5 is awkward: D: The "DDT-originated" flag. It is set by a DDT client to indicate that the receiver SHOULD return Map-Referral messages as appropriate. Use of the flag is further described in Section 7.3.1. This bit is allocated from LISP message header bits marked as Reserved in [RFC6830]. If the flag *means* "DDT-originated", then the message must have come from a DDT client, and the receiver MUST return Map-Referral messages -- that's what this draft is specifying! I get the feeling that the D flat is (or was) intended to work like the DNS "recursion" flag, it tells whether the client is willing to accept and follow Map-Referral messages, or whether the client wants to put that work of following referrals on the server. But as the lexicon makes clear, *any* DDT client must be willing to follow Map-Referral messages, and DDT nodes are *never* required to follow referrals on behalf of the DDT client. 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; The phrase "more information" is used in various places, but it is not really informative. As far as I can tell, all uses of "DDT nodes that have more information" mean "DDT nodes to which that XEID has been delegated". Unless perhaps hints are also considered to point to "DDT nodes that have more information", in which case the term "more information" needs to be defined specifically, as it doesn't always mean a delegation relationship. 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). I'd describe a negative Map-Referral as an answer from an authoritative DDT node that there is no mapping for the requested XEID. That happens because the request is sent to an authoritative DDT node "but for which there is no delegation configured (or no ETR registration if sent by a DDT Map-Server)", but the core semantics is an authoritative denial of a mapping. 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. Is it correct that a DDT Map Resolver can receive Map-Requests from DDT clients? I thought a Map Resolver could only receive them from ITRs, and a DDT client could only send them to DDT nodes. If a Map Resolver can receive requests from other Map Resolvers, there are complexities of behavior that don't seem to be described in this draft. In any case, does this need an entry in the lexicon? It seems that a pending request list is an implementation detail and should be described in the algorithm description sections. It is important to note that LISP-DDT does not store actual EID-to- RLOC mappings; it is, rather, a distributed index that can be used to find the devices (Map Servers and their registered EIDs) that can be queried with LISP to obtain those mappings. This text defines that Map Servers are not part of DDT, but the lexicon refers to DDT Map Servers. And actually, its the ETRs that store the EID-to-RLOC mappings, not the Map Servers (except when the Map Server is proxying for the ETR). 6.1. Action codes MS-ACK (2): indicates that a replying DDT Map Server received a DDT s/a replying/the replying/ 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. There's a treacherous case of how hints are returned by a DDT node. Reading the above definition, it's clear that a hint should be returned with a NON-AUTHORITATIVE action code, because the node isn't authoritative for the XEID. Then again, section 6.1 suggests that hints are returned as NODE-REFERRAL or MS-REFERRAL. If so, things get messy -- How is the DDT client to know that the referral set is a hint rather than an authoritative delegation? And that distinction is necessary because the client can't fully trust hints. 6.3. Incomplete flag 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. Is this situation equivalent to the referral set being a hint rather than a delegation? Or rather, a hint which the DDT node doesn't believe is the complete peer set for the prefix? (Is there any way for a DDT node to know that it has the complete peer set?) In any case, it seems to me that this might be usefully changed to "hint flag". 6.4. Map-Referral Message Format Is it intended that the "record" and "ref" sections can be repeated? That is a different usage of bracketing than in the figure in section 5, and if so, should be described in the text. I note that this section lists all the action codes, as does section 6.1. It seems like these should be consolidated into section 6.1. The handling of the "Incomplete" column of the table cannot be correct. There is no way for a node to send hints and mark them Incomplete, and the description at the top of page 12 is incompatible with the contents of the table. 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]. This paragraph doesn't make sense in this context. The terms "Loc", "keys", "LCAF", "Security material" are all undefined in this context. 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. I take it that the "Ref" sections is counted by the "Referral Count" field, and that the "Loc/LCAF-AFI" and "Locator" fields contain the RLOCs of the set of DDT nodes that are the referral set. It might help the reader to rephrase this sentence in those terms. 6.4.1. SIG section Sig Length: The length of the Signature field. Is this measured in bytes? 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. It's not clear to me why the Record TTL should be set to zero for computing the signature, given that you'd want to protect the TTL from modification. Also, what is the relationship between Record TTL and Original Record TTL? As far as I can tell, no DDT element can receive a Map-Referral Record from another element and pass it on to a third element, so there need never be TTL skew between when a record was signed and when it was sent. It seems awkward to compute the signature by first laying out the Sig section and filling it with zeros when the same benefit could be obtained by omitting the Sig section from the part of the record whose signature is calculated. Is it a problem that Original Record TTL, Signature Expiration, and Signature Inception aren't protected by the signature? 7.1.1. Match of a delegated prefix (or sub-prefix) If the delegation is known to be a DDT Map Server, This seems to assume that either all delegatees are Map Servers or none are. All of the processing algorithms seem to presuppose that a set of peers either are all Map Servers or all are not, but there doesn't seem to be an explicit requirement of that. 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 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. It would be a bit clearer if "the least-specific XEID-prefix" was changed to "the least-specific prefix of the XEID". If the requested XEID did not match either a configured delegation or an authoritative XEID-prefix, then negative Map-Referral with action code NOT-AUTHORITATIVE MUST be returned. I understand what you mean, but this isn't phrased quite right in regard to hints, because the DDT node may have a hint for an XEID-prefix that is neither a configured delegation nor within one of its authoritative XEID-prefixes, but hints are returned with NODE-REFERRAL. 7.3. DDT Map Resolver 7.3.1. Queuing and sending DDT Map-Requests I think there is an issue around the cache. Usually (IMHO) when discussing "resolvers", the "cache" is entirely transient information that the resolver has acquired from other devices, it doesn't contain configured information. But in some places, the draft reads as if the configured information is permanently present in the cache. If that is so, it would help the reader (i.e., this reader!) if when the cache is introduced that it was stated that the configured delegations (and hints) are permanently resident in the cache. That is, this should be promoted from section 7.3.1 to 7.3 where the structure (rather than the detailed behavior) of a Map Resolver is discussed: The referral cache is initially populated with one or more statically-configured entries; Similarly this is a structural statement about the cache: A DDT Map Resolver is not absolutely required to cache referrals, but it doing so decreases latency and reduces lookup delays. -- Note that in normal use on the public Internet, the statically- configured initial referral cache for a DDT Map Resolver should include a "default" entry with RLOCs for one or more DDT nodes that can reach the DDT root node. This suggests that it will be common that a Map Resolver won't be configured with the RLOCs of the root nodes (which is different from the common DNS usage), but rather configured with the RLOCs of nodes that contain a hint for the null prefix and the root nodes. (Also, "can reach" should be changed to "containing hints for".) If this is so, then the operation of hints is a central part of the DDT protocol and (IMO) it would greatly help if the role and processing of hints was outlined in some location. In particular, it suggests that all nodes that are expected to be the initial node for an extensible population of Map Resolvers SHOULD be configured with a hint for the root nodes. There is also a possible conflict with section 10 -- the Map Resolver isn't expected to be configured with the RLOCs of the root servers, but it is expected to be configured with the public keys of the root servers. Indeed, given the language in section 10, the keys can differ between the various root DDT nodes, which means that in order to configure the Map Resolver with the public keys of the root servers, it must be configured with their RLOCs. 7.3.2. Receiving and following referrals If the maximum number of retransmissions has occurred and all RLOCs have been tried, then the pending request list entry is dequeued. This isn't phrased quite right, because it requires a further retransmission if "the maximum number of retransmissions has occurred" but not "all RLOCs have been tried" -- and that would mean sending more retransmissions than the "maximum number". I believe that the intention is that the Map Resolver must attempt to contact all relevant RLOCs, but that it must also send at least "number of retransmissions", meaning that if there are fewer RLOCs than that number, some RLOCs will be attempted more than once. If that is so, then "maximum number" should be "minimum number". OTOH, if "maximum number" is intended, then the text should be "If the maximum number of retransmissions has occurred or all RLOCs have been tried". Also, this paragraph should specify what response the Map Resolver should send if processing is terminated due to response time-out. As written, the text doesn't require the Map Resolver to send *any* response, which seems like a bad design. MS-REFERRAL: The DDT Map Resolver follows an MS-REFERRAL in the same manner It might be better to say "processes" than "follows". 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 and the request has been forwarded to one of them It's not clear to me how the Map Server or ETR knows the address of the DDT client to which to send the Map-Reply. It seems that the address must be in the Map-Request message, but reading that section of RFC 6830 doesn't make it clear to me how that is done. The processing regarding MS-ACK is not clear to me. It would help if there was an overview discussion of the four-way dance between the DDT client, the Map Resolver, the Map Server, and the ETR. (Some times the Map Server also does the ETR's job.) Since one step of it is for the ETR to send Map-Replay to the DDT client, this processing doesn't break down into separate client/Map Resolver, Map Resolver/Map Server, and Map Server/ETR components, there's a specific overall structure. In particular, what happens when a Map Resolver sends a Map-Request to a Map Server without LISP-SEC information? It appears that processing goes through two cycles, with a second cycle when the Map Resolver re-sends the Map-Request to the Map Server with LISP-SEC information. The Map Server seems to return MS-ACK messages to the Map Resolver in both cycles, and there is no special marking in the first MS-ACK message to indicate that resending must be done (the Map Resolver can determine that itself). But presumably, the Map Server forwards the Map-Request to the ETR in both cycles, and the ETR sends Map-Replys to the client in both cycles. Presumably the first Map-Reply is useless to the client (otherwise there wouldn't need to be two cycles), but it's not clear how the client deals with two replies. MS-NOT-REGISTERED: ... 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. I think "non-registered XEID-prefix" is meant to mean "least-specific prefix of the XEID for which no registrations exist". NOT-AUTHORITATIVE: ... 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 requester. It seems like a poor design to return no response. Is there not some sort of "server failure" response that can be returned to the DDT client? 8. Pseudo Code and Decision Tree diagrams Care needs to be taken here as to whether the pseudo-code and decision trees are normative or not. Generally, algorithms enunciated in RFCs are marked as non-normative, as the implementation is usually allowed to deviate from the stated algorithm as long as it satisfies the constraints written in the text. 9. Example topology and request/referral following The same principle of hierarchical delegation and pinpointing referrals is equally applicable to any AF whose address hierarchy can be expressed as a bitstring with associated length. This sentence seems to be redundant because we've been assuming all along that in any address family used by DDT the address hierarchy is expressed as bistrings with lengths. Are lines in the diagram intended to cross? If so, they could be clarified as: +---------------------+ +---------------------+ | root1: 192.0.2.1 | | root2: 192.0.2.2 | | authoritative: ::/0 | | authoritative: ::/0 | +---------------------+ +---------------------+ | \ / | | \ / | | X | | / \ | | / \ | | | | | V V V V +-------------------------+ +--------------------------+ | DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 | | authoritative: | | authoritative: | | 2001:db8::/32 | | 2001:db8::/32 | +-------------------------+ +--------------------------+ | \ / | | \ / | | X | | / \ | | / \ | | | | | V V V V +--------------------------+ +---------------------------+ | Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 | | authoritative: | | authoritative: | | 2001:db8:0100::/40 | | 2001:db8:0500::/40 | | site1: 2001:db8:0103::/48| +---------------------------+ | site2: 2001:db8:0104::/48| | | +--------------------------+ | | | | | | V V +---------------------------+ +---------------------------+ | Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 | | authoritative: | | authoritative: | | 2001:db8:0500::/48 | | 2001:db8:0501::/48 | |site3: 2001:db8:0500:1::/64| |site5: 2001:db8:0501:8::/64| |site4: 2001:db8:0500:2::/64| |site6: 2001:db8:0501:9::/64| +---------------------------+ +---------------------------+ 10. Securing the database and message exchanges Each DDT node is configured with one or more public/private key pair(s) that are used to digitally sign referral records for XEID- prefix(es) that the DDT node is authoritative for. In other words, each public/private key pair is associated with the combination of a DDT node and the XEID-prefix that it is authoritative for. s/the XEID-prefix/an XEID-prefix/ But the first sentence doesn't say the same thing as the second sentence. Better would be Each DDT node is configured with one or more public/private key pairs for each XEID-prefix that it is authoritative for, and those keys are used to sign referral records for XEID-prefixes within the authoritative XEID-prefix. Also, there should be some text as to whether a node is required to sign a referral record with *all* of its keys. And in general, there should be some discussion of the significance and use of multiple keys for a single DDT node/authoritative prefix. Every DDT node is also configured with the public keys of its children DDT nodes. By including public keys of target child DDT nodes in the Map-Referral records, and signing each record with the DDT node's private key, a DDT node can securely delegate sub-prefixes of its authoritative XEID-prefixes to its children DDT nodes. Does a DDT node have the public keys of the DDT nodes that its hints point to? If not, hints can't be trusted and followed in the same way as "downward" Map-Referrals, which breaks the trust sequence if the DDT client is not configured with the keys of the RLOCs in the hint. Also, how does the DDT node return public keys to the Map Resolver? I don't see any field for it in the Map-Referral message. 11. Open Issues and Considerations o Management of the DDT Map Resolver referral cache, in particular, detecting and removing outdated entries. I assume that this means "the definition and use of TTL values", because the use of TTL values does not seem to be completely described in this document. Perhaps this item could be rephrased to mention TTL explicitly. 13. Security Considerations 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. This sentence is obscure, because "DDT security" is not defined anywhere, and there seems to be no optional security mechanism described in the draft. 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-13 (work in progress), May 2016. The reference to ietf-lisp-lcaf in the definition "XEID-prefix" in section 3 seems to be normative (unless the text in this draft is adjusted to consider XEIDs as undifferentiated bit strings). [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, <http://ieeexplore.ieee.org/xpls/ abs_all.jsp?arnumber=5586446>. This reference is not referenced. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>. The reference to RFC 3447 in section 6.4.1 seems to be normative, as the specifics of RSA-SHA1 signatures come from this RFC. Dale _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
