The Complete Cisco VPN Configuration Guide - page 36

Here is a quick review of some of PPTP's features:

• Compression Compression of data is handled by Microsoft's Point-to-Point Compression (MPPC) protocol within the PPP payload. This is supported by both PPTP and L2TP and normally enabled for dialup clients .

• Encryption Encryption of data is handled by Microsoft's Point-to-Point Encryption (MPPE) protocol within the PPP payload. The encryption uses RSA's RC4 encryption algorithm. PPTP uses this method, whereas L2TP uses IPsec, which is more secure. With MPPE, the initial key created during user authentication is used for the encryption algorithm and is regenerated periodically.

• User authentication User authentication is achieved using PPP's authentication methods, such as PAP or CHAP, and others, such as EAP. MPPE support requires the use of MS-CHAPv1 or v2. If you use EAP, you can choose from a wide range of authentication methods , including static passwords and one-time passwords (through the use of token cards).

• Data delivery Data is packetized using PPP, which is then encapsulated in a PPTP/ L2TP packet. By using PPP, PPTP can support multiple transport protocols, such as IP, IPX, NetBEUI, and others.

• Client addressing PPTP and L2TP support dynamic addressing of the client using PPP's Network Control Protocol (NCP). As mentioned in the last chapter, the Cisco IKE Mode Config supports a similar function.

To help you understand the inner workings of PPTP, the following sections cover these topics:

• Review of PPP

• PPTP Components

• How PPTP Works

• Issues with the Use of PPTP

PPP Review

Because PPTP leverages the use of PPP, I'll briefly review PPP in this section. PPP originally was designed to transmit data across dialup or point-to-point links. It supports the encapsulation of many Layer-2 and Layer-3 protocols as a transport.

PPP connections will go through four phases when establishing a connection:

The following sections discuss each in turn .

PPTP Phase 1

In phase 1, the Link Control Protocol (LCP) is used to initiate the connection. This includes the negotiation of Layer-2 parameters, such as the use of authentication, compression with MPPC, encryption with MPPE, protocols, and other PPP featuresthe actual compression or encryption algorithms are negotiated in phase 4.

PPTP Phase 2

In phase 2, the user is authenticated to the server. PPP supports four types of authentication:

• PAP

• CHAP

• MS-CHAPv1

• MS-CHAPv2

The Password Authentication Protocol (PAP) provides clear-text authentication of a user's name and password. This is not secure because it is susceptible to eavesdropping and replay attacks, and therefore is not commonly used. PAP also has a problem with session hijacking.

The Challenge Handshake Authentication Protocol (CHAP), unlike PAP, doesn't send a password between the peers; instead, only the username is sent in clear text. The user's username and password must be listed on the server. The server sends back a random challenge string and a session ID number for the PPP session. Each side takes the challenge, the session ID, and the user's password and runs them through the MD5 HMAC function, producing a digital signature. The user sends the signature to the server, which validates it. Because the password is never sent across the network and a random challenge is used, CHAP protects against replay attacks once the original PPP session is terminated . To increase security, PPP periodically uses CHAP on an existing connection to reduce the likelihood of a session hijacking attack taking place.

An extension of CHAP is the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). MS-CHAP allows the server to store the digital signature of a user instead of the user's password, providing an additional level of security. MS-CHAP has other enhancements, including password expiration notification, user password changing, additional error codes, and data encryption using MPPE. Therefore, CHAP and MS-CHAP are not compatible with each other. The first implementation of MS-CHAP is referred to as MS-CHAPv1.

Microsoft developed an enhanced version of MS-CHAP called MS-CHAPv2. v2 updated the encrypted authentication process, in which each device needs to authenticate to the other. Through this process, two unidirectional data pipes are established, allowing for a different encryption key for each connection between the peers.

Note

The server can store the user's credentials locally, or this can be found on an external server, such as an AAA RADIUS server product.

PPTP Phase 3

