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

[Luigi Iannone <[e-mail]>]

HI Kathleen,

yes, a reference on gleaning and related issues can be added easily.

ciao

Luigi


> On 22 Oct 2015, at 15:07, Kathleen Moriarty <[e-mail]> wrote:
> 
> Luigi,
> 
> Just one more question.
> 
> On Thu, Oct 22, 2015 at 7:06 AM, Kathleen Moriarty
> <[e-mail]> wrote:
>> 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.
> 
> Could you add an explicit reference so ti tis clear that this has been
> documented?
> 
> It would also be good to see how the impact of LISP on security too as
> this is an impact draft.
> 
> Thank you,
> Kathleen
> 
>>> 
>>>> 
>>>>                                 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.
>>> 
>>> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen