Issue 60: RADIUS Accounting

[Bernard Aboba <aboba@internaut.com>]

Issue 60: RADIUS Accounting
Submitter name: David Nelson
Submitter email address: dnelson@enterasys.com
Date first submitted: January 31, 2005
Reference: http://ops.ietf.org/lists/radiusext/2005/msg00013.html
Document: Issues and Fixes
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

RFC 2866 has the following text (or similar):

"...can only be present in Accounting-Request records where
the Acct-Status-Type is set to Stop."

contained in the description of the following RADIUS Accounting
Attributes:

5.3.  Acct-Input-Octets
5.4.  Acct-Output-Octets
5.7.  Acct-Session-Time
5.8.  Acct-Input-Packets
5.9.  Acct-Output-Packets
5.10. Acct-Terminate-Cause

With the exception of Acct-Terminate-Cause, do folks in think that RFC
2866 intended to prohibit these attributes from also appearing in
Accounting-Request messages where the Acct-Status-Type is set to
Interim-Update?

My research shows that the text in question first appears in RFC 2059.
RFC 2059 is obsoleted by RFC 2139, which in turn is obsoleted by RFC
2866.  The Interim-Update value of Acct-Status-Type is *not* included in
RFC 2059, just Start and Stop.  One possible scenario is that when the
Interim-Update type was added, no one bothered to notice the sections of
text that indicate this "Stop only" text and updated them to read "Stop
or Interim-Update".

Since the purpose of the Interim-Update is to provide a snap-shot of the
accounting statistics at that moment in time, I see no reason why the
octet counts and session time attributes ought not to be included.  Is
this potentially an erratum in RFC 2866? Or was there a good reason to
omit these accounting statistics from the Interim-Update messages?

[Barney Wolff]

I believe you are correct, and this was simply an oversight.

[Glen Zorn]

I tend to agree, but I think that the oversight (and error) was
actually in RFC 2869, which defines the semantics of the
Interim-Update Acct-Status-Type.  I think that the problem could
have been avoided but just including "Updates: RFC 2866" in the
header...

[Avi Lior]

Actually 2869 says the following:

"It is envisioned that an Interim Accounting record (with Acct-
Status-Type = Interim-Update (3)) would contain all of the attributes
normally found in an Accounting Stop message with the exception of
the Acct-Term-Cause attribute."

[Glen Zorn]

I'm quite aware of that; what's missing is the reverse pointer to
2866 that would allow people to discover (without the use of ESP :-)
that they need to read 2869 to understand interim accounting.

[David Nelson]

So it seems clear that this is the intent.

As Glen Zorn points out, RFC 2869 does not indicate that it updates RFC
2866, and RFC 2866 *does* include the code-id for Interim-Update (3),
but did not pick up any of the other related text from RFC 2869.  RFC
2869 also says:

  "This memo suggests several additional Attributes that can be added to
   RADIUS to perform various useful functions.  These Attributes do not
   have extensive field experience yet and should therefore be
   considered experimental."

While the RFC status is Informational, it indicates that the Attribute
status is Experimental?  Odd.

Perhaps we should consider adding a clarification in our RADIUS Issues
and Fixes document, once we actually start work on that charter item.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>