Slashdot Mirror
Remotely Counting Machines Behind A NAT Box
Overtone writes "Steve Bellovin of AT&T Labs Research has published a paper showing how to remotely count the number of machines hiding behind a NAT box (in IMW 2002, the
Second Internet Measurement Workshop). Your friendly DSL or cable broadband provider could implement this technique to enforce their single-machine license clause. Bellovin explains how to change the NAT software to defeat the measurement scheme, but the fix is complicated and unlikely to appear in commercial home gateways anytime soon."
Your friendly DSL or cable broadband provider could implement this technique to enforce their single-machine license clause.
There are still providers that limit you to only one computer per connection? Wow. I guess the high competition in my area (GTA) has allowed the customers a little bit more freedom. In fact, my provider will give minor tech support for most routers and hubs.
sin(6cos(r)+5A)
so that you have two firewalls back2back and the other boxes behind it? It's a bit extreme, but worth it if your cable company is composed of jackasses.
Most users just want web access, and this technique doesn't work on proxies.
You can't judge a book by the way it wears its hair.
the cable / DSL operators will soon find out that trying to wage this battle through technical means will result in an arms race they cannot possibly win...
...which will, of course, result in their attempts to find more onerous legal solutions to the problem.
I say - let the games begin!
Everyone will start to cheer when you put on your sailin' shoes.
The method described decodes packets from the NAT, using the IP header's ID field (which is normally a simple counter) to determine number of nodes behind the NAT. (Find X distinct ID field chains, that is the number of PCs...)
:)
However:
Some hosts take evasive measures. Since the IPid field is used only for fragment reassembly (see below), some Linux kernels use a constant 0 when emitting Path MTU discovery [5] packets, since they cannot be fragmented. Recent versions of OpenBSD and some versions of FreeBSD use a pseudo-random number generator for the IPid field.
Hurray for Linux...
Fron the paper:
;)
We do not currently attempt to deal with the randomized IPid generator used by OpenBSD and FreeBSD. Crypt-analyzing the generator may be infeasible in any event. It should be possible to detect a random background to other, linear sources; the current version of the code does not do that.
So take that BSD bashers [ggg]. Of course, a gateway implementation to mask/randomize the IPids would be better - giving you a site-wide fix at once.
First one to market with one wins
I can already imagine conversations like this:
ISP: We'll have to cut your net access! We detected several dozen computers simultaneously accesing the net through our service, while the contract only allows you one!
Customer: Uh, I only have one box, I just love to have 30 windows of VMWARE open at once. How better to show off system performance!
ISP: arglllll
I mean, if the customer says he uses VMware, what's the ISP gonna do? Cut off the line without real evidence? I'd assume there are enough people who'd not mind a lawsuit.
Ash nazg durbatulûk, ash nazg gimbatul
ash nazg thrakatulûk, agh burzum-ishi krimpatul.
Counting boxes is done using the "id" field in the IP header. The id field is relatively unique to each datagram sent between two hosts and is used to reassemble datagram fragments. This scheme depends on the observation that most IP stacks keep this field unique by just incrementing a counter for each datagram. By examining the id field of each packet coming from a NAT box and finding trends in the values you can tell how many boxes are behind the NAT. Each trend you can identify is another box hiding behind the NAT.
But as the article states:
We do not currently attempt to deal with the randomized IPid generator used by OpenBSD and FreeBSD. Cryptanalyzing the generator may be infeasible in any event.
So there you go. Write a patch for your IP stack to randomize the id field instead of incrementing it. I couldn't do it, but I imagine someone else can (and will).
Never approach a vast undertaking with a half-vast plan.
After reading the document (something that is rarely done among posters), it appears to me that this wouldn't be TERRIBLY hard to fix. The different machines are recognized by the sequences of IPids that are generated for the packets that are sent out. This field must be unique for each packet with the same protocal, destination, and source. This prevents the NAT from simply mangling the number in the field, making it impossible to track the number of machines.
Someone correct me if I'm wrong, but it seems to me that iptables could be updated to change the IPid of outgoing packets to a single sequence and just keep a table of old ids -> new ids. When necessary, it performs the translation. So basically it acts as a two way filter, packets behind the NAT will all have the correct id, packets beyond it will all appear as a single sequence. Would this work?
There must be some way to make it so that an ISP doing this kind of analysis becomes a DMCA violation of the customer. Any ideas?