RE: Issues & Fixes: Ordered delivery of EAP messages

["Alper Yegin" <alper.yegin@yegin.org>]

> >> ...  If no response is
> >> available, the duplicate Access-Request MUST be silently discarded.
> >
> > And in that case, protocol stalls... If the RADIUS server sent response
> to
> > the request, but the RADIUS client hasn't received it, the client will
> > retransmit the request but according to this text the server will keep
> > dropping the retransmitted requests.
> 
>   Your statement assumes that the server sent a response, but did not
> cache it.  So for that reason (and others), the text about caching will
> be MUST, rather than SHOULD.
> 
>   i.e. SHOULD cache means that it might not, leading to the problem you
> noted above.
> 
> > RADIUS server MUST respond to duplicate requests.
> 
>   Not in all cases.  See the following logic flow for why:
> 
> 1. RADIUS server receives & caches Access-Request
> 2. RADIUS server responds with, and caches Access-Accept (etc.)
> 3. RADIUS server receives duplicate Access-Request
> 4. RADIUS server sends duplicate Access-Accept (etc.)
> 
>   But there's a race condition:
> 
> 1a. RADIUS server receives duplicate Access-Request
> 
>   And the server hasn't yet responded with an Access-Accept.  In that
> case, the ONLY thing the server can do is to silently discard the
> duplicate.  It can't reply, because a reply doesn't exist.  It can't
> process it, because it's already being processed.  (And processing it
> again would negate the effectiveness of the duplicate detection.)
> 
>   How about changing the text to say:
> 
>  .. If a response is not yet available for any reason, the duplicate
> Access-Request MUST be silently discarded.
> 
>   Would that address your concerns?

Or, we can adapt from RFC 3748 text:

      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.

And if necessary, we can also describe the other case:

	The peer MUST silently discard any duplicate requests for which a
	response has not been sent yet.


Alper


> 
>   Alan DeKok.



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