Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

Other options may also be added to this list by optional feature protocols. For example,

Multilink PPP adds several options that must be negotiated during link setup.

The other device (let's call it say… device B ☺) receives the Configure-Request and

processes it. It then has three choices of how to respond:

1. If every option in it is acceptable in every way, device B sends back a Configure-Ack

(“acknowledge”). The negotiation is complete.

Figure 27: PPP LCP Link Configuration Process

This flowchart shows in more detail the negotiation process undertaken to configure the link by LCP. This

process begins when the PPP link enters the Link Establishment phase. After successful configuration, the

connection transitions to the Authentication phase.

Initiator Sends

Configure-Request

Me ssa ge

All Options

Recognized, With

Acceptable

Values?

Responder Processes

Configure-Request

Me ssa ge

Responding Device

Sends Configure-Ack

Me ssa ge

Devices Transition to

Authentication Phase

All Options

Recognized?

Responding Device

Sends Configure-Nak

Me ssa ge

Responder Sends

Configure-Reject

Me ssa ge

Yes

Initiator Processes

Response, Determines

New Negotiation

Parameters

Initiator Receives

Configure-Ack Me ssa ge

Yes

2. If all the options that device A sent are valid ones that device B recognizes and is

capable of negotiating, but it doesn't accept the values device A sent, then device B

returns a Configure-Nak (“negative acknowledge”) frame. This message includes a

copy of each configuration option that B found unacceptable.

3. If any of the options that A sent were either unrecognized by B, or represent ways of

using the link that B considers not only unacceptable but not even subject to negoti-

ation, it returns a Configure-Reject containing each of the objectionable options.

The difference between a Configure-Nak and a Configure-Reject is that the former is like

device B saying “I don't accept your terms, but I'm willing to haggle”, while the latter is

device B basically saying “No way Jose”. For example, if device A tries to request PAP as

the authentication protocol but device B wants to use CHAP, it will send a Configure-Nak. If

device B doesn't support authentication at all, it will send a Configure-Reject.

Note: Even after receiving a reject, device A can retry the negotiation with a new

Configure-Request.

LCP Link Maintenance

Once the link has been negotiated, LCP passes control to the appropriate authentication

and/or NCP protocols as discussed in the PPP Link Setup and Phases topic. Eventually the

link setup will complete and go into the open state. LCP messages can then be used by

either device to manage or debug the link:

☯ Code-Reject and Protocol-Reject: These frame types are used to provide feedback

when one device receives an invalid frame due to either an unrecognized LCP Code

(LCP frame type) or a bad Protocol identifier.

☯ Echo-Request, Echo-Reply and Discard-Request: These frames can be used for

testing the link.

LCP Link Termination

Finally, when the link is ready to be shut down, LCP terminates it. The device initiating the

shutdown (which may not be the one that initiated the link in the first place) sends a

Terminate-Request message. The other device replies back with a Terminate-Ack. A termi-

nation request indicates that the device sending it needs to close the link. Like a four-year-

old who tells you he “needs to go now, bad!”, this is a request that cannot be denied. ☺

Other LCP Messages

The standard RFC 1570, PPP LCP Extensions, also defines two new LCP message types.

The Identification message is used to allow a device to identify itself to its peer on the link.

The Time-Remaining message lets one device tell the other how much time remains in the

current session.

Relationship Between LCP and Other PPP Protocols

Note that many of the other protocols used in PPP are modeled after LCP. They use the

same basic techniques for establishing protocol connections, and send and receive a

subset of LCP message types. They also exchange configuration options in a similar

manner. The next topic shows how the Network Control Protocols (NCPs) are based on

LCP. You will see the same thing in looking at feature protocols such as CCP, ECP and

others.

PPP Network Control Protocols (IPCP, IPXCP, NBFCP and others)

One of the reasons why PPP is such a powerful technology is that it is flexible and

expandable. Even though it was originally created with the idea of carrying IP datagrams,

PPP's designers recognized that it would be short-sighted to think so narrowly. PPP could

easily carry data from many types of network layer protocols, and on some networks, it

might even be advantageous to let it carry datagrams from different layer three protocols

simultaneously.

Allowing PPP to support multiple network layer protocols would require it to have

knowledge of each one's idiosyncrasies. If we used only LCP for link configuration, it would

need to know all the unique requirements of each layer three protocol. This would also

require that LCP be constantly updated as new layer three protocols were defined and as

new parameters were defined for existing ones.

Instead of this inflexible design, PPP takes a “modular” approach to link establishment. LCP

performs the basic link setup, and after (optional) authentication, invokes a Network Control

Protocol (NCP) that is specific to each layer three protocol that is to be carried over the link.

The NCP conducts a negotiation of any parameters that are unique to the particular network

layer protocol. More than one NCP can be run for each LCP link; the process of how this is

done and the relationship between the NCP links and LCP link can be seen in the topic on

PPP link setup and phases.

Each of the common network layer technologies has a PPP NCP defined for it in a separate

RFC. These documents are usually named in this pattern: “The PPP <layer three protocol

name> Control Protocol”. The most common ones are The PPP Internet Protocol Control

Protocol (IPCP), The PPP Internetworking Packet Exchange Control Protocol (IPXCP), and

The PPP NetBIOS Frames Control Protocol (NBFCP)

. These are the NCPs for IP, IPX and

NBF (also called NetBEUI), respectively. A separate NCP is also defined for IP version 6,

the PPP IP Version 6 Control Protocol (IPv6CP).

Operation of PPP Network Control Protocols

Each NCP operates very much like a “lite” version of LCP, as you can see by examining

Figure 28 (and comparing it to Figure 26, which shows the messaging for LCP). Like LCP,

each NCP performs functions for link setup, maintenance and termination—only it deals

with its particular type of NCP link and not the “overall” LCP link. Each NCP uses a subset

of seven of the message types defined in LCP, and uses them in very much the same way

as the message type of the same name is used in LCP:

☯ Link Configuration: The process of setting up and negotiating the parameters of the

particular NCP link (once an LCP link is established) is accomplished using Configure-

Request, Configure-Ack, Configure-Nak and Configure-Reject messages just as

described in the LCP topic, except these ones are particular to the NCP. The configu-

ration options are of course different; they are the network layer protocol parameters

being negotiated.

☯ Link Maintenance: Code-Reject messages can be sent to indicate invalid code

values (NCP frame types).

☯ Link Termination: An NCP link can be terminated using Terminate-Request and

Terminate-Ack. (Remember that NCP links are set up within an LCP link; there can be

more than one NCP link open, and closing NCP links doesn't terminate the LCP link.

Also, NCP links do not need to be closed when an LCP link is terminated.)

Key Concept: After the primary PPP link is established using LCP, each network

layer protocol to be carried over the link requires the establishment of the appropriate

NCP link. The most important of these is the PPP Internet Protocol Control Protocol

(IPCP), which allows IP datagrams to be carried over PPP.

An Example NCP: The Internet Protocol Control Protocol (IPCP)

Let's look at the NCP for IP, IPCP. When PPP is set up to carry IP datagrams, IPCP is

invoked in the Network-Layer Protocol phase (one of the PPP phases) to set up an IP NCP

link between the two devices. The setup is carried out using the four “Configure-”

messages. For IP, there are two configuration options that can be specified in an IPCP

Configure-Request:

☯ IP-Compression-Protocol: Allows devices to negotiate the use of something called

“Van Jacobson TCP/IP header compression”. This compresses the size of TCP and IP

headers to save bandwidth. Thus, this is similar in concept to the Protocol-Field-

Compression and Address-and-Control-Field-Compression (ACFC) options in LCP.

☯ IP-Address: Allows the device sending the Configure-Request to either specify an IP

address it wants to use for routing IP over the PPP link, or to request that the other

device supply it with one. This is most commonly used for dial-up networking links.

Again, the receiving device can send back an IPCP Configure-Ack, an IPCP Configure-

Nak, or an IPCP Configure-Reject, just as they work in LCP. The other NCPs are similar, but

use different configuration options. After configuration is complete, data can be sent for the

layer three protocol corresponding to the NCP negotiated. This is indicated by using the

appropriate value for the Protocol field in PPP data frames containing that layer three data.

Note: As an aside, the full expanded name of the NCP for IP is “The Point-to-Point

Protocol Internet Protocol Control Protocol”. Three “protocols” in one name. That

has to be some sort of a record. ☺

Figure 28: PPP IP Control Protocol (IPCP) Message Exchanges

The overall operation of the NCPs, such as IPCP, is very similar to that of LCP. After LCP configuration

(including authentication) is complete, IPCP Configure-Request and Configure-Ack messages are used to

establish an IPCP link. IP Data can then be sent over the link. If the IPCP connection is no longer needed it

may be terminated, after which the LCP link remains open for other types of data to be transmitted. It is not

necessary, however, to explicitly terminate the IPCP link before terminating the LCP connection.

Initator

IPCP Configure-Request

IPCP Configure-Ack

Initiate IPCP Configuration

(LCP Link Establishment

and Authentication)

IP Data

Process IPCP Configuration

Request

(LCP Link Establishment

and Authentication)

Finish IPCP Configuration

...

Receive IP Close Request,

Notify Other Device

Responder

Terminate IP Link

Send and

Receive IP Data

IPCP Terminate-Request

IPCP Terminate-Ack

Non-IP Data Non-IP Data

...

LCP Terminate-Request

LCP Terminate-Ack

Send and

Receive

Non-IP Data

Send and

Receive IP Data

Send and

Receive

Non-IP Data

Receive IP Close Request,

Notify Other Device

Terminate Link

PPP Authentication Protocols: Password Authentication Protocol (PAP) and

Challenge Handshake Authentication Protocol (CHAP)

PPP was designed to provide layer two connectivity over a variety of serial links and other

physical layer technologies, some of which have much more of a concern about security

than others. For example, suppose you hook two machines in your computer lab together

with a serial cable and want to run PPP between them. When one of these initiates a PPP

link with the other, you don't really need to worry about “who's calling”. On the other hand,

consider an Internet Service Provider using PPP for remote dial-in users. They generally

want to allow only their customers to connect, not just anyone.

The PPP protocol suite was designed to include the use of an optional authentication

protocol for links where authentication is important. During basic link setup by LCP, devices

can negotiate the use of an authentication protocol. If they agree, after the LCP link is set

up a series of authentication messages are sent to verify the identity of the device initiating

the link. Only if authentication is successful can the link configuration proceed.

The PPP suite initially defined two different authentication protocols: the Password Authen-

tication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP).

