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

[Luigi Iannone <[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.