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

[Luigi Iannone <[e-mail]>]

Hi Ben,

> On 21 Oct 2015, at 04:14, Ben Campbell <[e-mail]> wrote:
> 

[snip]
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> It seems odd to me that an "impacts" paper would leave security impacts
> out of scope. Even with the detailed security considerations in
> draft-ietf-lisp-threats, it seems like there might be some higher-level
> observations to make, along the lines of the rest of the draft.
> 

Yes you are right.
We proposed an updated security section in the reply to Hillarie, who did the secdir review.
The proposed text is:


 	   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 mitigate the threats on the mapping system, authentication 
	   should be used for all control plane messages.
	   The current specification ([RFC6833],  [I-D.ietf-lisp-sec]) defines security 
	   mechanisms which can reduce threats in open network environments. 
	   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. 



> Along those lines, if you want to refer to draft-ietf-lisp-threats for
> security considerations, it needs to be a normative reference.
> 
> 

Absolutely. We will move the document as normative reference.

thanks

Luigi