Rate of growth on IPv6 not fast enough?

Mailman List Mirror (Read Only)
1

Jack Bates wrote:

.01%? heh. NAT can break xbox, ps3, certain pc games, screw with various
programs that dislike multiple connections from a single IP, and the
crap load of vpn clients that appear on the network and do not support
nat traversal (either doesn't support it, or big corp A refuses to
enable it).

If this were really an issue I'd expect my nieces and nephews, all of whom are big
game players, would have mentioned it. They haven't though, despite being behind
cheap NATing CPE from D-Link and Netgear.

Address conservation aside, the main selling point of NAT is its filtering of inbound
session requests. NAT _always_ fails-closed by forcing inbound connections to pass
validation by stateful inspection. Without this you'd have to depend on less
reliable (fail-open) mechanisms and streams could be initiated from the Internet at
large. In theory you could enforce fail-closed reliably without NAT, but the rules
would have to be more complex and complexity is the enemy of security. Worse, if
non-NATed CPE didn't do adequate session validation, inspection, and tracking, as
low-end gear might be expected to cut corners on, end-user networks would be more
exposed to nefarious outside-initiated streams.

Arguments against NAT uniformly fail to give credit to these security considerations,
which is a large reason the market has not taken IPv6 seriously to-date. Even in big
business, CISOs are able to shoot-down netops recommendations for 1:1 address mapping
with ease (not that vocal NAT opponents get jobs where internal security is a
concern).

IMO,
Roger Marquis

2

Once upon a time, Roger Marquis <marquis@roble.com> said:

Address conservation aside, the main selling point of NAT is its filtering
of inbound
session requests. NAT _always_ fails-closed by forcing inbound connections
to pass
validation by stateful inspection. Without this you'd have to depend on
less
reliable (fail-open) mechanisms and streams could be initiated from the
Internet at
large. In theory you could enforce fail-closed reliably without NAT, but
the rules
would have to be more complex and complexity is the enemy of security.

NAT == stateful firewall + packet mangling. You can do all the same
stateful firewall bits and drop the packet mangling quite easily (it is
certainly not "more complex" to not mangle packets).

3

If this were really an issue I'd expect my nieces and nephews, all of whom are big
game players, would have mentioned it. They haven't though, despite being behind
cheap NATing CPE from D-Link and Netgear.

I have heard it said before that there is significant cooperation and/or software engineering work between some or all of those who make residential gateways and those who make multi-player games to achieve this end result. The opinion I heard vocalised at the time was that it would have been a lot easier to reach this state of affairs if there had been standardisation of NAT in v4 at an early stage. As it is, peer-to-peer apps like games require significant if-then-else to make anything work.

Address conservation aside, the main selling point of NAT is its filtering of inbound
session requests.

If that was all that was required, you could sell a stateful firewall that didn't do NAT, and everybody would buy that instead because it would make things like iChat AV break less. Apparently there are other reasons to buy and sell devices that NAT (e.g. my ISP gives me one address, but the laptop and the Wii both want to use the internet).

Joe

4

Jack Bates wrote:

.01%? heh. NAT can break xbox, ps3, certain pc games, screw with various
programs that dislike multiple connections from a single IP, and the
crap load of vpn clients that appear on the network and do not support
nat traversal (either doesn't support it, or big corp A refuses to
enable it).

If this were really an issue I'd expect my nieces and nephews, all of whom are big
game players, would have mentioned it. They haven't though, despite being behind
cheap NATing CPE from D-Link and Netgear.

Address conservation aside, the main selling point of NAT is its filtering of inbound
session requests. NAT _always_ fails-closed by forcing inbound connections to pass
validation by stateful inspection. Without this you'd have to depend on less

Repeating the same falsehood does not make it any less false.

reliable (fail-open) mechanisms and streams could be initiated from the Internet at
large. In theory you could enforce fail-closed reliably without NAT, but the rules

Stateful Inspection can be implemented fail-closed. I point to Juniper ScreenOS
and Services JunOS as examples of this. Absent a specific permit or specific
configuration telling it to pass particular traffic inbound, traffic must pass the same
stateful inspection that NAT would require. This is default behavior in those boxes.
The rules are not complex at all.

would have to be more complex and complexity is the enemy of security. Worse, if
non-NATed CPE didn't do adequate session validation, inspection, and tracking, as

