1 / 25

Point-to-Point Protocol (PPP)

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 -

liz
Télécharger la présentation

Point-to-Point Protocol (PPP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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.

  2. PPP Connection Process • There 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

  3. 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.

  4. Phase 2: Authentication • After 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

  5. Phase 3: Callback • If 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.

  6. Phase 4: Protocol Configuration Using NCPs • After 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.

  7. PPP Connection Termination • After 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.

  8. Link Control Protocol • LCP, 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

  9. LCP Options • The 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.

  10. 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.

  11. 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)

  12. 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.

  13. CHAP • CHAP 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.

  14. MS-CHAP v2 • MS-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

  15. 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.

  16. Callback and the Callback Control Protocol • After 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.

  17. Network Control Protocols • After 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.

  18. IPCP • PCP 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.

  19. Compression Control Protocol • Compression 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.

  20. Encryption Control Protocol • Encryption 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.

  21. Network Monitor Example • The 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 protocol • In 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).

  22. PPP over Ethernet • PPP 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.

  23. PPPoE Discovery Stage • The PPPoE discovery process consists of the following four PPPoEframes • 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.

  24. PPPoE Session Stage

  25. 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.

More Related