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

Kyle Rose <krose@krose.org> Tue, 11 September 2018 16:48 UTC

Return-Path: <krose@krose.org>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE57213112F for <lisp@ietfa.amsl.com>; Tue, 11 Sep 2018 09:48:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 w7NRZrGvEeUP for <lisp@ietfa.amsl.com>; Tue, 11 Sep 2018 09:48:34 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 C47FF1310D9 for <lisp@ietf.org>; Tue, 11 Sep 2018 09:48:27 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id z125-v6so17175227qkb.12 for <lisp@ietf.org>; Tue, 11 Sep 2018 09:48:27 -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=X2fhHEN+ZyCDFM3jVfcRm0t4+SP+/VD37ofszG8PoIQ=; b=YqxbVYgVGtA8kgLeDad2fNIMYHLG9KdrLEqIEDOjKSZi2ktZAutSJ3M41D9WbieiJY NPn3MhWT5QRhPHLCk8I/uMBrpg7ANSZJnN1kkV6d28/+B+tZL7WcB/xjuqVVlvr9YTm3 jZ+ygM/vfIZ5qCeidT8Awe9RG+bBAIfmLz4Hc=
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=X2fhHEN+ZyCDFM3jVfcRm0t4+SP+/VD37ofszG8PoIQ=; b=m/AKjz0PgYyLv8juQQe/1yuyoZP7MaRtPXNfgAn2+90UoS1h1tM+iWADpBKIN+bVsT BHIV2A2XJHJ/MYyWgzonjp/x6Q1G65xJD+nEa9mHdJ5G99psM0RcizKqJ5VQyw6zV+7k dChOfEGzi9l6/ugqcAneqcKsSa9VozZZQ6UnGchx4AJoAGVFpvowX17l4N95tmdOgH0U ZNhP/4NNuwT+Oz/Ox34UA9HuhLrg+FWACjhhFhzSBDK4mxim0vAh+sWCfLGe9+5nrAUK QVqVKCKjXdbYJs8ebnmUqR0yGu9qDJMw9lC6W9/9tsvojiR8z7aMckTQltGK3Nx3Eq4a eu/g==
X-Gm-Message-State: APzg51Dsn5AAsDD0LrnxG0mzQrpPx7Uc6IFWDkhTwAyHoFbWfIV45tCx pdblG6G7ztGg9iUe4n7cp2BltTHN/XDZk758zkVCjA==
X-Google-Smtp-Source: ANB0VdZMmNcAFB01I++cNiK22cTaKGOVmu/jyc6u6v0xrl4FAhl81RwXLUK1cvKTD4Fya0ivPUhJIxuZlfTAthvFH/U=
X-Received: by 2002:ae9:e8d8:: with SMTP id a207-v6mr20018909qkg.235.1536684506663; Tue, 11 Sep 2018 09:48:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 09:48:26 -0700 (PDT)
X-Originating-IP: [2001:4878:a000:3000:b804:b2b6:546:6e10]
In-Reply-To: <77109099-A756-4563-968C-5AC17FF38291@gigix.net>
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> <CAJU8_nUJ7BLJhgjw6Sa-xeY0=OpK4N2ffKLjZ-3m6+Uiws5wTw@mail.gmail.com> <77109099-A756-4563-968C-5AC17FF38291@gigix.net>
From: Kyle Rose <krose@krose.org>
Date: Tue, 11 Sep 2018 12:48:26 -0400
Message-ID: <CAJU8_nX9mNZ=DvQoCmqzptWfK10G+HpmOx2L+LAH-srNJRuXuA@mail.gmail.com>
To: Luigi Iannone <ggx@gigix.net>
Cc: Dino Farinacci <farinacci@gmail.com>, 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="00000000000026e15b05759b3ef0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/eME-7GQA8sN_KF9LfdJWdYeizMc>
Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Sep 2018 16:48:43 -0000

I agree that the first point is probably not secdir-related, but it is
still something that should be addressed.

To the second point re: RFC 7835 and resource attacks on control vs. data
plane, what I want to see is an analysis for operators of novel attack
vectors that are created by LISP. For instance, the threat mitigation
section says:

q( The control plane is the most critical part of LISP from a security
   viewpoint, and it is worth noticing that the LISP specifications
   already offer an authentication mechanism for mappings registration
   [RFC6833].  This mechanism, combined with LISP-SEC [LISP-SEC],
   strongly mitigates threats in non-trustable environments such as the
   Internet.  Moreover, an authentication data field for Map-Request
   messages and Encapsulated Control messages was allocated [RFC6830].
   This field provides a general authentication mechanism technique for
   the LISP control plane that future specifications may use while
   staying backward compatible.  The exact technique still has to be
   designed and defined.  To maximally mitigate the threats on the
   mapping system, authentication must be used, whenever possible, for
   both Map-Request and Map-Reply messages and for messages exchanged
   internally among elements of the mapping system, such as specified in
   [LISP-SEC] and [LISP-DDT].

   Systematically applying filters and rate limitation, as proposed in
   [RFC6830], will mitigate most of the threats presented in this
   document.  In order to minimize the risk of overloading the control
   plane with actions triggered from data-plane events, such actions
   should be rate limited. )

but this doesn't specifically address the fact that a pull-based control
plane will fail in a different way, and one that is potentially harder to
diagnose, from a push-based one. One area in which it differs is that a
loss of a BGP session followed by a network partition is obvious to all
users trying to move traffic between those two networks, while choking off
control plane traffic in LISP may only affect some endpoints in a
mysterious way.

Kyle

On Tue, Sep 11, 2018 at 5:17 AM, Luigi Iannone <ggx@gigix.net> wrote:

> Hi Kyle,
>
> good for you having a break, hope you enjoyed your vacation.
>
> Any thoughts about my last email on the subject?
>
> Ciao
>
> L.
>
>
> On 11 Sep 2018, at 04:13, Kyle Rose <krose@krose.org> wrote:
>
> 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
>
>
>