[lisp] draft-ietf-lisp-threats

["Joel M. Halpern" <[e-mail]>]

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