ietf
[Top] [All Lists]

Re: NATs as firewalls

2007-03-01 11:00:37


--On Thursday, 01 March, 2007 08:07 -0800 Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org> wrote:

On a thread now unrelated to the topic of NATs,

At 9:42 AM +0100 3/1/07, Eliot Lear wrote:
With IPv4 the impetus for NAT was a combination of address 
exhaustion concerns and routing issues.

It is far deeper than that for many IT departments and network
users. NATs are seen as an easy-to-administer firewall that
prevents outside people from getting at hosts behind the NAT.
To many of us, that is a bug because it prevents session
initiation from the outside; to many users, it is a feature.

Nearly ever home *and SOHO* router today comes with NAT turned
on by default, and the setting to turn it off is difficult to
find. In our VPN testing, we have found that some of those
routers have bugs that prevent the NAT from being turned off.
When we report this to the vendors (because our tests do not
use NATs), we are often literally the first people to have
noticed this. That's how ingrained NATs are to the mentality
of users.

It is even worse than this, for two reasons, discussed below
(since it is now 2007, it is time for me to delivery my annual
whine on the subject).

State a different way: given the way that some popular
operating systems are configured out of the box to respond
insecurely to outsiders, it may be a good thing that NATs are
on by default. Of course, it would be better if the routers
were firewalls with a default "all incoming blocked" rule
instead of a NAT, but that is not how the world works, mostly
due to the two issues Eliot brings up above. But even if those
two issues were magically resolved today, it will take us
years or decades to convince users that they don't want the
NATs they have now, and that they instead want to become
firewall administrators.

Yes.

(1) Many of the most powerful consumer, end-user, SOHO, and
small enterprise router-firewalls don't permit the NATs to be
turned off at all, even when multiple public addresses are
available.  Instead, they provide a one-one NAT capability,
either because they are convinced it is safer or because they
are trying to support some sort of "backup network" or "DMZ"
capability and don't have adequate support for the routing
needed to do either with long-prefix public address ranges.

(2) NATs provide a huge advantage for customer support
organizations of ISPs supporting such lower-end (in terms of
financial returns, at least) connections.  With a standardized
NAT setup, the setups of all of their customers are pretty much
the same, including the address ranges used by default.  This
permits much easier (and cheaper) user support than trying to
debug LAN-specific routing tables, arrangements to support both
a LAN and the router providing the the interface between that
LAN and the WAN in a very small address range, and so on.

I continue to believe that, until and unless we come up with
models that can satisfy the underlying problems that NATs
address in the above two cases and implementations of those
models in mass-market hardware, NATs are here to stay, even if
we manage to move to IPv6 for other reasons.  And, conversely,
the perceived difficulties with NATs will be sufficiently
overcome by the above issues to prevent those difficulties from
being a major motivator for IPv6, at least for most of the
fraction of the ISP customer base who cannot qualify for PI
space.

      john


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf