> This is definitely clearer. The trust relationships appear to be: > > * A network trusts a particular map server to be authoritative for the entire EID/RLOC mapping. Yes, a map-server is delegated part of the EID-prefix space for any more specifics prefixes registered to it. That is what the parent of the LISP-DDT sends referrals for. > * The map servers trust the LISP-DDT root: they use LISP-DDT to publish and resolve EID/RLOC mappings, and can directly authenticate those mappings because they are signed in a hierarchical fashion (like DNSSEC). Yes. A delegated hierarchy where the parent provides the public-key in referrals so when the child signs its referrals, it can be verified (by the map-resolver). > The first is a transitive trust relationship, but this is probably acceptable because it's only one hop (I'm trusting someone else to verify a piece of data that has been authenticated end-to-end) and there is a direct business relationship between the two entities. Right. > The second, if I have the general idea correct, is very much like DNSSEC or the web CA system in that a compromise of a node in the signature tree/forest leads to a loss of authenticity for that entire Yep, correct. > subtree. This is not disqualifying: clearly, many standardized systems have this property. But it's important to state it explicitly so we can at the very least make the properties clear to operators, and potentially recommend and/or develop mitigations. Right, that is in the LISP-DDT spec on how map-servers should behave when they run LISP-DDT. Remember that 6833bis is how the xTRs use the mapping system to talk to map-resolvers and map-servers (as well as xTR to xTR for probing and map-replying, etc). > > this complex. But the interfaces between the documents, by which I mean the requirements they impose on each other, must be made explicit. When a system achieves complexity warranting design modularity, it’s > > And they should be by how the reference each other. If you think there is text that makes assumpiton without a reference to the particular draft, then we can add it. Do you think (need opinions from the chair), that if we put a document tree in draft-ietf-lisp-introduction, would that be helpful? The only drawback is that we may get a circular dependency. But could avoid it by having: (1) Have lisp-intro point to 6830bis and 6833bis. (2) Have 6830bis and 6833bis point to 6830/6833 (3) And none of the 4 documents point to lisp-intro (obviously RFC6830 and RFC6833 do not) but the new bis shoud not. But that is not good for the reader, because if someone picks up 6830bis and realizes they do not want that level of detail, they don’t know by reading it to go to draft-ietf-lisp-introduction. > What I might recommend is either an augmentation of, or a new document analogous to (and informationally referencing), draft-ietf-lisp-introduction that covers the expected security properties of the overall design and the requirements for each of the subcomponents in a way that someone can understand without referring to any document other than the high-level architecture itself. draft-ietf-lisp-introduction is actually quite good at getting the general point of LISP across to someone new; I want to see something similar for LISP's security model. I think that's going to be better than inserting clarifying text here or there. I've actually read enough of this stuff at this point that I'm not sure I can enumerate exactly what's missing where. The threat model document could potentially be folded into that, but it has to start by painting a picture of the security that someone new to LISP can quickly understand. I’ll yield to the WG to respond to this. Dino
