Deploying Virtual Private Networks with Microsoft Windows Server 2003 (Technical Reference)

Tunneling is a method of using an intermediate network infrastructure to transfer data for one network over another network while maintaining privacy and control over the original data. The data to be transferred (the payload) can be the frames (or packets) of another protocol. Instead of sending a frame as the originating node produces it, the tunneling protocol encapsulates the frame in an additional header. The additional header provides routing information so that the encapsulated payload can traverse the intermediate network.

The encapsulated packets are then routed between tunnel endpoints over the internetwork. The logical path through which the encapsulated packets travel through the internetwork is known as a tunnel. Once the encapsulated frames reach their destination on the internetwork, the frame is decapsulated and forwarded to its final destination. Tunneling includes this entire process (encapsulation, transmission, and decapsulation of packets). Figure 2-5 shows tunneling.

Figure 2-5: Tunneling.

The transit internetwork can be any internetwork—the Internet is a public internetwork and is the most widely known real-world example. There are many examples of tunnels that are carried over an organization’s internetworks. And while the Internet is one of the most pervasive and cost-effective internetworks, you can replace the references to the Internet in this book with any other public or private internetwork that acts as a transit internetwork.

Tunneling technologies have been in existence for some time, such as SNA tunneling over IP internetworks. When Systems Network Architecture (SNA) traffic is sent across an organization’s Internet Protocol (IP) internetwork, the SNA frame is encapsulated in a User Datagram Protocol (UDP) message and IP header. New tunneling technologies have been introduced in recent years. These newer technologies—which are the primary focus of this book—include:

• •PPTP.PPTP allows multiprotocol traffic to be encrypted and then encapsulated in an IP header to be sent across an organization’s IP internetwork or a public IP internetwork such as the Internet. It is a PPP-based technology, and therefore, it has functions for handling session control, address allocation, and routing allocation.

• L2TP.L2TP allows multiprotocol traffic to be encrypted and then sent over any medium that supports point-to-point datagram delivery. It is a PPP- based technology, and therefore, it has functions for handling session control, address allocation, and routing allocation. It allows for not only tunneling over IP, but the use of Layer 2–based transport solutions such as IP, X.25, frame relay, and Asynchronous Transfer Mode (ATM).

• IPSec tunnel mode.IPSec tunnel mode (IPSec TM) allows IP packets to be encrypted and then encapsulated in an IP header to be sent across an organization’s IP internetwork or a public IP internetwork such as the Internet. IPSec TM is not a recommended technology for remote-access VPN connections because there are no standard methods for user authentication, IP address assignment, and name-server address assignment. Although using IPSec TM for site-to-site VPN connections is possible using computers running Windows Server 2003, Microsoft does not implement IPSec TM as a standard because of man-in-the-middle (MITM) attacks that have been identified with most IPSec TM solutions. To handle PPP-like functions such as credential checking and encryption session management, IPSec TM would have to use Internet Key Exchange (IKE) aggressive mode and functions such as XAUTH/MODCFG, which are susceptible to MITM attacks. Also, because the IPSec tunnel is not represented as a logical interface over which packets can be forwarded and received, routes cannot be assigned to use the IPSec tunnel and routing protocols do not operate over IPSec tunnels. Therefore, the use of IPSec TM is recommended only as a VPN solution for site-to-site VPN connections in which one end of the tunnel is a third-party VPN server or security gateway that does not support L2TP/IPSec. Windows Server 2003 supports IPSec TM for interoperability with third-party solutions, but L2TP/IPSec is the preferred method of VPN operations. L2TP/IPSec is the only IETF (Internet Engineering Task Force) ratified IPSec-enabled VPN solution.

Tunneling Protocols

For a tunnel to be established, both the tunnel client and the tunnel server must be using the same tunneling protocol. Tunneling technology can be based on either a Layer 2 or a Layer 3 tunneling protocol. These layers correspond to the Open Systems Interconnection (OSI) reference model. Layer 2 protocols correspond to the data-link layer and use frames as their unit of exchange. PPTP and L2TP are Layer 2 tunneling protocols; both encapsulate the payload in a PPP frame to be sent across an internetwork. Layer 3 protocols correspond to the network layer and use packets. IPSec TM is an example of a Layer 3 tunneling protocol and encapsulates IP packets with an additional IP header before sending them across an IP internetwork.

