On Wed, Aug 4, 2021 at 12:55 AM Töma Gavrichenkov <ximaera@xxxxxxxxx> wrote:
Peace,On Wed, Aug 4, 2021, 3:00 AM Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:TCP over ANYCAST is crossing the streams. Not surprised it doesn't work and see no reason to change that.Does that imply that you believe no TCP-based protocol deserves protection from DDoS attacks? Because anycast is ultimately the one and the only basement for that protection.?? I had better get me to a patent lawyer then because I have multiple DDoS protection ideas and none involve ANYCAST and only a few TCP.Either that, or you might want to test your ideas against the specialized field expertise.Anycast has been the ultimate DDoS mitigation tool for a decade already, and for a reason. Basically, it all comes down to a simple idea: DDoS traffic, generated in thousands of locations on the globe, cannot possibly be handled when accumulated in one of such locations. But it's surely more complicated than that.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 fundamental, kind of.
The flaw in your argument is 'multiple traffic termination points on the net (a.k.a. anycast)'
Of course if you call 'multiple traffic termination' anycast, this is true but you are then taking the leap to TCP over ANYCAST is the only way to do things which is false.
It is time to abandon TCP entirely and not just because of QUIC. Once one alternative transport is allowed in, there will be others.
In my RUD transport, the source address, port and protocol are simply discarded. It is entirely valid to send three packets via HTTP and the next five over UDP.
So yes, I can use ANYCAST techniques to conceal the internals of my system. But I am not obliged to. And I certainly don't depend on ANYCAST working over TCP.
