Last Call Review of draft-ietf-lisp-rfc6830bis-15
review-ietf-lisp-rfc6830bis-15-secdir-lc-rose-2018-08-24-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-lisp-rfc6830bis-15-secdir-lc-rose-2018-08-24

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.

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 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.

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 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.

I would also like clarification on what defines the separation between the control plane and data plane, and whether authentication itself is used to 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.

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 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. 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.)

Another question it poses is: how does the Map-Resolver authenticate the Map-Server? Symmetric authentication with the ITR-OTK demonstrates only that 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 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.

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.