How Tunneling Works

For PPTP and L2TP, a tunnel is similar to a session; both of the tunnel endpoints must agree to the tunnel and negotiate configuration variables, such as address assignment or encryption or compression parameters. In most cases, data transferred across the tunnel is sent using a datagram-based protocol. A tunnel management protocol is used as the mechanism to create, maintain, and terminate the tunnel.

Once the tunnel is established, data can be encapsulated and sent through the tunnel. The tunnel client or server uses a tunnel data transfer protocol to prepare the data for transfer. For example, when the tunnel client sends a payload to the tunnel server, the tunnel client first appends a tunnel data transfer protocol header to the payload. The client then sends the resulting encapsulated payload across the internetwork, which routes it to the tunnel server. The tunnel server accepts the packets, removes the tunnel data transfer protocol header, and forwards the payload to the target network. Information sent between the tunnel server and the tunnel client behaves similarly.

Tunneling Protocols and the Basic VPN Requirements

Because they are based on the well-defined PPP, PPTP and L2TP inherit a suite of useful features. These features address the basic VPN requirements, as outlined below.

• User Authentication. PPTP and L2TP inherit the user authentication schemes of PPP, including standard Windows and Remote Authentication Dial-In User Service (RADIUS) authentication services as well as the Extensible Authentication Protocol (EAP) methods discussed in Chapter 3, “VPN Security.” Using the EAP, PPTP, and L2TP connections can support a wide variety of authentication methods, including one-time passwords, cryptographic calculators, and smart cards.

• Dynamic address assignment. PPTP and L2TP connections support dynamic assignment of client addresses based on the Network Control Protocol (NCP) negotiation mechanism. For example, IP uses Internet Protocol Control Protocol (IPCP) and Dynamic Host Configuration Protocol (DHCP) to obtain an IP address configuration.

• Configuration Protocol (DHCP) to obtain an IP address configuration.

• (IPCP) and Dynamic Host

• Configuration Protocol (DHCP) to obtain an IP address configuration.

• Data compression. PPTP and L2TP support PPP-based compression schemes. For example, the Microsoft implementations of both PPTP and L2TP use Microsoft Point-to-Point Compression (MPPC).

• Data encryption. PPTP and L2TP support PPP-based data encryption mechanisms. The Microsoft implementation of PPTP supports the use of Microsoft Point-to-Point Encryption (MPPE), based on the Rivest-Shamir- Adleman (RSA) RC4 algorithm. The Microsoft implementation of L2TP uses IPSec encryption to protect the data stream from the VPN client to the VPN server.

• Key Management. MPPE for PPTP connections relies on the initial key generated during user authentication, and then refreshes that key periodically. IPSec for L2TP/IPSec connections explicitly negotiates a common key during the IKE exchange, and also refreshes it periodically.

Point-to-Point Protocol (PPP)

Because PPTP and L2TP depend heavily on the features originally specified for PPP, it is worth examining this protocol more closely. PPP was designed to send data across dial-up or dedicated point-to-point connections. For IP, PPP encapsulates IP packets within PPP frames, and then transmits the PPP-encapsulated packets across a point-to-point link. PPP was originally defined as the protocol to use between a dial-up client and a NAS.

There are four distinct phases of negotiation in a PPP connection. Each of these four phases must complete successfully before the PPP connection is ready to transfer user data.

Phase 1: PPP Link Establishment

PPP uses the Link Control Protocol (LCP) to establish, maintain, and terminate the logical point-to-point connection. During Phase 1, basic communication options are selected. For example, authentication protocols are selected, but they are not actually implemented until the user authentication phase (Phase 2). Similarly, during Phase 1, a decision is made as to whether the two peers will negotiate the use of compression and/or encryption. The actual choice of compression and encryption algorithms and other details occurs during Phase 4.

Phase 2: User Authentication

