Ppp can support several types of network layer protocols that might use the connection.

8.7.1 Introduction

PPP (Point-to-Point Protocol) provides a standard method for transporting multiprotocol datagrams over point-to-point links. In the context of a network application, PPP allows IP datagrams to be exchanged with a node at the other end of a point-to-point link. Typically, a client will initiate a PPP connection by using a modem to dial into a foreign server through the public telephone system. However, PPP is also used in environments where the physical medium is not always point-to-point. One such example is Ethernet. The PPPoE and L2TP protocols enable support for transmission of PPP packets over Ethernet.

A PPP implementation may include support for a PPP client and a PPP server, perhaps even being utilized as both at the same time. Applications only have to be aware that PPP is being used as the underlying link-layer driver when establishing and breaking the physical link—that is, during dial-up and hang up. In all other respects, the application is not aware that PPP is the low-level driver being used.

Point to Point Protocol (PPP)

PPP is a relatively old communications protocol, described in 1994 in RFC 1661,1 and was designed to provide connectivity over serial hardware channels. PPP was originally developed to allow higher-level protocols to utilize these serial channels in a consistent manner. This protocol, though losing out to newer, faster technologies, is still used widely for embedded systems due to the fact that simple serial hardware is much less expensive than the hardware that some of the newer standards require. PPP consists of a few protocols designed to establish the serial link, encapsulate the higher-level data, and to control each of the high level protocols that can be used. Many different high-level protocols are compatible with PPP, but since we are discussing Internet security, it is reasonable to restrict our discussion to cover only the Internet Protocol, or IP. We will see in a minute how IP and PPP work together, but first we will look at the link establishment and discuss what it means for our embedded applications.

PPP, as with many low-level protocols, is designed to be the connection between the network hardware and the application. Link establishment in PPP is controlled by the Link Control Protocol, or LCP. The LCP divides the link establishment procedure into 4 distinct steps:

Establish the serial link using the hardware.

Optionally, test the quality of the link to determine if the hardware can handle the communication level desired.

Negotiate and configure the higher-level protocol for transmission.

Terminate the link and release the hardware.

To illustrate how we can adapt the protocol for our needs, let's look at the steps of the LCP. Obviously, we have to have a hardware connection in order to communicate with the remote device. However, the link quality test is an optional step; leaving it out may result in subpar communications, but it will definitely save on code size, and the link can be established faster. If we were trying to use PPP on an 8-bit CPU with only 64KB of program and data space (combined), this is a place where we can definitely cut corners to save on precious space. The tradeoff here is that while we obviously gain more space for our program and a small performance advantage, we lose some guarantee of robustness, and therefore, security. Imagine that an attacker could interfere with your communications by generating a high amount of electronic noise near the wire used for communications. Without the link quality test, you will not be able to determine if the link can handle the connection you need. The attacker then can hinder your application without having to cut a wire or hack into the system.

This is the type of tradeoff that we will focus on in developing secure applications that need to fit onto our resource-constrained devices. On one hand, we have the strict size requirement, on the other a potential security risk. Depending on the requirements of the application, it may be more desirable to remove the optional step and save precious space. We will look at some of these requirements so you can understand how to look for these types of options when dissecting security and communications protocols. For now, let's continue looking at PPP and see what we can do with the communication protocol itself.

