To make remote connections possible, users need to have the following components installed on their devices: application software (such as FTP, Telnet, or a web browser), protocol stacks (TCP/IP, IPX, AppleTalk), and link-layer protocols (such as PPP).

When sent out across the dialup connection, the higher-layer protocols are framed in link-layer protocols (such as PPP) much like Ethernet link-layer framing encapsulates IP datagrams on a LAN.

This article introduces the following concepts:

• Common remote-access protocols

• PPP framing

• PPP negotiation phases

• LCP options

• PPP frame format

Common Remote-Access Protocols

For datagram transmission over point-to-point lines, two standard protocols exist: Serial Line Internet Protocol (SLIP) and PPP. SLIP, described in RFC 1055, works only with IP on point-to-point serial connections. PPP, on the other hand, can facilitate multiprotocol connections over synchronous and asynchronous circuits. Therefore, PPP is the most widely used protocol for remote dial access.

PPP Framing

As mentioned, PPP can transmit packets over asynchronous or synchronous links. The packet's framing type is dictated by the medium in use. Asynchronous High-Level Data Link Control (AHDLC) framing is used for asynchronous links, and bit-synchronous framing is used for synchronous links. Cisco supports the following PPP framing types for different interfaces:

• Asynchronous interfaces (modems) AHDLC framing

• Synchronous interfaces (serial or ISDN) Bit-synchronous framing

• Virtual terminal (vty) connections via synchronous interface V.120 framing

• Asynchronous interfaces with special V.110 modems V.110 framing

PPP Negotiation Phases

As soon as the encapsulation type described in the preceding section has been confirmed, the link media type is no longer relevant to PPP connection establishment. PPP establishes network protocol connectivity in three functional phases:

• Link Control Protocol (LCP) Establishes and configures the data-link connection. During this phase, the protocol used in the next phase is negotiated.

• Authentication Applies security functionality to the connection.

• Network Control Protocol (NCP) Establishes and configures different network-layer protocols, such as IP, IPX, AppleTalk, DECnet, and bridged data.

LCP and NCP are discussed in detail in the following sections from a more theoretical perspective.

LCP

LCP deals with options that are link-dependent and protocol-independent. As mentioned, LCP negotiation is bidirectional, which means that both ends of the connection must agree on their options and acknowledge its peer's request. Some of the options negotiated during the LCP phase include magic number (to detect loopback), callback, multilink, link compression, and authentication. Authentication in terms of LCP translates into whether authentication is to be used and, if so, which protocol will facilitate the authentication. However, this is not the actual authentication process.

As soon as the LCP phase has been negotiated successfully, the LCP connection is considered open. Now the authentication process as determined by LCP can begin.

NCP

NCP is the final step of the PPP negotiation process. NCP deals with protocol-dependent options such as the protocol address, protocol compression, and so forth. The individual NCP options correspond to the type of protocol configured on the interface. For instance, if IP is the chosen protocol, IPCP (IP Control Protocol) is negotiated.

The protocol address is the NCP option that is always negotiated. Sometimes it is the only option negotiated. It is possible for the NAS to provide the protocol address to the dial-in client or simply acknowledge whatever protocol address the peer requests. For a remote Cisco router to accept an address from the NAS it has dialed into, the client router needs to be configured to do so.

IPCP is the primary NCP and is used here to explain the NCP parameters. As part of the IPCP process, usually three different options are negotiated: the IP address, IP/TCP header compression, and the DNS and WINS primary and secondary servers. Keep in mind that the DNS and WINS options relate to Microsoft Windows PC clients only.

During the IPCP negotiations, the roles of a client and a NAS are different. The access server is required to supply the negotiation parameters (IP address, DNS and WINS address, and so on) for itself and often for a client as well. On the other hand, the client needs to be configured to be able to retrieve this information from the NAS.

