Sander Steffann wrote:
Hi,
In fact, and call me crazy, but I can't help but wonder how many enterprises out there will see IPv6 and its concept of "real IPs for all machines, internal and external!" and respond with "Hell No."
Anyone got any numbers for that? I'm happy to admit I don't. :)
No numbers, but the customers I talked to usually have the feeling that public IP addresses on their machines seems to imply publicly (and thus unprotected) reachability for those machines. They don't understand the difference between NAT and stateful firewalls...
This is what leads to the "Hell No" attitude in my case. Educating them about security seems the only solution.
I think that rather than attempting to educate their customers about security firewall vendors will probably just sell a NAT capable IPv6 firewall. It's the path of least resistance to profit. (A lot of mainstream vendors have helped push the idea that NAT is synonymous with firewalling. Take the Cisco PIX as an example, where up until very recently you had to configure NAT to allow traffic through the device.) Even people I have spoken that understand the difference between firewalling/reachability and NATing are still in favour of NAT. The argument basically goes "Yes, I understand that have a public address does not neccessarily mean being publically reachable. But having a private address means that [inbound] public reachability is simply not possible without explicit configuration to enable it". i.e. NAT is seen as a extra layer of security. I want NAT to die but I think it won't. S
Even people I have spoken that understand the difference between firewalling/reachability and NATing are still in favour of NAT. The argument basically goes "Yes, I understand that have a public address does not neccessarily mean being publically reachable. But having a private address means that [inbound] public reachability is simply not possible without explicit configuration to enable it". i.e. NAT is seen as a extra layer of security.
I want NAT to die but I think it won't. Far too many "security" folks are dictating actual implementation details and that's fundamentally wrong.
A security policy should read "no external access to the network" and it should be up to the network/firewall folks to determine how best to make that happen. Unfortunately many security policies go so far as to explicitly require NAT. -Don
On 4-jun-2007, at 17:37, Donald Stahl wrote:
I want NAT to die but I think it won't.
Far too many "security" folks are dictating actual implementation details and that's fundamentally wrong.
A security policy should read "no external access to the network" and it should be up to the network/firewall folks to determine how best to make that happen. Unfortunately many security policies go so far as to explicitly require NAT.
Don't forget that the reason NAT works to the degree that it does today is because of all the workarounds in applications or protocol- specific workarounds in the NATs (ALGs). In IPv6, you don't have any of this stuff, so IPv6 NAT gets you nowhere fast with any protocol that does more than something HTTP-like. (Yes, I've tried it.) If people want to have their boxes on unroutable IPv6 space, my advice would be to forget NAT and do proxying instead. Proxying also has the advantage that doesn't care about the difference between IPv4 and IPv6, a dual stack proxy gives you access to both. Obviously proxying doesn't work for certain classes of applications, but I should hope that's the point. If you want to be on private address space and still enjoy a good deal of (peer-to-peer) connectivity (= NAT), PLEASE do yourself and the people you want to communicate with a favor and stay in IPv4.
On Mon, Jun 04, 2007, Iljitsch van Beijnum wrote:
On 4-jun-2007, at 17:37, Donald Stahl wrote:
I want NAT to die but I think it won't.
Far too many "security" folks are dictating actual implementation details and that's fundamentally wrong.
A security policy should read "no external access to the network" and it should be up to the network/firewall folks to determine how best to make that happen. Unfortunately many security policies go so far as to explicitly require NAT.
Don't forget that the reason NAT works to the degree that it does today is because of all the workarounds in applications or protocol- specific workarounds in the NATs (ALGs). In IPv6, you don't have any of this stuff, so IPv6 NAT gets you nowhere fast with any protocol that does more than something HTTP-like. (Yes, I've tried it.)
Won't stateful firewalls have similar issues? Ie, if you craft a stateful firewall to allow an office to have real IPv6 addresses but not to allow arbitrary connections in/out (ie, the "stateful" bit), won't said stateful require protocol tracking modules with similar (but not -as-) complexity to the existing NAT modules? Adrian
Won't stateful firewalls have similar issues? Ie, if you craft a stateful firewall to allow an office to have real IPv6 addresses but not to allow arbitrary connections in/out (ie, the "stateful" bit), won't said stateful require protocol tracking modules with similar (but not -as-) complexity to the existing NAT modules? It's a lot easier to write a firewall module that monitors a SIP connection to allow for bi-directional traffic than it is to monitor for such connections and rewrite the packets.
Not to mention- what happens when the SIP traffic (for example) goes out with 1918 addresses in the packets? The firewall never sees the return traffic because the destination system is trying to send traffic to a private address- it gets lost in the ether and troubleshooting becomes a pain. With real addresses in the packets the traffic will at least make it back to the firewall- even if the firewall doesn't know how to handle them. At that point you know what's happening and can either correct the rules, enable a proxy, or yell at your firewall vendor. -Don
On Mon, Jun 04, 2007, Donald Stahl wrote:
Won't stateful firewalls have similar issues? Ie, if you craft a stateful firewall to allow an office to have real IPv6 addresses but not to allow arbitrary connections in/out (ie, the "stateful" bit), won't said stateful require protocol tracking modules with similar (but not -as-) complexity to the existing NAT modules?
It's a lot easier to write a firewall module that monitors a SIP connection to allow for bi-directional traffic than it is to monitor for such connections and rewrite the packets.
Yes yes, people have pointed this out already.
Not to mention- what happens when the SIP traffic (for example) goes out with 1918 addresses in the packets? The firewall never sees the return traffic because the destination system is trying to send traffic to a private address- it gets lost in the ether and troubleshooting becomes a pain. With real addresses in the packets the traffic will at least make it back to the firewall- even if the firewall doesn't know how to handle them. At that point you know what's happening and can either correct the rules, enable a proxy, or yell at your firewall vendor.
And its still not "as simple as tracking connections" stateful firewall. You still need to stick your grubby fingers into (this example) the SIP handshake and add in related rules for the RTP session to occur. There's still similar room for screwing up in the firewall implementation. There's still similar angst possible with broken stateful protocol tracking. Anyway, this is the last post from me on this topic. Time's going to tell whether vendors implement IPv6 NAT; since their featuresets are customer driven, not nanog@ driven. :) Adrian
On 5-jun-2007, at 4:29, Adrian Chadd wrote:
Don't forget that the reason NAT works to the degree that it does today is because of all the workarounds in applications or protocol- specific workarounds in the NATs (ALGs). In IPv6, you don't have any of this stuff, so IPv6 NAT gets you nowhere fast with any protocol that does more than something HTTP-like. (Yes, I've tried it.)
Won't stateful firewalls have similar issues? Ie, if you craft a stateful firewall to allow an office to have real IPv6 addresses but not to allow arbitrary connections in/out (ie, the "stateful" bit), won't said stateful require protocol tracking modules with similar (but not -as-) complexity to the existing NAT modules?
I'm afraid so, yes. http://arstechnica.com/articles/paedia/ipv6-firewall-mixed-blessing.ars
participants (4)
-
Adrian Chadd -
Donald Stahl -
Iljitsch van Beijnum -
Sam Stickland