[arin-ppml] IPv6 Non-connected networks

[Chris Engel]

Owen DeLong wrote:

> On such a firewall, you would want software which specifies
> valid entry/exit interface combinations in addition to IP
> addresses which would also preclude the error you describe
> since the DMZ would be on a different interface than the
> internal network. So, again, NAT still doesn't actually do
> anything that you can't accomplish with good software and
> topology without NAT.

I don't really know what you are getting at here. Yes you could write a specific rule that Denys ALL IN to Private from External. We've already said that. You could write a rule that DENYs ALL IN to Private from ANY. You could even write a rule that Denys ALL IN to ANY from ANY. You could write 50 rules that all cover the same ground. It doesn't matter. The volume of rules that you write is irrelevant since they are all invalidated by an error in a single rule that that takes precedence over them and flubs scope or direction.

I don't know what sort of devices you've worked with but pretty much every firewall I've worked with impliments some sort of logic to determine what rules take precedence when they are in conflict. Sometimes these devices use logic that is IMPLICIT to determine precedence (i.e. more specific takes precedence over general, allow takes precedence over deny, etc), sometimes they impliment logic that lets the user configure precedence (rule weight 10 takes precedence over 20) sometimes it's a combination of the two. They all have their own quirks about how they work... but they all pretty much have some functionality to allow one rule to take precedence over X number of other rules. As long as that exists...it doesn't matter how many rules you write if the Admin flubs one that takes precedence. What you wrote doesn't change anything about the usage scenario I described.


> Furhtermore, your alleged "mail server" should live in the
> DMZ, like the web server.  The server should be reachable for
> IMAP/SMTP from inside. It should also be reachable for SMTP
> and possibly IMAP from outside. It should NOT have physical
> interfaces on the internal and external networks which would
> allow it to act as a router bypassing your firewall. In such
> a topology, there is, again, no gain from NAT.

No it would have an interface on the internal network only in this scenario. It would accept certain traffic (say SMTP) from the external interface and be hardened for such traffic as it was expecting it. It wouldn't "bypass" the firewall as all traffic going to it would still be getting filtered by the Firewall. It would certainly be a "point of attack"...just as e-mail on that server that goes to an end user is....but it would be a well anticipated and limited point of attack. However this is digressing from the main point of the discussion and entirely tangential...so not worth me spending too much more time on.


> Arguably the information store belongs in the DMZ rather than
> the inside, but, even if that is the case, NAT won't help you there.

One wonders if you are putting an organizations internal information stores and all the data they contain in the DMZ, what resources you actually believe you are protecting in the private zone.... but again this discussion is getting pretty far afield and is entirely tangential to the real issue.


> My point wasn't that this separation is absolute security. My
> point was that in a properly structured network, NAT doesn't
> improve security.

I'll concede that if no admin EVER makes ANY mistake in ANY aspect of configuring network security (including filter rules) then NAT would be largely unusefull for security. By that same token...If no one ever made ANY mistakes in the handling of a firearm, the safety would be an entirely superfluous device and would not be useful for safety either. However, I don't live in this perfect world that academics love to theorize on paper. I live in the real world where human beings make mistakes ALL the time. Network Admins do misconfigure security settings... and despite safeties, trigger locks and the many layers of rules regarding fire-arm safety (which I'm intimately familiar with as a life-long hunter and gun owner) that every fire-arm owner should be able to recite in his/her sleep people still get shot by accident. In the world I live in... safeties just like NAT ARE useful (albeit imperfect) controls in improving the security of the devices they are associated with.... specifically because people DO screw up and they provide some measure of safety net.



> I'd much rather fix the firewall software than break the
> internet, but, perhaps I'm the only one who things that
> problems should be resolved where they are broken rather than
> break something else instead.


I'd much rather have standards and policies that account for a wide variety of circumstances and situations, ones that exist in the real world for real people and give people the option to choose the ones that they believe best fit their situation rather then to try to shove everyone in one little box and say "this way or the highway".... but perhaps I'm the only one that things that there is room for people to make different and sometimes even incompatible choices.
Remember, one mans "broken" is another's "working as intended".

More to the point, NAT hardly breaks the "internet"... it breaks certain specific protocols when they try to go from some end points to certain other end-points. I never read the definition of a working internet that said it guarantied every single protocol would function from every single end point to every other single end point. For any organization that doesn't even guaranty the routability of the addresses they assign that seems like a pretty stringent standard to insist upon.



Christopher Engel