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

[Luigi Iannone <ggx@xxxxxxxxx>]

Hi Kyle,

good for you having a break, hope you enjoyed your vacation.

Any thoughts about my last email on the subject?

Ciao

L.

On 11 Sep 2018, at 04:13, Kyle Rose <krose@xxxxxxxxx> wrote:

Apologies for the two-week absence: I've been on vacation (especially from email) for most of that period.

On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci <farinacci@xxxxxxxxx> wrote:

> The whole point of LISP is to create a routing overlay for the EID address space, the RIB of which is managed by a global mapping system, not BGP sessions. If control plane traffic managed by BGP (or static routes, or whatever networks use once the DFZ RIB is limited to entities in the core) continues to flow, that is of small comfort to end users trying to get data over the data plane. From the perspective of end users, BGP is being replaced routing of the traffic that matters to them.

That really is not true. You need both the overlay and underlay to get user traffic to flow.

Sure, just like you need link layer connectivity and closed circuits. User traffic is directly handled by the overlay, which is an added layer of novel complexity. When you add complexity, you inevitably add room for bugs and mysterious behavior. Anyway, I'm happy to drop this point for secdir because this is more of a general architectural observation than something specifically related to security.

 

>  * It does not resolve the trust anchor problem. Instead of proposing a PKI, you seem to be proposing a trusted third party authoritative for the Hash-EID namespace. (Q.v. section 2, the Hash-EID definition: "Another entity”)

The trust anchor is the mapping system. And that is the PKI. And the mapping system is distributed.

What PKI? That's part of what I'm trying to establish. How do entities decide to trust each other?

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 you to do that without employing transitive trust is end-to-end signing chained to a trust anchor. With TLS as deployed on the web today, the trust anchors are a set of mostly mutually agreed-upon CA certificates that serve as roots for the certificates presented by every public web server. There are of course issues with this model (q.v., certificate transparency, Symantec), but its behavior is well-established and its properties are understood. What is the equivalent here?

It sounds like the answer here is mapping system-specific. E.g., from a quick perusal of the DDT draft, it sounds very DNSSEC-like (which might suggest a course of action to eliminate the need to develop, deploy, and maintain a custom security protocol, but that is a different discussion).

Where an interface is described without reference to a specific implementation, a set of assumptions (e.g., "correct routing relies on the authenticity of mapping system responses") and associated security requirements for any conforming mapping system (e.g., "entities making use of mapping system responses must have some way to authenticate them that does not rely on transitive trust") need to be stated for the document to be a complete description of a system component. That is, without first clearly defining the required properties of any valid implementation of described interfaces, there's no way to evaluate whether the component under review will do what it's supposed to.

A good place to put these assumptions and requirements is in the security considerations section: those statements are not normative for the system component described by the draft in which they appear, but are effectively requirements for whatever system component is to implement that interface in a conforming way. Enumerating them as such (in the document describing the interface in detail) allows the reader to evaluate the requirements in light of the system using the interface, while also providing a convenient checklist for those designing conforming systems.

A set of well-crafted security considerations sections also makes it much easier for a reviewer to understand the security of the system as a whole without having to understand the details of every implementation, and to verify that individual system components under review will have the appropriate behavior.

I'm going to skip the comments related to draft-farinacci-lisp-ecdsa-auth, just to limit scope here. We can get back to it once that document has been adopted and more fully fleshed-out.

> "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed:

Right as I explained DTLS does.

Check again. Just to be sure, I've tried several tools and the letters "T", "L", and "S" do not appear consecutively anywhere in this document. Neither do "SSL" nor "transport-level security".

 

> I would like to see a discussion of whether and how the nature and scale of this problem differs from that of the status quo. BGP sessions and RIB push have properties that are well-established from decades of experience: surely LISP does not have exactly the same properties. The security considerations should make clear, for instance, how a loss of control plane connectivity differs from the loss of a BGP session, and how this impacts visibility and behavior of the data plane.

Please look at the deployment drafts. Please note, you are reviewing a document that is focusing on encapsulating packets on an overlay. All the other support pieces are broken out, in what the WG felt was logical, in sepreate documents.

I think this gets back to the point I made at the end of my original review, which is that this system is difficult to evaluate from a security perspective in a piecewise manner given the dependencies between the different layers and the lack of explicitly-enumerated security requirements for each system component implementing a given interface.

Kyle