10.3 IP-Based Virtual Private Networks

10.3 IP-Based Virtual Private Networks

Each successive generation of VPN technology — from an actual private infrastructure, to private leased circuits, to layer 2 solutions — capitalized on the sharing of network infrastructure to reduce the overall cost of the service. Each solution was a bit less "private" than the previous one; but generally, the cost differential made up the difference for the users. An IP-based VPN takes the layer 2 solution one step further. Instead of sharing a specific layer 2 backbone with other users, IP-based solutions seek to leverage the comparatively low cost of Internet connections. Because the Internet is potentially less private than service provider layer 2 backbones, privacy is assured through the use of encryption protocols.

IP-based VPNs come in several different flavors. A description of each of the most common technologies used in the process and a discussion regarding their applicability is included in this section. Because many of these technologies rely on the concept of tunneling, this will be the focus of the first discussion.

10.3.1 Tunneling and Encapsulation

You cannot study IP-based VPNs for very long before running into the terms "tunneling" and "encapsulation." While related, there are some differences between the two terms. Recalling the OSI Model or the TCP/IP suite, the process of placing upper layer data into a lower layer is known as encapsulation. For example, an FTP application data unit is encapsulated in a TCP header. The TCP header, in turn, is encapsulated in an IP header that, in turn, is encapsulated within a data-link layer frame. For encapsulation, the normal model of the protocols remains intact.

While encapsulation occurs every time we transmit data over the Internet, it does not provide for all of our needs. Consider the instance where we need to send IPX/SPX data ^[5] over an Internet connection. Because IPX alone cannot be sent over the Internet, we must tunnel it inside an IP packet. If we were to follow the encapsulation process, we would see that we are taking a layer 3 protocol (IPX) and encapsulating it inside a layer 2 protocol (PPP). For the IPX protocol, this creates the illusion that the local IPX network is directly attached to the remote IPX network, a topology that IPX understands.

Of course, IPX data will not travel over the Internet; and because we do not really have a point-to-point connection between the local site and the remote site, we need to put our PPP frame inside of an IP packet so that it will be able to be routed over the Internet. At this point, we have placed a layer 2 data unit inside a layer 3 data unit. This process of placing a lower-layer or like-layer protocol inside a higher-layer protocol is known as tunneling. We have, in effect, created an envelope that can be used to deliver data that is normally not able to travel over the Internet on its own. Internet routers do not care what the contents of packets are; they only examine the outer-most packet header without regard to the packet contents.

Generic Routing Encapsulation (GRE) is known as a tunneling protocol and is the basis of many other tunneling protocols. As it turns out, simply placing a PPP packet inside an IP packet does not provide all the information required for tunneling to operate. We need some sort of framework to describe to each end of the connection what is happening inside the IP packets being sent and received. We need some way of indicating that inside this set of packets are protocols that deviate from what each side would normally expect in the process of encapsulation. GRE is one way of doing this.

Because GRE is the foundation of many other tunneling protocols, we need a brief discussion to fully explain what it is accomplishing. While there are a number of protocols that describe the tunneling of specific protocol combinations, GRE is an attempt to broadly define what is required for tunneling. A look at the protocol header from the RFC that describes GRE, RFC 2784 (see Exhibit 4) is instructive. A number of the fields in a GRE header are optional, including the checksum present bit, the reserved fields, and the checksum itself. Unless the GRE implementation is supporting RFC 1701 — which is an earlier version of GRE and supports key information, sequence numbers, and routing information — the Reserved0 field will be set to zero. The Reserved1 field is only present when the checksum field is present and is currently undefined. The version number of GRE is set to zero.

Exhibit 4: Generic Routing Encapsulation Header

Once the final count has been performed, we see that the only real information that is consistently within a GRE header is the protocol type field (Exhibit 5). This is a value that matches the IEEE values of layer 2 protocols. In effect, and at a minimum, the IP header that transports the data indicates that the data the IP header is carrying is GRE data. The receiving host then examines the GRE header, which indicates what type of layer 2 data is found in the GRE data field. This layer 2 header will then be examined to determine what kind of layer 3 information is found within the layer 2 frames. Simple, right? From this basic framework, tunneling protocols can become a lot more complicated. GRE itself does not provide any mechanism for authenticating tunnels or evaluating their performance. GRE simply defines which layer 2 protocol is being tunneled inside an IP packet.

