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

[Nick Lowe <[e-mail]>]

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

      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 apply to the whole NAS.

      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.

      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.

      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.

      A session MUST only come under the scope of one 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".

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

      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.

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

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

      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.


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

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

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

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