Re: [lisp] draft-ietf-lisp-threats

[Terry Manderson <[e-mail]>]

WG Co-Chair hat ON,

Lisp-threats Authors,

I am yet to see any responses from you to this and subsequent posts. As a
key deliverable in the charter it is imperative that dialogue on this
draft, or at the very least a summary of results and rationale, is posted
to the list.

At your earliest convenience can you please address the items raised. The
Berlin meeting is approaching (fast) and progress needs to be made.

Cheers
Terry


On 7/05/13 1:45 AM, "Joel M. Halpern" <[e-mail]> wrote:

>My apologies for not getting to this issue soone.
>
>The approach being taken in this version of the document seems to me to
>be ineffective.  As a simple example, section 5.2 says that EID-to-RLOC
>cache Threats are Severity level 2, meaning that it can be dealt with by
>turning off certain features in pubic deployments.
>But it is then followed by a LISP of threats, and a set of points to
>features in section 6 and 6.3.  As a result I can not tell what features
>would need to be turned off to address the threat of section 5.2.
>
>I am very concerned by declaring that folks should turn off echo-nonce.
>  Echo-none was added, for use in public deployments, fo good reasons.
>Changing the recommendations in this regard is fairly major.
>
>This leads to a general issue about Severity Level 2.  Across the
>document, different features are recommended to be turned off.  As a
>reader, it is very easily to lose track of the collective effect.  If we
>are going to stick with this approach, I think we need to pull up the
>list of problematic features to the front of the document.  We need to
>clearly state that based on the analysis below, features X, Y, and Z are
>not recommended for public deployments of LISP.
>And then the WG has to decide whether that is a recommendation we can
>support.
>(Yes, I think we would be well-served putting this in the front of the
>document, rather than in the security considerations section.)
>
>In the description of section 5.4.4 of Instance ID bits, I do not
>understand how an ACL could help.  I can not see folks configuring
>firewalls for the set of EIDs permitted within the VPN.  Such a
>configuration would counter the very ease of deployment associated with
>using LISP for VPNs.  Outer have a similar problem, and would need to be
>able to act on the instance ID, which current ACLs can not do.
>
>Section 7 seems to call for Proxy-ITR deployers to deploy data plane
>access control at "the border of the network, that is the edge of the
>scope of the Proxy_ITR's announcement of the EID-Prefix."  But in many
>Proxy-ITR deployments, that edge is not under the control of the
>Proxy-ITR deployer.
>
>Proxy-ETR static configuration seems to be difficult to integrate with
>the dynamics of LISP (section 7, Proxy-ETR.
>
>The text in section 10 (Security Considerations) regers to "the
>increasing deployment of spoofing prevention techniques such as
>[rfc3704] or [SAVI]..."  I have not seen any evidence of such increasing
>deployment, and plenty of evidence (such as the recent spoofed DNS
>reflection attack) that it is not increasing.
>
>----
>
>As a minor suggestion, when there are existing configuration mechanisms
>that can address the threat, it would be helpful to point to the
>specific document and section where that is described.  For example,
>section 5.3 could point to RFC 6830 section 10 (security considerations).
>
>The introduction of section 6 should not end with a Severity level as
>each subsection has its ow Severity level indication.
>
>Claiming that "correct deployment of anti-spoofing" means that a treat
>is Severity level 1 is technically accurate, but probably misleading and
>likely to raise problems.  (Section 6.1 for example).  (Rate limiting
>reduces the scope of the attack, but does not prevent it.)
>
>Yours,
>Joel
>_______________________________________________
>lisp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/lisp