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

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

general RADEXT Working Group Internet-Draft Connect-Info RADIUS WBA OpenRoaming This document describes a syntax for the Connect-Info attribute used with the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to provide servers information pertaining to the operation of 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.

but where the definition of "speed" is not defined in . 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 typically followed by a floating point value representing the maximum connection speed in Mbps. Implementations follow this with text information about the 802.11 version supported, as illustrated in .

Other implementations have extended this baseline to signal additional information to the RADIUS server, as illustrated in

The Wireless Broadband Alliance (WBA) defines the Wireless Roaming Intermediary eXchange (WRIX) framework, aimed at facilitating interconnectivity between Wi-Fi operators and the Wi-Fi roaming hub services, the Carrier Wi-Fi Services program that provides guidelines to improve customer experience on Carrier Wi-Fi networks, as well as the technical and legal frameworks that support the OpenRoaming federation of access and identity providers, enabling an automatic and secure Wi-Fi roaming experience globally . As part of its work program, the WBA has identified a number of use-cases that benefit from being able to share Wi-Fi access network quality metrics between a NAS and a server, including where the NAS is operated by an OpenRoaming Access Network Provider (ANP) and the server is operated by an OpenRoaming Identity Provider (IDP). The rest of this document describes a syntax for the Connect-Info attribute that is simultaneously able to support existing vendor implementations, while being enhanced with additional optional information to support new use-cases and requirements.

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.

Wireless Roaming Intermediary eXchange (WRIX):

• A framework, aimed at facilitating interconnectivity between operators and the Wi-Fi roaming hub services.

Types of Connect-Info Metrics The access network characteristics that can be shared between NAS and AAA include those that can be used to derive a quality metric of the performance of a Wi-Fi network. These include characteristics associated with the IEEE 802.11 connection: the Wi-Fi 802.11 version, the Wi-Fi channel number, and the Wi-Fi transmit and receive bit rates. Other use cases benefit from being able to share characteristics able to be calculated by the Wi-Fi access point's 802.11 driver, including: frame loss rate, and frame retry rate. Still other use cases benefit from sharing characteristics pertaining to the static configuration of the Wi-Fi network, including: the configured value of the minimum RSSI level for a device to associate/authenticate to the access point. Finally, other quality characteristics include measured values of: received signal strength indicator (RSSI), airtime utilization, and noise floor. The identified use cases include those where the metrics shared using the Connect-Info attribute are compared between different Wi-Fi systems, that can be operated using equipment from different vendors. In such a scenario, the algorithm used to generate a quality metric by a first installation can be different from the algorithm used to generate the same quality metric by a second installation. In order to facilitate comparisons in such a situation, there are benefits in sharing additional information pertaining to how a quality metric is calculated. This additional information includes: whether a calculation represents an average or a median value, whether an average value represent a linear or exponential moving average, and the configuration of the time duration over which a metric was calculated.

ABNF syntax for Connect-Info The Augmented Backus-Naur form (ABNF) is a syntax for specifications defined in . The proposed ABNF syntax for the text of the Connect-Info attribute used with Wi-Fi networks is shown below.

Example encoding in Access-Request The Connect-Info attribute value is limited to 253 bytes. Example encodings using the ABNF definition are illustrated in , indicating that the metrics can be signaled while keeping the attribute size below 253 bytes. In these examples, less than 180 bytes are used to encode the access network metric information.

Implementations A proof of concept has been built using modified hostapd code (https://w1.fi/) that is able to populate the connect-info attributes according to the syntax defined above.

Security Considerations This document describes a syntax that enables a RADIUS client to provide a RADIUS server information pertaining to the operation of an IEEE 802.11 wireless network. The terms agreed between the operator of the RADIUS client and the operator of the RADIUS server SHOULD include restrictions on the use of such non-personal information by the operator of the RADIUS server.

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 describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK] 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] Wireless Broadband Alliance, Inc. Cisco Systems Intel Corporation SingleDigits Cisco Systems This document describes the Wireless Broadband Alliance's OpenRoaming system. The OpenRoaming architectures enables a seamless onboarding experience for devices connecting to access networks that are part of the federation of access networks and identity providers. The primary objective of this document is to describe the protocols that form the foundation for this architecture, enabling providers to correctly configure their equipment to support interoperable OpenRoaming signalling exchanges. In addition, the topic of OpenRoaming has been raised in different IETF working groups, and therefore a secondary objective is to assist those discussions by describing the federation organization and framework.

Changelog 01 - Added extensibility to ABNF and corrected syntax. Added security considerations section. Added note on TxBitRate/RxBitRate when included in Accounting-Request type Stop. 02 - Corrected ABNF syntax definition of RATE.

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