Eric,
I agree with most of your post but there is something that you have not
grasped IMHO.
It is true that "dissimulating" the private (RFC1918?) address does not
achieve much in terms of security: in order to access:
http://arneill-py.sacramento.ca.us/ipv6mh/ you do not need to know nor
care that the IP address of the web server is 192.168.1.4. Knowing it
might provide limited help way farther down the hacking process though
and is likely to be leaked in things such as SMTP headers anyway.
However, if you are correct in saying that NAT != firewall, you are
mostly _not_ correct in saying that a NATs are not firewalls, as most
NAT boxes indeed are NAT+PAT boxes and {NAT != firewall} applies to
non-PAT things such as one-to-one static NAT (not overloaded) or subnet
natting.
Refrigerator = Frigidaire
Copy machine = Xerox
NAT box = Linksys
Eric Tomson wrote:
2.circuit level gateways (work mainly at session layer, by
identifying flows of data and established connections),
A more advanced device, able to identify "conversations",
"sessions", is a bit more advanced firewall of type 2.
By your own definition a NAT+PAT box is a type 2 firewall or circuit
level gateway. A pure NAT device (rare) does not care about flows but a
NAT+PAT box (very common) does and maintains hard state about them as
show below:
cisco3640#sh ip nat tr
Pro Inside global Inside local Outside local Outside
global
udp 209.233.126.65:1060 192.168.1.4:1060 206.13.31.12:53
206.13.31.12:53
tcp 209.233.126.65:1263 192.168.1.7:1263 198.133.219.25:80
198.133.219.25:80
tcp 209.233.126.65:25 192.168.1.4:25 --- ---
tcp 209.233.126.65:80 192.168.1.4:80 --- ---
Linksys/Netgear/misc home/soho NAT boxes have similar mechanisms. The
first two are originated-from-inside dynamic flows, the last two are
statically punched holes. Note that TCP flows are torn down as soon as
the TCP connection is terminated where UDP flows are torn down with a
timeout; on a Cisco 'show ip nat trans verbose' will show the timeouts.
This hard state is why NAT+PAT boxes have often been compared to
firewalls because _one_ of the features of firewalls is to build this
hard state that allows only return traffic related to traffic originated
from the inside (unless a hole is punched). The security brought by the
NAT+PAT process comes from this hard state; no entry in the translation
table, no traffic. A firewall (or a reflective access-list for Cisco
geeks) builds hard state the same way except that of course it does not
change the address.
NATs [...] won't control the traffic
This is incorrect for most NAT boxes. Although it is true that the main
two purposes of NAT are saving IPs (one-to-many NAT) and ease
renumbering, it is equally true that if there is no open flow originated
from the inside (or hole punched administratively), a NAT+PAT _DOES_ by
default block traffic originated from the outside, which is a
significant part of why people buy firewalls in the first place: Allow
users to surf but don't open anything except a few ports to a few IPs in
the other direction.
In other words, a NAT+PAT device blocks by default all traffic except
statically punched holes and transient return traffic related to a flow
opened from the inside (specific to a pair of IP addresses and a pair of
ports).
This circuit-level gateway feature is not enough security and must be
complemented with access-lists and stateful inspection but it's one of
the third major building blocks of a firewall. But that's for network
geeks; the sad truth is that when the network admin is lame (grandma or
Joe's Pizza) a windoze 9x PC is safer behind a Linksys than connected
directly to the cable modem.
As of myself I would not call a firewall any device that does not have
stateful packet inspection (free hint to IPv6 vendors ;-)
But by your own definition a NAT+PAT box is a firewall of type 2. Add to
this that when combined with RFC1918 they bring very easy renumbering as
only the outside address has to be changed and you'll understand why
there are so many of them around.
For the record, and since this thread started with IPv6, I am totally
against IPv6 NAT. With IPv4, all we have left at this time are lemons so
there's nothing wrong in making lemonade with them even if we prefer
beer. Although it is part of the job, IPv4 NAT is a royal pain in the
butt that I would gladly live without. But for IPv6 it is not too late.
If the end-to-end principle is a dogma it's not only because IETFers
like dogmas but mostly because NAT plain stinks.
Michel.