[arin-ppml] IPv6 Non-connected networks

[Owen DeLong]

On Mar 23, 2010, at 2:04 PM, Chris Engel wrote:

> 
> Owen Delong wrote:
> 
>> Sorry, I can't figure out what particular scenario is
>> envisioned in all the missing steps there...
> 
> 
> Owen,
> 
> Not trying to speak for Bill here...but I'll give you a simple common usage example of how NAT has value in protecting networks against misconfigurations.
> 
> Scenerio #1 Firewall with NAT deployed -
> 
> You have a private address space network (RFC 1918 space in IPv4) internaly. At the edge of it you have deployed a Firewall. You have a certain number of public addresses that you use to provide limited access to services (SMTP Server, Web Server, etc) to external users. On the Firewall you create a static mapping of each external address that provides an advertised service to the internal address of the device which provides it.
> 
> Now you also create filtering rules on the firewall to control what packets are allowed to pass through. Lets say your Firewall Admin, being human, screws up and misconfigures one rule. Instead of allowing HTTP incoming only to the Web Server (which presumably has been hardened
> to accept external traffic) he allows HTTP incoming to ALL. So now you have a potential disaster on your hands as your misconfigured filter allows HTTP traffic to EVERY device on your network....including possibly web applications that are in development and testing and haven't been hardened against misuse yet.
> 
Why on earth is your web server on the same network as your internal hosts to begin with? Machines which
do not belong in the same security zone shouldn't be on the same network any more than a box which
is not a security boundary device should have interfaces in multiple security zones.

Ideally, you would also want a different firewall either between the DMZ and your internal network or
between the external network and your internal network so that this can not occur.

> However here is where NAT comes in to help save your butt. You have no address mapping to any of those internal only devices on your firewalls EXTERNAL interface. So an external user has no way to address them. Even if that user was able to route a packet destined to an internal IP address to your Firewalls EXTERNAL interface.... that interface wouldn't pick it up...because as far as it's concerned no such IP address is bound to that interface. So the misconfigured rule still only results in external traffic to devices which are configured for external access.
> 
How is the firewall administrator less likely to misconfigure the address mapping than the rule? Perhaps I'm
confused, but, I would think that one mistake would not preclude the other. Especially when you consider the
scenario most likely in IPv6 NAT where it is more than likely we would at least abandon address overloading
in favor of 1:1 mappings for simple prefix rewriting.

> 
> Scenerio #2 Firewall no NAT -
> 
> You are using only public address space. You have a firewall deployed at your network boundary. It's in "Pass Through" configuration...meaning that it inspects each packet passing through it's interfaces and applies it's filtering rules. For anything that isn't restricted by those rules...it allows the packet through to it's destination address. Same mistake as above. Your all too human Firewall Admin has misconfigured the rule that filters inbound HTTP traffic. Instead of the just allowing it to the Web Server that is advertised for external access...he allows it through to ALL.
> 
Well, the default permit scenario you described is far more of a security issue than the lack of NAT. Why would anyone
configure their firewall that way?

> However, in this case there is no NAT, no "compensating control" to account for the single point of failure. An external user sends a packet destined for one of your "internal only" devices. In this case, since all devices use public address space...it's entirely addressable to that external user. The firewalls external interface picks up the packet... see's that it's allowed by the filtering rules...and passes it through to the destination address. Just as it thinks it's supposed to.
> 
More than likely even if there is NAT, the following configuration

NAT  External: 2001:db8:4f00::/48 Internal: 2001:db8:9200::/48 1:1

Would exist in IPv6, so, even if you got NAT, you most likely lose that.  However, I think your erstwhile firewall
admin is not significantly less likely to target the rule at the wrong host/host group than to target the mapping
in the identical incorrect way, so, I'm not convinced this is much in the way of security.

> Note in both cases Statefull Inspection is present....It's just been made completely irrelevent as the Admin has misconfigured the rule which would use it to block unwanted traffic. In scenerio #1 end result is that the traffic gets blocked anyways (fails closed), in scenerio #2 it gets through (fails open).
> 
Yes, in both cases, the admin can circumvent the stateful inspection either through willful or accidental
misconfiguration. I think this will remain true in both cases. It also remains true that a firearm, whether
a .22, or a shotgun can be used to inflict injury to one's own foot. I'm also opposed to gun control and
believe that the second amendment is an important protection even if we have at this point neutered
it such that it is unlikely to remain actually effective for its original intent.

> Am I wrong?
> 
You're not entirely wrong, but, I think you overestimate the value and underestimate the cost of this
alleged benefit, especially in the most likely IPv6 scenario where address availability would render
1:many NAT unlikely.

Owen