On 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.
The designs are done, the references in the various specs are modest because of the state of the documents. We are sorry for it being hard to navigate.. But for me, I am for less documents versus more, but the working group wants more modularity in the documentation so hence why all the pieces don’t seem to be connected (but they are by the security design of LISP).
I agree with, and am not taking issue with, modularity: no one wants a monolithic design for something 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 simply not sufficient to describe individual system components without providing a framework for analyzing how they fit together without having to read and fully understand all of it. All the information *might* in fact be there, but as an outsider not implementing LISP, and with finite time to review, asking me to understand the minutiae of the entire LISP ecosystem in order to understand the security properties of the overall system is simply not reasonable. I should be able to consume a high-level architectural overview, containing sufficient detail to understand the security properties of the overall system, and then use that to drill into areas of concern more deeply. This is why I want the high-level security requirements documented somewhere, along with a set of high-level explanations of how the proposed system components combine to satisfy them.
Put another way: as someone whose day job it is to read and review design documents and to offer architectural consulting on everything from from network architecture and hardware design to build automation and SDLC tools to dynamic job orchestration and application security, being able to achieve a high-level mental picture of the critical properties of a design is an important first step in evaluating a system's fitness for a particular task. Document authors have a responsibility to make their work consumable by people who don't already have the full context.
Kyle
