RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (3)

RFC 2866, "RADIUS Accounting", June 2000

Note: This RFC has been updated by RFC 2867, RFC 5080, RFC 5997

Source of RFC: radius (ops)

Errata ID: 4485
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Nick Lowe
Date Reported: 2015-09-27
Verifier Name: Benoit Claise
Date Verified: 2015-10-05

Section 5.1 says:

This attribute indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop).

It MAY be used by the client to mark the start of accounting (for
example, upon booting) by specifying Accounting-On and to mark the
end of accounting (for example, just before a scheduled reboot) by
specifying Accounting-Off.

It should say:

This attribute indicates whether this Accounting-Request marks the
beginning of the user service (Start) or the end (Stop).

It MAY be used by the client to mark the start of accounting for the
NAS (for example, upon booting) by specifying Accounting-On
and to mark the end of accounting for the NAS (for example, just
before a scheduled reboot) by specifying Accounting-Off.

Notes:

Some RADIUS client implementations send scoped Accounting-On and Accounting-Off Accounting-Request packets. This is seen, for example, with some wireless APs that include a Called-Station-Id attribute to scope to a Basic Service Set (BSS).

This is an incorrect interpretation of the RFC that is not backwards compatible with consumers of RADIUS accounting information, yet the RFC is ambiguous on this point.

The RFC must be clear that Accounting-On and Accounting-Off apply to the whole NAS and cannot be scoped in this manner.

New Acct-Status-Type values must instead be defined to allow this, perhaps named something like Scoped-Accounting-On and Scoped-Accounting-Off.

Errata ID: 2713
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Wang Haojian
Date Reported: 2011-02-12
Verifier Name: Dan Romascanu
Date Verified: 2011-02-13

Section 5 says:

      [7] characters and String contains 8-bit binary data.  Servers and
      servers and clients MUST be able to deal with embedded nulls.
      ^^^^^^^^^^

It should say:

      [7] characters and String contains 8-bit binary data.  Servers and
      clients MUST be able to deal with embedded nulls.

Notes:

Same as RFC 2865 , extraneous "servers and" can be deleted. ;)

Errata ID: 3896
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Andrew Kowal
Date Reported: 2014-02-18
Verifier Name: Benoit Claise
Date Verified: 2014-02-18

Section 3 says:

This memo documents the RADIUS Accounting protocol.  The early
deployment of RADIUS Accounting was done using UDP port number 1646,
which conflicts with the "sa-msg-port" service.  The officially
assigned port number for RADIUS Accounting is 1813.

Notes:

The whole 3rd paragraph of section 3 is a duplicate of "Implementation Note" section and is barely related to packet format description.

Status: Held for Document Update (1)

RFC 2866, "RADIUS Accounting", June 2000

Note: This RFC has been updated by RFC 2867, RFC 5080, RFC 5997

Source of RFC: radius (ops)

Errata ID: 5417
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Nick Lowe
Date Reported: 2018-07-06
Held for Document Update by: Ignas Bagdonas
Date Held: 2019-10-28

Section 5.11 says:

      This attribute is a unique Accounting ID to make it easy to link
      together multiple related sessions in a log file.  Each session
      linked together would have a unique Acct-Session-Id but the same
      Acct-Multi-Session-Id.  It is strongly recommended that the Acct-
      Multi-Session-Id contain UTF-8 encoded 10646 [7] characters.

It should say:

      This attribute is a unique Accounting ID to make it easy to link
      together multiple related sessions in a log file.  Each session
      linked together would have a unique Acct-Session-Id but the same
      Acct-Multi-Session-Id.  The start and stop records for a given
      session MUST have the same Acct-Multi-Session-Id.  An
      Access-Request packet MAY contain Acct-Multi-Session-Id; if it
      does, then the NAS MUST use the same Acct-Multi-Session-Id in
      the Accounting-Request packets for that session.  It is strongly
      recommended that the Acct-Multi-Session-Id contain UTF-8 encoded
      10646 [7] characters.

Notes:

RFC2866 does not make clear that an Access-Request packet MAY contain Acct-Multi-Session-Id in section 5.11 as it does for the Acct-Session-Id in section 5.5 or that consistency is expected between the start and stop records.

Status: Rejected (2)

RFC 2866, "RADIUS Accounting", June 2000

