Subject: Re: granularity of PPP timers

From: Leo Huber <[email-masked]>
Date: Thu, 03 Jun 1999 10:46:20 PDT

thx, James for your quick response.

Looking for an answer I also purchased your book "PPP design and Debugging" 
and would like to thank you for this contribution,
which I admire and find so helpfull on many other issues,
but the one discussed in this email.

I embedded some questions in the text below:

>From: James Carlson <[email-masked]>
>To: [email-masked]
>Subject: Re: granularity of PPP timers
>Date: 03 Jun 1999 06:49:09 -0400
>
>[email-masked] ("Leo Huber") writes:
> > does the PPP authentication require specific
> > granularity and/or absolute (= limited variablity)
> > timer value?
>
>No.  The standard recommends timers configurable in units of seconds,
>but the authentication mechanisms do not depend on timer granularity
>or variability.  If your 3 second nominal timer varies between 3 and
>10 seconds, this will not harm negotiation.
>
>(Note that most of the timers are there only to guard against packet
>loss.  In well-designed implementations, they won't actually be
>triggered.

so the adjustement granularity of ~1 sec. (+/- 0.5 sec.)
is sufficient?

My goal is a "well-designed" implementation, therefore the
consideration for the timer value and the granularity of timer ajustment.

>The two exceptions off the top of my head are the CHAP
>rechallenge and the LQM intervals -- and the exact timing of those is
>relatively unimportant, as long as they neither happen too quickly nor too 
>slowly.)

yes. I was looking for numbers to express the feelings like
"too quickly" or "too slowly". Could not find such numbers
in your PPP book or rfc 1994 (CHAP).

in the rfc 1994 I read:

"2.1.  Advantages

   The use of repeated challenges is intended to limit
   the time of exposure to any single attack.  The authenticator is in
   control of the frequency and timing of the challenges."

does this imply time limits on the authenticatee and how to make sure
these time limits are met?

I appreciate your help.

Leo

>
>--
>James Carlson, Software Architect                   <[email-masked]>
>IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
>Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
>"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp
>

_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com

---

From: James Carlson <[email-masked]>
Date: Thu, 3 Jun 1999 16:57:33 -0400 (EDT)

> so the adjustement granularity of ~1 sec. (+/- 0.5 sec.)

Certainly.  Many well-known versions simply hard-code the timers at
the RFC defaults and allow no adjustment at all.  Others make
adjustment only by modifying obscure (and dangerous) binary databases.
If you allow timer adjustment within 1 second, you're doing well.

(Do make sure that you use a variable back-off algorithm.  This makes
a *much* bigger difference in whether or not your implementation will
be robust.)

> in your PPP book or rfc 1994 (CHAP).

They depend on where and how your implementation is used.  Usually,
this feature is disabled by default and has to be configured by an
administrator in order to enable it.

> these time limits are met?

If I understand your question, no, it does not imply that.  It means
only that the authenticator may -- at its option and discretion --
rechallenge its peer at any interval it feels is necessary to be sure
that the peer hasn't been replaced with another.

In truth, this can be problematic.  If the peer is in use by a human
(rather than just being a stand-alone networking box), then
rechallenge probably means annoying the user with a pop-up window to
reenter the password, or it means that the PPP implementation caches a
copy of the cleartext password (!).  Either way, it's not good to do
this very often, especially where there is another, reasonably secure
means to know that the same peer is still on the line (such as modem
carrier detect).

On the other hand, some links (such as dedicated synchronous lines)
don't have positive indication when the link is severed, and thus
rechallenge is necessary to prevent an attacker from simply splicing
some equipment into the path.