eap Mailing List: Re: Ordered delivery of EAP messages

[Bernard Aboba (bernard_aboba]

> 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 
> on
> orderly 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 it
> still accept the second (duplicate) response if it arrives as well? 
> Wouldn't
> the 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.