NNSquad - Network Neutrality Squad
[ NNSquad ] Re: "How to Patrol Your ISP"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <7144C7E7-5D66-4F99-BA0C-D729BA8BBF1C@neiltiffin.com>, Neil
Tiffin <neilt@neiltiffin.com> writes
>Wireshark on both ends may be a little complicated for beginners to
>utilize for nnsquad efforts.
My credentials first :) I've worked on these issues, and have published
papers on the Great Firewall of China and on BT's "CleanFeed" that
attempts to block child pornography, plus LAN spoofing issues in my PhD
thesis....
... and most things are too complicated! and that's even when you think
you understand how TCP/IP works (which will certainly be a step too far
for most of the people who try to patrol their ISP), you'll discover
some little oddments that you'd forgotten or was invented too recently
for anyone except real experts to know about..
So as soon as you move beyond "can I contact the other end", you need
some very careful experiments to work out what's going on.
I noted people earlier mentioning (tcp)traceroute, ping & such. The
results from these are almost meaningless unless you have a really good
grasp of the network design in your neighbourhood :(
It's also amazing how many people don't understand it isn't a router's
job to return ICMP Echo Response packets (or receive UDP from you), and
that a lack of them doesn't mean it is turned off, or that
www.microsoft.com is dead because it never responds; or indeed that
Solaris ratelimits responses and so you tend to get *'s in the middle of
otherwise interesting values.
Designs like CleanFeed send different packets via different routes (and
there are other related designs at the BGP level). Once you know that
you can check for the effect, but naive testing would entirely miss it.
http://www.cl.cam.ac.uk/~rnc1/cleanfeed.pdf
>It seems to me that some sort of
>standardized, specific to nnsquad, measurement server(s) should be
>set up to control variables at one end of the connection.
I think you need to move beyond that to a standardized tool at the
testing end as well -- each module of which is designed to detect one
specific type of interference.
Otherwise you're going to have a whole heap of false reports from NATs,
local firewalls, or just service outages, along with loads of traces
that no-one can be bothered to sort through the minutiae of (if indeed
they aren't too private to look at).
>This would
>make the measurements somewhat more reliable and consistent. Of
>course, this could be gamed by a smart ISP, but this would be
>interesting to know also.
It won't so much be a smart ISP, as a smart appliance manufacturer :)
but I expect that it will be inability to make a test look exactly like
what the appliance is trying to block that will generate inaccurate
results, rather than "enemy action".
- --
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/AwUBR0CMtJoAxkTY1oPiEQIr6ACg62ZyiyAHqnBcThwjZjK5nVtvjdoAnjEl
ksOoaalM9nCzivFk6tx3s+NU
=vBXO
-----END PGP SIGNATURE-----