Re: Issues & Fixes: Ordered delivery of EAP messages

>Ordered delivery & duplicate rejection aren't the
same thing.

In general, that's true.  But if you have an ACK/NAK
protocol that only 
allows a single packet in flight other than retransmissions,
doesn't 
effective duplicate rejection imply ordered delivery?

>Suppose that the conditions you specify are met for the
EAP peer and
>authenticator, as well.  Does that solve the problem?

If EAP were to implement duplicate rejection within a short
time window, yes 
that would solve the problem.  We discussed this during the
development of 
RFC 3748, partly out of the desire to reconcile EAP with
IEEE 802.1X-2001 
which utilized a monotonically increasing Identifier field. 
During that 
discussion we found that there were EAP implementations
(such as the Solaris 
version, as I recall) that did not implement a duplicate
rejection window.  
That is how the ordering guarantee found its way into RFC
3748, so as to 
guarantee that those implementations would work.


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

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

Bernard Aboba <mailto:bernard_abobahotmail.com> allegedly
scribbled on
Wednesday, March 07, 2007 12:04 AM:

>> Ordered delivery & duplicate rejection aren't
the same thing.
> 
> In general, that's true.  But if you have an ACK/NAK
protocol that
> only allows a single packet in flight other than
retransmissions,
> doesn't effective duplicate rejection imply ordered
delivery? 

Perhaps.  Unfortunately, RADIUS does not require duplicate
detection.
This is what RFC 2865 says about duplicate detection:
"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."
That's it.  I don't see the word "MUST" (or even
"SHOULD") in that
sentence.  In fact, RFC 3748 is actually a bit stronger on
the topic
(Section 4.1): "The peer is responsible for detecting
and handling
duplicate Request messages before processing them in any
way, including
passing them on to an outside party.  The authenticator is
also
responsible for discarding Response messages with a
non-matching
Identifier value before acting on them in any way, including
passing
them on to the backend authentication server for
verification." 

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

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