Re: IPv6 Anycast has been killed by LINUX patch in 2016 - who cares?

[Tom Herbert <[e-mail]>]

On Sun, Aug 8, 2021, 5:13 PM Brian E Carpenter <[e-mail]>
wrote:

> Tom,
> On 09-Aug-21 07:23, Tom Herbert wrote:
> >
> >
> > On Sun, Aug 8, 2021, 12:03 PM David Farmer <[e-mail] <mailto:
> [e-mail]>> wrote:
> >
> >
> >
> >     On Sun, Aug 8, 2021 at 02:27 Töma Gavrichenkov <[e-mail]
> <mailto:[e-mail]>> wrote:
> >
> >         Peace,
> >
> >         On Sun, Aug 8, 2021, 5:20 AM Tom Herbert <[e-mail]
> <mailto:[e-mail]>> wrote:
> >
> >             Using anycast as a
> >             mitigation to DDoS doesn't seem like a great idea
> considering the
> >             problems being discussed here.
> >
> >
> >         It's quite the opposite: using anycast to mitigate DDoS is the
> only proper way to do it, because, basically, DDoS traffic, generated in
> thousands of locations on the globe, cannot be handled when accumulated in
> one place.
> >
> >         Either you have multiple traffic termination points on the net
> (a.k.a. anycast), each as close to some traffic generation point as
> possible, or you'll end up having capacity overload around your last mile.
> This is the equation fundamental to the Internet, while the implementation
> issues discussed here are hardly more than just typical software
> engineering tasks.
> >
> >
> >     Anycast is only one of several mitigation strategies for DDoS, yes,
> it is a good one for web type services, it might even be the best for that
> type of service, especially against large volumetric attacks. However,
> there are many other types of attacks to protect against and services that
> need protection and anycast is a lousy mitigation strategy for many of
> them, especially for client networks or peer to peer services.
> >
> >     While I agree with you, anycast is an important capability in the
> Internet architecture, nevertheless it has many limitations, and is not the
> panacea you claim it to be, even for DDoS.
> >
> >     Furthermore, I’m not sure what you or the original reporter
> of this problem expect the IETF to do to fix the problem that was
> reported. I’ll remind you of the well worn trope, “the IETF is not the
> protocol police.” Any fix to the problem reported is squarely in hands of
> Linux developers, not the IETF.
> >
> >
> > David,
> >
> > That's true, however we, Linux developers, certainly value the input and
> discussion on IETF lists. IMO, the later patch that started to recompute
> the hash on each RTO probably is too aggressive to be the default behavior
> on the Internet. I plan to post a patch that makes default less aggressive
> by restoring the original default behavior to recompute hash only after
> multiple RTOs. The rehash behavior will be configurable by sysctl and also
> I'll add a socket option to allow the application to control the behavior
> per connection thereby resolving Brian's concern.
>
> Yes, thanks, that looks good. How about a global default setting for a
> given host, too? That could be at sysctl level.
>

Yes, that will be there.

Tom


> Thanks
>     Brian
>
> >
> > Tom
> >
> >
> >     Thanks.
> >
> >     --
> >     ===============================================
> >     David Farmer               Email:[e-mail] <mailto:
> [e-mail]>
> >     Networking & Telecommunication Services
> >     Office of Information Technology
> >     University of Minnesota
> >     2218 University Ave SE        Phone: [phone]
> >     Minneapolis, MN 55414-3029   Cell: 612-812-9952
> >     ===============================================
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
>