On Thu, 16 Aug 2007, Alexander Harrowell wrote:
An "Internet variable speed limit" is a nice idea, but there are some serious trust issues; applications have to trust the network implicitly not to issue gratuitous slow down messages, and certainly not to use them for
Yeah, that's why I was limiting the need (requirement) to only 1-few ASN hops upstream. I view this as similar to some backbones offering a special blackhole everything BGP community that usually is not transitive. This is the Oh Crap, Don't Blackhole Everything but Slow Stuff Down BGP community.
Further, you're going to need *very good* filtration; necessary to verify the source of any such packets closely due to the major DOS potential. Scenario: Bad Guy controls some hacked machines on AS666 DubiousNet, who peer at AMS-IX. Bad Guy has his bots inject a mass of "slow down!" packets with a faked source address taken from the IX's netblock...and everything starts moving Very Slowly. Especially if the suggestion upthread that the slowdown ought to be implemented 1-2 AS away from the problem is implemented, which would require forwarding the slowdowns between networks.
For the ICMP packet, man in the middle attacks are really no different than the validation required for any other protocol. For most protocols, you "should" get at least 64 bytes back of the original packet in the ICMP error message. You "should" be validating everything against what you sent. Be conservative in what you send, be suspicious in what you receive.
It has some similarities with the Chinese firewall's use of quick TCP RSTs to keep users from seeing Bad Things; in that you could tell your machine to ignore'em. There's a sort of tragedy of the commons problem - if everyone agrees to listen to the slowdown requests, it will work, but all you need is a significant minority of the irresponsible, and there'll be no gain in listening to them.
Penalty box, penalty box. Yeah, this is always the argument. But as we've seen with TCP, most host stacks try (more or less) to follow the RFCs. Why implement any TCP congestion management?