Hi Ben,

> On 21 Oct 2015, at 04:14, Ben Campbell <[email protected]> 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



_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to