In the second phase, the client computer sends the user’s credentials to the remote access server. A secure authentication scheme provides protection against replay attacks and remote client impersonation. A replay attack occurs when a third party monitors a successful connection and uses captured packets to play back the remote client’s response so that it can gain an authenticated connection. Remote client impersonation occurs when a third party takes over an authenticated connection. The intruder waits until the connection has been authenticated, and then traps the communication parameters, disconnects the authenticated user, and takes control of the authenticated connection.

Windows Server 2003 and Windows XP support the following PPP authentication protocols:

• Password Authentication Protocol (PAP)PAP is a simple, clear-text authentication scheme. PAP is considered to be insecure and unsafe to use in VPN solutions. PAP is included in the options for Windows Server 2003 to satisfy legacy operations and for testing purposes during troubleshooting and the setting up of VPN solutions, but it is not recommended for production VPN connections.

• Challenge-Handshake Authentication Protocol (CHAP)CHAP is an encrypted authentication mechanism that avoids transmission of the actual password on the connection. While CHAP is an improvement over PAP because it encrypts the data being transmitted, it is not considered a strong security solution for authentication. The reason for this is that there is no authentication of the client that is talking to the gateway and therefore an untrusted entity could potentially break in and negotiate CHAP sessions. It is included in Windows Server 2003 for legacy, installation, and troubleshooting support, but it is not the recommended solution for user authorization.

• Microsoft Challenge-Handshake Authentication Protocol (MS- CHAP)MS-CHAP is an encrypted authentication mechanism similar to CHAP. The difference between MS-CHAP and CHAP is that the client system is checked for authentication prior to credentials being passed between it and the gateway system. This authentication is one way: Does the gateway trust the client connecting to it? If the answer is yes, the authorization negotiation is encrypted and completed.

• MS-CHAP version 2 (MS-CHAP v2)MS-CHAP v2 is an updated encrypted authentication mechanism that provides stronger security for the exchange of user name and password credentials and determination of encryption keys. The difference between MS-CHAP and MS-CHAP v2 is that there is mutual authentication between the gateway and the client. The gateway trusts the server and sets up encryption from it to the client, and the client trusts the gateway and sets up an equal encryption method in the reverse direction. This means there is mutual security between the two entities •instead of just one-way security and both sides can be assured of the authenticity of its partner. MS-CHAP v2 is the preferred and recommended authentication method for Microsoft VPN.

• Extensible Authentication Protocol (EAP).EAP is a new PPP authentication protocol that allows for an arbitrary authentication method. EAP differs from the other authentication protocols in that EAP during the authentication phase does not actually perform authentication. Phase 2 for EAP only negotiates the use of a common EAP authentication method (known as an EAP type). The actual authentication for the negotiated EAP type is performed after Phase 2. EAP allows for two-factor authentication, which is the recommended method for strong authentication security. EAP methods include certificates, smart cards, and biometric solutions for the identity management of users.

Chapter 3 includes additional details for these authentication protocols.

During Phase 2 of PPP link configuration, the NAS collects the authentication data and then validates the data against its own user database or a central authentication database server, such as one maintained by a Windows domain controller, or the authentication data is sent to a RADIUS server. Windows Server 2003 includes Internet Authentication Service (IAS), an implementation of a RADIUS server and proxy. As a RADIUS server, IAS can authorize users against Windows Active Directory. As a RADIUS proxy, IAS can forward RADIUS request to other RADIUS servers.

Phase 3: PPP Callback Control

The Microsoft implementation of PPP includes an optional callback control phase. This phase uses the Callback Control Protocol (CBCP) immediately after the authentication phase. If configured for callback, both the remote client and NAS disconnect after authentication. The NAS then calls the remote client back at a specified phone number. This process provides an additional level of security to dial-up connections. The NAS allows connections from remote clients physically residing at specific phone numbers only. Although there is an option on Windows Server 2003 for VPN Callback, it is only available for legacy support and is not recommended for use because of the unnecessary complexity it adds to the VPN. Callback is intended only for dial-up connections and should not be used for VPN connections.

Phase 4: Invoking Network Control Protocols

Once the previous phases have been completed, PPP invokes the various network control protocols (NCPs) that were selected during the link-establishment phase (Phase 1) to configure protocols used by the remote client. For example, during this phase, IPCP is used to assign a dynamic address to the PPP client. In the Microsoft implementation of PPP, the Compression Control Protocol (CCP) is used to negotiate both data compression (using MPPC) and data encryption (using MPPE).