Exhibit 5: Each Header Needs to Define What the Next Protocol Header Is

10.3.2 The Point-to-Point Tunneling Protocol (PPTP)

Designed primarily by the Microsoft Corporation, the Point-to-Point Tunneling Protocol (PPTP) is designed to simulate a layer 2 connection over multiple hops in an IP network. To best understand what PPTP accomplishes, let us first consider an example without PPTP.

In a typical dial-up scenario, a home user dials into his ISP for Internet access. Through a modem connected to the home computer, the computer accesses the PSTN (public switched telephone network) and creates a circuit-switched connection to a network access server at the ISP. This connection is a point-to-point (PPP) connection and uses the standard PPP frame format. Although the home user and the ISP access server are not directly connected, from the point of view of the data-link layer, there is a single circuit between the two devices. Once the initial PPP connection is established, there are a few things that need to happen. The first step is generally to make sure that the home user has paid his bill and has the privilege of using the service provider's resources. This is most commonly done through a username/password combination sent by the home user and verified through the use of a central database server at the ISP (more on authentication methods later). Once the user is authenticated, the home user's PC needs to be configured to use the network to which it is connected. Remember when using a PPP connection that the computer appears to be a node directly connected to the ISP network. Thus, it will require, at a minimum, an IP address, subnet mask, and default gateway. Typically, a DNS server address will also be configured at this time.

Fortunately for the Internet as a whole, instead of expecting millions of America Online (AOL) users to understand how to configure these elements on their home computer each time they connect to the network, the PPP protocol has the ability to configure the host device automatically.

The same process occurs when remote users create a dial-in connection to their office's remote access server. In this case, the company has a number of incoming lines specifically reserved for data calls and these lines will terminate at some type of modem device. The only difference between home users dialing their ISP is that sometimes a corporate dial-in connection will have the requirement that protocols other than IP be used. In this case, PPP, being a layer 2 protocol, supports a number of non-IP protocols. In the case of IPX and NetBEUI, PPP also supports the automatic configuration of these protocols.

In summary, PPP is an ideal protocol for dial-in connections because it is already configured with authentication support, configuration support, and the ability to use layer 3 protocols other than IP if needed. The catch is that all of this functionality only works when you are directly connected to a PPP network access server.

Clearly, this is not possible on the Internet. What we need is a way to make two remote devices think they are directly connected over multiple IP hops. So how do we place a layer 2 protocol (PPP) inside a layer 3 IP packet for transport? Using tunneling, of course!

The ability to logically extend a PPP connection over multiple layer 3 hops is what PPTP is all about. To accomplish this, PPTP relies on the GRE header, separate control and data connections, and network devices, as illustrated in Exhibit 6. Because the GRE header does not include any type of connection setup information by default, PPTP uses a separate control connection. This control connection is used to set up a PPTP session, to negotiate protocol parameters, to control session flow, and finally, to tear down a PPTP session. Using TCP allows error checking and flow control to apply to the PPTP control session without the need to introduce more complexity into PPTP itself. TCP uses port 1723 to listen for new connection requests.

Exhibit 6: PPTP Network

PPTP uses what the protocol specifications term an "enhanced" version of GRE. The enhancements to the GRE header are the inclusion of a sequence number field and an acknowledgement field much like that found in a TCP header. Unlike the fields in the TCP header, these fields are never used for retransmission or error correction. They are only used for flow control and sequencing information.

User data in a PPTP connection is tunneled inside a PPP header, which is, in turn, tunneled inside an enhanced GRE header. GRE simply provides protocol identification to the remote end along with some sequencing information. The GRE/PPP combination itself is connectionless. It is assumed that if error correction is important, then the user data itself will provide it.

The PPTP network server (PNS) is an application designed to operate as part of a generic operating system. Because this was a protocol primarily developed by Microsoft, the generic portion of this clearly means a Windows server of some sort. PPTP servers, however, can also be found for other operating systems. The responsibilities of the PNS include authenticating new connections, bundling PPP links if appropriate, terminating PPP control protocols for layer 3 protocols, and any bridging or routing functions required of the connection. The PNS can be summarized as the server portion of PPTP, with the exception that the PNS can also initiate a PPTP connection to a PAC if required.

