|
Re: Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08
2017-01-18 16:30:33
Hello Dale,
authors of the draft has just published revision -09 which addresses
your comments. Thanks again for your comprehensive comments on the
previous revision which certainly helped us to make the document better.
We agree with ~90% of your comments and made relevant text changes.
Even in those few cases were we didn't agree with comments we tried to
alter text to make intentions and reasons more clear. So I will not
reply here on each comment individually. Please give another round of
review to the new revision; there should be less comments this round and
we can have more meaningful (and faster) exchange.
---
Anton Smirnov
On Saturday 15 October 2016 03:28, Dale R. Worley wrote:
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
| <Prev in Thread] |
Current Thread |
[Next in Thread> |
- Re: Gen-ART IETF Last Call review of draft-ietf-lisp-ddt-08,
Anton Smirnov <=
|
|
|