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

[Tom Herbert <[e-mail]>]

On Sat, Mar 24, 2018, 12:14 PM Dino Farinacci <[e-mail]> wrote:

> > 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,

That's still contingent on be able to distinguish bad actors from good
ones, I claim there is no general method that can do that reliably.

Tom


>
> Dino
>
>
>
>