[arin-ppml] IPv6 Non-connected networks

[Chris Engel]

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.

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.


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.

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.

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).

Am I wrong?



Christopher Engel