RE: Issues & Fixes: Ordered delivery of EAP messages

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

> 
> We therefore recommend that RADIUS servers SHOULD

Why not MUST? Why leave the door open for some implementations to go without
dup detection, and have more of these discussions in the future?

> implement duplicate detection for Access-Request packets, as described
> in Section 3 of [RFC2865].  Implementations SHOULD also cache the
> responses to those Access-Request packets.  If a duplicate
> Access-Request packet is detected, the server MUST respond with a
> previously sent response packet (Access-Accept, Access-Challenge, or
> Access-Reject), if that packet is available.  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.

RADIUS server MUST respond to duplicate requests. 

> In
> either case, the server MUST NOT process the duplicate Access-Request
> again, as though it was an independent new request.

Yes, that's needed. This simply suggests caching the responses. Keep that
MUST NOT and recommend caching as a way to achieve this requirement.

Alper



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


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