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

From: Kyle Rose <[email-masked]>
Date: Fri, 24 Aug 2018 12:33:49 -0700

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.

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 25 Aug 2018 14:40:15 -0700

> Review result: Has Issues

Thanks for the review Kyle. See my responses inline.

> deployment in adversarial environments. For internet deployment, readiness is

Right, agree.

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

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

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

> issues exists elsewhere, I would appreciate a pointer as I have not yet found

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.

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

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

> real action is for the security area. That document poses a multitude of

And the documents I cite above.

> 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

> able to find documentation of consideration of this design alternative and why

Right, agree, and understand.

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

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

> mention of the latter, and it does not seem that the former scales particularly

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.

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 26 Aug 2018 11:42:31 -0500

Kyle, Dino,

Thanks for the review and discussion -- I look forward to seeing where it
ends up.  Just one note, inline...

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

If the PSK does get additionally purposed for encryption, please make sure
to use a modern key derivation hierarchy to provide separation between the
authentication and encryption usages.

-Benjamin

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 26 Aug 2018 18:19:09 -0700

> authentication and encryption usages.

I would venture to say we wouldn’t use the PSK for that. Our options are to negotiate a shared session key with the asymmetric keys already being used, use DTLS or TLS, or use lisp-crypto and have control messages encapsulated I the LISP data-plane. And yes, the later has 6 cipher suites with combinations of all the latest and greatest in Crypto (but not Edward Curves). 

Dino

---

From: Kyle Rose <[email-masked]>
Date: Tue, 28 Aug 2018 17:48:06 -0400

Hi, Dino. I have additional responses inline.

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

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.

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

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

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 28 Aug 2018 15:17:21 -0700

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

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

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 30 Aug 2018 13:01:20 +0200

Kyle, Dino,

I fill like this discussion is going sideways w.r.t. the original 6830bis document.

You started to discuss other documents and other solutions, which, while certainly interesting and important, belong to other threads and documents.

IMHO here are the few points that need to be clarified:

> On 28 Aug 2018, at 23:48, Kyle Rose <[email-masked]> wrote:
> 
> 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.

@Kyle: can we consider this point closed?

[trimmed]

> https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-D.ietf-lisp-rfc6833bis <https://tools.ietf.org/html/draft-ietf-lisp-sec-15#ref-I-D.ietf-lisp-rfc6833bis>
> 
 
I am not sure I understand the point. Isn’t this covered by RFC7835? Reference to that document isn’t sufficient?
If not, can you clarify further?

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

IMHO, these questions should be asked for in the 6833bis thread. Don’t you guys agree?

Ciao

L.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 Aug 2018 07:58:37 -0700

> You started to discuss other documents and other solutions, which, while certainly interesting and important, belong to other threads and documents.

Well I think the security guys want to make sure LISP, holistically, is secure. So we have to present solutions that may not be in the data-plane. I agree though we should focus on data-plane security since that is what Kyle is reviewing.

> @Kyle: can we consider this point closed?

From my standpoint, it should be.

> If not, can you clarify further?

And I am not sure this is relevant to the data-plane.

> IMHO, these questions should be asked for in the 6833bis thread. Don’t you guys agree?

Yes, agree.

Dino