[secdir] SecDir Review of draft-ietf-lisp-deployment

Warren Kumari <warren@kumari.net> Fri, 23 August 2013 23:19 UTC

Return-Path: <warren@kumari.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FA221F9EA8 for <secdir@ietfa.amsl.com>; Fri, 23 Aug 2013 16:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBdp7z+FGHEM for <secdir@ietfa.amsl.com>; Fri, 23 Aug 2013 16:19:40 -0700 (PDT)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C1021F9ECA for <secdir@ietf.org>; Fri, 23 Aug 2013 16:19:39 -0700 (PDT)
Received: from [192.168.1.153] (unknown [66.84.81.89]) by vimes.kumari.net (Postfix) with ESMTPSA id 6ED741B412DE; Fri, 23 Aug 2013 19:19:37 -0400 (EDT)
From: Warren Kumari <warren@kumari.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Aug 2013 19:19:36 -0400
Message-Id: <01D946E4-348D-4A3D-ABF8-B7DBD6F74F6E@kumari.net>
To: "secdir@ietf.org" <secdir@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Cc: draft-ietf-lisp-deployment.all@tools.ietf.org
Subject: [secdir] SecDir Review of draft-ietf-lisp-deployment
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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: Fri, 23 Aug 2013 23:19:45 -0000

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.

This draft describes LISP deployment scenarios. It represents current thinking and is expected to change (I guess be obsoleted / replaced?) as more experience is gained with deployment.

Summary: I'm not sure what to do here.

The document is very well written, and the authors seem to have taken care to consider the implications of various deployment scenarios. 
In spite of knowing very little about LISP I found the document to be accessible and easily understood. It clearly lays out the considerations for different deployments, and provides some guidance as to how to select.


However, the security considerations section simply says:
"Security implications of LISP deployments are to be discussed in
   separate documents.  [I-D.ietf-lisp-threats ] gives an overview of
   LISP threat models, while securing mapping lookups is discussed in
   [I-D.ietf-lisp-sec]."

This is a deployment document, and so this may be perfectly acceptable; the "separate documents" may completely cover everything. Or not.
I am unclear if the authors mean that I-D.ietf-lisp-threats and I-D.ietf-lisp-sec cover all security considerations, or if the implication is that there will be other documents that cover the security implications. 
http://i.imgur.com/5rTHfRs.jpg



Section 2.4.  "Inter-Service Provider Traffic Engineering" says:
"Failure to follow these recommendations may lead to operational and security issues when deploying this scenario."
I think that a (short) explanation of what the security issues are if you don't follow the recommendations would be nice.


Nits:
Section 4.2:
"For more details on P-ETRs see the [RFC6832] draft." -- I think that this could be better worded as "For more details on P-ETRs see [RFC6832]" (think this was written while RFC6832 was still a draft).

ID NITs complains about use of RFC2119 language ("It is NOT RECOMMENDED for deployment"), but no RFC2119 reference / boilerplate.
I'm scraping the bottom of the barrel here, 'tis well written..

--
It is impossible to sharpen a pencil with a blunt axe.  It is equally vain
to try to do it with ten blunt axes instead.
    --  E.W Dijkstra, 1930-2002