The PPTP access client (PAC) can be considered the client side of PPTP. This is a device that is responsible for the interface with the PSTN, the logical termination of the PPP link control protocols (LCPs), and participation in the authentication process. The PAC is a process that in PPTP implementations is most commonly found on a host PC with dial-in software. Prior to Microsoft's L2TP VPN implementation on Windows 2000 devices, PPTP was the default protocol used for host-to-gateway VPNs on Microsoft platforms.

As indicated in Exhibit 6, a PAC can also be found within the network itself. An example of this might be when an ISP wishes to offer dial-in VPN services for its customers. In this case, remote dial-in users would dial into the PAC, which would then forward traffic from a number of PPTP connections over a single data and control channel. Used in this manner, PPTP is transparent to the client because, from their point of view, they have established a normal dial-in connection to an ISP. From the PAC, all traffic is tunneled via PPTP to a corporate PNS.

Deployed in this manner, PPTP is a very scalable protocol. Because one control and data connection between the PAC and the PNS can multiplex many different user data sessions, PPTP session information and overhead are minimal. This is not, however, how PPTP is commonly deployed. As will be discussed in the L2TP section (Layer 2 Tunneling Protocol; see Chapter 10.3.3), if an ISP wished to offer this type of service, it would be more likely to use L2TP. PPTP is most commonly deployed as a host-to-gateway type VPN instead. Because each dial-in host requires a single control connection with no chance of multiplexing either control or data sessions, PPTP in practice generally does not scale well.

So far, in discussing the architecture surrounding PPTP, has any mention been made of security? Despite commonly being sold as a VPN solution, PPTP itself does not incorporate any security mechanisms. This means that the control channel information is sent in the clear. The private part of PPTP is accomplished using the Microsoft Point-to-Point Encryption Protocol (MPPE). As its name suggests, MPPE is used to encrypt PPP data. While MPPE does support 128-bit encryption, it has suffered from a number of serious security flaws that have allowed attackers to decipher encrypted data. Most of the weaknesses have revolved around the initial generation of the keys. Each discovered vulnerability is fixed in a subsequent service pack, yet the history of the protocol has left some network security experts unable to recommend its use as a company VPN.

The early flaws in Microsoft's PPTP and MPPE encryption were based on Microsoft's support of legacy LAN Manager authentication and MS-CHAPv1. This authentication scheme is not as robust as that used in Windows domain authentication and is more easily brute-force attacked. Microsoft's PPTP authentication using CHAP was also flawed, in that the server was never properly authenticated. An attacker could pose as the server over a network and accept incoming connections. Remote users would be none the wiser. Finally, the control connection implementation had a bug in it that would allow remote users to crash a PPTP server outright by sending connection information over the control channel.

Like most protocols that rely on passwords for authentication, PPTP also suffers from users who choose poor passwords. Early implementations of the Microsoft PPTP server based the secret key used for the actual encryption of data on the user's password. This allowed easily crackable keys to be created when users did not choose strong passwords.

Lest you think that all of these flaws are old and have been resolved, versions of PPTP shipping with Windows 2000 and Windows XP have been confirmed to have buffer overflow vulnerabilities that allow a remote user to again crash a PPTP server.

PPTP has several benefits that make it an attractive VPN solution for many companies. First, it is standard on every Windows server. Client support is also built into every Windows client. This, combined with an army of MCSEs that have been trained on and tested with PPTP, ensures that it will have wide popularity. This also means that it fits into the budget of most companies. They have already paid for the rights to use the operating system, so why invest more in VPN hardware and software if the basic building blocks are already there? PPTP is not only the domain of Windows operating systems anymore. Free implementations of PPTP servers and clients can also be found for the popular Linux operating system.

