Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15

[Kyle Rose <[e-mail]>]

On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci <[e-mail]>
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