John Payne wrote: > > On Nov 2, 2009, at 5:01 PM, Keith Moore wrote: > >> Chris Engel wrote: >>> Keith, >>> >>> Whether NAT is a useful discriminator or NOT is rather irrelevant >>> (though I happen to find it a useful one).... the point is the >>> Network Administrator and company security policy IS a useful >>> security discriminator in determining what applications are valuable >>> or not...and THEY can determine whether the benefits of NAT outweigh >>> the costs. >> Actually, I disagree. In my experience (at least for networks that >> serve a significantly sized population of users) such people are >> usually quite ignorant of both the diversity of needs of their users, >> and the true impact of NAT on their networks in terms of the range of >> the applications that NATs deny to users; and are therefore unable to >> make a realistic estimate of the costs. > > And the business has made a business decision to act that way, and I > strongly do not believe it's your job to decide that it's a dangerous > tool and take it away from them. Nobody's talking about taking anything away from anybody. We don't have any mechanism by which to do that.
But at the same time, just because a bunch of network administrators have made decisions that are extremely detrimental to the ability of networks (and not just their networks) to support applications, does not mean that IETF should pretend that what they're doing is not a problem. IETF's job is to make sound technical recommendations, not to reinforce other people's preconceptions. >>> NO ONE is arguing that NAT is a useful tool for EVERY network. I'm >>> glad that there will be more alternatives available under IPv6 for >>> people to use. However, that does NOT mean that for many of the >>> people who currently use it that NAT is not currently useful and >>> would not be so in future regardless of the other options available. >>> Just because person X in thier situation finds a particular tool >>> more harmful then helpful is NOT a good arguement for denying the >>> tools use to EVERYONE. >> The same could be said of applications whose functions are impaired by >> NAT. e.g. Just because a network administrator thinks that such >> applications are more harmful than helpful is NOT a good reason for >> denying the use of those applications to EVERYONE on that network. > > Actually, yes it is. If the network administrator has decided that > something shouldn't be on the network, there is _NO_ better reason for > denying the use of those applications to EVERYONE on that network. You appear to be talking about authority. I'm talking about wisdom. >> >> Perhaps unfortunately, nobody has figured out a way to prevent NATs >> from being used in IPv6. But the ONLY significant benefit of NAT in >> the IPv4 world is associated with their use to conserve precious >> address space, and even that comes with significant pain. The other >> benefits are corner cases that apply only to very specific situations. > > Cite? > I think it was Brian Carpenter who mentioned the use of NAT for > enterprise multihoming (dozens of interconnects to the public > Internet). That is a HUGE benefit.... and one that I believe also has > security implications - by "allowing" or "blessing" NAT at the > enterprise exit points, the internal filters become much simpler, > rather than having to track dozens or hundreds of prefixes in the > internal network, one can use one prefix internally and NAT out the > local Internet exit point, without having to size each and every one > of those to support the entire enterprise. Mumble. This is a very complex topic. IPv4 and IPv6 are different enough in this respect that they need to be analyzed separately. In the IPv4 world, very few large organizations have enough IPv4 address space to give a unique global address to each of their hosts. So it's easy for them to say "heck, we already have to use NAT because of address scarcity, we've already bought into this approach and accepted the collateral damage. We might as well use it for this too." Also, I've never thought that having IPv6 networks advertise a separate prefix for each exit point made good sense. It might work well enough for a network having only two or three exit points, all of which are equally capable, but it doesn't scale. My take is that the IPv6 designers were so intent on solving the routing scaling problem that, probably without realizing it, they created several other problems for other aspects of the network that were no easier to solve. I haven't followed recent work in the area of IPv6 multihoming, so I don't know the current state of thinking there. But I hope that they solve the problem in a way that doesn't confuse applications. Or at least, that they give applications a good way to not be confused. >>> Let the people who find the tool useful CHOOSE to use it (and live >>> with the consequences of that choice) and those who don't, don't. >> The problem is, the people who are choosing to install NATs are not >> the ones dealing with the consequences of that choice. > > In the enterprise world, they absolutely are. I really don't care > what application of yours I break on my network. Sorry. So why should application developers, or your users, care if they circumvent your network's security? I mean, they have to get work done in spite of your network administrators. It bears repeating: the result of putting NATs into the network is that applications need to be more complex in order to cope with the enviroments in which they're expected to function. They also tend to need explicit infrastructure (e.g. servers in the network core to do rendezvous or relay) which they might not otherwise need. What this means is that applications are more expensive and more fragile than they would otherwise be, and this in turn limits the availability of applications to users. It also increases the expense of managing networks, if for no other reason than the support costs. Network admins arguing for their "right" to install NATs are missing the point. What they're arguing for is the right to make their networks less flexible and less able to support users' needs for reasons that have nothing to do with policy. Keith _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
