Vitanuova for 2007 September 25 (entry 1)

< Self-reference
Perfect >

I was just reading a blog post by Lauren Weinstein in which he proposes empirically detecting violations of network neutrality -- that is, Internet users would run tests to see what networks are actually doing, so they can tell whether ISPs are violating some kinds of neutrality principles. I think this is a fairly challenging problem (first because of the complexity of defining what kinds of neutrality we're interested in, and second for technical reasons), but there is one particular kind of neutrality that we can observe pretty easily, and a particular tool that would help.

I'm referring to whether ISPs are acting as passive conduits for traffic, delivering packets unmodified and not altering them or adding additional packets (apart, perhaps, from the ways specified by the standards for the very lowest protocol layers). For example, some research on the Great Firewall of China suggests that it disrupts connections that match particular rules by forging TCP RST packets that trick the parties at each end of the connection into hanging up. Other people have written code for wifi routers that will invisibly change the contents of web pages that users view when connected via those routers -- for example, altering all the image files that users load in their web browsers.

Enough end-to-end cryptography could mitigate these problems by making it technically difficult for intermediaries to tell what end-users are doing (and thus much harder to selectively interfere with it), as well as making it difficult to alter data in transit without detection. What can we do in the absence of cryptography? One approach is to capture packet traces at each end and then compare them.

Earlier today, I had an idea for a tool called pcapdiff, which takes two libpcap-format packet logs, one from each of two computers that were trying to communicate with one another, and compares them to figure out automatically whether there's evidence that packets were being systematically forged or altered by an intermediary. Clearly, all networks have innocent packet loss, so the comparison we need is not simply a matter of finding packets in one log that are not present in the other. It's quite normal to have packets sent by one end that were not received at all by the other end. (We can measure the rate at which this happened -- and compute a packet loss rate, which is worth doing with real traffic of various sorts, not just ICMP echo request packets, which networks might treat specially in order to maintain low visible packet-loss statistics.) No, the suspicious thing is when a packet is received at one end that the other end never transmitted. If A remembers sending a certain packet to B, but B doesn't have a record of receiving it, that's OK: it's just a normal dropped packet, and we can measure the rate at which this occurs, and compare it from ISP to ISP, or application to application (to see if an ISP is selectively dropping packets of a certain sort at a greater rate). But if B received a packet apparently from A that A has no record of having sent, that's a problem: the ISP has either altered it in transit or concocted it from scratch. In this case the ISP is behaving non-neutrally, and a tool that compares the packet traces with this criterion could detect this.

The one complexity that comes to mind is that the IP protocol allows networks to fragment packets that are too large, turning a single packet into multiple packets containing the same data payload. In some sense, an ISP that fragments packets is not behaving perfectly neutrally -- it's doing something other than forwarding packets byte-for-byte unaltered -- but the Internet Protocol says that this accomodation for varying network hardware (with different maximum packet sizes) is OK. A pcapdiff tool, or users conducting an experiment with one, may need to take account of fragmentation in some way, either by trying to reassemble fragmented packets, trying to prevent fragmentation from taking place at all (setting the MTU very low on both ends before beginning to communicate?), or by analyzing fragments to see if they are correctly formed and correctly derived from packets that are known to have actually been sent. (If we insist on trying to reassemble packets, there is a potential problem about how to deal with dropped packets.)


Links from other weblogs:

Sat Oct 06 03:08:41: t949a from ma754zda

t111t

Sat Oct 06 03:08:59: t949a from ma754zda

t111t


[Main]
Support Bloggers' Rights!
Support Bloggers' Rights!


Contact: Seth David Schoen