Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
Seth Mattinen wrote:
Far too many people see NAT as synonymous with a firewall so they think if you take away their NAT you're taking away the security of a firewall.
NAT provides some security, often enough to make a firewall unnecessary. It all depends on what's inside the edge device. But really, I've never heard anyone seriously equate a simple NAT device with a firewall. People do, and justifiably, equate NAT with the freedom to number, subnet, and route their internal networks however they choose. To argue against that freedom is anti-consumer. Continue to ignore consumer demand and the marketplace will continue to respond accordingly. Give consumers a choice (of NAT or not) and they will come (to IPv6). It's just about as simple as that. Well, that and a few unresolved issues with CAMs, routing tables, and such. Roger Marquis
Roger Marquis wrote:
Seth Mattinen wrote:
Far too many people see NAT as synonymous with a firewall so they think if you take away their NAT you're taking away the security of a firewall.
NAT provides some security, often enough to make a firewall unnecessary. It all depends on what's inside the edge device. But really, I've never heard anyone seriously equate a simple NAT device with a firewall.
You must be very sheltered. Most end users, even "security" folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on "security" through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. 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
Stephen Sprunk wrote:
You must be very sheltered. Most end users, even "security" folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on "security" through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix.
It's also worth pointing out that CPE for DSL often has really poor stateful firewall code. So often turning it off means less issues for home users. At least NAT gives some semblance of protection. IPv6 without NAT might be awesome to some, but the reality is CPE is built to a price and decent firewall code is thin on the ground. I'm not hopeful of it getting better when IPv6 starts to become mainstream. (In case it's not clear - I'm not talking about enterprise stuff - I'm talking about CPE for domestic DSL/Cable users - please don't tell me all about how cool NetScreen/PIX/ASA/<insert favourite fw> is for enterprise). MMC -- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
On Feb 6, 2009, at 7:06 PM, Matthew Moyle-Croft wrote:
Stephen Sprunk wrote:
You must be very sheltered. Most end users, even "security" folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on "security" through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix.
It's also worth pointing out that CPE for DSL often has really poor stateful firewall code. So often turning it off means less issues for home users. At least NAT gives some semblance of protection. IPv6 without NAT might be awesome to some, but the reality is CPE is built to a price and decent firewall code is thin on the ground. I'm not hopeful of it getting better when IPv6 starts to become mainstream.
IPTables is decent firewall code. It's free. I don't buy that argument for a second. Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code. Owen
(In case it's not clear - I'm not talking about enterprise stuff - I'm talking about CPE for domestic DSL/Cable users - please don't tell me all about how cool NetScreen/PIX/ASA/<insert favourite fw> is for enterprise).
MMC
-- Matthew Moyle-Croft - Internode/Agile - Networks Level 4, 150 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc@internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909
Tell ya what Owen, When you can show me residential grade CPE which has a DECENT stateful firewall then PLEASE let me know. Needs to do other things well, not crash, not cost hundreds of dollars, supportable, does VOIP, WIFI etc are manufacturer supported etc. Of course, it needs to do IPv6 as well. (it's easy to say Owen, but quite frankly, the reality from my side of the fence as an operator is that it's not the norm). MMC On 07/02/2009, at 2:02 PM, Owen DeLong wrote:
IPTables is decent firewall code.
It's free.
I don't buy that argument for a second.
Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code.
Owen
On Fri, 06 Feb 2009 22:32:10 -0500, Owen DeLong <owen@delong.com> wrote:
IPTables is decent firewall code.
Not really. It's quite complicated for a non-engineer type to manage. Think of all the unpatched windows xp/vista users of the world.
It's free. ... Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code.
No. It's not. While you might not be paying anyone for the software, it does come with some significant costs... a moderately powerful processor and a lot of memory. Ah, "but both are cheap these days, and getting cheaper", you say. Tell me where I can get 500MHz+ processors and 16+ MB of ram for "pennies". Case in point... (in case you missed it) Linksys stopped using Linux on their popular WRT54G line years ago in favor of vxWorks because it took less resources and therefor meant they could use less memory (flash and ram) and save money despite paying a license fee for vxWorks. (They still use vxWorks on the 54g, but have used linux on their newer (much more expensive) hardware.) DSL and cable modems are extremely simple devices. I'm amazed they have any amount of "router" in them at all. And I've yet to see one running Linux. (the 2 popular brands around here -- westell and motorola -- run vxworks.) --Ricky
Comtrend DSL modem use iptables in their code. I discovered this while trying to understood why small-MTU FTP breaks when issuing the PORT command. Frank -----Original Message----- From: Ricky Beam [mailto:jfbeam@gmail.com] Sent: Monday, February 09, 2009 4:01 PM To: Owen DeLong Cc: nanog@nanog.org Subject: Re: v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space <snip> DSL and cable modems are extremely simple devices. I'm amazed they have any amount of "router" in them at all. And I've yet to see one running Linux. (the 2 popular brands around here -- westell and motorola -- run vxworks.) --Ricky
IPTables is decent firewall code.
Not really. It's quite complicated for a non-engineer type to manage. Think of all the unpatched windows xp/vista users of the world.
It's free. ... Further, since more and more CPE is being built on embedded linux, there's no reason that IPTables isn't a perfectly valid approach to the underlying firewall code.
No. It's not. While you might not be paying anyone for the software, it does come with some significant costs... a moderately powerful processor and a lot of memory. Ah, "but both are cheap these days, and getting cheaper", you say. Tell me where I can get 500MHz+ processors and 16+ MB of ram for "pennies". Case in point... (in case you missed it) Linksys stopped using Linux on their popular WRT54G line years ago in favor of vxWorks because it took less resources and therefor meant they could use less memory (flash and ram) and save money despite paying a license fee for vxWorks. (They still use vxWorks on the 54g, but have used linux on their newer (much more expensive) hardware.)
Well thank goodness that VxWorks 6.x (or with 3rd party hackery) can both do IPv6 and can have firewalling functionality as well (or so Google tells me). Oh, and Linux can be tiny - even with iptables. I suspect Cisco (nee Linksys) chose VxWorks for a number of reasons, "footprint" being but one of them.
DSL and cable modems are extremely simple devices. I'm amazed they have any amount of "router" in them at all. And I've yet to see one running Linux. (the 2 popular brands around here -- westell and motorola -- run vxworks.)
Actually, the DOCSIS 3.0 spec may be changing that ... "eRouter" ...
Matthew Moyle-Croft wrote:
Stephen Sprunk wrote:
You must be very sheltered. Most end users, even "security" folks at major corporations, think a NAT box is a firewall and disabling NAT is inherently less secure. Part of that is factual: NAT (er, dynamic PAT) devices are inherently fail-closed because of their design, while a firewall might fail open. Also, NAT prevents some information leakage by hiding the internal details of the site's network, and many folks place a high value on "security" through obscurity. This is understandable, since the real threats -- uneducated users and flawed software -- are ones they have no power to fix. It's also worth pointing out that CPE for DSL often has really poor stateful firewall code. So often turning it off means less issues for home users.
I assume you're referring to ALG code? Indeed, I've found that turning off ALGs in NAT/FW boxes fixes a lot of problems, because every vendor's seem to be broken in a different way. I deal mainly with SIP these days, and the first step in any sort of firewall-related troubleshooting is to turn _off_ any SIP ALG functionality in the CPE because 90% of the time, that's whats breaking things; the end devices can deal with NAT as long as there's nobody in the middle mangling their packets. Ideally, ALGs would fix up the packets such that the endpoints didn't need to be NAT-aware, but they're all (and I mean all, not most) so hideously broken that they make things worse, not better. They can't get even simple, fossilized protocols like active FTP working most of the time; there's no way they'll do better with newer, more complicated ones like SIP or the dizzying array of P2P and IM protocols.
At least NAT gives some semblance of protection. IPv6 without NAT might be awesome to some, but the reality is CPE is built to a price and decent firewall code is thin on the ground. I'm not hopeful of it getting better when IPv6 starts to become mainstream.
Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate. However, to be safe the endpoints cannot assume any firewalls in the path are going to work properly, and the absence of NAT makes it tougher for endpoints to detect firewalls' presence and react as needed...
(In case it's not clear - I'm not talking about enterprise stuff - I'm talking about CPE for domestic DSL/Cable users - please don't tell me all about how cool NetScreen/PIX/ASA/<insert favourite fw> is for enterprise).
I've found the "enterprise" NAT/FW gear to be worse: they attempt to implement more ALGs, but they do no better a job at implementing them than the less-ambitious consumer vendors, so more things break. 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 Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk <stephen@sprunk.org> wrote:
Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate.
This is exactly the same with NAT and non-NAT -- making any anti-NAT arguments null. In the case of NAT, the "helper" has to understand the protocol to know what traffic to map. In the case of a stateful firewalling ("non-NAT"), the "helper" has to understand the protocol to know what traffic to allow. Subtle difference, but in the end, the same thing... if your gateway doesn't know what you are doing, odds are it will interfere with it. In all cases, end-to-end transparency doesn't exist. (as has been the case for well over a decade.) --Ricky
Ricky Beam wrote:
On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk <stephen@sprunk.org> wrote:
Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate.
This is exactly the same with NAT and non-NAT -- making any anti-NAT arguments null.
Actually, it's worlds different.
In the case of a stateful firewalling ("non-NAT"), the "helper" has to understand the protocol to know what traffic to allow.
This is not completely true. Technologies such as uPNP can quickly open up a pinhole for traffic which needs to be initiated from the far end, but no address rewriting is necessary by the software (embedded in the protocol) or the firewall. For non-UDP/TCP packets, ports have no meaning, which is the biggest failing of NAT (since we are talking about overloading on one IP here, and not 1 to 1 translations). Firewall rules for packets that are not UDP/TCP usually allow the return traffic based on source and destination IP and IP protocol number. NAT, on the other hand can't do it. We have to make udp/tcp tunnels to carry the traffic through NAT instead.
Subtle difference, but in the end, the same thing... if your gateway doesn't know what you are doing, odds are it will interfere with it. In all cases, end-to-end transparency doesn't exist. (as has been the case for well over a decade.)
End-to-end addressing does exist, though. There are cases that are straight forward that NAT breaks without adding extra tunneling layers, or without either NAT or the software having to rewrite an embedded IP address in a packet to the public address. Sure, stateful firewalls can still block traffic and break certain scenarios without the assistance of uPNP(or application layer analysis). They will be simpler, and break less (we'd hope simpler means less). It's one thing to communicate with your firewall to dynamically open up ports for your address. It's another to start rewriting packets, analyzing specific protocols so that you can alter them. Feel free to disagree with me on all except non-TCP/UDP breakage. I've had too many support calls on that one, and NAT-T isn't always available, and even when available, it's not necessarily configurable. Jack
On Feb 9, 2009, at 2:11 PM, Ricky Beam wrote:
On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk <stephen@sprunk.org> wrote:
Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate.
This is exactly the same with NAT and non-NAT -- making any anti-NAT arguments null.
And making the PRO-NAT arguments in this respect equally NULL. This was being touted as a benefit of NAT, not a reason not to do NAT. Your statement proves my point... It is NOT a reason to do NAT or a benefit derived from NAT.
In the case of NAT, the "helper" has to understand the protocol to know what traffic to map.
In the case of a stateful firewalling ("non-NAT"), the "helper" has to understand the protocol to know what traffic to allow.
Subtle difference, but in the end, the same thing... if your gateway doesn't know what you are doing, odds are it will interfere with it. In all cases, end-to-end transparency doesn't exist. (as has been the case for well over a decade.)
Right. This is the counterpoint to the argument that NAT is needed. You have now agreed that it is not. Owen
Ricky Beam wrote:
On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk <stephen@sprunk.org> wrote:
Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate.
This is exactly the same with NAT and non-NAT -- making any anti-NAT arguments null.
In the case of NAT, the "helper" has to understand the protocol to know what traffic to map.
In the case of a stateful firewalling ("non-NAT"), the "helper" has to understand the protocol to know what traffic to allow.
Subtle difference, but in the end, the same thing... if your gateway doesn't know what you are doing, odds are it will interfere with it. In all cases, end-to-end transparency doesn't exist. (as has been the case for well over a decade.)
Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled. This mangling can be a serious source of problems. With UDP, it can introduce checksum errors. With TCP, not only do you have possible checksum errors, you also have to mangle the sequence numbers in both directions if the length of the payload changes. The mangling will inherently break standard IPsec and other "shim" layers like HIP. And let's not forget that NAT makes widespread deployment of any L4 alternative to TCP and UDP (e.g. SCTP) virtually impossible, forcing every new transport or shim protocol to inefficiently ride on top of TCP or UDP... Some protocols, e.g. SIP/RTP, also work fine through a stateful firewall even without an ALG in most cases -- but not when you add in NAT. 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 10/02/2009, at 9:54 AM, Stephen Sprunk wrote:
Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled.
Sure, but at the end of the day a non-NAT firewall is just a special case of NAT firewall where the "inside" and "outside" addresses happen to be the same. If I was a commodity consumer hardware manufacturer, that's how I'd handle the IPv6 firewalling problem, because that'd let me pass non-NAT'ed v6 packets and NAT'ed v4 packets through the same code paths, thereby enabling me to avoid reinventing the entire wheel (and an entire new set of bugs) to do v6 firewalling. DSL/Cable CPE is already full of v4 ALGs, and it's reasonable to expect that the only difference between those and the equivalent v6 ALGs will be the lack of v6 NAT. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
On Feb 9, 2009, at 3:33 PM, Mark Newton wrote:
On 10/02/2009, at 9:54 AM, Stephen Sprunk wrote:
Yes, an ALG needs to understand the packet format to open pinholes -- but with NAT, it also needs to mangle the packets. A non-NAT firewall just examines the packets and then passes them on unmangled.
Sure, but at the end of the day a non-NAT firewall is just a special case of NAT firewall where the "inside" and "outside" addresses happen to be the same.
Uh, that's a pretty twisted view. I would say that NAT is a special additional capability of the firewall which mangles the address(es) in the packet. I would not regard passing the address unmangled as a "special case" of mangling. In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6. Owen
On 10/02/2009, at 10:17 AM, Owen DeLong wrote:
Sure, but at the end of the day a non-NAT firewall is just a special case of NAT firewall where the "inside" and "outside" addresses happen to be the same.
Uh, that's a pretty twisted view. I would say that NAT is a special additional capability of the firewall which mangles the address(es) in the packet. I would not regard passing the address unmangled as a "special case" of mangling.
You're passing a value judgement on NAT, using loaded terms like "mangling" and "twisted". Fine, you don't like rewriting L3 addresses and L4 port numbers. Yep, I get that. Relevance?
In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6.
There is if you have a dual-stack device, your L4-and-above protocols are the same under v4 and v6, and you don't want to reinvent the ALG wheel. - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
Mark Newton wrote:
Fine, you don't like rewriting L3 addresses and L4 port numbers. Yep, I get that. Relevance?
Just out of what I like and might use, GRE (no port), ESP (no port), AH (no port), SCTP (would probably work fine with NAT, but I haven't seen it supported yet and because every box doing address rewrites MUST understand the protocol to perform NAT, it's likely to be back shelved despite it's cool features. Without NAT, it can be treated like GRE, ESP, and AH by a firewall, though improved security if the firewall does understand the protocol). And my favorite, 6-to-4, broken.
There is if you have a dual-stack device, your L4-and-above protocols are the same under v4 and v6, and you don't want to reinvent the ALG wheel.
ALG only fixes some problems, and it's not required for as much when address translations are not being performed. In addition, the bugs caused from address rewrites (and there have been some really poor implementations at the cheap home router level) will naturally disappear (to be replaced with new bugs concerning ALG/uPNP I'm sure). Jack
On 10/02/2009, at 11:03 AM, Jack Bates wrote:
There is if you have a dual-stack device, your L4-and-above protocols are the same under v4 and v6, and you don't want to reinvent the ALG wheel.
ALG only fixes some problems, and it's not required for as much when address translations are not being performed.
On a commodity consumer CPE device, the ALG code doubles as a stateful inspection engine. So it _is_ required when address translations are not being performed. Is security something that gets thought about now, or post-deployment? - mark -- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Pty Ltd Desk: +61-8-82282999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
Mark Newton wrote:
On a commodity consumer CPE device, the ALG code doubles as a stateful inspection engine.
So it _is_ required when address translations are not being performed.
Hmmmm, the code may be there, but I suspect that not all of it will apply to v6 and be used.
Is security something that gets thought about now, or post-deployment?
I suspect that depends on who you ask. Security is always the top of my list. That being said, what security is there in removing NAT from v4 because it broke what the customer wanted to do? Then they are back to their host based stateful firewall; which apparently everyone believes is not good enough. Might as well throw in v6 and trash the NAT. Jack
Owen DeLong wrote:
In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6.
Unless your SOX auditor requires it in order to give you a non-qualified audit of your infrastructure. The real problem with IPv6 deployment is not that it can't be done, but that there are so many still-to-be-answered questions between here and there... Matthew Kaufman
In message <4990C38C.8060007@eeph.com>, Matthew Kaufman writes:
Owen DeLong wrote:
In terms of implementing the code, sure, the result is about the same, but, the key point here is that there really isn't a benefit to having that packet mangling code in IPv6.
Unless your SOX auditor requires it in order to give you a non-qualified audit of your infrastructure.
The SOX auditor ought to know better. Any auditor that requires NAT is incompenent.
The real problem with IPv6 deployment is not that it can't be done, but that there are so many still-to-be-answered questions between here and there...
And the only way to answer them is to go ahead and find the gaps. Waiting and waiting won't find the problems and will just put you under more time presure. Mark
Matthew Kaufman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Mon, 9 Feb 2009 21:16:49 -0500 "TJ" <trejrco@gmail.com> wrote:
The SOX auditor ought to know better. Any auditor that requires NAT is incompenent.
Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ...
SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX.........
-- John
John Peach wrote:
On Mon, 9 Feb 2009 21:16:49 -0500 "TJ" <trejrco@gmail.com> wrote:
The SOX auditor ought to know better. Any auditor that requires NAT is incompenent. Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ...
SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX.........
Not just SOX. I vaguely remember something in PCI about NAT. It wouldn't surprise me if every auditing thing involving computers said something about requiring NAT. See my earlier comment about NAT=firewall. ~Seth
The SOX auditor ought to know better. Any auditor that requires NAT is incompenent.
Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ...
SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX.........
Fair enough, but my point was that it isn't the auditors' faults in _all_ cases. When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do.
TJ wrote:
When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do.
I believe that RFC1918 space won't be a requirement for IPv6. I'm pretty sure the requirements will change as the addressing changes. Of course, I'm sure you will have a lot of NEW requirements. :) Jack
When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do.
I believe that RFC1918 space won't be a requirement for IPv6. I'm pretty sure the requirements will change as the addressing changes. Of course, I'm sure you will have a lot of NEW requirements. :)
But that is the problem - it doesn't say "You must use RFC1918 for IPv4" ... it just says "You must use RFC1918". Meaning, you must not run IPv6. And some regulations do not mention/address IPv6 at all. Silence != security.
In message <00df01c98b27$3181b7e0$948527a0$@com>, "TJ" writes:
The SOX auditor ought to know better. Any auditor that requires NAT is incompenent.
Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ...
SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX.........
Fair enough, but my point was that it isn't the auditors' faults in _all_ cases. When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do.
Please cite references. I can find plenty of firewall required references but I'm yet to find a NAT and/or RFC 1918 required. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
Mark Andrews wrote:
Please cite references.
I can find plenty of firewall required references but I'm yet to find a NAT and/or RFC 1918 required.
(Skip if you've participated in a SOX audit from the IT department POV) The way it works is that the law doesn't call for specific measures. The law calls for audits. Audits are done by outside firms (like "large accounting firms") using their internally-developed checklists for compliance. Passing the checklist gets you an unqualified audit. Failing a few items gets you a qualified audit. Failing more means you don't have the necessary audit document to present. The exact details of every line item are typically under non-disclosure when presented to the IT department for review, so for instance I can't post the ones from the last audit I participated in. Firms are also free to develop their own internal control guidelines, as long as they can convince the outside auditor that the controls are at least as strong as the ones on the checklist. Other regulations, like HIPPA, also require the same thing. For instance, the top Google hit for HIPPA and "private address space" links to a wustl.edu document regarding how their controls over HIPPA-protected information are implemented (including the use of private address space and the use of multiple layers of NAT). It takes a *lot* longer to get policies changed and auditors to sign off on the revised policies than it does to make a change in a router. That means that the process of updating policies should have started *even sooner* than the process of upgrading and reconfiguring routers for IPv6. But since there's still open questions (like the recent discussion of IPv6 NAT on the BEHAVE list) that have no answers at all, I can imagine why some folks might be putting off revising their policies and asking for external review of those. Matthew Kaufman
On Tue, Feb 10, 2009 at 02:16:10PM +1100, Mark Andrews wrote:
In message <00df01c98b27$3181b7e0$948527a0$@com>, "TJ" writes:
[...SOX auditor stuff...]
When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do.
Please cite references.
I can find plenty of firewall required references but I'm yet to find a NAT and/or RFC 1918 required.
It isn't SOX, but sadly enough, PCI DSS Requirement 1.5 says: Implement IP address masquerading to prevent internal addresses from being translated and revealed on the Internet. Use technologies that implement RFC 1918 address space, such as port address translation (PAT) or network address translation (NAT) I know that some auditors want to hold people to that standard. I stopped working with the credit card people at that point...
The SOX auditor ought to know better. Any auditor that requires NAT is incompenent.
Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ...
SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX.........
Fair enough, but my point was that it isn't the auditors' faults in _all_ cases. When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do.
Please cite references.
I can find plenty of firewall required references but I'm yet to find a NAT and/or RFC 1918 required.
Minor correction (I did say I wasn't sure it was SOX) ... It is PCI that requires RFC1918 and translation. For SOX, what is your assessment of (IPv6) internal controls and risk based on? Has anyone (with the authority to do so) developed and released guidance? Do we have a repository of "current best practices" to rely on (yet)? Interestingly, with SOX, I am curious if lack of IPv6 preparation will play into the risk assessment as well :). Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply tend to omit IPv6 completely, and generally require everything not explicitly called out to be disabled ... thus, no IPv6 on any network that falls under any of these regulations. We are just starting to see finalized product profiles and STIGs for IPv6 configuration - without that guidance Defense networks really couldn't <wink> run IPv6 either. (In other words (again, generally speaking) - if you run IPv6, your current C&A (or perhaps your CTO (Certificate To Operate)) is invalid).
On Feb 10, 2009, at 8:52 AM, TJ wrote:
Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply tend to omit IPv6 completely, and generally require everything not explicitly called out to be disabled ... thus, no IPv6 on any network that falls under any of these regulations.
TJ - You attempted to say that for PCI, and then it was shown that there's clear language regarding compensating controls that could easily be considered applicable. I haven't had the honor of running an IPv6-enabled system through a PCI compliance audit, but have little doubt that it will happen shortly and will require auditor education just like every other technology introduction. I run a data center which specializes in secure, compliant managed services, and have been through hundreds of audits in support of our clients which include federal civilian, federal defense, health care, and financial services firms. There are very few IT standards which have precise protocol or address requirements embedded in them, and there is almost always an opportunity to provide compensating controls where necessary. If you've got an example from one of the above compliance frameworks to the contrary that would actually preclude IPv6 deployment, please cite it.
(In other words (again, generally speaking) - if you run IPv6, your current C&A (or perhaps your CTO (Certificate To Operate)) is invalid).
Sure... change your network, and you need to update your C&A package as part of maintaining your ATO. It's up to your DAA as to whether they want to use IPv6 prior to equipment being certified under the DoD IPv6 Profile. /John John Curran EVP, COO, CTO ServerVault Corp
Current versions of the rest (HIPAA, GLBA, SOX, FIPS, etc.) simply tend to omit IPv6 completely, and generally require everything not explicitly called out to be disabled ... thus, no IPv6 on any network that falls under any of these regulations.
TJ - You attempted to say that for PCI, and then it was shown that there's clear language regarding compensating controls that could easily be considered applicable. I haven't had the honor of running an IPv6-enabled system through a PCI compliance audit, but have little doubt that it will happen shortly and will require auditor education just like every other technology introduction.
I run a data center which specializes in secure, compliant managed services, and have been through hundreds of audits in support of our clients which include federal civilian, federal defense, health care, and financial services firms. There are very few IT standards which have precise
First off - me neither; this is related to my realm, but not within it. Secondly - we largely agree; although I think the level of "auditor education" that will need to occur is more burdensome than might be expected - partially due to lack of underlying guidance. Again, I don't live and breathe compliance, but the best I have seen is that some have started developing these procedures/guidelines. Started. Additionally, I suspect (but do not know that) the compensating control clause is meant to be a special case ... I'd love to hear more ... protocol
or address requirements embedded in them, and there is almost always an opportunity to provide compensating controls where necessary. If you've got an example from one of the above compliance frameworks to the contrary that would actually preclude IPv6 deployment, please cite it.
(In other words (again, generally speaking) - if you run IPv6, your current C&A (or perhaps your CTO (Certificate To Operate)) is invalid).
Sure... change your network, and you need to update your C&A package as
Sure, general language meant to be semi-technology-independent. Perhaps not outright preclude deployment altogether, but certainly cause (possibly rather expensive) delays or complications. Note - I am merely pseudo-quoting from what auditors and policy people have told me and my colleagues, through the course of several briefings. Allow me to more directly quote one of my colleagues: * Current C&A auditors are not checking for IPv6-based vulnerabilities. They do not understand the process or have the tools to do IPv6 C&A. * IPv6 is already deployed in a surprising number of IT systems, networks, and software - we find it operating in audits of agencies and enterprises that are "not deploying IPv6" * Is your FISMA C&A complete/valid without considering IPv6? Note that the last bullet is a somewhat rhetorical question - the answer is obviously no, but you might be surprised to see the look on some peoples' faces when you tell them that ... Or let's take this - http://72.34.43.90/IPV6/usipv6_reston_2004/thu/Kruger-Schifalacqua.pdf ... and while the goal is to show that/how it is possible to obtain your ATO, I think it makes a strong case in the opposite direction. How can you be assured that you live up to "Do no harm" when the definition of harm, based on the (until very recently) absent standards upon which to make this basis? Or with a staff (local network or auditor) that is not IPv6 savvy at day -1 (meaning prior to the expected deployment of IPv6). (And in fact, after just re-reading it - this presentation seems to make a case for disabling DAD (albeit in a specific case) - something that violates the protocol spec as well as the DoD APL requirements ... so who wins that decision?) To take it a step further (and perhaps be over-simplsitic): The guidance to "disable all unused protocols and services" applies. So, if you aren't using IPv6 today it must be off. If you want to turn it on, you must redo your C&A. That costs money, therefore doesn't happen - atleast not "soon". Therefore, no IPv6. I would love to hear more from those who have done C&A (of any flavor) on an IPv6 enabled network - specifically, was IPv6 actually considered/evaluated and any problems it caused for the process. part
of maintaining your ATO. It's up to your DAA as to whether they want to use IPv6 prior to equipment being certified under the DoD IPv6 Profile.
But that is my point - Do any of the compliance frameworks / requirements / audit standards today address IPv6, or detail how it could be implemented in such a fashion as to 'pass' an audit (including the "in-house" / consultant-specific audit guidelines)? If it can be done, but is solely a "you and your (current) auditor figure it out, on a case by case basis, every time" I would argue that that is not good enough for the general case. And while I agree with you, "any change = redo" I would argue that not everyone realizes that all of their C&A work will need to be re-done in order to retain their CTOs/ATOs if they move forward with any sort of IPv6 deployment. I have heard the gasps (I didn't see the faces, that was a coworker of mine did and said it was amusing - in a sad way.) Thanks ... /TJ
On Feb 10, 2009, at 4:30 PM, TJ wrote:
But that is my point - Do any of the compliance frameworks / requirements / audit standards today address IPv6, or detail how it could be implemented in such a fashion as to 'pass' an audit (including the "in-house" / consultant-specific audit guidelines)? If it can be done, but is solely a "you and your (current) auditor figure it out, on a case by case basis, every time" I would argue that that is not good enough for the general case.
Compliance frameworks are generally technology agonistic. They tell you "have an information boundary for your system", "manage your user identifiers", etc. Aside from the DoD IA STIGs (and small handful of NIST areas such as encryption), you don't find specifications that particular protocols or technology is required. They don't require major updating for IPv6 because there's very little IPv4 specific contents in them already. That's not to say that moving an application to IPv6 is trivial from a compliance and security perspective, as you've still got a pile of mandatory firewall, load-balancing, and IDS infrastructure that needs to handle IPv6 correctly before you can get started. In organizations that are planning ahead, this is common security control infrastructure, and gets done once centrally rather than each little component.
And while I agree with you, "any change = redo" I would argue that not everyone realizes that all of their C&A work will need to be re-done in order to retain their CTOs/ATOs if they move forward with any sort of IPv6 deployment. I have heard the gasps (I didn't see the faces, that was a coworker of mine did and said it was amusing - in a sad way.)
Look, systems change. Change your database software, and you get to update the corresponding pieces of the C&A package. Add IPv6, you have to update the network portions. This shouldn't be a surprise to anyone, and it certainly doesn't mean "all of their C&A work will need to be re-done". /John
On Mon, Feb 09, 2009 at 09:27:59PM -0500, TJ wrote:
The SOX auditor ought to know better. Any auditor that requires NAT is incompenent.
Sadly, there are many audit REQUIREMENTS explicitly naming NAT and RFC1918 addressing ...
SOX auditors are incompetent. I've been asked about anti-virus software on UNIX servers and then asked to prove that they run UNIX.........
Fair enough, but my point was that it isn't the auditors' faults in _all_ cases. When the compliance explicitly requires something they are required to check for it, they don't have the option of ignoring or waving requirements ... and off the top of my head I don't recall if it is SOX that calls for RFC1918 explicitly but I know there are some that do.
Considering that RFC1918 says nothing about IPv at all, could that be a blocker for deployment in general? That'd also make for an interesting discussion re: other legacy protocols (IPX, anyone?)... - Matt -- I tend to think of "solution" as just a pretentious term for "thingy". Doing that word substitution in my head makes IT marketing literature somewhat more tolerable. -- lutchann, in http://lwn.net/Articles/124703/
On Tue, 10 Feb 2009 18:03:40 +1100, Matthew Palmer said:
Considering that RFC1918 says nothing about IPv at all, could that be a blocker for deployment in general? That'd also make for an interesting discussion re: other legacy protocols (IPX, anyone?)...
I was all set to call shenanigans on this one - except I double-checked the dates on the RFCs, and RFC1752 pre-dates 1918 by a year... Not sure what it says about our industry that both RFCs are 13+ years old now, and we still can't collectively do either one right...
Considering that RFC1918 says nothing about IPv at all,
That may technically be true, but it does explicitly reference IPv4 addresses. Oh, and when RFC1918 (or more correctly, RFC1597) was written, "IP", "TCP/IP", etc. all directly meant IPv4. (RFC1597 @ 03/94 ... RFC1883 @ 12/95)
On Mon, 9 Feb 2009, Ricky Beam wrote:
On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk <stephen@sprunk.org> wrote:
Non-NAT firewalls do have some appeal, because they don't need to mangle the packets, just passively observe them and open pinholes when appropriate.
This is exactly the same with NAT and non-NAT -- making any anti-NAT arguments null.
In the case of NAT, the "helper" has to understand the protocol to know what traffic to map.
In the case of a stateful firewalling ("non-NAT"), the "helper" has to understand the protocol to know what traffic to allow.
Subtle difference, but in the end, the same thing... if your gateway doesn't know what you are doing, odds are it will interfere with it. In all cases, end-to-end transparency doesn't exist. (as has been the case for well over a decade.)
You arguments making any pro-NAT arguments null. You agree, that NAT and Stateful Packet Inspetion firewall doing similar things. Advantage of the SPI firewall is that you have to maintain only one forwarding/state table. While in NAT you have to maintain two table. Therefore SPI firewall is more scalable.... Regards, Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
--Ricky
participants (18)
-
Frank Bulk - iName.com -
Jack Bates -
John Curran -
John Osmon -
John Peach -
Mark Andrews -
Mark Newton -
Matthew Kaufman -
Matthew Moyle-Croft -
Matthew Palmer -
Mohacsi Janos -
Owen DeLong -
Ricky Beam -
Roger Marquis -
Seth Mattinen -
Stephen Sprunk -
TJ -
Valdis.Kletnieks＠vt.edu