Phase 3, an optional phase, provides control of callback functions through the use of the Callback Control Protocol (CBCP). If callback is enabled, once the authentication phase completes, the server disconnects the client and calls the client back based on the phone number the server has in its database for the client. This can be used to provide an extra layer of security, restricting users to use a specific phone to make connections, and reducing the likelihood of access attacks. This phase is performed for dialup clients only.

PPTP Phase 4

In phase 4, the protocols used for the data connection, which were negotiated during phase 1, are invoked. These protocols include IP, IPX, data compression algorithms, encryption algorithms, and others. Once phase 4 completes, data can now be sent across the PPP connection.

PPTP Components

As mentioned in the last section, PPTP uses PPP. However, it doesn't change the PPP protocol; instead, PPP is used to tunnel packets through an IP backbone. PPTP is based on a client-server architecture for remote access connectivity involving two entities:

• The client is commonly referred to as a PPTP Access Concentrator (PAC). The term "concentrator" can be misleading, because in the Cisco world it is commonly used to refer to a device terminating remote access sessions; however, with PPTP, this function can be split between two devices, a PC and a server. Originally this was done to offload the encryption process on a more appropriate device (a concentrator); however, you can easily combine the two processes (PPP and protection) into a single device, like a PC. The PAC is responsible for establishing a secure connection to a server and tunneling data, via PPP packets, to the server.

• The server is a PPTP Network Server (PNS). The server is responsible for terminating the tunnel from the PAC; it takes the tunneled protected PPP packets, verifies the protection, decrypts the packets, and forwards the encapsulated PPP payload informationfor example, an IP packet to the destination.

The PAC is responsible for initiating a connection to the PNS, using LCP for negotiation, and participating with the PPP authentication process. The PNS is responsible for authenticating the PAC, handling PPP Multilink for channel aggregation and bundle management, terminating the NCP protocols, and routing or bridging the PAC's encapsulated traffic to other locations. The use of multilink is unusual in this situation because it allows the use of multiple PACs to transmit the same data stream to a single PNS.

Note

Please note that I use the word "entities" to describe the PAC and PNS, and not "devices." This is because the PAC and PNS describe roles to be played and don't necessarily have to reside in the device initiating or receiving connections. From this perspective, you could view it as an IPsec site-to-site connection or an IPsec remote access network extension mode connection, where the PAC performs the role of the client and PNS performs the role of the gateway.

Two connections are built between the PAC and the PNS:

• A control connection used for call control and management functions. This control connection uses TCP and therefore, both the PAC and PNS must support TCP/IP; however, other protocols can be transported across the data connection.

• A data connection that uses an extended version of the Generic Route Encapsulation (GRE) protocol (this is IP protocol 47). This protocol provides for delivery, flow control, and congestion management of the tunneled PPP packets. The flow control and congestion management implemented for the extended version of GRE are simple in nature; they allow for the efficient use of available bandwidth while avoiding any unnecessary data transmissions because of buffer overruns. PPTP doesn't define the actual algorithms that should be used for these processes, but does define that this information is communicated between the PAC and PNS.

How PPTP Works

This section will provide an overview of how PPTP works. PPTP is a connection-oriented protocol in which the PAC and PNS maintain a state for their connection. This session is created when the PAC initiates a PPP connection to the PNS. Two connections are built for the session: a control connection and a data connection. Once the session is established, the PAC and PNS can use GRE across the data connection to transmit user traffic. Generically, the data connection is called a tunnel.

The following sections will cover these two connections in more depth, and also will cover how a PPTP session is established and used.

Control Connection

The control connection is responsible for establishing, maintaining, and tearing down the data tunnel. It uses TCP as a transport to carry this information with a destination port number of 1,723. This connection can be established either from the PNS or the PAC.

There are two basic types of PPTP messages that can be used in the control connection:

• Control

• Management (this is currently not defined in the RFC)

