5.2 Network access layer security protocols

In the Internet model and protocol stack, the network access layer handles issues related to local area networking and dial-up connectivity. Protocols that operate at this layer include Ethernet (IEEE 802.3), token bus (IEEE 802.4), token ring (IEEE 802.5), FDDI, and protocols for serial line dial-up networking, such as the Serial Line IP Protocol (SLIP) and ”most importantly ”the Point-to-Point Protocol (PPP) [2]. SLIP and PPP both define encapsulation mechanisms for transporting multiprotocol data across layer two point-to-point links (e.g., serial lines). In short, an encapsulation mechanism specifies how protocol data units (PDUs) from one protocol are encapsulated in PDUs of another protocol, and how these PDUs are then transported through the network. For all practical purposes, Ethernet is the most widely used and deployed technology for local area networking, and PPP is the most widely deployed protocol for dial-up networking.

In the late 1980s, the IEEE started to address issues related to LAN and metropolitan area network (MAN) security. In particular, the IEEE 802.10 working group (WG) was formed in May 1988 to address LAN and MAN security. Meanwhile, the IEEE 802.10 WG specified several standards for interoperable LAN/MAN security (SILS) that are compatible with existing IEEE 802 and OSI specifications [3, 4]. Unfortunately, SILS has not been commercially successful, and there are hardly any products that implement the standards. Consequently, we do not address the work of the IEEE 802.10 WG. Instead, we elaborate on recent work that has been done to secure dial-up connections using PPP with security enhancements.

First of all, we consider the problem that a European conference attendee traveling in the United States faces if he or she wants to connect his or her laptop computer to his or her corporate intranet in Europe (e.g., to read e-mail messages or download a presentation). There are at least two solutions for this problem:

A very obvious solution for the problem is to use the public-switched telephone network (PSTN) or the integrated services digital network (ISDN) to connect to a remote access server (RAS) located on the corporate intranet (e.g., a modem pool), to set up a PPP connection, and to use this connection to log in to the destination server located on the corporate intranet. The major advantages of this solution are availability and simplicity, whereas the major disadvantages are related to security and costs:
- The problem related to security is that the data traffic between the laptop computer and the intranet server goes unencrypted and unprotected .
- The problem related to costs is that the user is charged a long-distance call (or the company is charged the fees in the case of a modem pool with free charging or dial-back facilities).
A more sophisticated solution for the problem is to use a virtual private network (VPN) channel or tunnel. As we discuss later, there are many technologies that refer to and make use of the term VPN. Some of these technologies use cryptography to encapsulate data traffic and to establish and maintain cryptographically protected tunnels between the communicating peers. There are basically two approaches to create such a tunnel:
- One possibility is to encapsulate a given network layer protocol, such as IP, IPX, or AppleTalk, inside PPP, to cryptographically protect the PPP frames and to encapsulate the data inside a tunneling protocol, which is typically IP (but could also be ATM or Frame Relay). This approach is commonly referred to as layer 2 tunneling because the passenger of the tunneling scheme is actually a layer 2 protocol (i.e., PPP).
- Another possibility is to encapsulate a given network layer protocol, such as IP, IPX, or AppleTalk, directly into a tunneling protocol, such as 3Com s Virtual Tunneling Protocol (VTP), and to encapsulate the data inside another network layer protocol (e.g., IP) that is used to tunnel the data through the Internet. This approach is commonly referred to as layer 3 tunneling because the passenger of the tunneling scheme is actually a layer 3 protocol (i.e., VTP).

Figure 5.1 illustrates and puts into perspective the layer 2 tunneling and layer 3 tunneling encapsulation schemes (for IPX encapsulated inside IP). In either case, the protected part of the data is IPX. The major advantages of VPN tunnels are related to the fact that data traffic is encapsulated in IP packets that can be routed over the Internet and that cryptographic techniques can then be used to protect the IP packets.

Figure 5.1: The layer 2 and layer 3 tunneling encapsulation schemes.

The first solution is simple and straightforward; it does not deserve further explanation. In the following sections we elaborate on the second solution. In particular, we briefly overview and partly discuss the layer 2 forwarding/tunneling protocols that have been proposed and deployed in the past (layer 3 tunneling protocols are addressed in the following section).

Today, there is a strong consensus that the Layer 2 Tunneling Protocol (L2TP) is the preferred choice for applications that want to use layer 2 tunneling. Following the terminology introduced by the L2TP specifications, the following terms and acronyms are used (instead of POP and RAS ¹ ):

