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

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 06 May 2013 11:45:39 -0400

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

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 6 May 2013 12:02:43 -0400

On Mon, May 6, 2013 at 11:45 AM, Joel M. Halpern <[email-masked]> wrote:
> 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.

That concerns me, not because I care about the threats document much;
but because EID-to-RLOC cache attacks cannot be dealt with through any
means.  There is literally no way.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 06 May 2013 12:06:57 -0400

Jeff, could you please look at the section on this threat in the 
document, and provide comments on where it is incorrect.

Thank you,
Joel

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 7 May 2013 17:54:11 +0000

Jeff,

There was some good discussion regarding this issue on the mailing list between March 20 and 21. As I recall, seven approaches were discussed. I wonder if the threats document will be updated to reflect any of that discussion?

                                                   Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jeff Wheeler
> Sent: Monday, May 06, 2013 12:03 PM
> To: Joel M. Halpern
> Cc: [email-masked]
> Subject: Re: [lisp] draft-ietf-lisp-threats
> 
> > 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.
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Terry Manderson <[email-masked]>
Date: Thu, 30 May 2013 19:50:03 -0700

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