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

Kyle Rose <krose@krose.org> Fri, 14 September 2018 16:29 UTC

Return-Path: <krose@krose.org>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D26130E27 for <lisp@ietfa.amsl.com>; Fri, 14 Sep 2018 09:29:45 -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=unavailable 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 CeGC6N6ta_nT for <lisp@ietfa.amsl.com>; Fri, 14 Sep 2018 09:29:43 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 6F96C130ED9 for <lisp@ietf.org>; Fri, 14 Sep 2018 09:29:40 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id f17-v6so5482353qkh.4 for <lisp@ietf.org>; Fri, 14 Sep 2018 09:29:40 -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=b5c7FPOJ6pJCRorfhF09I7Tks+dLbalRHND+IhlYpbg=; b=GohL8Nm0NPVR1kazJCDKRby0T3wFwQa8rqSu+hiDzm/EB+1osiMl6VbA1YHmqMSkIh EZCI1KTBLXUpxpKRJpOPwymyayX8gGdx+dFkNnHMAP5tKGOwCz25fPg1w2O1DDMot2zv MQh7YnhJWMXoPYsiJlyCggYXbzItTbtjLYAYg=
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=b5c7FPOJ6pJCRorfhF09I7Tks+dLbalRHND+IhlYpbg=; b=Sz80C/+lWhzftED9Ob19mWuGkhEMMGRHO+sKydvc4eUcNjBsONqXOg13YMQTJc61jD D2fAJ33h9tU7+qIGT1im5PeA6wqOUbvA/ocJVFL1Bvzjh2JYxJ+DZ4TzboN2tvWAZla2 fxjT0ozJnJoPio530g13gYvAtqa+FnJq0eCZPrTllQrjV4YNZgm8m7DERlhxbmObF5xP fxKjXe3DOnWyj6lCMBwc4QtoYxS/7B1QiYUsu16J6GpPB9TyPWsmOvaT+7jXJ+MWmvw6 w0qIFCpYbQt70yoOqULPkxT+08K01YDWgkGpVS5SAYAosy6wvHTIUbJnMyFfRwchr0JU Vcuw==
X-Gm-Message-State: APzg51CwOfnJQ6H4yd3Iq2/xwTiwGIZ9sZxMeJs/+bOHmWRNtXV+mzZs Utixc6wdj3TXptIXwxfMzrIHLrbq7Aj+CGTZc3Alyw==
X-Google-Smtp-Source: ANB0VdbZUkrdrYgIX4cbJ2qOOxm0EgMFTr3hDa8XG87ig3lcvVK4eEk9VSP/NLHsybd8++ZK9R5QscSCvce03cqBo5A=
X-Received: by 2002:a37:3492:: with SMTP id b140-v6mr8602943qka.355.1536942579133; Fri, 14 Sep 2018 09:29:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a0c:86ea:0:0:0:0:0 with HTTP; Fri, 14 Sep 2018 09:29:38 -0700 (PDT)
X-Originating-IP: [2604:6000:8a42:6905:1d06:646e:3613:148c]
In-Reply-To: <F64C10EAA68C8044B33656FA214632C888405829@MISOUT7MSGUSRDE.ITServices.sbc.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> <CAJU8_nX+LkDy3HucYzVLO0R_ft6NbABKcGq9Ac+esNBHcVuehw@mail.gmail.com> <5655CB57-721B-4F9C-8F7F-0E38FBA60E0C@gmail.com> <F64C10EAA68C8044B33656FA214632C888405829@MISOUT7MSGUSRDE.ITServices.sbc.com>
From: Kyle Rose <krose@krose.org>
Date: Fri, 14 Sep 2018 12:29:38 -0400
Message-ID: <CAJU8_nXK7NNx8YGP=rmNxPcfnaVsVG5Fi5qJc=SRmhuLarasPw@mail.gmail.com>
To: "BRUNGARD, DEBORAH A" <db3546@att.com>
Cc: Dino Farinacci <farinacci@gmail.com>, IETF SecDir <secdir@ietf.org>, "draft-ietf-lisp-rfc6830bis.all@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="0000000000007841a40575d75408"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/uRQYmXY9YL2_e9wu9GE_3GW8B2I>
Subject: Re: [lisp] Secdir last call review of draft-ietf-lisp-rfc6830bis-15
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Sep 2018 16:29:51 -0000

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 <db3546@att.com> 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 <farinacci@gmail.com>
> Sent: Tuesday, September 11, 2018 2:40 PM
> To: Kyle Rose <krose@krose.org>
> Cc: IETF SecDir <secdir@ietf.org>rg>; draft-ietf-lisp-rfc6830bis.all@ietf.org;
> IETF Discussion Mailing List <ietf@ietf.org>rg>; lisp@ietf.org list <
> lisp@ietf.org>gt;; Benjamin Kaduk <kaduk@mit.edu>du>; Mirja Kühlewind <
> ietf@kuehlewind.net>
> 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":
> https://www.ietf.org/blog/how-read-rfc/
>
> 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.
>
>