Again, you simply are not correct here. I'm not sure what level of implementation is
available in low-end gear as it hasn't met my needs in a long long time. However,
I will say that although an SRX-100 is not especially low-end at 10x absolute low
end pricing and 5x average home gateway pricing, it is low-enough end that I
know this can be done in reasonable gear.

low-end gear might be expected to cut corners on, end-user networks would be more
exposed to nefarious outside-initiated streams.

Frankly, even with NAT, corner-cutting in those areas can lead to things passing which
you don't expect.

Arguments against NAT uniformly fail to give credit to these security considerations,

Because they are false. It's not that they fail to give credit to them. It's that they know
them to be false. It's like saying that discussions of breathing gas fail to give credit
to the respiratory effects of the trace amounts of argon present in the atmosphere.

which is a large reason the market has not taken IPv6 seriously to-date. Even in big
business, CISOs are able to shoot-down netops recommendations for 1:1 address mapping
with ease (not that vocal NAT opponents get jobs where internal security is a
concern).

While I recognize that there is a group of people who religiously believe that NAT
has a security benefit, I don't think the represent a significant fraction of the reasons
IPv6 is not getting deployed. Frankly, many of them have more IPv6 deployed than
they realize and their NAT is not protecting them from it at all. It may even be helping
some of the nefarious traffic that may be taking advantage of the current situation
to remain safely anonymized and invisible.

Owen

5

If this were really an issue I'd expect my nieces and nephews, all of whom are big
game players, would have mentioned it. They haven't though, despite being behind
cheap NATing CPE from D-Link and Netgear.

I have heard it said before that there is significant cooperation and/or software engineering work between some or all of those who make residential gateways and those who make multi-player games to achieve this end result. The opinion I heard vocalised at the time was that it would have been a lot easier to reach this state of affairs if there had been standardisation of NAT in v4 at an early stage. As it is, peer-to-peer apps like games require significant if-then-else to make anything work.

The fact that they work is usually due to uPNP or another inbound NAT-T solution. All of these will be very unlikely to work in an LSN environment. None of them work in a multilayer NAT environment.

Address conservation aside, the main selling point of NAT is its filtering of inbound
session requests.

If that was all that was required, you could sell a stateful firewall that didn't do NAT, and everybody would buy that instead because it would make things like iChat AV break less. Apparently there are other reasons to buy and sell devices that NAT (e.g. my ISP gives me one address, but the laptop and the Wii both want to use the internet).

In IPv4, yes, there are other reasons. (Address conservation). In IPv6, it shouldn't be a problem to sell a stateful firewall that doesn't do NAT.

Owen

6

Jack Bates wrote:

.01%? heh. NAT can break xbox, ps3, certain pc games, screw with various
programs that dislike multiple connections from a single IP, and the
crap load of vpn clients that appear on the network and do not support
nat traversal (either doesn't support it, or big corp A refuses to
enable it).

If this were really an issue I'd expect my nieces and nephews, all of whom are big
game players, would have mentioned it. They haven't though, despite being behind
cheap NATing CPE from D-Link and Netgear.

Address conservation aside, the main selling point of NAT is its filtering of inbound
session requests. NAT _always_ fails-closed by forcing inbound connections to pass
validation by stateful inspection. Without this you'd have to depend on less
reliable (fail-open) mechanisms and streams could be initiated from the Internet at
large. In theory you could enforce fail-closed reliably without NAT, but the rules
would have to be more complex and complexity is the enemy of security. Worse, if

As others have mentioned on the list, this is wrong. NAT is the one that makes things
much more complicated in fact. And even NAT can be tricked.

But I do have a question:

Do you think TCP-port 53 for DNS are only used for domain-name transfers ?

7

Roger Marquis wrote:

If this were really an issue I'd expect my nieces and nephews, all of whom are big
game players, would have mentioned it. They haven't though, despite being behind
cheap NATing CPE from D-Link and Netgear.

Disable the uPNP (some routers lack it, and yes, it breaks and microsoft will tell you to get uPNP capable NAT routers or get a new ISP).

uPNP at a larger scale? Would require some serious security and scalability analysis.

Arguments against NAT uniformly fail to give credit to these security considerations,

