]> Cisco Systems

10 New Square Park Feltham TW14 8HA UK mgrayson@cisco.com

CableLabs

858 Coal Creek Cr. Louisville 80027 US j.redmore@cablelabs.com

general RADEXT Working Group Internet-Draft Connect-Info RADIUS This document describes a syntax for the Connect-Info attribute used with the RADIUS protocol, enabling RADIUS clients to provide RADIUS servers information pertaining to a user's connection with an IEEE 802.11 wireless network.

Introduction The Connect-Info attribute is defined in to enable a Network Access Server (NAS) to indicate to a RADIUS server "the nature of the user's connection". includes the recommendation that:

• The connection speed SHOULD be included at the beginning of the first Connect-Info attribute in the packet. If the transmit and receive connection speeds differ, they MAY both be included in the first attribute with the transmit speed first (the speed the NAS modem transmits at), a slash (/), the receive speed, then optionally other information.

The Connect-Info attribute can be sent in both Access-Request and Accounting-Request messages, as shown in .

Many NAS implementations have implemented the Connect-Info attribute. Wi-Fi vendors supporting the Connect-Info attribute start the text field with "CONNECT" that is followed by a floating point value representing the maximum connection speed in Mbps. Implementations follow this with text information about the IEEE 802.11 amendment supported, as illustrated in .

Other implementations have extended this baseline to signal additional information to the RADIUS server using a slash (/) delimiter, as illustrated in .

There are use-cases that benefit from being able to share Wi-Fi network connection metrics between a NAS and a RADIUS server, including where the NAS is operated by a Wi-Fi Access Network Provider (ANP) and the server is operated by an third-party Identity Provider (IDP), responsible for authenticating Wi-Fi credentials and authorizing access onto the ANP's Wi-Fi network. Reception of the Connect-Info attribute defined in this document is intended to be used to assist the IDP in making authorization decisions. The rest of this document describes a syntax for the Connect-Info attribute that is simultaneously able to support existing Wi-Fi vendor implementations as illustrated in and , while being enhanced with additional optional information to support new use-cases and requirements. The technique by which a RADIUS server uses the information encoded in the Connect-Info attribute to assist in making authorization decisions is not defined in this document. Some servers may define the use a threshold for one or more parameters received in a RADIUS Access-Request, other systems may use historical Connect-Info records from previously authenticated sessions, including those in the RADIUS Accounting-Request messages received from the same NAS, still other systems may decide to algorithmically combine the parameters into a new metric used when making authorization decisions. The examples in and together with the recommendation in are representations of complex data types, as described in . Whereas discourages the use of complex data types where viable alternatives are available, it is argued that the present document does not introduce a new complex data type, rather defines and extends the syntax widely used in existing implementations of the Connect-Info attribute that currently encode information using a complex data type.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology Access Network Provider (ANP):

• A Wi-Fi operator that has configured its Wi-Fi equipment to support inbound roaming of users.

Identity Provider (IDP):

• An entity that authenticates end-user Wi-Fi devices onto ANP networks.

Received Signal Strength Indicator (RSSI):

• A measurement of the power level that is received by an antenna from a wireless device.

Types of Connect-Info Metrics The characteristics associated with the IEEE 802.11 connection that can be shared between NAS and RADIUS server include those that can be used to derive a quality metric of the performance of a Wi-Fi network. These are: transmit and receive bit rates, received signal strength indicator (RSSI), frame loss rate, frame retry rate, and the Wi-Fi global operating class associated with the connection, as defined in . While not uniquely associated with a single IEEE 802.11 connection, describes legacy implementations which include generic parameters concerning the configuration of the Wi-Fi network signaled in the Connect-Info attribute. These legacy parameters are: the maximum Wi-Fi transmit rate, the Wi-Fi amendment , and the Wi-Fi channel number.

ABNF syntax for Connect-Info The Augmented Backus-Naur form (ABNF) is a syntax for specifications defined in . The ABNF syntax for the text of the Connect-Info attribute used with Wi-Fi networks is shown below. This syntax encompasses current vendor implementations, including parameter ordering, while supporting optional enhancements to support sharing of new parameters.

Encoding Recommendations Example encodings using the ABNF definition are illustrated in and . These illustrate that the metrics can be signaled while keeping the attribute size below 253 bytes. If a RADIUS session is associated with a station operating using Multi-Link Operation (MLO), the Connect-Info attribute MAY include multiple instances of the Global-OC key-value attribute, corresponding to each operational link.

