Re: 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

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_abobahotmail.com] 
Sent: Tuesday, March 06, 2007 11:55 PM
To: alper.yeginyegin.org
Cc: radiusextops.ietf.org; eapfrascone.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 or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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

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_abobahotmail.com] 
> Sent: Tuesday, March 06, 2007 11:55 PM
> To: alper.yeginyegin.org
> Cc: radiusextops.ietf.org; eapfrascone.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-requestops.ietf.org with
> the word 'unsubscribe' in a single line as the message
text body.
> archive: <http://psg.com/li
sts/radiusext/>
> 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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