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? ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.61"
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
--On Friday, October 31, 2003 7:35 AM -0600 Stephen Sprunk <stephen@sprunk.org> wrote:
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.
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 -- If it wasn't signed, it probably didn't come from me.
-- On Friday, October 31, 2003 08:03 -0800 -- Owen DeLong <owen@delong.com> supposedly wrote:
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. -- TTFN, patrick
On 31 Oct 2003, at 11:43, Patrick W. Gilmore wrote:
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.
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
--On Friday, October 31, 2003 11:43 AM -0500 "Patrick W. Gilmore" <patrick@ianai.net> wrote:
-- On Friday, October 31, 2003 08:03 -0800 -- Owen DeLong <owen@delong.com> supposedly wrote:
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 -- If it wasn't signed, it probably didn't come from me.
On Fri, 2003-10-31 at 12:26, Owen DeLong wrote:
Even Windows now has stateful firewall capabilities on the box. It's just not that hard.
Not only that, but it is also enabled by default on their IPv6 stack, last I messed with Windows and v6 anyway. -Paul -- Paul Timmins <paul@timmins.net>
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.
Owen
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 --On Saturday, November 1, 2003 11:33 AM -0600 Shawn Morris <shawn@smorris.com> wrote:
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.
Owen
-- If it wasn't signed, it probably didn't come from me.
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.
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
--On Saturday, November 1, 2003 11:33 AM -0600 Shawn Morris <shawn@smorris.com> wrote:
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.
Owen
I think Paul Timmins covered it rather well. Owen --On Saturday, November 1, 2003 11:56 AM -0600 Shawn Morris <shawn@smorris.com> wrote:
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.
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
--On Saturday, November 1, 2003 11:33 AM -0600 Shawn Morris <shawn@smorris.com> wrote:
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.
Owen
-- If it wasn't signed, it probably didn't come from me.
On 1 Nov 2003, at 12:43, 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.
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
On Sat, 2003-11-01 at 12:33, Shawn Morris wrote:
Vonage's SIP implementation is not broken by NAT and in fact Vonage recommends that you purchase a SOHO router that does NAT.
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 -- Paul Timmins <paul@timmins.net>
participants (9)
-
Eliot Lear -
Joe Abley -
Kuhtz, Christian -
Owen DeLong -
Patrick W. Gilmore -
Paul Timmins -
Shawn Morris -
Stephen Sprunk -
Tony Hain