The client/server nature of PPTP and the ubiquitous presence of Microsoft means that a VPN can be set up quickly. This is handy when temporary or immediate VPN connectivity is required. It is also configured totally independent of the ISP. In an effort to provide differentiating and value-added services, some ISPs offer a VPN service of their own, configured much like PPTP (see the L2TP protocol, Chapter 10.3.3). PPTP, however, can be configured without the participation of the ISP, which naturally precludes payments to the ISP as well.

Because PPTP is configured independently of the ISP, it is also a good solution for companies that have a diverse user base. If you purchase PPP-based VPN services from an ISP, then to be cost effective, your users need to be dial clients of that ISP as well. With PPTP, if you have a remote user base that is connecting to the Internet in many different ways such as through cable modems, DSL, and multiple dial-up accounts, PPTP can easily accommodate them all.

Due to the virtual layer 2 PPP connections that PPTP creates between the remote user and the PPTP server, PPTP is also ideal if a company has non-IP data that it must transmit over the VPN. This is most commonly the case with corporations that are still running Novell's IPX on their LANs, or even Banyan Vines. PPTP allows remote users to tunnel these normally non-Internet protocols over public networks.

There are also several reasons why you might decide to pass on PPTP as your VPN solution. The first of these reasons is security. Most of the examples previously discussed in this chapter regarding flaws in the PPTP implementation have been fixed. Despite this, the fact remains that Microsoft is a favorite target of the Internet underground. It is not that Microsoft is necessarily any less secure than other options out there; it is just that those who would harm your network more often target it. It is a safe bet that new PPTP flaws will be found (just as new security flaws will be found in any Internet application), and there will be hordes of individuals out there who are anxious to try out any new PPTP holes.

Also related to security, the encryption used for PPTP packets is not as robust as other options such as IPSec. At the very least, PPTP does not offer any encryption of the control channel information. To an attacker trying to learn more about the network, captured control packets provide a wealth of information. With IPSec, after the first few packets of negotiation, all information exchanged between hosts is encrypted. The encryption algorithms in IPSec are also more robust. Not all 128-bit encryption schemes are created equal. Even those that use the same encryption algorithm depend on the use of securely generated secret keys used to encrypt and decrypt the data.

PPTP also adds quite a bit of overhead to IP packets. Consider that, in addition to the normal TCP data that you are sending to the company LAN, you add an internal PPP header, a GRE header, an outside IP address, and another layer 2 header, most likely PPP again. This adds about 37 more octets of data to each packet. While header compression can reduce this somewhat, over dial-up links these effects are noticeable. While this over-head is required for the functionality that PPTP brings to the VPN, if you are always going to pass IP traffic only, then the overhead to allow other layer 3 protocols to be tunneled is unnecessary.

The scalability of PPTP has always been an issue with the protocol. While the PPTP specifications outline a very scalable protocol when used with a network PAC and local PNS, the common implementation of PPTP with multiple remote clients means that for every user connection there is an associated control connection. This is contrasted with the original standards that suggested many remote users sharing a single PAC, thus allowing a single control connection to coordinate many user sessions. PPTP in the Microsoft implementation also has limitations as to how many remote clients can connect at one time. At last count there was support for 255 connections. While this sounds plentiful for the small network, I have never seen a server in common networking environments able to handle nearly that many connections.

Finally, for some, PPTP means Microsoft. While there are plenty of implementations of PPTP clients and servers out there that are not Microsoft products, the association between PPTP and Microsoft is strong. Some may disagree with Microsoft business practices and choose not to use its products — although these exceptions are few and far between. The association that PPTP has with Microsoft causes some to look elsewhere for alternative protocols.

Now that we have an understanding of the parts that make up PPTP, let us examine it in action (see Exhibit 7). For this discussion we assume the most common configuration of PPTP, which is that a remote user is accessing a company network. The remote user's computer will act as the PAC and a Windows server on the company network that is accessible from the Internet will operate as the PNS (PPTP network server). First, the user will establish a regular dial-up connection to the Internet via any ISP. After the authentication process, this will create a PPP connection to the ISP itself that will configure the user's computer with an IP address and other IP-related information. So far, this is the exact process the user would follow if he wished to surf the Web or download files.

Exhibit 7: PPTP Operation Example

