Slashdot Mirror
End Of the Line for SpeakFreely: NATed to Death
Arun writes "John Walker (of AutoDesk and Fourmilab fame), primary author of SpeakFreely, has decided to EOL the program (a pioneering network telephony effort), come January 15th, 2004. He cites difficulty in maintaining a decade-old code base, lack of appropriate developer support and a fundamental change in the peer-to-peer nature of the Internet upon which SF is dependent as motivating factors behind his decision. While the last release of the program will continue to be available from SourceForge, the main web site, mailing list, and web forum will be shut down on the aforementioned date." He's got some good points too, like how once IPv6 is more common, most users probably won't go back to one address per machine. I know I enjoy the added security of a NATed firewall, and without a really good reason, I won't be quick to give it up.
Why did I discover this cool application in a discontinuation announcement?
I wish I had discovered it earlier.
Oh well, I can only hope that I can repent this mistake in my next life.
NAT is about address use, not security. In no way should NAT ever be confused with security, even if it appears to give you some security.
Every single security feature you like about NAT can also be had without NAT.
The common things people think they get with nat:
- Connections that must initiate from inside the network.
This is easily achieved with a normal firewall and routable addresses as well.
- My addresses aren't routable, so I'm more secure.
No, your addresses are perfectly routable, just the internet at large does not route them by agreement. Your ISP could easily configure it's routers to get traffic in to your network on those addresses.
- It hides the real addresses of my machines.
Not really... or more accurately, to an outside attacker, those addresses dont mean anyhting anyway. Whether they are known or not is not relevant. A firewall in front of a network of routable addresses could hide things equally well.
NAT by itslef does not reduce exposure. The best example of this would be those who configure nat in a hurry on linux 2.4 systems..... they set up an SNAT or masquerade rule in postrouting, and that's it.
That's nat, full, 100% working nat.
With absolutely no security.
The ISP could route to their internal network, no problem, making connections to whatever they want.
This is easily fixed by a few rules.. but then you are into firewalling, and not NAT at all.
Just as a point of observation wrt NAT for security, I would like to note that NAT is wonderful at making your system incapable of acting as a publicaly accessible network server, but does nothing for a large percentage of the viruses and worms that exist on the internet at this time.
In fact it can be a serious problem as a significant percentage of the people with NAT on their Broadband gateway are doing little or nothing to improve their desktop security. Why be worried when the gateway will block NAT traffic for me?
I am probably preaching to the choir, but as a simple example of the flaw, you probably still get, and read e-mail, even behind your NAT firewall. If someone sends you an infected file as an attachment, (that you happen to execute, automatically or deliberately) that happens to be an IRC-Bot that will turn your workstation into a rdos center, your NAT box is unlikely to do anything to protect your PC. In fact now that the bug is running on your system, it has the potential to check for other systems in your home network that are vulnerable to various exploits that you haven't patched for, because you are "safe behind my nat firewall".
Suddenly you have multiple boxen in your network that are all accessing the internet without your awareness, and downloading whatever the bug writers have decided to have them download. It's not even remotely improbable that your NAT secured network may become a spaming source without you knowing about it.
NAT as a security tool is the network equivalent of Security through Obscurity, and is just as flawed.
-Rusty
You never know...
Walker also lists an entire slew of other reasons, but if he used the NAT argument as his central reason to quit, I think he's being very short-sighted. Of course, "because I don't wanna" is always a perfectly valid reason in an open source world, too.
But if you radiate, you're a target. There's always some little a-hole who wants to take you down for no other reason than than ... Hey, look, it's Saturday! Never understimate the stupidity or maliciousness of a 14-year old skript kiddie.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
You can have a good and secure firewall even without NAT, in case you didn't know..
Ahh, but NAT is the simplest. I like the fact that I can get a hardware NATting firewall, plug it in, and know that the default configuration is secure. There aren't any holes anywhere, no cracker is gonna scan my network through it, nothing like that...
Sure you can get that with a regular firewall, but you have to configure it and monitor it and all sorts of other stuff that I, as a consumer, just don't want to do.
And FYI, I work in the TCP/IP security business. It's not that I don't know how to build a firewall. It's that I don't WANT to when I'm off work...
I am disrespectful to dirt! Can you see that I am serious?!
First off, let me say I have no idea what Speak Freely is. My comments are solely in response to some of the reasons he gives for discontinuing the program.
Had his reasoning behind discontinuing the project rested solely on his lack of time and an aging code base, I don't think I'd have an issue. Instead, he goes on to blame the NAT protocol and boxes that implement it, like the very popular cable/DSL "routers," and many of his issues seem to either misunderstand them or deliberately misstate what they can do.
He makes comments like, "Since the user no longer has an externally visible Internet Protocol (IP) address (fixed or variable), there is no way (in the general case--there may be "workarounds" for specific NAT boxes, but they're basically exploiting bugs which will probably eventually be fixed) for sites to open connections or address packets to his machine." He continues to state, "experience has shown that a large number of installed NAT boxes either cannot map an externally accessible port to an internal IP address and port, or those who install the boxes do not provide their customers adequate information to permit them to do this."
First of all, I have yet to see a NAT device that cannot statically map ports to a machine inside the local area connection. If there is one, I'd love to know about it so I can tell anyone to avoid it. Some are more rudimentary than others - like one I know about that has no UI to distinguish TCP and UDP inbound ports - but they all offer some way of mapping inbound ports.
His argument that they don't provide sufficient documentation to allow end-users to do so, and this may be the case. But if one is to discontinue development of a program based on the fact that someone else is providing poor documentation, there wouldn't be any development going on - documentation for most hardware/software products in the last 3 years or more have been horrid in my experience.
His argument that the internet is moving towards a client-server model rather than a peer to peer model is undeniable. It's been moving that way since they allowed home computers on the internet, and shouldn't be a surprise to anyone. Still, this doesn't mean the "clients" can't continue to utilize products that utilize a peer to peer architecture. He dismisses peer to peer file sharing products while overlooking the fact that they're the most successful peer to peer architecture network to exist in the history of the internet, and disproves his argument that NAT spells the end of peer to peer.
In the end, it seems he just didn't want to continue developing his program - and instead of being honest, he thought he'd use this opportunity to climb on his soapbox and make some waves by blaming NAT for the ills of the internet and the death of his program.
In a world where virtually every NAT appliance will allow portmapping to an inside address, the only reason why consumers are losing control of the Internet is because-- thanks to their sluggish complacency-- they're making that choice as default by inaction. It takes the brains of a snail and about 5 minutes looking at documentation or ubiquitous and thoughtfully provided online help from the appliance itself to figure out portmapping. As long as most people voluntarily emulate mental midgets, projects like SF are doomed.
That's funny. If NAT provides nothing at all in terms of security, why is it that when someone tries to connect to my RPC port they instead hit the router's port (which is closed, of course).
It is not a matter of (just) static port mapping, it is more a fundamental problem in the way DNS works with Internet addressing -- or more specifically, the way way applications interact with Internet addressing. (This will no doubt invite flames from those outraged at the idea that there might be a fundamental problem/mistake in the Internet.)
More specifically, what happens when you have multiple machines behind the NAT device? How do you map the ports statically to multiple machines *and* also communicate this information to devices on the outside of the NAT device? (That is, port 80 on the NAT device maps to server1, port 81 on the NAT device maps to server2, etc.)
The key issue is that applications are using network level addressing (IP addresses) rather than application level addresses (URLs) to establish the network connection -- we have network specific information far too embedded in the applications, which is why the transition from IPv4 to IPv6 is such a nuisance. At the moment, the DNS SRV record could help with some of these matters by specifying a port number to use for a specific service and host/domain.
A better design for applications would be for them to be completely unaware of 'IP addresses' and function purely on URLs or hostnames + service name, and link to libraries or network drivers on the machine that handle the network aspects. Really -- excepting network mangement tools, what application bothers about the MAC addresses of machines or PPP negotiation details? IP addresses should not matter to the applications, either -- at that point, much of the arguments against NAT go away.
Honestly, the fact that NAT causes applications to break is more a reflection on mistakes in the architecture/application. IP packets themselves don't fall over and die just because they transition from a PPP link to wireless to ethernet to SONET to etc. The differing layers are independent of one another -- the applications have not yet been weaned off directly diddling with the IP layer.
The vulnerability lies in the "one page, one machine" paradigm. If the net operated more like (get ready for the flames) freenet then nobody (not even the RIAA) could be DDOSd into oblivion. A bittorrent sort of structure would ensure popular documents were always widely available, but the downside (of course) is that less popular content might end up lost. Of course, one can also make the argument nothing would really get lost because some archivists would specialize in retaining this info, just like projects like the wayback machine do with physical sites.
It astonishes me how people believe that they derive security from NAT. It's like saying blind folks are fortunate because they don't have to see ugly things.
It is trivial to achieve the same level of security in a firewall as you get with NAT. IPv6 will need firewalls just like IPv4 does. The difference, however, is that if you *want* to allow a certain type of communication to more than one hosts behind the firewall, you don't have to do a bunch of tortured port mapping nonsense (which often isn't good enough).
NAT breaks the Internet. If you like NAT, you should be using AOL instead.
So I don't see NAT dominating the Internet. I assume most people will just use a PC with two ethernet cards rather than dedicated routers and use that PC for stuff that requires incoming connections.
I suspect the author is just bitter that his stuff is not popular anymore. Even if it's possible to talk peer-to-peer, instant messangers with hosted servers are more convinient to use.
Well, its a free world, but he should have asked if anyone wants to take over the project and then forward the links to that person.