Is a NAT IP viewable from outside your network?

Very technical question here. In a current court case, RIAA Rips Defendant in Nation’s First Filesharing Jury Trial, the RIAA claims that the defendant illegally downloaded 1700 copyrighted music files and wants to be compensated to the tune of $4Mil. Seems fair, eh? :rolleyes:

But nevermind. The defense maintains that the accused, Jammie Thomas, might not have been at her computer and besides, with a wireless router, a neighbor could have been the actual downloader without Thomas knowing about it.

So my question is, is the 192.168… NAT address viewable from outside the local network? If so, that could lead investigators to a single computer (but still not tell who is sitting in front of it). If not, then any number of computers and users could be involved.

So are the prosecutors right about this single item, and could anyone monitoring traffic to/from detect the internal network address?

Some file sharing apps create a username based on some property of the machine on which they’re run, so I suppose it’s conceivable that it would show up that way, but other than that, no - the routing table isn’t available outside the network, without hacking it

Some protocols such as FTP, which predated widespread use of NAT, do include the original IP address in the payload. Naturally, it can be difficult to get those protocols to work with NAT.

Mangetout got it, at least as a general rule. However, there are situations – probably considered “hacking” – in which it might be possible. For instance, leaving the default password on a router. A bug in the hardware is another.

More interestingly, an office mate of mine used a linux box as his router. He came to realize, after noticing in his logs that his network had been scanned, that an outside party could set his public IP as their gateway; in doing so, his box would allow said outside party to “hop” through his “router” and reach his internal LAN. Yes, it was a misconfiguration, but the point is that sometimes internal IPs are retrievable.

On preview, I note Usram’s point; IIRC, some P2P apps also put the user’s IP address in their payload. What I don’t recall is if that was limited to the public IP address or not.

If you use a protocol that sends your IP address in-band, it will definitely be the internal (“private”) address. Your PC normally has no way to know what its “real” IP address is.

So there are lots of scenarios under which outsiders could see your private addresses.

So, in the court case, they MIGHT be able to see it, but there’s no GUARANTEE that they can. Right?

Isn’t there another possibility, that the internal IP isn’t transmitted outside the net, but a port number is used to distinguish intranet machines? When data is returned, there has to be SOMETHING inbedded in it to tell the router where it should go, right?

Yeah, the translation table held by the NAT device, which maps external port number to (internal address + port). Nothing in the packet itself tells you what internal IP address was used.

For general IP traffic, that’s true.

But this case is about the use of specific software – Kazaa. So the question is much more specific – does the Kazaa client software identify and transmit the actual IP address (or other distinguishing characteristics, like a MAC address) in use at the client end?

The destination port does indeed direct the traffic once it hits the public-facing IP address – but what happens then depends on the setup. If there is no NAT device and router in use, then the public-facing IP address assigned by the ISP is actually in use on the client machine – the client is listening on that particular port.

If there is a NAT device in use, then, as Usram suggests, the NAT device is assigned the public address on its WAN interface and is listening on that port. It also has a dynamic or static map that directs inbound traffic on that port to a particular private IP address on the LAN interface side.

For ordinary, run-of-the-mill traffic, the internal addresses would not be part of the IP packet once it left the NAT device, and would effectively be invisible outside. But a particular client, like Kazaa, might include its machine name, IP address, MAC address, or something else in its data.

