[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: RADIUS Response and Retransmissions
I'm not sure what is meant by a "retransmission" if the
Access-Request packet contents change. Which attributes determine a
"session"?
I'm not sure, either, but RFC 2865 section 2.5 mentions "retransmitting" and
changing the ID in the same paragraph:
If the NAS is retransmitting a RADIUS request to the same server as
before, and the attributes haven't changed, you MUST use the same
Request Authenticator, ID, and source port. If any attributes have
changed, you MUST use a new Request Authenticator and ID.
In the absence of a clear and consistent definition for "session",
the RADIUS server MAY treat a "retransmit with new ID" as a different
session. It MAY return Access-Accept for one request, and
Access-Reject for another. This can happen when multiple simultaneous
login restrictions are enforced, among other scenarios.
So the problem appears to be larger than just the NAS behavior.
Right. It is probably worth adding a caveat about the effects of changing
the Request ID.
Again, in the absence of a clear and consistent definition for
"session", the presumed behavior of a NAS when it "retransmits with a
new ID" is that the old session is being discarded, and a new session
is being initiated. In that case, the response of the server (if any)
is irrelevant, as the NAS has decided to stop supporting that session.
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.
My question is that if the NAS is supposed to validate the
response... what does it do then with that response? How does it's
behavior cange over silently dropping the response? How does it
handle the case where one "session" returns Access-Accept, and the
other Access-Reject? Which session wins, and why?
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.
If we are talking about retransmission as discussed in Section 2.5, I don't
think RFC 2865 defines what happens when the Response to one transmission
has a different result than the Response to a retransmission.
Silently discarding the old session would seem to me to be the
safest thing to do.
If the ID has changed, that might be reasonable, but if it hasn't, then I
don't see why it shouldn't be processed.
--
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/>