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

Dino Farinacci <> Tue, 11 September 2018 16:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 31771124BE5; Tue, 11 Sep 2018 09:56:54 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yJHpRKdXDy6L; Tue, 11 Sep 2018 09:56:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EFF4130F0F; Tue, 11 Sep 2018 09:56:52 -0700 (PDT)
Received: by with SMTP id b11-v6so12537958pfo.3; Tue, 11 Sep 2018 09:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vb2pwHTPakpIw9AeIdXU3iHbXJjZgAedb3A6VO4p3tI=; b=BonI908U8DqsV4EKB+sBQN8QYEcnBEznAbt6uKC89E3jna8KUxVhyccB2mHHmJmtQD EhwXpgTUH+qI0NJamdamfLiEs8UQokFElP0ATSxVhOjyRnGVT4RFwOn1mjA5Iy8BhFCG +KaeUG7ijmHIap4jIvSt8OkVeqp2cUgX1+03UY/gsmvBonSIXUkgHJdCLNQKUMbCed5V beBPg0jZGCy0nrs6E/iGd0ebfdRCqvH37CuZ4/abXPCRF6rDfPVzoDwo4MxePtPm+dfs bACjVllRu3PFhnPXl340jkrU6qrEpIiiRYk6abVubCFuYSKB0bNFNRFn4wzlQzc7YVsm eBZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vb2pwHTPakpIw9AeIdXU3iHbXJjZgAedb3A6VO4p3tI=; b=UaLhyXgsN+UJOZZ7Ga/ta9m4b7h0bD3nRkmjPYxC07w83Qy3fssQukTMlWWY2PbFAC +DqK2wZaR2u+RLMqLPYrvMTff0XQk0CXuvYTgDJQIKoHvZMAh6uPLjfXkQRqSlUUhR84 qp4yxKYmUmuE8GUW9IdCoQ/6hDzOvi9/fxeC5nOqV7IYLvDlDPeVmhtOAs7IdNaiKuRb 0P8BlN4Yg43S+AwtHwJN1xwJFIxo9ETJGMSXR6V4Cc7sWQkF8I7u2bI9OG63bUwFBKtH rMyc5F8rIgqzuuW35jXMf7Ypk9I+bgYMfj6ntB8bGVNAXUMYRhINcwfmV0g5fvfs3IC8 9rRQ==
X-Gm-Message-State: APzg51ARLRpcLkYiTpUgX5se/BVPIe4zLXkVmwaWCrSkAVy5QoaXUtnS nbNQEHkNW14b589ugXlWIqs=
X-Google-Smtp-Source: ANB0VdYsJZ7wEBHUQBxSuoPbmVKvt8zSTb3WXmIl38BEhKoj9D2AIA5k0sWHtsK7GtUR5a/i6UZm2A==
X-Received: by 2002:a65:5304:: with SMTP id m4-v6mr29746960pgq.250.1536685011575; Tue, 11 Sep 2018 09:56:51 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id r87-v6sm44078833pfb.1.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 09:56:50 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Tue, 11 Sep 2018 09:56:49 -0700
Cc: IETF SecDir <>,, IETF Discussion Mailing List <>, " list" <>, Benjamin Kaduk <>, =?utf-8?Q?Mirja_K=C3=BChlewind?= <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Kyle Rose <>
X-Mailer: Apple Mail (2.3445.9.1)
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:56:55 -0000

On Tue, Sep 11, 2018 at 11:29 AM, Dino Farinacci <> 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.

(1) A, B, and C register their mappings to the mapping system. They have a trust relationship with each of their respective map-servers.
(2) Those map-servers, who participate in the same mapping system and know about each other via LISP-DDT delegations, can sign referrals to tell map-resolvers that A uses to look up mappings for B and C can trust the map-servers of B and C.
(3) The map-servers can proxy-reply with the mappings for B and C to A. Or B and C can Map-Reply specifically with signed Map-Replies according to draft-ietf-lisp-sec.

Do I need to say more?

> I agree with, and am not taking issue with, modularity: no one wants a monolithic design for something

I was talking about the docments being modular (but the design is obviously so as well).

> 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

And they should be by how the reference each other. If you think there is text that makes assumpiton without a reference to the particular draft, then we can add it. 

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

Yes, understand. The LISP design, especially the security design, as evolved over 10 years. So having continuity over that long period of time with work items as well as people has been challenging. And with the IETF process to boot, it was more difficult. I’m sure you understand this.

The best I can offer is, that you tell us where you are confused at a point in the text and we add text to clarify it. But the problem we have is that the IETF process will not allow us to reference documents that are more inmmature than the document referencing it.

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

Well, we have, and each generation of people that come along want more changes and more consumability We are doing the best we can given the existing parameters, for a decade.  ;-)

So I suggest, you look at something and say “I think this is a bug”, or “I see something missing here, is there a design and does it need a reference”. I don’t know, that’s the most practical way I can see moving forward.

I think we are going to have the same issues/recommendations for Mirja’s comments as well.