(Yeah, we are getting off topic a little ... at least it's not about
Si's desk ...)
Chris Wedgwood
On Thu, Jul 19, 2001 at 09:01:17AM +1200, Don Stokes wrote:
Mostly it breaks in places where protocol layering is violated (e.g. putting a network address in the application layer), in which case it's going to break when you go to IPv6 (or any other protocol) anyway.
Well, for that there are even more evil hacks such as protocol helps most commonly for things like FTP and RTSP.
Well, the fact there exists duct tape to put over broken things doesn't alter the fact they're broken. And I have well-documented gripes about FTP and its PORT command, http://www.daedalus.co.nz/~don/ftp.html ...
It's because of things you get timeouts and other such funnies caused by this horrible often poorly written state-machine in the middle trying to second guess the state of the two ends. TCP in particular was designed with a reasonable degree of care to ensure that you can mathematically validate various principals. To do so, there is logic which allows one state-machine to resynchronize if the other other one gets hosed, and for both state-machines to stay synchronized under a wide range of conditions.
NAT completely stuffs this up. The most obvious example of this is TCP sessions die when they either time out or the NAT device looses state (e.g. nasty Nokia DSL modem crashes because it doesn't like packets with various '1323 extensions under load).
Well, we went around this question on the ADSL mailing list a month or four ago. Basically, if you have a long enough timeout on your NAT, it shouldn't be an issue, especially if you have TCP keepalives turned on. (Bear in mind that TCP sessions closing are also used to clean up NAT entries; timeouts are only necessary to clean up TCP NAT entries left over by abnormal terminations of connections. UDP is of course more problematic, but UDP based applications tend to be less inclined to keep state around for long periods.) Secondly, NAT mappings should be able to survive an interface transient, although if it negotiates a new IP address, those entries won't be of much use. And there's no reason why an interface transient should cause a new address to be assigned; a sensible RADIUS server should be able to re-assign an address if it's available. Router crashes are a pain. Some NAT implementations are smart enough to create new NAT entries from existing connections, although the packet that triggers them has to originate from the inside for this to work. But routers *shouldn't* crash...
By biggest objection with firewalls and NAT devices is that the majority of the commercial ones out there suck. Checkpoint Firewall-1 is IN MY OPINION a terrible product. It's quirky, slow, extremely resource hungry, terribly buggy, with abysmal support quality. However, as almost everything else 'brand-name' commercially available is even worse, its very popular despite being horrendously expensive.
After careful study (i.e. I still have the brickwork impressions on my forehead), I came to the conclusion that there exists a list of priorities for Firewall-1, of which the first ten entries are "Make Checkpoint more money". "Internet security" is well down the list, and customer satisfaction doesn't register at all. Has anyone succeeded in getting additional licenses out of Checkpoint in any semblance or reasonable time? Still, the fact that certain implementations of a thing are buggy or badly designed or sold by robbers doesn't make the thing inherently bad. In any case, it's not a question of whether NAT (and firewalls) is a nice solution or not. It's a fact that NAT *is* a solution (albeit one that comes with its own problems), and one that doesn't involve changing software on hundreds of millions of computers.
[1] Was it Vixie who said, "I want my old Internet back!" ???
The Internet is FULL! GO AWAY! (Joel Furr T-shirt from 1995) -- don --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog