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

Dino Farinacci <farinacci@gmail.com> Tue, 11 September 2018 15:29 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF4E130EA4; Tue, 11 Sep 2018 08:29:58 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 svvOyvUcLcj8; Tue, 11 Sep 2018 08:29:56 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 1D686130EA1; Tue, 11 Sep 2018 08:29:56 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id g2-v6so10542824plo.2; Tue, 11 Sep 2018 08:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jF+8TQINnxPKjifCU3kT3vw3vissMNt7qkMzv0fUuFA=; b=b2lGTiX4u3yD62pZXqOzcZjeeIn2ZvCeenvaPjqdAg+ovHZqeJd5FpehdKvTO1zxzG toquadjCLSZ77xdZSuLf1gU7RD0IAYUB6v+cs7MveMBT2lEuZmvziDmigK4SR4GCUcIj pFl7RP3u0uAKpUP10GL9uFwFPEF8zTw44gMXoaV+8EtLBJYbDBwTaTItdbB0rDkH6jnd gYDFHAQ1vy5OlUgRu5vaaVEnTp1Y+wKnRYLd7Js/xK1WBiTW2iFwCjAn4D05+FxHhWc3 XmFK530Jno2WWl6dcboc1eqcr6+NwKCsUKIBkHv46soXw12en0kLPU5G5B8yhQ4w/8rl tJ0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jF+8TQINnxPKjifCU3kT3vw3vissMNt7qkMzv0fUuFA=; b=duzOobK/TT7A1lqmCyWrhKG3c0IIryY4pIZi+7Ya6Mnau8kXDg2GAM4H/he8tvhhXc TGEbj6d5q1Z0SPX52ECvEJjLZLSw7Loln7wbVExSrDC39xCkIUpZo4hX6sMyLKrtJwsC dBxD+OLcIzmHS3EQfMz3es9Yc3n59GGeNZ3JVgFY8WdS4Vi5JY/rMTrkf/OYtGZgxpO3 3l8oOobH79Hhvp/yCou859Zl8Cc1s/npAk1tcGSpKkoNBY+eHYvfe9Cq029/0GftmoB9 r8WMspjX/I05Rl0FmMN2DOGl9bd2hU8blL1mTVFEpWSeqQGZ4SEiqqKvVpJhMuZ5bilP WyLA==
X-Gm-Message-State: APzg51AfyMpvodYd0OaAIZe/CFyWAP6dsp/mrDTb2ZgYYUJirQ4cQBdt YI4wNuFhc4Ob4NqAzLnZNdUrbuSA
X-Google-Smtp-Source: ANB0VdYO30ybDhXU8bKuUb7aM6tT5efPYpTj0x4E8ihBYwYPFQvg3LVXOG0kGoGrvTl7PB3PlC9RZw==
X-Received: by 2002:a17:902:6b0b:: with SMTP id o11-v6mr27751810plk.214.1536679795621; Tue, 11 Sep 2018 08:29:55 -0700 (PDT)
Received: from [10.31.79.252] ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id f184-v6sm40166076pfc.88.2018.09.11.08.29.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 08:29:54 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CAJU8_nUJ7BLJhgjw6Sa-xeY0=OpK4N2ffKLjZ-3m6+Uiws5wTw@mail.gmail.com>
Date: Tue, 11 Sep 2018 08:29:53 -0700
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-Transfer-Encoding: quoted-printable
Message-Id: <430EA55E-6D40-45A1-99D3-0978F1B20038@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> <CAJU8_nUJ7BLJhgjw6Sa-xeY0=OpK4N2ffKLjZ-3m6+Uiws5wTw@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/avyzRsKrGChTal_1PQNUI1K4Tf4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Sep 2018 15:29:59 -0000

Responding. The draft-ietf-lisp-sec authors need to respond to one of your points below about DTLS.

> On Sep 10, 2018, at 7:13 PM, Kyle Rose <krose@krose.org> wrote:
> 
> What PKI? That's part of what I'm trying to establish. How do entities decide to trust each other?

The xTRs has a trust association with the mapping system because they have (1) a business relationship with them and (2) a shared-key that is used to verify Map-Register messages. From that, Map-Registers and Map-Requests are can be signed where public-keys are stored by that trusted mapping system. That is what is documented in draft-farinacci-lisp-ecdsa-auth-03, and soon to be draft-ietf-lisp-ecdsa-auth-00 (hopefully).

> 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

The mapping system allows all of A-C to trust each other.

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

The designs are done, the references in the various specs are modest because of the state of the documents. We are sorry for it being hard to navigate. But for me, I am for less documents versus more, but the working group wants more modularity in the documentation so hence why all the pieces don’t seem to be connected (but they are by the security design of LISP).

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

The draft-ietf-lisp-sec authors need to comment.

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

I don’t know how to move forward from here. I think we need help from the lisp-chairs and Deborah.

Dino