Hi Luigi, Thank you! It must not have gone to the SecDir list. I had noticed at least one of the changes.
Best regards, Kathleen Sent from my iPhone > On Oct 22, 2015, at 5:32 AM, Luigi Iannone <[email protected]> wrote: > > 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