Data-Transfer Phase

Once the four phases of PPP negotiation have been completed, PPP begins to forward data across the tunnel. Each transmitted data packet is wrapped in a PPP header that is removed by the receiving system when it reaches the far destination. If data compression was selected in Phase 1 and negotiated in Phase 4, data is compressed before transmission. If data encryption is selected and negotiated, data is encrypted before transmission. If both encryption and compression are negotiated, the data is compressed first and then encrypted. De-encryption and decompression occur once the packets reach the far end of the tunnel.

Point-to-Point Tunneling Protocol (PPTP)

PPTP encapsulates PPP frames in IP datagrams for transmission over an IP internetwork, such as the Internet. PPTP can be used for remote access and site-to-site VPN connections. PPTP is documented in RFC 2637.

PPTP uses a TCP connection for tunnel management and a modified version of Generic Routing Encapsulation (GRE) to encapsulate PPP frames for tunneled data. The payloads of the encapsulated PPP frames can be encrypted, compressed, or both. Figure 2-6 shows the structure of a PPTP packet containing an IP datagram.

Figure 2-6: Structure of a PPTP packet containing an IP datagram.

Layer Two Tunneling Protocol (L2TP)

L2TP is a combination of PPTP and Layer 2 Forwarding (L2F), a technology proposed by Cisco Systems, Inc. L2TP represents the best features of PPTP and L2F. L2TP encapsulates PPP frames to be sent over IP, X.25, frame relay, or ATM networks. When configured to use IP as its datagram transport, L2TP can be used as a tunneling protocol over the Internet. L2TP is documented in RFC 2661.

L2TP over IP internetworks uses UDP and a series of L2TP messages for tunnel management. L2TP also uses UDP to send L2TP-encapsulated PPP frames as the tunneled data. The payloads of encapsulated PPP frames can be encrypted and/or compressed, although the Microsoft implementation of L2TP does not use MPPE to encrypt the PPP payload. IPSec is used to encrypt the L2TP operations, so MPPE is not needed. Figure 2-7 shows the structure of an L2TP packet containing an IP datagram.

Figure 2-7: Structure of an L2TP packet containing an IP datagram.

In the Microsoft implementation of L2TP, IPSec Encapsulating Security Payload (ESP) is used to encrypt L2TP traffic. The combination of L2TP (the tunneling protocol) and IPSec (the method of encryption) is known as L2TP/IPSec. L2TP/IPSec is described in RFC 3193.

The result after applying ESP to an IP packet containing an L2TP message is shown in Figure 2-8. By combining the properties of L2TP and IPSec, L2TP/IPSec has all the functionality of PPTP while providing all the added security and control of IPSec.

Figure 2-8: Encryption of L2TP traffic with IPSec ESP.

PPTP Compared to L2TP/IPSec

Both PPTP and L2TP/IPSec use PPP to provide an initial envelope for the data, and then append additional headers for transport through the internetwork. However, there are the following differences:

• •With PPTP, the encryption key is based on a hash created by using the password of the authentication process, and therefore data encryption begins after the PPP connection process (and therefore, PPP authentication) is completed. This difference also leads to an inherent weakness in PPTP—the encryption is only as “strong” as the password the user has and thus PPTP is very susceptible to dictionary attacks (which are discussed in the following sidebar). However, with L2TP/IPSec, data encryption begins before the PPP connection process by negotiating an IPSec security association before any credential passing occurs between the client and the server. This means there is no chance of credential capture by a hacker because the entire conversation occurs within the IPSec encrypted tunnel. This structure is the reason that L2TP/IPSec requires certificates or preshared secret keys—it needs to set up the encryption tunnel prior to getting password information, unlike PPTP, which uses the password to create the encryption key hash.

• PPTP connections use MPPE, a stream cipher that is based on the RSA RC4 encryption algorithm and uses 40-, 56-, or 128-bit encryption keys. Stream ciphers encrypt data as a bit stream. Conversely, L2TP/IPSec connections use the Data Encryption Standard (DES), which is a block cipher that uses either a 56-bit key (for DES) or three 56-bit keys (for 3DES). Block ciphers encrypt data in discrete blocks (64-bit blocks, in the case of DES).

