Re: Can we block the reset packets? in http://www.dslreports.com/forum/r20565801 en Wed, 11 Nov 2009 08:55:09 EDT Wed, 11 Nov 2009 08:55:09 EDT Re: Can we block the reset packets? http://www.dslreports.com/forum/remark,20578965 funchords :
said by Hehe :

Well, looking at the RFC it seems like we should not receive a RST while the connection is in the ESTABLISHED STATE. So, maybe we can drop RST if ESTABLISHED?

Anyone know how to make iptables do that?

And I assume I am not 100% correct! :)
It just can't be that easy.
RFC 793, Figure 11 would happen with one end in the Established state, thinking it was in a full-open connection when it actually is only in a half-open connection due to the remote host's reboot.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
HTTP is the new Bandwidth Hog...
]]> http://www.dslreports.com/forum/remark,20578965 Mon, 02 Jun 2008 16:27:35 EDT Re: Can we block the reset packets? http://www.dslreports.com/forum/remark,20578598 anon : Well, looking at the RFC it seems like we should not receive a RST while the connection is in the ESTABLISHED STATE. So, maybe we can drop RST if ESTABLISHED?

Anyone know how to make iptables do that?

And I assume I am not 100% correct! :)
It just can't be that easy.]]> http://www.dslreports.com/forum/remark,20578598 Mon, 02 Jun 2008 15:25:33 EDT Re: Can we block the reset packets? http://www.dslreports.com/forum/remark,20570655 funchords :
said by MxxCon See Profile :

you know perfectly well
With respect, your unnecessary attitude toward others does not promote friendliness. You called the previous poster's idea idiotic and you're being condescending to me.

In this case, you misunderstand how RST works. These are just facts, nobody wins or loses on the strength of their debating skills. It is whatever it is. We both learn about it by being here.

said by MxxCon See Profile :

if the far end crashed, it wouldn't generate RST. it wouldn't generate anything at all.
Right, but when network devices crash, they often reboot. When they come back up with no memory of the pre-crash states, then start receiving TCP packets on a closed port, they send RST in response.

This specific example is explained in RFC 793, Figure 11 (either page 34 or 35).

said by MxxCon See Profile :

RST would be generated if far end decided to close the existing connection, which can be a valid request.
If the far end decided to end the existing connection, FIN should be sent, not RST.

Anything is possible (there's an older Microsoft webserver that sends RST to kill the FIN's TIME_WAIT interval), but these exceptions are rare and usually pointed out as mistaken implementations.

said by MxxCon See Profile :

some bittorrent clients want to connect only to seeds, so the moment they see it's not a seed, they will abort such connection generating RST. blocking such packets will break your application
As said above, FIN not RST, is what should be sent. FIN completes the connection gracefully. RST can cause the loss of sent-but-unacknowledged data.

You can see this using Wireshark.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
HTTP is the new Bandwidth Hog...
]]> http://www.dslreports.com/forum/remark,20570655 Sat, 31 May 2008 20:59:57 EDT Re: Can we block the reset packets? http://www.dslreports.com/forum/remark,20569222 MxxCon : you know perfectly well if the far end crashed, it wouldn't generate RST. it wouldn't generate anything at all.
RST would be generated if far end decided to close the existing connection, which can be a valid request.
some bittorrent clients want to connect only to seeds, so the moment they see it's not a seed, they will abort such connection generating RST. blocking such packets will break your application]]> http://www.dslreports.com/forum/remark,20569222 Sat, 31 May 2008 14:25:11 EDT Re: Can we block the reset packets? http://www.dslreports.com/forum/remark,20568628 funchords :
said by MxxCon See Profile :

impossible and idiotic request.
RTS packets are an integral part of TCP protocol. blocking them will completely destroy your internet connection.
realtime detection methods are inaccurate so any block rule will have HUGE false positive rate.
the only accurate way to detect faked RST packets is by comparing traffic from both sides and see if one generated the given RST packet to the other.
After a 2-way connection has been established, a Reset (RST) flag should only be generated by the far end if it has crashed. However, all of the forged RST packets generated by Sandvine come in within the same second as a previous genuine packet from the remote host. This being the case, it would be possible to detect a bogus RST packet and react to it differently or discard it.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
HTTP is the new Bandwidth Hog...
]]> http://www.dslreports.com/forum/remark,20568628 Sat, 31 May 2008 12:03:49 EDT Re: Can we block the reset packets? http://www.dslreports.com/forum/remark,20565801 MxxCon : impossible and idiotic request.
RTS packets are an integral part of TCP protocol. blocking them will completely destroy your internet connection.
realtime detection methods are inaccurate so any block rule will have HUGE false positive rate.
the only accurate way to detect faked RST packets is by comparing traffic from both sides and see if one generated the given RST packet to the other.]]> http://www.dslreports.com/forum/remark,20565801 Fri, 30 May 2008 19:24:28 EDT Can we block the reset packets? http://www.dslreports.com/forum/remark,20564728 anon : It would be cool if we could detect and block these reset packets! A rule on the firewall! Or maybe an iptables module?]]> http://www.dslreports.com/forum/remark,20564728 Fri, 30 May 2008 16:04:35 EDT