background image
PPP Options 109
The authentication succeeds only if the hash value received from
the calling party (from Step 2) matches the calculated hash value
(from Step 4).
Step 5
Constructing the result--If the values of the hash calculations
match, the authentication is successful and a CHAP success
packet is constructed. It contains a CHAP success message type
and the id from the response packet.
If the authentication fails, a CHAP failure packet is constructed. It
contains a CHAP failure message type and the ID from the
response packet.
Indication of success or failure is then sent to the calling party.
PPP Callback
The PPP Callback option was developed to provide connectivity to remote users while
controlling access and the cost of calls. Callback enables a router to place a call, and then
request that the central router call back. Once the request is made, the call disconnects. The
central router then dials the router back, which reverses the charges for the call. This callback
feature adds another layer of protection because it only dials back authorized numbers.
However, callback is not considered to be a security feature.
PPP Callback routers can play two roles, that of the callback client and that of the callback
server. The client router passes authentication (PAP or CHAP) information to the server router,
which in turn analyzes dial string and hostname information to determine whether callback is
authorized.
If authentication is successful, the server disconnects the call and then places the return call.
The username of the client router is used as a call reference to associate it with the initial call.
For the callback to be successful, the hostname must exist in a dialer-map statement; otherwise,
the router is unable to determine the proper dial string to use in calling back the client. If the
return call fails, there are no retries. The client has to reissue the callback request.
For callback to function, both sides of a PPP link must be configured to support it. As mentioned,
a server and a client must be specified. The client issues the initial call and the server places
return calls. There is a catch, however. If a call is placed requesting callback, the server
disconnects the call after authentication. It is possible that another call will come in on the same
B channel during the idle time between disconnect and callback. If it is the last available B
channel, callback will not occur. It is also possible that on DDR implementations, interesting
traffic can force an outbound call on the last available B channel. Again, if this happens,
callback does not occur. Example 5-3 shows a PPP Callback configuration for the client.