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

Reply via email to