Subject: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off

From: Nick Lowe <[email-masked]>
Date: Sun, 4 Oct 2015 18:25:08 +0100

Dear all,

Following on from the three errata that I opened against RFC 2866, I
wished to expand on what Alan wrote at
http://freeradius.org/rfc/acct_status_type_subsystem.html to,
hopefully, get the ball rolling on an RFC that revises things.

Carl Rigney helpfully clarified that the original intent of the
Acct-Session-Id and Acct-Multi-Session-Id was that they were only
intended to be unique in the context of a NAS during its uptime, not
across reboots and certainly without requirements to be globally
unique.

The two errata that I raised that pertain to these attributes should
be rejected as it would be a technical change. I did not realise this
when I filed them. Therefore, a new RFC would be required to see
change going forward.

The errata that clarifies that Accounting-On and Accounting-Off apply
on a per-NAS basis and not on a per-subsystem basis is, I believe,
valid and should be accepted.

This status quo can and should be improved.

This original intent for the session ids, thankfully, does not
prohibit improvements from being made as these are opaque tokens
generated by a NAS.

Please may I solicit your feedback on the following changes so that I
may iterate the text as appropriate?

Kind regards,

Nick Lowe

Acct-Status-Type

   Description

      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.

      Where Accounting-On or Accounting-Off is specified, a
      Called-Station-Id attribute SHOULD NOT be present.  In the case
      that one is present, the value MUST be global to the NAS.

      It MAY be used by the client to mark the start of accounting for
      a subsystem of the NAS (for example, when an 802.11 BSS becomes
      available) by specifying Subsystem-On and to mark the end of
      accounting for the NAS (for example, when an IEEE 802.11 BSS is no
      longer available) by specifying Subsystem-Off.

      Where Subsystem-On or Subsystem-Off is specified, a
      Called-Station-Id attribute MUST be present.  The subsystem is
      indicated by the value of the Called-Station-Id attribute.  It
      MUST uniquely identify the subsystem to the NAS.

      For IEEE 802.11, this attribute SHOULD be used to store the
      BSSID (upper case only), with octet values separated by a "-".
      Example: "00-10-A4-23-19-C0".
      Where the SSID is known, it SHOULD be appended to the
      BSSID, separated from the BSSID with a ":".
      Example "00-10-A4-23-19-C0:AP1".

      The Called-Station-Id SHOULD be UTF-8 encoded.

   A summary of the Acct-Status-Type attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      40 for Acct-Status-Type.

   Length

      6

   Value

      The Value field is four octets.

       1      Start
       2      Stop
       3      Interim-Update
       7      Accounting-On
       8      Accounting-Off
       9-14   Reserved for Tunnel Accounting
      15      Reserved for Failed
      ??      Subsystem-On
      ??      Subsystem-Off

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.

      It is strongly recommended that the Acct-Session-Id SHOULD contain
      UTF-8 encoded 10646 [7] characters.  It MUST exhibit global and
      temporal uniqueness.

      For example, an implementation may use a string with a UUID. Other
      encodings are possible.

   A summary of the Acct-Session-Id attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  Text ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      44 for Acct-Session-Id.

   Length

      >= 3

   String

      The String field SHOULD be a string of UTF-8 encoded 10646 [7]
      characters.

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 SHOULD
      contain UTF-8 encoded 10646 [7] characters.  It MUST exhibit
      global and temporal uniqueness.

      For example, an implementation may use a string with a UUID. Other
      encodings are possible.

   A summary of the Acct-Session-Id attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

   50 for Acct-Multi-Session-Id.
   Length

   >= 3

   String

   The String field SHOULD contain UTF-8 encoded 10646 [7] characters.

---

From: Nick Lowe <[email-masked]>
Date: Sun, 4 Oct 2015 18:43:45 +0100

Quick clarification that I missed, somehow:

Should read:

      It MAY be used by the client to mark the start of accounting for
      a subsystem of the NAS (for example, when an 802.11 BSS becomes
      available) by specifying Subsystem-On and to mark the end of
      accounting for a subsystem of the NAS (for example, when an IEEE
      802.11 BSS is no longer available) by specifying Subsystem-Off.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 5 Oct 2015 16:05:19 -0400

