NNSquad - Network Neutrality Squad
[ NNSquad ] Ignoring RSTs
On Wed, Apr 23, 2008 at 1:52 PM, Craig A. Finseth <fin@finseth.com> wrote:
> ...
>
> Without having an inline blocking mechanism (eg, ACL injection into a
> router), with the significant reliability headaches incurred, RST
> injection is the ONLY mechanism for a legitimate network policy
> enforcer to block a TCP connection.
> ...
>
> ...and it will only work so long as the endpoints respect it.
>
> How long until someone patches the network driver to ignore RSTs?
> Sure, the end user might run into a few problems if they do so and
> have to manually cancel some connections, but far fewer than they will
> have if they continue to respect the RSTs.
>
> If _any_ network management mechanism is perceived to be at the
> expense of the user('s desire to achieve a goal), it will eventually
> be bypassed.
>
This is not something i'd consider that likely:
a) You need BOTH endpoints to cooperate. Very hard to begin with, as
Windows is pretty protective of its TCP stack.
b) You can just switch to UDP.
c) RSTs are very common. About 10% or so (give or take) of all flows
are ended by RST packets. Ignoring RSTs would be done at ones own
peril. Thus for every injected RST, you have thousands of benign RSTs
which must be respected.
d) Its hard to tell an injected RST from a legitimate one. There are
race conditions you can detect, but such race conditions won't always
occur. And I've seen legitimate sources that generate such race
conditions as well (buggy NATs, loadbalancers). So you CAN detect RST
injection, but you can't RELIABLY detect it.
e) Fine, the ISP just goes through the effort and implements ACL blocking.
Thus I think the "Ignore RST" is not going to happen, and even if it
does, it won't be effective.