• PPTP connections require only user-level authentication through a PPP- based authentication protocol. L2TP/IPSec connections require the same user-level authentication and, in addition, computer-level authentication using computer certificates. The computer-level authentication is usually in the form of certificates that allow the IPSec protocol to set up encryption prior to data passing through the tunnel.

Dictionary attacks occur when a hacker captures packets encrypted with the password hash and runs a program to try to crack that encryption against “well known” dictionary words. If the user does not use strong password methods and does not change passwords on a regular basis, the session can be potentially easily compromised. Strong passwords are composed of alpha, numeric, and symbol characters with both uppercase and lowercase alpha characters. For example: if the client uses “computer” as its password, the client is very susceptible to dictionary attacks because this word can be easily guessed. On the other hand, if the client uses “ComPuTer!1” as the password, there is a much lower chance of an intruder guessing the password. When using strong password methods, PPTP can have as much encryption strength as L2TP/IPSec.

Advantages of L2TP/IPSec Versus PPTP

The following is a list of the advantages of using L2TP/IPSec versus PPTP in Windows Server 2003:

• IPSec ESP provides per-packet data origin authentication (proof that the data was sent by the authorized user), data integrity (proof that the data was not modified in transit), replay protection (prevention from resending a stream of captured packets), and data confidentiality (also known as encryption, which prevents captured packets from being interpreted without the encryption key). In contrast, PPTP provides only per-packet data confidentiality.

• L2TP/IPSec connections provide stronger authentication by requiring both computer-level authentication through certificates and user-level authentication through a PPP authentication protocol.

• In L2TP/IPSec, PPP packets exchanged during user-level authentication are never sent in an unencrypted form because the PPP connection process for L2TP/IPSec occurs after the IPSec security association is established. If intercepted, the PPP authentication exchange for some types of PPP authentication protocols can be used to perform offline dictionary attacks and determine user passwords. By encrypting the PPP authentication exchange, offline dictionary attacks are much more difficult, as the encrypted packets must first be successfully decrypted.

Advantages of PPTP Versus L2TP/IPSec

The following are advantages of PPTP versus L2TP/IPSec in Windows Server 2003:

• PPTP does not require a certificate infrastructure. L2TP/IPSec requires a preshared secrets infrastructure or a certificate infrastructure for issuing computer certificates to the VPN server computer and all VPN client computers.

• PPTP clients can be placed behind a network address translator (NAT) if the NAT has an editor for PPTP traffic. L2TP/IPSec-based VPN clients or servers cannot be placed behind a NAT unless both the VPN client and the VPN server support IPSec NAT traversal (NAT-T). Windows Server 2003 and Microsoft L2TP/IPSec VPN Client support IPSec NAT-T. Microsoft is planning to support IPSec NAT-T for Microsoft Windows 2000 and Windows XP in a future update.

Comparison of L2TP/IPSec, PPTP, and IPSec TM

Table 2-1 provides a complete overview and comparison of L2TP/IPSec vs. PPTP vs. IPSec TM. As the table illustrates, L2TP/IPSec offers the most robust solution and an interoperable standards-based solution. PPTP offers a more deployable solution because it does not require a certificate system or preshared keys, and IPSec TM is mostly vendor-dependent and not standards-based at all, making it the most prohibitive solution in terms of overall security and interoperability on the Internet.

Preshared secrets are insecure in widely deployed IPSec scenarios because the more the preshared secret keys are deployed, the more susceptible they are to compromise. Preshared keys use group-shared keys to gain initial access to the network so that an individual preshared key can be allocated to the client. Because these group-shared keys are seen by everyone and they are a “skeleton” key to the entire network, the more they are deployed the less secure they are. Also, in the rare case of a network security breach, preshared keys are extremely cumbersome to reset and redeploy to all users. Conversely, Certificate Services on Windows Server 2003 can re-establish all certificates quickly and cleanly, and also provide certificate revocation lists to ensure the compromised certificates are identified and blocked.

Tunnel Types

Tunnels can be created in various ways. The two types of tunnels are:

