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

[Michael Tuexen <[e-mail]>]

> On 8. Aug 2021, at 21:23, Tom Herbert <[e-mail]> wrote:
> 
> 
> 
> On Sun, Aug 8, 2021, 12:03 PM David Farmer <[e-mail]> wrote:
> 
> 
> On Sun, Aug 8, 2021 at 02:27 Töma Gavrichenkov <[e-mail]> wrote:
> Peace,
> 
> On Sun, Aug 8, 2021, 5:20 AM Tom Herbert <[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.
What about making the number of retransmission timeouts after which you change the flow label
configurable via a socket option, having the default value configurable via sysctl.

The value of 0 could mean that you don't change the flow label at all due to retransmission
timeouts.

Maybe use 0 as the default value.

Just to be crystal clear: the same behaviour applies to retransmissions of SYN/SYN-ACK segments
and to segments which have no the SYN bit set.

Best regards
Michael
> 
> Tom
> 
> 
> Thanks.
> -- 
> ===============================================
> David Farmer               Email:[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
> ===============================================