RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

Source of RFC: radext (ops)

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