PPP is an inherently configurable protocol, allowing for many implementation options. For each network-layer protocol, there is a corresponding Network Control Protocol (NCP) that allows the protocol to utilize PPP as the link-layer transport mechanism. Each NCP is designed to provide the correct functionality to allow PPP to transport the higher-level packets. This functionality includes any security protocols inherent to the higher level protocols, such as IPSEC (security for IP). The selection of NCP's to support is another option we have to conserve code space. If we know that our application will only need to support one higher-level protocol (such as IP), then we only have to implement the functionality specific for the NCP for that particular protocol. We can tailor the implementation to fit the protocol, and since we do not have to support the other NCP's, we can simply reject any protocols that we do not support. We need to be sure that the rejection mechanism is robust, however, since if the mechanism is not well behaved, it could set up a situation where a denial-of-service or buffer overflow might be possible. For example, if the LCP on the remote end (asking for a link to the device) sends a protocol request mechanism that is very large, it can overflow local buffers, allowing a user on the remote end to crash the device or run arbitrary code (depending on the local implementation). If the rejection mechanism is slow, or if the implementation allows multiple connections from a single remote device with no limit between retransmissions, a remote device could send a flurry of connection requests, effectively preventing the device from serving legitimate requests. This is an example of where robust design and programming can make the device more secure.

PPP has its own security mechanisms that we can use to authenticate connection requests, allowing the implementation to protect the device from unauthorized use. The security mechanisms supported by PPP are password authentication and a challenge-handshake. Again, we can choose to support either of these mechanisms. The password mechanism will have a simpler implementation, since the challenge-handshake will require additional states in the PPP state machine to handle the additional messages. However, we may also choose not to support any PPP security, instead relying on the higher-level protocols to provide security for the application. Depending on the application, the no-security option may be more desirable. If the network is not secure, sending a password would allow anyone eavesdropping on the network to read the password.

The challenge-handshake protocol, though more complex, is also more secure than the password protocol. The common challenge-handshake protocol for PPP is defined in RFC 1994 (written in 1996), and is referred to as the Challenge Handshake Authentication Protocol, or CHAP. CHAP provides decent security for devices with a previously defined trusted relationship, but since it requires shared secret keys (cryptographic keys stored on each end), it is not practical for general-purpose security (connecting to arbitrary remote systems). Without an established relationship, the secret for the challenge mechanism must be sent plaintext over the network—which is obviously not secure at all. Whether or not such a relationship can be established should be a factor in deciding whether or not to support the authentication protocol.

As was mentioned previously, PPP is an older technology, but is still popular on smaller embedded devices because of its ability to use inexpensive networking hardware. However, current technology is moving toward newer, more complex low-level protocols, and these new technologies have more security options, but also more security challenges. Your application requirements will determine whether PPP or one of these other technologies should be used. Next we will look at another applicable technology that has gained widespread popularity and is practically the only technology used for Local Area Networks (LANs). This technology is practically a household word—Ethernet.

PPP

The Point-to-Point Protocol (PPP) is the existing method used when transferring Transmission Control Protocol/Internet Protocol (TCP/IP) data over modem connections. The Bluetooth specification reuses this protocol in the local area network (LAN) Access Profile to route network data over an RFCOMM port. Work is already underway on a TCP/IP layer that will sit directly above L2CAP, bypassing and removing the overhead of PPP and RFCOMM. This work is hinted at in some areas of the specification, but in v1.1 PPP, is all that's available.

Exam Objectives Fast Track

PPP and DSL

Why is PPP used with DSL (and SONET)? The core of the issue is that ISPs needed some kind of tunneling protocol. Tunneling occurs when the normal message-packet-frame encapsulation sequence of the layers of a networking protocol suite are violated. When a message is placed inside a packet, then inside a frame, and this frame is placed inside another type of frame (or even another frame-packet-frame sequence), this is a tunneling situation. Although many tunneling methods have been standardized at several different TCP/IP layers, tunneling works as long as the tunnel endpoints understand the correct sequence of headers and content (which can also be encrypted for secure tunnels).

In DSL, the tunneling protocol had to carry the point-to-point “circuits” from the central networking location to the customer’s premises and across the shared media LAN to the end user device (host). There are many ways to do this, such as using IP-in-IP tunneling, a virtual private network (VPN), or lower level tunneling. ISPs chose PPP as the solution for this role in DSL.

