|
|
4.5. PPTPA major problem faced by enterprises is that posed by the so-called road warrior. A typical example is a traveling sales representative who requires access to company inventory databases, order entry systems, and other servers located at the home office. One solution to this problem is shown in Figure 4.17. A remote user phones in to a remote access server (RAS), using, say, PPP to establish a connection to the home office's network. Figure 4.17. Dialing in to the Home Network Through a RAS
But this solution can be expensive. In the first place, the modem bank will have to be large enough to support the maximum number of simultaneous users. This equipment and the associated phone lines can represent a significant capital investment as well as recurring charges for the phone lines. In the second place, the remote user will, in general, incur long-distance charges. Despite its expense, the RAS solution has certain advantages. It is more secure than simply connecting to the company network through the Internet. Although it is possible, of course, to tap phone lines, doing so is considerably more difficult than intercepting Internet traffic. Another problem with merely connecting through the Internet is that the remote host will not have an IP address that's on the company network, which can create problems, especially when the company network has a private (RFC 1918) address space. Observe how this problem is avoided with the RAS: Its PPP daemon can negotiate an address on the company network for the remote host. In this section, we see how the Point-to-Point Tunneling Protocol (PPTP) offers a solution with the advantages of a RAS but without the associated expenses. We will ignore the security aspect for the time being and focus on the tunneling technology. Architecturally, PPTP divides the RAS functions between a PPTP access concentrator (PAC) that remote users "dial" into, and a PPTP network server (PNS) that terminates remote clients' PPP sessions, provides access to the company network, and acts as a server for one or more PACs.
Functionally, the PAC-PNS pair provides a tunnel for PPP packets between the remote user and the PNS. PPTP itself runs between the PAC and the PNS; it does not involve the remote host, except when the PAC is part of the remote host, or the hosts on the company network. From the point of the remote host, using PPTP is identical to the RAS solution of Figure 4.17. The remote user places a (probably local) phone call and establishes a PPP session with the PNS, which provides access to the company network. The role of the PAC is to transfer PPP packets between the remote host and the PNS by sending them through the tunnel. The PAC does not take part in the PPP session itself. As shown in Figure 4.18, each PAC-PNS pair has a tunnel between themthrough which they pass PPP packetsand a control connection that is used to manage the tunnel and establish PPP sessions between the remote host and the PNS. Figure 4.18. A PAC-PNS Pair
The control connection is a TCP session that either the PAC or the PNS may initiate by connecting to port 1723 of its peer. The control connection state machine has a mechanism for resolving collisions in which the PAC and PNS attempt to connect to each other simultaneously. The PAC and PNS communicate with each other over the control connection by exchanging PPTP control messages. These messages deal with control connection management, call management, error reporting, and certain PPP parameters. The general format of these messages is given in Figure 4.19. Figure 4.19. PPTP Control Message Header
The length field is the length of the entire PPTP message, including the header. The PPTP message type is always set to 1, indicating a control message. The protocol also provides for management messages (type 2), but they are not implemented or even defined. The magic cookie always has the value 0x1a2b3c4d and is used for synchronization with the TCP data stream. If the second 32-bit word of the message does not have this value, the receiver knows that it has lost synchronization. In the event of desynchronization, the receiver can search for the magic cookie to resynchronize with the message boundaries. The control message type field indicates the type of control message and the format of the rest of the message. The values of this field are listed in Figure 4.20.
The connection control management messages are used to set up, tear down, and test the connectivity of control connections. The typical case is for the PAC to send a Start-Control-Connection-Request to the PNS stating its desire to establish a control connection and listing its capabilities. The PNS replies with a Start-Control-Connection-Reply in which it lists its capabilities if it agrees to the connection, or gives a reason code for rejecting it. During the life of the connection, either side can send the other an Echo-Request if it has not received other traffic for a specified time. If the other side does not respond with an Echo-Reply, the sender closes the control connection. Either side can initiate connection teardown by sending its peer a Stop-Control-Connection-Request. The peer responds with a Stop-Control-Connection-Response either agreeing to the request or giving an error code specifying why it cannot comply. Closing the control connection will also cause the tunnel to be torn down, terminating any active PPP sessions. The tunnel is a GRE tunnel that encapsulates the PPP packets, as shown in Figure 4.21. The remote host passes the PPP packet to the PAC, which adds GRE and IP headers and sends them over the Internet to the PNS. The PNS removes the GRE and IP headers and passes the PPP packet to its PPP daemon. If the PPP packet is carrying network-layer data, PPP removes the datagram and forwards it to the company network. Figure 4.21. PPP Packets Tunneled in the PPTP GRE Tunnel
As we mentioned earlier, PPTP uses an extended (version 1) GRE header. As we see in Figure 4.22, this header has an additional acknowledgment number field and corresponding A bit to indicate whether it is present. The interpretation of the key field is different. It is divided into a payload length field that contains the length of the payload, not including the GRE header, and a call ID field that is used to demultiplex the PPP connection. Figure 4.22. The PPTP Extended GRE Header
Figure 4.23 shows PPTP tunneling in a typical situation. The upper PAC is a dial-in facilityat an ISP, saythat remote users connect to using PPP. This is called mandatory mode because the remote hosts have no say in whether their connections are tunneledindeed, they will usually be unaware of the tunneling. Several remote hosts can share the PAC and its tunnel: The figure shows n hosts connected to the PAC and passing PPP packets through its tunnel. The PAC does not deal with the PPP datagrams in any way other than sending them through the tunnel to the PNS. Figure 4.23. PPTP Mandatory and Voluntary Modes
The lower PAC is built into the remote host itself. In this case, the PPTP tunnel extends all the way to the remote host. This is called voluntary mode because the remote host is directly involved with the mechanics of the tunnel and must elect to use it. This is not the case with the upper PAC. When a remote host connects to a PAC, either by dialing in or internally when the PAC is built in, the PAC sends the PNS an Incoming-Call-Request with details about the source of the call. The PNS responds with an Incoming-Call-Reply either accepting the call or an error code specifying the reason for rejecting it. If it accepts the call, the PNS also responds with some information about its receive window and the processing delay that it expects will apply to PPP packets during the session. When the PAC receives the Incoming-Call-Reply, it can answer the remote host's call. Once the PAC has accepted the remote host's call, it has additional information, such as the type of connection, line speed, receive window, and processing delay, that it can pass to the PNS. Therefore, the PAC completes the session-establishment handshake by sending the PNS an Incoming-Call-Connected message with these parameters. At this point, the remote host and PNS begin their PPP LCP negotiation. At any time during the session, the PNS can send a Call-Clear-Request to the PAC, asking it to terminate the call. The PAC will disconnect the call and inform the PNS it has done so with a Call-Disconnect-Notify. The PAC will also send the PNS a Call-Disconnect-Notify if the remote host disconnects on its own. The PNS can initiate an outbound call to a remote host by sending the PAC an Outgoing-Call-Request. The PAC will respond with an Outgoing-Call-Reply either indicating that the connection was established or giving an error code specifying why it couldn't connect to the remote host. If, during the session, the PAC experiences an error on the WAN (Internet) connection, it will send the PNS a WAN-Error-Notify message. This message contains a set of cumulative error counters for CRC, framing, hardware overruns, buffer overruns, timeout, and alignment errors. This message is sent only when an error occurs and never more than once a minute. Although we have concentrated on the tunneling aspects of PPTP, its real use is as a VPN in Microsoft networks. We revisit PPTP in Chapter 5, where we discuss PPTP's VPN properties. Because most experts discourage the use of PPTP, and because Microsoft now uses the Layer Two Tunneling Protocol (L2PT) as the primary type of VPN in Microsoft networks, we have omitted some of the details of the protocol and the control message formats here. Complete details are available in RFC 2637 [Hamzeh, Pall, Verthein, Taarud, Little, and Zorn 1999].  | ||||||||||||||||||||||||||||||||||||||||
|
|
