dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
5748
AstroBoy
join:2008-08-08
Parkville, MD

AstroBoy

Member

iptables and RST revisited

On the subject of Comcast forging RST packets to block bittorrent, I found this about 1 month ago:
iptables -A INPUT -p tcp --dport *x* --tcp-flags rst rst -j DROP
- where *x* is the port used by your BitTorrent client

The thread was locked, so I had to start another.

I read the RFC (forgot which one). From what I read it would be a violation of the protocol to receive a RST packet after the connection was ESTABLISHED. Based on that I think this improvement is valid.

iptables -A INPUT -p tcp --tcp-flags RST RST -m state --state RELATED,ESTABLISHED -j DROP

iptables -A FORWARD -p tcp --tcp-flags RST RST -m state --state RELATED,ESTABLISHED -j DROP

No need to give a port number. Just DROP all invalid RST packets. Maybe the "RELATED" is not needed.

2 examples, depending on where you are running the bittorrent software and iptables. I have a NAT router with iptables, so I need the second example.

Oh, I know this does not help much unless everyone is blocking RST packets. Also, I know Comcast says they will stop forging the RST packets soon. I just want to confirm things work as I think they do.

Thanks,
Astro

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

funchords

MVM

You will receive a RST in an established state if the far end of the connection has crashed and restarted. Your rule would block them. The result would be connections that appear to live forever (since TCP does not eventually time out).

Having studied this extensively, I wouldn't block RSTs this way on a host-by-host basis. You can't get enough of the non-affected to cooperate. Even though Comcast and Cox are huge ISPs, there are simply too small of a population for the rest of P2Pdom to worry about.

But if we could, I would honor an RST in the Established state if it was received more than 5 seconds after the last received data or ack packet. Otherwise, I'd drop it. Even if we guessed wrong by dropping it (because the router or machine did reboot), then the next time we tried to send any kind of data we'd get another RST in response which then would be honored.

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

1 edit

1 recommendation

koitsu to AstroBoy

MVM

to AstroBoy
I concur with funchords See Profile.

Do NOT ignore TCP RST. Do NOT assume TCP RST will not happen during a normal TCP session -- it CAN happen on established connections which are being torn down by the remote end for one reason or another. It is a legitimate TCP flag that can happen in the middle of a connection when an anomaly occurs on the remote end.

I'm willing to bet you reached your conclusion solely by looking at the flow diagram on Wikipedia. Sadly, that diagram does not cover all cases with TCP. Here's some more appropriate reference information which you should read in full, supporting what funchords See Profile and myself have advocated:

»pages.cpsc.ucalgary.ca/~ ··· sets.pdf

That said, my opinionated response comes forth:

Stop trying to circumvent Comcast's TCP RST injection. There is nothing you can key off of to detect said injection; your only option is to use encryption, or wait for Comcast to remove the Sandvine equipment (which they had better do once the caps are put in place). I hate it as much as you do, if not more so, but there is no way I'm going to violate standard protocol to try and work around it.

Please remove the iptables rule you added.