PPP

PPP

Objectives:

• Configure and verify a PPP connection between Cisco routers
• Configure and verify a basic WAN serial connection

The PPP protocol has become the industry standard for connecting multi-vendor environments over WANs. Whenever people think about using an “industry standard” for anything, they usually think of the bland, saltine-cracker type of protocol. Surprisingly, PPP defies the norm and is one of the most feature-packed WAN protocols in existence. Although it functions at the Data Link layer of network connectivity, it comprises multiple sub-protocols that serve multiple functions. This provides you with a feature-rich connection, even when bringing up a WAN link between non-Cisco devices.

PPP can function over nearly any type of WAN connection that does not implement its own, specific mechanism for transporting data (such as frame relay and ATM). This means you can use PPP to connect if you are using an asynchronous (modem-like) connection or a synchronous (high-speed) point-to-point serial connection. Although PPP fills a single layer on the OSI Model (the Data Link layer), it has multiple “sublayers” that give it all its functionality. Each sub-layer adds specific functionality to the PPP protocol suite. Figure 22.2 depicts the three PPP sub-layers as they relate to the OSI model. Notice that all three of these sub-layers fit into the single Data Link layer.

FIGURE 22.2 PPP sub-layers.

It is easy to get confused when expanding the already confusing OSI model into sub-layers for a specific protocol. This is just a logical view of the PPP protocol describing how it is able to include all the functions it advertises. The following sections look at each of these sub-layers, one at a time.

EXAM ALERT
You need to know the sub-layers of PPP and their functions for the CCNA exam because these directly relate to the features PPP provides.

Sub-Layer 1: ISO HDLC

Initially, seeing this layer in PPP seems quite odd. Wasn’t HDLC a competing protocol to PPP?
This sub-layer of PPP comprises the industry standard ISO HDLC. This sub-layer is responsible for allowing PPP to be supported by multiple devices. It gives the devices that run PPP common ground to stand on when they communicate with each other. As you will see in just a moment, the LCP layer above is responsible for negotiating all the features of HDLC. Because all devices that run HDLC may not support every single feature, the HDLC sub-layer enables the base PPP communication to continue, even if the platforms support different features.

Sub-Layer 2: Link Control Protocol (LCP)

You can think of the LCP sub-layer as the feature negotiation layer. All the features that PPP supports are negotiated by LCP. These features are

• Authentication
• Callback
• Compression
• Multilink

EXAM ALERT
Be able to pick the features negotiated by LCP out of a line-up.

Authentication

The authentication features of PPP enable you to require a username and password for the connecting device to bring up the WAN connection. This is not a very important feature on leased line, point-to-point connections because the only way a hacker would be able to get a device connected to the WAN would be to render one of the on-site administrators unconscious and replace the on-site router with one of the hacker’s own. The PPP authentication features are most useful for dial-up connections that could be reached by users connected to the Public Switched Telephone Network (PSTN).

For example, you may choose to connect a modem to your router through the AUX port to allow dial-up access, should all the LAN and WAN connectivity to the router fail. This modem would be assigned a phone number, accessible from any computer modem in the world. PPP authentication would require a username and password to be entered before the modem connection would bridge a successful connection. There are two types of authentication supported by PPP: the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP).

PAP
This authentication protocol is one of the earliest authentication types to be released for WAN connectivity. If PAP is enabled for the connection, the call flow progresses as follows:

1. Client dials up to a router running PPP.
2. After the link (connection) is established, the client sends its username and password at the LCP (feature) layer.
3. The PPP router checks the username and password against its user database and allows or denies the client.

Although this list of three steps is a logical authentication process, it has a few flaws. First off, the client dictates the timing of sending the username and password; the server (router running PPP) receives the username and password whenever the client decides to send it. This causes the PAP mechanism to be susceptible to playback attacks. This is a type of attack where a hacker captures (sniff) packets from a conversation and then plays the packets back in an attempt to mirror the connection. Because the client is in complete control of the authentication attempt, the server accepts the played-back packets whenever the client decides to send them.