Access-Request The inclusion of the above defined parameters in a Connect-Info attribute signaled in a RADIUS Access-Request message is restricted by the number of IEEE 802.11 frames over which the calculation are based. In such cases, the transmit bit rates, receive bit rates and RSSI level MAY correspond to the instantaneous value of the specific parameter. When signaling an instantaneous value, the "AGGR" definition SHOULD NOT be included in the reported Connect-Info attribute.

Accounting-Request The inclusion of the Connect-Info attribute signaled in a RADIUS Accounting-Request with Acct-Status-Type set to Start, may be restricted by the number of IEEE 802.11 frames over which the calculation are based. In such cases, the transmit bit rates, receive bit rates and RSSI level MAY correspond to the instantaneous value of the specific parameter in which case the reporting with the "AGGR" definition SHOULD follow the rules introduced in . In other cases, i.e., where the Connect-Info attribute is signaled in RADIUS Accounting-Request messages with Acct-Status-Type set to Interim-Update or Stop, the NAS SHOULD use multiple measurements when calculating the reported value: the reported transmit and receive bit rates SHOULD represent the maximum values experienced since the last time the connect-info was signaled, i.e. the "ALGO" term SHOULD be set to "MAX". the received signal strength indicator (RSSI) SHOULD represent the average RSSI value, where the average value calculated MAY be either a linear average or an exponential weighted average, i.e. the "ALGO" term SHOULD be set to "AVG". frame loss rate and frame retry rate SHOULD represent the accumulated ratio, i.e. the "ALGO" term SHOULD be set to "ACC".

Security Considerations This document describes a syntax that enables a RADIUS client to provide a RADIUS server with information pertaining to the operation of an IEEE 802.11 wireless network, including connection metrics such as RSSI. Implementations SHOULD ensure that Connect-Info attributes are transmitted only over secure channels (e.g., using RADIUS secured with TLS), to protect against unauthorized interception. Operators SHOULD have interconnection agreements or policies in place governing the use, storage, and disclosure of connection metrics such as RSSI, consistent with the privacy considerations discussed in .

Privacy Considerations This section discusses the privacy implications of the Connect-Info attribute using the terminology of . While the Connect-Info attribute is intended to convey non-personal, network-operational information, some metrics - particularly RSSI - are indirectly identifying: they can reveal information about the physical location or movement of an end user relative to the access point. When correlated with other data, such as known access point locations, RSSI values may enable inference of a user's presence or proximity within a specific area. This constitutes a privacy risk in the sense of identifiability and correlation discussed in ', even though no directly identifying information (e.g., MAC address, username) is itself carried in the attribute. The primary mitigations available to limit this risk are: Data minimization: implementations SHOULD transmit only the connection metrics needed for the intended operational purpose, and SHOULD avoid retaining RSSI values for longer than necessary. Unlinkability: operators SHOULD avoid associating RSSI and similar metrics with persistent user identifiers, to reduce the risk of correlating a user's location or movement across sessions. This document does not define a mechanism for end users to be informed of or consent to the collection of these metrics; such notice and consent, where required, are matters of operator policy and applicable law, and are out of scope for this document.

IANA Considerations This document has no IANA Actions.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866. This memo provides information for the Internet community. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). This memo documents an Internet Best Current Practice.

Changelog 00 - Adopted as RADEXT Working Group document (was draft-grayson-connectinfo-10). Split security section into security and privacy sections. 01 - Addressed issues #1-#3: clarified reporting when operating with multiple links (value is the aggregate across links), added optional link-id to Global-OC ANBF as well as examples, fixed modulation rate range to 1-12 in ABNF, clarified description of guard interval values, updated RATE ABNF to allow > 9999 Mbps, and updated WINDOW ABNF to allow > 999 seconds

Acknowledgements The authors would like to thank all the members of the WBA's Access Network Metrics project team, as well as Iegor Sergieienkov, who have helped review and refine the Connect-Info syntax.

Contributors Cisco Systems

170 West Tasman Drive San Jose 95134 US sgundave@cisco.com

Wireless Broadband Alliance

5000 Executive Parkway, Suite 302 San Ramon 94583 US bruno@wballiance.com

Single Digits

4 Bedford Farms Drive, Suite 210 Bedford 1608 US msym@singledigits.com

Boldyn Networks

Pleasanton US blair.bullock@boldyn.com

Helium

Boulder US jpadden@helium.com