I've submitted an IANA request for allocation of Acct-Status-Type = Subsystem-On and Subsystem-Off.

  It's been assigned to... someone for review.  I think additional discussion here would be useful.

> On Oct 4, 2015, at 1:25 PM, Nick Lowe <[email-masked]> wrote:

  That's nice, but I think the design goals 20+ years ago shouldn't restrict what we do today.

> valid and should be accepted.

  I agree with that.

> prohibit improvements from being made as these are opaque tokens

  I agree.  I *strongly* believe that implementations should try to make these values globally and temporally unique.  There is more than sufficient CPU / memory available to even $30 routers to meet this requirement.

  Alan DeKok.

---

From: Nick Lowe <[email-masked]>
Date: Tue, 6 Oct 2015 13:25:08 +0100

Second revision. A discussion with Heikki Vatiainen (Radiator)
underlined the importance of explaining that this is fully compatible
with 802.11 wireless controllers and the need to fix/clarify RFC 3580
to explain the use of Acct-Multi-Session-Id in roaming or failover
accounting scenarios.

RFC 2865
========

Acct-Status-Type

   Description

      It MAY be used by the client to mark the start of accounting for a
      subsystem of the NAS (for example, when an IEEE 802.11 BSS becomes
      available) by specifying Subsystem-On and to mark the end of
      accounting for a subsystem of the NAS (for example, when an IEEE
      802.11 BSS is no longer available) by specifying Subsystem-Off.

      For IEEE 802.11, this attribute SHOULD be used to store the
      BSSID (upper case only), with octet values separated by a "-".
      Example: "00-10-A4-23-19-C0".
      Where the SSID is known, it SHOULD be appended to the BSSID,
      separated from the BSSID with a ":".
      Example "00-10-A4-23-19-C0:AP1".

      For IEEE 802.11 in particular, the Called-Station-Id SHOULD be
      UTF-8 encoded as the SSID may be UTF-8 encoded.

    0                   1                   2                   3

   Type

      40 for Acct-Status-Type.

   Length

      6

   Value

       1      Start
       2      Stop
       3      Interim-Update
       7      Accounting-On
       8      Accounting-Off

Acct-Session-Id

   Description

      For example, an implementation may use a string with a UUID.
      Other encodings are possible.

    0                   1                   2

   Type

      44 for Acct-Session-Id.

   Length

   String

Acct-Multi-Session-Id

   Description

      For example, an implementation may use a string with a UUID.
      Other encodings are possible.

    0                   1                   2

   Type

   String

RFC 3580
========

