Remote Access

Today's corporate environments contain more telecommuters than ever before. As a result, dial-in access is an important part of network connectivity. Although users need to have several computer components, including a Layer 3 protocol and necessary applications, this chapter primarily covers the login process using PPP.

PPP is not the only dial-in type supported; Cisco routers support Serial Line Internet Protocol (SLIP) by default. The biggest problem with SLIP is that it only works with Transmission Control Protocol/Internet Protocol (TCP/IP). For users who need to send Internetwork Packet Exchange (IPX) or AppleTalk traffic, PPP is the protocol of choice.

You can configure a router to automatically accept a certain type of connection when a user dials in. Go into line configuration mode for the appropriate line and enter the following command:

 autoselect <arap | ppp | slip | during-login> 

The PPP option for autoselect looks for frames that contain the hexadecimal value 7E, 01111110 in binary, in the flag field. during-login causes a username/password prompt to appear, allowing the user to immediately enter the username and password without pressing any keys to bring the prompt up. The user needs to configure PPP on a Windows machine to open a terminal window after dial-in.

Connectivity

Table 4.1 shows how PPP compares to the Open Systems Interconnect (OSI) model. PPP spans from the connection to Layer 1 to the connection to Layer 3. The Link Control Protocol (LCP) controls everything related to call setup. All sorts of authentication, compression, and so on are handled here. LCP is responsible for everything that is negotiated during call setup. On the other end of PPP are the Network Control Protocol (NCP) plug-ins. The NCP plug-ins are the plug-ins that encapsulate a useful protocol in the PPP format.

Cisco uses both "Control Protocol" and "Control Program" for defining the "CP" part of the NCP abbreviation.

Not every protocol here is strictly a network-layer protocol. If you look on a router after setting it up, you see a Cisco Discovery Protocol (CDP) control protocol (CP).

Table 4.1. OSI Model and PPP Chart

IP	IPX	Additional Protocols	Layer
IP	IPX	Other protocols	Layer 3
IPCP	IPXCP	Other CPs	Layer 3
NCP (directly connected to specific NCP above)			Layer 2
LCP			Layer 2
Standards-based high-level data link control (HDLC but not the Cisco version)			Layer 2
Physical connectivity, including cables (EIA/TIA 232, V.35, and so on)			Layer 1

PPP consists of several types of CPs that do a variety of things:

• HDLC This control is not the Cisco encapsulation across serial lines; instead, it is based on ISO standards. PPP is more than an encapsulation type and needs something to do other than just encapsulation.

• LCP This protocol handles the connectivity part beyond the HDLC portion. The LCP is responsible for hello packets, authentication, and so on. It is one of the primary items to observe via debug commands if you have a problem connecting.

• NCP A base form of NCP has several extensions, much like a fork. Each tine of the fork, each protocol-specific CP, allows that protocol to transport data across a PPP connection. This portion sets PPP apart from SLIP.

As mentioned earlier, the LCP is responsible for authentication, among other things. You have two choices for authentication, Password Authentication Protocol (PAP) and CHAP. As with any type of authentication, a username and password are required. In addition to authentication the LCP allows for callback, compression, and multilink:

• Callback A setting that allows the router that the user called to turn around and call the user back. If you remember the days of the bulletin board system (BBS), some BBSs wouldn't allow a user to dial in and do whatever. Instead, the BBS software would hang up and call the user back to make sure that the user was who he said he was by calling the number in the user's record. Cisco bills callback as a method to provide "billing consolidation," but it also increases security. Callback was first supported with IOS 11.0(3).

• Compression Allows for more data to cross WAN links than the link natively supports. Several different types of compression supported have different resource-utilization levels. They are covered in more detail later in this chapter. Compression was first supported in IOS 10.3.

• Multilink Allows for multiple data circuits to be logically bound together to increase throughput. Frames are broken up and transmitted across the series of channels at the same time and then recombined at the destination. Multilink was first supported in IOS 11.0(3).

Because PPP is an encapsulation protocol, it normally only travels across part of the network. Figure 4.1 shows how you can use PPP in a remote access setting.

Figure 4.1. A PPP connection.

