Transcript pppx
As first introduced in Chapter 2, “Wide Area Network (WAN) Technologies,” PPP is a standard for using point-to-point network links that provides the following: ■ A Data Link Layer encapsulation method that supports multiple protocols simultaneously 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 protocols 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 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 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: 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 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. 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. PPP Connection Termination After a PPP connection is established, it can be terminated at any time by either the connection-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 protocols that were operating over it that the point-topoint interface is no longer available. Link Control Protocol LCP, described in RFC 1661, is a simple protocol to configure a common set of PPP connection 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 typespecific data LCP Options The data portion of an LCP message consists of one or more LCP options for the ConfigureRequest, Configure-Ack, Configure-Nak, and ConfigureReject 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 connection from the LCP negotiation initiator. For two PPP peers, Peer A and Peer B, Peer A initiates 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 Configure-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 negotiations 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-torouter 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 (MSCHAP 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 password 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. 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 authentication, a calling peer is unable to determine whether it is calling a valid answering peer. 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 calling 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 Protocol After the authentication phase of the PPP connection process, CBCP negotiates the use of callback. 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 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. 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 automatically configure the IP address of name servers such as Domain Name System (DNS) and Windows Internet Name Service (WINS) servers. 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. 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 0x8055 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 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 MSCHAP 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). 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 peruser authentication and connection 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 Connections 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 automatically 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 verify the credentials of the calling or answering PPP peer. During callback negotiation, the calling 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.