With any of these tunneling protocols, you'll need to do some advanced planning to figure out how you'll identify components of your VPN. IPSec's Oakley Key Management Protocol supports a number of identity technologies including X.509 certificates. This gives IPSec extensive identity scaling capability. L2TP and PPTP use CHAP (Challenge Handshake Authentication Protocol) authentication technology. This is perfectly adequate for a small VPN, but its static nature is considered a security risk. Regardless, all of the tunneling protocols have some method other than clear-text passwords, and the choice of tunneling technology you use will be determined, in part, by your authentication needs.

The choices may seem simple. All you need to do is understand your VPN needs, work through the functionality of the available technologies, procure one of the tunneling protocols, and install it.

It would be terribly nice if this was how it worked in the real world, but it isn't. Any of these technologies will support VPNs, but all of them eventually reveal the true challenges you'll face in setting up a VPN.

A Pair of VPN Styles You can view your VPN in two ways. The first and more simple approach is to think of your network as one network with some atypical routed links called tunnels. This means that you have full routing between the parts of the network connected by the tunnels, and there's one unified DNS for your entire VPN. If you want to connect a number of office locations, you may find this solution fits your needs perfectly.

In the second approach, you view each part of the VPN as a separate network, much in the same way you think of the Internet, again with some atypical tunneled and routed links. In this situation, finding a unified routing table is unlikely, and the DNS might also be fairly fragmented. If you're under the impression that this would be difficult to manage, you're right. But it's the most likely situation when different business groups, even within one company, control the parts of the VPN.

If you can make the first style work for you, I envy you. The simplicity of your networking requirements are highly commendable. Thousands of my colleagues and I are realizing that, unfortunately, we are not in this position, and we must now grapple with the more challenging set of issues.

Oops. We Broke the Internet Some years ago, David Clark of MIT (considered by many to be the ongoing architectural guide to Internet development) warned of the Balkanization of the Internet. He stated that if we do not solve our address shortage, routing protocol limitations and lac k of security, every organization will partially shield itself from the Internet. In the long run, he warned, this activity will cost us extra engineering efforts in unforeseen ways. Well, Clark, much as we hate to admit it, you were right.

Private addresses (RFC 1918, which I coauthored) set the stage for a class of problems that VPNs now magnify. We have situations where two networks have the same addresses. This is of little interest when there's no interaction between the two networks, but the nature of VPNs has changed everything. We are now attempting to connect these networks and we're discovering the complexity that NAT (Network Address Translation) takes on in a VPN situation (for more on this, see ds.internic.net/internet-drafts/draft-moskowitz-ipsec-vpn-nat-00.txt).

The Internet routing tables are extremely large--too large to carry in any but the largest routers. Thus, we must use a default route from our internal network to one external gateway or we must proxy all applications out to the Internet. This worked well enough--until now. VPNs may require two (or more) external gateways. This can be accomplished only by changing our default routes, propagating each network within the VPN (an enormous management headache), or further complicating our NAT configurations (discussed in more detail at draft-moskowitz-ipsec-vpn-nat-00.txt). None of these approaches is easy.

Finally, there is the matter of the DNS. If you shield your DNS entries from the rest of the world, how will you provide this information to your VPN partners? If they are private addresses, what address value should the other parts of the VPN "see" for those entries? And, if you don't provide external DNS resolution, providing only proxy services, how will you ever resolve names for some other part of the VPN? The answers to these questions don't come easy. It will take a whole set of patchworks to our current, common use of internal DNS configurations. If only a limited number of hosts can be reached by other parts of the VPN, it may be possible to maintain dual DNS entries: one set for internal usage, the other for VPN usage. NAT situations might require DNS spoofing as well. Thankfully, this is performed by some firewall products. Alternatively, we may have to inform each part of the VPN of the accessible hosts and let the VPNs figure out their own DNS solutions.

If Only We Had Listened If we had the very large address space of IPv6 so that no one would need private addresses, and if we had a real routing protocol like Nimrod, and if we had IPSec--properly configured, of course--on every single node in our network, we could set up VPNs with impunity. We could operate in an environment of open borders with minimal checking at those borders. All we would have to do is implement any policy activity on the systems directly involved in the VPNs. We could even configure our own networks as a kind of VPN.

However, I suspect that this is unattainable. I am not speaking of the IPv6 or Nimrod or full IPSec deployment, but rather of the tearing down of the walls surrounding our networks. We will continue to expend an ever-increasing amount of resources to meet our corporate communication goals in an increasingly complex environment. We will all spend a lot of time deploying our VPNs and wondering why we must work in such complicated environments.

I applaud those of you who will tear down the walls and securely open your networks.

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.