> As the internet gets more users and more devices connected, the ratio of DDoS volume to a single connections volume will only get larger.

I'm not sure if that's the case. Large volumetric DDoS records have been increasing, but connection bandwidths have also been increasing.

7 tbps is a lot of traffic, but it only takes 7,000 nodes with 1G symetric connections to do it. Botnet sizes don't seem to be getting that much bigger.

The basic solution to volumetric DDoS is to get a bigger pipe; this works, kind of, but it's hard to get 7 Tbps of downstream capacity, and you need to be careful that you don't become a 7 Tbps reflector.

The more scalable way is using BGP to drop traffic before it gets to you. Depending on your relationship with your hosting facility and their ISPs or your ISPs, it's often pretty easy to get packet to a given IP dropped one network before yours. Ocassionally, those blocks could propagate, and things like BGP Flow Spec promise more specific filtering... dropping all packets to an attacked IP mitigages the attack for the rest of the IPs on the path, but dropping all UDP to an attacked IP might get all the attack traffic and let most non-attack traffic through... More specific rules are possible if you wanted to try to let DNS and HTTP/3 survive while being attacked.

To work against a 45 second attack, BGP based measures need a lot of automation.

Not a 100% solution but would help greatly if ISPs:

1) performed egress filtering to prevent spoofing arbitrary source addresses

2) temporarily shut off customers that are sending a large volume of malicious traffic

Banks have already figured out fraud detection through pattern recognition, ISPs can do the same. When a connection has never used more than 300/10 of a 1000/1000 link and 80% of that was TCP with dstport 80 or 443, then it starts doing /900 UDP to every possible dstport, maybe something is wrong?

"Your network is generating an extraordinary amout of traffic, which is likely the result of a virus-infected device. As a result, we have lowered your speed to 100/20. Please read the steps to check your devices and unlock your connection here: ____"

Apparently no solution that has gained traction, and no single solution that works everywhere. Source address filtering (BCP 38) got us part of the way, but it's difficult/undesired to do in data centers.

IoT devices (speculated to be used here) would have to have a solution upstream. Things like MUD (RFC 8520) have been proposed, but have problems too - developers need to be able to list all communications of their device and make that available somehow (MUD profile server). Some consumers will never do it on their own, and may want to prevent alerting a device manufacturer they have a device (think connected adult toy...).

Also given that IoT devices may never be updated by their owners, expect to see IoT botnet DoS attacks for years.

Consumer home/office routers provide their clients IP connectivity without reserve. Why is that the case?

The default is to allow all available bandwidth, which presumably should be the case from ISP to consumer (most likely a paid-for service), but why should that be the default at consumer router <-> IoT? What need has your printer for 500Mbps outgoing? Or my fancy toothbrush?

Locate and brick IoT devices with vulnerabilities?

Capachas?

Sorry for the worst and most hated possible solution, but I thought I'd at least mention it.

Maybe too many failed capachas causes you to not connect to the IP for an hour.

Make people pay per traffic.