Once the initial PPP connection to the ISP has been established, the user will then open another connection. For the most part, this is a connection that is configured much like a normal dial-in connection except, instead of dialing a phone number for a connection, the configuration indicates a remote IP or DNS name to which to connect. This should not be surprising, considering that PPTP simply creates another tunneled PPP connection. When the user initiates the second connection, the PPTP software on his PC attempts to create a TCP/PPTP control connection with the PPTP server software located on the company network. Depending on the configuration of the network itself, the firewall protecting the company network will have to be configured to allow TCP port 1723 and the GRE protocol through the firewall to the company's PPTP server for this connection to be successful.

The first packets sent will attempt to set up the control connection itself. Once this has been accomplished, information specific to the PPTP data session will be exchanged. The outer layer is now up. PPP and key exchanges will then be performed to bring up the virtual PPP link over the GRE data session. Key information will provide for the encryption process applied to the PPP session. The PPP authentication process will also validate the user and configure the remote user's host PC with another IP address. Yes, the remote host will now be configured with two IP addresses and that point bears some discussion.

PPTP will create a virtual network adapter on the remote host. This virtual adapter will be the one that is configured with IP information specific to the tunneled PPP connection. The real network adapter — the one that dials the ISP in the first place — is assigned an address and IP information specific to the ISP. This allows packets from the remote host to be routed across the Internet. Once the GRE PPP connection is created using PPTP, the virtual adapter allows the remote host to look like it is directly attached to the company LAN. Because the IP addresses used inside the GRE PPP connection are never examined or seen by the Internet routers (the whole point of GRE and tunneling, right?), the inside IP addresses can be private addresses that are not normally routable over the Internet.

At this point there is a TCP control connection between the remote user and the PPTP server. This control connection, once set up, periodically sends a keep-alive packet between the two hosts. This is simply to ensure that the remote side was not suddenly disconnected and resources are being saved for a connection that no longer exists. There is also an enhanced GRE tunnel between the remote PPTP client and the PPTP server. Data sent over this traffic appears to the two devices to have traveled over a PPP connection. In effect, the remote PPTP client has become a virtual part of the company LAN. While PPTP itself does not support any encryption, during the setup of the PPP tunnel, MPPE was configured based upon the username of the remote user. This provides up to 128-bit encryption for the traffic over the GRE tunnel only.

Because the user has an Internet IP address assigned to him by his local ISP when he dialed in to the Internet, the remote user is also able to access Internet sites at the same time he is using the PPTP tunnel. This process is known as split tunneling and will be discussed in more detail when we consider the overall security implications of VPNs. Suffice it to say at this point, a split tunnel is the ability to access the VPN tunnel and non-VPN sites at the same time.

When the user no longer has a need for the PPTP tunnel, the control connection begins the process of first terminating the remote PPP connection, and then the PPTP connection. Finally, the TCP session that has established the control connection is torn down between the PPTP client and the PPTP server. If the user has no need for Internet access at all, he will then disconnect from the ISP or is able to continue using the ISP's Internet connection to continue working online.

Based on all this information, we are ready to make some recommendations regarding the use of PPTP as a VPN protocol. PPTP should be considered when:

• A company has limited needs for VPN connections. PPTP on the Microsoft platform is not as scalable as other solutions.

• Remote connectivity is more important than encryption. PPTP will protect data, but not as securely as other options available.

• There is an immediate need for VPN connectivity. PPTP can be deployed very quickly without the involvement of other parties. Typically, PPTP can be ready for access within a couple of hours at most.

• Windows domain integration is desired. PPTP uses existing user names and passwords for authentication on the Windows network. This makes managing users a straightforward process for Windows shops.

• Non-IP protocols must be supported. The PPP extension that PPTP provides allows for non-IP protocols to be tunneled over the Internet.

PPTP also has a number of reasons that it should not be considered, including:

• Microsoft is moving away from the PPTP model as well. The option we will discuss next (i.e., L2TP) is the preferred method of layer 2 VPN connectivity for dial-in and remote clients on Windows 2000 and XP operating systems.

• It does not scale as well as other options.

• The security of the protocol according to Microsoft's implementation has been compromised several times in the past; including the encryption.

• It is primarily a Microsoft-only protocol. While there are other implementations of PPTP available, the major support for PPTP has been through Microsoft.

