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

Kyle Rose <> Tue, 11 September 2018 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 722E5128CF2 for <>; Tue, 11 Sep 2018 09:40:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2_O6peiTZLSI for <>; Tue, 11 Sep 2018 09:40:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95BED128B14 for <>; Tue, 11 Sep 2018 09:40:52 -0700 (PDT)
Received: by with SMTP id f62-v6so15453387qke.2 for <>; Tue, 11 Sep 2018 09:40:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/bpDNXkFidMPnjzTu4buW2A9tvBBViqCUENYjpd+OGk=; b=mC73jjvcClys19h6g5sgHjkw91JYMQXiqAa3XvVbDiE2zZhWEZh6XtNGgD/7tS1+e6 CfmocBZuUCw1MbNti5Mov9/EBk6k1ot8BI4u7SYl9dZ/7YnDt14ONlVzCbg0xDmZyNR0 QK0llEkzu3WiVvitrNJZjoBiUWaH4RXQI0qEvpbRz8T1Ba1pBSUpAUy205tV2ySKh/yD 7W4jNmVf+goTncy+1gaSNp5yZaYTfCrL+F6oNeGyWRivwauZn4NR3jMYtLq/p+Ce+bkb wLR1YT47uWLOpXat8648UhXudl4xkS/bRJqbxopTc921hdyQo7JNy+EcZPg0a7gH9CRZ QLNg==
X-Gm-Message-State: APzg51ArmBw+CpzdCtkpsweOu6cwvfCn1LbPjOsTeaHOAfWrMRbJNG8p DXnxibFsiaQxYepO69BXsfLJXdM7/ex3l7zLOvhnrQ==
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: <>
References: <> <> <> <> <> <>
From: Kyle Rose <>
Date: Tue, 11 Sep 2018 12:40:50 -0400
Message-ID: <>
To: Dino Farinacci <>
Cc: IETF SecDir <>,, IETF Discussion Mailing List <>, " list" <>, Benjamin Kaduk <>
Content-Type: multipart/alternative; boundary="00000000000004c5aa05759b23ed"
Archived-At: <>
Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Sep 2018 16:40:58 -0000

On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci <>

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