A magic cookie is included in each control message. It is used to ensure that the sender and receiver are synchronized on the TCP connection. If there is a loss of synchronicity between the PAC and PNS, the TCP connection terminates immediately.

Setting Up the Control Connection

The setup of the control connection encompasses the exchange of two initial messages:

• Start-Control-Connection-Request

• Start-Control-Connection-Reply

The initiator sends the first message while the receiver responds with the second one. Table 4-1 describes the results that can be included in the reply message. Besides initiating the connection, these messages allow the PAC to share capability information with the PNS. Each PNS/PAC pair requires a separate control connection.

Table 4-1. Start-Control-Connection-Reply Results

Because both the PNS and PAC can initiate a control connection, there is a possibility of a collision if both try to do it simultaneously; only one control connection can exist between the PAC and PNS. A collision occurs when both the PAC and PNS simultaneously send Start-Control-Connection-Request messages. In this situation, the initiator with the highest IP address (compared as a 32-bit number) is used and the other control connection is immediately terminated.

Because there are different control versions, there is a possibility that one peer has a higher version than the other. In this case, one of two things will occur on the receiver:

• If the receiver's version is higher or the same, it will use the lower version of the sender and send back a Start-Control-Connection-Reply message and continue with the building of the connection.

• If the receiver's version is lower and it cannot support the requested version, it will send a Start-Control-Connection-Reply message and terminate the TCP connection; at this point, it is up to the sender to use a compatible version with the receiver when re-initiating the connection.

Maintaining the Control Connection

Keepalives are used on the control connection to ensure that connectivity exists between the PAC and PNS, and that any failure of either two devices can be quickly detected . There are two types of keepalive messages for the control connection:

• Echo-Request

• Echo-Reply

Both the PAC and PNS can initiate keepalives. Keepalive messages are generated if no type of control message is received from a peer in 60 seconds. If a PAC/PNS doesn't receive an Echo-Reply in response to its request, the control connection will be terminated.

Terminating the Control Connection

The control connection is also responsible for terminating any data connections and for the control connection itself. To terminate the control connection, two messages are used:

• Stop-Control-Connection-Request

• Stop-Control-Connection-Reply

Both the PAC and PNS can initiate the teardown process of the control connection. Whenever the control connection is terminated, any data (user) connections are also terminated automatically. Table 4-2 lists some reasons why the control connection might be terminated. The next section covers the data (tunnel) connection.

Table 4-2. Stop-Control-Connection-Request Reasons

Note

If an invalid or misconfigured control message is received, the correct information should be logged and the control connection is automatically terminated and rebuilt to recover from the error.

Tunnel Connection

The tunnel carries all user session PPP packets. GRE is used as the transport protocol for the PPP packets. The control connection determines the actual rate and buffering parameters to use to ensure that the PAC/PNS do not create flow-control problems. Other parameters that need to be negotiated are the PAC address assignment, the encryption algorithm to use, and the use of compression, if any. The following sections will discuss how the user's data is encapsulated and transported across the tunnel.

Setting Up the Tunnel Connection

Once the Start-Control-Connection-Request and Start-Connection-Reply messages have been exchanged for the control connection, the setup of the tunnel (data) connection is next. The following messages are possibly involved in this process:

• Outgoing-Call-Request

• Outgoing-Call-Reply

• Incoming-Call-Request

• Incoming-Call-Reply

• Incoming-Call-Connected

Note

I don't like the use of the term "call" in these messages, since most people would equate it with the use of telephone calls. Remember that PPP is being used here, which is normally a dialup solution, so a lot of PPP's implementation and nomenclature are found here when dealing with PPP and PPTP. The term "session" would be a more precise term, or perhaps "tunnel" in the loosest sense.

Outgoing calls are messages generated by the PNS to the PAC, telling the PAC to establish a tunnel to the PNS. This connection also provides information concerning the regulation of data transmitted across the tunnel from the PAC to the PNS, such as windowing information. The outgoing reply is sent from the PAC to the PNS, with the possible results in the reply listed in Table 4-3. An interesting point about the information for the result codes is that many of these are related to telephony, which is where PPP is typically used. For most situations, only codes 1, 2, 6, and 7 are used because the PAC functionality is built directly into the actual client instead of an intermediate device.

