> Reviewer: Kyle Rose > Review result: Has Issues Thanks for the review Kyle. See my responses inline. > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These comments > were written primarily for the benefit of the security area directors. Document > editors and WG chairs should treat these comments just like any other last call > comments. > > For intranet purposes, LISP (including this document) is Ready: operators > adopting this technology assume responsibility for the potentially novel > operational difficulties of a routing infrastructure having seen limited > deployment in adversarial environments. For internet deployment, readiness is > less clear. Right, agree. > 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. > piecewise on-demand state pull. This new control plane presents novel > opportunities for attackers, and so RFC 7834 recommends authentication for all > control-plane traffic as a countermeasure for many of the threats outlined in > RFC 7835. Proper authentication will be effective for certain classes of > attacks, but does not completely address the security needs of the control > plane, nor is it clear that the proposed authentication is appropriate to the > desired scale of deployment. You are missing pieces of the design and hence why you came to the conclusion you did. There are three documents that enhance the security of LISP, they are: (1) RFC 8061 - Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality (2) RFC 8111 - Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) (3) draft-farinacci-lisp-ecdsa-auth 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). > 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. > EID address space. Section 6.7 of draft-ietf-lisp-sec discusses denial of > service attacks, but fails to distinguish between impersonation attacks > (properly countered by authentication using a pre-established chain of trust) > and volumetric attacks (perhaps complicated by those very authentication > mechanisms, which are often quite expensive). If discussion of this class of > issues exists elsewhere, I would appreciate a pointer as I have not yet found > it. In draft-farinacci-lisp-ecdsa-auth, there are mechanisms to sign Map-Register and Map-Requests going to the mapping system. The map-servers, that make up the mapping system, verify signatures by looking up public-keys in another part of the mapping system. > 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. > distinguish, because that impacts how to precisely describe how attacks relate > to the architecture. Lack of clarity here will lead to inconsistent sets of > assumptions and security assertions. We have a lot of research and documentation identifying the threats and how to manage caches to minmize the impact of an attack. See the following documents: (1) RFC 7835 (was draft-ietf-lisp-threats) (2) draft-ietf-lisp-rfc6833bis (3) RFC 7215 (was draft-ietf-lisp-deployment) These documents also point to research papers that have done analysis on threat attacks. > Moreso than this particular document, draft-ietf-lisp-sec is probably where the > real action is for the security area. That document poses a multitude of And the documents I cite above. > questions, only the most obvious of which is why communication between an ITR > and a Map-Resolver should be over a bespoke protocol instead of (say) DTLS. LISP-SEC does suggest that DTLS can be used. And there have been proposals to run a reliable transport between the nodes that use the mapping system and the nodes that are part of the mapping system. And when using TCP, TLS can be acompanied as well as turning on encryption in QUIC. This document is: (1) draft-kouvelas-lisp-reliable-transport > Since there must be a pre-established trust relationship between the two, and > presumably a persistent session, this seems an obvious choice for > confidentiality and integrity protection. (Note: this is not intended as a > statement that DTLS is definitely a better choice, only that I have not been > able to find documentation of consideration of this design alternative and why > it was rejected.) Right, agree, and understand. > Another question it poses is: how does the Map-Resolver authenticate the > Map-Server? Symmetric authentication with the ITR-OTK demonstrates only that We plane to add that in draft-farinacci-lisp-ecdsa-auth. Up until now it was the clients of the mapping system that first needed to be authenticated, but the map-servers can do the same. We plan to adding signing Map-Notify messages which is typically an Ack to a signed Map-Register sent by an xTR. > the response is associated with the request: it's not immediately clear to me > what security guarantees it provides to the ITR. Limiting attacks to on-path > attackers, yes. But what about MitM? That class of attacks requires either a > pre-shared key (implying a pre-existing trust relationship between a We do use pre-shared keys for registering to the mapping system. And you could encrypt messages in both directions using this shared-key. This shared-key was intended for authorization of a particulary (IID, EID) pair to the mapping system, but can be easily for encryption. > Map-Resolver and every Map-Server it interacts with) or asymmetric > authentication with some kind of trust anchor. I have been able to find no > mention of the latter, and it does not seem that the former scales particularly > well. The way draft-farinacci-lisp-ecdsa-auth specs this is out is: (1) A controller registers hash-to-pubkey mappings in the mapping system. There is a shared key between the controller and map-server(s) so only specific, authorized controllers can register these public-keys. (2) When Map-Register messages arrive at the Map-Server, there is a signature-EID in the message, that is the hash of the public-key used to lookup the hash-to-pubkey mapping, if mapping not found, Map-Register is rejected. If found, the signature is verified. (3) When Map-Requerst messages arrive at the Map-Resolver, the same happens as in (2). Note when LISP0-DDT is used, each level of the delegation hierarchy advertises the public-key of the children so when they send Map-Referral messages which are signed by the children, the Map-Resolver has a public-key to verify the Map-Referral signature. > Given the difficulties in evaluating the readiness of this one piece of the > LISP ecosystem, it may be best to batch the set of documents describing the > entire protocol and to move them through IETF LC at the same time. I hope I have helped you a bit. And if you have any more questions, please don’t hesitate to ask. Thanks again for your review, Dino
