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."

Comments

Realm-Specific IP (RSIP) is the answer

[crt]

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.

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.html

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.

NATs are a good reason to rollout IPv6

[PTrumpet]

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.

Good article but not much to worry about

[Sheepdot]

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.