Slashdot Mirror
P2P, Firewalls And Connection Splicing
dbarclay10 writes: "There's an interesting article over at Byte about what happens when nobody accepts incoming connections any more, like when more people start using firewalls or NAT. Specifically, it talks about peer-to-peer networking(a la Napster), and how it would be affected. Good read."
Specifically the problem is 2 clients behind firewalls such that neither can be used as a server, so they cannot communicate with each other directly. They COULD have their traffic relayed through an indirect server that is open to the internet, but that means that the relay needs to be able to handle that bandwidth as well.
I'm not well versed on the internals of TCP/IP, but I believe that when a connection is established, the ip and port information are written to some type of internal table and used from then on for further data transfers across that socket.
Consider if both clients initiated a connection with the relay to open the connection. Once the connection is opened, the IP information in the internal table will be modified on both clients to the IP address/port of the NAT machine of the other client. At this point, both clients will be connected to each other but neither of them is a server. And the connecting relay only needs to pass enough traffic to initiate the connection, thereby keeping it readily available.
-Restil
Play with my webcams and lights here
Coming from the gaming industry (which has done P2P LONG before Napster), I can safely say that Proxys and NATs are the bane of a network programmer's existence. Often times it's difficult or impossible to detect them, and most of the time once detected there's nothing you can do about them.
l
NAT is certainly an improvement over application-specific proxies (like HTTP) - since you can usually make arbitrary outgoing connections, but the inability to allow incoming connections makes peer-to-peer gaming difficult or impossible.
However, there is a solution in the works, it's called Realm-Specific IP, here's the IETF working group that's working on it: http://www.ietf.org/html.charters/nat-charter.htm
Basically it allows a client behind a NAT to reserve a port on the NAT and forward all traffic from that port to the client. So different clients can open up different listening ports on the NAT, and it will forward them incoming connections. Since a NAT box has a good 65k ports to play with, you should easily be able to support several thousand clients on a NAT'd IP with virtually no loss in functionality - clients can make any outgoing connection they want, and can accept incoming connections after binding a port on the NAT.
I pray every day that this protocol will get finalized quickly and be implemented in all NAT products. Even better if it could be implemented in the client OSs at a low-level - so that when you do a bind() on a client, it automatically makes an RSIP request to your NAT to bind the port there as well. That way client applications can work transparently without having to add special code (like you do to support stuff like SOCKS) - although I expect there will be Winsock wrappers on Windows to support RSIP like there are SOCKS wrappers.
Maybe I'm falling for a troll here but...
I'm afraid that you are in danger of losing your job -- unless of course your job is to know how to manage networks but not necessarily to know how they work.
The author of the article knows exactly what he is talking about. The two modes he mentions would work as follows:
Brokering - Napster does this. It allows two independent peers to "find" each other and then establish a direct correction, much like DCC in IRC. This follows the definition of a "broker" very well.
Relaying - basically like proxying, except that it allows two "clients" to communicate with each other. Both clients connect to the same server, which establishes a "virtual" connection between them by storing and forwarding the data between them, sort of like a bridge. The reason why this would require huge amounts of bandwidth is that the server would have to be able to handle the traffic for both ends of all connections that it relayed in this way. Seems pretty obvious right?
The other technique that the author hints at is "connection splicing". This is a mechanism whereby an intermediate basically "joins" two TCP connections together. There are a number of difficulties in doing this -- mostly to do with the unpredictablity of TCP sequence numbers. It probably would not work in this scenario. You really have to be in the middle to rewrite all packets that go between the two parties - e.g. as a bridge. It's pretty impossible to switch the endpoint IP addresses of a TCP connection midstream.
Like I say, maybe you're just a troll, but I would say that the main lesson here is don't go shooting your mouth off unless you are pretty sure that you know what you're talking about.
It's generally recognized that NATs are a hack to get around the failing of the current IPv4 network. Even though I have written one of the first NATs before they became popular, it is widely agreed within the IETF that NATs present surmounatble problems. In adition to the inability to establish peer to peer TCP connections - the primary reason being that you can't determine both ends TCP ports until after the connection is established - there are also significant problems for network security mainly because you can't directly ties the end user's IP address to the security protocol. Also, IPsec won't work through NAT's particular well because the ESP protocol doesn't typically work through NATS. Also, I suspect that MTU discovery may not fully work through NATs if they haven't been correctly implemented - i.e. you also need to translate the ICMP messages related to the NAT - often these might not pass through.
This is one of the dominant reasons why IPv6 is needed. While there are many reasons that NAT is useful, the dominant one is the lack of IP addresses. Ipv6 certainly deals handsomely with that issue.
Another issue I have with NATs is that from an ISP point of view (we run one also) it is quite difficult to trace a rogue user that is on the inside of a NAT because usually a NAT will hide the identity of the customer, and you have to resort to other means to determine the identity of a user that may be launching an attack. This may be a good thing for some, but generally it makes life more difficult for the sysadmin.
There are other failings with NATs - for that reason they are generally frowned upon.
Time to rollout IPv6.
While I had a hard time understanding NAT, I'm beginning to learn that it is extremely versatile and a lot of times people, like the author, don't understand that it can be configurable in a lot of ways.
For our home connection, I set up a port for each of my roommates 4 computers and we use Napster through those.
What is even more interesting is that NAT will soon have unnoticed configuration itself. There has been work done to improve NAT translation so if a port is opened on an inside IP, a client can connect to the router and request that NAT redirect to that port.
I don't think IP masquerading is going to anything but get better over the next few years, and I trust it to be the best security with the most configuration in the future.
I don't believe the author of the article has realized that even with the Cisco 675, used for a large number of DSL connections, changes have been made to NAT such as one-time configuration of addresses.
What this new option allowed over previous versions of the bios was setting an inside NAT port and address and binding it to the routers IP. Before this, users would have to log in every time the routers IP had changed and continually change the NAT translation.
NAT is only going to get better folks. Don't worry about peer-to-peer sharing dying any time soon because of it.
Well, for each network of computers behind a firewall sharing an IP address, there can be one computer that has access to incoming requests. Linksys refers to this as the DMZ (Demilitarized Zone). This one connection can be the representative for the entire network.
I know my apartment is behind a Linksys router, and we have 4 connections, however we have one computer that is the dedicated incoming access server. This doesn't really help the other computers on the network, but it is a partial solution to the problem.
..to peer-to-peer connection requests should be intellegence in the firewalls or routers. Once they're aware enough of the application to recognize a "requested" inbound connection that doesn't exactly match an "originated" connection, the problem goes away. Many firewalls already do this with outbound FTP access to eliminate the need for PASV transfers.
If a suitable peer-to-peer protocol were well-documented (read RFC) and widely implemented, it wouldn't take long before the vendors started picking up support for it. Problem solved.
_________________________________
Now!
I've always considered it more of a router. It's not like Napster stores anything on its own system. Rather, they allow the appearance of PTP connections through a pool of users.
Actually, I could consider it a completely connected graph, where every user is a point on the graph, connected by lines to every other user. It's just when you refuse to 'share', it's a directed graph. And considering that I'm not trying to traverse the graph completely, just search the data at each point, it still doesn't seem like a server.
Just my 2 shekels.
Kierthos
Mr. Hu is not a ninja.
Is that what NT stands for?
I always thought it was naked turkies. Go figure.
"I would kill everyone in this room for a drop of sweet beer."
...distribution of BSD
are you saying that it should be "distribution of BS"?
--
It isn't like people will ever quit accepting connections, the home user won't let it, I know people who have only gotten the internet because of napster. Also, if you were an ISP, and you took away Napster and the like, you would lose half your customers. (it isn't likely that all individual users would cut off incoming transmissions, so the ISP would have to do it for it to actually happen)
On top of that, it just doesn't make sense. This sounds like the rumor that the internet will die soon that always goes around. It could happen, but it won't.
In addition, once people quit doing it, someone would revive it. The Gopher article from yesterday says it all, you can't really destroy any kind of internet technology that could be considered cool to even a small group of people. They will revive it, and it will grow.