Re: [lisp] Restarting last call on LISP threats

[Roger Jørgensen <[e-mail]>]

A general reply, we were on the way to getting into a head-to-head
discussion instead of being constructive. The last few email I read
moved away from that path.

I think we should discuss all threat, not just define them to be out of scope.



some comments:


On Fri, May 23, 2014 at 4:36 PM, Ross Callon <[e-mail]> wrote:
> Detailed comments below. To summarize, these details include three threats which are new to LISP and which are not adequately explained in the current threats document:
>
>  (1) The Control Plane Threat: LISP allows a dataplane DOS attack (lots of packets sent to overwhelm a site) to turn into a control plane attack (the router is forced to respond to the attack in the control plane, which is of course frequently multiple orders of magnitude slower than the data plane, particularly for very high speed routers).

Seems like we all disagree on how serious this is, how much harm it
can do. But it should be mention.

I think I remember an earlier discussion on a very similar topic that
just ended with people disagreeing and stopped discussing it.
This is probably a new topic, but where is the weakness really,
Mapping-System or on the xTR side? ...?
Could be that our ongoing discussion here might be because it's not
good enough explained?



>  (2) The Privacy Threat: LISP provides an attacker with a relatively easy way to determine the identity of large numbers of PE and/or CE routers (globally, if LISP is deployed on that level) .

I agree there are privacy threats.

LISP is no better or worse compared to current internet on privacy for
end-user, it's reveled one way or another somehow unless you encrypt
your data (HTTPs etc).
What LISP add to the pool is the possibility to collect the IP for
many end-sites with ease, xTR sides. Is that the same thing as what
you're describing?



>  (3) the Traffic Gleaning Threat: If an xTR gleans EID -> RLOC mappings from incoming packets, this provides an easy way for hackers to intercept traffic. I put this threat third because gleaning can be turned off, and thus this threat can be defeated simply by not gleaning EID -> RLOC mappings.

Isn't this the same as on-path and Man-in-the-middle attack? Or do you
describe something else?




-- 

Roger Jorgensen           | ROJO9-RIPE
[e-mail]          | - IPv6 is The Key!
http://www.jorgensen.no   | [e-mail]