On Friday, November 06, 2009 6:37 PM, Brian E Carpenter wrote: "We worked as hard as we could to make the list complete.Can you identify exactly which benefits of NAT are not mentioned in section 2 of the document?"
On Mon 11/9/2009 7:27 AM, Eric Klein wrote: "As one of the co-authors of RFC 4864 I would be interested if you could itemize that you mean by:" Eric & Brian, I was under the impression that I had done just that with my origional post to the list. Let me provide the relavent excerpt. It contains 2 very specific examples (there are more areas, but these 2 really stand out). 1) NAT allows a firewall to "fail closed" rather then "fail open" when there is a miscofiguration of rules. 2) NAT serves to abstract internal hardware that provides services from the external advertisement of those services. Making it very easy and flexible to distribute and redistribute the provision of those services among your internal hardware. --------------------------------------- Let me illustrate with a simple hypothetical example of NAT's utility in this area. Let us assume that an administrator had intended to block all HTTP traffic INBOUND (save for some static servers) and allow all OUTBOUND. In practice, this is a very common rule. It is trivially easy on many firewalls for said administrator to mistakenly open up the firewall to all INBOUND and OUTBOUND HTTP traffic instead. In practice, this is actually one of the more common (and potentially dangerous) misconfigurations that we see in the field. In the NAT scenario, the private network is still largely protected against such a failure. Most devices inside the firewall would have private addresses and not be statically mapped to any external IP.....thus INBOUND HTTP requests would have no way of addressing or reaching them to initiate communications. The only machines exposed under such a scenario would be those few devices that had static 1:1 NAT mappings. However, the entire reason to provid e a device with a static 1:1 mapping is that one would be expecting some sort of INBOUND connectivity to it.... thus those machines are highly likely to be hardened against such traffic (at least far more so then the ENTIRETY of the infrastructure behind the FW would be). Without NAT in such a scenario and with all devices behind the FW provided with a public address (as would generally be presumed in IPv6). EVERY SINGLE DEVICE becomes publicly exposed to HTTP traffic.... all from one very simple and common mistake. Thus every device capable of responding to HTTP would have to be hardened (at all times) to the same degree that servers expected to recieve external traffic are. I hope this example serves to illustrate SOME of the utility of NAT from a security perspective. Another very important utility of NAT that I did not see addressed at all in RFC 4864 is to abstract the internal hardware that provides a given external service from the connection information provided externally for that service. As an Application Service Provider this is a pretty darn important consideration. Let me illustrate what I mean. If I am providing a particular service that external users connect to on IP x.x.23.46:80 and I want to substitute either permanently or temporarily the internal hardware that provides said service.... with a 1:1 NAT mapping on the firewall ALL I need do is bring that new internal hardware up in parallel on it's own internal IP's and then when I am ready cycle the active connections to that IP on the firewall and change the NAT mappings to it. This affords me great utility as I am allowed precise control over the exact timing which this operation occurs and it can be implemented with very little time and effort. All my internal applicatio ns still correctly identify the internal hardware distinctly.... yet the entire operation is obfuscated from external users....nothing need change about their connection information....and they may not even realize that a change in the internal hardware providing the service has occurred. Going even a step further I can provide a related service on x.x.23.46:25 and use entirely separate internal hardware to provide it, and I can replace the hardware that provides said services independant of those on port 80. Yet to the external user...everything looks like it is provided from the same physical address. NAT allows this to be done simply, efficiently and with minimal effort. Other solutions would either not be possible at all...or would be far less efficient to enact. These two examples provide just a few of the practical benefits of NAT. Benefits that would transcend issues specific to IPv4. I could go on with others, but this post is already lengthy enough. I hope it has served to illustrate what I believe to be the continuing importance of NAT to administrators...even in an IPv6 environment. I thank you for your attention....and hope this choice of venue was the appropriate one for raising these issues. --------------------------------------- To this I might add a third...thougn not technical in nature still pretty darn important... It's listed as a REQUIREMENT in order to be compliant with PCI DSS v1.2 "PCI-DSS v1.2 Requirement 1.3.8 - "Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies-for example, port address translation (PAT)." It seems that the prime arguements against NAT are... 1) That it breaks certain applications/protocols.... but if the orginization that is deploying NAT has no need or desire to allow those particular applications/protocols to traverse thier network boundary anyways, I fail to see the harm being done there. 2) That when the device implimenting it runs out of resources it aborts user sessions.... but I fail to see how this is any different then any device in the chain of services running out of resources and breaking functionality of a user transaction. Certainly if my web or database server gets overloaded and can't respond to a user request quickly enough.... they will get a time-out error. Christopher Engel _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