2.2.  Acct-Multi-Session-Id

   The purpose of this attribute is to make it possible to link together
   multiple related sessions for IEEE 802.11.  While [IEEE8021X] does
   not act on aggregated ports, it is possible for a Supplicant roaming
   between Basic Service Sets or in failover accounting from one
   Controller to another to cause multiple RADIUS accounting packets to
   be sent by the same or different Access Points or Controllers.

   Where supported by the Access Points or the Controllers, the
   Acct-Multi-Session-Id attribute can be used to link together the
   multiple related sessions of a roaming Supplicant or in failover
   accounting from one Controller to another.  In such a situation, if
   the session context is transferred between Access Points or
   Controllers, accounting packets MAY be sent without a corresponding
   authentication and authorization exchange, provided that Association
   has occurred.  However, in such a situation it is assumed that the
   Acct-Multi-Session-Id is transferred between the Access Points or the
   Controllers as part of the Inter-Access Point Protocol (IAPP) or
   another handoff scheme.

   If the Acct-Multi-Session-Id were not globally unique between Access
   Points and Controllers, then it is possible that the chosen
   Acct-Multi-Session-Id will overlap with an existing value allocated
   on that Access Point or Controller, and the Accounting Server would
   therefore be unable to distinguish a roaming or failover session
   from a multi-link session.

   In order to provide global uniqueness, it is suggested that the
   Acct-Multi-Session-Id be an UTF-8 encoded UUID that offers inherent
   global and temporal uniqueness.

   An alternative construction for the Acct-Multi-Session-Id may be of
   the form:

   BSSID | Supplicant MAC Address | NTP Timestamp

   Here "|" represents concatenation, the BSSID is the MAC address of
   the BSS under which the session started, and the 64-bit NTP timestamp
   indicates the beginning of the original session.  In order to provide
   for consistency of the Acct-Multi-Session-Id between roaming or
   failover sessions, the Acct-Multi-Session-Id may be moved between
   Access Points or Controllers as part of IAPP or another handoff
   scheme.

   The use of an Acct-Multi-Session-Id of this form should guarantee
   uniqueness among all Basic Service Sets, Access Points, Supplicants,
   Controllers and sessions.  Since the NTP timestamp does not wrap on
   reboot, there is no possibility that a rebooted Access Point or
   Controller could choose an Acct-Multi-Session-Id that could be
   confused with that of a previous session once time synchronisation
   has occurred.  The downside of this construction is that it is
   dependent on time synchronisation having occurred.  For this reason,
   a UUID is preferred.

   Since the Acct-Multi-Session-Id is of type String as defined in
   [RFC2866], for use with IEEE 802.1X, it is encoded as an UTF-8 string
   of Hex digits.  Example:  "00-10-A4-23-19-C0-00-12-B2-
   14-23-DE-AF-23-83-C0-76-B8-44-E8"

3.20.  Called-Station-Id

   For IEEE 802.1X Authenticators, this attribute is used to store the
   bridge MAC address or IEEE 802.11 BSSID (upper case only), with octet
   values separated by a "-".  Example: "00-10-A4-23-19-C0".

   For IEEE 802.11, where the SSID is known, it SHOULD be appended to
   the BSSID, separated from the BSSID with a ":".
   Example "00-10-A4-23-19-C0:AP1".

   For IEEE 802.11, the Called-Station-Id MUST be UTF-8 encoded as the
   SSID may be UTF-8 encoded.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Oct 2015 09:57:09 -0700

Comments below. 
> RFC 2865
[BA]  Not sure why you are referring to RFC 2865 here.  This is a Draft Standard RFC that covers authentication/authorization.   There is no material in this document relating to accounting.   
>       that one is present, the value MUST be global to the NAS.
[BA] What does "global to the NAS" mean?  Are you referring to a globally unique MAC Address?  
>       BSSID (upper case only), 
[BA]  This seems to contradict the text before that which seems to imply that the BSSID is encoded in ASCII.   Allowing UTF-8 encoding of the BSSID could introduce interoperability issues so that is not a good idea. 
>       UTF-8 encoded as the SSID may be UTF-8 encoded.
[BA] It would appear to me that only the SSID may be UTF-8 encoded.  So why don't we just say that?

---

From: Nick Lowe <[email-masked]>
Date: Tue, 6 Oct 2015 21:12:21 +0100

On Tue, Oct 6, 2015 at 5:57 PM, Bernard Aboba <[email-masked]> wrote:
> Comments below.
>>
>> RFC 2865
>> ========
>
> [BA]  Not sure why you are referring to RFC 2865 here.  This is a Draft
> Standard RFC that covers authentication/authorization.   There is no
> material in this document relating to accounting.

Correct. I meant to say this was in the context of RFC 2866. I typed
that autonomously and managed to miss that while proof reading. Sorry,
it was a flat out mistake.

> [BA] What does "global to the NAS" mean?  Are you referring to a globally

This is taken from Alan's wording:

http://freeradius.org/rfc/acct_status_type_subsystem.html

"with a value for Called-Station-Id that is global to the NAS"

I wanted to mandate that the value must be something that applies to
the whole NAS. It is not and cannot be a value that scopes to a
subsystem and must therefore constant to all Accounting-On and
Accounting-Off forms of Accounting-Request packets that a NAS sends.

Perhaps it would be better to state the reverse, that any value must
not scope to subsystem on the NAS. How would you word this? Omit this
entirely? Any suggestions?

