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

["Ben Campbell" <[e-mail]>]

Thanks, those changes would address my comments.

Ben.

On 22 Oct 2015, at 4:08, Luigi Iannone wrote:

> 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