On Sat, Mar 24, 2018, 12:14 PM Dino Farinacci <[email protected]> wrote:
> > On Fri, Mar 23, 2018, 1:01 PM Dino Farinacci <[email protected]> > 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 > > > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
