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

[Damien Saucez <[e-mail]>]

Dear Joel,

Please first apologies four our silence.

We are indeed very late with this draft. We have discussed with the authors about
the way of fixing the problems. However, we think that we need to discussed f2f
with people to propose a new draft version that corresponds to the best consensus
between needs of people. For example, we believe that assessing the security level
risk is important, however, putting a "rank" as we made is touchy as from one to
another, the feeling of danger can be very different. We thus think of remove this
"absolute" ranking and replace by some sentences that are more neutral. For
that, we still need to find a way to cover with precision the problems and their
solutions. Also, we want to add to the draft the example provided during the
discussion by mails.

We hope to have valuable changes in the document at the term of this IETF
and propose a new version to the WG in the following of the meeting. So,
we are not dead or silent, just that we want to be sure to provide the best
possible document as the topic is very serious.

Respectfully yours,

The authors,


On 06 May 2013, at 17:45, 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