On Tue, Sep 11, 2018 at 12:56 PM, Dino Farinacci <farinacci@xxxxxxxxx> wrote:
KyleOn Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci <farinacci@xxxxxxxxx> 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.