Using PPP made perfect sense. For years, ISPs had used PPP to manage their WAN dial-in users. PPP could easily assign and manage the ISP’s IP address space, compartmentalize users for billing purposes, and so on. As a LAN technology, Ethernet had none of those features. PPP also allowed user authentication methods such as RADIUS to be used, methods completely absent on most LAN technologies (if you’re on the LAN, it’s assumed you belong there).

Of course, keeping PPP meant putting the PPP frame inside the Ethernet frame, a scheme called Point-to-Point Protocol over Ethernet (PPPoE), described in RFC 2516. Since tunneling is just another form of encapsulation, all was well.

PPP is not the only data link layer framing and negotiation procedure (PPP is not a full data link layer specification) from the IETF. Before PPP became popular, the Serial Line Internet Protocol (SLIP) and a closely related protocol using compression (CSLIP, or Compressed SLIP) were used to link individual PCs and workstations not connected by a LAN, but still running TCP/IP, to the Internet over a dial-up, asynchronous analog telephone line with modems. SLIP/CSLIP was also once used to link routers on widely separated TCP/IP networks over asynchronous analog leased telephone lines, again using modems. SLIP/CSLIP is specified in RFC 1055/STD 47.

PPP Multilink Protocol

PPP has, by Internet standards, a long history with the Internet Engineering Task Force (IETF). The basic documented history of PPP dates back to 1989 when “A Proposal for Multi-Protocol Transmission of Datagrams Over Point-to-Point Links” was specified in Request For Comments (RFC) 1134. The official implementation, as used by Microsoft, comes from RFP 1990. Capabilities were added and subsequent modifications to the standard were made leading up to PPP as it exists today. In 1994, a documented standard was proposed for “The PPP Multilink Protocol” in RFC 1717. At the time, other proposals existed to combine streams of data at the bit level (basically a hardware solution). This proposal described a software-based solution for the need to combine multiple streams of data into one. This solution was well-suited to the twin bearer channels of ISDN (2B+D).

The PPP Multilink Protocol must be enabled on both the remote access client and the remote access server. PPP Multilink is enabled on the remote access server via remote access policy, using the Routing and Remote Access Service management console or the Internet Authentication Service (IAS). The nature of multilink requires dialing to multiple devices or endpoints. To enable Multilink on a remote access client, you must enable multiple device dialing on the client system through the Network and Dial-up Connections folder. Again, if unlimited connectivity is not available, the nature of Multilink presents cost prohibitive problems due to the lack of provisions to link and unlink extra physical connections on an as-needed basis.

Note

Be aware that if you use Multilink to dial a server that requires callback, only one of your devices is called back. Because you can store only one number in a user account, only one device connects and all other devices fail to complete the connection. Some ISDN service uses a single number for both B channels. If your ISDN uses only a single number for both B channels, then Multilink callback will work in this case. This attribute of callback means your connection loses Multilink functionality.

4.5.2 Point-to-Point Protocol Example5

PPP (point-to-point protocol) is a common OSI data-link (or network access layer under the TCP/IP model) protocol that can encapsulate and transmit data to higher layer protocols, such as IP, over a physical serial transmission medium (see Figure 4.24). PPP provides support for both asynchronous (irregular interval) and synchronous (regular interval) serial communication.

PPP is responsible for processing data passing through it as frames. When receiving data from a lower layer protocol, for example, PPP reads the bit fields of these frames to insure that entire frames are received, that these frames are error free, that the frame is meant for this device (using the physical address retrieved from the networking hardware on the device), and to determine where this frame came from. If the data are meant for the device, then PPP strips all data-link layer headers from the frame, and the remaining data field, called a datagram, is passed up to a higher layer. These same header fields are appended to data coming down from upper layers by PPP for transmission outside the device.

In general, PPP software is defined via a combination of four submechanisms:

The PPP encapsulation mechanism (in RFC1661) such as the high-level data-link control (HDLC) framing in RFC1662 or the link control protocol (LCP) framing defined in RFC1661 to process (i.e., demultiplex, create, verify checksum, etc.)

