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

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 12 Oct 2015 21:01:32 -0600

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.

---

From: "Hilarie Orman" <[email-masked]>
Date: Tue, 13 Oct 2015 11:28:59 -0600

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 <[email-masked]>
>  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 <[email-masked]> wrote:

---

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 19 Oct 2015 13:02:57 -0600

[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 <[email-masked]>
>  Date: Sat, 17 Oct 2015 21:49:24 +0200
>  Cc: Damien Saucez <[email-masked]>,
>	   [email-masked], [email-masked],
>	   The IESG <[email-masked]>

>  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 <[email-masked]> wrote:
>  >

---

From: Damien Saucez <[email-masked]>
Date: Tue, 13 Oct 2015 08:13:08 +0200

Dear Hilarie,

or 

Thank you,

Damien Saucez

---

From: Luigi Iannone <[email-masked]>
Date: Sat, 17 Oct 2015 21:49:24 +0200

Hi Hilarie,

Old Version:

NEW Version:

ciao

Luigi

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 20 Oct 2015 17:20:09 +0200

Hi Hilarie,

Thanks again for your reply.
please find our comments inline.

ciao

Luigi

> On 19 Oct 2015, at 21:02, Hilarie Orman <[email-masked]> wrote:
> 

This is actually discussed in sections 6 and 12 of RFC6830 and analysed in Section 3.1 of draft-ietf-lisp-threats.

> I doubt authentication is "maximal" mitigation.  It just mitigates.

Agreed. The sentence will be simplified as just “To mitigate the threats…."

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

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

> ?

>     backward compatible. "  ??

Reads much better, thanks.

Luigi