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

Kyle Rose <> Tue, 11 September 2018 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C1B9130EDF for <>; Tue, 11 Sep 2018 11:29:03 -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 SrUYgBSSN3M7 for <>; Tue, 11 Sep 2018 11:29:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7BE01292F1 for <>; Tue, 11 Sep 2018 11:28:59 -0700 (PDT)
Received: by with SMTP id g44-v6so29268040qtb.12 for <>; Tue, 11 Sep 2018 11:28:59 -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=uqfGIHyqdRJg9C/LgAfTR+iwx8At3KN+RnIb+avIy3U=; b=GuZZK0L2CmE8LYrs74YbN/rvqd/rRQgw8YwvKWKRZUm4/SjDgLfYG3Uu5eG3Vi98Sa hEuYitNEQmbv/T15CHhTkzE+5IPVRHnR7RkKM3Ao08i+amhnGtJ2JWDiydI0sAdbJyES AV75EOaw5zRL+j2XHBtvWwNyXzk0rq+YAfQ7w=
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=uqfGIHyqdRJg9C/LgAfTR+iwx8At3KN+RnIb+avIy3U=; b=Zv+Bw9xeryWVc3BHCIOwdMiv1WiT+tzUPQqFH0RgdT+GB10TPZpyld553VYYRicyG8 w08/yOX1lCxQwfhRO+TCjjB9x0UtSUb3uKErGzUTc4zjieLw1mMfcRUvPn91rWyZYND1 6BGSPgvZM/EScS2VKzRWNmVnmdjGwxA5dNwaMsI3DJu6yOG5z9EdYUj4+BOlMpHeAw2U qdTBnqP65xoLtVBYQbavsPnZ0eYUpr3bzVkXXUPFW2T4Uxym6PuAnA1+GvDYgOkDvpHP gYygxbwvbmKuED+6g+I+BPta6r0GXshz329/yRGhOlYBqj+ZHoGSGm3DfusJ49EOuumV 9kQA==
X-Gm-Message-State: APzg51BOpRtk32sWjW350R35oyjJThIWxDnX8ZN8hpOhOUSrlKyPqx2/ g4bzOXCJFQ78QvvygugbhD4vXNcS5GFr1TH1AgxEmXrZRRVVaQ==
X-Google-Smtp-Source: ANB0VdZ36Pkhzwphir62bgtPqW5Pdwy2aKcS6V3Yv0MjDRjhWS2WVoVu7dTEUjVlB+qp9wXw9zeaFDhjH2si8HgDPyw=
X-Received: by 2002:aed:3d48:: with SMTP id h8-v6mr20758589qtf.222.1536690538778; Tue, 11 Sep 2018 11:28:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Tue, 11 Sep 2018 11:28:57 -0700 (PDT)
X-Originating-IP: [2001:4878:a000:3000:65c5:5df1:11df:7dca]
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Kyle Rose <>
Date: Tue, 11 Sep 2018 14:28:57 -0400
Message-ID: <>
To: Dino Farinacci <>
Cc: IETF SecDir <>,, IETF Discussion Mailing List <>, " list" <>, Benjamin Kaduk <>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>
Content-Type: multipart/alternative; boundary="000000000000b1a6ab05759ca579"
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 18:29:03 -0000

On Tue, Sep 11, 2018 at 12:56 PM, Dino Farinacci <>

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

This is definitely clearer. The trust relationships appear to be:

 * A network trusts a particular map server to be authoritative for the
entire EID/RLOC mapping.
 * The map servers trust the LISP-DDT root: they use LISP-DDT to publish
and resolve EID/RLOC mappings, and can directly authenticate those mappings
because they are signed in a hierarchical fashion (like DNSSEC).

The first is a transitive trust relationship, but this is probably
acceptable because it's only one hop (I'm trusting someone else to verify a
piece of data that has been authenticated end-to-end) and there is a direct
business relationship between the two entities.

The second, if I have the general idea correct, is very much like DNSSEC or
the web CA system in that a compromise of a node in the signature
tree/forest leads to a loss of authenticity for that entire subtree. This
is not disqualifying: clearly, many standardized systems have this
property. But it's important to state it explicitly so we can at the very
least make the properties clear to operators, and potentially recommend
and/or develop mitigations.

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

What I might recommend is either an augmentation of, or a new document
analogous to (and informationally referencing),
draft-ietf-lisp-introduction that covers the expected security properties
of the overall design and the requirements for each of the subcomponents in
a way that someone can understand without referring to any document other
than the high-level architecture itself. draft-ietf-lisp-introduction is
actually quite good at getting the general point of LISP across to someone
new; I want to see something similar for LISP's security model. I think
that's going to be better than inserting clarifying text here or there.
I've actually read enough of this stuff at this point that I'm not sure I
can enumerate exactly what's missing where. The threat model document could
potentially be folded into that, but it has to start by painting a picture
of the security that someone new to LISP can quickly understand.