RFC 5080, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", December 2007Source of RFC: radext (ops)
Errata ID: 4623
Status: Held for Document Update
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.
- 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.