Re: Free NAT for NT?

[Mikael Olsson <mikael.olsson () enternet se>]

Carl Brewer wrote:
> <rant>
> It's a shame that M$ are providing NAT, which even they know
> is a bad technology (it was a M$ employee that wrote the IETF
> case against NAT), and not IPv6.  Please don't lose focus!  NAT
> is a short-term ugly broken hack, push your vendor(s) for IPv6
> support!
>
> http://www.ietf.org/internet-drafts/draft-iab-nat-implications-04.txt
> http://www.ietf.org/internet-drafts-ietf-iab-case-for-ipv6-04.txt
>
> If you're using, or worse, planning to use, NAT and you haven't
> read the above two documents, read them :)
> </rant>


I think I have a bone or two to pick with you here, Carl...
Well actually I'd like to pick them with T. Hain of Microsoft,
but since he's not listening and you are, and you seem
to agree with him.... >:]

<rant size=666 target=_ms color=brightred>

First a couple of first-glance observations

- Isn't it ironic that a Microsoft employee wrote that paper?
  Especially taking into consideration all the "protocols"
  they have designed that require nothing less than
  complete port 0-65535 access between the machines involved 
  in a conversation? NetMeeting is probably the prime example.
  Also note that you cannot logon to a domain if you 
  are NATed.

- NAT has the excellent property of hiding a network's
  structure to the outside world. Most organisations tend
  to like that.

- The argument that, for instance, two users behind two
  NATs cannot connect to each other is moot in my book.
  >>> The same is true of two users behind two firewalls. <<<
  A firewall using stateful inspection (without NAT) that
  is able to figure out that a new connection should be allowed,
  could just as easily do this with translated connections.

- I like firewalls. Especially since some (a-hem) OS vendors
  install magic in their IP stacks and operating systems that
  open a LOT of ports with no ability to turn them off.
  (Someone ever tried to get rid of those ports in the 1024--1030
   span that are always listening on machines talk CIFS?)
  Not to mention buggy implementations that we want to protect.
  Can we agree that we want firewalls? Ok, fine. :-)


Let's adress the claims in the section "Disadvantages of NATs":


> - NATs break the flexible End-to-End model of the Internet. 

Duh. So do firewalls. No further comment.


> - NATs create a single point where fates are shared, in the device 
>   maintaining connection state and dynamic mapping information. 
>   (While single routers have the same property, the lack of state in 
>   a router makes creating redundancy trivial.)  

FUD.. "Fates are shared"... Pah....
Again, the problem is identical in firewalls even without NAT.
It _is_ easier to do redundancy in routers, but it is certainly
not impossible to do in NATs aswell as non-NAT firewalls.
Exchanging state information is not completely impossible...
(I think it's been done? Might be dreaming tho)


> - NATs inhibit implementation of security at the IP level.  

If this means "NAT inhibits me from writing programs that 
authenticate users based on their sender IP address", I'd humbly 
advise the author to brush up on security history. 
Source routing, RIP spoofing, ARP spoofing, BGP injection...


> - NATs enable casual use of private addresses. These uncoordinated 
>   addresses are subject to collisions when VPNs traverse multiple 
>   NATs along a path. 

True. But not if you NAT the private adresses before passing
them to the VPN! >:]
Seriously, this should not be a problem within an organisation?
Again, you probably wouldn't want to reveal your network structure
to someone outside your organisation.


> - NATs facilitate concatenating existing name spaces with the DNS. 

More FUD? I have no idea what he is talking about here...
Maybe he means it'll break their excellent? idea of integrating
NT Domains with the public DNS infrastructure?
(Hint: hiding information is good)


> - Port versions (NAPT, HNAPT, & RSIP) increase operational 
>   complexity when publicly published services reside on the private 
>   side. This includes the restriction that only one private side 
>   well-known-port can be accessed through a given public side name.

Errrrrr... If you want to make two web servers accessible through
port 80, why not just publish them on two different public IP addresses?


> - NATs invalidate the authentication mechanism of SNMPv3 

I haven't looked at SNMPv3 yet, but if it involves authentication
based on on the sender IP, maybe it should be redesigned before
implemented in large scale?


> - Products may embed a NAT function without identifying it as such.   

"Cars may be delivered with a spare tire without identifying
it as such, hence, spare tires should be banned".
Is this what he is saying?



This was just the opening list of points... For those that
haven't had it up to their neck yet, I'll address some
of the points found inside the body of the text...


> NATs place constraints on the deployment of applications that carry 
> IP addresses (or address derivatives) in the data stream

True. Why do applications do that? Isn't it just unnecessary
bandwidth loss? Why not look at the packet's sender address instead?


> Applications or protocols that assume end-to-end integrity of the 
> address will fail when traversing a NAT. (TCP was specifically 
> designed to take advantage of, and reuse the IP address in 
> combination with its ports for use as a transport address.)

Is he saying that TCP doesn't work through NAT?
It is true that you cannot TCP out of the blue to a host
"protected" by a NAT, but, again, this is also true of firewalls.
This COULD be the case of many-private-to-few-public NAT,
which, to my mind, is an abomination. 
Asuume hosts "P1" and "P2" are behind such a NAT, and there's
a web server "WWW" on the outside.
P1 opens the connection P1:1024->WWW:80, which will appear
as NAT1:1024->WWW:80, and finishes it.
P2 opens the connection P2:1024->WWW:80, which will get
the now free address NAT1; NAT1:1024->WWW:80, which may
not work for a couple of minutes.
I prefer many-private-to-one-public dynamic NAT, where this
simply would not be a problem.


> As noted earlier, NATs break the basic tenet of the Internet 
> that the endpoints are in control of the communication

Who ever said that?
I actually thought the most basic concept of the Internet
was free sharing of information. (*wink* *wink* Proprietary?)


> The concept of a well-known-port is undermined 
> because only one private side system can be mapped through the 
> single public-side port number at a time. 

Yes folks, this is reiteration.


> This can affect home networks, when applications like 
> multi-player Internet games can only be played on one system 
> at a time.

Note that Microsoft DirectPlay or XWhatever (their internet
gaming API, I've forgotten its name) works notoriously unwell 
through NAT (i e not at all), while many other network games 
work just fine.


> It will also affect small when only one system at a time can 
> be operated on the standard port to provide web services.

He keeps getting back to that point.
HEY GUY! YO!! GET ANOTHER PUBLIC IP!!! I THINK YOU CAN AFFORD IT!
(Sorry, I'm getting worked up)


> The issue is that the public private usage requires administrative 
> mapping for each target prior to connection. 

Yeah, ah, well, I s'pose I could just tell my firewall to let
everything in to all my addressess, ports 0-65535 and 
I won't have to worry about how many web servers we 
deploy... Duh.


Actually, most of the rest of this document goes on to whine
about many-to-few NAT, which, as I said, is generally a Bad Idea(tm)
for many reasons.

Since I'm now coming down from my adrenaline high, I just 
don't feel like keeping this rant up...
Anyone care to continue? :-)

</rant>

Note that I am in NO WAY trying to downplay the benifits of IPv6. 
Saying that "we don't need IPv6 now 'cause we got NAT"
doesn't quite compute.

These two concepts are, however, not mutually exclusive.
NAT works just as fine under IPv6.
The purpose would of course not be to "virtually"
increase the address span, but for security matters.

*phew!*

/Mikael

-- 
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46-(0)660-105 50           Fax: +46-(0)660-122 50
Mobile: +46-(0)70-248 00 33
WWW: http://www.enternet.se        E-mail: mikael.olsson () enternet se