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

Dino Farinacci <> Sat, 25 August 2018 21:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C909D130EE8; Sat, 25 Aug 2018 14:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OS1EKFuoxXcS; Sat, 25 Aug 2018 14:40:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B5DA130E44; Sat, 25 Aug 2018 14:40:19 -0700 (PDT)
Received: by with SMTP id p4-v6so2502137pll.8; Sat, 25 Aug 2018 14:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rpa55aNt2PptfCWqNXmfgS4w7ISGEM14BSoh1NGJpvA=; b=DGUBhbC5CpLFrjZOkkzglonmI1mkmqKf9lE5wFOxs5+rO2oT3GuJvBpyXul7L7QdIp hEedIY3hu3R9Y9zKFGB3iKxmep0AvFJagcaDgPhC01Q56KjzwAbzBATU4dJfkwqCXHW4 5rJk5wDNL4/wRhNjAFSROKDMAXqGtHbWxM0qCu8mPguIGGD3u2C+fbsOgLf68fDSqtLz pN1htO5STDWLO0dYrvqic9XEacE+lOfmG9+F/dw3I0Y0z6dXi63HqcsDvRLmXyZrptDD ADN63UbG8vocthzCWgqVBVRH++0UlcPQO8CfFFgk83rfL3pcOYfC6wjPOqBDNPnbBgVX 1dKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rpa55aNt2PptfCWqNXmfgS4w7ISGEM14BSoh1NGJpvA=; b=aDDy7t2np9bMFAdnuxkb+Cj3VFs6T+x1ETwCTWfpn4bM47l6oSueBdcjIle8RmWzPr JILXo9kVLSZegCo3H0LE+OWL6tj+tJKIRmAXDZWRpK1hdMHeyp7WE3YgwkCSK77g3YfZ pGjxlH9YkHfHdYgmJBShoI/ukocklrbxQqXYvKYvZbpUgc0lOOwmzYuvxPgLxXrOGaQ8 QYEgiOeml+ye7n3Nwh/FSfZG0pNq/4jHHg9V9ju/YNQ9OgbEd6Hwogwl+lLqX8Vrs8iT P7ZaISpRPP0MKS5FJQ+T+qy1pnuKJV5oHyXURWwIZ1jWhV8a8MaJSqJTO+9QLbyzQ/tR IkWw==
X-Gm-Message-State: APzg51As407VMEunLlrcS+22+rpKwk/5afuMwYpdz1pjzVcxcAD8PoB2 yZtbicj9GQOwCnM72HlOZzs=
X-Google-Smtp-Source: ANB0Vda5+bgdgSOlPEhqeDrCpPqC/hJbMvhVc9ghwe8rlLoUhzgVDAxGmSTW+6MKfA01j5YJwlsGmA==
X-Received: by 2002:a17:902:528a:: with SMTP id a10-v6mr6890065pli.199.1535233218835; Sat, 25 Aug 2018 14:40:18 -0700 (PDT)
Received: from ?IPv6:2603:3024:151c:55f0:f595:40dc:8980:444e? ([2603:3024:151c:55f0:f595:40dc:8980:444e]) by with ESMTPSA id s73-v6sm17087002pfi.154.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Aug 2018 14:40:18 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Sat, 25 Aug 2018 14:40:15 -0700
Cc:,, IETF Discussion Mailing List <>, Dino Farinacci <>, " list" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Kyle Rose <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Aug 2018 21:40:22 -0000

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