[lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15

[Kyle Rose <[e-mail]>]

Reviewer: Kyle Rose
Review result: Has Issues

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.