On Sat, Mar 8, 2008 at 9:30 AM, Michael Rogers <m.rogers at cs.ucl.ac.uk> wrote: > Evan Daniel wrote: > > At least for the near term future, and probably longer, we need an > > answer other than TCP because of ugliness like Comcast's Sandvine > > hardware. Forged TCP reset packets are non-trivial to deal with, but > > the equivalent problem doesn't even exist for UDP. > > True, UDP is more robust than TCP against this particular attack, but > that just means the next logical step in the P2P vs ISP arms race is for > all the P2P apps to move to UDP, and then the ISPs will just start > throttling UDP instead of forging RSTs. Ultimately if your ISP doesn't > want to carry your traffic, they won't carry it.
Sure, the arms race will continue. Hence "near-term future." For the near-term future, we want to be on the winning side of it, rather than assuming we can switch to the way that *currently doesn't work*. You're also ignoring the reason they're forging resets rather than throttling -- they don't need to modify the main routing hardware to inject packets, they do need to modify it to drop or delay them. Thus it's cheaper to forge TCP resets than to throttle UDP or TCP. They certainly *can* throttle things properly, but the point remains that they aren't, and likely will continue doing exactly what they're doing for the near term future. I don't know what the state of legacy NATs is. I had been of the impression UDP worked better, but I could easily be mistaken. Evan Daniel