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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 20 Oct 2015 19:14:58 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-lisp-impact-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/

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

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

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 22 Oct 2015 10:08:12 -0500

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 <[email-masked]> wrote:
>>
>
> [snip]
>>
>>
> 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.
>
>
>
> Absolutely. We will move the document as normative reference.
>
> thanks
>
> Luigi