Your argument has nothing to do with this part of the thread and discussion of why implementing NAT at a larger scale is bad. I guess it might have something to do in other tangents of supporting NAT66.

Jack

8

This is the latest proposal. The Security Considerations section needs
some love...

http://tools.ietf.org/html/draft-wing-softwire-port-control-protocol

Simon

9

Simon Perreault wrote:

This is the latest proposal. The Security Considerations section needs
some love...

draft-wing-softwire-port-control-protocol-02

Nice read. IF it ever makes it into all the necessary clients, then perhaps it might be a bit more feasible. That is a big if and very little time for adoption in a large number of devices to fix just one of the problems.

Jack

10

> Jack Bates wrote:
>> .01%? heh. NAT can break xbox, ps3, certain pc games, screw with various
>> programs that dislike multiple connections from a single IP, and the
>> crap load of vpn clients that appear on the network and do not support
>> nat traversal (either doesn't support it, or big corp A refuses to
>> enable it).
>
> If this were really an issue I'd expect my nieces and nephews, all of whom are big
> game players, would have mentioned it. They haven't though, despite being behind
> cheap NATing CPE from D-Link and Netgear.
>
> Address conservation aside, the main selling point of NAT is its filtering of inbound
> session requests. NAT _always_ fails-closed by forcing inbound connections to pass
> validation by stateful inspection. Without this you'd have to depend on less

Repeating the same falsehood does not make it any less false.

> reliable (fail-open) mechanisms and streams could be initiated from the Internet at
> large. In theory you could enforce fail-closed reliably without NAT, but the rules

Stateful Inspection can be implemented fail-closed. I point to Juniper ScreenOS
and Services JunOS as examples of this. Absent a specific permit or specific
configuration telling it to pass particular traffic inbound, traffic must pass the same
stateful inspection that NAT would require. This is default behavior in those boxes.
The rules are not complex at all.

Frankly, when you hear people strongly using the argument stateful
firewalling == NAT, you start to wonder if they've ever seen a stateful
firewall using public addresses.

11

I may be the only one that finds that unintentionally hilarious.

In any case, to a first-order approximation, it doesn't even matter all that
much security wise. I mean - let's be *honest* guys. After XP SP2 got any
significant market penetration, pretty much everybody had a host-based firewall
that defaulted to default-deny, so the NAT-firewall was merely belt and
suspenders.

Pretty much all the attacks we've seen in the last few years have been things
like web drive-bys, trojaned torrents, and other stuff that sails right in
through open ports through the firewall (both host and standalone). And any
malware that's able to turn around and punch open a port on the host firewall
is just as easily able to go and use uPNP to send a "Pants Down!" command to
the standalone firewall.

(Yes, defense in depth is a Good Thing. But that external firewall isn't
doing squat for your security if it actually accepts uPNP from inside.)

12

In this case we are referring to uPNP functionality at a LSN level. uPNP as it sits will not work at all, and security in this case refers not to the customer but to the ISP's router/server performing this service.

Jack

13

Once upon a time, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> said:

In any case, to a first-order approximation, it doesn't even matter all that
much security wise. I mean - let's be *honest* guys. After XP SP2 got any
significant market penetration, pretty much everybody had a host-based firewall
that defaulted to default-deny, so the NAT-firewall was merely belt and
suspenders.

Well, that covers the hosts. "Normal" people are adding more devices
than PCs all the time, such as network printers (which have a very
spotty security record, especially on the cheap end) and disk servers.
Network devices like that _can't_ just block all access.

14

