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

[Kathleen Moriarty <[e-mail]>]

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