Subject: RE: (radius) IDs

From: Paul Raison <[email-masked]>
Date: Thu, 25 Feb 1999 15:10:18 -0500

A corresponding question is how does the client "know" when it is
safe to re-use an identifier (please see inline comment below).

> -----Original Message-----
> From:	Alan DeKok [SMTP:[email-masked]]
> Sent:	Thursday, February 25, 1999 2:23 PM
> To:	[email-masked]
> Subject:	Re: (radius) Retransmission hints 
> 
> Carl Rigney <[email-masked]> wrote:
> >
> > IDs are really (server, source port, ID) 3-tuples,
> 
>   Let me start another firestorm by saying I almost disagree.
> 
>   Say you've got a server which uniquely identifies requests based on
> the client, source port, ID, and request code.  The clients use the
> same source port for all messages (as do most clients I've seen).
> 
>   The server keeps track of the requests for a period of time, X, in
> order to detect duplicate requests from the NAS.  After that time, the
> server deletes the remembered requests/replies from it's cache.
> 
>   When the server is under heavy load from a client: 200+ requests per
> second, where X is ~5s.  This server will then:
> 
> New devices are emerging that are terminating multiple T3 or OC12
> (and more) ports which brings the likelihood of 200+ current requests
> into reality
> 
> - send 256 replies to 256 client requests.
> 
> - ignore "duplicate" requests with the same client, source port, ID,
>   and request code.  (Or send "duplicate" replies, the effect is the
> same)
> 
> In the case of sending "duplicate" replies, does the Server
> (inadvertently)
> authenticate a new set of users without going to the database?
> 
> - after the timeout period X has passed, it will start replying to
>   requests again. 
> 
> 
>   The net effect is that authentication becomes "bursty".  Lots of
> people get authenticated, then more people wait a long time, then more
> people get authenticated again.
> 
>   The only solution I could think of was to use the Request
> Authenticator as part of the unique request identifier.  My reasoning
> goes like this:
> 
>   IF the client is sending another request with the same code, ID, and
> source port, it MUST either be a duplicate request, or a new request.
> 
>   IF it's a duplicate request, then the Request Authenticator MUST be
> the same.
> 
>   IF it's a new request, then the Request Authenticator MUST be
> different.
> 
>   IF it's a new request, then the client must have received the old
> reply, and the server can throw away its saved copy of the old
> request.
> 
> 
>   With these modifications, a server can do 256 requests per second,
> with *all* requests having ID=0.  This gets rids of the "bursty"
> problem, and flattens the response time.
> 
> > Note that if you use different ID tracks for different servers, then
> the
> > server MUST use the address you sent to when replying to you.  Do we
> want
> > to make that explicit?
> 
>   Yes.
> 
> > Do we want to require that IDs be tracked globally on a NAS, and not
> > per server?  At the moment we don't say one way or the other, but
> > this is a subtle enough point that I'd like to provide guidance in
> > the updated draft.
> 
>   ID's SHOULD be tracked per server.
> 
>   If ID's are tracked globally, we run into the "pseudo duplicate"
> problem above even more quickly.
> 
>   Alan DeKok.
> -
> To unsubscribe, email [email-masked]' with
> 'unsubscribe ietf-radius' in the body of the message.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Carl Rigney <[email-masked]>
Date: Thu, 25 Feb 1999 12:33:14 -0800 (PST)

> (inadvertently) authenticate a new set of users without going to the database?

That can't happen, because the Response Authenticator in the reply is
based on Request Authenticator, so if the response gets mixed up, it'll
be rejected as invalid, and the request will be retransmitted.

RADIUS servers that want to serve really huge NASes (100,000 ports) or
with very bursty traffic would be wise to check the request
authenticator when weeding out duplicates.

Someday I'd like to see a good informational RFC discussing RADIUS
timers in depth; for the moment such things are left to the
inventiveness of implementers.

--
Carl Rigney
[email-masked]

"I think the essense of reliable protocol design is getting the timers
right.  If you do, the protocol will probably work & scale (though
there may be lots of things you'll have to tweak to get good
performance).  If you botch the timers, the protocol is guaranteed to
fall apart at some scale (but, unfortunately, people are very bad about
anticipating the effects of scale & a lot of these bench-top grad
student projects end up escaping & causing no end of suffering for
their users before they die)." -- Van Jacobson, 96/7/18 talking about 
something else entirely

-

---

From: Jeff Weisberg <[email-masked]>
Date: Thu, 25 Feb 1999 17:17:50 -0500 (EST)

| Someday I'd like to see a good informational RFC discussing RADIUS
| timers in depth; for the moment such things are left to the
| inventiveness of implementers.

RFC 1536 (Common DNS Implementation Errors and Suggested Fixes),
section 1 (Fast Retransmissions) is a good start. 
many of the same issues apply.

	--jeff

-