Point-to-Point Protocol (PPP)

Introduction to PPP

In the early days of the internet, connecting a single computer to a network over a simple serial link, such as a dial-up modem or a direct cable connection, was a challenge. The first major solution, SLIP (Serial Line Internet Protocol), was very basic. It could send IP packets, but it could not perform error detection, had no security, and could not handle protocols other than IP. A solution supporting more functions and protocols was needed.

Enter the Point-to-Point Protocol (PPP). Developed in the early 1990s, PPP defines how to establish a direct link between two networking nodes. In addition to carrying data, it can negotiate link parameters, optionally authenticate the remote peer, configure network settings such as IP addresses, and carry packets from multiple network protocols at the same time. Its principles are still used in technologies such as for broadband connections.

The Layered Architecture of PPP

PPP is a suite of protocols organized into a layered architecture. It has three main components:

Encapsulation Protocol:
This defines the format used to transport packets over the point-to-point link. PPP uses a structure very similar to HDLC (High-Level Data Link Control), including flag sequences that mark the beginning and end of a frame and an FCS for error detection.
Link Control Protocol (LCP):
LCP establishes, configures, and tests the data link before user data is exchanged. It negotiates options such as the maximum frame size (MRU), the authentication protocol if one is required, and mechanisms for detecting problems such as a looped-back or otherwise misconfigured link.
Network Control Protocols (NCPs):
This is a family of protocols responsible for configuring the different Network Layer protocols that will be used over the PPP link. PPP is protocol-independent, meaning it can carry packets from various protocols like IP, IPX, and AppleTalk simultaneously. For each network protocol being used, a corresponding NCP must be active. The most common NCP is the Internet Protocol Control Protocol (IPCP), which is responsible for assigning and configuring the IP address for the connection, as well as other parameters like DNS server addresses.

PPP Frame Format

Every piece of information sent across a PPP link, whether user data or a control message, is placed in a PPP frame. Its structure is largely based on HDLC.

Flag (1 byte): The frame begins and ends with the hexadecimal sequence 0x7E (binary 01111110). The flag separates frames. Depending on the link type, PPP uses HDLC-style bit stuffing or octet stuffing so that this pattern does not appear accidentally in the data.
Address (1 byte): Since PPP is for point-to-point links, the receiver is known. The field is therefore normally set to the all-stations address 0xFF (binary 11111111).
Control (1 byte): This field is retained from the HDLC format. PPP does not use HDLC flow control or sequencing in this field, leaving reliability to higher-layer protocols such as TCP. The value is 0x03, indicating an unnumbered information frame.
Protocol (1 or 2 bytes): This field identifies the data in the Information field and enables PPP to carry multiple protocols. Different values distinguish control packets from user data. Common values include:
- 0x0021 for an IPv4 packet
- 0x8021 for IPCP (IP Control Protocol) packets
- 0xC021 for LCP (Link Control Protocol) packets
- 0xC023 for PAP (Password Authentication Protocol) packets
- 0xC223 for CHAP (Challenge-Handshake Auth Protocol) packets
Information (Payload): This field contains data such as an LCP negotiation message, an authentication packet, or a complete IP datagram. Its length is variable and cannot exceed the value defined by the . On links aligned with Ethernet, the value is often 1500 bytes.
Frame Check Sequence (FCS) (2 or 4 bytes): An error-detection field, typically a 16-bit CRC (CRC-16). The sender calculates the FCS and the receiver verifies it. If the values do not match, the frame is discarded, indicating a transmission error. FCS detects an error but does not correct it or provide retransmission at the PPP layer. Further action depends on the upper-layer protocol.

The PPP Connection Lifecycle

Establishing a PPP connection uses several phases. Each phase begins after the conditions of the previous phase are met.

Phase 1: Link Establishment (LCP Negotiation)
Once a physical connection is detected, such as a modem carrier signal, the link enters this phase. The two devices exchange LCP packets to negotiate basic connection parameters. They use messages such as:
- Configure-Request: "I would like to set up the link with these options (e.g., MRU of 1500 bytes, using CHAP for authentication)."
- Configure-Ack (Acknowledge): "I agree to all of your requested options."
- Configure-Nak (Negative Acknowledge): "I agree to the general idea, but I cannot accept this specific value (e.g., your MRU is too large), please try again with this alternative."
- Configure-Reject: "I do not understand or support one of the options you are requesting. Let's proceed without it."
This phase is complete once both sides have sent and received a Configure-Ack. The link is then open for the remaining PPP phases.
Phase 2: Authentication (Optional)
If authentication was negotiated in the LCP phase, the link proceeds to authentication. One side authenticates to the other using the agreed protocol, usually PAP or CHAP. The connection can proceed after successful authentication.
Phase 3: Network Layer Configuration (NCP Negotiation)
With the link established and authenticated, the appropriate NCP begins its own negotiation. For an internet connection, this would be IPCP. In one typical exchange, the client sends an IPCP Configure-Request asking the server to assign a dynamic IP address. The server may respond with an IPCP Configure-Nak containing a free address, which the client confirms with its own Configure-Request; the server then sends a Configure-Ack. DNS server addresses can also be negotiated here. Once the NCP phase is complete, the connection is operational.
Phase 4: Link Termination
When the connection is no longer needed, it must be closed gracefully. Either side can initiate termination by sending an LCP Terminate-Request packet. The other side responds with a Terminate-Ack, and the logical link is closed. This is followed by the termination of the physical connection (e.g., hanging up the modem).

PPP Authentication: PAP and CHAP

PPP includes two commonly encountered authentication methods that protect credentials in different ways.

PAP (Password Authentication Protocol)

PAP is a simple authentication mechanism based on a request and response exchange:

The client sends its username and password to the server in plain text.
The server checks the credentials against its user database and sends back either an Authentication-Ack (success) or Authentication-Nak (failure).

Security Warning: The password is sent without encryption, so PAP does not protect it from eavesdropping. The method is considered obsolete and should not be used on untrusted links.

CHAP (Challenge-Handshake Authentication Protocol)

CHAP is a three-way handshake protocol that does not send the password directly over the link. Its protection depends on the hash method and configuration.

The server sends a "Challenge" message to the client, which contains a random value.
The client takes this challenge value and its secret password, combines them, and calculates a one-way (typically using the MD5 algorithm).
The client sends this calculated hash value back to the server in a "Response" message.
The server, which also knows the client's secret password, performs the exact same hash calculation independently. It then compares its own result with the hash received from the client.
If the hashes match, the server sends a "Success" message; otherwise, it sends a "Failure" message.

Key Advantages of CHAP: The actual password is not sent across the network. A random challenge for each attempt limits reuse of a captured response. The server can also issue new challenges periodically during the connection to check that the same peer is still participating in the session.