Hi Kathleen, > On 21 Oct 2015, at 18:52, Kathleen Moriarty > <[email protected]> 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 <[email protected]> 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 <[email protected]> >> Date: Sat, 17 Oct 2015 21:49:24 +0200 >> Cc: Damien Saucez <[email protected]>, >> [email protected], [email protected], >> The IESG <[email protected]> > >> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> 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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
