Security gain from NAT

Donald Stahl wrote:

Ever try to set up a VPN between two offices using the same
address space?

Sure, very easily, by using NAT between the subnets.

NAT is still evil though, the problems it causes operationally
are just plain not worth it.

Can you clarify this claim? What about managing NAT is allegedly
difficult. Are you unable to easily map public addresses with private
addresses on your own networks?

Stateful inspection provides security benefits.

Neither SI nor NAT provides any security. It is the rules commonly
implemented on top of them that can provide security. Please be
consistent in the use of these terms to avoid confusing the issue.

Jeff McAdams wrote:

But it is correct. Just mangling the addresses in the headers
doesn't actually stop anything from getting through, it just
means it gets through mangled. The security comes from SI and
dropping packets that don't have an active session established
from inside, or related.

Crux of the thread for sure. In an academic context NAT only swaps
header addresses, however, in the world of network operators and
end-users all NAT devices do SI and filtering. It is the filtering,
blocking connections initiated from public addresses, that provides
"NAT security". That is still "NAT security" if only because it is
characteristic of virtually all NAT devices, and not the default or
even a common configuration of non-NAT network devices and
applications.

Perhaps it is difficult to understand this vernacular "NAT" after
studying Comer, Stevens et al, but when you've run the equivalent of
'sh conn' regularly for several years the narrow, some would say ivory
tower, definition of NAT tends to morph into one based on actual
implementations.

Since this mailing list is by and for network operators as opposed to
academics perhaps we could ask the later (NANAGs?) to use footnotes(1)
to clarify their meaning?

Sure, very easily, by using NAT between the subnets.

Have at it. Nothing like trying to reach 10.10.10.10 nad having to put in a dns entry pointing to 172.29.10.10, NAT'ing the address on your side to their side and from their side back to your side, and adding the rules. That's definitely simpler than allow a -> b for service c.

Can you clarify this claim? What about managing NAT is allegedly
difficult. Are you unable to easily map public addresses with private
addresses on your own networks?

Easily map them? Sure- I can do my external tcpdump, see some funny traffic, then match that up with the dynamic nat's. That's a lot easier than just going "oh, hey, it's this user" without any further steps.

I, for one, give up. No matter what you say I will never implement NAT, and you may or may not implement it if people make boxes that support it. Clearly neither of us will change our minds so why bother. I'm sure we've both gotten supportive emails in private and both know we are "right." In the end it isn't going to change a thing.

-Don

I, for one, give up. No matter what you say I will never implement NAT, and you may or may not implement it if people make boxes that support it. Clearly

...

This was supposed to be a private reply and was not meant to go to the list. My apologies.

I will also refrain from further responses- something I definitely should have done 20 messages ago... -Don

Sure, very easily, by using NAT between the subnets.

Have at it. Nothing like trying to reach 10.10.10.10 nad having
to put in a dns entry pointing to 172.29.10.10

End-users prefer hostnames to IPs. DNS hostnames are valid on both
sides due to either local zone files or a DNS protocol-NAT. It's a
no-brainer to implement and a lot easier than using public address
space given the relatively complex firewalling and filtering that
requires.

NAT'ing the address on your side to their side and from their
side back to your side, and adding the rules. That's definitely
simpler than allow a -> b for service c.

Not simpler than running something like "fixup protocol dns" on a
VPN termination.

I, for one, give up. No matter what you say I will never
implement NAT, and you may or may not implement it if people
make boxes that support it.

Most of the rest of us will continue to listen to both sides and
continue to prefer NAT, in no small part because of the absurd
examples and inconsistent terminology NATophobes seem to feel is
necessary to make their case.

