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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
