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.
You can have a good and secure firewall even without NAT, in case you didn't know..
The IETF midcom group has been working on solutions for passing media streams through NATs and other middleboxes for a few years now. One protocol, STUN, is already a standards-track RFC, and the group has other tools in progress. These tools work with the IETF multimedia suite (SDP, SIP, RTP, etc).
*ding ding ding* give the man a cookie!
i'll dumb it down in case you've never heard of h.323 or anything of that description.
lets say there's this protocol for a program. it assumes that all content will be delivered from a static port. lets call this port '80' for kicks, and to really make it easy to understand. so, if i have a system behind a NAT that wants to serve content, i have to do the following:
on the NAT-box: all connections to port 80, forward to 10.0.0.2:80. fairly straightforward.
however, what happens when i want to have two machines inside the network both serving content?
well, i could have the NAT box forward all connections to port 80 to 10.0.0.2:80 and port 81 to 10.0.0.3:81. however, this mythical protocol that uses port 80 has a lot of clients implementing it that are stupid and always assume port 80 is the one to connect to. all of a sudden, binding a forward to port 81 isn't an option.
many industry-standard protocols act like the mythical protocol described above. they listen on defined ports for incoming data ('push' would be the buzzword). this totally pooches the NAT user with many people behind the NAT.
now, we see the problem. NAT is good, but it introduces a lot of limitations! these can be defeated by climbing higher up the OSI model and implementing proxy/gateway setups on the NAT box but that doesn't help when your NAT box is a dumb piece of hardware that can only be told to forward packets at the IP layer..
Here in the netherlands at least, both the major broadband providers (UPC adn KPN)give all customers a generically routable IP.
...
Does anyone have different experience elsewhere? The States, for instance? I'd like to hear.
Not only do most (all?) of the US broadband providers give you a globally routable IP, many of them actually get angry with you if you try to use NAT, because they want to have a one IP to one machine mapping for charging your account. Comcast in particular even has language in their AUP that says they may take legal action against you if you try to use NAT to install more machines (which is totally stupid, but there it is).
I've got a lot of respect for Walker in other areas, but this NAT rant is just barking up the wrong tree. NAT boxes are installed by users so that they can get more functionality out of the limited IPs available to them, not by ISPs to limit the users. I know Cox cable will help you install a NAT network, but they by no means require it or lock it down. At any time you could simply plug your machine straight into the internet and be just like everyone else. Or get a better NAT box!
On the other hand, saying that the internet is transitioning to a client/server architecture at the hands of corporate overlords isn't a big stretch at all (limited upstream, blocking HTTP ports, etc) but it has nothing to do with NAT.
Anyway, as others have said, if he is just tired of writing the program for a perceivably uninterested audience, he should just stop and turn it over to an SF project, like he's done. No need for this NAT rant...
Cryptic Allusion - New Mac and Dreamcast Games!
I'm not faulting NAT whatsoever, NAT is good, NAT is great..
but NAT is not security.
Perhaps my point is too subtle... let me try to put it another way.
All the security features you think you get by using NAT are actually not related to NAT at all.. they just happen to be configured along side it, and nobody ever really thinks about it. All of them are available, and work equally well, without NAT in the picture. NAT works equally well without any security features.
My point is not that "NAT devices are insecure" or that NAT is evil.. but that implying that NAT == sequrity in any way, shape, or fashion, is wrong.
send the subsequent data directly between the initial hosts
This is crux, isn't it? If A and B are neither NAt'd, there is no problem.
If exactly one of A and B are NAT'd, the NAT'd party connects to a port on the non-NAT'd party, and everything i s good.
If A and B are BOTH NAT'd, then they both probably have non-routable addresses. A has no knowledge of how to get to B and vice versa. The only thing about them that we (should) know is the IP address of the NAT box (assuming there is only one between them and the Internet). Therefore, the NAT boxes would have to be aware of and participate in the protocol.
NAT service developers are not going to bother with a protocol that requires special handling until it reaches critical mass (like RealAudio did some years ago). What this guy is saying is that he can't reach sustainable mass because of NAT boxes. It's catch 22.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
i just had a neat idea what if you combined the function of the speak freely relay server, to get around the NAT issue, with bit torrent, to get around the bandwidth issue.
Don't think that'd work. Bittorrent is meant to distribute files. If you're trying to stream audio, the packets need to arrive in sequential order. With BT, the machines you're connected to send pieces of the file (whatever they have), not necessarily in any particular order that makes sense for live audio.
You can accomplish anything you set your mind to. The impossible just takes a little longer.
And it works with NAT (it's more or less like IRC with voice-capability)
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
been done, it's called Skype
"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."
:)
Of course the ISP gets traffic in to your network even with NAT but that's how you get to surf the web.
"That's nat, full, 100% working nat.
With absolutely no security."
Seriously tho, while your ISP can easily subvert data and existing connections (and so can Verisign etc), it is nontrivial for your ISP to make new inbound connections into your network through a NAT device.
If you know how typical NATs work, it isn't that easy. (BTW Cisco calls them PATs because Cisco used to have inferior NAT solutions that didn't support IP sharing or overloading as they called it).
In the simplest case that supports multiple NAT'ed hosts, a NAT device builds a table based on outbound packets: src address, src port, dest address, dest port -> new src address, new src port, dest address, dest port.
You need a new source port because two source hosts could use the same source port.
Reply packets that match are then translated back.
Packets that don't match can't go through the device because the device just doesn't know where they should go.
Unless the device is terribly buggy you should be reasonably safe from inbound connections.
In fact with NAT, in order to allow inbound connections you need to add more code.
So with NAT having inbound connections is harder, and that is a good thing.
Coz there are some tricks you can play with IP fragments, where you get a fragment to overlap the original header on a vulnerable operating system. But if you have a reasonably recent O/S this shouldn't work anymore even on Windows.
Simple example of how it works, an inbound packet fragment goes through a firewall with an legit destination address and port and is stored in a packet buffer on the destination host. Subsequent fragments are sent and allowed through by the firewall and they overwrite/overlap the original destination port on the packet buffer, so the destination host actually ends up with a packet that connects to a service that should have been blocked by the firewall.
If you don't allow inbound connections and only allow outbound, such subversion is a lot harder, someone needs to be able to see your outbound packets as they head towards to the real destination, in order to construct suitable "inbound" packets and fragments.
"Hee hee, my ISP doesn't realise I'm connecting more than one PC" BONK. Yes they do.
And with that, your credibility rating drops to zero. Thanks for playing; have a nice day.
Apparently you missed the research that went into this. There are multiple ways. There are some basic packet sniffing mechanisms that can tell how many systems are initiating the connections as well as other methods.
-- The world is watching America, and America is watching TV.
Counting client hosts behind NAT is quite possible, so I think it's your credibility that has dropped.
While the user can contact and freely exchange packets with sites not behind NAT boxes, he cannot be reached by connections which originate at other sites. In economic terms, the NATted user has become a consumer of services provided by a higher-ranking class of sites, producers or publishers, not subject to NAT.
Even cheap consumer firewalls allow you to accept incoming connections and run services. Furthermore, despite a lot of noise, most broadband providers do not seem to block incoming traffic; too many games and other popular software rely on it.
The only thing that NATs change is that services should be more flexible in the ports they will work with: when you have multiple machines behind a NAT box, you end up having to assign non-standard ports to services if they are being offered by multiple firewalled machines.
I agree that the trend towards relegating end users to a "client" status is disturbing, but NAT is not primarily responsible for that. Inventing bogus technical arguments will not help us reverse that trend.
But you forgot the current result is that it's not routable.
...hard to do isn't it?
g ro und/Hacking/Methods/Technical/Source_Routing/defau lt.htm
ok...someone try to reach my 10.10.10.3 machine
http://www.iss.net/security_center/advice/Under
That method will not work if you have a quality firewall. But the reason for that not working has absolutely nothing to do with the fact that you are NATing.