• This technology is primarily to enable dial-in, or host-to-gateway VPN connections. Gateway-to-gateway tunnels are possible, but normally not configured using PPTP.

10.3.3 Layer 2 Tunneling Protocol (L2TP)

Like PPTP, the Layer 2 Tunneling Protocol (L2TP) is used to create an extended PPP tunnel. We will see that as we explore L2TP, it shares many similarities with PPTP and there is a reason for this. Prior to the development of L2TP, there was another layer 2 tunneling option known as Layer 2 Forwarding (L2F). Developed by Cisco, this protocol was used in routers to create virtual point-to-point connections and competed with the Microsoft-developed standard PPTP. Knowing that confusion in the marketplace is bad for technologies, the IETF requested that Microsoft and Cisco work together to merge their tunneling protocols. The result of that work is L2TP. Currently, the most widely deployed version of L2TP is L2TPv2. Most of the discussion below refers to v2. There is an emerging standard known as L2TPv3 that provides many of the benefits of MPLS without the need for an MPLS-enabled network. This protocol, along with its pros and cons, are discussed after the initial L2TPv2 discussion.

The major difference between L2TP and PPTP is that L2TP does not use GRE encapsulation for data. Instead, the protocol specifies an L2TP header designed specifically for the needs of the protocol. The second major difference and one more relevant to implementation of the protocol is that L2TP does not attempt to provide its own encryption of the PPP tunnel as PPTP does. Instead, L2TP relies on the IPSec protocol to apply encryption if it is required.

Before explaining these two points and examining the protocol in greater detail, it is worthwhile to point out while we are on the subject that both L2TP and PPTP do not have to provide encryption of data. Encryption adds additional overhead and latency to packets due to the encryption/decryption process. In some cases, it may be more important to simply establish an extended PPP tunnel between two points as in the case of tunneling non-IP protocols.

While PPTP was developed with the average Windows office network in mind as the market, L2F and its derivative L2TP were developed with the ISP market in mind. Thus, while many of the features and pieces of the protocols are similar, we will see that their implementations are different. This, however, is changing, with L2TP working its way into the small-office market as recent Windows operating systems include L2TP as the default tunneling protocol.

L2TP networks (Exhibit 8) are designed around two primary components: the L2TP access concentrator (LAC) and the L2TP network server (LNS). The similarity to the PPTP components PAC and PNS should not be overlooked. Other than the name, the devices provide similar functions in both protocols. The LAC is the remote side of the connection. This can be a remote client, but is just as often an actual device that sits on the ISP's network. Deployed with the LAC as part of the ISP, L2TP is an ideal example of compulsory tunneling. Clients dial-in to the LAC and their calls are forwarded in a multiplexed L2TP tunnel to the LNS. Clients are unaware of, and do not have to configure, any element of the VPN tunnel. They dial what to them seems like a normal ISP dial-up connection. The LNS is the corporate-based network server. In a managed solution, however, this does not even need to be located at the company site, but can be at the ISP. L2TP uses a data session and a control session. The control session is used for the establishment of the PPP connection in the data session and for feedback about the quality of the link. The L2TP control channel is fairly low bandwidth once the connection is set up and therefore can be used to multiplex many data sessions. When employed as originally designed, with the LAC part of the ISP network, this leads to a very scalable solution with one control session being able to manage numerous user sessions. Of course, used in a host-to-gateway solution like PPTP typically reduces the usefulness of this option.

Exhibit 8: L2TP Network

For both the control and data session, L2TP has its own header that it encapsulates inside a UDP datagram. For reliability, the L2TP control channel has its own built-in sequencing and acknowledgement of packets. The entire protocol header for discussion is shown in Exhibit 9, along with the encapsulation model of the control and data sessions.

Exhibit 9: L2TP Header Format

The first bits of the header, the type (T), length (L), sequence (S), and offset (O) are primarily used to differentiate between control and data sessions within a stream of multiplexed L2TP messages. The priority (P) bit is used to indicate the relative importance of the L2TP packet in a local dequeuing and transmission scheme. This bit is only used in data messages. The version field is always version 2, unless of course this is one of the rare circumstances where the emerging version 3 is being introduced.