Another option in the IPCP negotiations is, as mentioned, the TCP/IP header compression. This might decrease a header's size from 40 to 5 bytes. The negotiation of this option includes whether the peer can accept a packet with the compressed header. This feature is recommended for transmissions whose packet sizes are small, such as Telnet or WWW.

LCP Options

PPP offers a number of features that are negotiated at the LCP level that can prove very useful when implemented in an internetwork:

• Authentication options

• PPP callback

• PPP compression

• Multilink PPP

• Bandwidth Allocation Protocol (BAP)

These services are described next.

Authentication

Before you begin learning about the PPP authentication process and techniques, you should become familiar with the following terms:

• Authenticator The peer demanding authentication. Specifies the authentication protocol to be used during the LCP phase.

• Peer The opposite end of the link; an entity that is being authenticated by the authenticator.

• Remote authentication The remote PPP peer authentication of the local NAS.

• Local authentication The local NAS authenticating its remote peer.

When authentication is requested by either side of the connection during LCP negotiation, the actual authentication takes place after the LCP stage is completed. Authentication is accomplished to check the peer's validity. This is done by verifying the preassigned name (often called the userid or host name) and the secret (often called the password). The name/secret combination can be stored locally or remotely on an AAA server.

The two most popular PPP authentication techniques are Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Both ensure that unauthorized individuals can't access the remote-access server (RAS). Their differences are discussed in greater detail later.

As is the case with all other PPP negotiation phases, authentication is bidirectional. This means that both ends of the connection are required to authenticate one another. Consequently, authentication needs to be enabled at both ends.

The Cisco NAS differentiates among types of call direction. Depending on the type, the NAS takes certain action when it comes to authentication. This is done to protect the network against security violations. Table 1 lists the types of calls and the NAS's subsequent responses.

The following subsections describe PAP and CHAP in more detail.

PAP

PAP is the less-secure of the two PPP authentication protocols, because the secret is sent over the wire in clear text. Therefore, if the packet is captured, the secret contained in it can be used in a malicious attack. Understandably, because of this drawback, PAP isn't a preferred method of authenticationunless, of course, it is the only one supported.

PAP implements a two-way handshake sequence to verify its peer's identity:

Step 1. The peer sends its host name and secret to be checked by the authenticator.

Step 2. The authenticator verifies the offered host name/secret combination against the known value either locally or via an AAA server. If the authenticator determines that the values are legitimate, the authentication is satisfied and acknowledged. If not, the connection is terminated on the spot.

CHAP

CHAP is quite a bit more secure than PAP. During CHAP authentication, the secret itself is never sent across the connection, some parts of communication are encrypted, and the challenges are constantly repeated to ensure that the connection is authorized at all times. Unlike PAP, CHAP uses a three-way handshake for identification purposes:

Step 1. The authenticator sends a challenge to the peer. The challenge contains a random number and the authenticator's host name.

Step 2. The peer answers the challenge with a one-way hash value and its own host name. The hash value is calculated via MD5 encryption and is derived from the random number from the challenge message plus the secret associated with the authenticator's host name.

Step 3. When the authenticator receives the response to its challenge, it goes through the same hashing process as the peer, inputting the secret and the random number as the derivatives. After the new MD5 value is calculated, the challenger compares it to the one that came back from the peer. If they match, the authentication is accepted and acknowledged. Otherwise, the connection is dropped.

PPP Callback

PPP callback is an option negotiated during LCP that allows a caller to request that a called party should place another callback to the initiating peer. For this discussion, the party requesting a callback is the client, and the party accepting the request and making the callback is the server. PPP callback is useful whenever centralized control over a call is desired, such as for the purposes of bill consolidation, dialup call savings, and even security, because the callbacks are placed only to preconfigured numbers.

Although normally authentication is considered an optional PPP feature, it must be enabled and passed for the callback feature to work.

The sequence of a PPP callback is as follows:

