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

Kyle Rose <krose@krose.org> Tue, 11 September 2018 18:29 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 8A1FC130F0A for <ietf@ietfa.amsl.com>; Tue, 11 Sep 2018 11:29:02 -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 vfSJBaQxk75q for <ietf@ietfa.amsl.com>; Tue, 11 Sep 2018 11:29:00 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 D391E130EDF for <ietf@ietf.org>; Tue, 11 Sep 2018 11:28:59 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id o15-v6so29293739qtk.6 for <ietf@ietf.org>; Tue, 11 Sep 2018 11:28:59 -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=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; d=1e100.net; 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=DAILrM2Y23AZc01OgTmfNsD/dQjblArCDq3SmUKZUITfnhZwo72Ivahskmj8MdRAV4 /0uT/ssCGNxOIRH+SUjuiagWCvwklb+ibGhHOwnNycbxV7zgQr2iGMO3dHKHZHV7qGBX FDtw8t1ia89Qc+w3J7hEaBMeGLBUA5RK0OTKUJtjaB+LoB0rcdhLZP+Yy4xGJ+yPJI7+ Jd55vj2kmS76v4WI7kanFsA0musObZgsVooHtjETgMSzIXPhfaU4LSNBu1SkMt9qGgVR /WrEN7GpCEJypgP5l7hyXyZyS6eCijLQFMTPBRxRpLfspS1WzDZspTkC9h2fSoy2/LFD IoTQ==
X-Gm-Message-State: APzg51AodF1CEUeNXAOg04/D5HwFlg/wjzrQzGRkZIoscPbq0/7M7QqG bT4Tjbo8ldYkmmyyeca7HyLD5718Kfnar+QcVMy/Wg==
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: <8025C400-D41F-4A6D-BC14-6A50E80F854D@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> <CAJU8_nXyEn7y_Me2GrFdDbedA2_CTbznLEw_GBAhu-4Jb_3Y6Q@mail.gmail.com> <8025C400-D41F-4A6D-BC14-6A50E80F854D@gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Tue, 11 Sep 2018 14:28:57 -0400
Message-ID: <CAJU8_nX+LkDy3HucYzVLO0R_ft6NbABKcGq9Ac+esNBHcVuehw@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>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Content-Type: multipart/alternative; boundary="000000000000b1a6ab05759ca579"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ujQ033EFg8fF0zW3RJCNcSYtoiw>
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 18:29:03 -0000

On Tue, Sep 11, 2018 at 12:56 PM, Dino Farinacci <farinacci@gmail.com>;
wrote:

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

Kyle