It's not exactly a knockdown argument by itself, but it just adds a little more to the pool of thought saying an IP address doesn't correspond to an individual. That viewpoint seems to be gaining more and more momentum, e.g. somewhat recently: http://torrentfreak.com/ip-address-not-a-person-bittorrent-c...
If you do layer 4 network address translation (NAT) - then a single IPv4 address can theoretically be used by circa 64000 people at the same time; depending on how multiplexing is done, by maybe even more.
The large-scale translators on the headends are the reality for quite a few service providers already.
So, the "IP address does not correspond to an individual" is not just a mere viewpoint gaining momentum, but an emerging hard technical fact. ;-)
Tinfoil hat Just wait, once the US government at large finally understands IPv4 networking, someone with too much power will look at IPv6 and the phrase "Look we don't have to do NAT anymore!" Then the government will assign a unique IPv6 address or two to every citizen to use as ID (they'll need a replacement anyway once they get rid of social security). Then they mandate the ISPs to track IPs, and they make it illegal to share or mask IP/IDs since that's something only pirates and thieves and other bad people do anyway. And we'll look back and say "Remember The Right to Read? rms was right again!"
If governments were to do that, they would also be forced to solve the problem of the routing table explosion. Which is a hard problem.
As for unique ID - it's already doable and being done without any IPv6. Read up on evercookie. There was an article on HN a while ago about a bunch of advertisers doing just that.
This is worse than the government having it - not only it gets abused, but someone gets rich on this.
Unique internet IDs are far from a conspiracy theory. They're being actively developed in China and South Korea to name a few. While the South Korean one has faced setbacks it's only a matter of time before they become common place in other countries in my opinion.
But there are at most 2^16 TCP ports available on the other side. I think this doesn't theoretically prevent one from reusing an exterior port multiple times for multiple connections to different other IP addresses or ports, but that would be both rather tricky and inconsistent with some cultural expectations regarding the use of initiating ("client") ports, and so I doubt any current NAT stack in common use uses that approach (though I'd love to be proven wrong). It also fails naturally if all sixteen million hosts try to communicate with the same host/port on the other side. UDP has similar but nonidentical constraints.
I was originally thinking this would break things like IDENT, but then I remembered that they use the entire tuple (d'oh). I'll take your word for the pf behavior, and retract my bogus guess about kernel NAT. :-)
one-up-manship sucks, but correct information is beneficial. ;)
The problem with the term "NAT" as "Network Address Translation" is the
term is often misused/incorrect; most all modern "NAT" implementations
are actually "PNAT" ("Port and Network Address Translation") where the
translator system modifies both the source address and source port
rather than just modifying the source address.
For notes, the earliest translation implementations really were just
address modification, and hence, really were plain "NAT," but the
problem of conflicting port numbers is the reason why just about every
implementation moved to PNAT.
When running a PNAT implementation, you can exhaust the number of
available TCP ports with enough load from client systems. The number of
available TCP ports is typically, but incorrectly, stated as 2^16 ports,
but in practice, you can't use all of them.
Getting around the TCP port count limitation is entirely possible, and
regularly done in large scale networks. The early implementations were
standard "proxy systems/servers" (typically requiring client-side
configuration like, address, port, user/pass, etc.). More modern
implementations are "transparent proxies" and require no client-side
configuration. Transparent proxy implementations (typically) count on
PNAT in order to be "transparent" to the client systems and prevent the
need for client-side configuration.
The mental leap one needs to make in order to understand how to get past
the TCP port count limitation is, understanding that a single public IP
address can be shared by multiple systems simultaneously without
NAT/PNAT or proxies. There are many ways to do it from "load balancing
appliances," to CARP (Common Address Resolution Protocol - free in
OpenBSD), to VRRP (Virtual Router Redundancy Protocol - patented by
Cisco), to other methods. This is often combined with multiple stateful
firewalls where all of the firewalls share their state tables.
Similarly, pools of public IP addresses can also be shared amongst
multiple systems simultaneously. Let's say your shared state table
already has an entry with your source of "aaa.bbb.ccc.ddd port 1331",
with a pool of address, you now have your choice of changing either the
port number or the source address. --This isn't particularly precise,
but it is a good way to reason through it.
AOL used to (and maybe still does?) run some humongous transparent
proxies. If you search around, you'll find some (historic?) complaints
from sites about not being able to block trolls or malicious traffic
from jerks on AOL without blocking everyone on AOL. The only IP the site
owners got was the from the small block dedicated to the AOL transparent
proxies. I think this issue may have been resolved by the "proxy-for"
header being added eventually (i.e. often called a "non-anonymous
proxy"), but my recollection is a bit fuzzy.
The point to take away from this is, AOL, at its height, was able to
stuff all of it's millions of users behind a couple dozen proxies/IP's,
so the number of TCP ports is only a limitation in theory, but it's not
a limitation in practice.
Yogi Beara once said, "In theory, practice and theory are the same, but
in practice, they're not."
The number of available TCP ports is typically, but incorrectly, stated as 2^16 ports, but in practice, you can't use all of them.
That's mainly why I wrote “at most” instead of trying to compute the exact available number, yes.
You don't even theoretically need application-layer gateways to multiply the effective number of ports by a large factor for common loads, of course, as I mentioned; I just erroneously thought such technique was not in common use, per my reply to eggnet.
I thought that BitTorrent used TCP? If so, spoofing a connection requires being in a position where you can intercept the return packet in order to be able to complete the TCP handshake. Possible, but requires a spoofer to be very well connected.
You don't need to spoof a TCP connection to register a spoofed IP address on a tracker. The tracker GET request has an optional `ip` field, the contents of which is registered as the client's address, regardless of the source address of the actual request. So it's trivial to write a Bittorrent client that reports a false address to the tracker.
Probably. When the tracker responds with a list of peers, each peer only has an id, an ip & a port; there's no real_ip or reported_ip parameters. Of course there could be tracker software in the wild that ignores the ip parameter entirely; it's just a spec, not a contract.
I don't think they mean spoof in such a technical way. I think they just mean it as "the You Have Downloaded website could be just generating files to go with IPs", and similarly "any torrent logs may have been spoofed/made up."
Obviously the next step for the You Have Downloaded site is to track in real-time and say "This IP is currently downloading x,y,z."
