The thing about the threat model is that in the worst case, DDOS protection is about power -- specifically, infrastructural power. It runs in contradiction to decentralization efforts.
Well maybe it should be easier to signal every middlebox that just delivered a nasty segment that you hated that segment and want the sender never contact you again. Should be a disallowed route, with a reasonable decay. Eventually they will exhaust all possible routes to you, to the boundary of the middleboxes they can get to disregard your request.
My understanding is that this would require a change to TCP/IP itself, and NATs make this system probably unworkable in IPv4. But it would result in a truly distributed ddos protection. This also brings to mind the nightmare scenario of exponentionally larger parts of the IPv6 space hoovered up to satisfy the needs of spammers. Imagine burning 1 ip address per message!
This is the first time I've heard this idea and I love it. There should absolutely be a standard for this.
EDIT: Ok, I thought about this a bit... would it actually work? Would the packets just find another path, and actually end up using more network resources as they traverse successively longer routes?
There's a trust issue, too: how far up the chain do you propagate the signal "suspected abuse from this host"? How hard would it be to abuse this system to censor people you don't like?
I don't have a mathematical proof, just an intuition about how the graph (nodes are routers, links are routes) would change in time. Yes, the packets might find another path, at least at first, but each time the recipient signals rejection every intermediate goes dark. Eventually, the sender will be surrounded, at some radius, by dark nodes. The best case is if the bad sender is rejected very quickly.
>how far up the chain
All the way, as close to 100% as possible. I would want this to be part of TLS encrypted socket such that either side of the socket can signal unhappiness with the counterparty, and have that be respected. This should be difficult to spoof, so you'd have to pick a way to signal it within the TLS stream, and do packet inspection at the middleboxes. (I never said it would be an easy solution!)
Keyword here being "nasty". You'd need some sort of trust metric to identify malicious clients. This becomes harder with botnets that lay dormant on regular users' systems.
