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

[Bernard Aboba <[e-mail]>]

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: [e-mail]
> To: [e-mail]; [e-mail]
> 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,
> 
> 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:[e-mail]] De la part de Nick Lowe
> Envoyé : mercredi 7 octobre 2015 15:35
> À : [e-mail]
> 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
> 
>       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 preceding 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 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.
> 
>       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.
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> 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.
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext