Re: [secdir] review of draft-saucez-lisp-impact-04.txt

"Hilarie Orman" <ho@alum.mit.edu> Mon, 19 October 2015 19:04 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552711B2BE9; Mon, 19 Oct 2015 12:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 YXnx_jZdjk46; Mon, 19 Oct 2015 12:04:47 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00CBA1B2BE8; Mon, 19 Oct 2015 12:04:28 -0700 (PDT)
Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <hilarie@purplestreak.com>) id 1ZoFix-0007t4-07; Mon, 19 Oct 2015 13:04:05 -0600
Received: from [72.250.219.84] (helo=sylvester.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <hilarie@purplestreak.com>) id 1ZoFih-0000Zw-8a; Mon, 19 Oct 2015 13:03:53 -0600
Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.4/Debian-2ubuntu1) with ESMTP id t9JJ2xEH019910; Mon, 19 Oct 2015 13:02:59 -0600
Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id t9JJ2vGf019909; Mon, 19 Oct 2015 13:02:57 -0600
Date: Mon, 19 Oct 2015 13:02:57 -0600
Message-Id: <201510191902.t9JJ2vGf019909@sylvester.rhmr.com>
From: "Hilarie Orman" <ho@alum.mit.edu>
To: luigi.iannone@telecom-paristech.fr
In-reply-to: Yourmessage <C35464F2-B22D-4E2C-BED0-95267A8A5A23@telecom-paristech.fr>
X-XM-AID: U2FsdGVkX19GH6XoeAD4U2yRlFDAyTDc
X-SA-Exim-Connect-IP: 72.250.219.84
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ******;luigi.iannone@telecom-paristech.fr
X-Spam-Relay-Country:
X-Spam-Timing: total 5025 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 4.9 (0.1%), b_tie_ro: 4.1 (0.1%), parse: 0.71 (0.0%), extract_message_metadata: 21 (0.4%), get_uri_detail_list: 3.4 (0.1%), tests_pri_-1000: 5 (0.1%), tests_pri_-950: 1.06 (0.0%), tests_pri_-900: 0.83 (0.0%), tests_pri_-400: 31 (0.6%), check_bayes: 30 (0.6%), b_tokenize: 9 (0.2%), b_tok_get_all: 12 (0.2%), b_comp_prob: 2.5 (0.1%), b_tok_touch_all: 3.2 (0.1%), b_finish: 0.66 (0.0%), tests_pri_0: 608 (12.1%), tests_pri_500: 4349 (86.6%), poll_dns_idle: 4339 (86.3%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600)
X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/wpPgb7mFEiHKtbKMj3LG6O3pF4s>
Cc: damien.saucez@inria.fr, draft-saucez-lisp-impact@tools.ietf.org, iesg@ietf.org, draft-ietf-lisp-impact@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] review of draft-saucez-lisp-impact-04.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
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: Mon, 19 Oct 2015 19:04:49 -0000

[NB: this is in re draft-ietf-lisp-impact-04]

A few comments and suggestions:

      Unless gleaning features (actually deprecated in
      RFC 6830 [RFC6830]) are used, 

I don't see that gleaning is deprecated.  In any event, how does gleaning
undermine security?

                                     the  LISP data-plane shows the 
      same level of security as other IP-over-IP technologies.
      From a security perspective, the control-plane remains the 
      critical part of the LISP architecture.

      To maximally mitigate the threats on the mapping

I doubt authentication is "maximal" mitigation.  It just mitigates.

      system, authentication must be used, whenever possible, for all 

When would it be impossible to use authentication?

      control plane messages.

      Current specification already offer security mechanisms 
      ([RFC6833],  [I-D.ietf-lisp-sec]) able to strongly reduce threats 
      in non-trustable environments such as the Internet.  

"The currenet specification defines security mechanisms which can
reduce threats in open network environments" ?

      Actually, LISP specifications define a generic authentication data field 
      control plane messages [RFC6830] allowing to propose a general
      authentication mechanisms for the LISP control-plane while staying
      backward compatible. 

"The LISP specification defines a generic authentication data field 
      for control plane messages [RFC6830] which could be used for a general
      authentication mechanisms for the LISP control-plane while staying
      backward compatible. "  ??

Hilarie

