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.
- [secdir] review of draft-saucez-lisp-impact-04.txt Hilarie Orman
- Re: [secdir] review of draft-saucez-lisp-impact-0… Hilarie Orman
- Re: [secdir] review of draft-saucez-lisp-impact-0… Hilarie Orman
- Re: [secdir] review of draft-saucez-lisp-impact-0… Damien Saucez
- Re: [secdir] review of draft-saucez-lisp-impact-0… Luigi Iannone
- Re: [secdir] review of draft-saucez-lisp-impact-0… Luigi Iannone