Re: Issues & Fixes: Ordered delivery of EAP messages

[Alan DeKok <aland@nitros9.org>]

Alper Yegin wrote:
>> ...  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?

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