Responding. The draft-ietf-lisp-sec authors need to respond to one of your points below about DTLS. > On Sep 10, 2018, at 7:13 PM, Kyle Rose <krose@xxxxxxxxx> wrote: > > What PKI? That's part of what I'm trying to establish. How do entities decide to trust each other? The xTRs has a trust association with the mapping system because they have (1) a business relationship with them and (2) a shared-key that is used to verify Map-Register messages. From that, Map-Registers and Map-Requests are can be signed where public-keys are stored by that trusted mapping system. That is what is documented in draft-farinacci-lisp-ecdsa-auth-03, and soon to be draft-ietf-lisp-ecdsa-auth-00 (hopefully). > 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. > 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. 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). > 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”. The draft-ietf-lisp-sec authors need to comment. > > 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 I don’t know how to move forward from here. I think we need help from the lisp-chairs and Deborah. Dino