Step 1. The callback client places a call to the callback server (NAS) indicating that the callback service is requested. The callback server responds with the callback request acknowledgment. The type of acknowledgment sent in this step signifies simply that the server is generally capable of accepting callback requests.

Step 2. The callback server proceeds further by authenticating the client. As usual, the authentication can take place locally or at an AAA server.

Step 3. As soon as the client has been successfully identified, the server verifies whether the callback service is allowed for the particular client that requested it. If so, the call initially placed by the client is disconnected.

Step 4. After the call is disconnected, the server waits a certain amount of time. Then it initiates a new callback to the client on a preconfigured number. If this call fails, additional attempts are not undertaken.

PPP is negotiated upon the client-initiated call only. The callback does not require a new PPP negotiation.

PPP Compression

Compression can significantly improve throughput on slow links. Cisco IOS offers PPP compression for all upper-layer protocols through Compression Control Protocol (CCP). This type of compression is considered a per-interface compression.

PPP CCP is an optional feature and is negotiated after the LCP phase. Cisco supports two CCP compression algorithms:

• STAC Checks the data stream for redundant strings and replaces them with tokens that are smaller. Then it creates tables of tokens with information about where the original type occurs within the data stream. These tables are used to replace redundant strings found in the subsequent data streams. This process uses more CPU but less memory.

• Predictor Checks the data for previous compression. The already-compressed data is sent as is. This process requires more memory but fewer CPU cycles.

Both of these algorithms base their operation on "dictionaries" of past data compression. When dictionaries become full, information is renewed. The choice of an algorithm depends on each individual case.

Compression should be used with care, because it can be a burden on system resources. Keep in mind that the rate of compression is dependent on the data type. For instance, text files are very good candidates for compression versus already-compressed file formats that would not yield a better than 1:1 compression ratio. Also, whenever possible, hardware compression should be chosen over software compression.

Although PPP compression can be bidirectional, it is recommended that only the remote client side perform compression. This way, the NAS can decompress the client's communication but doesn't compress its own. The reason for this is so that the NAS itself avoids performing compression that can use four times as much CPU power as decompression.

Multilink PPP

Multilink PPP (MPPP) is a technique of fragmenting packets and sending them over multiple data links to the PPP peer for reassembly. The benefit of MPPP lies in its ability to temporarily use additional bandwidth that's available between the two peers. MPPP is identified by an additional 4-byte header that dictates the fragment sequencing.

MPPP can be used in the following scenarios:

• In circuit-switched topologies for ISDN B channels or asynchronous connections Although MPPP was not designed exclusively for ISDN networks, it can certainly be successfully employed in such an environment by dynamically combining multiple B channels into a single larger-sized link to achieve N * 64 kbps bandwidth. The most usual of the N values is 2 because it is cost-effective and widely available. Combining two B channels would yield a total bandwidth of 128 kbps.

• Leased line All group members are synchronous serial lines.

• Dialed or leased lines Separate links can be of either origin.

• Different bandwidth of individual members The maximum fragment size is computed based on the slowest of all grouped links.

• Combination of applications producing different-sized datagrams Intermixing of datagrams without a multilink header.

MPPP Terms

Before you can understand the ins and outs of MPPP, you should become familiar with the following terms:

• Bundle A group of links between two PPP peers combined for MPPP operation.

• Bundle master An interface in control of a bundle.

• Bundle member An interface that is a part of a bundle.

• Dialer interface A rotary group for multiple interfaces such as ISDN BRI/PRI.

• Nondialer interface A serial interface.

• Virtual-access interface A temporary logical interface created for the purpose of an MPPP call. Its configuration is cloned from the dialer interface that placed or received the MPPP call.

• Virtual template Used for MPPP calls over nondialer interfaces to provide configuration information.

• Max-Receive-Reconstructed Unit (MRRU) An LCP option that indicates whether the LCP packet sender supports MPPP and the link's maximum byte limit.

• Endpoint discriminator An LCP option that specifies whether an MPPP bundle exists for the sending device.

