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, ﬁber-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 eﬀective Challenge Handshake Authentication Protocol (CHAP).
|Code (in hex)||Protocol|
|8021||Internet Protocolo Control Protocol|
|8023||OSI Network Layer Control Protocol|
|8029||Appletalk Control Protocol|
|802b||Novell IPX Control Protocol|
|c021||Link Control Protocol|
|c023||Password Authentication Protocol|
|c223||Challenge Handshake Authentication Protocol|
|LCP Code||LCP Packet Type||Description|
|1||Conﬁgure-Request||Sent to open or reset a PPP connection. Conﬁgure-Request contains a list of LCP options with changes to default option values.|
|2||Conﬁgure-Ack||Sent when all of the values of all of the LCP options in the last Conﬁgure-Request received are recognized and acceptable. When both PPP peers send and receive Conﬁgure-Acks, the LCP negotiation is complete.|
|3||Conﬁgure-Nack||Sent when all the LCP options are recognized, but the values of some options are not acceptable. Conﬁgure-Nak includes the oﬀending options and their acceptable values.|
|4||Conﬁgure-Reject||Sent when LCP options are not recognized or not acceptable for negotiation. Conﬁgure-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 oﬀending LCP packet.|
|8||Protocol-Reject||Sent when the PPP frame contains an unknown Protocol ID. The Protocol-Reject message includes the oﬀending 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.|
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 speciﬁc 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 conﬁgured 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.
PPP may include the following LCP options:
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.
Increases the eﬀective 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.
Identiﬁes fault conditions. The Quality and Magic Number options help ensure a reliable, loop-free data link. The Magic Number ﬁeld helps in detecting links that are in a looped-back condition. Until the Magic-Number Conﬁguration Option has been successfully negotiated, the Magic-Number must be transmitted as zero. Magic numbers are generated randomly at each end of the connection.
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 traﬃc across multiple physical WAN links while providing packet fragmentation and reassembly, proper sequencing, multivendor interoperability, and load balancing on inbound and outbound traﬃc. Multilink is not covered in this course.
To enhance security, Cisco IOS Release 11.1 and later oﬀers 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 conﬁguration statements. The command is ppp callback [accept — request].
|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 ﬁeld 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 ﬂag 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 ﬂag indicating that the PPP Address ﬁeld (always set to 0xFF) and the PPP Control ﬁeld (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.|
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 conﬁguration 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.
PPP deﬁnes 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 deﬁnes two protocols for authentication, as shown in the ﬁgure.
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.
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 ﬁnd 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.