Network Computingwww.networkcomputing.com

		our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at www.networkcomputing.com /express/

Four steps are involved in implementing a VPN. The first is selecting the security technology that will make the network private. Next is developing the discipline to manage the privacy tunnels. Then the addressing and routing issues within each network in the VPN must be rationalized. Finally, DNS methodologies to support the actual use of the VPN must be developed. All of the work has been focused on the first step--its seeming vastness has dwarfed the other three. Now that we've come out on the other side of that tunnel (pun intended), we can see that it was the easiest part of the process.

The routing problem turns out to be the real showstopper. As one of the authors of RFC 1918 (Address Allocation for Private Internets), I knew that breaking up the Internet into poorly connected networks--where packets will not move from one area to another without major changes like NAT (Network Address Translation)--would make for serious routing fragmentation. This fragmentation has a detrimental impact on the ability for one part of the VPN to route packets from another part that could be using the same addressing range. Even in cases where global routable addresses are used, the VPN tunnel end point may not be the normal route path for packets that need to return through the tunnel. After struggling with this problem space for six months, I am starting to find IPv6 attractive.

Have you ever worked through the configuration of a corporate DNS for an external service? If that service is not HTTP based (that is, "proxyable" via a proxy client configuration file) and not accessed through a default gateway, the DNS work can be challenging enough to cross your eyes, because somehow, the user's workstation must receive a response to a DNS query that co ntains an address that your corporate network can use. The solutions are few; you can use manual configuration along with NAT (route control) or DNS address translation with NAT. In either case, long hours are involved. Yes, IPv6 is looking better everyday--especially because its multiple address support can make it fairly easy to support the public DNS alongside any tricks that are needed inside your company.

Payment Due Corporate America approached the Internet with understandable trepidation. The Internet's power to facilitate sharing was severely offset by the risks inherent in the Internet's openness. The IETF's early efforts identified three key items that prompted us to hide behind the complex routing, naming and security moats we call firewalls--the lack of abundant addresses, controlled access and secure communications, and non-spoofable naming. The IETF recognized these limitations and spent nearly three years agonizing on the best technical solution. The effort resulted in the IPv6 spec ifications, but pressures have diminished this work. The business community has failed to convey a sense of urgency for IPv6, opting instead for quick fixes.

It takes time to build a protocol suite, even when it is linearly derived from an existing one. Engineers have taken their time building this protocol suite--so much, in fact, that many of us didn't even realize we needed it. Instead, we opted to create private address ranges, routable domains and DNS trees. Then we slapped up firewalls to isolate everything. We have continually added complexity to both our corporate borders and our applications to support this choice--and every step has increased the support requirements. Now we have to live with this balkanized network to get VPNs working. Have I mentioned that IPv6 is becoming really attractive?

Time for the Next Generation IPv6 was the outgrowth of the IP Next Generation workgroup of the IETF. Many of us feel that its members could have been more far-reaching in their technology, but I' ll take what they're offering. The lure of lots of routable addresses and many addresses for single interfaces is attractive. NAT has never been easy. It imposes a gateway mentality, making redundant connectivity harder. Of course, we will lose the ability to easily rattle off an address or three, but maybe that's a good thing. We should forget about the address of the device and, instead, turn our attention to its name.

IPv6 mandates the inclusion of IPSec and Oakley/ISAKMP (this is a packet-level security protocol and a protocol for negotiating security keys) by all stack vendors. In IPv6 products, this is rudimentary at best because IPSec is still evolving. But most of the IPSec participants recognize that host-level IPSec is inherently sounder than gateway-level IPSec; the trust model is more clearly delineated, and routing and naming need not be kludged together, which is what we do today.

Clearly, this is the way to go. It holds true to the Internet model of keeping the complexity at the end point s instead of within the network. Complexity within the network is difficult to scale, let alone keep working. But complexity at the end points can be upgraded on a case-by-case basis, though it can be challenging to manage.

Interestingly, IPv6 will deliver differentiated service classes so that we can use our networks more effectively. Also, when the data is encrypted, it will be difficult for the network to make class-of-service decisions based on packet content. As class of service increases in importance in our networks, so too will the advantage of end-point VPN where class of service can be stated outside the VPN envelope of the IP packet.

Managing VPN Policy: The End (Points) We are starting to learn about host management. More accurately, TME (Tivoli Management Environment) and Norton Administrator System, to name just two, are teaching us what to do and how to keep to the path of central, end-point management. Our efforts can be extended to IPSec and Oakley management and allow for tigh t host access and creation of VPNs on as fine a granular level as we seem to need.

Those of us responsible for building corporate networks will need to create a consistent security-policy language of sorts to allow for security and enable network managers to define the roles of end points in the VPN fabric. This language will have to allow for a finitely large number of VPN participation for every end point. Yes, end-point management is daunting, no question about it. But, like everything in the network specialist's life, it mostly requires good planning. Start dedicating a fair piece of your resources to IPv6 and end-point policy management now. In the foreseeable future, it will simplify your job.

Robert Moskowitz is a software systems specialist at Chrysler Corp., Detroit, Mich., and a member of the Internet Architecture Board (IAB). He can be reached at rgm@htt-consult.com.