Note: Incidentally, in addition to PAP and CHAP, it is possible to use proprietary

authentication schemes. This requires that the appropriate configuration option

values be programmed into LCP for placement in the Authentication-Protocol

configuration option.

Password Authentication Protocol (PAP).

PAP is a very straight-forward authentication scheme, consisting of only two basic steps, as

shown in Figure 29:

1. Authentication Request: The initiating device sends an Authenticate-Request

message that contains a name and a password.

2. Authentication Reply: The responding device looks at the name and password and

decides whether to accept the initiating device and continue in setting up the link. If so,

it sends back an Authenticate-Ack. Otherwise, it sends an Authenticate-Nak.

Simple. Now, remember what Einstein said about simplicity? PAP is another example of

something that is just too simple for its own good. Chief amongst its flaws is that it transmits

the user name and password in clear text across the link. This is a big “no-no” in security

protocols, as it means any eavesdropper can get the password and use it in the future. PAP

also provides no protection against various security attacks. For example, an unauthorized

user could simply try different passwords indefinitely and hope he or she eventually found

one that worked. PAP also puts control of the authentication squarely on the shoulders of

the initiating device (usually a client machine) which is not considered desirable.

Challenge Handshake Authentication Protocol (CHAP)

The most important difference between PAP and CHAP is that CHAP doesn't transmit the

