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

Dino Farinacci <> Tue, 11 September 2018 18:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9E3B130F3F; Tue, 11 Sep 2018 11:39:39 -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 o-PtNdBgFJfJ; Tue, 11 Sep 2018 11:39:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CF881310F3; Tue, 11 Sep 2018 11:39:37 -0700 (PDT)
Received: by with SMTP id v66-v6so12673163pgb.10; Tue, 11 Sep 2018 11:39:37 -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=AztiOreLFTVnp8qlmYs7d77Zo4hb46ypdV01KoBYNVM=; b=niJpgLRQAiLjfMqM5FCdsZwkhDG/SE3VUFbgENQM47PgCbFi2oQPrUs7TqEI6CWinC rJD7d7rsDsYa6VhthY3Vj6COPRrppc2JpxMh/ckWQB0foFVMz9zVTKMBrv3Oi6BepELC n8EDI3B01mLOUl09d56jDLv4Dc2ixX1e/hm+9VRb5OXfwADTCYO97okeqk0gUILIvTRY XSe7swH7rOU9jqsWyxXKy3IAb+rOW6w1VNSgyYnluWptvy5qJUqTiCcjLxE8ZBRBb43w tZpoTonYpCKclho7Pu8xDyoJbtmlsJe+ZLJ/MdiFCtOc0QzcvewpSRPPnBOHCXVKFQNC KwoA==
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=AztiOreLFTVnp8qlmYs7d77Zo4hb46ypdV01KoBYNVM=; b=ZFS6wRsUSGB1IE2QoBZesvi/WSJdve4xyyMxUV9qYg2dXJ5H+heHrzVRuhOdyG1U7L ygeslVeojp6lNN/ik19BoUP4txvb8tbrGxOPdmJVcyPpvasSbBv3Lu5y7IH/5LNzNLUI YMne3m95hEzO/1/swA4dnLHGYyT8ct3NV829xLJ69VZ5alk6ZD2TRLF19shT+9a/QbdW X/wjW021vgEGRw2Xt0SusXOSw2u9VL5TgzkrjNg0otD+cQCYUhCNR1FZLgbmA/YKku1k kgsk0+SEjz07HV11MMT6At2I22Lndl4cMGSZcOkOIzN37sxXmGDHQqofz0ZfSeDhjbGy 85kQ==
X-Gm-Message-State: APzg51CFBmxYueS6Bz9/gve1hqziFI/zVNkAGNuC4IqfyIgj+x+nYbE5 gx0cQHDlYiIJ5h0h1U8WaV8=
X-Google-Smtp-Source: ANB0Vdbz48U5j4hJzURxSoCc9bhaz5HViBv0nbqq84RFBq8MQ4UnssLN0IcIfDxlXtXX+LPFnXRCHw==
X-Received: by 2002:a63:fa0c:: with SMTP id y12-v6mr30153378pgh.177.1536691177176; Tue, 11 Sep 2018 11:39:37 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id n83-v6sm36696042pfk.19.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 11:39:36 -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 11:39:35 -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 18:39:47 -0000

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

Yes, a map-server is delegated part of the EID-prefix space for any more specifics prefixes registered to it. That is what the parent of the LISP-DDT sends referrals for.

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

Yes. A delegated hierarchy where the parent provides the public-key in referrals so when the child signs its referrals, it can be verified (by the map-resolver).

> 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

Yep, correct.

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

Right, that is in the LISP-DDT spec on how map-servers should behave when they run LISP-DDT. Remember that 6833bis is how the xTRs use the mapping system to talk to map-resolvers and map-servers (as well as xTR to xTR for probing and map-replying, etc).

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

Do you think (need opinions from the chair), that if we put a document tree in draft-ietf-lisp-introduction, would that be helpful? The only drawback is that we may get a circular dependency. But could avoid it by having:

(1) Have lisp-intro point to 6830bis and 6833bis.
(2) Have 6830bis and 6833bis point to 6830/6833
(3) And none of the 4 documents point to lisp-intro (obviously RFC6830 and RFC6833 do not) but the new bis shoud not.

But that is not good for the reader, because if someone picks up 6830bis and realizes they do not want that level of detail, they don’t know by reading it to go to draft-ietf-lisp-introduction.

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

I’ll yield to the WG to respond to this.