Re: [lisp] Kathleen Moriarty's No Objection on draft-ietf-lisp-impact-04: (with COMMENT)
Luigi Iannone <ggx@gigix.net> Thu, 22 October 2015 09:32 UTC
Return-Path: <ggx@gigix.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D187D1B3499 for <lisp@ietfa.amsl.com>; Thu, 22 Oct 2015 02:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=unavailable
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 LKGO3P3xW7Sn for <lisp@ietfa.amsl.com>; Thu, 22 Oct 2015 02:32:10 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF051B341B for <lisp@ietf.org>; Thu, 22 Oct 2015 02:32:05 -0700 (PDT)
Received: by wikq8 with SMTP id q8so22606155wik.1 for <lisp@ietf.org>; Thu, 22 Oct 2015 02:32:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix_net.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PrSWT+K9L2nCFg9UZUqTTuVhbsbEKQ4jgmA1q7RR/Y4=; b=R7JsiCgqDUXxaF6ixa/8I0pUPeOgGWIBH38FTup1yErf+nO0skmERElUNjnQ/55w7S nIILfWWZthoBvl3qu4h/CenYD/3rgiMkUS6ziJXP7bjQn0HrBzfv2URB2/fdtt2d+Tnw Ao7TX9jAXpw6Zt1L/cJ77e8e247IZwP6iqQBhU45Aqpn08JYu7jVkOgf3XDB0dc3+BDz M2TR31490D6abZ66zZgEvBrIAC8p1j8PCunHv23EPfjehBHhXbjm+Y2TPfJB4R/Q4Y0T LQaiBBgCdfXrNxgAWhH4tB/KjNe2vYLssYhI+fRuAJzbq9eFMYRkSGNlndHib35oXmuV DPrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=PrSWT+K9L2nCFg9UZUqTTuVhbsbEKQ4jgmA1q7RR/Y4=; b=LNygCVOxb95noQrMCMthZPcQs9u5HSQZ7xR9OmfzL47E/nCPmvBeVvwOPKyQIYX/tB 54LFcimPlUDN4iLFKPtp0xjSDsFv6zz1rp5JjAs79VhmygszjM1G+8qLS4ggEsq3pUjq 09ZsTxz/QaUIVWzZ/0bLMOtc+pm2WrvREgJpIQdkJitbgk6JKbkqVZh4pKQVMniQAzFi /1onbve6CEBiFPYkfFAkvf6xlts0D8AOIaEOxHT/GG/lboMSmjzlP+je7PDL/CzelLVz 8IhwmA5GpqHTxy95/7MxNEpQbK1jug60qftEk0IVEfm1cJeuQrBAvHDvD/aICiAejayS luTg==
X-Gm-Message-State: ALoCoQntNYwueM8Tq8G5tUkHf0ZRXRlmt5+2iAwirgEs7Tk70YYi8f0Wg54pZsLtGIBziwEIRBuX
X-Received: by 10.180.187.237 with SMTP id fv13mr17351064wic.81.1445506323933; Thu, 22 Oct 2015 02:32:03 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:69d0:ed82:4a4d:120e? ([2001:660:330f:a4:69d0:ed82:4a4d:120e]) by smtp.gmail.com with ESMTPSA id q1sm15673400wjy.31.2015.10.22.02.32.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 Oct 2015 02:32:02 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <20151021165230.18223.65896.idtracker@ietfa.amsl.com>
Date: Thu, 22 Oct 2015 11:32:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF2097B2-704A-4A9A-84F2-0C5870925B9B@gigix.net>
References: <20151021165230.18223.65896.idtracker@ietfa.amsl.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/lisp/wsnOZs66K3c6DG5ZwxZfslHJeVM>
Cc: lisp-chairs@ietf.org, lisp@ietf.org, draft-ietf-lisp-impact.all@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-lisp-impact@ietf.org
Subject: Re: [lisp] Kathleen Moriarty's No Objection on draft-ietf-lisp-impact-04: (with COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2015 09:32:12 -0000
Hi Kathleen, > On 21 Oct 2015, at 18:52, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote: > > [snip] > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hello, > > There was no follow up or changes (it seems) as a result of the SecDir > review. It would be helpful to address the questions on the aim of this > draft and how it applies to security for the user and impact of LISP. > https://www.ietf.org/mail-archive/web/secdir/current/msg06103.html > > There was actually a follow up (see below) or ami I missing something? Let me know. ciao L. %—— Last reply to Hilarie on 20th October———————% 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.
- [lisp] Kathleen Moriarty's No Objection on draft-… Kathleen Moriarty
- Re: [lisp] Kathleen Moriarty's No Objection on dr… Luigi Iannone
- Re: [lisp] Kathleen Moriarty's No Objection on dr… Kathleen Moriarty
- Re: [lisp] Kathleen Moriarty's No Objection on dr… Kathleen Moriarty
- Re: [lisp] Kathleen Moriarty's No Objection on dr… Luigi Iannone
- Re: [lisp] Kathleen Moriarty's No Objection on dr… Kathleen Moriarty