Point-to-Point Protocol (PPP)As first introduced in Chapter 2, “Wide Area Network (WAN) Technologies,” PPP is a stan-dard for using point-to-point network links that provides the following: ■ A Data Link Layer encapsulation method that supports multiple protocols simulta-neously on the same link. ■ A protocol for negotiating the Data Link Layer characteristics of the point-to-point connection named the Link Control Protocol (LCP). ■ A series of protocols for negotiating the Network Layer properties of Network Layer pro-tocols over the point-to-point connection named Network Control Protocols (NCPs). For example, RFCs 1332 and 1877 describe the Internet Protocol Control Protocol (IPCP), the NCP for IP. IPCP is used to negotiate an IP address, the addresses of name servers, and the use of the Van Jacobsen TCP compression protocol.

PPP Connection ProcessThere are four phases to a PPP connection,

all of which must be completed before data can be

sent on the connection. The four phases are the following

1. PPP configuration using LCP 2. Authentication using a PPP

authentication protocol (optional 3. Callback 4. Protocol configuration using NCPs

Phase 1: PPP Configuration Using LCP In the first phase of the PPP connection process, PPP connection parameters are configured using LCP. With LCP, the PPP peers negotiate a common set of parameters that are used for

all subsequent phases of the PPP connection and for sending data. Some of the communication parameters that are negotiated are the following: ■ The maximum receive unit (MRU), the largest PPP frame that can be sent on the connection ■ Whether the Address and Control fields in the PPP header are used (for links that use the High-Level Data Link Control [HDLC] encapsulation that is described in RFC 1662) ■ Whether the Protocol field in the PPP header can be compressed from 2 bytes to 1 byte ■ The PPP authentication protocol to be used during the authentication phase ■ Whether Multilink PPP (MP) is used For more information, see the section titled “Link Control Protocol,” later in this chapter.

Phase 2: AuthenticationAfter LCP negotiation, the authentication

process using the PPP authentication protocol nego-

tiated during phase 1 is performed. This process is specific to the PPP authentication protocol

used. For more information, see the section titled “PPP Authentication Protocols” later in

this chapter

Phase 3: CallbackIf the authentication process succeeds and callback

behavior is configured, the answering PPP peer terminates the connection and initiates a

connection to the original calling PPP peer, a feature of PPP implementations known as callback.

The PPP implementation in Windows Server 2008 and Windows Vista uses the Callback

Control Protocol (CBCP) to complete the callback phase. For more information, see the

section titled “Callback and the Callback Control Protocol,” later in this chapter.

Phase 4: Protocol Configuration Using NCPsAfter PPP is configured, the original initiating

PPP peer is authenticated, and callback is done

(optional and only if configured), individual data protocols and ancillary PPP services such

as encryption and compression are configured using NCPs. For more information, see the

section titled “Network Control Protocols,” later in this chapter.

PPP Connection TerminationAfter a PPP connection is established, it can

be terminated at any time by either the connec-

tion-initiating or connection-receiving PPP peer. PPP connections can be terminated by user

action, connection policy action (such as terminating the connection after a specific amount

of idle time), or link failure. When the PPP connection terminates, PPP informs the data pro-

tocols that were operating over it that the point-to-point interface is no longer available.

Link Control ProtocolLCP, described in RFC 1661, is a simple protocol to configure a

common set of PPP connec-tion parameters (for phase 1 of the PPP connection). It is also

used by NCPs to configure specific data protocol configuration parameters (for phase 2 of

the PPP connection). LCP uses the PPP Protocol ID 0xC0-21. Figure 4-1 shows an LCP f■ Code A 1-byte field that identifies the type of LCP message■ Identifier A 1-byte field that identifies a specific pair of LCP

messages: the request and ■ Length A 2-byte length field that indicates the size of the LCP

message in bytes■ Data A variable-sized field that contains the LCP frame type-

specific data

LCP OptionsThe data portion of an LCP message consists of

one or more LCP options for the Configure-Request, Configure-Ack, Configure-Nak, and

Configure-Reject LCP frames. An LCP option is formatted in type-length-value (TLV) format. A

1-byte Type field indicates the option type, a 1-byte Length field indicates the length in bytes

of the entire option, and the Option Data field contains the data of the option. Figure

4-2 shows an LCP message that contains LCP options.

LCP Negotiation Process LCP is used to negotiate the parameters of PPP when sending data in a single direction on the PPP connection. Different PPP parameters could be negotiated in the two different directions of data travel on a PPP connection. Therefore, each PPP peer must perform a separate LCP negotiation. An LCP negotiation is used by a PPP peer to establish how the other PPP peer should send data to it. Each LCP negotiation is a series of LCP frames to negotiate the use of a common set of parameters for data sent by the PPP peer on the other side of the PPP con- nection from the LCP negotiation initiator. For two PPP peers, Peer A and Peer B, Peer A ini- tiates an LCP negotiation for the data to be sent by Peer B and Peer B initiates a separate LCP negotiation for the data to be sent by Peer A. An individual LCP negotiation consists of an initial set of LCP options using the LCP Config- ure-Request message. The specific set of LCP options is negotiated using Configure-Nak and Configure-Reject messages and finally confirmed with a Configure-Ack message. Both negoti- ations occur simultaneously, making it more difficult to read the captures of PPP connection establishments.

PPP Authentication Protocols After LCP negotiation is complete, the authentication protocol agreed on

during LCP negotia- tion using LCP option 3 is used to establish the identity and credentials of

the PPP peer that is requesting the PPP connection, typically a remote access client (for remote

access dial-up or vir- tual private network [VPN] connections) or a calling router (for router-to-

router dial-up or VPN connections). The authentication process is phase 2 of the PPP connection

establishment. Windows Server 2008 and Windows Vista support the following PPP

authentication protocols: ■ Password Authentication Protocol (PAP) ■ Challenge Handshake Authentication Protocol (CHAP) ■ Microsoft Challenge Handshake Authentication Protocol version 2 (MS-

CHAP v2) ■ Extensible Authentication Protocol (EAP)

PAP PAP is a very simple, plain-text authentication protocol described in RFC 1334. The entire PAP negotiation consists of the following messages: 1. The connection-initiating PPP peer (the calling peer) sends a PAP Authenticate-Request message to the authenticating PPP peer (the answering peer), which contains the calling peer’s user name and password in plain-text. 2. The answering peer validates the user name and password. If the user name and pass- word are correct, the answering peer sends a PAP Authenticate-Ack message. If not, the answering peer sends a PAP Authenticate-Nak message. Obviously, PAP is not a secure authentication protocol. A malicious user that can capture the PAP frames sent between the calling peer and answering peer can view the contents of the

PAP Authenticate-Request message to determine the user name and password of a valid user account. The use of PAP is highly discouraged and is only included in Windows Server 2008 and Windows Vista for troubleshooting and compatibility with PPP peers that do not support more secure authentication protocols.

CHAPCHAP is a more secure authentication protocol,

described in RFC 1994, which uses a challenge–response exchange of messages to validate

that the calling peer has knowledge of the user’s password. The password itself is never sent.

Although more secure than PAP, CHAP does not provide mutual authentication. The calling

peer authenticates to the answering peer but the answering peer does not authenticate to the

calling peer. Without mutual authentica-tion, a calling peer is unable to determine whether it

is calling a valid answering peer.

MS-CHAP v2MS-CHAP v2 is a CHAP-based authentication protocol

described in RFC 2759 that, unlike CHAP, provides mutual authentication. With MS-CHAP

v2, the answering peer receives confirmation that the calling peer has knowledge of

the user account’s password and the call-ing peer receives confirmation that the answering

peer has knowledge of the user account’s password. To provide for this mutual authentication,

both peers issue a challenge and must receive a valid response or the connection is

terminated

EAP EAP was designed as an extension to PPP to allow for more extensibility

and flexibility in the implementation of authentication methods for PPP connections. For PAP,

CHAP, and MS- CHAP v2, the authentication process is a fixed exchange of messages. With

EAP, the authenti- cation process can consist of an open-ended conversation, in which

messages are sent by either PPP peer on an as-needed basis. In addition, unlike the PPP

authentication protocols discussed so far in this chapter, EAP does not select a specific

authentication method during phase 1 of the connection. Rather, the selection of a specific EAP

authentication method, known as an EAP type, is done during phase 3 of the connection. EAP is

described in RFC 3748.

Callback and the Callback Control ProtocolAfter the authentication phase of the PPP connection process,

CBCP negotiates the use of call-back. If callback is negotiated, the answering PPP peer

terminates the PPP connection, and then calls the original calling PPP peer at a specified phone

number. CBCP messages use the PPP Protocol ID 0xC0-29 and have the same structure as LCP

messages. However, only the first seven LCP message types are used, corresponding to LCP

Codes 1 through 3. For the Callback-Request (Code set to 1), Callback-Response (Code set

to 2), and Callback-Ack (Code set to 3) messages, the data portion of the CBCP message

contains one or more CBCP options.

Network Control ProtocolsAfter the callback phase of the PPP

connection process, individual NCPs are used to negotiate

the configuration of networking protocols, such as TCP/IP, and the additional PPP facilities of

compression and encryption.

IPCPPCP is used to automatically configure

TCP/IP configuration for a calling PPP peer. IPCP as

used by Windows-based PPP peers is described in RFCs 1332 and 1877. RFC 1332 defines

the original set of IPCP options and RFC 1877 defines an additional set of options to automat-

ically configure the IP address of name servers such as Domain Name System (DNS) and Win-

dows Internet Name Service (WINS) servers.

Compression Control ProtocolCompression Control Protocol (CCP), described in RFC

1962, allows PPP peers to negotiate the use of a data compression algorithm. CCP messages

use the PPP Protocol 0x80-FD and have the same structure as LCP messages. However, only

the first seven LCP message types are used, corresponding to LCP Codes 1 through 7. For the

Configure-Request (Code set to 1), Configure-Ack (Code set to 2), Configure-Nak (Code

set to 3), and Configure-Reject (Code set to 4) CCP messages, the data portion of the CCP

message contains one or more CCP options. Table 4-6 lists these CCP options.

Encryption Control ProtocolEncryption Control Protocol (ECP), described

in RFC 1968, allows PPP peers to negotiate the

use of a data encryption algorithm. ECP messages use the PPP Protocol IDs 0x80-53 or 0x80-

55 and have the same structure as LCP messages. However, because Windows-based PPP

peers only support the use of MPPE for encryption of PPP payloads, ECP is not supported or

used. For more information, see RFC 1968.

Network Monitor ExampleThe following summary of Capture 04-01 in the \Captures

folder on the companion CD-ROM is an example of a successful PPP connection using the MS-

CHAP v2 authentication protocolIn this example, the following frames show the four phases of

the PPP connection:■ Frames 1 through 8 and frames 10 and 11 are for phase 1,

the LCP negotiation.■ Frames 9, 12, and 13 are for phase 2, authentication.■ Frames 14 through 16 are for phase 3, callback.■ Frames 16, 19, 20, and 23 are for CCP negotiation (in phase

4). ■ Frames 18, 21, 22, and 24 through 28 are for IPCP

negotiation (in phase 4).

PPP over EthernetPPP over Ethernet (PPPoE) is a method of

encapsulating PPP frames so that they can be sent over an Ethernet network. PPPoE was created so

that Internet service providers (ISPs) that deploy a broadband Internet access technology in a

bridged Ethernet topology, such as cable modems or Digital Subscriber Line (DSL), can use

the per-user authentication and connec-tion identification facilities of PPP to identify

individual customer connections for accounting and billing purposes. PPPoE is described in RFC

2516.

PPPoE Discovery Stage The PPPoE discovery process consists of the following four PPPoE frames 1. The PPPoE Active Discovery Initiation (PADI) frame is sent by the PPPoE client to the Ethernet broadcast address (0xFF-FF-FF-FF-FF-FF). Within the Ethernet payload, the Code field is set to 9, the Session ID is set to 0, and there is a single Service-Name PPPoE tag, as well as other tags as needed. If the network connection in the Network Connec- tions folder corresponding to the broadband Internet adapter has been configured with a service name, that service name is sent. Otherwise, the PADI frame is sent with a null service name. 2. The PPPoE Active Discovery Offer (PADO) frame is sent by the AC to the unicast MAC address of the PPPoE client. Within the Ethernet payload, the Code field is set to 7, the Session ID is set to 0, there are the AC-Name and Service-Name tags, and other tags as needed. If the network connection in the Network Connections folder corresponding to the broadband Internet adapter has not been configured with a service name, it is auto- matically set to the value of the Service-Name tag in the PADO frame. 3. The PPPoE Active Discovery Request (PADR) frame is sent by the PPPoE client to the unicast MAC address of the AC. Within the Ethernet payload, the Code field is set to 25, the Session ID is set to 0, and there is a Service-Name tag and other tags as needed. 4. The PPPoE Active Discovery Session-confirmation (PADS) frame is sent by the AC to the unicast MAC address of the PPPoE client. Within the Ethernet payload, the Code field is set to 101, the Session ID field is set to the session ID for the PPP session of the PPPoE client, and there is a Service-Name tag, as well as other tags as needed.

PPPoE Session Stage

Summary PPP is used for encapsulation, link negotiation, and network protocol negotiation for network protocol packets that are sent over a point-to-point link. The PPP connection process has four phases: link negotiation, authentication, callback negotiation, and network protocol negotiation.

During link negotiation, each PPP peer determines how it will send PPP frames. During authentication, PPP authentication protocols such as MS-CHAP v2 or EAP-TLS are used to ver- ify the credentials of the calling or answering PPP peer. During callback negotiation, the call- ing and answering PPP peers determine whether the answering PPP peer will call the calling peer back and at which phone number. During network protocol negotiation, NCPs such as IPCP, CCP, and ECP are used to determine the use and configuration of TCP/IP, compression, and encryption. PPPoE is a method of encapsulating PPP frames so that they can be sent over an Ethernet link. A PPPoE connection consists of two phases: a PPPoE discovery phase and a PPPoE session phase. After a PPPoE connection is negotiated during the discovery phase, PPP is used to negotiate a connection and send network protocol frames during the PPPoE session phase.