Consider augmenting TCP with a "pre-SYN" and "pre-SYNACK". Suppose you have to send a pre-SYN which declares your identity ip X. Then the server sends to X a "pre-SYNACK" encrypted message containing (X, t = timestamp()) based on a server-only key.
Afterwards, X may send the server a SYN for real. But then the server only allows a timeout of length, say, timestamp() - t, as of receiving the SYN back to maintain bookkeeping.
As benevolent cooperating clients, we may want to ourselves wait an exponentially-backed-off amount between receiving the pre-SYNACK from the server and sending our SYN back (such that in log-many rounds we establish our conn).
Then any malevolent actor must then keep a resource on X alive for at least half long as the server does (since the server requires zero bookkeeping after firing off the pre-SYNACK).
Edit: this is simplified, you could just own a machine at X which is far away from the ddos'd server and then have your botnet spoof requests from X; by augmenting this procedure with even more preamble rounds you could verify how long communication takes between the server and client X and subtract that out.
Your pre-SYN design is very close to the design of TLS 1.2, by the way. That’s how I knew how to attack it. TLS is attackable in just this way: open a real connection, then lots of fake handshake requests. No crypto required to generate them, but the server has to do lots.
Now that said, BCP 38 would go a LONG way towards addressing this. There will come a day when the well-behaved networks decide they’re not accepting traffic from non-compliant peers.
It still feels like there's a way of specifying a protocol (which of course would need to be adopted) where (1) authentication is a first-class entity (2) all non-authenticated requests enforce resource symmetry at the protocol level, while still allowing asymmetric work to be done (after a resource-symmetric auth).
Edit: augmenting the rough outline of what I originally proposed you can essentially require an arbitrary amount of proof-of-work, however useless, on the requester side (e.g., literally request a nonce such that the hash of the packet is below some value). Since only auth needs to be symmetric the overhead doesn't seem too bad.
Sure, you could crank up the difficulty until it makes the cost of the attack too high, but then all your users will get mad - that's basically what CloudFlare does and it attracts non-stop criticism.
Another way we could put this is that asymmetric work requirements are basically the definition of a network service. If we require the client to do enough computation that it expends as many resources as the backend, in a lot of ways there's no reason for the backend to even exist! People will be prone to migrate to a peer-to-peer or desktop solution instead of using your very very slow website.
Or a little more of a hot-take: the idea of proof-of-work requirements to prevent abuse of systems with asymmetric workload is almost as old as network systems. A prominent example is "hashcash" for email, introduced 1997. These have so routinely failed to gain any traction that we need to consider that the proof-of-work idea tends to come from a fundamental misunderstanding of the problem. Increasing the cost to the attacker sounds great until you consider that in most real-world situations, the attacker's budget is effectively infinite... because for a couple decades now these types of abuses have originated mostly from compromised systems, not from systems the attacker controls. Proof-of-work requirements still reduce the volume the attacker is capable of, but trends like IoT and the general proliferation of computing mean that the attacker's potential resources continually expand. More difficult PoW, in most cases, will only cause the attacker to make a relatively one-time investment of obtaining a new set of compromised resources (new botnet, new exploit to distribute existing botnet, etc). The increase in "per-item" cost to the attacker tends to never materialize.
This is interesting, where can I read more about both sides?
I do think you hit the nail on the head here, with resource symmetry being the center of the give-get here and making the botnet run warmer is the win (because it requires larger botnets, because it's more detectable, etc.). I think that this might make me upset as a client, but if it's economically advantageous for the server, then I'd still tolerate it to get the server's content.
I think that's why you need auth to be first-class in such a protocol. Yes, auth might be painful and annoying and require that your browser essentially mines hashes for a while on connection setup, but then after that presumably your website would be as fast as usual, and perhaps there might be a way to safely cache such authentication with a lease for valid users. Perhaps this kind of approach is too anti-internet, though, since it basically says that to do any useful backend work you need to be a registered user for some backend service.
But I don’t think we will ever get to a point where we bring that asymmetry to zero. We often really do want complex tasks to be done by a server in response to a simple client request.
Software people rarely put this asymmetry in the front of their minds during design, so I think its something we will continue to see in new systems, even if we (magically) universally adopted better versions of the old, too-trusting protocols.
I admit I haven't specified a full counterfactual protocol here, but see my edit for a rough outline of how you wouldn't just be able to generate garbage.
The symmetry is irrelevant when the attacker has stolen someone else's resources. Granny may notice her computer is even slower than usual, what then?
If we stipulate a future where attackers cannot steal other people's resources, then work backwards, I can't see any internet with any degree of freedom.
It would be necessary for every system to be 100% watertight. Mathematically-provably so. Spectre/Meltdown demonstrates that this isn't just formal proof about software. Eradicating the pathways to ddos is an intractable problem. You'd need to seriously consider preventing all network access except through certified and regulated kiosks to which users do not have direct physical access. Like, hand a librarian a piece of paper with a URL on it and get a print out.
I'm not expert, you shouldn't have confidence that I'm correct.
On the point of stolen resources, true, the attacker doesn't care, but I think if we get to the level of resource symmetry in a protocol we've effectively throttled a class of attacks. There are only so many grannies whom a given attacker can pwn. Symmetry is relevant because it makes it that much harder and that much more demanding of your botnet. Besides, like you mention at the end of your comment demanding some kind of additional Byzantine DOS-tolerance is likely too hard of an ask.
And at how many millions does that number start to taper down? Plus, zombie devices of all sorts are being used of course, so while there certainly does feel like some sort of resource-symmetry scheme would be, if nothing else, a satisfying solution, its hard to see logically how that would really help all that much for these sort of attacks.
Sending a HTTP GET is easy, but the server has to process the request and send the whole page... think a few tens of bytes of a request, and a whole webpage in a reply.
I've got to pay for capacity, but a bot net controller doesn't need a whole lot of bandwidth to trigger a lot. If you control 10,000 hosts with 10Mbps upload, that's 100Gbps; and botnets are growing as are typical upload bandwidths.
And that's without spoofing and amplified reflection attacks. Some of the reflection attacks have high amplification, so if you've got access to 100Gbps of spoofable traffic, you can direct Tbps of traffic.
If my server has a 10G connection and you're sending me 1Tbps, there's just no way I can work.
Syncookies work pretty well for TCP, I had run into some effective SYN floods against my hosts I managed in 2017, but upgrading to FreeBSD 11 got me to handling line rate SYNs on a 2x 1Gbps box and I didn't take the time to test 2x10G as I wasn't really seeing that many SYN floods. I don't recall any more effective SYN floods after that point. We didn't tend to have dedicated attackers though; people seemed to be testing DDoS as a service against us, and we'd tend to see exactly 90 or 300 seconds of abuse at random intervals.
Our hosting provider would null route IPs that were attacked if the volume was high enough for long enough. Null routing is kind of the best you can hope for your upstreams to do, but it's also a denial of service, so there you go.
Protocols are trying to avoid this problem. For TCP there exist SYN cookies to reduce the amount of work a host has to do. For QUIC retry packets exist, as well as anti-amplification rules. However applying those mechanisms also has a cost. One is you still get computational cost not to zero, since you still have to receive and reject packets. And the other cost is now your legitimate users are experiencing a latency penality due to potentially requiring another round trip.
The latter means you don't want to make those mechanisms the default, but rather use them selectively in certain situations.
The former means even if you apply countermeasures you are not fully protected. If you get flooded purely by the bare amount of packets and the system stalls just from handling them, all the higher level mitigations won't work very well anymore. That's the difference between a DDoS and a DoS - the DDoS might not even need an asymetry in cost, it just brute-forces the system down.
There's some sense in which a little asymmetry is unavoidable -- a malicious attacker can always just send whatever bytes they want over the wire, and a server on the other end with any practical purpose must at a minimum receive each of those bytes AND perform some operation equivalent to determining if any more work needs to be done.
To the extent that any real work or state management needs to be done by the server, the only way to avoid much asymmetry is to use a protocol forcing the client calls to be artificially more expensive before the server will agree to respond.
Worse, the cost is another round trip delay. That's a problem for anyone with a high latency connection.
While they may be a class of attacks, I would describe all of them as undesired requests. Sometimes, with some clever protocol design, you can, in fact, mitigate a whole class of problems.
My router has some SYN flood protection is that useful at all?
High level these kind of attacks must be easily fixable, just remove the offending IPs of the countrys internet for a set amount of time... easy peasy.
Edit: Also, even though you blackhole them within your iptables, packages are still coming to you (routed) and filling up the bandwidth whether you like it or not.
And you pay your peers according to bandwidth you use. (eg. bytes in and out per month)
So, a proper solution is to use globally distributed system to broadcast specific routes so the attack gets stopped even before it reaches you. (eg. through their own ISP's route table blackholing your routes) But that means legit users from that ISP wont be able to access your network at all...
Without needing NAT everyone can have their own IP address and biz will be able to ban individual machines instead of some giant NAT Network because one host using that IP address is compromised.
The other form of ddos is udp amplification. you send a packet to a legit host and spoof the target ip as the from ip, the reply goes to your target and bam, ddos.
Most machines don't have UDP services open to accept packets.
moving these to tcp would actually seriously help with filtering ddos, but good luck.
Running a quick netstat -p udp doesn't show any UDP entrys with LISTENING status.
the hackers are better than I thought!
Distributed can mean different things, especially if you can spoof addresses, in which case you can do fake distribution (causing src based filtering to be useless). If you know it's just a single bad AS that is doing it, then you can block the AS, but if it's distributed amongst multiple AS'es that's harder. Same with reflective attacks, the source of the traffic might not be the source of the attack and might be a legitimate source which you cannot block because your internet wouldn't work anymore (i.e. when it's DNS servers or NTP servers doing the reflection, or a GCN address which would completely take an ISP's section offline).
It's not as simple as sending a large volumetric load from A to B. It used to be that way a decade ago and it can be effective today, but it's not the only way it's happening.
Most robots participating in this are unwitting. It's incredibly unlikely someone is paying... even with stolen funds.
Often a sort of malware that more or less sits dormant until command/control sends a target to attack
edit: To the individual machine, not a lot. The sum total is where the denial of service comes in - everything has a tipping point.
This is the problem with botnets - all the connections look like real traffic at first glance.
For example, a classic is the SYN flood. In this, the attacker makes many requests to open TCP connections (with a SYN packet) but does none of the rest of the handshaking. The server does the initial bookkeeping for setting up TCP connections, before eventually timing out and freeing the resources. The SYN packets are very cheap and easy to form (and the attacker can immediately free all the resources after firing them away), but the connection state information is a little bigger. This asymmetry builds up, making the server overloaded.
I believe that asymmetries in resource consumption are, at some point, unavoidable.
You also asked:
> are there any R&D in the pipeline that may kill this type of attack once and for all?
Note that DDoS attacks are a class of attacks. They're a description for a broad genre. It's kind of like how "bronchitis" actually just means "enflamed bronchial tubes" - it's a symptom, not a cause. Even if we permanently defeat SYN floods, there are a gazillion other DDoS-type attacks (UDP flooding, messing with ARP tables - its an almost endless list).