Subject: [radext] [Errata Held for Document Update] RFC5080 (4623)

From: RFC Errata System <[email-masked]>
Date: Wed, 18 May 2016 00:49:25 -0700 (PDT)

The following errata report has been held for document update 
for RFC5080, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5080&eid=4623

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Alan DeKok <[email-masked]>
Date Reported: 2016-02-22
Held by: Benoit Claise (IESG)

Section: 2.2.1

Original Text
-------------
   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.

Corrected Text
--------------
   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.

--------------------------------------
RFC5080 (draft-ietf-radext-fixes-08)
--------------------------------------
Title               : Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes
Publication Date    : December 2007
Author(s)           : D. Nelson, A. DeKok
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG