[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: RADIUS Response and Retransmissions
"Bernard Aboba" <email@example.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
> 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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.