PPP (Point-to-Point Protocol

Vicente González Ruiz

December 14, 2014

Contents

1 Intro
2 EL PPP (Point-to-Point Protocol)
3 Data framing
 3.1 Byte stuffing
4 Protocolo de control del enlace
5 NCP
6 PPP options
 6.1 Authentication
 6.2 Compression
 6.3 Error detection
 6.4 Multilink
 6.5 PPP Callback
7 PPP Authentication
8 PAP Authentication Protocol
9 CHAP Authentication Protocol

1 Intro

One of the most common types of WAN connection is the point-to-point connection. Point-to-point connections are used to connect LANs to service provider WANs, and to connect LAN segments within an Enterprise network. A LAN-to-WAN point-to-point connection is also referred to as a serial connection or leased-line connection, because the lines are leased from a carrier (usually a telephone company) and are dedicated for use by the company leasing the lines. Companies pay for a continuous connection between two remote sites, and the line is continuously active and available. Understanding how point-to-point communication links function to provide access to a WAN is important to an overall understanding of how WANs function.

Point-to-Point Protocol (PPP) provides multiprotocol LAN-to-WAN connections handling TCP/IP, IPX, and AppleTalk simultaneously. It can be used over twisted pair, fiber-optic lines, and satellite transmission. PPP provides transport over ATM, Frame Relay, ISDN and optical links. In modern networks, security is a key concern. PPP allows you to authenticate connections using either Password Authentication Protocol (PAP) or the more effective Challenge Handshake Authentication Protocol (CHAP).

2 EL PPP (Point-to-Point Protocol)

3 Data framing

PIC

3.1 Byte stuffing

PIC

4 Protocolo de control del enlace


PIC


Figure 1: Diagrama de estados del protocolo de control del enlace en PPP.

The PPP Process  
 
  Initiator              Responder  
      |                      |  
      v                      v  
   ------------------------------  
          LCP negotiation  
   ------------------------------  
      |                      |  
      v                      v  
   ------------------------------  
     PAP or CHAP authentication  
             (optional)  
   ------------------------------  
      |                      |  
      v                      v  
   ------------------------------  
           NCP negotiation  
   ------------------------------  
      |                      |  
      v                      v  
   ------------------------------  
        Send and receive data  
   ------------------------------  
      |                      |  
      v                      v  
   ------------------------------  
          NCP termination  
   ------------------------------  
      |                      |  
      v                      v  
   ------------------------------  
          LCP termination  
   ------------------------------  
      |                      |  
      v                      v

The LCP Negotiation Process  
 
  Initiator                  Responder  
.....>|                          |<.........  
.     |    Configure-Request     |  
.     +------------------------->| Options accepted?  
.    /|\                      Y / \ N      .  
.   / | \                      /   \ Options recognized?  
.  /  |  \                    /  Y /\ N    .  
. |   |   |   Configure-Ack  |    |  |     .  
. |<--|---|------------------+    |  |     .  
. |   |   | Configure-Reject |    |  |     .  
. |   |<--|------------------|----+  |     .  
. |   |   |  Configure-Nack  |    :  |     .  
. |   |   |<-----------------|-------+     .  
. |    \ /                   |    :  :     .  
. |     : Determine new      |    ..........  
. |     : negotiation        |  
..|...... paramenters        |  
  |                          |  
  v                          v

The LCP/NCP Termination Process  
 
          Initiator                  Responder  
              |                          |  
Receive IP    |    Terminate-Request     |  
close request +------------------------->| Terminate Link  
              |     Terminate ACK        |  
              |<-------------------------+  
              |                          |  
              v                          v

 The Data field of a PPP frame that carries an LCP message:  
 
 LCP Data = Code | Identifier | Length | Data  
 
 Code (1B) = Type of LCP packet  
 
 Identifier (1B) = Matchs packet requests and replies  
 
 Length (2B) = Lenght of the LCP Data field  
 
 Data (variable length) = The information transmitted by the LCP Data

LCP Code LCP Packet Type Description



1 Configure-Request Sent to open or reset a PPP connection. Configure-Request contains a list of LCP options with changes to default option values.
2 Configure-Ack Sent when all of the values of all of the LCP options in the last Configure-Request received are recognized and acceptable. When both PPP peers send and receive Configure-Acks, the LCP negotiation is complete.
3 Configure-Nack Sent when all the LCP options are recognized, but the values of some options are not acceptable. Configure-Nak includes the offending options and their acceptable values.
4 Configure-Reject Sent when LCP options are not recognized or not acceptable for negotiation. Configure-Reject includes the unrecognized or non-negotiable options
5 Terminate-Request Optionally sent to close the PPP connection.
6 Terminate-Ack Sent in response to the Terminate-Request.
7 Code-Reject Sent when the LCP code is unknown. The Code-Reject message includes the offending LCP packet.
8 Protocol-Reject Sent when the PPP frame contains an unknown Protocol ID. The Protocol-Reject message includes the offending LCP packet. 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.
10 Echo-Reply Sent in response to an Echo-Request.
11 Discard-Request Optionally sent to exercise the link in the outbound direction.



5 NCP

After the link has been initiated, the LCP passes control to the appropriate NCP. Although initially designed for IP datagrams, PPP can carry data from many types of Network layer protocols by using a modular approach in its implementation. It can also carry two or more Layer 3 protocols simultaneously. Its modular model allows the LCP to set up the link and then hand the details of a network protocol to a specific NCP. Each network protocol has a corresponding NCP. Each NCP has a corresponding RFC. There are NCPs for IP, IPX, AppleTalk, and many others. NCPs use the same packet format as the LCPs.

When the NCP has successfully configured the Network layer protocol, the network protocol is in the open state on the established LCP link. At this point, PPP can carry the corresponding Network layer protocol packets.

6 PPP options

PPP may include the following LCP options:

6.1 Authentication

Peer routers exchange authentication messages. Two authentication choices are Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Authentication is explained in the next section.

6.2 Compression

Increases the effective throughput on PPP connections by reducing the amount of data in the frame that must travel across the link. The protocol decompresses the frame at its destination. Two compression protocols available in Cisco routers are Stacker and Predictor.

6.3 Error detection

Identifies fault conditions. The Quality and Magic Number options help ensure a reliable, loop-free data link. The Magic Number field helps in detecting links that are in a looped-back condition. Until the Magic-Number Configuration Option has been successfully negotiated, the Magic-Number must be transmitted as zero. Magic numbers are generated randomly at each end of the connection.

6.4 Multilink

Cisco IOS Release 11.1 and later supports multilink PPP. This alternative provides load balancing over the router interfaces that PPP uses. Multilink PPP (also referred to as MP, MPPP, MLP, or Multilink) provides a method for spreading traffic across multiple physical WAN links while providing packet fragmentation and reassembly, proper sequencing, multivendor interoperability, and load balancing on inbound and outbound traffic. Multilink is not covered in this course.

6.5 PPP Callback

To enhance security, Cisco IOS Release 11.1 and later offers callback over PPP. With this LCP option, a Cisco router can act as a callback client or a callback server. The client makes the initial call, requests that the server call it back, and terminates its initial call. The callback router answers the initial call and makes the return call to the client based on its configuration statements. The command is ppp callback [accept — request].

Options:

Name Code Length Description





Maximum Receive Unit (MRU) 1 4 MRU is the maximum size of a PPP frame and cannot exceed 65,535. The default is 1,500 and if neither peer is changing the default, it is not negotiated.
Asynchronous Control Character Map (ACCM) 2 6 This is a bit map that enables character escapes for asynchronous links. By default, character escapes are used.
Authentication Protocol 3 5 or 6 This field indicates the authentication protocol, either PAP or CHAP.
Magic Number 5 6 This is a random number chosen to distinguish a peer and detect looped back lines.
Protocol Compression 7 2 A flag indicating that the PPP protocol ID be compressed to a single octet when the 2-byte protocol ID is in the range 0x00-00 to 0x00-FF.
Address and Control Field Compression 8 2 A flag indicating that the PPP Address field (always set to 0xFF) and the PPP Control field (always set to 0x03) be removed from the PPP header.
Callback 13 or 0x0D 3 A 1-octet indicator of how callback is to be determined.

7 PPP Authentication

The authentication phase of a PPP session is optional. If used, you can authenticate the peer after the LCP establishes the link and choose the authentication protocol. If it is used, authentication takes place before the Network layer protocol configuration phase begins.

The authentication options require that the calling side of the link enter authentication information. This helps to ensure that the user has the permission of the network administrator to make the call. Peer routers exchange authentication messages.

At the receiving node, the username-password is checked by an authentication server that either allows or denies the connection. An accept or reject message is returned to the requester.

PAP is not a strong authentication protocol. Using PAP, you send passwords across the link in clear text and there is no protection from playback or repeated trial-and-error attacks.

PAP authentication requires the remote device to send a name and password to be checked against a matching entry in the local username database or in the remote TACACS/TACACS+ database.

8 PAP Authentication Protocol

PPP defines an extensible LCP that allows negotiation of an authentication protocol for authenticating its peer before allowing Network layer protocols to transmit over the link. RFC 1334 defines two protocols for authentication, as shown in the figure.

PAP is a very basic two-way process. There is no encryption-the username and password are sent in plain text. If it is accepted, the connection is allowed.

PAP usernames and passwords are sent as clear-text strings and can be intercepted and reused.

PAP usernames and passwords are sent as clear-text strings and can be intercepted and reused.

9 CHAP Authentication Protocol

CHAP is more secure than PAP. It involves a three-way exchange of a shared secret.

Unlike PAP, which only authenticates once, CHAP conducts periodic challenges to make sure that the remote node still has a valid password value.

After the PPP link establishment phase is complete, the local router sends a challenge message to the remote node.

The remote node responds with a value calculated using a one-way hash function, which is typically Message Digest 5 (MD5) based on the password and challenge message.

The local router checks the response against its own calculation of the expected hash value. If the values match, the initiating node acknowledges the authentication. Otherwise, it immediately terminates the connection.

CHAP provides protection against playback attack by using a variable challenge value that is unique and unpredictable. Because the challenge is unique and random, the resulting hash value is also unique and random. The use of repeated challenges limits the time of exposure to any single attack. The local router or a third-party authentication server is in control of the frequency and timing of the challenges.

CHAP authentication sends a challenge to the remote device. The remote device must encrypt the challenge value with a shared secret and return the encrypted value and its name to the local router in a response message. The local router uses the name of the remote device to look up the appropriate secret in the local username or remote TACACS/TACACS+ database. It uses the looked-up secret to encrypt the original challenge and verify that the encrypted values match.

Example: Router R1 wishes to establish an authenticated PPP CHAP connection with Router R2.

Step 1. R1 initially negotiates the link connection using LCP with router R2 and the two systems agree to use CHAP authentication during the PPP LCP negotiation.

Step 2. Router R2 generates an ID and a random number and sends that plus its username as a CHAP challenge packet to R1.

Step 3. R1 will use the username of the challenger (R2) and cross reference it with its local database to find its associated password. R1 will then generate a unique MD5 hash number using the R2’s username, ID, random number and the shared secret password.

Step 4. Router R1 then sends the challenge ID, the hashed value, and its username (R1) to R2.

Step 5. R2 generates it own hash value using the ID, the shared secret password, and the random number it originally sent to R1.

Step 6. R2 compares its hash value with the hash value sent by R1. If the values are the same, R2 sends a link established response to R1.

If the authentication failed, a CHAP failure packet is built from the following components:

04 = CHAP failure message type

id = copied from the response packet

”Authentication failure” or some such text message, which is meant to be a user-readable explanation

Note that the shared secret password must be identical on R1 and R2.

References

[1]   James F. Kurose and Keith W. Ross. Computer Networking: A Top-Down Approach Featuring the Internet (2nd Edition). Addison Wesley, 2003.