RE: [eap] Ordered delivery of EAP messages

["Avi Lior" <avi@bridgewatersystems.com>]

I think this is an interesting discussion on RADIUS but we seem to have
diverted from the original question posed.

RFC 3748, section 3.1 says:

[6] Ordering guarantees.  EAP does not require the Identifier to be 
       monotonically increasing, and so is reliant on lower layer 
       ordering guarantees for correct operation. 

Lower layer transports for EAP MUST preserve ordering between a 
       source and destination at a given priority level (the ordering 
       guarantee provided by [IEEE-802]). 

I don't think that the "MUST" above is true! 

A little further down it says:

"It is RECOMMENDED that EAP only be run over lower layers that provide 
ordering guarantees; "

Isn't that a requirement contradiction of the previous statement, or am
I missing something?



-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
Sent: Tuesday, March 06, 2007 11:55 PM
To: alper.yegin@yegin.org
Cc: radiusext@ops.ietf.org; eap@frascone.com
Subject: Re: [eap] Ordered delivery of EAP messages

>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.


_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

--
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/>