[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues & Fixes: Ordered delivery of EAP messages



We therefore state that new implementations of RADIUS servers MUST
implement duplicate detection for Access-Request packets, as described
in Section 3 of [RFC2865].  New implementations MUST 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.  In
either case, the server MUST NOT process the duplicate Access-Request
again, as though it was an independent new request.

  The time span for duplicate detection SHOULD be no less than 5
seconds, and no more than 30 seconds.

Picking up on Avi's point, in the first paragraph, are these really all MUSTs? Also does this apply only to new implementations? I'd suggest the following:

We therefore recommend that RADIUS servers SHOULD
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.  In
either case, the server MUST NOT process the duplicate Access-Request
again, as though it was an independent new request.



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