Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15

[Kyle Rose <[e-mail]>]

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.

Maybe this is just splitting hairs: I certainly don't want to rathole on
this point.


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

I did not review this document because I was following up on authentication
of control plane messages. If that is covered in a document titled
"Data-Plane Confidentiality", some reorganization may be in order.


> (2) RFC 8111 - Locator/ID Separation Protocol Delegated Database Tree
> (LISP-DDT)
>
(3) draft-farinacci-lisp-ecdsa-auth
>

I take it from the name that this has not even been adopted by the WG yet?
Evaluating something I'm supposed to review for IETF LC should not depend
on an unadopted draft.

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

 * 128 bits is already too short for a cryptographic hash, and this
document proposes reducing that to 80 bits for a /48.

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

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

 * Why a scheme like this for addressing Map-Register? Presumably an ETR
will either be owned by the 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.

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

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

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


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

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.

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

Kyle