On Tue, Sep 11, 2018 at 12:56 PM, Dino Farinacci <[email protected]> wrote:
> On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci <[email protected]> > wrote: > > > E.g., if entity A has pairwise trust with peer B, but needs an EID > mapping for peer C, it needs some way to establish that the replies it's > supposedly receiving from C are genuine. One popular model enabling > > > > The mapping system allows all of A-C to trust each other. > > > > Explain how with a detailed example, or point me to a detailed > explanation in a specific document. The mechanism is still not entirely > clear to me. If A and C don't have an established business relationship, > how does A know that the responses it's getting for EID mappings owned by C > are genuine and not modified by B? This is a critical property of the > system, and so it needs to be made obvious to the reader. > > (1) A, B, and C register their mappings to the mapping system. They have a > trust relationship with each of their respective map-servers. > (2) Those map-servers, who participate in the same mapping system and know > about each other via LISP-DDT delegations, can sign referrals to tell > map-resolvers that A uses to look up mappings for B and C can trust the > map-servers of B and C. > (3) The map-servers can proxy-reply with the mappings for B and C to A. Or > B and C can Map-Reply specifically with signed Map-Replies according to > draft-ietf-lisp-sec. > > Do I need to say more? > 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. * 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). 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. 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 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. > > 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. > 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. Kyle
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
