Technical Overview of PPTP
Because Cisco routers do not support compulsory tunnel mode with PPTP, only voluntary tunnel mode is examined in this chapter.
Voluntary tunnel mode, unlike compulsory tunnel mode, is initiated by the remote access client itself. In this mode of operation, the remote access client acts as the PNS, with the tunnel being established directly to the PAC.
PPTP provides for two distinct channels of communication between the remote access client/PNS and the PAC:
The control connection/channel
The control connection is used to exchange control messages between the remote access client/PNS and the PAC. These control messages allow the establishment and termination of client sessions and perform such functions as keepalive, error reporting, and link parameter configuration.
The (user) data tunnel
The data tunnel allows the forwarding of PPP frames between the remote access client/PNS and the PAC. In compulsory tunnel mode, it is possible to multiplex multiple user PPP sessions over the tunnel. In voluntary tunnel mode, however, only one user session is maintained.
Note that control channel and data tunnel connections between the remote access client/PNS and PAC are separate and distinct. Control channel transport is provided for via a TCP connection, whereas data tunnel transport is provided for via Enhanced GRE.
Figure 3-3 illustrates control channel and data tunnel connectivity between the remote access client/PNS and the PAC.
The following few sections describe PPTP operation and examine control channel setup, session establishment, PPP negotiation, tunnel maintenance, and session and control channel termination.
PPTP Control Channel Setup
The control channel must be established before any user PPP sessions are established over a tunnel between the PNS and the PAC. The control channel setup is initiated by the remote access client/PNS over a TCP connection that utilizes destination port 1723. According to RFC 2637, the source port should simply be an unused port.
RFC 2637 discusses two types of message that may be sent over a Control Connection between the PNS and the PAC:
Management Messages are presently not defined.
Figure 3-4 shows the overall control channel packet format.
Control Messages are used to establish and maintain the control connection itself, to manage calls, to report errors, and to control the PPP session.
Table 3-1 summarizes PPTP Control Message types.
Table 3-1. PPTP Control MessagesMessage Code | Control Message |
|---|
1 | Start-Control-Connection-Request (SCCRQ) | 2 | Start-Control-Connection-Reply (SCCRP) | 3 | Stop-Control-Connection-Request (StopCCRQ) | 4 | Stop-Control-Connection-Reply (StopCCRP) | 5 | Echo-Request | 6 | Echo-Reply | 7 | Outgoing-Call-Request (OCRQ) | 8 | Outgoing-Call-Reply (OCRP) | 9 | Incoming-Call-Request (ICRQ) | 10 | Incoming-Call-Reply (ICRP) | 11 | Incoming-Call-Connected (ICCN) | 12 | Call-Clear-Request (CCRQ / ClearRQ) | 13 | Call-Disconnect-Notify (CDN) | 14 | WAN-Error-Notify (WEN) | 15 | Set-Link-Info (SLI) |
Establishment of the Control Channel itself begins with the transmission of a Start-Control-Connection-Request (SCCRQ) message from the remote access client/PNS to the PAC.
As the name suggests, the function of the SCCRQ message is to initiate establishment of the control connection between the PNS and PAC.
Figure 3-5 shows the format of the SCCRQ.
As Figure 3-5 depicts, the SCCRQ message format consists of the following fields:
As the name suggests, the Length field indicates the length of the PPTP message, including the PPTP header itself. The PPTP Message Type field is set to a value of 1 to indicate that this is a Control Message. The Magic Cookie field holds a constant value irrespective of the control message type. The value of the Magic Cookie is 0x1A2B3C4D. The function of the Magic Cookie is to ensure that the receiver of the message (PNS or PAC) is synchronized with the control connection TCP data stream. The Control Message Type field value for the SCCRQ is 1. The Reserved0 field is set to a value of 0. This field is designed to allow future expansibility of PPTP. Protocol Version defines the version and revision number of PPTP being requested by the sender (the remote access client/PNS in this case). This field is four octets wide, with the first two octets describing the version number, and the last two octets the revision number. The Reserved1 field is also reserved for future use and should be set to a value of 0.
NOTE
Note that the Length, PPTP Message Type, Magic Cookie, and Reserved0 fields are present in all PPTP control messages.
Framing Capabilities indicates the type of framing that the sender of the SCCRQ can support. Although this field is 32 bits wide, only two bit settings are currently defined. If bit 1 is set, asynchronous framing is supported, and if bit 2 is set, synchronous framing is supported. Bearer Capabilities, the next field, is similar. Although 32 bits wide, only two bit settings are defined. Bit setting 1 indicates that analog access is supported, and bit setting 2 indicates that digital access is supported. The Maximum Channels field is used by the PAC in compulsory tunnel mode to specify the number of user (PPP) sessions that can be supported within the tunnel. In voluntary tunnel mode, the remote access client/PNS sets this field to a value of 0. The Firmware Revision field specifies the firmware revision number or software driver version of the remote access client/PNS. The Host Name field contains the DNS name of the sender of the SCCRQ. The Vendor Name field contains vendor-specific information, such as the type of software being used by the remote access client/PNS.
The PAC responds to the SCCRQ message with a Start-Control-Connection-Reply (SCCRP) message. This message indicates whether the control channel has been successfully established or whether an error condition has resulted.
Figure 3-6 illustrates the exact format of the SCCRP message.
The SCCRP message format consists of many of the same fields as the SCCRQ message format. After the Protocol Version field, the message format begins to look a little different than that of the SCCRQ (see Figure 3-5). The significant fields for the SCCRP message format that differ from the SCCRQ message format are described as follows:
The Control Message Type field contains a value of 2, which indicates that this message is a SCCRP. The Result Code field is an 8-bit field that is used to indicate one of five conditions or results. Table 3-2 summarizes the possible result codes, together with their associated meaning. Table 3-2. Result CodesResult Code | Meaning |
|---|
1 | Successful channel establishment | 2 | General error (Error Code specifies) | 3 | Command channel already exists | 4 | Requester is not authorized to establish command channel | 5 | Protocol version of the requester is not supported |
Should a General Error be indicated by the Result Code (code 2), the next field, Error Code, indicates the specific error that has caused the control connection to fail. Table 3-3 summarizes the Error Codes, together with their meanings. Table 3-3. Error CodesGeneral Error Code | Meaning |
|---|
0 | No general error | 1 | No control connection exists yet for this remote access client/PNS-PAC pair | 2 | Length is wrong or Magic Cookie value is incorrect | 3 | One of the field values was out of range/reserved field was non-zero | 4 | Insufficient resources to handle this command now | 5 | The Call ID is invalid in this context | 6 | Vendor specific error (for errors on PAC) |
Note that if a General Error should not be indicated in the Result Code field (in other words, any value other than 2 is contained within the field), the Error Code field should be set to 0.
Figure 3-7 shows the exchange of messages to enable the establishment of the control channel from the PNS to the PAC.
PPTP Session Establishment
Once the control channel has been established between the remote access client/PNS and the PAC, the remote access client/PNS signals that it wishes to establish a client session. This is done by sending an Outgoing-Call-Request (OCRQ) message over the control channel.
The OCRQ was originally designed to be sent by the PNS to the PAC in compulsory tunnel mode. Its purpose was, as the name suggests, to signal the PAC to make an outgoing call to an end user or client.
In voluntary tunnel mode, the remote access client/PNS sends an OCRQ to the PAC to signal that the remote access client/PNS wishes to establish a PPP session within the PPTP tunnel.
Figure 3-8 shows the packet format for the OCRQ message.
As Figure 3-8 depicts, the OCRQ message format consists of the following fields. (Explanations of fields already described have been omitted unless they differ based on packet relevance.)
The Control Message Type field is set to a value of 7 to indicate that this message is an OCRQ. Skipping the Reserved0 field, the next field is Call ID. This field is a unique identifier for a particular PPP session within the overall PPTP tunnel. The Call ID is essential in a compulsory tunnel mode environment to disambiguate the different sessions within the tunnel. In a voluntary tunnel mode environment, there is only one session but the Call ID remains. Note that the Call ID is locally unique, meaning that the remote access client/PNS and the PAC may use different Call IDs to identify the same session. The Call Serial Number field has a similar function to that of the Call ID. The purpose of the Call Serial number is again to identify uniquely the session within the tunnel but only for session logging purposes. It is worth noting that the Call Serial Number, unlike the Call ID, is globally unique (that is, the remote access client/PNS and the PAC use the same number to identify the same session). The Minimum BPS field specifies the minimum line speed (in bits per second) that would be acceptable to the remote access client/PNS. The Maximum BPS field specifies the maximum line speed (in bits per second) that would be acceptable to the remote access client/PNS. The Bearer Type field is used in compulsory tunnel mode to specify the bearer type that the outgoing call should be made with. The possible bearer types are: 1 = analog, 2 = digital, and 3 = any. The Framing Type field is similar in nature to the Bearer Type field and indicates the type of PPP framing that should be used. There are three possible values: 1 = asynchronous, 2 = synchronous, and 3 = any. The Packet Recv. Window Size field is used for flow control and specifies the number of packets that are buffered for a particular session. The Packet Processing Delay (PPD) field is again used for flow control purposes and specifies the time required to process the maximum amount of data in the buffer. The time is specified in tenths of a second. The final three fields (excluding Reserved1, which has been previously described) are Phone Number Length, Phone Number, and Subaddress. Again, these three fields are relevant only to compulsory tunnel mode. They are used to specify the telephone number (and subaddress) to call. In voluntary tunnel mode, all three fields are set to a value of 0 (by the remote access client/PNS).
The PAC replies to the OCRQ from the remote access client/PNS with an Outgoing-Call-Reply (OCRP) message. In compulsory tunnel mode, this message is used to signal the result of the outgoing call. In voluntary tunnel mode, however, it is simply used to signal the success or otherwise of the session establishment attempt from the remote access client/PNS.
Figure 3-9 illustrates the packet format of the OCRP.
As Figure 3-9 depicts, the OCRP message format consists of the following fields (explanations of fields already described have been omitted unless they differ based on packet relevance):
The Control Message Type field is set to a value of 8, which indicates that this message is an OCRP. The Call ID field is used to identify uniquely the session within the PPTP tunnel. This value is locally unique to the PAC. You may be wondering how the remote access client/PNS is going to associate the OCRP from the PAC with the OCRQ that it sent if the Call ID in the OCRP is local to the PAC. The answer is the next field, the Peer's Call ID. This is set to the value of the Call ID in the OCRQ sent from the remote access client/PNS. With this information, the remote access client/PNS can associate this OCRP message with the OCRQ that it sent. The Result Code field is significant. It is used to indicate the success or failure of the session establishment attempt (the OCRQ). Although RFC 2637 specifies seven different possible result codes, most of these are relevant only for compulsory tunnel mode. Only three codes have possible relevance for voluntary tunnel mode: 1 = Call (session) established with no errors, 2 = Outgoing call (session) not established for the reason specified in the Error Code field (this is known as a General Error), and 7 = Outgoing call (session) administratively prohibited. The Error Code field is a nonzero value if the Result Code field is set to a value of 2 (General Error). Table 3-3 summarizes the possible error codes. The Cause Code field is designed to provide additional error information. In compulsory tunnel mode, in the event of ISDN call failure, the Q.931 cause code could be communicated in this field, for example. The Physical Channel ID field is used in compulsory tunnel mode and specifies the physical channel used to dial out from the PAC.
Figure 3-10 shows the call session establishment sequence between the remote access client/PNS and the PAC.
PPP Negotiation and Frame Forwarding
After the exchange of OCRQ and OCRP messages, PPP negotiation takes place between the remote access client/PNS and the PAC.
The PPP negotiation sequence between the remote access client/PNS and the PAC consists of:
1. | LCP negotiation
| 2. | PPP authentication
| 3. | NCP negotiation
|
These negotiations proceed as they would between directly connected PPP peers. Once PPP negotiation is complete, regular PPP frame forwarding can take place over the tunnel between the remote access client/PNS and the PAC.
Figure 3-11 illustrates the PPP negotiation phase, together with PPP frame forwarding (post negotiation).
PPP frames sent between the remote access client/PNS and the PAC are forwarded over the data tunnel and are encapsulated in Enhanced GRE packets.
Enhanced GRE differs from regular GRE in that it provides congestion and flow control (something not provided by regular GRE).
Figure 3-12 shows the Enhanced GRE header.
The bits and fields in this header are described as follows:
The C, R, K, S, and s bits indicate the presence of a checksum, routing, a key, a sequence number, and strict source routing, respectively. The Recur (Recursion Control) bits are all set to 0. The A bit indicates the presence of an acknowledgment number. Note that the A bit is not present in the regular GRE header. The Flags bits are all set to 0. Importantly, the Ver (Version) field is set to a value of 1. This indicates Enhanced GRE. The Protocol Type field must be set to a value of 0x880B (the Ethertype for PPP). The low two octets of the Key field are set to equal the Call ID for this session. PPTP uses the high two octets of the key field to indicate the size of the packet payload (not including the GRE header). The two final fields are the Sequence Number and Acknowledgement Number fields. The presence of these two fields is dependent on the setting of the S and A bits, respectively. The Sequence Number field contains the sequence number of the payload, and the Acknowledgement Number field contains the sequence number of the highest numbered Enhanced GRE packet received. Note that the Acknowledgement field is not present in the regular GRE header.
Enhanced GRE packets are themselves encapsulated within IP (protocol 47).
Figure 3-13 shows the data tunnel packet encapsulation.
PPTP Tunnel Maintenance
PPTP also provides a keepalive mechanism that operates over the control channel. This keepalive mechanism allows the control connection to be closed down in a timely fashion should there be a connectivity failure of some kind between the remote access client/PNS and the PAC.
The keepalive mechanism consists of Echo-Request and Echo-Reply messages and operates as follows: If there is no activity on the control channel for 60 seconds, an Echo-Request message is sent. An Echo-Reply message should then be received back from the peer within 60 seconds. If it is not, then the control channel is terminated.
Figure 3-14 shows the packet format for the Echo-Request message.
As you can see, the message format is very simple:
The Control Message Type field is set to a value of 5 to identify this message as an Echo-Request. The Identifier field is a unique value set by the sender of the message (either remote access client/PNS or PAC).
Figure 3-15 illustrates the format of the Echo-Reply packet.
Again, the message format is very simple:
The Control Message Type field is set to a value of 6 to indicate that this message is an Echo-Reply. The Identifier field is set to the same value as the Identifier field in the received Echo-Request. This allows the sender to match the Echo-Reply to the original Echo-Request message. The Result and Error codes are used to indicate the validity of the Echo-Request and any error conditions generated. The Result Code field can have one of two values: 1, which indicates that the Echo-Request is valid, and 2, which indicates that the Echo-Request was not accepted. If the Echo-Request was not accepted, then the error condition is indicated in the Error Code field. The Error Code field is set to 0 if the Result Code was 1. If the Result Code is 2, the General Error condition is indicated in this field. Table 3-3 earlier in this chapter summarized the General Error conditions.
Figure 3-16 shows the PPTP keepalive mechanism.
In Figure 3-16, the Echo-Request is sent from the remote access client/PNS to the PAC. It should be noted that this message can be sent by either the remote access client/PNS or the PAC.
PPTP Session and Control Channel Termination
In voluntary tunnel mode, if either the remote access client/PNS or the PAC wishes to terminate the PPTP tunnel, the call (session) is first torn down, followed by the control connection. The exact sequence of messages used to terminate the PPTP tunnel depends on whether the termination is initiated by the remote access client/PNS or by the PAC.
Note that all session and control channel termination messages are sent over the control channel.
If the remote access client/PNS wishes to terminate the session, it sends a Call-Clear-Request (CCRQ, or ClearRQ). The PAC then replies to this with a Call-Disconnect-Notify (CDN).
Figure 3-17 shows the format of the CCRQ message.
The CCRQ packet fields of significance are as follows:
Figure 3-18 illustrates the CDN packet format.
The CDN packet fields of significance are as follows:
The Control Message Type field is set to 13 to indicate that this is CDN message. The Call ID field is set to identify the particular call (session) that is being cleared down. The Result Code field can contain one of four possible values: 1 = call disconnected due to lost carrier (relevant for compulsory tunnel mode only), 2 = call disconnect for reason indicated by the Error Code field (known as General Error), 3 = call disconnected for administrative reasons, and finally, 4 = call disconnected in response to CCRQ. The Error Code field is set to 0, except in the event that the Result Code is set to a value of 2. If this is the case, the Error Code is set to one of the values shown earlier in Table 3-3. The Cause Code and Call Statistics field are the final two fields in the packet. Both are relevant only for compulsory tunnel mode. Cause Code is used to convey additional call disconnect information, and Call Statistics can be used to give call statistics for logging purposes.
As soon as the session has been terminated, the control channel is cleared down.
A Cisco PAC initiates control channel clearing as soon as the session has been terminated by sending a Stop-Control-Connection-Request (StopCCRQ).
Figure 3-19 shows the format of the StopCCRQ packet.
The StopCCRQ packet fields of significance are as follows:
The Control Message Type field is set to 3 to indicate that this is a StopCCRQ. The Reason field conveys the reason for the control connection termination. There are three legal values: 1 = general request to clear the control connection, 2 = cannot support the peer's PPTP version, and 3 = this machine is being shut down. The Reserved2 field is set to 0.
The client/PNS should then reply to the StopCCRQ with a Stop-Control-Connection-Reply (StopCCRP).
Figure 3-20 illustrates the format of the StopCCRP packet.
The StopCCRQ packet fields of significance are as follows:
The Control Message Type field has a value of 4 to indicate that this is a StopCCRP. In the Result Code field, one of two values can be used to indicate the result of the attempt to terminate the control connection. The valid values are: 1 = the control connection has been closed, and 2 = the control connection has not been closed for the reason indicated by the Error Code field (this is known as a General Error). The Error Code field is set to a value of 0, unless the Result Code field is set to a value of 2. If this is the case, an error condition is indicated. These error conditions are shown in Table 3-3.
Once this exchange has been completed, the PPTP tunnel has been completely terminated.
Figure 3-21 shows the exchange of messages between the remote access client/PNS and the PAC necessary for call (session) and control channel termination.
If session termination is initiated by the PAC, the sequence of messages is slightly different. The PAC initiates call session termination by sending a CDN to the remote access client/PNS. The control connection is then cleared using an exchange of StopCCRQ and StopCCRP messages, as previously described. As soon as this has been completed, the tunnel is down.
Figure 3-22 shows this exchange.
Other PPTP Messages
In addition to all of the control channel message types described in the previous section, one other message is used in voluntary tunnel mode. This message is called Set-Link-Info (SLI). The SLI is sent by the remote access client/PNS to communicate Asynchronous Control Character Map (ACCM) information to the PAC.
Figure 3-23 shows the format of the SLI message.
The SLI packet fields of significance are as follows:
The Control Message type field is set to a value of 15. This indicates that this is a SLI message. The Peer's Call ID indicates the Call ID that has been assigned by the PAC to this call (session). Finally, and most importantly, the Send and Receive ACCM fields are used to communicate Send and Receive Asynchronous Control Character Maps to the PAC.
Figure 3-24 shows the remote access client/PNS sending a SLI message to the PAC.
 | 
