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

[Kathleen Moriarty <[e-mail]>]

Thank you!

On Thu, Oct 22, 2015 at 10:01 AM, Luigi Iannone <[e-mail]> wrote:
> 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
>



-- 

Best regards,
Kathleen