Data-link protocol handshaking, such as the link control protocol (LCP) handshaking defined in RFC1661, responsible for establishing, configuring, and testing the data-link connection

Authentication protocols, such as PAP (PPP authentication protocol) in RFC1334, used to manage security after the PPP link is established

Network control protocols (NCP), such as IPCP (Internet protocol control protocol) in RFC1332, that establish and configure upper-layer protocol (i.e., OP, IPX, etc.) settings.

These submechanisms work together in the following manner: a PPP communication link, connecting both devices, can be in one of five possible phases at any given time, as shown in Table 4.1. The current phase of the communication link determines which mechanism – encapsulation, handshaking, authentication, and so on – is executed.

Table 4.1. Phase Table8

How these phases interact to configure, maintain, and terminate a point-to-point link is shown in Figure 4.25.

As defined by PPP layer 1 (i.e., RFC1662), data are encapsulated within the PPP frame, an example of which is shown in Figure 4.26.

The flag bytes mark the beginning and end of a frame, and are each set to 0x7E. The address byte is a high-level data-link control (HDLC) broadcast address and is always set to 0xFF, since PPP does not assign individual device addresses. The control byte is an HDLC command for UI (unnumbered information) and is set to 0x03. The protocol field defines the protocol of the data within the information field (i.e., 0x0021 means the information field contains IP datagram, 0xC021 means the information field contains link control data, 0x8021 means the information field contains network control data – see Table 4.2). Finally, the information field contains the data for higher-level protocols, and the FCS (frame check sequence) field contains the frame's checksum value.

Table 4.2. Protocol Information8

The data-link protocol may also define a frame format. An LCP frame, for example, is as shown in Figure 4.27.

The data field contains the data intended for higher networking layers, and is made up of information (type, length, and data). The length field specifies the size of the entire LCP frame. The identifier is used to match client and server requests and responses. Finally, the code field specifies the type of LCP packet (indicating the kind of action being taken); the possible codes are summarized in Table 4.3. Frames with codes 1–4 are called link configuration frames, 5 and 6 are link termination frames, and the rest are link management packets.

Table 4.3. LCP Codes8

The LCP code of an incoming LCP datagram determines how the datagram is processed, as shown in the pseudocode example below.

In order for two devices to be able to establish a PPP link, each must transmit a data-link protocol frame, such as LCP frames, to configure and test the data-link connection. As mentioned, LCP is one possible protocol that can be implemented for PPP, to handle PPP handshaking. After the LCP frames have been exchanged (and thereby a PPP link established), authentication can then occur. It is at this point where authentication protocols, such as PPP Authentication Protocol or PAP, can be used to manage security, through password authentication and so forth. Finally, Network Control Protocols (NCP) such as IPCP (Internet Protocol Control Protocol) establish and configure upper-layer protocols in the network layer protocol settings, such as IP and IPX.

At any given time, a PPP connection on a device is in a particular state, as shown in Figure 4.28; the PPP states are outlined in Table 4.4.

Table 4.4. PPP States8

Events (also shown in Figure 4.28) are what cause a PPP connection to transition from state to state. The LCP codes (from the RFC1661 spec) in Table 4.5 define the types of events that cause a PPP state transition.

Table 4.5. PPP Events8

As PPP connections transition from state to state, certain actions are taken stemming from these events, such as the transmission of packets and/or the starting or stopping of the Restart timer, as outlined in Table 4.6.

Table 4.6. PPP Actions8

