PPP

PPP is a standards based protocol that offers authentication at L2. This is one of the main reasons why you’d use PPP to begin with. The other main reason is dynamic IP addressing. It was originally designed for dial-up connections.

As it is point to point there is no need for Layer 3 to Layer 2 resolution like ARP in Ethernet, because the data is only going to one destination. You have no Layer 2 address with PPP.

PPP Frame Format

A quick look at the frame format for PPP.

The Flag is used to signal this is the beginning of a PPP frame (like preamble with Ethernet).

The Address is set to 0xFF (11111111) statically.

The Control field is also static.

The Protocol field indicates whether the frame is a data or control protocol frame (type of payload) for negotiation.

The PPP header gives a total of 8 bytes of overhead!

Negotiation of a Connection

PPP uses two steps to negotiate a connection. LCP (Link Control Protocol) for the link and NCP (Network Control Protocol) for the upper layer protocols running over the link. Optionally negotiate authentication before NCP.

• LCP
  • Callback
  • Multilink (for fragmentation)
    • MRRU (Maximum Received Reconstructed Unit) in debug
      • This value is the total size of the original packet. Letting the other end know that if you receive a packet of say 2,100 bytes, do not even attempt to fragments it, because I will not be able to reconstruct it.
  • Authentication (whether or not to do authentication)
  • Magic Number (Looped Link Detection)
  • Compression
• Authentication (optionally)
• NCP
  • IPCP
    • Static one IP address (not available for PPPoE!)
    • Pool
    • DHCP
    • DHCP-Pool
  • IPXCP
  • CDPCP

In order for PPP to finish LCP, both ends must agree on the way the intend to run PPP on the link. This means both send out a CONFREQ and both must send a CONFACK agreeing to the requested parameters. Of course if one end does not support a feature or offers an alternative, the CONFREJ and CONFNAK messages. Have a look at the messages of Negotiation Packets

You can watch the negotiation using debug ppp negotiation

If you see MRU negotiated, someone has changed the MTU on an interface, letting the other end know the Maximum Received Unit value.

PPP Authentication

Usually the server requests authentication wanting to validate the client. Authentication can be two way, though.

• PAP
  • Clear text username and password
  • Two-way handshake
• CHAP
  • Three-way handshake
• MS-CHAP
• MS-CHAPv2
• EAP

PPP PAP Authentication Configuration

Client:

int serial0/0

encapsulation ppp

ppp pap sent-username R1 password Cisco

Server:

username R1 password Cisco

!

int serial0/0

encapsulation ppp

ppp authentication pap

The ppp authentication pap command means “I want to authenticate you (using pap), before we can talk”.

With PAP the username is case in-sensitive, but the password is case sensitive.

You can debug just authentication with ppp using debug ppp authentication

Failed Authentication will be seen as AUTH-NAK in the debug.

PPP CHAP Authentication Configuration

Client:

int serial0/0

encapsulation ppp

ppp chap hostname R1

ppp chap password Cisco

Server:

username R1 password Cisco

!

int serial0/0

encapsulation ppp

ppp authentication chap

This will work if the Client always uses Serial0/0 to speak with the server. If the Client wishes to speak with other servers, this will not work unless the other servers are configured for the same username and password.

The username (hostname), challenge, and the password is run through a hashing algorithm. The output of this hashing is sent across the wire by the client and verified by the server. The server generated the random challenge and send it to the client for input into the algorithm.

If you want to use different credentials depending to which server you are authenticating, you must the this configuration:

Client:

hostname R1

!

username server1 password Cisco1

username server2 password Cisco2

!

int serial0/0

encapsulation ppp

Server:

hostname server1

!

username R1 password Cisco

!

int serial0/0

encapsulation ppp

ppp authentication chap

Note the username/hostname must be the same, because the router will use its hostname for username.

Capture of the server sending a configuration request for CHAP authentication

The request is acknowledged by the client whereafter the server sends a Challenge:

Here we see the Challenge Value the server sends to the client. The client then computes its own hash and sends it to the server that replies with a Success message if authentication is successful as we see in this case.

PPP Authentication Verification

sh int serial0/0 – look for OPEN: IPCP

sh users

PPPoE

PPPoE uses a 4 step message exchange like with DHCP to establish a connection.

Before LCP starts the client must discover the server. This is a broadcast message. A unique Session-ID is created between the server (ISP) and client for the server to uniquely identify the client. The process is called Active Discovery. It starts with a PADI (PPPoE Active Discovery Initiation) broadcast to find a PPPoE server. The server replies (unicast) with a PADO (PPPoE Active Discovery Offer) containing Access Concentrator (AC) ID of the server along with the MAC address. Next the client sends a unicast PADR (PPPoE Active Discovery Request) message asking for the Session-ID. The server sends a unicast replay called PADS (PPPoE Active Discovery Session-Confirmation) containing the unique Session-ID. To sum up:

• PADI (Initiation) – client broadcast
• PADO (Offer) – server unicast
• PADR (Request) – client unicast
• PADS (Session-Confirm) – server unicast

The EtherType for this session setup is 0x8863 (PPPoE Discovery). After Active Discovery, LCP kicks in and now the EtherType is 0x8864 (PPPoE Session).

When the session is terminated, a PADT (PPPoE Active Discovery Termination) is sent to the server.

• PADT (Termination) – client unicast

The PPPoE header is placed between the L2 ethernet header and the PPP header.

I will use the following topology to go over various PPPoE configs and messages:

PADI

Let’s have a look at PPPoE PADI.

This is the first message sent by the PPPoE client to initiate a PPPoE session. It is broadcasted at L2 and the  Type in the L2 header is PPPoE Discovery (0x8863) as expected.

PADO

The PADO is sent in response to the PADI. Let’s see how this message looks like in wireshark:

Still in the PPPoE Discovery phase and the Offer contains the AC-name of R1 (the server) and an AC-Cookie which is useful against some DoS attacks.

PADR

The client sends a PADR requesting a session based on the Offer (PADS) the server sent.

It contains the same Host-Uniq, AC-Name, and AC-Cookie the PADS contained.

PADS

Finally the server sends the PADS as a confirmation that the session has now been established.

Now the PPP negotiation can begin – over PPPoE over Ethernet.

PPPoE Configuration

The Active Discovery information can be configured under the bba-group on the server. Here you can also configure session limitations. These tweaks are optional.

It is said that if you use a static IP address for the virtual-template interface on the server, you’ll only be able to have a total of 6 concurrent sessions. Use ip unnumbered instead.

PPPoE Verification

show pppoe session – PTA (PPP Termination Aggregation) state – locally terminated on this box.

show pppoe summary

(on the server) show interface virtual-access 1.1 – look for PPPOE and OPEN and Vaccess state

(on the client) show interface dialer1 – to find the virtual-access interface

(on the client) show interface virtual-access1 – LCP Open

MTU issues on the PPPoE Client, because the Dialer interface has an MTU of 1500 not taking into account the 8 bytes PPP header. So be careful with OSPF running on PPPoE links.

I the real world you’d want to adjust the tcp mss on the interface facing clients making the TCP SYN sent by the clients change the MSS to 8 bytes less (1452).