NNSquad - Network Neutrality Squad
[ NNSquad ] Re: How do I detect connection disruption by my IAP?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <3ECD7F7DDE95BA4FA598E8DDE71F1A5104F40875@nwpsrv08.edj.ad.edw
ardjones.com>, Holtz,Robert <Robert.Holtz@edwardjones.com> writes
>You would want to zero in on TCP SYN packets immediately followed by a
>TCP RST packet, i.e., the handshake would never complete.
I think it's unlikely that the RST would be in response to the SYN, and
traces such as the one at
http://torrentfreak.com/images/comcast-rst1.txt
show that it's occurring rather later on in the connection.
Several people report seeing multiple RSTs, this may well be because the
mechanism is out of band, and it's necessary to create RSTs with
correctly matching ACK values -- rather like the system used in China
which we described in our 2006 paper
http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf
One of the things we found was that it was necessary to be extremely
careful in the way that we ran the tests because the Chinese system also
proactively blocked all future connections to the same destination for
many minutes. Also, because of the out-of-band nature of the system
packets that were being "reset" also reached the far end and were
replied to -- this led to complex interactions that were not always the
same from one test to the next. Logging the packets at both ends of the
connection is to be recommended for a full understanding! Doubtless many
people are looking carefully at the Comcast system to better
characterise what it does...
Looking at the paper you will see that we found, in the Chinese case,
that connections could continue if the forged RSTs were ignored either
en masse (which does less harm than you'd naively expect) or if you
ignored packets with the "wrong" TTL.
However, evading Comcast's particular way of interfering with traffic
probably isn't, as I understand it, really the point of this list :(
- --
Richard Clayton <richard.clayton @ cl.cam.ac.uk>
Computer Laboratory, University of Cambridge, CB3 0FD
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBRzOeVJoAxkTY1oPiEQJ/YQCgy9Gzt60rSkEsT27rsz4SFzVc22UAn0I5
lFyP16VY7cBwCXa1y0xdi9Yg
=Yygx
-----END PGP SIGNATURE-----