The authentication of PAP is also done in clear text, which makes it even more vulnerable to packet-sniffing intruders. Anyone who does have a way of monitoring the connection can capture the packets, break them open, and find the username and password used for authentication in clear text. Can you say, “network devastation”?
With all this being said, the only reason you would choose to use the PAP method for authentication is if you were using very old equipment that did not support the newer method of
authentication, CHAP.

CHAP
CHAP is a much more secure procedure for connecting to a PPP-based system. The authentication process for CHAP goes like this:

1. Client dials up to a router running PPP.
2. The router sends a challenge message to the client.
3. The client responds with the hash of the password it is configured to use.
4. The router looks up the password hash against its database. If the hash matches, the client is allowed into the network.
5. After the client is authenticated, the router sends re-authentication messages at random

intervals, requiring the client to send the password hash whenever prompted. Doesn’t that list already make you feel better than PAP? The first thing to notice is that the router (server) is in control of the authentication process. Rather than accepting the username and password whenever the client decides to send it, the router demands the username and password on its timeframe. If the client isn’t ready to ante up with the credentials, the server immediately terminates the connection. This makes performing a playback attack much more difficult to accomplish.

Even if a hacker were to successfully execute a playback attack with CHAP, the random authentication interval ensures the hacker will not be connected for long. Executing the initial playback attack would require intricate timing for the hacker to be successful. The random authentication requests would be nearly impossible to keep up.

The clear text issues have also been solved by using a system known as password hashing. Without getting too deep into cryptography and security mechanisms, you must understand that this is not the same thing as encrypting a password and sending it across the network. Given the time, nearly any encryption algorithm can be broken if the data is captured. Using a hashed version of the password means that the client never actually sends the real password across the line. To accomplish this, the router (PPP server) and the PPP client must be configured to have the identical password. Before the client sends the password, it runs an irreversible mathematical algorithm on the password. The result of that algorithm is called the hash, which is sent to the server. The server runs the same algorithm on its password and compares the two hashes.

If the answer is the same, the client successfully authenticates. Now, you may be thinking the same thing I did when I first heard about this process, “Well, can’t you just get the mathematical formula and reverse it to figure out what the password is from the hash? For example, if the formula is (the password) ∞2 = the hash, could you just take the (hash÷2) = the password?” Fair question, but just wait until you see the formula. The hashing method (formula) used is known as the MD5 hash. This formula has been engineered with the sole purpose of being irreversible. With that in mind, someone might capture the password hash and find out that it is 5,381,120,123,590.

Now the trick is to reverse-engineer an irreversible formula to figure out how the algorithm came up with that answer. It would be much easier for hackers to render the IT staff unconscious at whatever site they were looking to compromise and steal the servers containing the data they needed.

Callback

Just as the name implies, the PPP callback functionality enables a dial-up server (or router) running PPP to use a predefined number to call the person back who initially dialed into the location. One of the major advantages of this function is the increased security: It requires the dial-up user to authenticate and then be present at the predefined phone number to be able to receive the return call. The other advantage is the toll consolidation. If you have long distance users dialing into the network, you leave your company at the mercy of the long distance carriers of your users. By using PPP callback, you can ensure that the company long distance charges are applied, which are typically much lower than normal carrier charges. A PPP callback process goes through the following steps:

1. A user dials into a router using PPP and authenticates.
2. Upon a successful authentication, the router terminates the connection (typically without any notification) and dials the user back at the predefined number configured by the administrator.
3. Upon reconnect, the user authenticates a second time.
4. Upon a successful authentication, the user is granted network access.

Compression

When I first heard about compression on a WAN link, my mind flashed back to the days of the Stacker compression program of Microsoft DOS. This program slowed your computer down to a crawl to gain a few megabytes of storage space on a hard disk. Surprisingly, one of the two compression algorithms used on PPP WAN connections is named “Stacker”; however, the effects are much less devastating than they were with the old DOS program.

Using compression to make your WAN connection more efficient is not a new concept. These technologies have been around since the days of DOS. However, these technologies have become much more viable on today’s networks because of the increase in CPU and memory resources on network equipment. The tradeoff when choosing to use compression is that you gain more WAN bandwidth by sacrificing your router’s processor and memory resources. How much you sacrifice depends on the type of compression algorithm you use.

