North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)

  • From: James Hess
  • Date: Tue Jun 05 09:26:25 2007
  • Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z8QGPm61qmXLE34i+SrspkZymV7r0PNt8fxSG7dujEecXkHRq2iEzYMFNLzxtDJJKsMBH7+IiqKR9M/FR4YzqDX1IifVAc4MLpwSGzSy3LDzR2A616BSmYeihi7oqnPGxW7ekJ7ODFG+PgthDRGIJQ4LSnUCg5fE5ZrAwYU8xkU=
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f//1kGQqY0imWUfO/vV/2hXSlljzafId2VFyBkWJWFoQ+XW8PgH7mRJnuA7zoX6Jx+dC/shzgG3T/Jticwb+/P4ryrXUW0JUcPY42C3gwGzxlYT4rFJriRgaRSQ6ECIvO47kfXoLuGSeRcY7XwEhZAV9jxCP9Gqc3tUzs4REHhY=

On 6/4/07, David Schwartz <[email protected]> wrote:

> I posit that a screen door does not provide any security. A lock and
> deadbolt provide some security.  NAT/PAT is a screen door.
This is a fine piece of rhetoric, but it's manifestly false and seriously
misleading.

Hi, David

I think the essence of what prior post is suggesting is that NAT
itself is not necessarily a security feature, but there is a popular
method of using NAT to get a feature that comes with it and has
security benefits, that really goes by the name SPI, and which can be
decoupled from what it means to have a "NAT", and that feature can and
should perhaps be implemented alone, on its own right, instead of NAT.

In other words "In IPv4 we got a security gain that happened to be
packaged with NAT," but in ipv6 we have another way of getting almost
the very same gains, except without the disadvantages of NAT.


It should be cheaper to implement SPI than full blown NAT
capabilities.  However,  that greatly depends on what consumers (end
users) will demand, and a handful of hardware manufacturers will
provide, if/when some inexpensive gateway type hardware becomes
available for end users that has IPv6 support.


If IPv6 allows them  to "not buy the NAT" box, then the typical end
user won't necessarily instead buy a SPI box, they may buy no box at
all, other than say, a $10 switch or hub, or it might be on the same
box as their access equipment, it will be less expensive.  Therefore
they might have fewer protections in the real world, unless upstream
provider's routing equipment provides them with SPI: that's not very
likely.

NAT-less SPI may strangely have a higher price tag than NAT+SPI.
A hardware vendor selling an IPv4 SPI box might typically have
labelled that product as a security appliance, making it cost more,
because "SPI/security/firewall" was considered an  "enterprise
feature", NAT was considered a commodity functionality.   For SPI
without translation to replace NAT, it needs to become a commodity
functionality that every end user IPv6 gateway supports and has
enabled by default, setup with no holes (i.e. ports open) by default,
out of the box.

It is understandable that end users rely on the cheapest boxes they
can get, that best suited their immediate needs -- it was convenient
for the equipment to have secure defaults; I would hope that hardware
makers would continue to provide security by default with IPv6, since
all too many OSes have insecure defaults.


Should users want it badly enough, nothing forces hardware makers to
stick with the best  known solutions -- HW makers may specify NAT or
other hacks all on their own... if the transport protocol standards
don't specify it.  I think some hardware maker is probably going to
just invent and patent  IPv6 NAT, since noone thought to specify it,
and implement in their products just to list  "[brand name] IP Version
6 private addressing" in their marketing materials, for said premium
device(s).


Today's IPv4 NAT box may well be the next decade's  SOCKS6 proxy box, even
if there is no technical need whatsoever for it; there is a comfort
factor here, since
some users of IPv4 have become accustomed to certain hacks, and they will not be
forgotten easily.

IPv6 users may not like that in case an internal machine is
compromised to some extent, , without NAT, the actual ip addresses of
other machines behind the gateway may have become known in advance of
the initial compromise, but if the addresses were private, extra
effort would normally be required to discover what exactly the private
addresses were, only possible after the compromise, while the timer is
ticking for the incursion to be discovered.


I can give you the root password to a Linux machine running telnetd and
sshd. If it's behind NAT/PAT, you will not get into it. Period.


That might be so, but the assurance may not be 100%. In practice, your NAT box,
even if properly configured may well  have a number of different types
of holes, and
it may be possible for an outsider to open a  session you didn't anticipate.

I would suggest that implementations of NAT and SPI suffer the same
type of deficiencies in that respect.



Are there things most stateful inspection firewalls can do that NAT/PAT does
not do? Definitely. Are those things valuable and in some cases vital?
Definitely. So why lie and distory what NAT/PAT actually does do? A large
class of security vulnerabilities require the attacker to reach out to the
machine first, and NAT/PAT stops those attacks completely.


If there's something remaining a NAT is good for, that doesn't have a
much better
replacement technology, or hasn't been mentioned yet anywhere, then it
should be
spelled out, to the ipv6 wg, so it can be ascertained... whether a NAT
is still necessary
to offer that advantage, or whether NAT is merely the box that
capability happened to come in for IPv4.

Is a car alarm useless because some professtional theives can disable it? Is
a lock useless because some thieves can pick it? Many exploits only go after
low-hanging fruit, and NAT/PAT stops them.


No, but a lock should eventually be replaced if it doesn't entirely
lock and has extra features that cause problems and don't really
contribute to the task of locking, but make the lock more complicated,
and possibly easier to defeat, when a cheaper, better lock can be made
in its place.

No need to make old-style easy-pick locks that take skeleton keys
anymore, no need to even specify them.


Ideally individual NICs would be smart enough for SPI to be done on
host NICs. Spreading the load, and sharing a "connections table" with
the host OS rather than imposing load down upon one NAT box (to manage
the connections  tables for many interfaces), or requiring "timing
out" to know when a connection is still possibly active or not.


I.E.  It's possibly a little bit better to have a deadbolt on each of
your doors, instead of having only one big fence around your
neighborhood, with just one lock on that gate, no locks on your
individual doors, and all neighbors sharing a single mailing address.

There is a chance that someone you don't know can still get mail to you.
Also, one of your neighbors could turn out to be the bad guy (one of
your other systems could become infected by some trojan, perhaps it is
a laptop and was temporarily plugged into a different network, and
compromised at that time)

There is a security gain involved if you have NAT, over having nothing at all,
but there are other security measures that can possibly be taken that obsolete
some major NAT security gains...

--
-J