[secdir] Secdir telechat review of draft-ietf-lisp-rfc6830bis-18

Kyle Rose <krose@krose.org> Thu, 20 September 2018 18:23 UTC

Return-Path: <krose@krose.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F2F130E67; Thu, 20 Sep 2018 11:23:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kyle Rose <krose@krose.org>
To: secdir@ietf.org
Cc: draft-ietf-lisp-rfc6830bis.all@ietf.org, ietf@ietf.org, lisp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153746783815.5331.10419091174803926555@ietfa.amsl.com>
Date: Thu, 20 Sep 2018 11:23:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jW49UtfqCzRlkfCe84KGQ9VsoMo>
Subject: [secdir] Secdir telechat review of draft-ietf-lisp-rfc6830bis-18
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Sep 2018 18:23:58 -0000

Reviewer: Kyle Rose
Review result: Has Issues

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

I have reviewed the -15/-18 diff and found no changes relevant to the points I
raised in the first review and its subsequent discussion. I maintain that some
reorganization is warranted to clarify the intended security properties of the
system, especially given the complexity of the overall LISP ecosystem and the
choice to move documents separately, complicating the realistic need to review
them as a block. Otherwise, I have nothing further to add.