We’ve Moved!
Our blog has a new home. From now on, all of our updates, insights, and stories will be shared directly on our website. By bringing the blog and website together, everything you need will be in one place, making it easier to stay connected with us.
Visit us at radiatorsoftware.com/blog and bookmark the page so you don’t miss out on any updates.
We recommend viewing this post in our new website's integrated blog section instead.
An eSIM is a standardised, remotely programmable digital circuit in a mobile device. Electronics with built-in eSIMs include phones and tablets, companion devices such as smart watches and other wearables, and also enterprise devices such as cellular-connected PCs, automotives and various IoT devices.
The Entitlement Servers, also known as Entitlement Configuration Servers (ECS), are used to communicate the availability of services such as eSIMs, VoWiFi and Voice-over-Cellular to the client devices. Most importantly, Entitlement Servers provide the applicable entitlement configurations enabling the services on the mobile devices.
The process of activating an eSIM is called On-device Service Activation (ODSA) and it’s specified by GSMA. To initiate eSIM provisioning, the eSIM capable device requests eSIM entitlement configuration from the mobile operator’s Entitlement Server, which in turn starts EAP-AKA dialog with the 3GPP AAA server to authenticate the subscriber. The process may also include subscription transfer when switching to a new device, or a device check to prevent eSIM activation on stolen or fraudulent devices. When all the steps are successful, the Entitlement Server sends the entitlement configuration to the mobile device.
Radiator SIM Pack is a flexible 3GPP AAA solution that provides multiple interfaces for the EAP-AKA authentication. With the Entitlement Server, Radiator can use EAP over RADIUS, or EAP over Diameter, such as SWa, SWm, STa and Diameter-EAP applications. For connecting with the operator’s subscriber servers, Radiator supports Diameter SWx, Wx, Cx and S6a/S6d interfaces, SIGTRAN, REST API and other APIs.
This flexibility allows mobile operators to easily introduce eSIM support using their existing HSS or HLR, and also makes Radiator a great solution for MNVOs who rely on the authentication interfaces provided by the parent MNO.
The above figure shows the eSIM provisioning flow (ODSA) and the various interfaces supported by the Radiator for the EAP-AKA authentication part. If you require yet another method, please contact Radiator team: we can often make it happen.
Radiator Software provides on-prem software licenses for the Radiator SIM Pack 3GPP AAA solution, and expert services to assist with the customer specific configuration and integration with the other network elements. To learn more about Radiator SIM Pack and to discuss your use case, please contact the Radiator team.
As broadband connectivity continues to serve as a backbone of modern digital infrastructure, the mechanisms that enable secure and efficient access are more important than ever. Whether delivered over copper lines (xDSL), high-speed fiber networks (FTTH) or a mixture of both, fixed-line internet services rely on a well-orchestrated authentication and provisioning system to ensure that subscribers are correctly identified, authorized, and serviced.
In this post, we’ll break down the high-level architecture of fixed-line networks and identify the key software components and their responsibilities.
Both Asymmetric Digital Subscriber Line (xDSL) and Optical fibre networks share a similar back-end architecture when it comes to authentication and user management. While the access technologies differ — xDSL using DSLAMs and FTTH using Optical Line Terminals (OLTs) — the authentication flow typically follows these core stages:
When a user powers on their home router or modem, known as the Customer Premises Equipment (CPE), it initiates a connection to the broadband provider’s access network. The CPE is typically configured to use PPP over Ethernet (PPPoE) or IPoE (IP over Ethernet) with DHCP for session establishment.
From the CPE, traffic is routed through aggregation devices; digital subscriber line access multiplexers (DSLAM) in xDSL networks and optical line terminals (OLT) in optical fibre networks.
These devices forward traffic to Broadband Network Gateways (BNGs), also known as Broadband Remote Access Servers (BRAS). The BNG is the first IP-level point of access for the user, and is responsible for IP address assignment either with a built-in or external DHCP server.
Once the session request reaches the BNG, it performs user authentication with the AAA server with the RADIUS protocol.
The BNG sends credentials (typically a circuit ID or other unique identifier, which are automatically sent from CPE) to a RADIUS server, which validates the connection and authorises it by setting line parameters from central subscriber database.
Here is where user provisioning comes into play. User provisioning is typically done by the Subscriber Management System (SMS) or more broadly, the OSS/BSS (Operations Support System / Business Support System). This is the software layer responsible for:
The OSS/BSS typically interfaces with the subscriber database, where the provisioned user information is stored for authentication and authorisation. Modern systems may use automation platforms like Ansible, NetConf, or TR-069 for zero-touch provisioning of CPE devices, especially in FTTH environments.
| Component | Role |
|---|---|
| CPE | Initiates session; endpoint for the user |
| BNG/BRAS | Handles session control and IP management with DHCP / RADIUS server |
| RADIUS server | Authenticates and authorizes user sessions against a subscriber database |
| DHCP server | Assigns IP addresses (can be built-in into BNG) |
| Subscriber management system (OSS/BSS) | Central provisioning engine for user services, integrates with subscriber database |
Radiator Software offers commercially supported ISP-grade RADIUS servers for all types of fixed-line networks. Whether a greenfield deployment or a migration from existing AAA server setup, Radiator is the product for you.For more details, please e-mail us sales@radiatorsoftware.com
A full list of changes can be found in the revision history.
Radiator Carrier Module 1.9 is recommended for all Radiator deployments with Diameter features enabled. The new release is available for all customers with active support contracts for Radiator Service Provider Pack, Radiator SIM Pack, Radiator Policy and Charging Pack and Radiator GBA/BSF Pack. You can find the Radiator Carrier downloads and repositories at the Radiator downloads page.
As always, you can contact the Radiator team at info(a)radiatorsoftware.com – we are happy to learn more about your use case and assist you!
With people’s ever-increasing online activity, communication service providers are faced with increasingly growing performance requirements for their networks. And while computing power grows as well, not all software can utilise the resources and scale to meet these increasing performance requirements.
We’ve closely monitored the feedback from our existing and prospective customers, and designed and built a new policy engine, Radiator 10, from ground up to handle the highest performance requirements, setting the bar for what the performance of a modern RADIUS server should look like.
We conducted a case study to showcase how our product excels in EAP-TLS authentication, demonstrating its ability to process an industry-leading number of authentication transactions per second. In this case study, we showcase how our solution not only enhances security but also delivers unparalleled authentication speed, ensuring smooth and secure access for thousands of users simultaneously.
The performance tests were conducted on standard-sized Google Compute Engine machines using a bash script to repeatedly execute the eapol_test tool for EAP-TLS authentication. The testing was done with two deployments, one for RADIUS/UDP and one for RadSec.
In the RADIUS/UDP deployment, the Client instances sent direct EAP-TLS authentication requests to authenticating Radiator 10 instance. In the RadSec deployment, Client instances sent RADIUS EAP-TLS authentication requests to Radiator 10 proxy instances, which proxied the requests over RadSec to an authenticating Radiator 10 instance.
For more information about the test setups, please see the case study paper here.
The tests concluded that on the test setup, Radiator 10 could process over 4200 RADIUS EAP-TLSv1.3 requests per second. With parallel RadSec connections from four proxy instances, Radiator processed over 9900 EAP-TLSv1.3 authentications per second. With an average EAP-TLS request requiring 8.4 total RADIUS packet exchanges, this means that Radiator 10 exchanged over 83 000 RADIUS packets per second over the 3 500 000 EAP-TLS authentication test set.
For more results and considerations, please see the case study paper here.
If you have questions about the performance testing, or want to discuss how Radiator 10 products, Radiator Policy Server and Radiator Core, could help you scale up your deployment, please do not hesitate to contact sales@radiatorsoftware.com
For the last 25 years, Radiator AAA has been a cornerstone of network authentication for thousands of companies across all continents and industries. There are few things it can not do when it comes to integration interfaces, backends, authentication methods and logging extensions. We’ve closely listened to feedback from existing and prospective customers, and in order to meet the demands and latest drivers in the market, and after years of development we are proud to announce a completely rewritten policy engine Radiator 10. Designed from the beginning with performance and security in mind by the same engineers who’ve worked with Radiator deployments for years. Developed with Rust, assuring asynchronous processing and concurrent queries with multi-threadding, security and continuity, Radiator products continue to be the reliable cornerstone of your network’s security that help you scale your business now and in the future.
Radiator Policy Server is our next-generation product aimed for enterprise customers. It includes full RADIUS and TACACS+ functionality, with latest functionality like enterprise Wi-Fi authentication with TLS1.3 support, RadSec and ENTRA ID authentication. The all-new user interface provides a dashboard for monitoring, option for user and client management with the built-in database, as well as options for licence and certificate management. We are currently taking up pilot enterprise customers who want to leverage the performance and functionality of Radiator Policy Server, for both greenfield deployments and as migrations from existing AAA server setups. We are currently expanding the use case base of Radiator Policy Server based on our experiences on Radiator AAA. If you are interested in joining the pilot, please contact us at email sales(a)radiatorsoftware.com.
Radiator 10 is the platform for our new product line, but at the same time Radiator AAA server products remain under active development. We also continue to offer multi-year support renewals for existing Radiator 4 based products, such as Radiator AAA Server Software, Radiator SIM Pack and others. For customers looking to take advantage of Radiator 10 products’ enhanced features, we are happy to discuss the options based on your customer needs - also providing cost-effective ways to utilize our Radiator 10 product line as well. For inquiries in new Radiator Policy Server or Radiator Core deployments or renewal of your existing Radiator AAA deployment’s support contract, please contact sales(a)radiatorsoftware.com
As the telecom industry gears up for the biggest connectivity event of the year, we at Radiator Software are also preparing for Mobile World Congress 2025, taking place at Fira Gran Via in Barcelona from March 3–6, 2025.
At MWC25, we’ll be showcasing a new Radiator product release, designed to offer an unbeatable combination of flexibility, interoperability, and high performance for complex operator AAA deployments.
Meet our team of network authentication specialists to explore key AAA topics, including FTTH authentication, WiFi roaming, VoWiFi, IMSI Privacy, OpenRoaming, and more. Whether you’re an existing partner, a longtime customer, or new to Radiator, we’d love to connect at MWC25!
Schedule a meeting here: Google Form
At 00:00 UTC (beginning of the day) on 3rd of Febuary 2025 Wireless Broadband Alliance (WBA) switched to issuing OpenRoaming certificates using new WBA Root Certificate Authority (CA) chain. This means that all OpenRoaming certificates, which are renewed or issued on 3rd of February 2025 or later, use the new WBA Root CA chain.
Although WBA planned and informed OpenRoaming Identity Providers (IdP) and Access Network Providers (ANP) about the planned change, there are OpenRoaming ANPs and IdPs, which have not updated their RADIUS/RadSec server configurations to accept both the old and new WBA root CA certificate chain for RadSec connections.
This means for example that IdP customers of the IdP using the new root chain issued certificate are not able to roam in the ANP networks, which do not accept IdP's new RadSec server certificate if it is issued by the new WBA Root CA chain. If an IdP does not accept the new WBA Root CA verified RadSec client certificates for connections originating from the ANP's Wi-Fi network, that IdP's customers are not able to roam into that ANP's Wi-Fi network.
If ANPs and IdPs do not update their inbound and outbound RADIUS/RadSec connections to accept both the old and new WBA Root CA chain certificates, when new OpenRoaming certificates are issued or old ones are renewed, gradually the roaming connections with those ANPs and IdPs deteriorate.
First install the new WBA Root CA to the CA directory for verifying inbound OpenRoaming RadSec connections:
cd /etc/radiator/certificates/radsec_inbound_openroaming/ca wget https://wballiance.com/wp-content/uploads/2024/05/wba-root1.pem chown root:radiator wba-root1.pem chmod 644 wba-root1.pem openssl rehash -v .
And then install the new WBA Root CA to the CA directory for verifying the IdP servers responding to outbound OpenRoaming RadSec connections:
cd /etc/radiator/certificates/radsec_outbound_openroaming/ca wget https://wballiance.com/wp-content/uploads/2024/05/wba-root1.pem chown root:radiator wba-root1.pem chmod 644 wba-root1.pem openssl rehash -v .
After installing the certificates, it is recommended to restart the Radiator instances responsible of handling the connections with:
systemctl restart radiator@radsec_inbound_openroaming systemctl restart radiator@radsec_outbound_openroaming
or all Radiator instances with:
systemctl restart radiator-instances
If you are deploying Radiator OpenRoaming Configuration from scratch, you should also download and install wba-root0.pem from the WBA PKI repository by following the above instructions but replacing the wget command, which retrieves the certificate with:
wget https://wballiance.com/wp-content/uploads/2024/05/wba-root1.pem
All other commands should be executed as described above for both directories.
As a result you now have a Radiator OpenRoaming configuration, which supports both the old and the new WBA Root CA chain. You can read more about Radiator OpenRoaming configuration from the Radiator OpenRoaming Configuration Guide. There are also new useful updates to the Radiator OpenRoaming configuration template files done in January 2025.
In today’s day and age, every machine around us is ‘smart’. Ranging from smart homes and wearables to more complex machines like cars, planes and industrial machinery, devices are connected with each other and with the internet to enhance user experience, control machines remotely and use other benefits of connectivity. This network of connected devices that communicate with each other and share information over the internet is often called Internet of Things, IoT for short.
Every one of these devices should be authenticated with secure methods when connecting to the internet, else a perpetrator can falsify data, steal information or gain access to networks through unsecure devices and networks. Companies can manage this and take control of their network by deploying a private access point name network, private APN for short.
The Private APN service utilises operator’s SIM cards for radio network access, but separates the data traffic in operator’s P-GW (LTE core network packet gateway) by the access point name (e.g. internet.company instead of operator’s own access point name). These separate private access points may have their own parameters for authentication, accounting, IP networks, IP address allocation, connection parameters, traffic accounting, priorities, and other functionalities. Depending on the P-GW capabilities, it is possible to move some of these functionalities and information to a separate RADIUS service, which is provided either by the operator or company utilising the Private APN.
The choices of authentication method are between PAP and CHAP. As can be seen from the picture, the deployment does not need extensive infrastructure for the AAA, merely a basic Radiator AAA licence and a backend of choice (AD, SQL, REST etc.).
The private APN functionality can also be enhanced with Radiator SIM Pack. If the IoT device also has Wi-Fi radio and functionality, it can also utilise Wi-Fi access whenever within range of the company’s Wi-Fi network. In this case, the authentication would be done directly with SIM-based authentication methods (EAP-AKA, EAP-AKA’) and the device will have access to the company network via Wi-Fi, like illustrated in the next picture.
The benefits of adapting Radiator SIM Pack lies in coverage. While the monitoring and other IoT devices might not need the biggest bandwidth, reliable cellular connection can be an issue for in-door solutions, for example in warehouses. With Radiator SIM Pack, the IoT devices will connect to the company network securely over Wi-Fi, ensuring reliable monitoring and metrics.
If you are building an IoT device network or want to enhance the security of an existing IoT device network, Radiator is the solution for you.
For more information about Radiator licensing, technical details or for any questions, please do not hesitate to contact us sales@radiatorsoftware.com
In recent years, libraries have evolved from venues where people come to pick up books into community places for people to read, study, work and much more. As most of these activities require reliable internet access, there is no denying that providing stable connectivity is becoming a requirement for modern libraries.
Hence why more and more libraries are looking at efficient and secure ways to enable connectivity for their patrons, while ensuring that that connection is not used for malicious business. Having an open Wi-Fi broadcasted across the library facilities is not the way to, and provisioning separate credentials for internet connection for all users visiting the library is a big hassle.
Radiator has got you covered. Radiator AAA server seamlessly integrates with existing Library management system (LMS, also known as Integrated library system, ILS) providing patrons connectivity utilising the credentials from LMS, used for lending books.
The key to library Wi-Fi authentication with Radiator lies on 3M™ Standard Interchange Protocol 2.0, known as the SIP2 protocol. The SIP2 protocol provides an interface between a library’s management system and library automation devices. This is the same protocol used for automated self-check devices for loaning and returning library books, and the parameters that can be used for self-lending can also be used for Wi-Fi access.
Radiator authenticates patrons based on their existing patron credential, for example library card number and PIN code. This means libraries do not need to provision and store separate Wi-Fi credentials for patrons. The basic version of this configuration is very simple and Radiator’s scripts handle the communication with the library system. Essentially, in the library system’s view, Radiator is a self-service loaning device among the others.
This integration also enables further functionality. Radiator can be configured to do that if the patron has outstanding fines or fees that exceed an agreed threshold, their Wi-Fi access will be declined upon login. This is done by Radiator’s scripts and is a toggleable option within the Radiator configuration file. The access can be tied to patron status or other patron information, for example age restriction can be applied.
Radiator is priced based on the number of servers, which makes a single library deployment very cost-effective. Radiator’s flexible evaluation licences allow you to set up a test system and see the solution working before making any commitments.
If you are interested in deploying a secure, robust and affordable solution for your library connectivity, please contact our sales team at sales@radiatorsoftware.com
Recently, we have seen a significant increase in demand for our Wifi Offloading solutions and services. Many mobile operators are aiming for increased use of their own existing wifi infrastructure or the use of wifi infrastructure provided by 3rd party partners. This is done in many cases to expand especially indoor coverage in areas where 5G infrastructure has its limitations.
With Radiator, the essential product is Radiator SIM Pack that provides the integration between key components in wifi network and mobile core for WiFi Offloading. In this blog, we are clarifying how this kind of concept can be easily evaluated in different networks - as we are currently engaged heavily in these kinds of projects.
How Wifi Offloading Proof of Concept can be implemented?
For this kind of Wifi Offloading Proof of Concept (POC), a small number of steps are needed.
Firstly, you will need access to relevant wifi controllers / access gateways, in order to configure the RADIUS traffic to be configured towards Radiator SIM Pack. With this, seamless SIM authentication (with EAP-SIM/EAP-AKA/EAP-AKA’ for example) can be implemented.
As a next step, you will need to install the evaluation version from relevant Radiator packages: Radiator AAA Server Software, Radiator Carrier Module and Radiator SIM Module, along with the UtilXS component. The packages exist for all recent versions of RedHat based systems, Ubuntu and Debian.
After the installation, our team will provide you with the necessary configuration in order to configure traffic towards your subscriber data source. For HSS, Diameter SWx interface is the standard. Radiator can also use Diameter S6d, Cx or Wx interfaces. When using HLR, Radiator connects with GSM MAP with SIGTRAN. If the subscriber data is stored in more than one location, Radiator can authenticate SIMs from multiple backends. SIM authentication uses IMSI, and Radiator can optionally fetch user MSISDN (phone number) for billing purposes.
Lastly, you will need to have access to the carrier profiles for the mobile phones or other end user devices so that automatic wifi authentication can be done. The methods for this differ a bit with Android and iOS devices: for Android, there are developer tools available for your own testing. For iOS, you need assistance from Apple. For both cases, we are happy to provide assistance.
As can be seen, successful WiFi Offload POC requires a bit of cooperation internally in the organization of the mobile operator. However, at the same time the needed configuration is typically something that can be done with limited effort - and with the assistance from us. As we have already deployed tens of successful WiFi offloading and VoWiFi installations, most challenges (and how to overcome them) are familiar to us.
What are the next steps?
If you are interested in WiFi offloading, please do not hesitate to contact us. Please fill out our contact form or contact sales@radiatorsoftware.com, and we are happy to help you with the next steps.
Altice Labs, a technology company that is at the forefront of global innovative solutions in telecommunications, networks, and digital services, alongside Radiator Software, a Finnish company which provides AAA (RADIUS/Diameter Authentication, Authorization and Accounting) software products and services for Service Providers and Enterprises, announced a partnership enabling both organizations to jointly deliver end-to-end solutions to Service Providers and Enterprises.
This partnership will allow Altice Labs and Radiator Software to combine efforts to improve efficiency by eliminating barriers and accelerating delivery, thereby enhancing the value of products and solutions for both organizations. One of the key use cases that Radiator Software and Altice Labs can provide together includes WiFi offload and Voice-over-WiFi solutions, among others.
Jaakko Stenhäll, Director of Business Development at Radiator Software, highlighted that, “with Altice Labs, we are able to complement our Radiator AAA offering with excellent technical knowledge on different customer needs and also world-class support on various markets - bringing great value to our mutual customers”.
Tiago Pereira, Director of Global Business Development at Altice Labs, commented, “we are looking forward to partnering with Radiator Software, bringing our extensive experience, knowledge and technical expertise on network and service management and control. This is an area where Altice Labs has been present for more than 20 years, with its own products and solutions”.
For Cleverson Novo, Managing Director of Open Labs - Altice Labs branch in Brazil, “this area has gained huge importance in the Latin America market, with Service Providers leveraging their Wi-Fi networks as a complement to traditional cellular networks“.
Together, both companies are paving the way to the future, exploring new marketing opportunities and business growth.
We are delighted to announce that Radiator Software will be attending the two top connectivity events of the season: WGC EMEA and Network X, co-located in Paris on 7 – 10 October 2024. We are looking forward to meeting our current and prospective partners and customers in Paris.
WGC is hosted by the Wireless Broadband Alliance and gathers together Wi-Fi industry leaders and experts from all around the world. As usual, the event is divided into two parts: WBA Members-Only Sessions on 7 and 8 October at the Hôtel Mercure Paris Porte de Versailles Expo, followed by the WGC EMEA Open Congress on 9 and 10 October in Porte de Versailles conference centre.
https://www.wirelessglobalcongress.com/emea-2024/
Network X event runs through 8 - 10 October and brings together Broadband World Forum, 5G World and Telco Cloud. For service providers of all kinds, Radiator provides a flexible AAA solution for fixed broadband, wireless, and WiFi offloading including VoWiFi.
For more information about the Network X event, please see the official website: https://networkxevent.com/
You can find the Radiator team at the WBA Members-Only Sessions and in the WGC Open Congress throughout the event. For insights on Wi-Fi authentication, Wi-Fi roaming and OpenRoaming, we extend an invitation to all WGC EMEA and Network X attendees to meet with the Radiator team and managing director Karri Huhtanen.
To book a meeting or simply ask a question, please leave a message and we will get back to you. See you in Paris!
As mobile and wireless networks have evolved, the ability for users to move between different networks while maintaining service, known as roaming, has become essential. WiFi roaming, while convenient for users, introduces several complexities for service providers, particularly in managing billing and user identity securely across network boundaries.
The Chargeable User Identity (CUI) parameter was introduced to address these challenges. While the specification RFC 4372 for CUI has existed for quite awhile, the implementations are now popularising as commercial Wi-Fi is becoming more sought after.
Chargeable user identity is a parameter used mostly by service providers to identify users for accounting in roaming networks, while ensuring their privacy is not compromised with trackable credentials. The CUI allows service providers to charge users based on their usage, even when users roam across different networks. It is primarily intended for billing purposes, but also provides other benefits to both public and commercial networks.
The main benefit of using Chargeable User Identity parameter is that it solves the business problem of anonymity in commercial networks, while not making any compromises in privacy and security. It provides a robust mechanism for calculating usage, which can be used not only for billing but also analytics purposes. For example, with CUI, roaming network providers can track whether their 100 sessions come from 10 users with 10 sessions each or by 2 users with 50 sessions each. This allows for more accurate analytics, but does not allow the networks to identify the users. This is possible in deployments where the CUI is the same across all of the user’s devices.
The use of Chargeable User Identity also allows public institutions to restrict and ban roaming users who violate their terms. Previously, when administrators decided to take action against users who violate their visiting terms, the user can simply log on with another device. With a CUI parameter that is mutual across user’s all devices, this is not possible.
Chargeable User Identity is transmitted in RADIUS packets using dedicated RADIUS attribute 89: Chargeable-User-Identity. The implementation is specified in RFC 4372.
Upon sending the authentication Access-Request to the home organisation for a roaming user’s authentication, the visiting organisation should add the Chargeable-User-Identity parameter into the request with a null value. This signals the home organisation that a CUI is requested. The home organisation check’s for an existing valid CUI and sends either a new or existing valid CUI included in the Access-Accept.
The Chargeable-User-Identity parameter will remain the same for the duration of the roaming user’s session and is included in the accounting packets and responses.
Are you looking to deploy Wi-Fi offloading or other Wi-Fi roaming functionality for your customers or members of your organisation? Or are you setting up a commercial Wi-Fi infrastructure to provide roaming services for operators? For both cases, Radiator AAA is the product for you.
Radiator AAA provides functionality for Wi-Fi roaming host organisations, with dozens of completed deployments for the biggest Wi-Fi roaming networks (eduroam, govroam, OpenRoaming). Combined with the Radiator SIM Pack, Radiator provides seamless authentication for Wi-Fi offloading, roaming between mobile networks and Wi-Fi. Both products and use cases include Chargeable User Identity function for Radiator.
For more information about CUI deployments, please contact our sales team at sales@radiatorsoftware.com
Latest reports from the industry indicate that globally 5G subscriptions are closing in on 20% of all mobile subscriptions. Mobile operators are deploying 5G networks at an increasing rate and 5G is at an early stage of its life cycle. Global data usage increases year by year and mobile operators’ cellular networks are hard-pressed to withstand all the traffic, requiring investment in more infrastructure.
5G provides higher data rates and other benefits compared to the previous generations, but at the cost of lower signal range. Strong 5G signal for proper coverage requires operators investment in small cell networks and even with one customers might struggle with in-door service quality. At the same time, there are commercial and other WiFi network infrastructure already in place for many of the areas where operators struggle with in-door coverage.
In this blog post, we’ll take a look at underlying reasons driving the demand for Wi-Fi offloading, and how Radiator SIM Pack solution provides the seamless authentication to enable it. In short, with the performance and reliability that Wi-Fi 6 and 7 have brought to the table, it is easy to see the economical and environmental benefits Wi-Fi offloading brings to those who adopt it, all while improving end users’ coverage and quality of service indoors without need for massive infrastructure investments.
Even before 5G, operators were struggling with in-door coverage of cellular networks. Upgrading to 5G will not improve the coverage, but rather do the exact opposite. 5G utilises higher signal frequency millimetre waves, which are unable to penetrate obstructions and have short range. This is becoming a key concern when designing 5G networks in congested areas. However, building a network of small cells to reach proper coverage in-doors is fast becoming a challenge for operators in urban areas.
Wi-Fi offloading can significantly enhance coverage and quality of service for network operators by leveraging the ubiquitous presence of Wi-Fi networks to alleviate congestion on cellular networks. By directing data traffic from overloaded cellular networks to available Wi-Fi connections, operators can effectively extend coverage into areas with weak cellular signal and manage high-demand scenarios, such as large public venues. Wi-Fi offloading not only optimises the utilisation of network resources but additionally offloading traffic to Wi-Fi can help operators reduce network congestion and associated operational costs, making it a win-win solution for both service providers and their customers.
As an added benefit for the end user, According to Wireless Broadband Association, smartphones and IoT devices using Wi-Fi 6 have an up to 67% lower power consumption compared to their respective cellular networks. This energy efficiency will be further enhanced with Wi-Fi 7. This does not directly affect the operator, but enhances the end users’ service quality.
This point is not specific to 5G, but rather for all operators who have previously considered Wi-Fi offloading and found Wi-Fi to have high latency, unreliable connections and low data rate, not matching the standard operators want for their networks. This may have been the case once, but not anymore.
Wi-Fi 6, 6E and especially Wi-Fi 7 have brought down latency (below 5ms on most estimations), increased data rate tremendously (up to 46 Gbps) and made connections much more reliable. And as discussed previously, Wi-Fi networks are built with coverage in mind, bringing offloading users optimal quality of service even in areas with dozens of devices online.
Another concern our MNO customers have expressed from time to time is that Wi-Fi security is not up to par with mobile networks. Today’s Wi-Fi offloading solutions use EAP-AKA and EAP-AKA’ authentication, which provides vast improvements to older protocols. IMSI Privacy and standards in MAC address randomisation should be in place in a modern Wi-Fi offloading solution, with which end users details remain private and can not be snooped. Security and privacy concerns are a thing of the past for operators who want to adopt Wi-Fi offloading, so long as the operator chooses a solution that provides these features.
We’ve seen many industry blogs and articles discuss the differences of 5G and Wi-Fi, often comparing them as rivals and recommending customers choose one or the other based on their needs. This need not be the case. As leading operators have demonstrated, these networks are not at odds, but rather better utilised together.
Wi-Fi offloading can solve operators’ problem of coverage in congested areas, particularly in-doors and in large venues with high volumes of data traffic. These areas often have Wi-Fi infrastructure in place which operators can utilise, lessening the need for investment in small cell networks.
As an improvement to previous mobile network generations, Wi-Fi offloading has been clearly specified as part of 5G architecture in 3GPP standards (3GPP TS 33.501; Annex S). When viewed as part of the architecture with dedicated authentication interface, rather than a case-by-case solution, Wi-Fi offloading is becoming a more integral part of operators’ connectivity stack.
Are you looking to adopt Wi-Fi offloading to your cellular network? Radiator SIM Pack is the product for you! Radiator SIM Pack provides seamless authentication for mobile users roaming between cellular and wireless networks.
Radiator SIM Pack provides SIM-based authentication (EAP-SIM, EAP-AKA, EAP-AKA’) with IMSI Privacy and a variety of different integration options for Diameter interfaces and for logging. Often combined with the Radiator Policy and Charging Pack for OCS billing integration, these products provide a one stop shop for operators looking to adopt seamless Wi-Fi offloading for their mobile customers.
If you wish to learn more about our Wi-Fi offloading deployments, please do not hesitate to contact sales@radiatorsoftware.com
We are pleased to announce the release of Radiator version 4.29. The latest release includes a major Radius protocol security fix, and the usual usability and interoperability improvements and bug fixes.
Radiator is actively engaged with IETF’s radext working group and we have been working under embargo to implement the fixes based on the work done in the group.
Please see the security notice for more information on CVE-2024-3596 and our security recommendations.
More detailed changes can be found in the revision history. Radiator packages are available to download for current licensees from the downloads page and the Radiator repository.
As always, you can contact Radiator team at info(a)radiatorsoftware.com - we are happy to learn more about your use case and assist you!
In February 2024 University of California San Diego researchers and their partners reported a vulnerability discovered in the RADIUS protocol to the CERT and IETF. The RADIUS protocol vulnerability was later named BlastRADIUS. The vulnerability allows the attacker to alter RADIUS messages between the RADIUS server and client so that for example a rejected authentication can be turned into accepted authentication. Utilising the vulnerability requires that the attacker is able replace the original requests and replies between RADIUS client and server with the attacker’s content. Only the RADIUS messages, which do not contain message authenticator, or where the RADIUS client or server is not verifying message authenticator properly, are vulnerable.
Radiator Software has been working since February together with the researchers and other RADIUS server implementers to implement the identified fixes for RADIUS protocol in Radiator. This work and fixes have been under embargo until July 9th 2024 12:00am UTC. The fixes for RADIUS protocol have been implemented in the Radiator v4.29 released now after the embargo has ended.
Since this is a recently discovered RADIUS protocol vulnerability, all Radiator versions up until version 4.29 are affected.
The RADIUS server deployments, which send and receive RADIUS requests without message authenticator or RadSec (RADIUS over TLS) over untrusted networks, are the most vulnerable for abuse. Enterprise Wi-Fi (EAP) authentication is using message authenticator in all messages by default so in those networks, the effect of the vulnerability depends if the RADIUS client implementation (e.g. in a Wi-Fi controller) is verifying the message authenticator properly. In addition to the RADIUS server updates, also RADIUS clients and client software may need to be updated.
As Radiator implements the RADIUS protocol all Radiator configurations and deployments using RADIUS protocol without requiring Message Authenticator or RadSec (RADIUS over TLS) are affected by this vulnerability.
Radiator Software strongly recommends upgrading Radiator to the latest version to get all the improvements and fixes to the vulnerability. In addition to upgrading Radiator, the Message-Authenticator requirement instructions should also be followed.
Radiator version 4.10 (2012) or newer can be configured to require a Message-Authenticator from a RADIUS client by adding RequireMessageAuthenticator to the Client configuration. For example:
<Client 192.0.2.42>
Identifier CLIENT-IPV4-192.0.2.42
Secret 6m9TXQTjLdH5BbgT
RequireMessageAuthenticator
</Client>
Please note that configuring RequireMessageAuthenticator will require the Message-Authenticator to be present in the request and does not accept requests without it.
A legacy RADIUS client, which is not able, or configured, to send Message-Authenticator is not able to connect with Radiator after this requirement. The RADIUS client should be configured to send Message-Authenticator in its requests and require Message-Authenticator in the replies. If only Radiator is configured to use Message-Authenticator but RADIUS client does not require it, an attacker can drop the Message-Authenticator from the reply to Access-Request and modify the contents of the reply.
By default Radiator proxies and responds with Message-Authenticator to all messages with Message-Authenticator already present in them, but accepts also requests without the Message-Authenticator for compatibility and interoperability reasons.
If your configuration uses SQL database to specify clients in addition to (or instead of) the Radiator configuration by utilising the ClientListSQL, please see ClientListSQL part of Radiator AAA reference manual. See documentation subsections GetClientQuery and ClientColumnDef for more detailed instructions.
Radiator v4.29 (2024) adds RequireMessageAuthenticator configuration directive for RADIUS based AuthBys such as AuthBy RADIUS, ROUNDROBIN and HASHBALANCE. With RequireMessageAuthenticator enabled, the AuthBy only accepts requests with Message-Authenticator in the RADIUS replies. Radiator by default adds Message-Authenticator to outgoing messages.
<AuthBy RADIUS>
Identifier AUTHBY-RADIUS-PROXIES
Secret 9iLeKAnBP8e8oMhb
Asynchronous
Retries 1
RetryTimeout 3
FailureBackoffTime 5
# Requires Message-Authenticator from all RADIUS proxies/servers in this AuthBy
RequireMessageAuthenticator
<Host 192.0.2.111>
# RequireMessageAuthenticator can also be required per host
#RequireMessageAuthenticator
AuthPort 1812
AcctPort 1813
</Host<
<Host 192.0.2.112>
# RequireMessageAuthenticator can also be required per host
#RequireMessageAuthenticator
AuthPort 1812
AcctPort 1813
</Host>
</AuthBy>
Radiator v4.29 introduces an additional configuration directive, LimitProxyState, which can be added to NAS RADIUS client definitions to require a valid Message-Authenticator in all requests, which contain the Proxy-State attribute used in the BlastRADIUS attack. This allows requests without Message-Authenticator (e.g. RADIUS client does not support it) to be received, but prevents the BlastRADIUS attack by not accepting requests with Proxy-State included in them. This configuration directive should only be used for NAS RADIUS clients, e.g network equipment such as switches, Wi-Fi controllers etc. It should not be used for clients, which are RADIUS servers or proxies. An example of the configuration is below:
<Client 192.0.2.42>
Identifier CLIENT-IPV4-192.0.2.42
Secret 6m9TXQTjLdH5BbgT
LimitProxyState
</Client>
Please note that RequireMessageAuthenticator should not be set together with LimitProxyState because RequireMessageAuthenticator will prevent requests without Message-Authenticator altogether. LimitProxyState is intended for use cases where client can not be configured to send Message-Authenticator.
If your configuration uses SQL database to specify clients in addition to (or instead of) the Radiator configuration by utilising the ClientListSQL, please see ClientListSQL part of Radiator AAA reference manual. See documentation subsections GetClientQuery and ClientColumnDef for more detailed instructions.
To utilise the vulnerability the attacker needs to get in between RADIUS servers or between RADIUS server and RADIUS client. Separating unencrypted RADIUS traffic into a management network and reducing the routing distance between the server and clients makes it more difficult to perform the actual attack.
Unencrypted RADIUS over public networks exposes the RADIUS requests for the well-resourced attackers to abuse and should be avoided.
The BlastRADIUS attack only works on unencrypted RADIUS traffic over UDP or TCP. The RADIUS traffic can already be secured with RADIUS over TLS (RadSec, RFC 6614) or with VPN solutions if RadSec support is not available.
Radiator is the first RADIUS server ever (v3.12, 2005) to implement RADIUS over TLS neve(RadSec, RFC 6614), which was an IETF draft originally developed in cooperation between eduroam and Radiator implementers. Radiator Software continues to participate in developing the RADIUS over TLS specification in the IETF as well as implementing the latest features into the Radiator itself.
Radiator Software strongly recommends migrating from unencrypted RADIUS to RADIUS over TLS. While requiring Message-Authenticator from RADIUS client and servers mitigates the vulnerability, the effort needed to configure these and test the changes, clients and servers for interoperability may be greater than configuring and deploying RADIUS over TLS to secure both the protocol and privacy of the information transferred in RADIUS request attributes.
If your multi-factor authentication is using RADIUS, it is likely to be affected. The exposure for the vulnerability depends on the RADIUS clients, servers and the attacker’s access to the network in between them. If your systems are for example doing MFA authentication with unencrypted RADIUS over the public Internet to a multi-factor authentication service provider your authentication is exposed and vulnerable. Is my enterprise Wi-Fi (WPA2/WPA3 Enterprise) affected?
No. Enterprise Wi-Fi utilises EAP authentication over RADIUS. The EAP authentication already mandates Message-Authenticator in all requests.
No. Both eduroam and OpenRoaming are utilising EAP authentication like enterprise Wi-Fi (WPA2/WPA3) networks. OpenRoaming additionally mandates RadSec (RADIUS over TLS) and it is also supported in eduroam.
Similarly as with multi-factor authentication if your VPN endpoint is using unencrypted RADIUS for authenticating the VPN connection credentials from the RADIUS server or service, this vulnerability could be used in the worst case to allow an attacker to get a successful VPN connection to your network. Those VPN solutions which are using EAP authentication with RADIUS servers are not affected.
The roam.fi roaming service is similar to eduroam and OpenRoaming utilising Enterprise Wi-Fi EAP authentication so it is not affected. Additionally roam.fi roaming service also supports RadSec (RADIUS over TLS) and it is strongly recommended that the roam.fi member organisations would migrate in using RadSec, when they have the RadSec connection capability themselves. The service will be updated to utilise Radiator v4.29 as soon as it becomes generally available.
The Radiator Auth.Fi EAP authentication including both username-password and client certificate authentication is not affected.
The captive portal and MAC address authentication used for guest network functionality is affected if unencrypted RADIUS connections are used. The Radiator Auth.Fi already supports RadSec client connections for securing the RADIUS traffic and it is strongly recommended that customers who have the ability to use RadSec, will switch to using RadSec instead of unencrypted RADIUS.
The Radiator Auth.Fi Radiator will also be updated to utilise Radiator v4.29 as soon as it is released and that will enable additional options for adjusting Message-Authenticator settings for unencrypted RADIUS.
As these solutions are usually based on unencrypted RADIUS they are affected, but usually the RADIUS traffic is in these cases separated into management networks. If an attacker has access to a management network, the attacker is more likely to focus on more interesting targets than fabricating RADIUS requests and replies. The mitigation options work also in these networks, but extra attention should be given to testing, because the mitigation requires interoperable functionality from both RADIUS servers and clients.
If you have an active support contract for Radiator, you can get Radiator updates including the new Radiator v4.29 release from the Radiator download and repository page at https://radiatorsoftware.com/downloads/. If you are not sure or have an older license without a support contract, please contact sales@radiatorsoftware.com to renew your support.
Radiator Software email support is able to answer questions and support you in case you want to evaluate the vulnerability’s effect on your deployment and use case. If you have active support, you can contact Radiator support at support@radiatorsoftware.com. If you are not sure or have an older license without a support contract or want to engage in larger scale configuration evaluation or upgrade, please contact sales@radiatorsoftware.com to renew your support or discuss the scope for Radiator expert services.
BlastRADIUS WWW site: https://www.blastradius.fail/
BlastRADIUS paper: https://www.blastradius.fail/pdf/radius.pdf
CERT CVE: https://www.cve.org/CVERecord?id=CVE-2024-3596
CERT Coordination Center: https://kb.cert.org/vuls/id/456537 (vendor status for vulnerability fixes)
Radiator revision history (v4.29): https://radiatorsoftware.com/products/radiator/history/