NNSquad - Network Neutrality Squad
[ NNSquad ] Re: "How to Patrol Your ISP"
|
This overlaps with another goal of mine -- a standard wireless<=>bridge
(AKA, an access point but I don't like that biased term) with both a closed
face for the local bubble baby network while providing an open face for amenity
access. It can also be a way to be proactive on NN assurance. For this purpose of this discussion I see such a router as
an opportunity to add measurement capabilities -- both probing and responding. I'm
interested in what router code may already have these capabilities or, perhaps
better, what a metering platform would be like since you don't really want to
hard code it. The added value would be more than just reporting in NN
issues -- it could be a start towards taking responsibility to network
integrity from the edge if such routers were widely adopted. -----Original Message----- -----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----- |