Stacker
The compression type analyzes the data that is being sent and replaces continuous streams of characters with codes. These codes are stored in a dictionary and looked up on the other end of the connection to rebuild the original data. The Stacker algorithm (which is actually called LempelZiv) uses a “flat dictionary-style compression.” This means that for every packet of data, it goes through the same process: Look up the character streams in the dictionary, replace the characters with codes, begin again. Therefore, it is very good for network connections that have constantly varying data types (such as SQL, HTTP, FTP, and so on) crossing them. It doesn’t matter what the previous traffic was; the same compression algorithm is applied. The Stacker algorithm is notoriously heavy on CPU resources and has less effect on the router’s memory resources.

Predictor
This compression algorithm received its name because it literally attempts to predict the next character stream that will be sent or received. It uses a similar dictionary lookup process as Stacker; however, it takes the most common characters looked up and builds a cached index file. Anytime some traffic needs to be sent or received, the index file is checked first. If the character stream (or codes) is not found in the index file, it then consults the full dictionary to find the necessary compression or decompression algorithm. Therefore, the Predictor algorithm works best on network connections that have fairly similar traffic patterns (that can be cached in the index file). For example, perhaps you have a WAN link back to a central office that houses an intranet server that users access to update the corporate e-commerce website.

In this case, the traffic patterns would be very similar (HTTP/HTTPS) for most times of the day. The Predictor algorithm usually uses more memory resources and has less effect on the router’s CPU than the Stacker algorithm (as long as the traffic patterns do not vary largely).

Microsoft Point-to-Point Compression
Microsoft has its own compression algorithm for PPP, aptly named the Microsoft Point-to-Point Compression (MPPC). This protocol offers slightly improved processor and bandwidth utilization for Microsoft Windows–based clients. Because other devices, such as Cisco routers, would need to support this compression algorithm for Microsoft Windows to use it, Microsoft released the algorithm as an RFC standard (RFC 2118). Under the licensing in this RFC, Microsoft permits other vendors to implement MPPC solely for the purpose of connecting to other MPCC clients. MPPC therefore is used only to allow Windows dial-up users to use compression.

Multilink

PPP multilink enables you to bundle multiple WAN connections into a single, logical connection. This could be as small as bundling two 33.6Kbps modems together to make a 67.2Kbps connection, or bundling four T1 lines together to give yourself a 6.176Mbps connection. The separate interfaces that are bundled together are no longer seen as individual interfaces, but rather join a larger “logical” multilink interface. You can assign this single interface its own IP address, configure authentication, or optimize the logical line with compression. It acts and feels like a real interface, even though it could potentially comprise many physical links.

There are two major benefits to using Multilink PPP (MLPPP). First off, the logical link becomes a single point of management. Rather than figuring out what the traffic utilization is on all the individual physical lines, you can focus your monitoring software (if you have some) on just a single interface. The second benefit to MLPPP is the fact that all physical links bundled in the logical group get exact load balancing. When I say “exact,” I mean the down-tothe-exact-bit-level kind of exact. MLPPP chops all your packets (referred to as fragmentation) into exactly equal sizes before it sends them across the line. This leads to the one drawback of using MLPPP: slightly increased processor and memory utilization on your router.

Sub-Layer 3: Network Control Protocol

The final sub-layer of PPP is what gives it the functionality to allow multiple Network layer protocols to run across a single WAN link at any given time. I think of this layer as the PPP DUPLO ® LEGO ® block connector. Have you ever seen the DUPLO ® blocks for small children? They all have that standard connector with which any other DUPLO ® can connect so the child can put any two pieces together (which provides positive affirmation, I’m sure). In that same sense, the Network Control Protocol (NCP) sub-layer of PPP has open-source, network-layer connectors that anyone can plug into. For example, the TCP/IP protocol has a connector called IPCP (the CP stands for “control protocol”) that enables TCP/IP to run across a PPP WAN link. IPX/SPX has a connector called IPXCP.

With the open-source nature of this protocol, I could create a “Jeremy protocol” and then write a JeremyCP to allow it to run across a PPP WAN link. Cisco has written its own extension called CDPCP that enables the Cisco Discovery Protocol to run across a PPP WAN link, which enables the routers on each end of the connection to use CDP to see each other.

• CCNA Study Guide