Table 4-3. Outgoing-Call-Reply Results

Tip

According to the RFC, the outgoing call request is made from the PNS to the PAC; however, my experience with Microsoft's implementation is that it is the reverse: The PAC initiates the outgoing call request to the PNS. A key, called a caller ID value, is placed in the tunnel packet header to indicate which session a PPP packet belongs to because PPP can multiplex traffic across multiple sessions. This value is negotiated during the call setup process on the control connection.

The Incoming-Call-Request message is sent by the PAC to the PNS to indicate that an inbound call is to be established from the PAC to the PNS. This message allows the PNS to obtain information about the call before it is answered or accepted. The Incoming-Call-Reply message is sent from the PNS to the PAC, replying to the acceptance or denial of the connection request. This message can also contain flow control information the PAC should use in tunnel communications to the PNS. Table 4-4 shows the possible results from the PNS.

Table 4-4. Incoming-Call-Reply Results

The Incoming-Call-Connected message is sent from the PAC to the PNS in response to the reply. Therefore, incoming calls use a three-way handshake: request, reply, and connected.

Encapsulating the Payload

GRE is used to carry the PPP packets between the PAC and PNS. Figure 4-1 shows an example of a PPTP packet. As you can see, the PPP packet is encapsulated in a GRE packet, which, in turn, is encapsulated in an IP packet. The PPP packet contains the actual user data which is some protocol packet such as IP, IPX, or another type.

The GRE header used to encapsulate the PPP packet is not a standard GRE header, but has been enhanced slightly for PPTP. The main difference between the standard GRE header and the PPTP GRE header is that the PPTP GRE header has a new acknowledgment number field, which is used to determine whether or not a GRE packet(s) has been received by the tunnel endpoint. This GRE acknowledgment process has nothing to do with the actual user data packets; instead, it is used to determine packet rates for packets transmitted via the tunnel. In other words, PPTP uses a sliding window protocol for flow control of the tunneled packets by using the sequence and acknowledgment fields. The window size can be changed dynamically throughout the tunnel's lifetime. PPTP will not retransmit packets that are lost or that arrive outside the window time frame: this is the responsibility of the source device.

Maintaining the Tunnel Connection

The tunnel connection parameters, such as windowing, are negotiated when the tunnel connection is built. Likewise, the parameters can be changed for the tunnel based on current network conditions. The PAC and PNS use a Set-Link- Info message to share tunnel operation parameters. Typically, the PNS sends this message to the PAC to indicate any tunnel/PPP configuration changes.

Tearing Down a Tunnel Connection

When a tunnel connection is no longer needed, it is torn down by the PPTP devices. Two messages are exchanged to handle the teardown process:

• Call-Clear-Request

• Call-Disconnect-Notify

Both the PAC and PNS can initiate a teardown of the tunnel connection. The Call-Clear-Request message is sent from the requestor, signaling that the tunnel connection is being cleared (torn down). The receiver responds with a Call-Disconnect-Notify message, indicating the status of the tunnel clear request.

Example PPTP Connection

Now that I've explained the basic process and messages used to set up a PPTP connection, I'll go through a simple example of a PPTP connection being built, maintained , and then torn down in the following sections.

Here's a brief overview of the setup of a typical PPTP session:

If no messages are received on the control connection for 60 seconds, the PNS (typically) will send Echo-Request messages to the PAC; and assuming the PAC is reachable, the PAC will respond with an Echo-Reply message. These messages are used to ensure that the tunnel endpoints are still alive and reachable .

Eventually the tunnel connection is torn down. Some common reasons for tearing down a tunnel (and control connection) include:

• Reachability problems have been found.

• An error condition exists.

