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

[Dino Farinacci <[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.

(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?

> I agree with, and am not taking issue with, modularity: no one wants a monolithic design for something

I was talking about the docments being modular (but the design is obviously so as well).

> 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. 

> 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.

Yes, understand. The LISP design, especially the security design, as evolved over 10 years. So having continuity over that long period of time with work items as well as people has been challenging. And with the IETF process to boot, it was more difficult. I’m sure you understand this.

The best I can offer is, that you tell us where you are confused at a point in the text and we add text to clarify it. But the problem we have is that the IETF process will not allow us to reference documents that are more inmmature than the document referencing it.

> 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.

Well, we have, and each generation of people that come along want more changes and more consumability We are doing the best we can given the existing parameters, for a decade.  ;-)

So I suggest, you look at something and say “I think this is a bug”, or “I see something missing here, is there a design and does it need a reference”. I don’t know, that’s the most practical way I can see moving forward.

I think we are going to have the same issues/recommendations for Mirja’s comments as well.

Dino