MPPP Operation

Every MPPP bundle needs to be controlled by a single interface, the bundle master, which is a virtual-access interface.

The multilink PPP process starts out with LCP negotiation, including the MRRU option that takes place on the physical interface. PPP LCP negotiation determines whether MPPP can be used on the link. The bundle is identified by a peer's name, its endpoint discriminator, or both. Therefore, the PPP authentication is required to complete so that the peers can identify each other, name the bundle, and check whether another bundle of the same name already exists. If a bundle already exists, the new call simply joins in. No new negotiations of any sort are required for additional calls.

At this point, the NAS sets up a virtual-access interface as the bundle master. From this moment, all PPP negotiations are transferred from the physical interface to the virtual-access interface. The physical interface becomes a part of a bundle governed by a bundle master. Whatever NCP parameters are negotiated for the master are automatically applied to the rest of the bundle members.

MPPP Operation Issues

Three major issues are associated with MPPP's operation:

• A new link in a bundle is brought up and added to the bundle whenever the bundle master's saturation reaches the specified load. This value is represented as a percentage of 255, where 255 is the maximum.

• As mentioned, a new bundle can be created when no other bundle is between the same two peers already in existence. A single bundle can handle multiple connections between the same pair of devices. So the rules are simple: If there is no bundle, one can be built; if there is a bundle, the new call joins it. A bundle's existence is checked by using an expected name. The default order in which the bundles are named is first by the PPP authenticated name and then by the endpoint discriminator if no authentication has been negotiated.

• The links are dropped from a bundle when the bundle master's load falls below the configured threshold for a predetermined amount of time (the idle timer). The link that was added to the bundle last is the first one to be disconnected. With links of unequal bandwidth, the slowest link is dropped first.

Bandwidth Allocation Protocol

The specification for BAP is an extension of the MPPP concept. It was created to control the number of connections that an authorized user is allowed to establish at any time. BAP creates a standard set of rules that let MPPP change bandwidth on demand without the need for end-user participation in the configuration changes. As a result, the NAS can manage the usage of its access ports per caller.

BAP administers the method in which individual links are added to and deleted from an MPPP bundle. While LCP is negotiated, BAP is decided on, and a distinguishing link discriminator is given to every link in an MPPP bundle. It allows peers to specify which link is brought up or disconnected when the bandwidth increase or decrease is requested.

BAP can operate in two different modes: active and passive. Active mode means that the device can initiate or accept any type of connection request and determine whether links should be added to or removed from a multilink bundle. Active mode is for dialer interfaces, but not for virtual-template interfaces. Passive mode means that the device only responds to calls by accepting a call request, a callback request, or an addition or removal of a link by an active peer. Passive mode can be used for virtual-template interfaces and dialer interfaces.

BAP supports ISDN and asynchronous serial interfaces. When talking about BAP operation over dialer interfaces, only legacy dial-on-demand routing (DDR) dialer configurations are discussed. BAP does not support DDR dialer profiles.

BAP Operation

The first member link of the MPPP bundle is not negotiated under BAP. The subsequent member links, however, require BAP management. Although the first link does not belong to BAP, it does carry all BAP information packets. There are a total of eight BAP packet types:

• Call-Request

• Call-Response

• Callback-Request

• Callback-Response

• Link-Drop-Query-Request

• Link-Drop-Query-Response

• Call-Status-Indication

• Call-Status-Response

BAP follows Cisco's MPPP implementation in its judgment of load by monitoring the bundle master. The bundle load determines the need for bandwidth aggregation. Only with BAP, both peers have to agree on the bandwidth aggregation decision.

PPP Frame Format

• The Flag, Address, and Control field values are constant.

• The Protocol field reveals the protocol payload (such as TCP/IP or IPX).

• The Data field may be of variable length according to the maximum transmission unit (MTU) of the PPP interface.

• FCS is the frame check sequence.