I would prefer to prohibit a Called-Station-Id being present outright
for Accounting-On and Accounting-Off. I cannot see that it serves a
legitimate purpose but realise there may be too much of a
compatibility implication pushing for this.

The intent is for NASes that are currently sending Accounting-On and
Accounting-Off that are scoped to a subsystem to stop doing so.

> [BA]  This seems to contradict the text before that which seems to imply
> that the BSSID is encoded in ASCII.   Allowing UTF-8 encoding of the BSSID
> could introduce interoperability issues so that is not a good idea.

UTF-8 being a general superset of ASCII, my thoughts were that it
would be easier to treat the whole thing as being UTF-8 encoded rather
than thinking about it being ASCII encoded up and until the first : is
encountered after which point UTF-8 is used.

That was my reasoning behind writing it like that anyway.

I felt it was unneeded complexity that could easily becomes too
nuanced without giving a tangible benefit.

I'll reword this if you think there could be significant
interoperability issues.

> [BA] It would appear to me that only the SSID may be UTF-8 encoded.  So why

As above, I'll reword this if you feel there could be significant
interoperability issues.

---

From: Nick Lowe <[email-masked]>
Date: Wed, 7 Oct 2015 10:18:50 +0100

Corrections made.

Reference to RFC 2866
=====================

Acct-Status-Type

   Description

      Where Accounting-On or Accounting-Off is specified, a
      Called-Station-Id attribute SHOULD NOT be present.  In the case
      that one is present, the value MUST apply to the whole NAS.

      It is strongly recommended that the value of the Called-Station-Id
      attribute that is used for a session SHOULD match the value of the
      Called-Station-Id that identifies the subsystem.

      The value of any Called-Station-Id attributes that are used in accounting
      types that are session specific SHOULD match the value used when
Subsystem-On and
      Subsystem-Off are specified where they come under the scope of that
      subsystem.

      For IEEE 802.11, this attribute SHOULD be used to store the
      BSSID (upper case only) in ASCII format, with octet values
      separated by a "-".
      Example: "00-10-A4-23-19-C0".
      Where the SSID is known, it SHOULD be appended to the BSSID in
      UTF-8 format, separated from the BSSID with a ":".
      Example "00-10-A4-23-19-C0:AP1".

      The SSID MUST be UTF-8 encoded as the SSID may be UTF-8 encoded.

    0                   1                   2                   3

   Type

      40 for Acct-Status-Type.

   Length

      6

   Value

       1      Start
       2      Stop
       3      Interim-Update
       7      Accounting-On
       8      Accounting-Off

Acct-Session-Id

   Description

    0                   1                   2

   Type

      44 for Acct-Session-Id.

   Length

   String

Acct-Multi-Session-Id

   Description

    0                   1                   2

   Type

   String

Reference to RFC 3580
=====================

Acct-Multi-Session-Id

Called-Station-Id

   For IEEE 802.1X Authenticators, this attribute is used to store the
   bridge MAC address or IEEE 802.11 BSSID in ASCII format (upper case
   only), with octet values separated by a "-".
   Example: "00-10-A4-23-19-C0".

   For IEEE 802.11, where the SSID is known, it SHOULD be appended in
   UTF-8 format to the BSSID, separated from the BSSID with a ":".
   Example "00-10-A4-23-19-C0:AP1".

   The SSID MUST be UTF-8 encoded as the SSID may be UTF-8 encoded.

---

From: Nick Lowe <[email-masked]>
Date: Wed, 7 Oct 2015 10:38:31 +0100

Oops, this reads in a really odd way.

Change:

To:

 As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID MUST
be UTF-8 encoded.

---

From: Nick Lowe <[email-masked]>
Date: Wed, 7 Oct 2015 11:52:51 +0100

Upon further reflection, I think that the term "log file" should be
dropped and "easy to link" changed to "possible to link" for the
Acct-Session-Id and Acct-Multi-Session-Id.

If they're eventually going to be revised to offer global and temporal
uniqueness, seems worth doing.

Reference to RFC 2866
=====================

