Hello, Forgive me if I am entering late into the discussion here...but I was referred to the IETF mailing lists by individuals from a discussion that was occurring in the ARIN mailing lists.
The NAT66 list in IETF seemed to me to be the most relevant place to raise my concerns. Please forgive me if this is not the proper venue to raise such issues...as this is my first participation with IETF mailing lists. First, by way of introduction...I'm a Network Manager in charge of operations at a small ASP. My responsibilities include management of both the corporate network infrastructure and the infrastructure of the environment where the application services my company provides to it's clients is hosted. As such, I find NAT an EXTREMELY useful tool under IPv4 and would expect it to remain so under IPv6. In fact, were some sort of NAT solution not available under IPv6, my company would likely eschew any implementation of IPv6 to whatever degree would be possible. I do NOT feel that RFC 4864 adequately addresses the utility of NAT.... nor adequately provides a acceptable substitutes for it. That NAT proves problematic for some (mainly peer to peer) applications is undeniable. However for many of the people who make widespread use of NAT that is also largely irrelevant. In fact, I might even hazard that NAT's tendency to break such application are actually seen as a side benefit of NAT by many of the administrators who utilize it... and not a determent. I'm sure that my standard base FW rule of DENY ALL IN, which is pretty standard fare at corporate network boundaries, would prove similarly problematic to most such applications. The very fact that NAT abstracts the private network from the public and makes it difficult for external traffic to address or reach an internal device without a 1:1 mapping IS part of the utility that NAT offers. This may indeed prove problematic for certain applications... but in a way similar to a right-handed golf club proving problematic to a left-handed user. The answer to this is simple, like golf-clubs, not ALL technologies are equally suited to all circumstances.... however with a variety of technologies available individuals are able to make a CHOICE of using those which ARE well suited to their particular circumstances (just as with golf clubs)... which is why NAT should continue to be useful in an IPv6 environment. In section 2.2. of RFC 4864 "Simple Security Due to Tasteful Filter Implementation" the authors contend that NAT's utility for Security is not particularly compelling because it incomplete and can be bypassed through techniques such as Trojans.... and that filtering via a FW offers a more robust solution. Respectfully, it's difficult for me to fathom that anyone well versed in security would find these arguments compelling. Those of us who have worked in security are well aware that there is no one "magic bullet" to address all security issues. It is well known that they key to providing robust security is a MULTI-LAYERED DEFENSE that utilizes multiple controls over multiple layers to reduce the chances that a SINGLE point of failure will result in a breach. Even under such a design we realize that such security is not bullet-proof, just makes it require greater resources to breach. Thus claiming that NAT is not a useful security tool because their are methods that can circumvent it is like claiming that firewalls are not useful either simply because they can't prevent an intruder from physically breaking into your server room and walking out with a hard drive. NAT (like filtering done by a firewall) is simply one useful control among the many that are employed to protect an environment. Furthermore, I don't believe that anyone seriously suggests that NAT in itself is an adequate substitute for firewalls entirely. The utility of NAT lies in CONJUNCTION with the use of firewalls to do filtering and statefull inspection. NAT acts as a partial insurance policy against firewall misconfigurations. Security controls are designed and implemented by human beings...as such they are prone to flaw both in design and in implementation. It is realization of this axiom that allows those charged with security to be effective in the execution of their duties. In the lab is perfectly fine to say that a well configured set of firewall rules renders much of NAT's security functionality superfluous... in the real world, we realize and try to account for the fact that individuals can (and eventually are bound to) make mistakes configuring such rules. NAT adds partial protection against this reality. 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. Christopher Engel _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