>  Subject: Re: review of draft-saucez-lisp-impact-04.txt
>  From: Luigi Iannone <luigi.iannone@telecom-paristech.fr>
>  Date: Sat, 17 Oct 2015 21:49:24 +0200
>  Cc: Damien Saucez <damien.saucez@inria.fr>fr>,
>	   draft-saucez-lisp-impact@tools.ietf.org, secdir@ietf.org,
>	   The IESG <iesg@ietf.org>

>  Hi Hilarie,

>  In the current format the security section just states that actually 
>  security is out of the scope of the document.
>  This was actually an outcome of the WG discussion, were it was
>  decided to clearly separate security and impact.


>  Yet, it is true that the security section is poor, while 
>  security analysis is out of the scope of the document, it does not 
>  mean that we cannot mention the major security points 
>  thoroughly analysed in the threats document.


>  Hence we propose to modify the security section as follows:

>  Old Version:

>	   Security and threats analysis of the LISP protocol is out of the
>	   scope of the present document.  A thorough analysis of LISP security
>	   threats is detailed in [I-D.ietf-lisp-threats].


>  NEW Version:

>	   A thorough security and threats analysis of the LISP protocol
>	   is carried out in details in [I-D.ietf-lisp-threats]. 
>	   Like for other Internet technologies, also for LISP most of 
>	   threats can be mitigated using Best Current Practice, meaning 
>	   with careful deployment an configuration (e.g., filter) and also 
>	   by activating only features that are really necessary in the 
>	 deployment and verifying all the information obtained from third 
>	   parties. Unless gleaning features (actually deprecated in
>	   RFC 6830 [RFC6830]) are used, the  LISP data-plane shows the 
>	   same level of security as other IP-over-IP technologies.
>	   From a security perspective, the control-plane remains the 
>	   critical part of the LISP architecture.
>	   To maximally mitigate the threats on the mapping
>	   system, authentication must be used, whenever possible, for all 
>	   control plane messages.
>	   Current specification already offer security mechanisms 
>	   ([RFC6833],  [I-D.ietf-lisp-sec]) able to strongly reduce threats 
>	   in non-trustable environments such as the Internet.  
>	   Actually, LISP specifications define a generic authentication data field 
>	   control plane messages [RFC6830] allowing to propose a general
>	   authentication mechanisms for the LISP control-plane while staying
>	   backward compatible. 


>  We hope this delivers the information you were looking for.

>  ciao

>  Luigi


>  > On 13 Oct 2015, at 19:28, Hilarie Orman <ho@alum.mit.edu> wrote:
>  > 
>  > Thanks for pointing out my mistake.  I have now reviewed
>  > draft-ietf-lisp-impact-04 and the same comments about security apply.
>  > 
>  > Hilarie
>  > 
>  >> From: Damien Saucez <damien.saucez@inria.fr>
>  >> Date: Tue, 13 Oct 2015 08:13:08 +0200
>  > 
>  > 
>  >> Thank you for the review. I would have a question regarding the document you reviewed. Did you review th
>  > 
>  >> draft-sauces-lisp-impact-04
>  > 
>  >> or 
>  > 
>  >> draft-ietf-lisp-impact-04
>  > 
>  >> Thank you,
>  > 
>  >> Damien Saucez 
>  > 
>  >> On 13 Oct 2015, at 05:01, Hilarie Orman <ho@alum.mit.edu> wrote:
>  > 
>  >>> Secdir review of LISP Impact
>  >>> draft-saucez-lisp-impact-04.txt
>  >>> 
>  >>> Do not be alarmed.  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.
>  >>> 
>  >>> A new way of handling routing information has been defined in IETF
>  >>> documents about the Locator/Identifier Separation Protocol (LISP).
>  >>> The draft under discussion here elaborates on the possible
>  >>> consequences of widespread use of LISP.
>  >>> 
>  >>> The draft punts on security considerations and refers to previous
>  >>> documents describing threats to LISP and how LISP uses cryptography
>  >>> for protecting the integrity of its messages.
>  >>> 
>  >>> It seems to me that if the purported impact of LISP is to "scale the
>  >>> Internet", then its impact on security should be a major part of the
>  >>> equation.  Will it make routing information more or less vulnerable
>  >>> malicious manipulation?  How will it affect the stability of a network
>  >>> that is under constant threat of attack?
>  >>> 
>  >>> I don't feel that the draft can achieve its purpose without addressing
>  >>> security.
>  >>> 
>  >>> Hilarie
>  >>> 
>  >>> PS. I was very disappointed to realize that this was not a draft
>  >>> about my favorite programming language.