A remote system or dial-up client is a computer system or router that is typically the initiator of a layer 2 tunnel.
An L2TP access concentrator (LAC) is a node that acts as one side of a layer 2 tunnel endpoint and is a peer to the layer 2 tunneling protocol server (e.g., the L2TP network server discussed next ). As such, the LAC sits between the remote system or dial-up client and the server and forwards packets to and from each. The connection from the LAC to the remote system is either local or a PPP link.
Finally, an L2TP network server (LNS) is a node that acts as one side of a layer 2 tunnel endpoint (typically the recipient) and is a peer to the LAC. As such, the LNS is the logical termination point of a PPP session that is being tunneled from the remote system by the LAC.

Note that the LAC and the LNS require a common understanding of the encapsulation protocol so that layer 2 frames (e.g., PPP frames) can be successfully transmitted and received across the Internet. Also note that in this terminology, a network access server (NAS) is a device that provides access to users across a remote access network, such as the PSTN or ISDN. As such, the NAS may serve as either a LAC, LNS, or both.

5.2.1 Layer 2 Forwarding Protocol

Historically, the first layer 2 forwarding/tunneling protocol was the Layer 2 Forwarding (L2F) Protocol originally developed and proposed by Cisco Systems. It addressed two areas of standardization:

The encapsulation of layer 2 frames (i.e., PPP frames) within the L2F protocol. Each L2F frame, including an L2F header and a payload, is then encapsulated and sent within an IP packet or a UDP datagram, respectively. Contrary to more recent layer 2 forwarding/tunneling protocol proposals, the L2F protocol does not take into account the use of cryptography to protect the confidentiality of the encapsulated layer 2 frames.
The connection management for the layer 2 tunnel (i.e., how the tunnel is initiated and terminated ).

Both areas are specified in RFC 2341 [5]. According to this specification, the L2F protocol uses the well-known UDP port 1701 (for both source and destination ports).

Because the L2F protocol is only of historical value, ^[2] we do not delve into the technical details of the L2F protocol specification. You may refer to the referenced RFC document if you are interested in history (or if you are an administrator in charge of installing and configuring an implementation of the L2F protocol).

5.2.2 Point-to-Point Tunneling Protocol

Similar to the L2F protocol, the Point-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]. ^[3] The 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 (PPPEXT ^[4] ) 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:

If the remote system supports PPTP, it can directly use it to connect to the LNS.
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.

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 the Microsoft 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 MSPPTP cannot be recommended from a security point of view.

5.2.3 Layer 2 Tunneling Protocol

In June 1996, Microsoft and Cisco Systems proposed and submitted a combination of MS-PPTP and the L2F protocol to the IETF PPPEXT WG. The proposal was named Layer 2 Tunneling Protocol (L2TP) [18]. This collaborative protocol specification was particularly good news, as it meant that there would be just one industrywide IETF specification for a layer 2 tunneling and VPN dial-up protocol.

Similar to the L2F protocol and PPTP, the L2TP facilitates the tunneling of encapsulated PPP frames across an intervening network in a way that is as transparent as possible to both end users and applications. Contrary to the other protocols, however, L2TP uses and even requires the use of IPsec security associations (SAs) to cryptographically protect data that are transmitted between LACs and LNSs.

After this initial release, the L2TP specification was further refined. In August 1999, a preliminary release was published in RFC 2661 [19] and submitted to the Internet standards track. As such, the L2TP is likely to replace both the L2F protocol and PPTP in the future (in both Microsoft and Cisco products).

5.2.4 Virtual private networking

In summary, the L2F protocol, PPTP, and L2TP provide means for virtual private networking. Consequently, a final word is due on the use of these protocols for virtual private networking. According to RFC 2828, a virtual private network (VPN) is ˜ ˜a restricted-use, logical computer network that is constructed from the system resources of a relatively public, physical network (such as the Internet), often by using encryption, and often by tunneling links of the virtual network across the real network [20]. According to this definition, the use of encryption is not mandatory for VPNs. Consequently, there are some alternative technologies and notions of virtual private networking in use today. These technologies use controlled route leaking (i.e., route filtering) or label switching instead of cryptography to provide VPN facilities.

For example, multiprotocol label switching (MPLS) is a technology that can be used to implement something similar to closed user groups (CUGs) in a TCP/IP-based network [21, 22]. In short, MPLS makes sure that IP packets cannot reach hosts that are not legitimate members of a specific host group. Note, however, that there is no cryptographic protection in use, and that an MPLS subscriber has to trust the network provider not to eavesdrop on its communications and not to manipulate the IP traffic accordingly . Sometimes this level of trust may be justified. Sometimes, however, this level of trust may not be justified and the subscriber is then well advised to look into and consider the use of VPN technologies that employ cryptography in one way or another.

^[2] Because the term RAS is heavily used in the PPTP implementation of Microsoft, we use it when we discuss MS-PPTP later in this chapter.

^[3] Note that the category of the referenced RFC document is historic.

^[4] http://www.microsoft.com/technet/winnt/winntas/technote/pptpudst.asp

^[5] http://www.ietf.org/html. charters /pppext-charter.html