Acct-Status-Type

   Description

      As IEEE 802.11 allows that SSIDs may be UTF-8 encoded, the SSID
      MUST be UTF-8 encoded.

    0                   1                   2                   3

   Type

      40 for Acct-Status-Type.

   Length

      6

   Value

       1      Start
       2      Stop
       3      Interim-Update
       7      Accounting-On
       8      Accounting-Off

Acct-Session-Id

   Description

      This attribute is a globally unique Accounting ID to make it
      possible to match start and stop records.  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.

    0                   1                   2

   Type

      44 for Acct-Session-Id.

   Length

   String

Acct-Multi-Session-Id

   Description

      This attribute is a globally unique Accounting ID to make it
      possible to link together multiple related sessions.  Each session
      linked together would have a globally unique Acct-Session-Id but
      the same Acct-Multi-Session-Id.

    0                   1                   2

   Type

   String

Reference to RFC 3580
=====================

Acct-Multi-Session-Id

   In order to provide global uniqueness, it is suggested that the
   Acct-Multi-Session-Id be a UUID that offers inherent global and
   temporal uniqueness.

Called-Station-Id

---

From: Nick Lowe <[email-masked]>
Date: Wed, 7 Oct 2015 12:30:32 +0100

Should we state:

A session MUST only come under the scope of one subsystem.

---

From: Nick Lowe <[email-masked]>
Date: Wed, 7 Oct 2015 12:36:16 +0100

I definitely think that that needs to be stated which brings me to:

Reference to RFC 2866
=====================

Acct-Status-Type

   Description

      The value of any Called-Station-Id attributes that are used in
      accounting types that are session specific SHOULD match the value
      used when Subsystem-On and Subsystem-Off are specified where they
      come under the scope of that subsystem.

    0                   1                   2                   3

   Type

      40 for Acct-Status-Type.

   Length

      6

   Value

       1      Start
       2      Stop
       3      Interim-Update
       7      Accounting-On
       8      Accounting-Off

Acct-Session-Id

   Description

    0                   1                   2

   Type

      44 for Acct-Session-Id.

   Length

   String

Acct-Multi-Session-Id

   Description

    0                   1                   2

   Type

   String

Reference to RFC 3580
=====================

Acct-Multi-Session-Id

Called-Station-Id

---

From: Nick Lowe <[email-masked]>
Date: Wed, 7 Oct 2015 13:57:52 +0100

I strongly feel that the opportunity should be seized to specify
transition behaviour between subsystems.
Subsystem-on and Subsystem-off would be a new Acct-Status-Types so
there are no compatibility constraints.

I have added more to the description for Acct-Status-Type. Thoughts please!

Sorry about all the emails!

Reference to RFC 2866
=====================

Acct-Status-Type

   Description

      Where transition occurs for user service from one one NAS to
      another, the original session SHOULD end with a Stop and a new
      session SHOULD begin with a Start.  This is strongly recommended.
      An Acct-Multi-Session-Id SHOULD be present with the same value to
      link together related sessions.  This is strongly recommended.

      Where transition occurs for user service from one one subsystem to
      another, the original session MUST end with a Stop and a new
      session MUST begin with a Start.  An Acct-Multi-Session-Id MUST be
      present with the same value to link together related sessions.

      The Acct-Session-Id MUST be different for new sessions started
      when transition occurs.

    0                   1                   2                   3

   Type

      40 for Acct-Status-Type.

   Length

      6

   Value

       1      Start
       2      Stop
       3      Interim-Update
       7      Accounting-On
       8      Accounting-Off

Acct-Session-Id

   Description

    0                   1                   2

   Type

      44 for Acct-Session-Id.

   Length

   String

Acct-Multi-Session-Id

   Description

    0                   1                   2

   Type

   String

Reference to RFC 3580
=====================

Acct-Multi-Session-Id

Called-Station-Id

---

From: Nick Lowe <[email-masked]>
Date: Wed, 7 Oct 2015 14:34:30 +0100

Reference to RFC 2866
=====================