Note: This RFC has been updated by RFC 2867, RFC 5080, RFC 5997

Source of RFC: radius (ops)

Errata ID: 4487
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Nick Lowe
Date Reported: 2015-09-29
Rejected by: Benoit Claise
Date Rejected: 2015-10-05

Section 5.5 says:

Acct-Session-Id

   Description

      This attribute is a unique Accounting ID to make it easy to match
      start and stop records in a log file.  The start and stop records
      for a given session MUST have the same Acct-Session-Id.  An
      Accounting-Request packet MUST have an Acct-Session-Id.  An
      Access-Request packet MAY have an Acct-Session-Id; if it does,
      then the NAS MUST use the same Acct-Session-Id in the Accounting-
      Request packets for that session.

      The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7]
      characters.

It should say:

Acct-Session-Id

   Description

      This attribute is a globally unique Accounting ID to make it easy
      to match start and stop records in a log file.  The start and stop
      records for a given session MUST have the same Acct-Session-Id.
      An Accounting-Request packet MUST have an Acct-Session-Id.
      An Access-Request packet MAY have an Acct-Session-Id; if it does,
      then the NAS MUST use the same Acct-Session-Id in the Accounting-
      Request packets for that session.

      The Acct-Session-Id SHOULD contain UTF-8 encoded 10646 [7]
      characters.

Notes:

A very common implementation fault in RADIUS clients that perform accounting is that Acct-Session-Ids are observed to be reused after a NAS is rebooted or are only unique only in the scope/context of a NAS.

The RFC does not explicitly state the scope of uniqueness and it must be clarified to state that Acct-Session-Ids are expected to be globally unique. I believe this to be the original, implicit intent of the author.

This is necessary because the ambiguity causes substantial implementation issues today.

See: http://freeradius.org/radiusd/man/rlm_acct_unique.txt

An ideal Acct-Session-Id would have the properties of a GUID/UUID.
--VERIFIER NOTES--
As summarized by Nick:


It looks like the Acct-Session-Id and Acct-Multi-Session-Id errata
both will and should be rejected on the grounds that they would
constitute technical changes based on the original intent of the RFC,
which we now know. That does make sense and would be a reasonable
course of action now that that's known.

I am pleased that I have engendered a discussion on what I believe to
be a pertinent issue here. Alan has commented that he feels another
RADIUS fixes RFC would be sensible. I agree with that course of
action.

Thanks for all your time here!

Regards,

Nick

Errata ID: 4488
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Nick Lowe
Date Reported: 2015-09-29
Rejected by: Benoit Claise
Date Rejected: 2015-10-05

Section 5.11 says:

Acct-Multi-Session-Id

   Description

      This attribute is a unique Accounting ID to make it easy to link
      together multiple related sessions in a log file.  Each session
      linked together would have a unique Acct-Session-Id but the same
      Acct-Multi-Session-Id.  It is strongly recommended that the Acct-
      Multi-Session-Id contain UTF-8 encoded 10646 [7] characters.

It should say:

Acct-Multi-Session-Id

   Description

      This attribute is a globally unique Accounting ID to make it easy
      to link together multiple related sessions in a log file.  Each
      session linked together would have a globally unique
      Acct-Session-Id but the same Acct-Multi-Session-Id.  It is
      strongly recommended that the Acct-Multi-Session-Id contain
      UTF-8 encoded 10646 [7] characters.

Notes:

The RFC does not explicitly state the scope of uniqueness and it must be clarified to state that Acct-Multi-Session-Ids are expected to be globally unique. I believe this to be the original, implicit intent of the author.

An ideal Acct-Multi-Session-Id would have the properties of a GUID/UUID.

See Errata 4487 for the same clarification on the Acct-Session-Id.
--VERIFIER NOTES--
As summarized with Nick:


It looks like the Acct-Session-Id and Acct-Multi-Session-Id errata
both will and should be rejected on the grounds that they would
constitute technical changes based on the original intent of the RFC,
which we now know. That does make sense and would be a reasonable
course of action now that that's known.

I am pleased that I have engendered a discussion on what I believe to
be a pertinent issue here. Alan has commented that he feels another
RADIUS fixes RFC would be sensible. I agree with that course of
action.

Thanks for all your time here!

Regards,

Nick

Report New Errata



Advanced Search