password across the link. Now you may be wondering—if that's the case, how is the

password verified? Well, think of it this way. PAP works by the initiator telling the authenti-

cator “here's the password I know, see if it matches yours”. CHAP does this by having each

of the devices use the password to perform a cryptographic computation and then check if

they each get the same result. If they do, they know they have the same password.

CHAP Authentication Procedure

In CHAP, a basic LCP link is set up between the initiator (calling client) and authenticator

(generally the server that is deciding whether to grant authentication). The authenticator

then takes charge of the authentication process, using a technique called a three-way

handshake. This is a fairly common general authentication procedure; the same basic

technique is used, for example, in IEEE 802.11 Shared Key Authentication.

The three-way handshake steps are as follows (and as illustrated in Figure 30):

Figure 29: PPP Password Authentication Protocol (PAP) Authentication

PAP works using a simple exchange of a request containing name and password information, and a reply

indicating whether or not authentication was successful.

Initator

Authenticate-Request

Authenticate-Ack

Authenticate-Nak

Initiate Authentication

(LCP Link Establishment)

Validate Name and

Password In Request

(LCP Link Establishment)

If Successful,

Authenticated. Otherwise,

Try To Authenticate Again

...

Responder

(NCP Link Establishment,

Normal Operation)

(NCP Link Establishment,

Normal Operation)

...

1. Challenge: The authenticator generates a frame called a Challenge and sends it to

the initiator. This frame contains a simple text message (sometimes called the

challenge text). The message has no inherent special meaning so it doesn't matter if

anyone intercepts it. The important thing is that after receipt of the Challenge both

devices have the same challenge message.

2. Response: The initiator uses its password (or some other shared “secret” that the

authenticators also knows) to encrypt the challenge text. It then sends the encrypted

challenge text as a Response back to the authenticator.

3. Success or Failure: The authenticator performs the same encryption on the

