PPPoE provides a standard method of employing the authentication methods of the Point-to-Point Protocol (PPP) over an Ethernet network. When used by ISPs, PPPoE allows authenticated assignment of IP addresses. In this type of implementation, the PPPoE client and server are interconnected by Layer 2 bridging protocols running over a DSL or other broadband connection.
PPPoE is composed of two main phases:
+ Active Discovery Phase: In this phase, the PPPoE client locates a PPPoE server, called an access concentrator. During this phase, a Session ID is assigned and the PPPoE layer is established.
+ PPP Session Phase: In this phase, PPP options are negotiated and authentication is performed. Once the link setup is completed, PPPoE functions as a Layer 2 encapsulation method, allowing data to be transferred over the PPP link within PPPoE headers.
PPP Session Phase: In this phase, PPP options are negotiated and authentication is performed. Once the link setup is completed, PPPoE functions as a Layer 2 encapsulation method, allowing data to be transferred over the PPP link within PPPoE headers.
The “dialer persistent” command (under interface configuration mode) allows a dial-on-demand routing (DDR) dialer profile connection to be brought up without being triggered by interesting traffic. When configured, the dialer persistent command starts a timer when the dialer interface starts up and starts the connection when the timer expires. If interesting traffic arrives before the timer expires, the connection is still brought up and set as persistent. An example of configuring is shown below:
ip address 220.127.116.11 255.255.255.0
Password Authentication Protocol (PAP) is a very basic two-way process. The username and password are sent in plain text, there is no encryption or protection. If it is accepted, the connection is allowed. The configuration below shows how to configure PAP on two routers:
|R1(config)#username R2 password digitaltut1
R1(config-if)#ppp authentication PAP
R1(config-if)#ppp pap sent-username R1 password digitaltut2
|R2(config)#username R1 password digitaltut2
R2(config-if)#ppp authentication PAP
R2(config-if)#ppp pap sent-username R2 password digitaltut1
Note: The PAP “sent-username” and password that each router sends must match those specified with the “username … password …” command on the other router.
The “vpdn enable” command is used to enable virtual private dialup networking (VPDN) on the router and inform the router to look for tunnel definitions in a local database and on a remote authorization server (home gateway). The following steps include: configure the VPDN group; configure the virtual-template; create the IP pools.
There are three authentication methods that can be used to authenticate a PPPoE connection:
+ CHAP – Challenge Handshake Authentication Protocol
+ MS-CHAP – Microsoft Challenge Handshake Authentication Protocol Version 1 & 2
+ PAP – Password Authentication Protocol
In which MS-CHAP & CHAP are two encrypted authentication protocol while PAP is unencrypted authentication protocol.
Note: PAP authentication involves a two-way handshake where the username and password are sent across the link in clear text; hence, PAP authentication does not provide any protection against playback and line sniffing.
With CHAP, the server (authenticator) sends a challenge to the remote access client. The client uses a hash algorithm (also known as a hash function) to compute a Message Digest-5 (MD5) hash result based on the challenge and a hash result computed from the user’s password. The client sends the MD5 hash result to the server. The server, which also has access to the hash result of the user’s password, performs the same calculation using the hash algorithm and compares the result to the one sent by the client. If the results match, the credentials of the remote access client are considered authentic. A hash algorithm provides one-way encryption, which means that calculating the hash result for a data block is easy, but determining the original data block from the hash result is mathematically infeasible.
Challenge Handshake Authentication Protocol (CHAP) periodically verifies the identity of the client by using a three-way handshake. The three-way handshake steps are as follows:
1. When a client contacts a server that uses CHAP, the server (called the authenticator) responds by sending the client a simple text message (sometimes called the challenge text). This text is not important and it does not matter if anyone can intercepts it.
2. The client then takes this information and encrypts it using its password which was shared by both the client and server. The encrypted text is then returned to the server.
3. The server has the same password and uses it as a key to encrypt the information it previously sent to the client. It compares its results with the encrypted results sent by the client. If they are the same, the client is assumed to be authentic.
Note: PPP supports two authentication protocols: PAP and CHAP.
A PPPoE session is initiated by the PPPoE client. If the session has a timeout or is disconnected, the PPPoE client will immediately attempt to reestablish the session. The following four steps describe the exchange of packets that occurs when a PPPoE client initiates a PPPoE session:
1. The client broadcasts a PPPoE Active Discovery Initiation (PADI) packet.
2. When the access concentrator receives a PADI that it can serve, it replies by sending a PPPoE Active Discovery Offer (PADO) packet to the client.
3. Because the PADI was broadcast, the host may receive more than one PADO packet. The host looks through the PADO packets it receives and chooses one. The choice can be based on the access concentrator name or on the services offered. The host then sends a single PPPoE Active Discovery Request (PADR) packet to the access concentrator that it has chosen.
4. The access concentrator responds to the PADR by sending a PPPoE Active Discovery Session-confirmation (PADS) packet. At this point a virtual access interface is created that will then negotiate PPP, and the PPPoE session will run on this virtual access.
If a client does not receive a PADO for a preceding PADI, the client sends out a PADI at predetermined intervals. That interval is doubled for every successive PADI that does not evoke a response, until the interval reaches a configured maximum.
If PPP negotiation fails or the PPP line protocol is brought down for any reason, the PPPoE session and the virtual access will be brought down. When the PPPoE session is brought down, the client waits for a predetermined number of seconds before trying again to establish a PPPoE.