UDP DDOS mitigation. It'll be important for protocols like HTTP3/QUIC where decrypting every packet is costly, and malicious packets can't be identified until after the application tries to decrypt them.
The idea is to assign a random 8 or 16 byte number (DdosID) to each connection. The DdosID is unrelated to any other identifier; like the HTTP3 connection id. The client puts the DdosID at the beginning of every UDP packets data section (raw; no encryption or compression.) Packets that have a valid DdosID are processed. Packets with an invalid DdosID are dropped. New connections use zero as the DdosID. Any client can use zero to re-establish a connection or if something goes wrong.
If attackers make random DdosIDs it will result in packets that are dropped before decryption. If a valid DdosID (or hundreds of valid DdosIDs) are used, the volume of packets with that DdosID will make the attack obvious, and the DdosID can be invalidated and the packets dropped.
Attackers will need to spam new connection attempts (DdosID zero) to deny service. New connection attempts could be dropped, or a small percentage allowed when the application can handle them. The rate of allowed new connection attempts could be adjusted very easily and quickly, but a high rate of bad packets would still deny new connections. Existing connections to continue to work.
The challenges are mostly creating functional thresholds: what packet volume is too high? how long is a DdosID valid? Should a load balancer record the IP and Port and to force a new DdosID if it changes?
I would also like to see a way that applications and load balancers can use a DdosID system without it being dependent on the specific application; DdosID should not depend on the protocol it's protecting.
The idea is to assign a random 8 or 16 byte number (DdosID) to each connection. The DdosID is unrelated to any other identifier; like the HTTP3 connection id. The client puts the DdosID at the beginning of every UDP packets data section (raw; no encryption or compression.) Packets that have a valid DdosID are processed. Packets with an invalid DdosID are dropped. New connections use zero as the DdosID. Any client can use zero to re-establish a connection or if something goes wrong.
If attackers make random DdosIDs it will result in packets that are dropped before decryption. If a valid DdosID (or hundreds of valid DdosIDs) are used, the volume of packets with that DdosID will make the attack obvious, and the DdosID can be invalidated and the packets dropped.
Attackers will need to spam new connection attempts (DdosID zero) to deny service. New connection attempts could be dropped, or a small percentage allowed when the application can handle them. The rate of allowed new connection attempts could be adjusted very easily and quickly, but a high rate of bad packets would still deny new connections. Existing connections to continue to work.
The challenges are mostly creating functional thresholds: what packet volume is too high? how long is a DdosID valid? Should a load balancer record the IP and Port and to force a new DdosID if it changes?
I would also like to see a way that applications and load balancers can use a DdosID system without it being dependent on the specific application; DdosID should not depend on the protocol it's protecting.