Re: [lisp] Kathleen Moriarty's No Objection on draft-ietf-lisp-impact-04: (with COMMENT)

[Kathleen Moriarty <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi Kathleen,
> 
>> On 21 Oct 2015, at 18:52, Kathleen Moriarty <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>> Date: Sat, 17 Oct 2015 21:49:24 +0200
>>> Cc: Damien Saucez <[e-mail]>,
>>>       [e-mail], [e-mail],
>>>       The IESG <[e-mail]>
>> 
>>> 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 <[e-mail]> 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 <[e-mail]>
>>>>> 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 <[e-mail]> 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.
> 
>