A user dials up a remote network and needs to connect with servers on that network or maybe beyond. From the user's computer to the access server, data is encapsulated in a format suitable for a serial connection. PPP is one of the potential formats, but other serial connection methods include Frame Relay, HDLC, SLIP, and others. PPP is used here because it supports the features that we need.

Because we don't necessarily know where the other end of the connection is, when a user dials up and wants access to our network, it makes sense to provide for authentication control. Because mobile users often use low-speed circuits, a form of compression might also be useful. Neither of these features are supported in the Frame Relay or HDLC standards, but they are with PPP.

Authentication

PAP and CHAP are the two types of router-based authentication supported under PPP. In addition to local authentication, PPP supports sending a request to an authentication server, such as Terminal Access Controller Access Control System Plus (TACACS+) or Remote Authentication Dial-In User Service (RADIUS).

PAP's one major problem is passwords that cross the line in clear text. The user sends a request to the router saying, "Let me in; this is my username and this is my password." The router then permits or denies the user based on that information. The user controls the connection and authentication attempt.

From user to router, the authentication is one way. The router attempts to authenticate the user and that's it. With a router-to-router connection, each router authenticates the other.

CHAP is a bit more secure. The called router doesn't just accept whatever information is given to it; it makes sure the remote device is not spoofing by sending a challenge to the remote device.

Next, the calling router sends its password in a hash generated with an MD5 (Message Digest 5) hashing function. The called router compares the received hash against its copy to validate. This process prevents anyone sniffing the circuit to easily see the password.

Finally, CHAP has a third feature that makes it more desirable than PAP: the use of repeated challenges. Every two minutes, the called device generates a challenge that the remote device must respond to. Because all these challenges contain a random part, an attacker can't analyze the circuit and play back the hash to gain access.

Cisco has maintained for several versions of older IOS that CHAP automatically generated authentication requests when in fact, it did not. This feature had also been testable in previous versions of this exam.

The following steps outline the CHAP authentication process:

1. The user dials into the CHAP authenticating device.

2. The called device generates a challenge. This challenge has a challenge identifier (a type 01), a sequencing ID, a random value, and the authentication name of the challenger.

3. The calling device responds to the challenge by providing its username and password, the sequencing ID, and the random value. The password, ID, and random number are hashed and put into a packet with a response ID (a type 02), the sequencing ID, and the calling device's username.

4. When the authenticating device receives the response, it looks at the sequencing ID to find the original challenge packet for the random value. Then, it places the ID, the random value, and the password the called device has for the calling device into the hashing program and generates a hash. The two hashes are compared.

5. One of two things now happens. If the authentication is successful, then a message is sent authorizing access. This message uses a type 03 CHAP message. If the comparison of hashes fails, then access is denied with a type 04 message.

Hashing

Just what is a hash? Hashing is the process of performing an irreversible encryption. Two popular methods for hashing are MD5, which uses 128-bit keys, and Secure Hash Algorithm (SHA), which uses 160-bit keys. The information gets encrypted, then the hashing process truncates or pads as necessary to have a 96-bit hash value. Every CHAP hash is the same length, 96 bits. Once the hashing algorithm is done, it should be nearly impossible to reliably regenerate the original message.

Hashes are used in many applications but are normally used in two ways. The first is to hash a value and send both across the network. You use this type of transmission if you don't care whether anyone sees the data; you're concerned about it being changed. An example is a routing update. It probably isn't too important if someone sees a routing update for 10.1.2.0, but if the update got changed, you would have problems. This method is useful if the target doesn't know what the data is supposed to be. Another way of using a hash involves sending just the hashed value, which is what CHAP does. Both sides must know what the value is supposed to be, so when the hashed value arrives, it's what the recipient was expecting.

Suppose 98765 is the value that we want to send. For us to send it hashed, we need to apply the hash process to this value. Let's say the hashing algorithm says that we must reverse the number and multiply by 543; then, it says we have to send four digits:

98765 becomes 56789

56789 * 543 = 30836427

Because 30836427 is more than four digits, we must truncate. If we had only three digits of output, we would pad the hash by adding a digit. In this case, 30836427 becomes 3083. So if our password is 98765, our router runs the password through the hashing process and comes up with 3083. Once it reaches the far side with the authentication request, the remote router takes the password it has for the user in question, hashes the password, and compares the hash with the one from the initiating router. If the hashes match, the password is good and the user is allowed access.