[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [eap] Ordered delivery of EAP messages
I agree that there is some ambiguity, but I'd rather think that the
RECOMMENDED part should be a MUST from operational perspective, not
the other way around.
Yoshihiro Ohba
On Wed, Mar 07, 2007 at 11:53:40AM -0500, Avi Lior wrote:
> 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/>
>
>
--
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/>