Chris Engel wrote: > However, I personally don't see alot of difference between the statements > "NAT is bad because it has the capability to break many > protocols/applications" and "Packet Filtering is bad because it has the > capability to break many protocols/applications". One difference is granularity.
If you just firewall your network, you can always change the configuration to support new apps or special-purpose hosts as needed. On the other hand, if you NAT your whole network - assign private or ULIA addresses to be used internally and translate at the borders - you are stuck with NAT. Chances are good that you can't turn off the NAT, even for specific hosts or ports, without renumbering your whole network. (Okay, you might be able to set up a tunnel through your NATted network that forwards traffic for a specific global address to a specific host behind your NAT, but that gets tedious if you need to do it for many hosts.) So when if you find that you have good reason to support an application or appliance that doesn't work with NAT, you won't be able to do that without significant disruption. This is why firewalls are better for implementing security policy than NATs. A firewall gives you a lot more flexibility to implement the policy you want, and to change it when you need to change it. NATting everything just gets in the way. The distinction between policy and implementation is key. Nobody is trying to say that a network operator should not be able to implement a policy that, say, prevents all externally originated traffic from reaching one of his internal hosts. At the same time, it's probably not a good idea to "carve that policy in stone", so to speak, by relying on private addressing, and/or investing in lots of hardware that is designed to NAT but makes a poor firewall. > > The bottom line is that there should be NO EXPECTATION that every > application/protocol has connectivity from EVERY end point TO EVERY end point > on the NET. In fact, wasn't part of the original DARPA specification that the > NET remain significantly useful even in the face of massive disruption to it, > with whole sections of nodes dropping out? No. The intent was that the network would make a "best effort" to route traffic to its specified destination even in the event of failure of routers or communications links. These days I think we'd say that the network's job is to make a best effort to route all traffic _that is permitted by policy_ to its specified destination. > Once you put your packets across some-one else's network boundary, you > shouldn't assume a mandate that they MUST be delivered. It's the CHOICE of > the person who's boundary you are trying to cross into to determine what to > do with them. > > That NAT CAN (and even DOES) do harm. Sure I'll buy that. However the exact > same thing can be said of firewall rules. It's failure to acknowledge the > counter-argument that seems problematic.... NAT (just like FW rules) CAN (and > even DOES) do benefit as well. When firewall policy does harm, it's presumably intentional. If the firewall breaks an app, the app is broken because it's supposed to be broken. (Of course there are ways in which some firewalls break apps that have nothing to do with policy, e.g. by breaking SMTP extension negotiation. I'm assuming a well-written firewall here.) When NAT does harm, it's often an "accident", or "collateral damage". NATs interfere with applications that are _supposed_ or _expected_ to work. Remember that the vast majority of NAT boxes today aren't branded as NATs - the typical user has no idea that the box is screwing with IP addresses or even what that means. The boxes are typically marketed as "routers" that support "connection sharing". Consequently, application developers quite reasonably interpret NATs as damage and try to route around them (which incurs extra expense, raises cost, lowers reliability, maybe forces changes to the funding model, etc.) > I guess the difference that I've seen argued is that with FW rules you CAN > open them up where appropriate to let traffic through. However I don't see > NAT being any different then that under IPv6...you CAN choose not to deploy > it if the situation warrants or impliment a workaround where neccesary. It's > up to you individually to judge what's most appropriate for your environment. > There is a far cry between having a REQUIREMENT that you deploy in my mind > and having the OPTION that you deploy. Again, it's an issue of granularity and flexibility. If you're just enabling NAT for one host at a time, so that you can change the mappings between external addresses and internal hardware, that's no big deal. You're not breaking the ability to support apps on all of your hosts just for the sake of wanting to NAT a few hosts. But if you're NATting all of your hosts and using private addresses internally, you can't easily change your policy to allow an application that is incompatible with NAT. Though it begs the question: which is more difficult to change - network hardware that implements NAT, or people's ways of thinking about NAT?
_______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