Windows XP SP2 and later has the concept of different "zones" (or whatever it's called) where it'll allow things from the local subnet but not from outside of it, if you tell it so. I know people who configure their network printers without default gw to handle their spotty security.

I do think the home router should have a stateful firewall and according to what I see in the IETF, this is going to be the recommendation for an IPv6 enabled home gateway.

15

Not to take issue with either statement in particular, but I think there
needs to be some consideration of what "fail" means.

Dealing with an unwanted but foreseeable error condition, like running
out of memory, is not a failure mode. It is a controlled event. NOT
dealing with it is a failure mode.

So a properly written program (or properly constructed device) will deal
with whatever error conditions the designer was able to anticipate, and
will hopefully deal with them intelligently. Power failure and physical
damage are harder to handle than others, but on high-end equipment even
some of those are considered and managed. Ideally the designer will have
considered all conditions that can possibly arise, but the ideal is not
achievable. There will *always* be conditions a program or device is
unable to handle or possibly even detect.

When a situation arises that is beyond the control of the program or
device, was not anticipated by the designer, or if the designer made a
mistake, we enter the realm of an actual failure. And all bets are off.
NAT (for example) could fail in any way at all - including by (say)
inappropriately sharing a mapping. If processes are running on a shared
platform - say NAT, routing and packet filtering - failure of any part
could cause failure of any other part. In some cases (I seem to recall
that recent Californian power failures were an example) the error
handling itself can cause another error condition and another
opportunity for failure.

Reading through the security alerts from any vendor is a pretty sobering
process - stuff fails open more often than you might expect.

So I think we should be very cautious about saying that things "fail
open" or "fail closed".

We should be especially cautious about it when the functionality we are
interested in is really no more than a happy side effect of some other
functionality. NAT's "security", to the extent that it exists at all, is
a side effect of what it is intended to do, which is translate and map
addresses.

Regards, K.

16

NAT _always_ fails-closed

I love this statement particularly in the context of enterprise networks...

When you pop the label off an l3 vpn or pseudo wire in the wrong place where does the packet go? Does one even know? does the outside network have overlapping addresses with the inside one, does it have a default route? is there filtering?

Is it an opportunity for information leakage?

How many parallel networks with overlapping private addressing domains are there on router? your your l3 vpn providers routers? How far will a private address get you when it leaks. These sorts of things I wonder about when I contemplate doing syslog on a q-in-q vlan over a vpls.

17

Once upon a time, Mikael Abrahamsson <swmike@swm.pp.se> said:

Windows XP SP2 and later has the concept of different "zones" (or whatever
it's called) where it'll allow things from the local subnet but not from
outside of it, if you tell it so. I know people who configure their
network printers without default gw to handle their spotty security.

That still requires someone to configure a printer, while most just plug
it in and let it DHCP. Also, I needed to update the firmware on a
network printer once, and it had to have a gateway because it downloaded
the firmware directly.

Heck, I have filled up a 5 port switch in my entertainment center now
with TiVo, Xbox, Blu-Ray, and TV (plus back-haul); all of those use the
Internet and so should have the protection of a firewall at the gateway
(and of course the Xbox requires UPnP for some games). The TiVo,
Blu-Ray, and possibly TV run Linux, which may be somewhat safer, but
Linux has had (and will have) bugs too.

18

Frankly, when you hear people strongly using the argument stateful
firewalling == NAT, you start to wonder if they've ever seen a stateful
firewall using public addresses.

I'd hazard a guess that the number of hosts behind NAT gateways is an order
of magnitude -- probably two-- greater than the number of hosts behind
stateful firewalls using public addresses. It's not that the latter don't
exist, it's that economies of scale make the NAT/PAT appliances more widely
used and thus more relevant to the discussion.

19

Frankly, when you hear people strongly using the argument stateful
firewalling == NAT, you start to wonder if they've ever seen a stateful
firewall using public addresses.

I've run several of them.

Why do you ask?

Owen

20

NAT _always_ fails-closed

Stateful Inspection can be implemented fail-closed.

Not to take issue with either statement in particular, but I think there
needs to be some consideration of what "fail" means.

I believe we are talking about the case where some engineer fat-fingers
a change and Roger's claim is that a stateful inspection without NAT
box will permit unintended traffic while a NAT box will not.

My claim is that the stateful inspection box can be implemented such
that it has an equally secure set of failure modes for fat-fingering to
a NAT+stateful inspection device.

Reading through the security alerts from any vendor is a pretty sobering
process - stuff fails open more often than you might expect.

Yep.

So I think we should be very cautious about saying that things "fail
open" or "fail closed".

My point is not that they do or do not fail closed, but, that a well designed
SI firewall will fail with the exact same security risks as a NAT device.

We should be especially cautious about it when the functionality we are
interested in is really no more than a happy side effect of some other
functionality. NAT's "security", to the extent that it exists at all, is
a side effect of what it is intended to do, which is translate and map
addresses.

IOW, All of NAT's security comes from the fact that it requires a state
table, like stateful inspection.

Owen