Subject: [radext] [Technical Errata Reported] RFC5080 (4623)

From: RFC Errata System <[email-masked]>
Date: Mon, 22 Feb 2016 13:13:20 -0800 (PST)

The following errata report has been submitted 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

--------------------------------------
Type: Technical
Reported by: Alan DeKok <[email-masked]>

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" which includes an updated Acct-Delay-Time MAY also
   include updated statistics, but otherwise be treated as a
   retransmission of the original packet, with timers as described
   above.  Also, when the NAS sends periodic Accounting-Request
   packets, as when requested via Acct-Interim-Interval ([RFC 2869]
   Section 5.16), or configured via administrative timers, 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.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

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

---

From: Nick Lowe <[email-masked]>
Date: Mon, 22 Feb 2016 22:57:00 +0000

>    be discarded, and the new one sent in its place.

I am not convinced that the Acct-Delay-Time attribute value in a
'retransmitted' Interim-Update Accounting-Request packet should be
anything other than 0 where dynamic attribute values have
refreshed/overwritten with current information rather than the
original contents. It is ripe information at that point.

I do think it's reasonable, and a good idea, to not resend the
original contents for the dynamic attribute values for a
retransmission.

---

From: Nick Lowe <[email-masked]>
Date: Mon, 22 Feb 2016 22:59:31 +0000

The same would apply to the Event-Timestamp attribute, it should
contain the current time where this is done not the original time, in
my opinion.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Feb 2016 18:16:56 -0500

I agree with both of Nick's comments.

> On Feb 22, 2016, at 5:59 PM, Nick Lowe <[email-masked]> wrote:
>

---

From: Peter Deacon <[email-masked]>
Date: Mon, 22 Feb 2016 15:33:37 -0800 (Pacific Standard Time)

> original contents. It is ripe information at that point.

The point of Acct-Delay-Time is to provide a signal of queue delay so that 
time of event is more accurately reflected in accounting stream.

>From 5.2 of RFC2866:

"     This attribute indicates how many seconds the client has been
       trying to send this record for, and can be subtracted from the
       time of arrival on the server to find the approximate time of the
       event generating this Accounting-Request.  (Network transit time
       is ignored.)"

The reason you can't update content of accounting when Acct-Delay-Time is 
updated is because content did not actually happen at the time implied 
suggested by incremented delay time.  Effectively this enables transmission 
of bad data.

For example if you advance both Acct-Delay-Time by 30 seconds and an 
accounting counter by 1000 to account for current condition at time of 
transmission the effective result of this signal:  1000 appears to have 
incremented 30 seconds earlier than it actually occurred.

If you want to retransmit old and just update Acct-Delay-Time thats fine.

If you want to replace old interim record with a new one and associated 
reset Acct-Delay-Time thats fine too.

Incrementing both Acct-Delay-Time and content should not be allowed 
because it will provide an illusion that events have occurred earlier than 
they actually have.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Feb 2016 18:41:39 -0500

On Feb 22, 2016, at 6:33 PM, Peter Deacon <[email-masked]> wrote:
> If you want to replace old interim record with a new one and associated reset Acct-Delay-Time thats fine too.
> 
> Incrementing both Acct-Delay-Time and content should not be allowed because it will provide an illusion that events have occurred earlier than they actually have.

  Yes.

  Alan DeKok.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 22 Feb 2016 21:03:59 -0800

> original contents for the dynamic attribute values for a

So, you would therefore flag these as hold for document  update?

---

From: Nick Lowe <[email-masked]>
Date: Tue, 23 Feb 2016 10:48:31 +0000

Personally, I do not feel that it would be appropriate to hold this
for a document update as this is an ambiguous area of RADIUS
accounting due to deficiencies in the RFCs that causes real
implementation issues. These pertain to accuracy, reliability and
scalability. It does not change anything in a backwards incompatible
way, rather further asserts has previously been implicit best
practice.

I do, however, think that it is necessary to iterate the amended text
to the RFC given in the errata to something that is more encompassing,
along the lines of:

then the accounting information could potentially be discarded without
being recorded.

Both the Acct-Delay-Time and Event-Timestamp attributes SHOULD be
present in all Accounting-Request packets.  At least one MUST be
present.  The value of the Acct-Delay-Time attribute MUST be
calculated from a monotonic timer rather than a system clock to ensure
that it is accurate and not subject to shifts in the clock, which
typically occurs as clock synchronization completes via NTP.  The
Event-Timestamp attribute contains UNIX time, the number of seconds
that have elapsed since January 1, 1970 00:00:00 UTC.  Where the value
of this is known to be inaccurate by being impossibly close to the
UNIX time epoch, this MUST NOT be included.  The Event-Timestamp
attribute SHOULD take priority over the Acct-Delay-Time where both are
present at a receiver as it is not subject to network transmission
delays.

The retransmission behavior of Accounting-Request packets containing
an Acct-Status-Type of Interim-Update SHOULD be special cased.  A
retransmission, that would otherwise have included an accrued
Acct-Delay-Time value, SHOULD instead include refreshed values for its
attributes with dynamic content with an Acct-Delay-Time value of 0.
It will otherwise be treated as a retransmission of the original
packet with timers as described above.  For the avoidance of doubt,
where refreshed values are supplied and an Event-Timestamp attribute
is present, this MUST contain the current timestamp and not that of
the original transmission.

Where a RADIUS server receives multiple Accounting-Request packets
with identical timestamps, supplied or calculated, careful
consideration MUST be given to the order of precedence.  For the
common Acct-Status-Types, the following order or precedence is
correct: Accounting-On, Start, Interim-Update, Stop, Accounting-Off.

When a NAS sends periodic Accounting-Request packets, as when
requested via Acct-Interim-Interval ([RFC 2869] Section 5.16) or
configured via administrative timers, the NAS SHOULD NOT continue to
retransmit an old Accounting-Request packet when it becomes 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 still attempting to send one or more that are preceding.  This
situation could lead to the NAS sending multiple Accounting-Request
packets simultaneously for the same session, which could lead to
congestive collapse of the network.

---

From: Nick Lowe <[email-masked]>
Date: Tue, 23 Feb 2016 10:52:18 +0000

Further clarification:

The retransmission behavior of Accounting-Request packets containing
an Acct-Status-Type of Interim-Update SHOULD be special cased.  A
retransmission, that would otherwise have included an accrued
Acct-Delay-Time value, SHOULD instead include refreshed values for its
attributes with dynamic content with an Acct-Delay-Time value of 0.
It will still in all other respects be treated as a retransmission of
the original packet with timers as described above.  For the avoidance
of doubt, where refreshed values are supplied and an Event-Timestamp
attribute is present, this MUST contain the current timestamp and not
that of the original transmission.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 23 Feb 2016 08:28:22 -0500

Yes.

  There are no current plans in RADEXT to update 5080, but it's worth keeping track of things which need updating.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 23 Feb 2016 08:32:08 -0500

On Feb 23, 2016, at 5:52 AM, Nick Lowe <[email-masked]> wrote:
> ...
> present in all Accounting-Request packets.

  That's good, but this paragraph doesn't really belong in that section of RFC 5080, and it doesn't flow with the rest of the text.

  I'd suggest filing another errata for that paragraph. 

> that of the original transmission.

  That's good.

> correct: Accounting-On, Start, Interim-Update, Stop, Accounting-Off.

  That paragraph doesn't really belong in the section which deals with retransmission behaviour.  I agree with the sentiment, but I'd suggest filing another errata for this topic.

> while still attempting to send one or more that are preceding.

  This text is unclear.

>  This