So now the cruft extends and embraces, and you have to play DNS view games
based on whether it's on company A's legacy net, company B's legacy net,
or the DMZ in between them, and start poking around in the middle of DNS
packets to tweak the replies (which sort of guarantees you can't deploy DNSSEC).

And if the company aquires *another* one with rfc1918 on their legacy net,
then you get to play "as seen from A, B, or C, or this DMZ, or that DMZ"..

I think somebody on this list mentioned that due to corporate acquisitions,
there were legitimate paths between machines that traversed 5 or 6 NATs.

But yeah, "Sure, very easily". Whatever you say...

So now the cruft extends and embraces, and you have to play DNS
view games based on whether it's on company A's legacy net,
company B's legacy net, or the DMZ in between them, and start
poking around in the middle of DNS packets to tweak the replies
(which sort of guarantees you can't deploy DNSSEC).

Are you proposing that every company use publicly routable address
space? How about the ones that don't qualify for a /19 and so are
dependent on addresses owned by their upstream?

To change ISPs for example, would it be simpler to change the IP
address of every node in the company or to run NAT on the gateways?

How about multi-homing? Can you even do it without NAT on a network
too small assign an AS?

In the mid-90s I was CSO at a company whose internal networks were
publicly routable thanks to a /16 they owned (though they really only
needed a few /24s). In my experience, for every example of how
complex NAT is there are at least 10 counter-examples of how an
equivalent non-NATed network is more complex, less flexible, less
reliable, and less secure.

You clearly missed the start of this conversation, and my summaries in the last couple of days, about which I am not surprised.

We were discussing IPv6, the lack of NAT was brought up as being viewed as a blocker for security reasons, and solutions were presented so that it no longer is, assuming adequate education is provided.

Are you proposing that every company use publicly routable address
space? How about the ones that don't qualify for a /19 and so are
dependent on addresses owned by their upstream?

This discussion evolved from an IPv6 discussion, so there's plenty of
address space for everybody in the assumptions, and you can have a /48
even if a /64 is overkill.

To change ISPs for example, would it be simpler to change the IP
address of every node in the company or to run NAT on the gateways?

Unlike the security discussions, that's one area where NAT really does
make life easier for medium-large companies (either 1-1 NAT or PNAT
will do.) It lets you number your internal space as 10/8, regardless
of what ISP or ISPs you're using externally, so if you have to change
one of your ISPs, you don't have to renumber anything except possibly
a couple of externally-visible servers and gateways.
Of course, that only remains true until some merger or acquisition
mashes your 10/8 address space into another company's 10/8 address
space , at which point you've still got work to do unless you were
both careful about taking random subnets of 10/8, e.g. 10.x/16 for
randomly selected x>10.

Thus spake "Roger Marquis" <marquis@roble.com>

I, for one, give up. No matter what you say I will never
implement NAT, and you may or may not implement it if people
make boxes that support it.

Most of the rest of us will continue to listen to both sides and
continue to prefer NAT, in no small part because of the absurd
examples and inconsistent terminology NATophobes seem to feel is
necessary to make their case.

The thing is, with IPv6 there's no need to do NAT. What vendors have (so far) failed to deliver is a consumer-grade firewall that does SI with the same rules on by default that v4 NAT devices have. Throw in DHCP PD and addressing (and renumbering) are automatic. This is simpler than NAT because no "fixup" is required; a v6 firewall with SI and public addresses on both sides just needs to inspect packets, not modify them.

The same device will probably be a v4 NAT device; nobody is trying to take that away because it's a necessary evil. However, NAT in v6 is not necessary, and it's still evil.

S

Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

The thing is, with IPv6 there's no need to do NAT.

Changing providers without renumbering your entire infrastructure.

Multi-homing without having to know or participate in BGP games.

(yes, the current PI-for-everybody allocation mindset would address the first, however I have to admit I find the idea of every small enterprise on the planet playing BGP games a bit ... disconcerting)

However, NAT in v6 is not necessary, and it's still evil.

Even ignoring the two above, NAT will be a fact of life as long as people who are only able to obtain IPv6 addresses and need/want to communicate with the (overwhelmingly IPv4 for the foreseeable future) Internet. Might as well get used to it. I for one welcome our new NAT overlords...

Rgds,
-drc

For all those people who think IPv4 NAT is quite fine, I challenge them
to submit RFCs to the IETF that resolve, without creating worse
or more even more complicated problems, the list of problems here. All
the IPv6 RFCs do ... :

http://www.cs.utk.edu/~moore/what-nats-break.html

I've spent a number of years wondering why people seem to like NAT
(don't bother trying to convince me, my burnt stubs of fingers have
convinced me it's evil), and the only feasible conclusion I can come to
is that it is a chance to live out the "invisible man" fantasy they had
in their childhood. We've all had that fantasy I think, and we'd all
like to live it out ...

In IPv6, if you want to have a globally reachable service, you bind it
to a global address, and you protect the rest of the services/layer 4
protocol endpoints on that host that use global addresses via an SI
firewall, preferably on the host itself.

If you don't want to have a service globally reachable, then you don't
bind it to a global address - bind the service only to the to the ULA
addresses on the host. Then it'll be globally unreachable regardless of
whether there is a SI firewall active or not (although if people start
convincing upstreams and peers to accept their ULA routes external to
their own private network ... well, they made that choice, they'll have
to live with the security consequences)

I think at this point, everything that could possibly be said about NAT
and security has been said.

Unless you have something profound to add which hasn't been mentioned in
this thread before, please refrain from adding to this thread.

-Alex (for the mailing list team)

People keep saying that this device doesn't exist, infact it does. First let me say that vendors haven't failed, as they (for the most part) haven't tried yet. I'd consider them to have failed if they delivered a bunch of IPv6 boxes without SI, and that hasn't happened. (ok, Cisco delivered an IPv6 capable CPE in the 8xx series, but IPv6 on those things is hardly a consumer-configurable setting to enable.)

Anyway, my Apple Airport Extreme base station (the new draft-802.11n one) does IPv6 SI and IPv4 NAT perfectly fine, infact, that was the primary reason I bought it. It also does 6to4 or static tunnels if you don't have native IPv6. 6to4 with IPv6 SI is the default out of the box configuration. If you just configure the IPv4 stuff, you get IPv6 for free, by default.

IPv6 SI /was/ disabled by default in the original firmware, and while the firmware update is pretty hard to miss when configuring the thing (it pops up and says "new software, install?" or similar), I believe it leaves the SI checkbox where you'd left it - the new default only kicks in if you do a factory reset. However, I believe that new units ship with the new software, so I suspect it's not really a widespread problem in the grand scheme of things.

This was the first IPv6 capable consumer router, as far as I'm aware, and this issue was found and fixed within weeks. I've got no doubt that other vendors will learn from this mistake.