PPP 2.4.4 doesn't retransmit Response messages. Most (all?)
implementations don't do that, because it's common for the authenticator
to move from Authentication phase to Network phase after sending the
CHAP Success message, and thus end up ignoring any subsequent CHAP
Response messages.
Just as RFC 1994 specifies that you can take an LCP Terminate-Request to
mean the same thing as CHAP Failure, you can take any NCP
Configure-Request message from the peer to mean CHAP Success.
(I'm pretty sure there's a book that covers these sorts of detailed
design issues ...)
In general, PPP is intentionally asymmetric, and the burden for
retransmit is on the sender of a request-type message. The design of
CHAP is, in my opinion, a little odd in that context. If I were doing
it, I would have had a CHAP Success-Ack message, if guaranteeing
delivery was important. (Or perhaps have CHAP Result and Result-Ack
messages, to combine Success/Failure.) Doing that would put the burden
of retransmission back where it belongs -- the peer sending
Success/Failure would have to resend if the message was lost.
--
James Carlson 42.703N 71.076W <
carl...@workingcode.com>