challenge text that the initiator did. If the authenticator gets the same result that the

initiator sent it in the Response, the authenticator knows that the initiator had the right

password when it did its encryption, so the authenticator sends back a Success

message. Otherwise, it sends a Failure message.

Figure 30: PPP Challenge Handshake Authentication Protocol (CHAP) Authentication

CHAP uses a three-way handshake beginning with a Challenge from the authenticating device (usually the

remote server accessed by a host). This message is encrypted and returned to the authenticating device,

which checks to see if the device trying to authenticate used the correct password (or other “shared secret”).

Initiator

Response

Challenge

(LCP Link Establishment)

Generate Challenge Text

and Send to Initiator

(LCP Link Establishment)

Encrypt Challenge Text,

Send Response to

Authenticator

...

Responder

(Authenticator)

(NCP Link Establishment,

Normal Operation)

(NCP Link Establishment,

Normal Operation)

...

Success

Failure

Validate Encrypted

Challenge Text and Send

Results to Initiator

If Successful,

Authenticated. Otherwise,

Try To Authenticate Again

Benefits of CHAP

You can see the beauty of this: it verifies that the two devices have the same “shared

secret” but doesn't require that the secret be sent over the link. The Response is calculated

based on the password, but the content of the Response is encrypted and thus, much

harder to derive the password from. CHAP also provides protection against replay attacks,

where an unauthorized user captures a message and tries to send it again later on. This is

done by changing an identifier in each message and varying the challenge text. Also, in

CHAP the server controls the authentication process, not the client that is initiating the link.

Key Concept: PPP supports two authentication protocols: PAP and CHAP. PAP is a

simple request/reply authentication protocol that is widely considered to be inade-

quate since it sends the user name and password in clear text and provides little

protection against many security concerns. CHAP uses a three-way handshake procedure

and is preferred over PAP in most implementations.

CHAP itself is not perfect, but it's a heck of a lot closer to perfection than PAP is. In fact, the

IETF made a rather strong statement in this regard when it revised the original RFC

describing PAP and CHAP, and included only CHAP in the new standard. Despite this, PAP

is still used in some applications, because it is simple. And well, some folks think they are

smarter than Einstein. ☺ Seriously though, PAP can be fine in situations where security is

not a big deal, but CHAP is much better and still not really that complicated.

PPP Feature Protocols

PPP is the standard for data link layer connectivity over serial links because its core

protocols provide a solid operational foundation, as we saw in the previous section.

However, PPP's popularity is based not just on its highly capable link establishment and

management features. It also has a number of very useful features that provide important

security and performance benefits to network users.

In this section I describe the protocols that implement several of the most common "extra"

features in PPP. I begin with a discussion of PPP link quality monitoring. I describe the sets

of protocols used to configure and implement data compression and data encryption. I then

discuss the PPP Multilink Protocol (MP, MLPPP), which allows PPP to bundle multiple low-

speed links into a single high-speed link. I also cover the BAP and BACP protocols, which

are used to manage the operation of Multilink PPP.

PPP Link Quality Monitoring/Reporting (LQM/LQR)

PPP includes optional authentication in recognition of the varying security needs of the

many different kinds of links over which PPP may operate. These links also differ greatly in

terms of their quality. Just as we don't need to worry about authentication much when two

machines are linked with a short cable, we also can feel pretty confident that data sent

between them is going to arrive intact. Now, contrast that to a PPP session established over

a long-distance telephone call. For that matter, how about PPP over a dial-up call using an

analog cellular phone?

PPP includes in its basic package a provision for detecting errors in sent frames (a CRC

field), and higher-layer protocols like TCP also include methods of providing robustness on

noisy lines. These techniques allow a link to tolerate problems, but provide little in the way

of useful information about what the status of the link is. In some situations, devices may

want to be able to keep track of how well the link is working, and perhaps take action on it.

For example, a device experiencing too many errors on a dial-up connection might want to

cut off and retry a new call. In some cases a device might want to try an alternate method of

attachment if the current physical link is not working well.

Recognizing this need, the PPP suite includes a feature that allows devices to analyze the

quality of the link between them. This is called PPP Link Quality Monitoring or LQM. PPP is

set up generically to allow any number of different monitoring functions to be used, but at

present there is only one, called Link Quality Reporting (LQR). LQR works by having a

device request that its peer (the other device on the link) keep track of statistics about the

link and send them in reports on a regular basis.

LQR Setup

Before LQR can be used it must be set up, which is done by LCP as part of the negotiation

of basic link parameters in the Link Establishment phase. The device opening the link

requests link monitoring by including the Quality-Protocol configuration option in its