Encryption For PPP Links Using MPPE

Chances are that if you have been working with Cisco technologies for a while in your career or through study that you have come across a variety of different ways to authenticate the point-to-point protocol over serial links. For instance, most of you are probably aware of PAP and CHAP to handle this. If you have been doing CCIE study, you might even be aware of EAP. PAP uses plain-text authentication while CHAP and EAP use MD5 based authentication. This is all well and good, but these methods only authenticate the link — they do not actually encrypt the data going between the two end points. In order to do encryption, there is a lesser well known protocol known as MPPE (Microsoft Point-To-Point Encryption).

MPPE is a protocol defined by RFC 3078 which provides a way to do encryption over PPP links. The protocol allows for two different types of encryption which differ on the size of the key. The two key sizes supported are 40-bit, and 128-bit and the encryption itself uses an RC4 cipher. The session keys themselves also change dynamically. Encryption of the PPP links is something that is negotiated by a lower level sub-protocol of PPP known as CCP (Compression Control Protocol) during NCP phase of PPP link negotiation.

OK, now that we have looked at the important protocol information with a 5 minute summary of the RFC let’s look at how to actually get this working in a Cisco environment! For our test bed, we will simply be looking at two routers on a standard proctorlabs rack — R2 and R5. R2 and R5 have a direct PPP link between them on interface s0/2/0.

One thing to be aware of before we look at the configuration is that in order to get MPPE working on a Cisco router you must already have configured and working authentication. Specifically, you must run MS-CHAP authentication. MS-CHAP is a microsoft-ized version of the popular CHAP authentication protocol. Let’s get started. For our example, we will simply do 1-way authentication to make things simple. R2 will be authenticating R5. We will use the hostname as the username and a password of “pants.”

R2:

username R5 password pants
!
interface Serial0/2/0
 ip address 25.25.25.2 255.255.255.0
 encapsulation ppp
 clock rate 2000000
 ppp encrypt mppe 128 required
 ppp authentication ms-chap

R5:

interface Serial0/2/0
 ip address 25.25.25.5 255.255.255.0
 encapsulation ppp
 ppp encrypt mppe 128
 ppp chap password 0 pants

Let’s take a look at some debug and show command output to verify our configuration. Notice that on R2 we have specified the required keyword. This means that R2 will require that the other side of the link use 128-bit encryption for the line to come up properly. We have configured 128-bit encryption on the remote end so we are good. Also notice that we use the usual “ppp chap password” command on R5 even though technically it is MS-CHAP. There is no “ppp ms-chap…” command.

Let’s take a look at a “debug ppp negotiation” on R5 when the interface comes up

R5(config-if)#no shut
 R5(config-if)#
