Re: [Ila] Securing pull-based ID/LOC caches

[Dino Farinacci <[e-mail]>]

> On Fri, Mar 23, 2018, 1:01 PM Dino Farinacci <[e-mail]> wrote:
> I believe we have to spec out how CMS could work in more detail and try different fields of the IP header for input to  different hash functions to see if the needle (good actors) can get through the haystack (bad actors).
> 
> Dino,
> 
> I'm not sure what else in IP header could help, attackers can spoof any field. If you are saying that users 

Destination address and possibly QoS. That is, popular destinations or EF QoS could have more strict rate-limters.

> need to authenticate with the LISP sub-system that will have a lot of pushback.

I am not saying that.

> The other possibility is to accept the fact that we can't prevent DoS attacks on public networks, however we can limit the effects of the DoS attack so that it's not worth it to an attacker. The limit of interest is 

Well if the mapping system doesn’t allow high-rate senders to get RLOCs, that helps a lot more than what we have today. Especially when xTRs/ILA-N nodes are close to the source.

By the way, if you call your ILA-N nodes xTRs, you’d be compatible with LISP. That is, “T” in LISP means “Tunnel” and “T” in ILA means “Transformation”. So when we speak we can say that an xTR is on the edge of the overlay that can “tunnel” or “transform”. 

And this follows nicely with RTRs/ILA-R nodes (“Re-encapsulating Tunnel Routers and “Re-transforming Transforming Routers).  

> the worst case effect of the DoS attack. The worse case we are targeting for attacks on a mapping cache is that packets for good guys might take a suboptimal route. This should be much better than good users having packets dropped or blocked. 

Well I think you can do this once the map-cache entry is populated. That is if you see high-rate sources that are not legit, then one of the RLOCs in the RLOC-set could be a honey-pot or third-party that has sufficient bandwidth and capacity to drop packets. Where other sources that are within the rate-limiters can get their packets sent to good RLOCs.

But then you have to absorb the low-rate bad actors. But if they are low-rate, one would argue you can classify them as good actors (i.e. they get the same service as low-rate good-actors). The other thing you can do is lower the QoS value for bad actors. With encapsulation you can retain the original QoS value in the inner header and the downgraded value in the outer header. 

Dino