Re: [lisp] possible text for LISP threats

[Dino Farinacci <[e-mail]>]

> For the host to which the attack packets are destined, I don't think that LISP is worse in this case. However, it is not the effect on a host that I am concerned about. If the xTR serving that host in this case is either a CE router or a PE router, then this is a lot worse for the xTR, since the attack packets cause a reaction in its control plane. Of course if the effect of the attack is to fill the cache, then again LISP is worse since "non-LISP Internet operation" doesn't have a cache. I understand that we are not planning to describe solutions in this text, but if rate limiting of map requests is considered to be normal practice, I wonder if it would be worth mentioning that rate limiting could prevent overload of the xTR's control plane, but that in this case the attack could prevent map requests in support of legitimate users. 

I beg to differ, because what you refer to a cache makes assumptions that it is finite size. A BGP RIB is finite size as well. And even a legit BGP peer can fill up a finite size RIB.

So it is my claim that LISP is no worse.

> the attacked xTR noticing and putting in a packet filter for that source RLOC,
>>> so that varying the source RLOC may make this attack more difficult to counter. 
>> 
>> You shouldn't say how the xTR would handle this or else, yes, it will get worse.
>> Because if you choose a faulty solution, you will introduce more issues.
> 
> I am fine with dropping the sentence stating "Optionally the attacker could use the same source RLOC for each, but this could in theory lead to the attacked xTR noticing and putting in a packet filter for that source RLOC, 

I wouldn't put in a packet filter or else the real RLOC is denied service by the attacked xTR itself.

> so that varying the source RLOC may make this attack more difficult to counter". However, I do wonder, what would happen if a single attacker sent a large number of packets which look like LISP packets with the same RLOC for all (perhaps the legitimate RLOC of the attacker) but with different EID's, each EID chosen from a different EID block. Would the xTR receiving all of these incoming packets send a map request for each EID? 

This is what Ron brought up.

> This could be a way to get around source IP address checks (where they are deployed), since the source RLOC would be correct and legitimate. 

Right, understand.

It all comes down to the (source-EID, source-RLOC)-tuple needs to be authenticated to be the legitimate source.

Dino