  funchords Robb Premium,MVM join:2001-03-11 Hillsboro, OR
·Skype
·Verizon Online DSL
·Comcast
| reply to funchords Tests and Results-RSTs are set in both directions
Regarding these Posts and similar: »redhatcat.blogspot.com/2007/09/b···pfw.html »redhatcat.blogspot.com/2007/09/b···les.html
Several have mentioned that it is possible to defeat the injected/forged RST packets by ignoring them at a firewall. I tested that theory earlier »Re: Comcast is using Sandvine to manage P2P Connections but the rumor persists. "Redhatcat" claims first-hand knowledge that a forged RST is not sent from the Comcast network.
»digg.com/linux_unix/Linux_iptabl···_Killing quote: Comcast does not kill non-Comcast connections. I only know from personal experience.
I believe they choose to not do this to avoid lawsuits from other ISPs, as that behavior could be seen as a DoS attack on their customers/networks. That's not to say what they are doing to their customers now is not a DoS attack, but they are less afraid of lawsuits from individuals than other ISPs most likely.
Unfortunately, he is incorrect.
The following are two Wireshark copies of the same TCP conversation -- one from a Comcast system that is seeding a BitTorrent file, one from a Non-Comcast system that is trying to download it. The connection is torn down by forged RST packets about 30 seconds after it starts:
Conclusion: The RST is sent to both the Comcast and Non-Comcast sides of the connection.
If only one side respects the RST flag, the connection will be left in a half-open state. To one side, the TCP connection will appear to be valid and open. To the other, the TCP connection will have been ended. A half-open TCP connection is useless for exchanging data.
Comcast users should not modify their firewalls to drop RST packets as it is not an effective defense against the injected RST packets.
-- Robb Topolski -= funchords.com =- Hillsboro, Oregon USA Are you affected by Comcast's RST forging? How to test it! -or- Read my original report. |