RFC 5080, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", December 2007

Errata ID: 4623
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2016-02-22
Held for Document Update by: Benoit Claise
Date Held: 2016-05-18

Section 2.2.1 says:

   For Accounting-Request packets, the default values for MRC, MRD, and
   MRT SHOULD be zero.  These settings will enable a RADIUS client to
   continue sending accounting requests to a RADIUS server until the
   request is acknowledged.  If any of MRC, MRD, or MRT are non-zero,
   then the accounting information could potentially be discarded
   without being recorded.

It should say:

   For Accounting-Request packets, the default values for MRC, MRD, and
   MRT SHOULD be zero.  These settings will enable a RADIUS client to
   continue sending accounting requests to a RADIUS server until the
   request is acknowledged.  If any of MRC, MRD, or MRT are non-zero,
   then the accounting information could potentially be discarded
   without being recorded.

  This retransmission behavior can be modified for Accounting-Request 
  packets containing Acct-Status-Type of Interim-Update.  A 
  "retransmission" MAY include updated statistics, but will otherwise be
  treated as a retransmission of the original packet, with timers as 
  described above.  Such an updated packet MUST set Acct-Delay-Time 
  (if present) to zero, and Event-Timestamp (if present) to the current
  time.  These changes indicate that the statistics contained in the 
  packet are new, and were not previously sent.

  When the NAS sends periodic Accounting-Request packets containing 
  Acct-Status-Type of Interim-Update, the NAS SHOULD NOT continue to
  retransmit an old Accounting-Request packet when it is time to send a
  new one.  The old packet SHOULD be discarded, and the new one sent
  in its place.

  The alternative is for a NAS to send a new Accounting-Request
  packet while it still is trying to send an old one.  This situation
  could lead to the NAS sending multiple Accounting-Request packets
  simultaneously for the same session, leading to congestive collapse
  of the network.

Notes:

- if we're retransmitting an Accounting-Request packet, it should be acceptable
to update the statistics in it.

- i.e. there should not be a requirement that the content remain the same. The
Acct-Delay-Time attribute is changing, so why not other things, too?

- And MRT of zero for Accounting-Request packet SHOULD NOT mean that the
NAS starts a new retransmission timer every 5 minutes.

- e.g. if the server is down for 20 minutes, the NAS should have *one*
Accounting-Status packet in it's retransmit queue. Not 4.

Report New Errata