Acct-Status-Type

   Description

      another, the preceding session SHOULD end with a Stop and a new

      Where transition occurs for user service from one one subsystem to
      another, the preceding session MUST end with a Stop and a new
      session MUST begin with a Start.  An Acct-Multi-Session-Id MUST be
      present with the same value to link together related sessions.

    0                   1                   2                   3

   Type

      40 for Acct-Status-Type.

   Length

      6

   Value

       1      Start
       2      Stop
       3      Interim-Update
       7      Accounting-On
       8      Accounting-Off

Acct-Session-Id

   Description

    0                   1                   2

   Type

      44 for Acct-Session-Id.

   Length

   String

Acct-Multi-Session-Id

   Description

    0                   1                   2

   Type

   String

Reference to RFC 3580
=====================

Acct-Multi-Session-Id

Called-Station-Id

---

From: <[email-masked]>
Date: Wed, 7 Oct 2015 15:51:22 +0000

Hi Nick,

To make the life easier for people not involved in previous (offline) discussions and receive feedback from RADEXT members, it would be better to:
- have a separate email thread per proposed change, one for each attribute
- provide a short summary of the issue triggering the proposed change
- highlight the proposed changes (e.g. OLD/NEW)

Moreover, I have 2 short general comments:

- The proposed changes introduce the concept of " subsystem of NAS" that is not defined, nor in RFC2865/2865, nor in the proposed changes. It should be introduced somewhere. It would be then easier to understand the relationship between Called-Station-Id and NAS/subsystem as well as the proposed new values for Acct-Status-Type.

- For sake of clarity, it would be maybe easier to make the distinction between the definition of the attribute and how this attribute should be used depending on the context (with/without another attribute, etc.)

- It should be considered if everything related to session management could be captured in a separate section.

Regards,

Lionel

-----Message d'origine-----
De : radext [mailto:[email-masked]] De la part de Nick Lowe
Envoyé : mercredi 7 octobre 2015 15:35
À : [email-masked]
Objet : Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off

Reference to RFC 2866
=====================

Acct-Status-Type

   Description

    0                   1                   2                   3

   Type

      40 for Acct-Status-Type.

   Length

      6

   Value

       1      Start
       2      Stop
       3      Interim-Update
       7      Accounting-On
       8      Accounting-Off

Acct-Session-Id

   Description

    0                   1                   2

   Type

      44 for Acct-Session-Id.

   Length

   String

Acct-Multi-Session-Id

   Description

    0                   1                   2

   Type

   String

Reference to RFC 3580
=====================

Acct-Multi-Session-Id

Called-Station-Id

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 13 Oct 2015 11:40:08 -0700

I would also like to distinguish extensions to RFC 2866 (such as Accounting-On/Off) from revisions to RFC 2866. 
Assignment of new RADIUS op-codes requires Standards Action, so this cannot be done in an Informational RFC.  

Also, since RADIUS accounting is 20+ years old, revisions need to be backward compatible. 
> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Wed, 7 Oct 2015 15:51:22 +0000
> Subject: Re: [radext] Feedback solicited: Acct-Session-Id, Acct-Multi-Session-Id, Accounting-On/Off and Subsystem-On/Off
> 
> Hi Nick,
>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 13 Oct 2015 14:53:31 -0400

> I would also like to distinguish extensions to RFC 2866 (such as Accounting-On/Off) from revisions to RFC 2866. 

  Sure.

> Assignment of new RADIUS op-codes requires Standards Action, so this cannot be done in an Informational RFC.  

  That's not needed.  What has been requested (by me via IANA) are new values for Acct-Status-Type.  These require expert review, and not standards action.

  There is no suggestion to assign new packet codes or attributes.

> Also, since RADIUS accounting is 20+ years old, revisions need to be backward compatible. 

  That is of key importance.

  For Acct-Session-Id, we can make recommendations for how it's values are created... with no inter-operability issues.  All consumers of Acct-Session-Id treat it as an opaque token.  This behaviour is implied by RFC 2866.

  Recommending *better* values fort Acct-Session-Id has no impact on existing NASes, proxies, or servers.

  Alan DeKok.