RFC 2865 says: The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time.This, to me, implies duplicate detection on the server side does not rely onorderly delivery. Keeping the history for "a short span of time" allows duplicate detection irrespective of the order the requests come in.
That advice seems sensible; if implemented, I think it would address the FRTO scenarios we have been discussing, wouldn't it? Given client backoff, it seems highly unlikely that an Access-Request would be reordered outside of a "short span of time" (e.g. say, 1 minute).
As for the responses... Assuming the RADIUS client transmitted a request twice (first one timed out), if it receives one of the responses, would itstill accept the second (duplicate) response if it arrives as well? Wouldn'tthe RADIUS client just drop the second response because there is no outstanding request to match anymore?
Yes, I think that the RADIUS client will drop a duplicate response. The problem occurs more on the RADIUS server side, where the server could potentially send an Access-Reject if it wasn't doing duplicate detection as referred to above, and as a result the EAP method got mixed up.
-- 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/>