If the length bit (L) is set, the length field will logically enough contain information as to the length of the L2TP message in octets. Like other fields indicated with the optional (opt) term, these fields may or may not be present in any given L2TP message. The most common differentiator is that control messages have more options set and data messages have less. The concept is that the control messages have nothing assisting them with flow control or reliability, whereas data transmitted will have the encapsulated data itself to provide flow control and resequencing if necessary.

Of the most interest for us in our examination of L2TP are the tunnel ID field and the session ID field. The tunnel ID is a locally significant value exchanged during the creation of a control session. Locally significant only means that the value does not need to be agreed upon between remote points of an L2TP connection; it only needs to be communicated. If an LNS has multiple control sessions active, the tunnel ID allows the LNS to identify control information as it is received.

The session ID identifies a session within a particular tunnel. This is the identification of user data. Like the tunnel ID, this value is only locally significant, determined by the local host and transmitted to the remote host for use in packets sent back to the local host.

Nr and Ns are both sequence numbers indicating what has been sent (Ns) and what has been received (Nr). These fields together are used by control sessions to ensure reliable communications.

Turning to the issue of security, L2TP does not make any attempt to secure data on its own. Instead. it uses IPSec as its means of encrypting data. The benefit of this approach is that IPSec is mature and well tested. Any security flaws have been identified. IPSec also has many vendors that support and implement it, increasing the chances of interoperability in a heterogeneous environment.

When describing L2TP encryption with IPSec, the question is often asked, "If I'm going to use IPSec for encryption anyway, why use L2TP at all?" A good example of this is in the Microsoft implementation of its IPSec VPN intended as a replacement for PPTP. Although it is an IPSec VPN, it uses L2TP as the protocol to transmit data. Although we have not discussed IPSec in any detail yet, we will share just enough to make sense of this discussion.

IPSec provides encryption for IP protocols, as the name implies. It also has the ability to encapsulate data so that all information in a packet, other than the IP header required for routing is encrypted. Notice the use of the term "encapsulate" rather than "tunnel" in this instance. By default, IPSec will not allow you to tunnel layer 2 data — only IP data. So far, this is not a problem. L2TP is transmitted inside a UDP header, making its operation with IPSec seamless.

IPSec, however, cannot support layer 2 protocols. That is, IPSec will not provide the illusion of an extended PPP tunnel. If you need to include other non-routable protocols across the WAN, then L2TP is required for the tunnel. IPSec on top of that tunnel is then required for encryption.

Many companies will then note that they only transmit IP data anyway, so there is no need for the PPP connection enabled through L2TP. That may be true for data transmission, but PPP also provides another important function for remote users: the ability to authenticate users and configure the PPP adapter of remote users with IP addresses, subnet masks, default gateways, and DNS servers. Referring back to the Microsoft IPsec VPN implementation, L2TP provides authentication and configuration services that are essential to the seamless deployment of a host-to-gateway VPN solution even if IP is the only protocol that the remote user will ever be sending over the connection.

In the end, it is not so much a matter of L2TP lacking functionality as the reason that IPSec was included as the encryption protocol. It was the lack of capability of IPSec at the time that L2TP was being developed. The protocol designers realized that IPSec lacked important functions for host-to-gateway deployments where IP address would change frequently and it would be a duplication of effort to include another encryption protocol for L2TP. Instead, the protocols were joined. As we discuss in the IPSec section (Chapter 10.4), many of the problems with the remote configuration of IPSec and authentication of roaming users have been fixed. The future of L2TP, like that of PPTP, may be limited as understanding and operating implementations of IPSec shrink over time.

In summary, L2TP is a VPN solution to consider if:

• Compulsory tunneling is required. If an ISP is going to offer a managed dial-in solution for VPN services, L2TP is most likely to be the protocol in use.

• Non-IP protocols need to be routed over the WAN to remote gateways or hosts. The PPP connection created by L2TP enables this.

• A managed VPN service is desired. As noted above, PPTP is a Windows-based solution and L2TP is a service provider-based solution.

• Strong encryption is called for in the security policy. L2TP's integration with IPSec ensures that the strongest available encryption and authentication methods can be used.

