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
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
