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

Kyle Rose <krose@krose.org> Tue, 11 September 2018 02:13 UTC

Return-Path: <krose@krose.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07462130E17 for <secdir@ietfa.amsl.com>; Mon, 10 Sep 2018 19:13:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL_MbmYQsutA for <secdir@ietfa.amsl.com>; Mon, 10 Sep 2018 19:13:15 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D19130DCF for <secdir@ietf.org>; Mon, 10 Sep 2018 19:13:14 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id o15-v6so26614809qtk.6 for <secdir@ietf.org>; Mon, 10 Sep 2018 19:13:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CcUbFUOnFScAud2LqiElwYRrYmvv9Kdx4fbBFUmNBBg=; b=Cuzny2xKtZ27xXlleN0+c5ioZbNTlMiW9Z5CvYI5z+2DcKj8ZUTtvF7+yowIuA8PYj 8G+e8Y5CWhk2rAZmLDgUePNEu7z3ICSWPkY3XNmDjV02pNQh88/IC7japQjrvWjFKDNa UuR2yTzJWirM8UarLFVRDinqg8FBMD7se66/E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CcUbFUOnFScAud2LqiElwYRrYmvv9Kdx4fbBFUmNBBg=; b=d3dxfs7CljjmtA6e7Al8W7F5CFIcUjsNcP+tI37a+AvmtXd2K6GJ1HXNRB1LlClI6h ndh2bfUwU0LoRx9/vfF07FmNDcinchW2RsZI00r965BtdU43bqyKv2UwuOOoyct2R0K6 1DMaUseiQN/CwgL7PRmtve55RqtizwIDomw5x0g7uMoifSQfsIt/Y+QFqKrOW7m/7pH/ 9YmgV8nebaoW7Ba8wMDEC2Xp6TtH/KgZ/pkSO68H9+hszKa4rb76eJxZMtg3SBR/uct1 wu/w812JvO1ONCHFr2AN5lBkGjxq0sumEs/Lp21wKthMbehdpfVbhnUlF27ji9lzobH0 wvKQ==
X-Gm-Message-State: APzg51AisgrNhMowApMzLicEb7vEY6FAv/WywJnVnlQEczbJlDMU5W60 gKNWNz0rblfDe3dMJrMFo0J3GICI2erTfYzaSEKl6Q==
X-Google-Smtp-Source: ANB0Vda+RtUvaujke2BlAy5qajZTQc2Ej1HKc0PKjqK5/Ddvln0TZDq/bcGG3rMgmPilZbZQBWO4F7+F8B/SNEd0Plk=
X-Received: by 2002:a0c:d842:: with SMTP id i2-v6mr16355801qvj.145.1536631993621; Mon, 10 Sep 2018 19:13:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Mon, 10 Sep 2018 19:13:12 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:922b:34ff:fe5d:efa3]
In-Reply-To: <A037BDB7-C780-4D44-A031-49F39AA3F11F@gmail.com>
References: <153513922907.22939.10542350679349996082@ietfa.amsl.com> <FDA69FDF-696B-4959-AADB-0999630C723D@gmail.com> <CAJU8_nWwHAQYeo4oCVq=dVquRK1VhO-TdUKw5JmvbX1idWa=VA@mail.gmail.com> <A037BDB7-C780-4D44-A031-49F39AA3F11F@gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Mon, 10 Sep 2018 22:13:12 -0400
Message-ID: <CAJU8_nUJ7BLJhgjw6Sa-xeY0=OpK4N2ffKLjZ-3m6+Uiws5wTw@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: IETF SecDir <secdir@ietf.org>, draft-ietf-lisp-rfc6830bis.all@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Content-Type: multipart/alternative; boundary="00000000000021742005758f0470"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/o-sCl0tQ53TL4svSc6q7voYH7zQ>
Subject: Re: [secdir] Secdir last call review of draft-ietf-lisp-rfc6830bis-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Sep 2018 02:13:18 -0000

Apologies for the two-week absence: I've been on vacation (especially from
email) for most of that period.

On Tue, Aug 28, 2018 at 6:17 PM, Dino Farinacci <farinacci@gmail.com> 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.
>
> That really is not true. You need both the overlay and underlay to get
> user traffic to flow.
>

Sure, just like you need link layer connectivity and closed circuits. User
traffic is directly handled by the overlay, which is an added layer of
novel complexity. When you add complexity, you inevitably add room for bugs
and mysterious behavior. Anyway, I'm happy to drop this point for secdir
because this is more of a general architectural observation than something
specifically related to security.


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

What PKI? That's part of what I'm trying to establish. How do entities
decide to trust each other?

E.g., if entity A has pairwise trust with peer B, but needs an EID mapping
for peer C, it needs some way to establish that the replies it's supposedly
receiving from C are genuine. One popular model enabling you to do that
without employing transitive trust is end-to-end signing chained to a trust
anchor. With TLS as deployed on the web today, the trust anchors are a set
of mostly mutually agreed-upon CA certificates that serve as roots for the
certificates presented by every public web server. There are of course
issues with this model (q.v., certificate transparency, Symantec), but its
behavior is well-established and its properties are understood. What is the
equivalent here?

It sounds like the answer here is mapping system-specific. E.g., from a
quick perusal of the DDT draft, it sounds very DNSSEC-like (which might
suggest a course of action to eliminate the need to develop, deploy, and
maintain a custom security protocol, but that is a different discussion).

Where an interface is described without reference to a specific
implementation, a set of assumptions (e.g., "correct routing relies on the
authenticity of mapping system responses") and associated security
requirements for any conforming mapping system (e.g., "entities making use
of mapping system responses must have some way to authenticate them that
does not rely on transitive trust") need to be stated for the document to
be a complete description of a system component. That is, without first
clearly defining the required properties of any valid implementation of
described interfaces, there's no way to evaluate whether the component
under review will do what it's supposed to.

A good place to put these assumptions and requirements is in the security
considerations section: those statements are not normative for the system
component described by the draft in which they appear, but are effectively
requirements for whatever system component is to implement that interface
in a conforming way. Enumerating them as such (in the document describing
the interface in detail) allows the reader to evaluate the requirements in
light of the system using the interface, while also providing a convenient
checklist for those designing conforming systems.

A set of well-crafted security considerations sections also makes it much
easier for a reviewer to understand the security of the system as a whole
without having to understand the details of every implementation, and to
verify that individual system components under review will have the
appropriate behavior.

I'm going to skip the comments related to draft-farinacci-lisp-ecdsa-auth,
just to limit scope here. We can get back to it once that document has been
adopted and more fully fleshed-out.

> "TLS" does not appear anywhere in the draft of LISP-SEC I reviewed:
>
> Right as I explained DTLS does.
>

Check again. Just to be sure, I've tried several tools and the letters "T",
"L", and "S" do not appear consecutively anywhere in this document. Neither
do "SSL" nor "transport-level security".


> > 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 think this gets back to the point I made at the end of my original
review, which is that this system is difficult to evaluate from a security
perspective in a piecewise manner given the dependencies between the
different layers and the lack of explicitly-enumerated security
requirements for each system component implementing a given interface.

Kyle