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

Dino Farinacci <> Fri, 14 September 2018 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA3C412F1A5; Fri, 14 Sep 2018 09:59:55 -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 uwhzw4Aj2nWv; Fri, 14 Sep 2018 09:59:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 101C412F1A2; Fri, 14 Sep 2018 09:59:53 -0700 (PDT)
Received: by with SMTP id ba4-v6so4469006plb.11; Fri, 14 Sep 2018 09:59:53 -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=mo54qbWH0tRtE4JAYcaR98ceC89lF8vUl+TanjlalTs=; b=A8k6A832onnetWSS3kBKVwFnsWOo6mPVNwYedkz9o/wBn6SVSeoime3CwQUDSiOnss XmDoUkH28ZfKIHsWaNL9+urZXEf1GEj1iB/VsA5tcjpwE79XRDAsx3wuE/d//9zEM3A/ f2l3VBOluiiA3TtNV4DyLYMEvJz8qsYkTepeavcl56RLL/XE6ZSNeLbFjW9i2/HPio4P AhQAB4350AAPi/JQlbGG0dqxoGbkchZIQwpbNzOOAeDHBVZ7yU77VUgm7rK57BUZrkMF +HAHgbo7B3GRtRGXJKstjh0Wew6uiaH+uP5KWkxAr8cZ3UU2FTcEGX107FnUrbnK9A/Q Azjg==
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=mo54qbWH0tRtE4JAYcaR98ceC89lF8vUl+TanjlalTs=; b=OKnQl51BF+Lc1xAB6SdOUn66tHmVSbYCYDFxYzKzfH/UcXBUv07HO4XZHmO0SGR/TF Jyur3IcwqYcFs14ZuE5CVmTf9/W/zM0cdnaDRPOZiY3vZVDA2hnoKMybsr7pgn4/9A1n qbjqcAKaEGEv+ze+vTTf4u/RxPaKQHxu7zWxLsUqyFCNJN9wiegIH09oJpNV6E9M6lNp FgTqA1sVC8GIRLvQSOmrfQOA+Ivk7U3X3UIQfYdZRg7/aaIqnc6ZP/44TNFrPJbhAvFU XQG9hdFyRBNpuP4a/z97irnqMq6UiD5CAm4PpPB0nG6is/8XcqqiTOjVvlwGGKWTgKUF g/YA==
X-Gm-Message-State: APzg51CiLNg4ru2JBJtlWCsUuePkJg+f3eJgZCx9SecnrMruWMFCKVPT 8V/p3d5FViPm2vp7yWBZ79E=
X-Google-Smtp-Source: ANB0VdajRObVIN//dyk8GgKn2rqzjZ2ApTf+Zw52gxy3P8IWvrOyHtA6W8hWtn5nh7oabGGyYJ9rXQ==
X-Received: by 2002:a17:902:543:: with SMTP id 61-v6mr13335471plf.126.1536944392529; Fri, 14 Sep 2018 09:59:52 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id y124-v6sm10886408pfg.63.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Sep 2018 09:59: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: Fri, 14 Sep 2018 09:59:49 -0700
Cc: "BRUNGARD, DEBORAH A" <>, 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: Fri, 14 Sep 2018 16:59:56 -0000

The SAAG has helped the LISP WG with RFC8061 (data-plane). And Brian Weiss and Dan Harkins were authors/reviewers.

As for the control-plane, draft-ietf-lisp-sec has been around and implmented by cisco (in 3 implementations). RFC8111 (LISP-DDT) has been around as well for a while, a pilot network deployed using it, and cisco has an implementation of LISP-DDT-SEC. Draft draft-farinacci-lisp-ecdsa is relatively new, necessary for IoT deployments. I have done an implementation of it. I don’t know if that helps but focusing on those 3 documents can clearly explain (in detail) the security mechanisms in place.

Your comment is noted about not seeing TLS or DTLS in draft-ietf-lisp-sec but we had always intended it to be in there. I’m not sure (I thought it was in) if it was removed for some reason. The authors can comment about that.


> On Sep 14, 2018, at 9:29 AM, Kyle Rose <> wrote:
> My response is that while I suspect based on the conversation between myself and Dino that LISP's security model probably adequately protects mapping system integrity, my confidence in that judgment is low because the information I need for a security review I can't find in the drafts without reading every LISP-related document in detail, a time commitment I simply can't justify. It's possible there's someone else in the security directorate who knows more about the details of LISP and so would be able to much more easily answer some of these questions with confidence; if so, I would recommend that you ask them to take a look. I'm unwilling to say "LGTM" simply because I can't find a problem in the time I've allocated.
> Kyle
> On Tue, Sep 11, 2018 at 5:55 PM, BRUNGARD, DEBORAH A <> wrote:
> Thanks much Kyle for your comments and Dino for resolving!
> Cutting to the end where Dino asked for help-
> -----Original Message-----
> From: Dino Farinacci <> 
> Sent: Tuesday, September 11, 2018 2:40 PM
> To: Kyle Rose <>
> Cc: IETF SecDir <>rg>;; IETF Discussion Mailing List <>rg>; list <>rg>; Benjamin Kaduk <>du>; Mirja Kühlewind <>
> Subject: Re: Secdir last call review of draft-ietf-lisp-rfc6830bis-15
> > 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.
> Dino
> [deborah] 
> It's difficult to do *one* overview document on an evolving technology, especially if the intention is to provide reference to other documents which are also evolving. Lisp-intro is already having its problems and it is not published yet.
> As Mark Nottingham noted in his "How to Read an RFC" blog, when reading RFCs, for better or worse and the resulting frustration, it is "necessary to read not only the relevant text but also anything that it references":
> I'd suggest a wiki would be a better tool to capture this "overview" informational material. Not only can the format be easier on the eye, it can be a shared effort and timely updated. Similar to Benoit's work on his YANG tree dependencies, it would be helpful if a working group provided a working group tree of documents and it could even reference other working group documents.