Re: Rate of growth on IPv6 not fast enough?
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
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). -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 2010-04-20, at 15:31, 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.
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
On Apr 20, 2010, at 12:55 PM, Joe Abley wrote:
On 2010-04-20, at 15:31, 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.
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
On Apr 20, 2010, at 3:55 PM, Joe Abley wrote:
On 2010-04-20, at 15:31, 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.
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.
Please go read RFC3235. Also please go read some history. This RFC and others that came out of the NAT working group in the IETF were an attempt to document what NAT was, in its various flavors, and NOT to standardize it in any way. Those of us working on the effort faced voices of opposition at every turn, not for trying to standardize it, but just to DOCUMENT it. During the writing of the drafts that became 3235, I was approached by folks working on gaming, and indeed you will find therein a reference to exactly that. What the gamers wanted was a way to punch a hole out in normal NAT fashion for UDP packets with a given port mapping, but then have less stringent matching on subsequent return packets.
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).
Implementing stateful inspection firewall code is rather straightforward. Adding NAT functionality to it adds a small number of additional instructions in the forwarding path, enabled only as needed depending on configuration. The NAT part of it is a trivial additional step, nothing more. The point, though, is when dialup and later DSL and cable connections originally came out, ISPs didn't (and in general wouldn't, or wouldn't without a substantial additional fee) give out blocks of addresses to customers. It was the mismatch of customer need and ISP offerings that led to the implementation of NAT in the router products at the vendor I worked at in the early 1990s. In the end, this is all really good lounge discussion, but has nothing to do with network operations and the purpose of the main NANOG list. It doesn't even have anything to do with the subject line of the threat to which it's attached.
On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
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
On Tue, 20 Apr 2010 12:59:32 -0700 Owen DeLong <owen@delong.com> wrote:
On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
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.
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
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. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
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
On Tue, 20 Apr 2010 21:16:10 -0700 Owen DeLong <owen@delong.com> wrote:
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.
My comment wasn't a reply to you, more of a general comment about the surprising effort you still need to go to explain that stateful firewalling doesn't mandate NAT. I sometimes wonder if some people's heads would explode if I told them that this PC is directly attached to the Internet, has both public IPv4 and IPv6 addresses, and is performing stateful firewalling - with no NAT anywhere. Regards, Mark.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/21/2010 03:38, Mark Smith wrote:
On Tue, 20 Apr 2010 21:16:10 -0700 Owen DeLong <owen@delong.com> wrote:
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.
My comment wasn't a reply to you, more of a general comment about the surprising effort you still need to go to explain that stateful firewalling doesn't mandate NAT.
I sometimes wonder if some people's heads would explode if I told them that this PC is directly attached to the Internet, has both public IPv4 and IPv6 addresses, and is performing stateful firewalling - with no NAT anywhere.
I hear ya. Except for simple translations (e.g. one-to-one, whole net xlates), NAT is dependent on SPI, but SPI is not dependent on NAT. But some seem to combine the two into a single inseparable concept. I've definitely run into people who confuse the concepts. And also presume that without NAT there is less or no security. This head definitely wouldn't explode, since back in the early to mid 90s I ran enterprise networks on which all hosts had public IPs and there was no NAT at all. First protected by "dumb filters" on routers, which were fairly quickly replaced by dedicated SPI firewalls (such as Checkpoint). The first couple SPI firewalls I used didn't even *have* NAT capability. Yet, they did a fine job securing my LANs without it. And this is at a time when most workstations and servers on the LAN didn't have firewalls themselves (no OS included FW). Despite it doing the job it was intended to do, I've always seen NAT as a bit of an ugly hack, with potential to get even uglier with LSN and multi-level NAT in the future. I personally welcome a return to a NAT-less world with IPv6. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvO87cACgkQ2fXFxl4S7sSzQQCfU4Ip5mHkJ/inTfKO/1zih5yY VWUAnjte4aAbrcYvUraMXsUmaPj2JHGA =S3Gn -----END PGP SIGNATURE-----
On 4/21/2010 8:46 AM, Jim Burwell wrote:
Despite it doing the job it was intended to do, I've always seen NAT as a bit of an ugly hack, with potential to get even uglier with LSN and multi-level NAT in the future. I personally welcome a return to a NAT-less world with IPv6. :)
Don't you get all of the same problems when there is a properly restrictive SPI firewall at both ends of the connection regardless of weather NAT is used as well.
No. You get a different set of problems, mostly administrative. On Apr 21, 2010, at 1:53 PM, Dave Sparro wrote:
On 4/21/2010 8:46 AM, Jim Burwell wrote:
Despite it doing the job it was intended to do, I've always seen NAT as a bit of an ugly hack, with potential to get even uglier with LSN and multi-level NAT in the future. I personally welcome a return to a NAT-less world with IPv6. :)
Don't you get all of the same problems when there is a properly restrictive SPI firewall at both ends of the connection regardless of weather NAT is used as well.
James R. Cutler james.cutler@consultant.com
Dave Sparro wrote:
Don't you get all of the same problems when there is a properly restrictive SPI firewall at both ends of the connection regardless of weather NAT is used as well.
If you mean, "do we still need protocols similar to uPNP" the answer is yes. Of course, uPNP is designed with a SPI in mind. However, we simplify a lot of problems when we remove address mangling from the equation. That's not to say there won't be NAT for IPv6. Fact is, businesses will ask and firewall vendors will give. Of course, business needs are often different than general usage (and especially home usage) needs. Jack
On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote:
On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
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. 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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On 4/20/2010 6:34 PM, Karl Auer wrote:
On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote:
On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
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.
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.
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.
On Apr 20, 2010, at 6:34 PM, Karl Auer wrote:
On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote:
On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
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
In message <FB17BC57-FAB3-45E1-886A-664A0FD42C9E@delong.com>, Owen DeLong write s:
On Apr 20, 2010, at 6:34 PM, Karl Auer wrote:
On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote:
On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
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.
Especially when the NAT/Router has a enable/disable NAT checkbox.
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
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, 2010-04-20 at 21:27 -0700, Owen DeLong wrote:
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.
Possibly restating Mark's point, but if fat fingers are allowed as a source of failure, impact is unlimited.
IOW, All of NAT's security comes from the fact that it requires a state table, like stateful inspection.
Er - I think it's a deeper point I was making. To the extent that NAT offers security at all, that security comes as an *unintentional side effect* of the job it is actually designed to do. That is, the NAT device *does not care* about its "security" function. Regards, K.
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
On 4/20/2010 6:34 PM, Karl Auer wrote:
On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote:
On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
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 addressed packet go when it leaks. These sorts of things I wonder about when I contemplate doing syslog on a q-in-q vlan over a vpls.
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.
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.
On Tue, Apr 20, 2010 at 9:34 PM, Karl Auer <kauer@biplane.com.au> wrote:
On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote:
On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
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.
Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Wed, 21 Apr 2010 14:24:37 -0400 William Herrin <bill@herrin.us> wrote:
On Tue, Apr 20, 2010 at 9:34 PM, Karl Auer <kauer@biplane.com.au> wrote:
On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote:
On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
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.
Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed.
Fail is expecting a low level staff member, who doesn't know better, to substitute for a senior one, who does. Would you also let a helpdesk teamleader (low level, relatively inexperienced management position) take over the CEO's job if the CEO was available and there was a business crisis? A medical student take over from a doctor in an emergency ward?
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
CEO position -> >>>>Did you know:
The majority of S&P 500 CEOs are in their 50s 29% of S&P 500 CEOs have an advanced degree other than an MBA CEOs in the S&P 401-500 group are more likely to have a shorter tenure with his or her company than other S&P 500 CEOs 60% of S&P 500 CEOs have been in office less than six years CEOs of the top 100 S&P 500 companies are more likely than the rest of the S&P 500 CEOs to have been with the same company throughout their entire career
Operation Director ->>>>>> some say that age wouldn't be that important, though maturity might. How would they feel about being given this much power? What kinds of goals should they have in mind if they get the job? Don't forget that the person over 30 may be just as new to IT as a fresh college graduate. more ...and more .....you just won't believe how this is smashing your hearts to pieces ...... CAREER HISTORY 1996-2000: Graduate trainee rising to marketing manager Are you sure you don't need a network technician to do the job? ----- Original Message ---- From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> To: William Herrin <bill@herrin.us> Cc: nanog@nanog.org Sent: Thu, April 29, 2010 10:24:03 PM Subject: Re: Rate of growth on IPv6 not fast enough? On Wed, 21 Apr 2010 14:24:37 -0400 William Herrin <bill@herrin.us> wrote:
On Tue, Apr 20, 2010 at 9:34 PM, Karl Auer <kauer@biplane.com.au> wrote:
On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote:
On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
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.
Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed.
Fail is expecting a low level staff member, who doesn't know better, to substitute for a senior one, who does. Would you also let a helpdesk teamleader (low level, relatively inexperienced management position) take over the CEO's job if the CEO was available and there was a business crisis? A medical student take over from a doctor in an emergency ward?
Regards, Bill Herrin
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Apr 29, 2010 at 11:24 AM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Wed, 21 Apr 2010 14:24:37 -0400 William Herrin <bill@herrin.us> wrote:
Fail means that an inexperienced admin drops a router in place of the firewall to work around a priority problem while the senior engineer is on vacation. With NAT protecting unroutable addresses, that failure mode fails closed.
Fail is expecting a low level staff member, who doesn't know better, to substitute for a senior one, who does.
Funny thing about junior staff... Their reach is often longer than their grasp. Someone has to have the keys when the senior guy is away... Even if they don't always have the good judgment to know what they can safely do with them. As the senior guy, I'd rather find out about the mistake when the panicked junior calls me on the cell phone because he crashed the network, not when I get back and find the company jewels have been stolen. NAT protecting unroutable addresses gives me a better chance that junior's mistake only causes a network outage. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, 29 Apr 2010 15:58:24 -1000, William Herrin said:
Funny thing about junior staff... Their reach is often longer than their grasp. Someone has to have the keys when the senior guy is away...
Isn't that the defense that Terry Childs used? :) (Sorry, couldn't resist. :)
On 04/20/2010 09:31 PM, Roger Marquis wrote:
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 ?
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
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
On 04/20/2010 04:51 PM, Jack Bates wrote:
uPNP at a larger scale? Would require some serious security and scalability analysis.
This is the latest proposal. The Security Considerations section needs some love... http://tools.ietf.org/html/draft-wing-softwire-port-control-protocol Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org
Simon Perreault wrote:
This is the latest proposal. The Security Considerations section needs some love...
http://tools.ietf.org/html/draft-wing-softwire-port-control-protocol
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
On Tue, 20 Apr 2010 18:03:09 EDT, Simon Perreault said:
This is the latest proposal. The Security Considerations section needs some love...
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.)
Valdis.Kletnieks@vt.edu wrote:
(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.)
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
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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Tue, 20 Apr 2010, Chris Adams wrote:
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.
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
participants (20)
-
Chris Adams -
Cutler James R -
Daniel Senie -
Dave Pooser -
Dave Sparro -
isabel dias -
Jack Bates -
Jim Burwell -
Joe Abley -
joel jaeggli -
Karl Auer -
Leen Besselink -
Mark Andrews -
Mark Smith -
Mikael Abrahamsson -
Owen DeLong -
Roger Marquis -
Simon Perreault -
Valdis.Kletnieks＠vt.edu -
William Herrin