Re: [secdir] review of draft-saucez-lisp-impact-04.txt

["Hilarie Orman" <[e-mail]>]

[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?

                                     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.

      system, authentication must be used, whenever possible, for all 

When would it be impossible to use authentication?

      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" ?

      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. "  ??

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.