PPP Phases and LCP - Industrial Networks II PDF
Document Details

Uploaded by HappierStar
TU Dublin
Keith Smyth
Tags
Summary
This document describes the phases of a Point-to-Point Protocol (PPP) connection, including the establishment, authentication, network, open, and termination phases. It also details the Link Control Protocol (LCP) used by PPP to negotiate link parameters. The document focuses on configuration and negotiation aspects of PPP connections.
Full Transcript
CWE091- 5 Industrial Networks II Oct 2021 PPP phases and LCP (Revision from previous lecture) Dead: In the dead phase the link is not being used. There is no active carrier (at the physical layer) and the line is quiet....
CWE091- 5 Industrial Networks II Oct 2021 PPP phases and LCP (Revision from previous lecture) Dead: In the dead phase the link is not being used. There is no active carrier (at the physical layer) and the line is quiet. Establish: When one of the nodes starts the communication, the connection goes into this phase. In this phase, options are negotiated between the two parties. If the negotiation is successful, the system goes to the authentication phase (if authentication is required) or directly to the networking phase. The link control protocol (LCP) packets are used for this purpose. Several packets may be exchanged here. Authenticate: The authentication phase is optional; the two nodes may decide, during the establishment phase, not to skip this phase. However, if they decide to proceed with authentication, they send several authentication packets. If the result is successful, the connection goes to the networking phase, otherwise, it goes to the termination phase. Network: In the network phase, negotiation for the network layer protocols takes place. PPP specifies that two nodes establish a network layer agreement before data at the network layer can be exchanged. The reason is that PPP supports multiple protocols at the network layer. If a node is running multiple protocols simultaneously at the network layer, the receiving node needs to know which protocol will receive the data. Open: In the open phase, data transfer takes place. When a connection reaches this phase, the exchange of data packets can be started. The connection remains in this phase until one of the endpoints wants to terminate the connection. Terminate: In the termination phase the connection is terminated. Several packets are exchanged between the two ends for house cleaning and closing the link. These are exchanged in LCP packets. Link Control Protocol: The Link Control Protocol (LCP) is responsible for establishing, maintaining, configuring, and terminating links. It also provides negotiation mechanisms to set options between the two endpoints. Both endpoints of the link must reach an agreement about the options before the link can be established. All LCP packets are carried in the payload field of the PPP frame with the protocol field set to C021 in hexadecimal. The code field of the LCP packet defines the type of LCP packet. There are 11 types of packets for configuring, terminating and debugging the link. Keith Smyth Page 1 of 6 CWE091- 5 Industrial Networks II Oct 2021 Notes directly from: http://technet.microsoft.com/en-us/library/cc957992.aspx The PPP Link Control Protocol (LCP) is documented in RFC 1661. LPC negotiates link and PPP parameters to dynamically configure the data link layer of a PPP connection. Common LCP options include the PPP MRU, the authentication protocol, compression of PPP header fields, callback, and multilink options. LCP Packet Structure LCP uses the PPP Protocol ID of 0xC0-21. The packet structure of LCP is illustrated in Figure 7.11. Each LCP packet is a single LCP message consisting of an LCP Code field identifying the type of LCP packet, an Identifier field so that requests and replies can be matched, a Length field indicating the size of the LCP packet and LCP packet type–specific data. Packet type Config Req Config Ack Config Nack Config Rej Figure 7.11 LCP Packet Structure Table 7.7 lists the LCP packet types documented in RFC 1661. Table 7.7 LCP Packet Types LCP LCP Packet Description Code Type Configure- Sent to open or reset a PPP connection. Configure-Request contains a list 1 Request of LCP options with changes to default option values. Sent when all of the values of all of the LCP options in the last Configure- Configure-Request received are recognized and acceptable. 2 Ack When both PPP peers send and receive Configure-Acks, the LCP negotiation is complete. Sent when all the LCP options are recognized, but the values of some Configure- 3 options are not acceptable. Configure-Nack includes the offending Nack options and their acceptable values. Sent when LCP options are not recognized or not acceptable for Configure- 4 negotiation. Configure-Reject includes the unrecognized or non- Reject negotiable options. Keith Smyth Page 2 of 6 CWE091- 5 Industrial Networks II Oct 2021 Terminate- 5 Optionally sent to close the PPP connection. Request Terminate- 6 Sent in response to the Terminate-Request. Ack Sent when the LCP code is unknown. The Code-Reject message includes 7 Code-Reject the offending LCP packet. Sent when the PPP frame contains an unknown Protocol ID. The Protocol- Protocol-Reject message includes the offending LCP packet. 8 Reject Protocol-Reject is typically sent by a PPP peer in response to a PPP NCP for a LAN protocol not enabled on the PPP peer. 9 Echo-Request Optionally sent to test the PPP connection. Sent in response to an Echo-Request. 10 Echo-Reply The PPP Echo-Request and Echo-Reply are not related to the ICMP Echo Request and Echo Reply messages. Discard- 11 Optionally sent to exercise the link in the outbound direction. Request LCP Options When using the Configure-Request, Configure-Ack, Configure-Nack, and Configure-Reject LCP packet types, the LCP data portion of the LCP packet consists of one or more LCP options as illustrated in Figure 7.12. Each LCP option consists of an option Type field, a Length field indicating the total length in bytes of the option and the data associated with the option. Packet type Config Req Config Ack Config Nack Config Rej Etc… Option MRU · AUTH PAP or CHAP Add and control field compression Etc… Figure 7.12 LCP Options Keith Smyth Page 3 of 6 CWE091- 5 Industrial Networks II Oct 2021 Table 7.8 lists common LCP options negotiated by Microsoft PPP peers. For information about other LCP options, see RFC 1661. Table 7.8 LCP Options Option Option Option Name Description Type Length The maximum size (up to 65,535) of the PPP frame. The Maximum Receive Unit (MRU) 1 4 Bytes default MRU is 1,500. If neither peer is changing the default, this option is not negotiated. A bit map that enables (bit set to 1) or disables (bit set to 0) the use of character escapes for asynchronous links for Asynchronous the 32 ASCII control characters from 0x00 to 0x20. By Control Character 2 6 default, character escapes are used. The ACCM bit map Map (ACCM) is set to 0x00-00-00-00 for links with XON/XOFF software flow control. Indicates the authentication protocol used during the authentication phase of the connection. Authentication Values for this field for Microsoft PPP peers are 0xC2- 3 5 or 6 Protocol 27 for EAP, 0xC2-23-80 for MS-CHAP version 1, 0xC2- 23-81 for MS-CHAP version 2, 0xC2-23-05 for MD5- CHAP, 0xC0-27 for SPAP, and 0xC0-23 for PAP. A random number chosen to distinguish a peer and * Magic Number 5 6 detect looped back lines. A flag indicating that the PPP protocol ID be compressed Protocol 7 2 to a single octet when the 2-byte protocol ID is in the Compression range 0x00-00 to 0x00-FF. Address and A flag indicating that the PPP Address field (always set Control Field 8 2 to 0xFF) and the PPP Control field (always set to 0x03) Compression be removed from the PPP header. A 1-octet indicator of how callback is to be determined. For remote access clients and server running Microsoft® 13 or Windows 32-bit operating systems, the callback option Callback 3 0x0D octet is set to 0x06, indicating that the callback is determined during Callback Control Protocol (CBCP) negotiation. sand data to the Loopback- interface that back comes USED FOR TESTING ONLY Keith Smyth Page 4 of 6 CWE091- 5 Industrial Networks II Oct 2021 LCP Negotiation Process The LCP negotiation is a series of LCP packets exchanged between PPP peers to negotiate a set of options and option values when sending data. The LCP negotiation is actually two separate dialogs between two PPP peers (Peer 1 and Peer 2): 1. Peer 1 asks, negotiates, and then receives confirmation of the LCP options that are used when sending data to Peer 2. This dialog starts with Peer 1 sending a Configure-Request message and ends when Peer 2 sends a Configure-Ack message. 2. Peer 2 asks, negotiates, and then receives confirmation of the LCP options that are used when sending data to peer 1. This dialog starts with Peer 2 sending a Configure-Request message and ends when Peer 1 sends a Configure-Ack message. Peer 1 and Peer 2 do not have to use the same set of LCP options. When a PPP peer sends its initial Configure-Request, the response is any of the following: A Configure-Nack message because one or more options have unacceptable values. A Configure-Reject message because one or more of the options are unknown or not negotiable. A Configure-Ack message because all of the options have acceptable values. When a PPP peer receives a Configure-Nack message or Configure-Reject message in response to its Configure-Request message, it sends a new Configure-Request message with modified options or option values. When a Configure-Ack message is received, the PPP peer is ready to send data. Figure 7.13 shows a hypothetical LCP negotiation process for Peer 1 using the fictional options W, X, Y, Z. EACH REQUEST HAS A DIFFERENT ID. ID IS USED TO MATCH THE Figure 7.13 Sample LCP Negotiation RESPONSE Keith Smyth Page 5 of 6 CWE091- 5 Industrial Networks II Oct 2021 From the LCP messages in Figure 7.13: 1. Peer 1 sends a Configure-Request message requesting option W, option X set to 100, option Y set to 0, and option Z. Options W and Z are flag options. 2. Peer 2 does not understand option Z so it sends a Configure-Reject message containing option Z. 3. Peer 1 sends a new Configure-Request message requesting option W, option X set to 100, and option Y set to 0. 4. Peer 2 prefers that option X be set to 200 so it sends a Configure-Nack message containing option X and its preferred value. 5. Peer 1 sends a new Configure-Request message requesting option W, option X set to 200, and option Y set to 0. 6. Peer 2 sends a Configure-Ack message. Each time Peer 1 sends a new Configure-Request message, it changes the Identifier value in the LCP header so that Configure-Request messages can be matched with their responses. The previous process only configures how Peer 1 sends data to Peer 2. A separate LCP negotiation must be done so that Peer 2 can be configured to send data to Peer 1. Very often, the LCP packets for the two dialogs are intermixed during the connection process. Peer 1 is configuring the way it sends data at the same time as Peer 2. Keith Smyth Page 6 of 6