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 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
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
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
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
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
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:
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
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:
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
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
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
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
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
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 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 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
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
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