To be or NAT to be?
Network address translation (NAT) technology has been critical to the growth of IP networking over the past decade. NAT allows organizations to create large, well-organized IP numbering systems behind their firewalls, despite a dearth of available public IP addresses. The limited number of public IP addresses that the organization possesses can then be used only for public servers and/or active IP sessions with the outside world.
In addition to allowing companies to conserve their public IP address supply, NAT also shields working internal IP-addressing structure from prying eyes. That's an important security measure when you consider how useful IP numbers can be to hackers.
NAT can also present a variety of technology implementation problems. These problems typically have to do with the disparity between real, working internal addresses and those visible to the outside world.
Voice over Internet protocol (VoIP), Microsoft's NetMeeting and other streaming media applications provide the prime example. Say a user behind the firewall wants to establish a session with an outside party. First, the insider and outsider communicate with each other to confirm the fact that they want to set up a session. Unfortunately, because of the way such applications work, the message that the internal user sends out for setting up the session with the outsider provides only the user's working internal IP address.
That piece of information can't be accessed or translated by the NAT firewall on its way out, because it's ensconced within the packet payload itself. Therefore, when the outsider's router tries to establish the session, it searches in vain for that internal address--which it can't find, since the only addresses visible to the outside world from the originating site are its public ones. So, the outsider's router gets frustrated and aborts the call.
One historical solution has been to place VoIP gateways and NetMeeting servers outside the firewall. While this eliminates the problem with NAT, it creates a variety of security issues that make many managers uncomfortable.
A safer solution would be to employ techniques within the application that would execute network address translation in the presession messaging itself. This way, the server or gateway could sit behind the firewall where it's safest, while the outside party's router could be given an IP address that it could actually find.
This isn't, however, a capability that's available with many such applications. Developers generally assume that a user's IP address is a user's IP address. NAT firewalls can shield most applications from the fact that there is some network sleight-of-hand taking place, but in the case of streaming UDP-based applications, they fail to do so.
The issue of NAT interoperability is another case-in-point that illustrates the same type of schism between developers and networkers that we examined last month. In this case, however, it also points up other potential territorial conflicts in technology organizations--such as that between network technicians and IT security teams.
What's particularly interesting at this point in the history of IT is that technology organizations are actually becoming more compartmentalized, even as project success becomes increasingly dependent on cross-disciplinary execution. This growing compartmentalization is occurring because each IT subdiscipline--networking, server management, storage architectures, security--is becoming more complex. That requires more specialized, dedicated teams to handle them.
The danger, of course, is that these teams will become so focused on their specific technology objectives that they will lose the larger perspective of the IT team as a whole and the organization that they serve. Territorial disputes and frustration with the headaches that one team's technology causes another's will lead to fragmented, inefficient practices. These inefficiencies will continue to make technologists look bad in the eyes of CEOs, CFOs and the rest of upper management.
In fact, overcompartmentalization also paves the way for outsourcing. After all, if your internal teams can't get along, you might as well turn over their functions to an outside contractor. That way, if one team doesn't get along with another, you just show them the door. It's certainly easier to discontinue a contract with a supplier than it is to fire all of your system administrators or LAN managers.
NAT is a great technology; but, if the people managing NAT can't see past their firewall--and if developers don't even know NAT exists--then it can be as much of a stumbling block as an enabler. The same is true of any other technology. It has to interoperate with the rest of the environment. And, interoperability, it turns out, is as much about people as it is about engineering. Network managers better keep that in mind if they don't want to find their jobs farmed out to a managed services provider.
Comments for publication should be sent to email@example.com.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||network address translation|
|Comment:||To be or NAT to be?(network address translation)|
|Date:||Sep 1, 2001|
|Previous Article:||Customization through a team approach.|
|Next Article:||A world changed.|