ENFOQUE DE APRENDIZAJES DE FORMACIÓN PRODUCTIVA

Similar to the L2F protocol, thePoint-to-Point Tunneling Protocol(PPTP) was originally developed and designed to solve the problem of creating and maintaining VPN tunnels over public TCP/IP-based networks using the PPP [6, 7].3The PPTP is the result of joint efforts of Microsoft and a set of product vendors, including, for example, Ascend Communications, 3Com/Primary Access, ECI Telematics, and U.S. Robotics. These companies originally constituted the PPTP Forum, whose resulting PPTP specification was made publicly available and submitted to the IETF Point-to-Point Protocol Extensions (PPPEXT4) WG for possible consideration as an Internet Standard in 1996.5

A typical deployment of the PPTP starts with a remote system or dial-up client, such as a laptop computer, that must be interconnected to an LNS located on a corporate intranet using an LAC. As such, the PPTP can be used to encapsulate PPP frames in IP packets for transmission over the Internet or any other publicly accessible TCP/IP-based network. More specifically, the remote system can connect to the LNS in two ways:

1. If the remote system supports PPTP, it can directly use it to connect to the LNS.

2. If, however, the remote system does not support PPTP, it can use PPP to connect to an Internet service provider’s LAC, and this LAC can then use PPTP to connect to the LNS.

In the first case, the situation is comparably simple. The remote system first establishes a PPP connection to the Internet service provider’s LAC and then uses PPTP to send encapsulated PPP frames to the LNS. The IP packets that encapsulate the PPP frames are simply forwarded by the LAC.

In the second case, however, the LAC must use the PPTP to encapsulate the PPP frames in IP packets on behalf of the remote system. Consequently, the LAC must play the role of an intermediate or proxy server in one way or another. In fact, there are two connections. The first connection uses the PPP to interconnect the remote system and the LAC, whereas the second connection uses the PPTP to interconnect the LAC and the LNS. PPP frames received by the LAC are encapsulated in IP packets using the PPTP.

3. http://www.microsoft.com/technet/winnt/winntas/technote/pptpudst.asp

4. http://www.ietf.org/html.charters/pppext-charter.html

5. Note that the IETF PPPEXT WG is situated in the IETF’s Internet area (not in the security area).

In either case, the PPTP uses a sophisticated encapsulation scheme to tunnel PPP frames through the Internet (or any other TCP/IP-based network that interconnects the LAC and the LNS). In fact, network or Internet layer protocol data units (e.g., IP packets, IPX packets, or NetBEUI messages) are first framed using PPP. The resulting PPP frames are then encapsulated using a generic routing encapsulation (GRE) header [8] as well as an IP header that is used to route the frame through the Internet. Finally, the resulting IP packets are framed with still another media-specific header before they can be forwarded to the interface connected to the Internet.

In addition to the data channel that uses IP encapsulation to transmit data, the PPTP uses a TCP connection for signaling. The corresponding messages that are sent or received over this connection are used to query status and to convey signaling information between the LAC (i.e., the PPTP client) and the LNS (i.e., the PPTP server). The control channel is always initiated by the PPTP client to the PPTP server using TCP port number 1723. In most cases, it is a bidirectional channel where the client can send messages to the server and vice versa. Note that the notion of an outband signaling channel is something very specific for PPTP. Most other security protocols (e.g., the IPsec protocols) use inband signaling, meaning that signaling information is transported together with the protected data units.

The PPTP specification does not mandate the use of specific algorithms for authentication and encryption. Instead, it provides a framework for the negotiation of particular algorithms. This negotiation is not specific to PPTP, and relies on existing PPP option negotiations contained within the PPP compression protocol (CCP) [9], the challenge handshake authentication protocol (CHAP) [10], and some other PPP extensions and enhancements. Also outside the world of the PPTP, PPP sessions have been able to negotiate compression algorithms as well as authentication and encryption algorithms [11, 12].

In spite of the fact that the PPTP specification was submitted to the IETF PPPEXT WG for consideration as an Internet Standard, its standardization effort has been abandoned. Microsoft’s implementation of the PPTP (i.e., MS-PPTP) is heavily used in Windows NT environments. Outside these environments, however, neither MS-PPTP nor another implementation of PPTP is widely deployed.

Using MS-PPTP, the client and the server typically authenticate each other using MS-CHAP [13], which is Microsoft’s version of the CHAP, and encrypt data using theMicrosoft Point-to-Point Encryption(MPPE) protocol [14]. As outlined in [15], MS-PPTP has severe flaws in both its design and implementation. This is particularly true for MS-PPTP version 1, but it is also

true for MS-PPTP version 2 (e.g., [16, 17]). Consequently, the use of MS- PPTP cannot be recommended from a security point of view.