See, it’s crap like this that makes me, a card-carrying geek, cower in fear at the thought of attaching one of my home-brew Linux servers to the raw Internet. I know I’d screw up some tiny detail and be hacked within minutes :(. It’s a real shame because I would like to use a standalone Linux box as a gateway and do all kinds of fancy filtering stuff on it that my router can’t do. Guess I’ll have to get a WRT54g and put DD-WRT on it and hope that has the features I want.

Have no fear there. Although I said “misconfigured”, it wasn’t really. My mate just didn’t think there was a need to run iptables (a firewall), since he’s very careful about the exposed ports/services. If he did, the packets would’ve been caught and rejected at the public interface. IMHO, it’s always a good idea to set up at least a basic firewall.

Since I haven’t looked at Kazaa’s protocol, I can’t say whether the IP address is in there. However, even if it is, if the router was set up to use DHCP (which is likely), there’s no guarantee that the same internal IP address is assigned to a given computer.

Here is where it gets tricky.

If the defendant was using a cable modem, it usually acts as an ethernet bridge - all external packets get forwarded to the single internal mac address. To share internet from that point, the internal mac address would have to be for a NATting router, and have the cloned mac address of the registered PC (most cable modems used to be locked to a single MAC address).

If this was the case, the NAT router would need to have a pinhole forwarding P2P packets to the PC running the P2P app. This generally needs to be manually configured, but UPnP can be used.

So the defendant has to prove that she had a wireless NAT router that was so badly configured that someone else was able to attach to the network, set up a pinhole and use the network to download music via P2P. This may not be difficult, as most wireless routers are pretty poor at security out of the box. But the defendant has a lot to prove - whereas the prosecutors have the IP address, the ISP records of the defendants equipment, and the P2P data as well.

Not easy.

But the damages claimed by the prosecution are preposterous, and I hope it fails on those grounds alone.


I guess unless someone here has disected the KaZaA code or written it, we’ll never know. But it seems to me that anyone writing code for such a purpose would take extreme pains to avoid leaks like this, at least more than someone writing a word processor.

So that brings me to a related question – unless RIAA had a real-time trap on the line during the alleged downloads or had a court order in advance, they would be unable to analyze anything more than what the ISP stored in logs. Just how much is stored that way? Surely application data wouldn’t be, if only for data size reasons. I would imagine only brief headers, and even then, not every packet, would be saved for very long.

So if I went to my ISP to mine for data passed thru them 6 months ago, what detail could I expect to get, even with an after-the-fact blanket court order?

As I understand it, the RIAA sets up its own Kazza client, and then downloads music from the target. This proves (a) the target is offering for download the RIAA-protected material, and (b) at the time of the download, the target is using IP address w.x.y.z.

Then the RIAA determines what ISP is responsible for IP address w.x.y.z, and sends them a demand letter, saying, “On Tuesday, July umpty-frtoz, we downloaded copyrighted material from IP address w.x.y.z. Who had that address at that time?”

The ISP then checks its own DHCP logs and determines what ARP address and associated customer had that IP address at that time.

Now the RIAA’s got a name and evidence that that the named customer was hosting their copyrighted material. That’s enough for them to sue.

They don’t need the ISP to keep data packets – the RIAA captured the data packets as they came in to the computer the RIAA was using. The data packets show a destination IP address of w.x.y.z, which they can demonstrate was assigned to the defendant at that date and time.

One other note – this is a civil suit. To prevail, a plaintiff must show by preponderance of the evidence that their claims are true. Unlike a criminal case, which must be proved beyond a reasonable doubt, the RIAA must only persuade the finder of fact that it’s more likely than not that their claim is correct.

In a criminal case, they would have to disprove any reasonable hypothesis other than the one that supports guilt. Here, the jury can say to itself, “Yeah, that other thing could have happened, but it probably didn’t,” and award a win to the RIAA.

Thanks, Bricker. I hadn’t considered that the RIAA might actually be the download recipient/culprit, so of course they can capture their own data stream.

Sort of seems like entrapment, doesn’t it? What if all the downloaders were RIAA plants and the uploaders were honeypots? That would make a fun court case.

Another plausible explanation would be that the defendant was running a wireless access point in bridge mode instead of as a router, and her computer was off, but someone else hopped on, got assigned her real IP address via DHCP (from the ISP), and shared files. The AP would be completely invisible from the perspective of someone logging the P2P data.

Not entrapment; the defendant is offering the copyrighted material for download before the RIAA computer is turned on. The essential element of entrapment is that the accused is persuaded by the government to commit a crime he would otherwise never have committed. Here, even if we analogize the RIAA to law enforcement, it’s clear they did nothing to cause the defendant to start offering copyrighted material for download; he was doing it before they came on the scene.

Er… I’d say that’s a possible scenario, but not a particularly plausible one. I’m not aware of any commercial router/wireless access point that would be normally set up that way. Typically an access point in bridge mode would be placed inside the private IP network, not as a substitute for a router, and not placed on the public-facing (the ISP-facing, I should say) interface. And I’m not aware of any claim that the defendant in this case has or was using a WAP instead of a router.

Obviously, the idea gets more plausible if the accused can say, “Yeah, that’s what I was doing…” But in the absence of any such evidence, and remembering that the standard the RIAA must satisfy is merely “preponderance of the evidence…” I’m going to say that this is a long-shot story.

Yep. I have to say that the defendant has been ill advised in her defense. It should be more like…
[sweet as cherry pie southern drawl]*
ya 'onour, all I wanted was some of those internets, so I called the nice people at Comcast, and they came and fitted mah house with an internets box, and hooked up mah computer. And they didn’t say nuthin about no firewalls and antivirus. And I just left mah computer runnin, cause I got so many emails, and I clicked on each one to read them.
And mah computer started running slower and slower, and naughty things popped up on the screen, and they tell me that bad men had stolen my computer and were using it - cause they can do that, I hear.
So I took mah computer to BestBuy, and they said I had to have it “formulated” or some such thing, and they installed some software from that nice Mr Norton, to stop bad people from stealing it, and you know, it runs just as slowly as when the bad people had stolen it, and it crashes more.just as slowly as when the bad people had stolen it, and it crashes more.
So your 'onour, I don’t know nuthin about no music, or any Kazoo, or nuthin. The bad people took mah computer, but they left it, see. And thats all that I can say about that.*
[/sweet as cherry pie southern drawl]

Don’t try implausible deniability when plausible deniability will suffice.


The trial is expected to last only thru this week, so we should see some updates soon.