*Apr  6 13:23:27.832: Se0/2/0 PPP: Outbound cdp packet dropped
*Apr  6 13:23:29.832: %LINK-3-UPDOWN: Interface Serial0/2/0, changed state to up
*Apr  6 13:23:29.832: Se0/2/0 LCP: I CONFREQ [Closed] id 252 len 15
*Apr  6 13:23:29.832: Se0/2/0 LCP:    AuthProto MS-CHAP (0x0305C22380)
*Apr  6 13:23:29.832: Se0/2/0 LCP:    MagicNumber 0x18180FB4 (0x050618180FB4)
*Apr  6 13:23:29.832: Se0/2/0 LCP LCP: Missed a Link-Up transition, starting PPP
*Apr  6 13:23:29.832: Se0/2/0 PPP: Using default call direction
*Apr  6 13:23:29.836: Se0/2/0 PPP: Treating connection as a dedicated line
*Apr  6 13:23:29.836: Se0/2/0 PPP: Session handle[C500011F] Session id[474]
*Apr  6 13:23:29.836: Se0/2/0 PPP: Phase is ESTABLISHING, Active Open
*Apr  6 13:23:29.836: Se0/2/0 LCP: O CONFREQ [Closed] id 234 len 10
*Apr  6 13:23:29.836: Se0/2/0 LCP:    MagicNumber 0x19046115 (0x050619046115)
*Apr  6 13:23:29.836: Se0/2/0 LCP: O CONFACK [REQsent] id 252 len 15
*Apr  6 13:23:29.836: Se0/2/0 LCP:    AuthProto MS-CHAP (0x0305C22380)
*Apr  6 13:23:29.836: Se0/2/0 LCP:    MagicNumber 0x18180FB4 (0x050618180FB4)
*Apr  6 13:23:29.836: Se0/2/0 LCP: I CONFACK [ACKsent] id 234 len 10
*Apr  6 13:23:29.836: Se0/2/0 LCP:    MagicNumber 0x19046115 (0x050619046115)
*Apr  6 13:23:29.836: Se0/2/0 LCP: State is Open
*Apr  6 13:23:29.836: Se0/2/0 PPP: Phase is AUTHENTICATING, by the peer
*Apr  6 13:23:29.836: Se0/2/0 MS-CHAP: I CHALLENGE id 218 len 21 from "R2      "
*Apr  6 13:23:29.852: Se0/2/0 MS CHAP: Using hostname from unknown source
*Apr  6 13:23:29.852: Se0/2/0 MS CHAP: Using password from interface CHAP
*Apr  6 13:23:29.852: Se0/2/0 MS-CHAP: O RESPONSE id 218 len 56 from "R5"
*Apr  6 13:23:29.860: Se0/2/0 MS-CHAP: I SUCCESS id 218 len 4
*Apr  6 13:23:29.860: Se0/2/0 PPP: Phase is FORWARDING, Attempting Forward
*Apr  6 13:23:29.860: Se0/2/0 PPP: Queue CCP code[1] id[1]
*Apr  6 13:23:29.860: Se0/2/0 PPP: Discarded CDPCP code[1] id[1]
*Apr  6 13:23:29.860: Se0/2/0 PPP: Queue IPCP code[1] id[1]
*Apr  6 13:23:29.864: Se0/2/0 PPP: Phase is ESTABLISHING, Finish LCP
*Apr  6 13:23:29.864: Se0/2/0 PPP: Phase is UP
*Apr  6 13:23:29.864: Se0/2/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Apr  6 13:23:29.864: Se0/2/0 IPCP:    Address 25.25.25.5 (0x030619191905)
*Apr  6 13:23:29.864: Se0/2/0 CCP: O CONFREQ [Closed] id 1 len 10
*Apr  6 13:23:29.864: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.864: Se0/2/0 CDPCP: O CONFREQ [Closed] id 1 len 4
*Apr  6 13:23:29.864: Se0/2/0 PPP: Process pending ncp packets
*Apr  6 13:23:29.864: Se0/2/0 IPCP: Redirect packet to Se0/2/0
*Apr  6 13:23:29.864: Se0/2/0 IPCP: I CONFREQ [REQsent] id 1 len 10
*Apr  6 13:23:29.864: Se0/2/0 IPCP:    Address 25.25.25.2 (0x030619191902)
*Apr  6 13:23:29.868: Se0/2/0 IPCP: O CONFACK [REQsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 IPCP:    Address 25.25.25.2 (0x030619191902)
*Apr  6 13:23:29.868: Se0/2/0 CCP: Redirect packet to Se0/2/0
*Apr  6 13:23:29.868: Se0/2/0 CCP: I CONFREQ [REQsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.868: Se0/2/0 CCP: O CONFACK [REQsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.868: Se0/2/0 CCP: I CONFACK [ACKsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 CCP:    MS-PPC supported bits 0x01000040 (0x120601000040)
*Apr  6 13:23:29.868: Se0/2/0 CCP: State is Open
*Apr  6 13:23:29.868: Se0/2/0 CDPCP: I CONFACK [REQsent] id 1 len 4
*Apr  6 13:23:29.868: Se0/2/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Apr  6 13:23:29.868: Se0/2/0 IPCP:    Address 25.25.25.5 (0x030619191905)
*Apr  6 13:23:29.868: Se0/2/0 IPCP: State is Open
*Apr  6 13:23:29.872: Se0/2/0 IPCP: Install route to 25.25.25.2
*Apr  6 13:23:30.864: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/2/0, changed state to up
*Apr  6 13:23:31.856: Se0/2/0 CDPCP: I CONFREQ [ACKrcvd] id 2 len 4
*Apr  6 13:23:31.856: Se0/2/0 CDPCP: O CONFACK [ACKrcvd] id 2 len 4
*Apr  6 13:23:31.856: Se0/2/0 CDPCP: State is Open
R5(config-if)#do no deb all

All possible debugging has been turned off

We can see from the above output exactly what we would expect — The LCP phase of PPP negotiation begins which moves us into authentication via MS-CHAP. We can see that R5 gets an inbound authentication request from R2. R5 responds appropriately with the MD5 hash and R2 lets us know the authentication was successful. After LCP and authentication we move into the NCP phase. During NCP, we can see that encryption is being negotiated via the CCP protocol. If encryption is successfully negotiated you will see that the CCP state goes to Open as it has here. So, let’s take a look at our link and test

R2#sh ip int brie | i 0/2/0
Serial0/2/0                25.25.25.2      YES manual up                    up

R2#ping 25.25.25.5 re 100
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 25.25.25.5, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (100/100), round-trip min/avg/max = 1/2/4 ms

R2#show ppp mppe serial0/2/0
Interface Serial0/2/0 (current connection)
Software encryption, 128 bit encryption, Stateless mode
packets encrypted = 100      packets decrypted  = 100
sent CCP resets   = 0        receive CCP resets = 0
next tx coherency = 100      next rx coherency  = 100
tx key changes    = 100      rx key changes     = 100
rx pkt dropped    = 0        rx out of order pkt= 0
rx missed packets = 0

We can see from the above output that we are indeed running 128-bit encryption and that all of our ping packets were encrypted! We can also see that the key seems to actually change every packet! That is about it for setting up basic MPPE on a Cisco router PPP link!!!

Joe Astorino CCIE #24347

Print Friendly

Tags: CCIE R&S, CCIE Routing & Switching, mppe