Information Technology Reference
In-Depth Information
CHAP
CHAP is somewhat more complicated. The authenticator sends a
challenge
to the requester, which then
responds with a value. This value is calculated by using a “one-way hash” function to hash the challenge
and the CHAP password together. The resulting value is sent to the authenticator along with the
requester's CHAP host name (which may be different from its actual host name) in a
response
message.
The authenticator reads the host name in the response message, looks up the expected password for that
host name, and then calculates the value that it ought to expect the requester to have sent in its
response
by performing the same hash function that the requester performed. If the resulting values match, the
authentication is successful. Failure should lead to a disconnect.
AAA
As part of authentication, use may be made of an authentication, authorization, and accounting (AAA,
or triple-A) service such as TACACS+ or RADIUS. AAA is not a replacement for PAP or CHAP, but it
is a mechanism for accomplishing them.
Network Control Protocol
Assuming successful authentication, the NCP phase begins. As in LCP, the peers exchange CONFREQs,
CONFREJs, CONFNAKs, and CONFACKs, although in this phase of negotiation, the elements being
negotiated have to do with higher-layer protocols—IP, IPX, bridging, CDP, and so on. One or more of
these protocols may be negotiated. Because it is the most commonly used, and because other protocols
operate in much the same fashion, Internet Protocol Control Protocol (IPCP), defined in RFC 1332, will
be the focus of this discussion. Other pertinent RFCs include (but are not limited to) the following:
•
RFC 1552 (IPX Control Protocol)
•
RFC 1378 (AppleTalk Control Protocol)
•
RFC 1638 (Bridging Control Protocol)
1
•
RFC 1762 (“DECnet Control Protocol”)
•
RFC 1763 (“VINES Control Protocol”)
In addition, Cisco Discovery Protocol Control Protocol (CDPCP) may be negotiated during NCP,
although this is not common—many Cisco TAC engineers advise that the command
no cdp enable
be
configured on any and all dialer interfaces to prevent CDP packets from keeping a call up indefinitely.
The key element negotiated in IPCP is each peer's address. Each of the peers is in one of two possible
states: either it has an IP address, or it does not.
2
If the peer already has an address, it will send that
address in a CONFREQ to the other peer. If the address is acceptable to the other peer, a CONFACK will
be returned. If the address is not acceptable, the reply will be a CONFNAK containing an address for
the peer to use.
If the peer has no address, it will send a CONFREQ with the address 0.0.0.0—this tells the other peer to
assign an address, which is accomplished by sending a CONFNAK with the proper address.
Other options may be negotiated in IPCP. Commonly seen are the primary and secondary addresses for
Domain Name Server and NetBIOS Name Server, as described in informational RFC 1877. Also
commonly seen is the IP Compression Protocol (RFC 1332).
1. Note that Cisco IOS does not support Bridging on asynchronous interfaces.
2. Interfaces configured using
ip unnumbered [interface name]
are considered to have an IP address. They use the IP address of
the interface named in the configuration command.