• The PAC or PNS is shutting down.

• The tunnel is no longer needed.

Here is an example of a PAC terminating its PPTP session to a PNS:

Issues with the Use of PPTP

As in any VPN implementation, you'll have to deal with certain issues for PPTP to perform optimally and with minimal problems. Here are some common issues you'll need to deal with:

• Fragmentation problems

• Security concerns

• Address translation issues

The following sections will address these issues.

Fragmentation Problems

The MTU of the PPP information that is encapsulated in GRE is 1,532 bytes. On top of this, you have the GRE and the IP headers. The GRE header is 16 bytes in length and the IP header is between 20 and 60 bytes, depending on whether or not the IP Options field is used. Therefore, the total length of a PPTP tunneled packet could be 1,608 bytes. And this doesn't even count the outer Layer-2 header. If Ethernet II was used, you would need to add an additional 20 bytes, totaling 1,628. Of course, if it was a dialup connection, you would have to consider the overhead of the PPP data-link protocol to transport the PPTP information between the client and ISP access server.

Because most devices use an MTU size of 1,500 bytes, this can cause these devices to have to fragment each PPTP packet across two frames . This is a very undesirable result, because not only is encryption being done by PPTP, but now there is fragmentation of the protected packets, and the destination has to reassemble the fragments into complete packets and then decrypt them.

More than 60 percent of the throughput problems I've dealt with concerning VPNs have dealt with fragmentation problems. Therefore, you'll definitely want to adjust your PAC's and PNS's MTU size to a better size. Many vendors suggest 1,300 bytes to play it safe; but you could probably increase this to 1,320 or 1,340 and be okay. However, you will definitely want to monitor your PPTP connection to ensure that fragmentation is not occurring.

Security Concerns

There are three security concerns you should consider when using PPTP:

• Session hijacking and data manipulation of the control connection

• No protection for the IP, GRE, and PPP header information

• Weak encryption

There is no security protection for the TCP control connection used by PPTP: the messages sent between the PAC and PNS have no authentication or data integrity check. Therefore, it is susceptible to data manipulation and session hijacking attacks. For example, an attacker could create fake control messages or alter valid ones while the messages are in transit between the PAC and PNS. Likewise, an attacker could execute a session hijacking attack, taking over the control connection and pretending to be the PAC, PNS, or both.

Another security concern is that the IP, GRE, and PPP header information is not protected in the tunnel connection. Therefore it is possible for an attacker to eavesdrop on the tunnel connection and modify these, or hijack the session (as is the case with the control connection).

Caution

Be aware that only the PPP payload is encrypted with PPTP: any other information, such as the control connection and the headers of the tunnel connection, are not protected. Plus, MPPE supports RC-40 and RC-128 for encryption, both of which are known to be vulnerable.

Address Translation Issues

Address translation can pose a problem with the use of PPTP. There are two general types of translation: NAT and PAT. NAT poses no problems for both the control and tunnel connections because the headers in these are not protected by an HMAC function, and NAT changes only source or destination IP addresses.

However, PAT can create problems. Because the control connection uses TCP, and the TCP header isn't protected, the control connection easily can be established through an address translation device performing PAT. The same cannot be said about the tunnel connection. Because the tunnel connection uses GRE, a Layer-3 protocol, and GRE doesn't have port numbers , PAT doesn't work.

Some vendors have implemented proprietary solutions to get around this problem. Most vendors will use the caller ID field in the GRE header to denote different connections.

However, if more than one device was using the same caller ID in the tunnel header, the address translation device would have to translate the caller ID values to ensure uniqueness. This performs a similar function to what PAT does with TCP or UDP port numbers. Remember that not all address translation devices support this function, and your PPTP connections might break when going through address translation devices.

Note

PPTP isn't used much anymore because of security concerns regarding MS-CHAPv1 and MS-CHAPv2 being needed as part of the MPPE generation process; moreover, its two encryption algorithms are known to be vulnerable.