PPP states, actions, and events are usually created and configured by the platform-specific code at boot-time, some of which is shown in pseudocode form on the next several pages. A PPP connection is in an initial state upon creation; thus, among other things, the ‘initial’ state routine is executed. This code can be called later at runtime to create and configure PPP, as well as respond to PPP runtime events (i.e., as frames are coming in from lower layers for processing). For example, after PPP software demuxes a PPP frame coming in from a lower layer, and the checksum routine determines the frame is valid, the appropriate field of the frame can then be used to determine what state a PPP connection is in and thus what associated software state, event, and/or action function needs to be executed. If the frame is to be passed to a higher layer protocol, then some mechanism is used to indicate to the higher layer protocol that there are data to receive (IPReceive for IP, for example).

PPP over SSH

The point-to-point-protocol describes the connection and the following communication steps between two virtual network interfaces. Through a simple configuration, it is possible to tunnel communications through ssh.

As you can see, ssh represents a plus, which allows most services to add the security concept in the transmission and authentication without turning to compromises other than that of the time required for the initial setup of the environment. We can protect any type of service by differentiating which communications are protected from ssh and which are not. The use of ssh is therefore recommended for all services that do not natively offer the protection and check for the integrity of the media.

VPN

Virtual private networks (VPNs secure data sent via insecure networks like the Internet. The goal is to virtually provide the privacy afforded by a circuit, such as a T1. The basic construction of VPNs involves secure authentication, cryptographic hashes such as SHA-1 to provide integrity, and ciphers such as AES to provide confidentiality.

L2TP/IPSec

L2TP, first introduced with Windows 2000, combines the benefits of PPTP with Cisco System’s Layer Two Forwarding (L2F) protocol. Generally, a layer-two connection is used to connect a remote client with a remote access server, and consequently the PPP connection also terminates at the same endpoints as the layer two connections.

L2TP extends PPP to allow the PPP and layer-two endpoints to reside on different devices. Whereas PPTP connects systems over an IP network only, L2TP allows for connectivity over IP, X.25, Frame Relay, or Asynchronous Transfer Mode (ATM). When IP is used as a transport mechanism, L2TP uses UDP packets and special L2TP messages to handle tunnel management. L2TP also carries the tunneled data in UDP encapsulated PPP flames. Remember that Microsoft’s PPTP provides encryption via MPPE as well as compression via Microsoft Point-to-Point Compression (MPPC). L2TP has provisions for encrypted and compressed PPP encapsulated payloads; however, the Microsoft implementation of L2TP does not provide for these features directly. To encrypt the encapsulated PPP payload, Microsoft’s implementation of L2TP must be used with IPSec’s Encapsulating Security Payload (ESP) protocol.

Note

L2TP can be used only if both the VPN server and VPN client support it. Windows 2000 and Windows XP clients and Windows 2000 and Windows Server 2003 servers include built-in L2TP/IPSec support. Windows 9x and Windows NT clients do not include L2TP support, but you can download an L2TP/IPSec client for Windows 98, Windows ME, and Windows NT Workstation 4.0 from Microsoft’s Web site at http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/12tpclient.asp.

L2TP is described in IETF RFC 2661. The combination of L2TP with IPSec is described in IETF RFC 3193.

Head of the Class…

Both L2TP/IPSec and PPTP/MPPE exhibit certain advantages and disadvantages. Table 7.2 compares L2TP/IPSec with PPTP/MPPE.

Table 7.2. Comparison of L2TP/IPSec and PPTP/MPPE

Exam Warning

L2TP is still the latest and greatest for VPN security. Ensure that you understand the similarities and differences between L2TP and PPTP. Although L2TP/IPSec tends to provide a more secure VPN solution, PPTP still has its advantages as well. Make sure you understand the advantages and disadvantages of each.

Now that you understand the basic concepts and terminology associated with Windows Server 2003 VPNs, we will move on to practice some hands-on configurations and you’ll learn how to put the concepts to work. The following preconfiguration checklist will simplify the configuration settings outlined in the next section:

Review the basic VPN concepts. Determine the type of VPN you wish to configure: router-to-router or client-server.

Ensure hardware is compatible and install necessary hardware.

Install and enable the Routing and Remote Access service as outlined in Exercise 7.01.