begin  quoting Andrew Lentvorski as of Sun, Jan 29, 2006 at 05:25:13PM -0800:
> Stewart Stremler wrote:
> >NAT is a godsend and should rule the day; process level IPs should be
> >implemented as NAT'd 127.x.x.x IPs and mediated by the OS kernel to the
> >appropriate static IP.  We need to make sure we start implementing NAT
> >functionality in IPv6-capable firewalls.
> 
> Who are you and what have you done with Stewart?

Heh.

> NAT is the *worst* possible solution.  It gives the illusion of security 
> while breaking the end-to-end nature of the Internet which made all of 
> these nice applications feasible.

All the applications I care about work with NAT (well, network address
_and_ port translation).  Applications are still feasible.

NAT is useful for a couple of things: first, it lets me run as many
machines I want in any configuration I want with minimal interference
from my ISP.  I pay for two IP addresses... but I use a lot more.

Second, it imposes a default-deny policy on the services my systems run.
By default. This is a Good Thing.

The difference between using NAT and not using NAT consists of how
complicated my firewall rules are.  NAT just simplifies things a bit,
as well as meaning I don't have to pay for additional IP addresses.

"Ah!" you say, "that's what IPv6 is for!"

Yes... and no. There's no guarantee that I won't be charged on a per-IP
address if all the world moved to IPv6 tomorrow.  If I'm paying for each
IP address, then NAT is again the answer.

Additionally, I can't remember an IPv6 address.  I _like_ knowing the
IP addresses of my internal network.  I don't have to set up a DNS
server for my internal network, and I like that. 

Finally, I see no reason to expose my internal network structure to the
outside world...  when one of my machines decides to go to the outside
world, it's no business of anyone else which one of those machines it
is making that connection.

> On top of this, anything *behind* the NAT is free to infect anything 
> else behind the NAT.

Yup.

I'm not suggesting that NAT be the primary or sole defense of your
network -- it's just the first-stage filter.

> Don't get me started about the number of RFC 1918 space queries that 
> still manage to make it to the Root DNS servers.
 
Well, that's a software problem.  Presumably, NAT gateways should also
proxy DNS, and filter out what shouldn't leave the (local) network.

> Finally, the worst security problems are *still* caused by stupid people 
> opening email and programs with viruses.  Including Sony DRM ...

Yes, and that doesn't go away with anything we do. Stupid people violate
all security policies, no matter what you do. Granted, we should tackle
the bigger problems before we try for the smaller problems, but we don't
have the means to equip every computer with a stick (for smacking
stupid users).

> Although, what I think you are proposing is less like NAT and more like 
> host-based security.

Well, that too.  I'm thinking of NAT as a component of complete
virtualization as a means of implementing host-based security.

Rather than having to register a (bunch of) IPs, I can just spin up a
service in a virtual machine, and use NAT to redirect connections to
the appropriate port on the visible IP to the virtual machine's IP.
In case of a conflict, I can choose... or even silently proxy the
connection.

After all, the advantage of the Internet is that the applications on
each end _don't care_ how the data gets back and forth. 

-- 
_ |\_
 \|


-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to