Re: Issue: RADIUS Response and Retransmissions

["Alan DeKok" <aland@nitros9.org>]

"Bernard Aboba" <bernard_aboba@hotmail.com> wrote:
> Right.  It is probably worth adding a caveat about the effects of changing 
> the Request ID.

  I'll try to write up some text for inclusion in the issues & fixes
document.

> RFC 2865 doesn't give an indication that change of ID relates to aborting 
> the session.  For example, we could be talking about re-authentication or a 
> situation where an Event-Timestamp attribute is being included (such as is 
> recommended in RFC 3576).  That would lead to a change on ID with each 
> retransmission.  Yet the session is still in progress.

  I quite agree.  But how does the NAS know that the server will agree
it's the same session?  It can guess, but...

> What we are seeing is that the RADIUS client RTO is less than the time it 
> takes for the RADIUS server to respond.  The ID isn't necessarily changing, 
> but the RADIUS client is dropping the Response.  If the RTO is not backed 
> off, this can continue for quite a while without success, even though an 
> Access-Accept is being continually returned.

  That's an independent problem, I think, caused by two issues:

  1) RTO is fixed and unchanging (and probably much less than 30s)
  2) old request packets are discarded

  The side-effect of (1) means that the NAS isn't doing exponential
backoff, which is a well-known solution to delay/congestion in networks.

  The side effect of (2) means that the NAS has no idea of knowing
what the RTO *should* be.

  RADIUS clients typically use fixed time intervals for RTO & total
packet time.  The "Issues & Fixes" document already talks about
congestive back-off.  Maybe it's worth adding a section about RTO's in
general.  If poor retransmission methods cause problems in
non-congested situations, that's reason to have a separate section.

  I'll see if I can write up some text this week.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>