eap Mailing List: Re: Ordered delivery of EAP messages

[Bernard Aboba (bernard_aboba]

>  While all non-toy RADIUS implementations I'm aware of already do
> duplicate detection, this has nothing whatsoever to do with EAP.  There
> are EAP-only servers, and those servers MUST ALSO perform duplicate
> detection, or an approach with similar results.  This mandate needs to
> be part of the EAP specification.

Duplicate detection is part of the EAP specification.  From RFC 3748, 
Section 4.1:

     If a peer receives a valid duplicate Request for which it has
     already sent a Response, it MUST resend its original Response
     without reprocessing the Request....

     The Identifier field of the Response MUST match that of the
     currently outstanding Request.  An authenticator receiving a
     Response whose Identifier value does not match that of the
     currently outstanding Request MUST silently discard the Response...

  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.  Since
  the authenticator can retransmit before receiving a Response from the
  peer, the authenticator can receive multiple Responses, each with a
  matching Identifier.  Until a new Request is received by the
  authenticator, the Identifier value is not updated, so that the
  authenticator forwards Responses to the backend authentication
  server, one at a time.

However, it was not specified that a duplicate detection window greater than 
1 needs to be implemented, because PPP-based implementations of EAP assumed 
ordered delivery and therefore did not need a window larger than that.  That 
was the origin of the ordered delivery requirement --it was inserted at the 
request of authors of existing EAP implementations who did not want RFC 3748 
to make their implementations non-compliant.