• Your site decides to completely manage the VPN on its own. L2TP, like PPTP, does not require the assistance of a service provider to enable it.

• Dial-in users can use multiple ISPs and accounts to access your VPN. Just because L2TP is ideal for service provider provisioning does not mean that this is the only way to provision it. L2TP can be provisioned just as PPTP is in a host-to-gateway scenario.

There are few reasons not to use L2TP. Most of the reasons not to use L2TP revolve around redundancy of features with IPSec. L2TP would not be an ideal solution if:

• Only IP-based protocols are ever going to be required on the VPN. In this case, L2TP only adds more complexity and overhead to the VPN.

• Packet overhead is an issue on low-bandwidth links. L2TP does add overhead to IP packets. If all that is required is encryption then it is more efficient to simply use IPSec.

10.3.3.1 Layer 2 Tunneling Protocol, Version 3.

While much of the discussion thus far has focused on L2TPv2, there is a new VPN protocol on the horizon that might fit your security needs as well. Although related to L2TPv2, L2TPv3 is significantly different enough in its implementation to warrant its own chapter section.

While L2TP was a technology that allowed the extension of a PPP tunnel across a network, L2TPv3 removes the PPP-specific information in the header of the L2TP packet. This, with further modifications to the header, allows L2TPv3 to tunnel layer 2 protocols other than PPP. Thus, L2TPv3 could tunnel Ethernet frames across a network, giving a company the appearance of a global LAN. Other protocols that operate with L2TPv3 are HDLC, 802.1q VLANs, Frame Relay, and Packet over Sonet (POS). The header has also been modified to support rapid encapsulation and deencapsulation, allowing L2TPv3 to operate at high speeds.

In many respects, L2TPv3 is much like MPLS but without the need for a network core that has been reconfigured to support MPLS. Only the end-points of the tunnel need to understand that there is an L2TPv3 tunnel present. All other network nodes route IP traffic normally. To some service providers, wary of investing too heavily in a fairly new technology like MPLS, L2TPv3 tunnels are the perfect solution. Customers receive the same layer 2 protocols using L2TPv3 that they would receive if the carrier were utilizing MPLS layer 2 VPNs, yet the service provider does not need to globally provision an MPLS network. L2TPv3 can only be rolled out between the customers that desire the service.

So far, much of the discussion of L2TPv3 has focused on the carrier backbone. This is because unless you are a large enterprise customer, L2TPv3 is not something that you are going to be able to provision on your own. Currently, L2TPv3, while on a standards track with the IETF, is Cisco proprietary. Furthermore, the L2TPv3 feature set is available only on some of Cisco's most powerful (and expensive) routers. This alone limits the implementation of L2TPv3 to only large service providers and large corporations. If you are a small company that is interested in the benefits of L2TPv3, then you need to find a service provider that supports this service.

When considering if L2TPv3 is the solution for you, many of the same pluses and minuses that are applied to MPLS can also be applied here. First, L2TPv3 alone does not provide any type of encryption service. IPSec is used as in L2TPv2 to provide encryption services. The privacy of L2TP is still up in the air. MPLS takes a number of steps to ensure that data cannot be inserted into the label-switched path. Because L2TPv3 is simply IP encapsulated packets, the ability to restrict traffic to the level of an MPLS, Frame Relay, or ATM network is limited to current IP controls. To help protect against data being inserted into an L2TPv3 session, an L2TPv3 header uses a 64-bit "cookie" field that serves as an incrementing sequence number. As in a TCP session, remote ends of the L2TPv3 tunnel will only accept data that is within a certain range. Without the ability to sniff the data, it would be extremely difficult to guess the value of these sequence numbers and insert bogus L2TPv3 data remotely. Data captured in transit can be read. Remember, however, that L2TPv3 is generally a provider technology. Your data is much more likely to be captured on your own LAN than in the backbone of a single, large service provider. In summary, if you want the private element of L2TPv3, make sure that IPSec is being employed on sensitive data.

^[5]Diminishing in popularity, IPX/SPX is the network layer protocol used by the Novell operating system for best effort and reliable transportation of data on LANs.