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

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

Return-Path: <krose@krose.org>
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 2FBEE130E5A for <ietf@ietfa.amsl.com>; Tue, 11 Sep 2018 09:40:55 -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=ham 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 Kk1Tpts4KXfo for <ietf@ietfa.amsl.com>; Tue, 11 Sep 2018 09:40:52 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 95CBB128CF2 for <ietf@ietf.org>; Tue, 11 Sep 2018 09:40:52 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id f17-v6so17146163qkh.4 for <ietf@ietf.org>; Tue, 11 Sep 2018 09:40:52 -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=/bpDNXkFidMPnjzTu4buW2A9tvBBViqCUENYjpd+OGk=; b=IcxdOu9RnireLun38gdIlCHIHBEwBeLqLpyVuRY1bPhRvrKAGpSQqToMbIG6QakA+t R3eyVXnc7HwAIUgjieCatDXK7rN/sqBXvYZ5e8dNGyz+tOJosB9F2ZtvqK/ScoW9biWn 9S3h11G7jaPvXCkHGqb+u49hnHpYiHPFquklk=
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=/bpDNXkFidMPnjzTu4buW2A9tvBBViqCUENYjpd+OGk=; b=P+aojSnK8L1+P6jJSElDzGqlmfG9bPI/3bWc1k0dXacOviQ4tyQPrLfnKCd6YkJWD1 675252anQUaUHydt9RqDv5+opLcusPZocxIAhor88ADG+H/t7mQgM4EAsfSzLlXuMZC4 BkGwZe/a8rtpmf6kUY4jkTeAaWw5RBItUJ4TQgZuPYo09wGpKVSkeUBwDYeD+Orx6Yhs Yy/g9uqr4xQr0B0V5y1a9bXumVIVu+4gVRbLrZsJYxVN4m9fDioLQLZTamU8xo0mg9eQ W+LGPsuwFhaICcp+NYtl3zIDOy2RWSQXvlpe1XEtxpXvlT6Hlq3LTKnst6voLMIunocB nN/w==
X-Gm-Message-State: APzg51Djs/ybJj2x8cuAiXhaG23GzCrYZO+HPcH+2/nM1Im9F9QJE7Ga AP6QU6PskZKZrYfq+6uy4Nmd8bpseHvAzWUnnbiliQ==
X-Google-Smtp-Source: ANB0VdZJTTV7/fT4BuuinqLkoEJJv4A65jrWrsFpVjdBAk+wFlnC9zsiepzUlSiM44b4QsK0W89aM8+oJfP8yKnXEdU=
X-Received: by 2002:a37:2381:: with SMTP id j123-v6mr19155128qkj.259.1536684051442; Tue, 11 Sep 2018 09:40:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 09:40:50 -0700 (PDT)
X-Originating-IP: [2001:4878:a000:3000:b804:b2b6:546:6e10]
In-Reply-To: <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> <430EA55E-6D40-45A1-99D3-0978F1B20038@gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Tue, 11 Sep 2018 12:40:50 -0400
Message-ID: <CAJU8_nXyEn7y_Me2GrFdDbedA2_CTbznLEw_GBAhu-4Jb_3Y6Q@mail.gmail.com>
Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15
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="00000000000004c5aa05759b23ed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Zpa6jCwPOxmaKYbu9LI2mxiBmx0>
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 16:40:55 -0000

On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci <farinacci@gmail.com>;
wrote:

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

Explain how with a detailed example, or point me to a detailed explanation
in a specific document. The mechanism is still not entirely clear to me. If
A and C don't have an established business relationship, how does A know
that the responses it's getting for EID mappings owned by C are genuine and
not modified by B? This is a critical property of the system, and so it
needs to be made obvious to the reader.


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

I agree with, and am not taking issue with, modularity: no one wants a
monolithic design for something this complex. But the interfaces between
the documents, by which I mean the requirements they impose on each other,
must be made explicit. When a system achieves complexity warranting design
modularity, it's simply not sufficient to describe individual system
components without providing a framework for analyzing how they fit
together without having to read and fully understand all of it. All the
information *might* in fact be there, but as an outsider not implementing
LISP, and with finite time to review, asking me to understand the minutiae
of the entire LISP ecosystem in order to understand the security properties
of the overall system is simply not reasonable. I should be able to consume
a high-level architectural overview, containing sufficient detail to
understand the security properties of the overall system, and then use that
to drill into areas of concern more deeply. This is why I want the
high-level security requirements documented somewhere, along with a set of
high-level explanations of how the proposed system components combine to
satisfy them.

Put another way: as someone whose day job it is to read and review design
documents and to offer architectural consulting on everything from from
network architecture and hardware design to build automation and SDLC tools
to dynamic job orchestration and application security, being able to
achieve a high-level mental picture of the critical properties of a design
is an important first step in evaluating a system's fitness for a
particular task. Document authors have a responsibility to make their work
consumable by people who don't already have the full context.

Kyle