On Sun, Aug 8, 2021, 5:13 PM Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
Tom,
On 09-Aug-21 07:23, Tom Herbert wrote:
>
>
> On Sun, Aug 8, 2021, 12:03 PM David Farmer <farmer@xxxxxxx <mailto:farmer@xxxxxxx>> wrote:
>
>
>
> On Sun, Aug 8, 2021 at 02:27 Töma Gavrichenkov <ximaera@xxxxxxxxx <mailto:ximaera@xxxxxxxxx>> wrote:
>
> Peace,
>
> On Sun, Aug 8, 2021, 5:20 AM Tom Herbert <tom@xxxxxxxxxxxxxxx <mailto:tom@xxxxxxxxxxxxxxx>> 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:farmer@xxxxxxx <mailto:Email%3Afarmer@xxxxxxx>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 612-626-0815
> Minneapolis, MN 55414-3029 Cell: 612-812-9952
> ===============================================
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@xxxxxxxx
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
