Information Technology Reference
In-Depth Information
When negotiation begins, each of the peers that want to establish a PPP connection must send a configure
request (seen in
debug ppp negotiation
and referred to hereafter as CONFREQ). Included in the
CONFREQ are any options that are not the link default; these often include Maximum Receive Unit,
Async Control Character Map, Authentication Protocol, and the Magic Number. Also seen often are the
options that deal with multilink PPP.
There are three possible responses to any CONFREQ:
•
A configure-acknowledge (CONFACK) must be issued if the peer recognizes the options and agrees
to the values seen in the CONFREQ.
•
A configure-reject (CONFREJ) must be sent if any of the options in the CONFREQ are not
recognized (for instance, some vendor-specific options), or if the values for any of the options have
been explicitly disallowed in the configuration of the peer.
•
A configure-negative-acknowledge (CONFNAK) must be sent if all the options in the CONFREQ
are recognized, but any of the values are not acceptable to the peer.
The two peers will continue to exchange CONFREQs, CONFREJs, and CONFNAKs until each sends a
CONFACK, until the dial connection is broken, or until one or both of the peers deems the negotiation
to be not completable.
Authentication
With LCP negotiation successfully completed, and an AUTHTYPE agreed upon, the next step is
authentication. Authentication, while not mandatory per RFC 1661, is
highly
recommended on all dial
connections; in some instances, it is a requirement for proper operation, with dialer profiles being a case
in point.
The two principal types of authentication in PPP are the Password Authentication Protocol (PAP) and
the Challenge Handshake Authentication Protocol (CHAP), defined by RFC 1334 and updated by RFC
1994. PAP is the simpler of the two, but it is less secure because the plain-text password is sent across
the dial connection. CHAP, on the other hand, is more secure because the plain-text password is not ever
sent across the dial connection.
This leads to a good question: Why should PAP ever be used? Two reasons frequently seen by Cisco TAC
engineers are these:
•
The existence of large installed bases of client applications that do not support CHAP
•
Incompatibilities between different vendor implementations of CHAP
When discussing authentication, it is helpful to use the terms
requester
and
authenticator
to distinguish
the roles played by the devices at either end of the connection, although either peer can act in either role.
Requester
describes the device that requests network access and supplies authentication information; the
authenticator
verifies the validity of the authentication information and either allows or disallows the
connection. It is common for both peers to act in both roles when a DDR connection is being made
between routers.
PAP
PAP is fairly simple. After successful completion of the LCP negotiation, the requester repeatedly sends
its username/password combination across the link until the authenticator responds with an
acknowledgment or until the link is broken. The authenticator may disconnect the link if it determines
that the username/password combination is not valid.
