Or you could simply call it what it is -- a firewall -- since
that's what most consumers think NAT is anyways.While I disagree with the general sentiment that NATs create
security, the standard usage of such devices is certainly
that of a stateful firewall.
All hairsplitting aside, given that the term NAT these days is mostly used
in a PAT (particularly in a customer connecting to the I) context, what
isn't secure about?
Kuhtz, Christian wrote:
...
All hairsplitting aside, given that the term NAT these days is mostly used
in a PAT (particularly in a customer connecting to the I) context, what
isn't secure about?
mangling the header doesn't provide any security, and if you believe it
does, do the following exercise:
Configure a static NAT entry to map all packets from the public side to a
single host on the private side. Show how that mapping provides any more
security than what would exist by putting the public address on that host.
A stateful filter that is automatically populated by traffic originated from
the private side is what is providing 'security'. That function existed in
routers long before NAT was specified by the IETF (see RFC1044 for vendor).
Tony
Thus spake "Tony Hain" <alh-ietf@tndh.net>
Kuhtz, Christian wrote:
> All hairsplitting aside, given that the term NAT these days is mostly
used
> in a PAT (particularly in a customer connecting to the I) context, what
> isn't secure about?mangling the header doesn't provide any security, and if you believe it
does, do the following exercise:
Mangling the header does not, but the stateful inspection and blocking used
by a dynamic NAT/NAPT certainly does.
Configure a static NAT entry to map all packets from the public side to a
single host on the private side. Show how that mapping provides any more
security than what would exist by putting the public address on that host.
You snipped my comment, which said:
the standard usage of such devices is certainly that of a stateful
firewall.
Configuring a static mapping to a particular "inside" host is not the
standard usage in my experience. Obviously if you intentionally create a
hole in your "security device", whether that be a NAT/NAPT or real firewall,
that defeats some or even all of the protection offerred.
A stateful filter that is automatically populated by traffic originated
from
the private side is what is providing 'security'. That function existed in
routers long before NAT was specified by the IETF (see RFC1044 for
vendor).
True. But consumers can't buy a RFC1044 device off the shelf today; what
they can buy are generic NAT/NAPT devices which provide a minimal
firewalling function _iff_ the user doesn't intentionally create holes.
While it'd be nice if these devices didn't _require_ NAT/NAPT for their
minimal operating mode, that's the configuration that is most likely to work
in the setting it's intended for.
S
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
Thus spake "Tony Hain" <alh-ietf@tndh.net>
Kuhtz, Christian wrote:
> All hairsplitting aside, given that the term NAT these days is mostlyused
> in a PAT (particularly in a customer connecting to the I) context, what
> isn't secure about?mangling the header doesn't provide any security, and if you believe it
does, do the following exercise:Mangling the header does not, but the stateful inspection and blocking
used by a dynamic NAT/NAPT certainly does.
The point is that the stateful inspection/blocking can be achieved without
NAT/PAT/NAPT.
A stateful filter that is automatically populated by traffic originated
from
the private side is what is providing 'security'. That function existed
in routers long before NAT was specified by the IETF (see RFC1044 for
vendor).True. But consumers can't buy a RFC1044 device off the shelf today; what
they can buy are generic NAT/NAPT devices which provide a minimal
firewalling function _iff_ the user doesn't intentionally create holes.
While it'd be nice if these devices didn't _require_ NAT/NAPT for their
minimal operating mode, that's the configuration that is most likely to
work in the setting it's intended for.
I'm not sure about RFC1044, but, it's relatively easy to buy lots of
devices that will do stateful inspection without NAT off the shelf.
Any version of *NIX with iptables or ipchains, some Cisco routers,
Various Checkpoint software products, Cyberguard firewalls, Nokia,
Sonic, Netscreen, NetGuard, and others all support Stateful
inspection with or without NAT/PAT/NAPT.
There is NO security benefit to NAT/PAT/NAPT. There is a security benefit
to stateful inspection. NAT is harmful to many protocols. Stateful
inspection is not.
Owen
There is NO security benefit to NAT/PAT/NAPT.
Disagree.
None of the scanning / infecting viruses could get past a $50 NAT/PAT device which Joe User brings home and turns on without configuring.
Do not talk about "if they statically NAT...". Punching holes in stateful firewalls will cause just as much damage.
There is a security benefit
to stateful inspection.
Agreed. And I doubt anyone on this list would say differently.
NAT is harmful to many protocols. Stateful
inspection is not.
Possibly. But Joe User will never use those "many protocols". Plus the overwhelming majority of protocols are not harmed by NAT.
I would bet a statistically insignificant number of packets on the Internet (many places to the right of the decimal) are part of those protocols.
This does not mean we should NAT everything, since I use some of those protocols. But if every Joe User had a DLink NAT box in front of his Winbloze box, the Internet would be a safer place. And you know it.
It's not the NAT that those boxes are doing which protected Joe User (no relation). It's the firewall function of those boxes -- the function which stops certain traffic being permitted through the front door -- which stopped the viruses outside the front door infecting the windows box in the dining room.
The $50 NAT device performs the firewall function as well as the NAT function.
A $50 device which just provided the firewall function would protect Joe User just as well from viruses.
The NAT function is required because Joe User requires multiple addresses, but his ISP will only give him one. That's orthogonal to the firewall function.
Let's move on.
Joe
Patrick W. Gilmore wrote:
NAT is harmful to many protocols. Stateful
inspection is not.Possibly. But Joe User will never use those "many protocols". Plus the overwhelming majority of protocols are not harmed by NAT.
Of course NAT causes all sorts of damage to all sorts of protocols, as the debate over VPN software demonstrated, nevermind voice applications and peer to peer networking. It also has substantial implications for mobility. This has all been well documented, as have workarounds. Having yet another argument about this on nanog is a waste of bits (to which I freely admit I'm contributing). Let me suggest we not bother with the rest of the argument, but just have people search the archives.
Eliot
There is NO security benefit to NAT/PAT/NAPT.
Disagree.
None of the scanning / infecting viruses could get past a $50 NAT/PAT
device which Joe User brings home and turns on without configuring.Do not talk about "if they statically NAT...". Punching holes in
stateful firewalls will cause just as much damage.
Actually, many of the viruses will because they are received via other
mechanisms and create stateful outbound connections that go right past
NAT.
However, the scanners won't get past a STATEFUL INSPECTION firewall,
with or without nat. You can get a $50 stateful inspection device
without NAT too. Takes the same configuration effort and usually on
the same devices. In fact, assuming you have a PC, you probably don't
need to spend $50. You can get a stateful inspection firewall on your
PC by downloading the ISOs from RedHat (or other LINUX source) for FREE.
Admittedly, the free one takes a little bit of configuration, since
you have to check the box that says "high security".
There is a security benefit
to stateful inspection.Agreed. And I doubt anyone on this list would say differently.
Right. There is NO security benefit to NAT/PAT/NAPT beyond the
stateful inspection.
NAT is harmful to many protocols. Stateful
inspection is not.Possibly. But Joe User will never use those "many protocols". Plus the
overwhelming majority of protocols are not harmed by NAT.
If you are telling me that Joe User will never use VOIP, then you are
somking from a different internet hooka than the folks at Vonage. I don't
know which of you is right, but, I know Vonage has enough customers to
say that at least some number of Joe User's are using SIP and RTP
which are among the protocols broken by NAT. Next?
I would bet a statistically insignificant number of packets on the
Internet (many places to the right of the decimal) are part of those
protocols.
I guess that depends on your measurement method. Shall we include or not
include in the count the number of packets that are bogusly tunneled
over other protocols in an attempt to circumvent NAT silliness because
it has become an unfortunate fact of life? Also, depending on who
you ask, P2P filesharing (regardless of your position on the legality,
the technology isn't inherently a bad thing) does not constitute a
statistically insignificant portion of the traffic mix. A number of
P2P protocols incorporate significant workarounds to deal with NAT.
Many of these workarounds do things which essentially eliminate the
previously defined security benefit and often in a way which makes
things less secure than they would have been without NAT with a good
stateful inspection firewall.
This does not mean we should NAT everything, since I use some of those
protocols. But if every Joe User had a DLink NAT box in front of his
Winbloze box, the Internet would be a safer place. And you know it.
I disagree. I think the better solution to that problem is for every Joe
user to spend that $50 suing Micr0$0ft for their exploding pinto in the
local small claims court. If that happened, Micr0$0ft would get the
message that there is a cost to doing business they way they have and they
would be forced to change their strategy and fix some of these issues.
That would be $50 much better spent. Even if Joe user loses his case
in small claims (most likely), making Micr0$0ft play legal whack-a-mole
would still have the desired effect.
For Joe User to go out and get the NAT box requires that Joe User recognize
some level of need for security. If we can teach Joe User that, then we
ought to be able to teach him to secure the box directly without needing
a $50 device. Even Windows now has stateful firewall capabilities on
the box. It's just not that hard.
--
TTFN,
patrick
Owen
Not only that, but it is also enabled by default on their IPv6 stack,
last I messed with Windows and v6 anyway.
-Paul
Owen DeLong wrote:
If you are telling me that Joe User will never use VOIP, then you are
somking from a different internet hooka than the folks at Vonage. I don't
know which of you is right, but, I know Vonage has enough customers to
say that at least some number of Joe User's are using SIP and RTP
which are among the protocols broken by NAT. Next?
Vonage's SIP implementation is not broken by NAT and in fact Vonage recommends that you purchase a SOHO router that does NAT.
That probably means they are not using SIP, but, instead are using
either H.323 or some other proprietary ugliness. That's unfortunate.
SIP has to include the IP address of the RTP destination in it's payload.
As such, you can't use SIP cleanly across NAT unless the NAT box knows
to proxy the SIP and edit the payload (very messy).
In any case, Vonage aside, lots of things that the average user will
eventually consider useful are broken by NAT and NAT is an unnecessary
ugliness in most places where it is used.
It should _NOT_ be encouraged.
Owen
Vonage also has a financial interest in ensuring you're unable to
connect using RTP and SIP to anyone else but them. The NAT router works
great for that.
SIP server vendors (Cisco and Asterisk for a few) have made workarounds
so that the client can be behind NAT, provided it can only talk via the
SIP proxy on the server, it can't be instructed to talk peer-> peer with
another device via a SIP reinvite.
So put this one in the "Dirty hack that works out in the vendor's favor"
category.
-Paul
Owen DeLong wrote:
That probably means they are not using SIP, but, instead are using
either H.323 or some other proprietary ugliness. That's unfortunate.SIP has to include the IP address of the RTP destination in it's payload.
As such, you can't use SIP cleanly across NAT unless the NAT box knows
to proxy the SIP and edit the payload (very messy).
Well, VOIP is not my area of expertise, but Vonage is using SIP and we have some of our engineers who are using our internal VOIP/SIP network behind a NAT device.
That probably means they are not using SIP, but, instead are using
either H.323 or some other proprietary ugliness. That's unfortunate.
You can use SIP through a NAT, if you can hack the NAT to poke particular ranges of ports back to devices on the internal network.
There's no useful way to use H.323 through a NAT though, at least that I have seen working.
SIP has to include the IP address of the RTP destination in it's payload.
As such, you can't use SIP cleanly across NAT unless the NAT box knows
to proxy the SIP and edit the payload (very messy).
Yeah, that's not actually the case.
Joe
I think Paul Timmins covered it rather well.
Owen