• Voluntary tunnels.A user or client computer can issue a VPN request to configure and create a voluntary tunnel. In this case, the user’s computer is a tunnel endpoint and acts as the tunnel client. This is the standard method for remote access VPN.

• Compulsory tunnels.A VPN-capable dial-up access server configures and creates a compulsory tunnel. With a compulsory tunnel, the user’s computer is not a tunnel endpoint. Another device, the dial-up access server, between the user’s computer and the tunnel server is the tunnel endpoint and acts as the tunnel client.

To date, voluntary tunnels are proving to be the more popular type of tunnel. Voluntary tunnels make no assumptions about the connection methods for a client to access the intermediary network, usually the Internet—the client can use any method she chooses when connecting to the ISP this way and it will not affect VPN operations. Compulsory tunneling assumes that a given connection method will be used, thus limiting the options available to the client for connectivity. The following sections describe each of these tunnel types in greater detail.

Voluntary Tunneling

Voluntary tunneling occurs when a workstation or routing server uses tunneling client software to create a virtual connection to the target tunnel server. To accomplish this, the appropriate tunneling protocol must be installed on the client computer. For the protocols discussed in this book, voluntary tunnels require an IP connection (either LAN or dial-up).

In a dial-up situation, the client must establish a dial-up connection to the internetwork before the client can set up a tunnel. This is the most common case. The best example of this is the dial-up Internet user, who must dial an ISP and obtain an Internet connection before a tunnel over the Internet can be created.

For a LAN-attached computer, the client already has a connection to the internetwork that can provide routing of encapsulated payloads to the chosen LAN tunnel server. This would be the case for a client on an organization’s LAN that initiates a tunnel to reach a private or hidden subnet on that LAN.

It is a common misconception that VPN connections require a dial-up connection. They require only IP connectivity between the VPN client and VPN server. Some clients (such as home computers) use dial-up connections to the Internet to establish IP transport. This is a preliminary step in preparation for creating a tunnel and is not part of the tunnel protocol itself. A good example of this is broadband Internet connectivity. Home users today frequently have cable modem or xDSL for high- speed Internet connectivity. These technologies are “always on” in the sense that they always have active Internet connectivity available to them. “Dialing up” is therefore an unnecessary step for broadband users.

Compulsory Tunneling

A number of vendors that sell dial-up access servers have implemented the ability to create a tunnel on behalf of a dial-up client. The computer or network device providing the tunnel for the client computer is variously known as a front-end processor (FEP) for PPTP or an L2TP Access Concentrator (LAC) for L2TP. For the purposes of this chapter, the term FEP is used to describe this functionality, regardless of the tunneling protocol. To carry out its function, the FEP must have the appropriate tunneling protocol installed and must be capable of establishing the tunnel when the client computer connects.

In the Internet example, the client computer places a dial-up call to a tunneling- enabled NAS at the ISP. For example, a corporation might have contracted with an ISP to deploy a nationwide set of FEPs. These FEPs can establish tunnels across the Internet to a tunnel server connected to the organization’s private network, thus consolidating calls from geographically diverse locations into a single Internet connection at the organization’s network.

This configuration is known as compulsory tunneling because the client is compelled to use the tunnel created by the FEP. Once the initial connection is made, all network traffic to and from the client is automatically sent through the tunnel. With compulsory tunneling, the client computer makes a single PPP connection. When a client dials into the NAS, a tunnel is created and all traffic is automatically routed through the tunnel. An FEP can be configured to tunnel all dial-up clients to a specific tunnel server. The FEP could also tunnel individual clients, based on the user name or destination.

Unlike the separate tunnels created for each voluntary client, multiple dial-up clients can share a tunnel between the FEP and the tunnel server. When a second client dials into the access server (FEP) to reach a destination for which a tunnel already exists, there is no need to create a new instance of the tunnel between the FEP and tunnel server. Instead, the data traffic for the new client is carried over the existing tunnel. Because there can be multiple clients in a single tunnel, the tunnel is not terminated until the last user of the tunnel disconnects.

Although some facets of compulsory tunneling might seem attractive at first, the overall supportability, administration, and exorbitant cost of the compulsory tunnel model make it less popular than the voluntary tunnel model, which is the prevalent VPN standard today.