> Hi, Dino. I have additional responses inline. > > > For the internet core (DFZ RIB) use-case, LISP proposes replacing BGP > > sessions > > and global eventually-consistent state sharing with a global control plane > > and > > LISP *does not propse to eliminate BGP*, in fact it needs it so RLOC > reachability across the network is available, or there would be no underlay > for the LISP overlay. > > 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. > That said, I have been trying to make sense of this document for the past few > days. I have a few basic observations: > > * 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. > * 128 bits is already too short for a cryptographic hash, and this document > proposes reducing that to 80 bits for a /48. It can go as high as 120 bits. The eid-hash-prefix is configurable on a per LISP instance-ID basis. > * The entire scheme relies on the integrity of the Hash-EID mappings: if an > attacker can compromise a Hash-EID mapping with a different public key that > hashes to the same truncated hash, they can sign anything for that space of > Crypto-EIDs. A shared-key is also used to accept mapping system registrations. And the signature-EID can be accompanied with additional data to make the hash “more unqiue”. That is, the hash is only used as a mapping system lookup key (i.e. a compressed public-key). > * The only protection provided by this scheme is for Map-Register and > Map-Request, and not for the response to Map-Request, which (to me) is the > critical gap. The problem I noted in my original review is We discussed this in Montreal and we have updates pending so map-servers have signature-IDs that can sign responses. It’s on our document todo list. > that the ITR-OTK only allows the Map-Server to prove that a response is > associated with a Map-Resolver's request, not that the Map-Server is the > proper authority for the response. What the system needs is a global trust > network that does not rely on either universal transitive trust (e.g., I'll > just trust whatever my trusted-but-potentially-mistaken neighbors tell me > about the rest of the world based on what they heard) or n^2 relationships > (e.g., symmetric keys with every other entity). There is no reason why a separate mapping system can be deployed just for this purpose. But I could be misunderstanding you. > * Why a scheme like this for addressing Map-Register? Presumably an ETR will > either be owned by the You are conflating two drafts and now I am not sure which one you are referring to. In terms of security, there are 3 documents that cover LISP security, let’s call then RFC 8061 (data-plane confidentiality and authenticstion via AEAD), LISP-SEC (that uses the OTK so Map-Reply messages are authenticated), and lisp-ecdsa-auth (which is used to authenticate control-plane messages from xTR to mapping system). > same entity running the Map-Server authoritative for its own EID space, or it > will contract with one. Either case is a single, pre-established relationship > per ETR, which scales fine. The xTR is run by an entity different than the mapping system entity. And its EID allocation comes from a completely different entity. Once an EID is allocated, then the xTR entity shops for mapping system providers (MSPs) and the MSP decides based on the bit pattern of the address which map-servers the xTR registers to for the EIDs owned by the xTR (the LISP site). At that time, a shared-key is agreed upon (out of band and at provisioning time), to authorized the EID to be registered within an instance-ID to those set of map-servers the MSP has chosen. And with respect to lisp-ecdsa-auth, a key-pair is generated, the private key held by the xTR, the public-key sent out of band to the MSP, the MSP registering the hash->pubkey mapping in its infrastrucutre so it can verify control-plane message signatures. > > * What is the use case for Map-Request authentication? Its only use seems to > be to keep address space -> network topology mapping hidden. From whom? The > end user doesn't need to know, but every entity in the core needs to have > access to a Crypto-EID's associated RLOC or it won't be able to determine the > next hop. It allows only specific entities to lookup EIDs with an instance-ID. The core knows nothing about any of this. All this machinery is done part of the LISP overlay. > * My general recommendation for design documents is that the overall > architecture should be clear to a reader with a relevant technical background > without having to first consume a pile of other documents. To the > authentication point specifically, you may wish to include some text > regarding the properties generically offered by an asymmetric authentication > scheme with the appropriate feature set, and reference those properties in > the security considerations section when addressing certain classes of > attacks. You can then use these requirements as input to a document > describing a specific authentication scheme. Right agree. But this has evolved and improved over a 10 year period. > * This document doesn't present a clear description of the problem it's > trying to solve in the introduction. I understand what it's getting at now > that I've read the whole thing, but a better There is an LISP introduction document we decided to write 5 years ago that was intended to introduce the idea of LISP and overlays. That document is stuck in MISREF. We are trying to unstuck it by publishing these documents. The working group decided that RFC6830bis and RFC6833bis would be technical and background material be put in other documents. We have deployment and interworking documents as well. > introduction (for the actual problem you need to solve, I'd add) would say > something like, q( The LISP architecture introduces two address spaces along > with a mapping from one to the other. The integrity of this mapping is > critical for achieving the intended routing of traffic through a LISP > network, being This is stated in the introduction section. > directly related to service availability and end user privacy. This document > describes a mechanism for implementation of strong authentication of this > mapping. ) The security considerations should then This is a data-plane spec. The control-plane spec (RFC6833bis) explains more about authentication of mappings. > discuss the turtles-all-the-way-down problem of BGP hijacking on the underlay > (should BGP be employed for this purpose) so operators are clear on the > limitations of the scheme. This is out of scope. > You find strong asymmetric authenticaiton and authorization in (3). And > you’ll find authentication of the mapping system nodes in (2). And note that > (1) can be used and layered under the control-plane to give encrypted > control-plane flows (or use DTLS as LISP-SEC refers to for the messages it > requires for its functionality). > > "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed: Right as I explained DTLS does. And TLS is part of an expired Internet Draft. > https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-D.ietf-lisp-rfc6833bis > > > One area of concern, of which I have not been able to find discussion, is > > that > > of the implications of shared capacity for the control and data planes, and > > how > > this can allow a volumetric data plane attack to deny a router access to the > > global mapping system, slowly choking off service to uncached portions of > > the > > Well yes, this happens with all our IETF protocols. It is a valid concern and > there are many operational techniques in network infrastructure that *help* > solve (but not eliminate) these problems. > > 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 would also like clarification on what defines the separation between the > > control plane and data plane, and whether authentication itself is used to > > A control-plane obtains information to store in a table. The data-plane uses > that table. That is the definition in the simpliest form. > > I mean specific to LISP, not generically. For instance, does "LISP > Control-Plane signaling" include only valid messages, or valid + inauthentic > (and presumably dropped) messages? Traditional attack traffic (e.g., a DDoS > attack against a website) is part of the same data plane as all legitimate > end user traffic; is attack traffic directed at control plane endpoints > considered part of the control plane, or is it a third category of traffic? > If the latter, then what does an operator need to do to ensure that control > plane is always available? All in RFC6833bis. I’m sorry LISP is spread across so many documents but we tried to divide and conquer to create a modular way of introducing the entire design. Dino > > Kyle _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
