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

Luigi Iannone <luigi.iannone@telecom-paristech.fr> Tue, 20 October 2015 15:26 UTC

Return-Path: <luigi.iannone@telecom-paristech.fr>
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 146D01B34BD; Tue, 20 Oct 2015 08:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 CQopcx2qLWY1; Tue, 20 Oct 2015 08:26:30 -0700 (PDT)
Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.52.33]) by ietfa.amsl.com (Postfix) with ESMTP id 11C5C1A6F6F; Tue, 20 Oct 2015 08:20:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id 54A3A101878; Tue, 20 Oct 2015 17:20:11 +0200 (CEST)
Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id T3M4UzTutCL3; Tue, 20 Oct 2015 17:20:09 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by zproxy110.enst.fr (Postfix) with ESMTP id AD83C10077B; Tue, 20 Oct 2015 17:20:09 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.0 zproxy110.enst.fr AD83C10077B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecom-paristech.fr; s=A6AEC2EE-1106-11E5-B10E-D103FDDA8F2E; t=1445354409; bh=IRDUX5oj+D+GV0MHea1KZCC9ot3+gjjFgLJhXbo2qnA=; h=Content-Type:Mime-Version:Subject:From:Date: Content-Transfer-Encoding:Message-Id:To; b=o21Ox01Sq9y23IKaLJiB5Goig2yplnzdAdxdJRzwfmBDMGZa09DRFOFz68dzC7fP3 Q2I0yU1X1hQSVXD260EZeX6H+53wn4NEYdurdRiuL7rW+SRNI5RWlYSmFdAL5YNzlc UQe9B5zPwN5aTgJXbJbsOUkJVCcMPOZQGdd3p2S4=
X-Virus-Scanned: amavisd-new at zproxy110.enst.fr
Received: from zproxy110.enst.fr ([127.0.0.1]) by localhost (zproxy110.enst.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EvTnBDKaDABD; Tue, 20 Oct 2015 17:20:09 +0200 (CEST)
Received: from dhcp164-197.enst.fr (dhcp164-197.enst.fr [137.194.165.197]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 7BBEC1019E5; Tue, 20 Oct 2015 17:20:09 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Luigi Iannone <luigi.iannone@telecom-paristech.fr>
In-Reply-To: <201510191902.t9JJ2vGf019909@sylvester.rhmr.com>
Date: Tue, 20 Oct 2015 17:20:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1F75F71-B363-45FD-A441-21DA6C4D6B5F@telecom-paristech.fr>
References: <201510191902.t9JJ2vGf019909@sylvester.rhmr.com>
To: Hilarie Orman <ho@alum.mit.edu>
X-Mailer: Apple Mail (2.3094)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/wwjsRs7rjbEfwTC5Y6yIqS9OHak>
X-Mailman-Approved-At: Thu, 22 Oct 2015 07:18:02 -0700
Cc: Damien Saucez <damien.saucez@inria.fr>, draft-saucez-lisp-impact@tools.ietf.org, The IESG <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
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: Tue, 20 Oct 2015 15:26:33 -0000

Hi Hilarie,

Thanks again for your reply.
please find our comments inline.

ciao

Luigi


> On 19 Oct 2015, at 21:02, Hilarie Orman <ho@alum.mit.edu> wrote:
> 
> [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?

This is actually discussed in sections 6 and 12 of RFC6830 and analysed in Section 3.1 of draft-ietf-lisp-threats.

> 
>                                    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.

Agreed. The sentence will be simplified as just “To mitigate the threats…."

> 
>     system, authentication must be used, whenever possible, for all 
> 
> When would it be impossible to use authentication?
> 

The idea was to hint at deployments in ressource constrained environments.
It might in fact be misleading. The whole sentence can be reworded as follows:

	To mitigate the threats on the mapping system, authentication 
	should be used for all control plane messages.


>     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”

Just to keep the references, the sentence can be:

	The current specification ([RFC6833],  [I-D.ietf-lisp-sec]) 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. "  ??
> 

Reads much better, thanks.

Luigi

> 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>,
>> 	   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.