>That problem is hard. It's not just that we need a way to tell the source ISP to drop the traffic on their end, it's that we need a way for them to trust that you are the actual destination and not someone trying to cause a denial of service by having them drop legitimate traffic.
I think a large part of it could be solved by a combination of (1) egress filtering and (2) the ISP enforcing TCP congestion control -- so that if a DDoS'd server stops sending an ACKs to an attacker, the attacker get limited (at its own ISP) to 1 packet every few seconds. For UDP, something similar could probably be done -- e.g., if no packets are received from the other host, then drastically rate-limit the bandwidth to that host. (I'm not sure if this would break any widely used UDP protocols, though.)
"Have middleboxes do something" as a method of solving problems has historically created more problems than it solved.
The current dark age where nearly everything uses TLS/443 has been the net result, because for a significant minority of networks nothing else can get through. People are now even running DNS over TLS, even though DNS itself is allowed and DNS over TLS is complicated and inefficient, because the middleboxes prevent the DNS protocol from evolving to have better security.
Inviting more interference would only create more problems. For example, suppose I want to create a multipath UDP-based protocol where the acknowledgments can be consolidated (and so only sent along one path). That proposal would break it and force me to use something less efficient. In general it creates asymmetric routing problems at the ISP level.
Middlebox "solutions" cause problems that are hard to predict and even harder to fix after the fact, because once 20% of networks are doing something it's hard to get half of them to stop even after the problems are discovered.
And it may not even solve the original problem. What happens when the DDoS is just a botnet acting like a huge number of normal users?
They can do things like spoof DNS requests from the victim which are known to have large responses. The attacker causes ~4000 bytes of traffic to be sent to the victim from the DNS server by sending a ~40 byte DNS request.
That amplifies the attacker's bandwidth but is a lot easier to distinguish from normal traffic, and would be prevented if everyone did egress filtering because then the attacker couldn't spoof the requests.
But that only prevents the amplification, not the general problem. A botnet with millions of computers in it has enough bandwidth even without amplification to cause plenty of trouble.
I think a large part of it could be solved by a combination of (1) egress filtering and (2) the ISP enforcing TCP congestion control -- so that if a DDoS'd server stops sending an ACKs to an attacker, the attacker get limited (at its own ISP) to 1 packet every few seconds. For UDP, something similar could probably be done -- e.g., if no packets are received from the other host, then drastically rate-limit the bandwidth to that host. (I'm not sure if this would break any widely used UDP protocols, though.)