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.
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
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/
From time to time, our customers reach out to us and ask guidance on how to speed up RADIUS authentication processing during peak hours. Performance of this core functionality of Radiator is stable and predictable, and with increasing traffic load, most of the bottlenecks often emerge from the performance of the backend services that Radiator is utilising. In this blog, we give some helpful information to make improvements.
What causes bottlenecks?
In many cases, authentication backends that Radiator is configured to use may be too slow to process the number of requests that are arriving. For example SQL databases may be slow to respond, LDAP lookups can take time, or HTTP requests be delayed. Writing accounting data or logging to a slow database can slow down Radiator.
When this happens, the host system's UDP traffic buffer on the listening port fills up to the point that it overflows and new RADIUS request packets arriving at the server get dropped. Because the requests are dropped by the host operating system, they cannot even be logged as failed requests by Radiator.
To get a better understanding of what is happening during peak hours, set `Trace 4` debug log level with `LogMicroseconds` in the configuration file (see [How to enable debug logging?]. The debug log will show how long each processing step is taking, and from there you can determine how many requests per second the configuration can handle.
How to tune Radiator to speed up authentication processing?
There are several ways to tune Radiator to speed up processing:
We are delighted to announce that Radiator Software will be attending the top connectivity event of the summer: WGC Americas in Dallas on 10 – 13 June 2024. We are looking forward to meeting our current and prospective partners and customers in Texas.
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 and plugfest on 10 and 11 June hosted by AT&T, and WGC Americas Open Congress on 12 and 13 June held in Dallas Marriott Downtown.
We extend an invitation to all WGC Americas attendees to meet with Radiator managing director Karri Huhtanen, who is part of our conference delegation. You can find the Radiator team at the WBA Members-Only Sessions and in the Open Congress throughout the event.
To schedule a meeting or simply ask a question, please leave a message and we will get back to you. See you in Texas!
We are pleased to announce an expansion to the Radiator product offering – Radiator Cloud for Azure. We have ever so often been approached by companies and organisations that require a fast to set up, easy to use hosted WiFi authentication solution.
Often the trouble with Software-as-a-Service type WiFi solutions is the concern for privacy, who has access to customer data and how it is handled. To address the demand for a hosted solution with complete privacy to customer data, we’ve developed an Azure-native cloud solution – Radiator Cloud for Azure
Radiator Cloud for Azure is a managed application that is deployed, hosted, operated and monitored all in Azure. User data and logs stay within your Azure tenant with no external access. User and NAS client provisioning is done with enhanced Azure UI and the solution can be monitored with premade Azure Monitoring queries.
The first application that is now live in Azure Marketplace is Radiator Simple WiFi authentication. It is a simple username-password authentication solution that allows organisations to take control of their wireless network with minimum requirements. The only prerequisites to deploying the solution are an active Azure subscription and access to one’s network device configuration.
Deployment is done within minutes from the Azure Marketplace. A user with at least Contributor permissions for their tenant can deploy the application. Provisioning and monitoring is made straightforward with Azure UI and billing is done together with the organisation's other Azure applications.
The main customer groups that benefit from the application are organisations who do not yet have any WiFi authentication solution in use, as well as organisations with multiple locations who want to centralise their WiFi authentication operations. Radiator Simple WiFi authentication provides an easy way for centralised user and device management with minimum prerequisites.
Radiator Simple WiFi authentication is easy, fast and affordable. The simple structure of the application, backed with comprehensive deployment guide and user manual, make the application easy to deploy and operate. Deployment process is automated and does not need any vendor approval. Provisioning is very straightforward. In a typical deployment, you have a working system within the same day.
The costs of the application consists of two parts: fixed monthly software cost and Azure running costs for hosting the application. All costs are transparent and easy to estimate. You are only billed by Azure, along with your other Azure applications.
While Radiator Simple WiFi authentication is already available for purchase in Azure Marketplace, we are also actively looking to expand the Radiator Cloud product family both horizontally with other use cases and vertically to other platforms.
Our two big roadmap items for Radiator Cloud are enterprise-grade WiFi authentication application and an application for WiFi authentication utilising Microsoft Entra IDs. Both of these address a direct need not only from new but also existing customers who are looking to move from their existing Active Directory on to Azure.
While these development news are all about Radiator Cloud, this is by no means a sign that we would have shifted focus from our on-site products. Radiator is committed to active development and latest standards and these efforts are made to make Radiator products more accessible to all organisations across different platforms and deployment models.
If you have any questions about Radiator Simple WiFi Authentication or Radiator Cloud roadmap items, please do not hesitate to contact us at sales(a)radiatorsoftware.com
Radiator team continues the active engagement with RADIUS working groups at IETF and will be attending IETF 119 meeting in person at the Brisbane Convention and Exhibition Center 16 - 22 March 2024.
Staying at the forefront of industry developments is a top priority for Radiator development. As always, we are looking forward to working on RADIUS drafts and standards and implementing them in Radiator.
You can find the Radiator team at these sessions - click the links for the respective meeting materials and agendas.
Radext working group will be discussing reverse CoA and deprecating insecure practices in RADIUS. EMU group has Forward Secrecy for EAP-AKA on the agenda, and madinas group is addressing the current status of MAC randomisation. We also welcome Wireless Broadband Alliance presenting a document describing OpenRoaming protocols - for Radiator, we have released the Radiator OpenRoaming configuration guide on Github.
For other IETF sessions, please see full meeting agenda here: https://datatracker.ietf.org/meeting/119/agenda
The point of contact is Radiator developer Heikki Vatiainen, whom you can find at the RADIUS working group sessions and around the venue. If you’re in Brisbane, come find us and say hi! Everyone else interested in Radiator development, please drop us an email!
Like everyone else in the telecom industry, we’re busy preparing for the world’s largest connectivity event of the year: Mobile World Congress held at Fira Gran Via in Barcelona on 26th – 29th February 2024. We’re looking to catch up with old and new partners and customers in Barcelona!
For MWC24, Radiator Software is showcasing Radiator solutions, which deliver a superb combo of flexibility, interoperability and performance to complex operator AAA deployments. We invite you to engage with our team of network authentication experts to discuss all things AAA: FTTH authentication, WiFi roaming, VoWiFi, IMSI Privacy, OpenRoaming, and more.
Book a meeting here: Google Form
Recently, we have met increased demand for SIM authentication in different use cases and services. Radiator development is driven by the actual customer cases and we are now pleased to announce the release of Radiator SIM Pack version 2.9!
Here are selected highlights from the new release:
Diameter Cx interface provides an alternative way of fetching the SIM authentication vectors when the standard SWx interface is not available from the MNO. Cx is an HSS interface that is typically used to authenticate users from the IMS side of the network, but Radiator can now also use it for SIM based Wi-Fi authentication.
Support for MAP UpdateLocation, MAP UpdateGprsLocation and MAP CancelLocation have been implemented in SIGTRAN. Location update features make it possible to resolve the user MSISDN (i.e. mobile number) and use IMSI related profile for authorisation. As a result, different authorisation rules can be enforced based on the MSISDN, or mobile numbers can be included in logging, accounting and other customer specific requirements.
Temporary Mobile Subscriber Identity or TMSI is a pseudonym for the subscriber’s actual identity, IMSI. Plain or encrypted IMSI is always used for the initial SIM authentication, but a temporary identity can be generated for the subsequent requests to make re-authentication faster and increase security. Radiator TMSI implementation has now been updated per recent 3GPP specification: the improved implementation no longer requires a SQL session database further enhancing the speed of re-authentication. Historical data is also retained better.
For a full list of new features and changes, please see Radiator SIM Pack revision history.
In our recent projects with customers ranging from small private operators to major tier 1 carriers, we have seen these significant trends:
In addition, security requirements have increased. Demand for IMSI Privacy is driven by Android and iOS, and support for IMSI encryption is now a must for new offloading projects. RadSec is required for various roaming scenarios, including OpenRoaming. Both are supported by the Radiator SIM Pack - with a long track record of field proven production implementations.
Radiator pre-sales team includes experienced engineers who can provide expertise for advanced Diameter and roaming use cases, including non-standard and custom cases.
In addition to top tier technical support, we also provide a flexible licensing model to match your business case. Whether you have your own subscribers, IoT devices or roaming guests, you can grow your license at the same pace where your business grows - you can just buy add-on licensing as you are onboarding more SIM authentication or VoWiFi end users, for example.
We always know that every customer case is different - so please do not hesitate to contact us at info@radiatorosoftware.com.
We are pleased to announce the release of Radiator version 4.28! The latest release is full of stability, usability and interoperability features that make it easier than ever to run and maintain Radiator.
New vendor specific attributes included in the standard dictionary:
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 our sales team at info(a)radiatorsoftware.com - we are happy to learn more about your use case and assist you!
Radiator is a command line software which is controlled with a simple text file. The Radiator AAA reference manual and goodies directory contain a plethora of examples, but it might be daunting to find a good starting place.
Radiator runs on a wide range of platforms and there are platform specific installation packages as well as the full source code package available. Check out the installation instructions from Radiator AAA reference manual.
The manual lists various system requirements, but the absolute minimum that is needed for a simple initial setup are Radiator installation package, Radiator Radius::UtilXS add-on and Perl. Perl is usually included in the most common Unix distributions, and for Windows the Radiator MSI package contains all of these!
Once Radiator is installed, it is time to see that Radiator can be run. The deb, RPM and MSI installation packages all install Radiator so that it is controlled by the system. On the Unix side by systemd and on Windows as service. By default the installation also brings a Radiator configuration that can be used to verify the installation, that is the configuration is capable of receiving RADIUS authentication and accounting requests from within the system and always responds with accept.
See how to start Radiator service and run the test from the installation instructions:
The default configuration available right after Radiator installation is not particularly useful, seeing as it always responds with accept. To develop a proper Radiator configuration, suitable to your needs, check out the goodies directory available in /opt/radiator/radiator/goodies/ on Linux and in \Radiator\Radiator\goodies\ on Windows. Note that on Windows Radiator is automatically installed on the drive that has most space, so the directory can be C:\Radiator\Radiator\goodies\ but it could also be E:\Radiator\Radiator\goodies\
Goodies contains full configuration examples, so when picking suitable starting point to your own configuration you can just copy the whole configuration from goodies as the default Radiator configuration /etc/radiator/radiator.conf on Linux or C:\Program Files\Radiator\radiator.conf on Windows. For example goodies/simple.cfg shows how to authenticate users from a file:
perl /opt/radiator/radiator/radpwtst -user mikem -password fredon Linux or on Windows:
perl radpwtst -user mikem -password fred
Although the recommended approach is to use the distribution specific Radiator packages, sometimes the source code package is the only option. The source code package can be unpackaged to any directory and it doesn’t automatically create any services. The simplest way to test the source code package is to run both Radiator server and radpwtst test from the command line.
perl radiusd -foreground -log_stdout -trace 4 -config_file simple.cfg
perl radpwtst -user mikem -password fred
You now have a basic Radiator installation and you are ready to start configuring Radiator your own use case. Check out these resources:
For any questions, please reach out to us at info(a)radiatorsoftware.com. We’re always ready to discuss your use case and how to implement it with Radiator!
We are delighted to announce that Radiator Software will be exhibiting at the top connectivity events of the season: WGC EMEA and Network X co-located at Porte de Versailles conference centre in Paris on 23 – 26 October 2023.
The Radiator team will participate in the WBA Members-Only Sessions on 23 and 24 Oct, and the WGC EMEA Open Congress on 25 and 26 Oct. Backed with 20 years of roaming experience, Radiator team can help you deploy RadSec, OpenRoaming, In-Flight Connectivity, and IMSI Privacy with best in class security.
For more information about Wireless Global Congress EMEA 2023, please see the official event website: https://www.wirelessglobalcongress.com/wgc-emea-2023/
Network X event 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/
We extend an invitation to all WGC EMEA and Network X attendees to visit Radiator Software booth F19. Here, you can engage Radiator experts for insightful discussions on latest advancements in network authentication, WiFi and mobile convergence and how Radiator unifies RADIUS and Diameter infrastructure.
To schedule a meeting or simply ask a question, please leave a message and we will get back to you. See you in Paris!
Like we have written before in our blog, Radiator AAA Server Software is currently being used in many projects to replace Juniper’s Steel-Belted RADIUS that is now reaching the end of support. Of course at the same time, many FTTH service providers, ISPs and mobile operators are always searching for new options when they prepare their network infrastructure for the future.
One specific use case where we have seen a lot of demand for Radiator is the RADIUS authentication needed in mobile networks. In mobile networks, RADIUS protocol is used when there are private, organization-specific APN (Access Point Name) network paths in use. For example, critical communications such as emergency services often require this kind of network segmentation to secure their operations.
In VoLTE/4G networks, PGW/GGSN components in mobile networks make RADIUS queries to RADIUS server (such as our Radiator), and RADIUS server then authenticates and authorizes the end user to a specific APN network path - that can for example be an enterprise-related private network.
What we have been recently doing with many customers is the replacement of RADIUS servers and the related business logic in mobile networks. These have been done both with Radiator AAA Server Software and with the consultation of our technical team. At the same time, these projects are often combined with different accounting use cases, storing of CDR records etc.
When preparing for the future and taking the course to 5G networks, either RADIUS or Diameter interfaces will be used for similar use cases. Radiator, with extensive support of different TLS-based EAP methods, is of course prepared for this use case with 5G networks as well.
In case you are looking for a future-proof RADIUS and Diameter server for your mobile network, we are happy to provide more info - and discuss your use case. Just reach out to us at sales@radiatorsoftware.com and we can discuss further.
Modern SIM-based devices, like smartphones and tablets, are able to join and switch between different networks automatically. This is especially valuable to mobile operators who want to offload data from their mobile network to a nearby Wi-Fi network, because Wi-Fi connections are significantly cheaper to operate. It also enables Wi-Fi providers to monetize their Wi-Fi net- works and provide services in partnership with mobile operators. In addition, with use of OpenRoaming or other Wi-Fi roaming services, it also provides a way to expand the coverage of carrier Wi-Fi.
In busy locations with high volumes of mobile traffic like sports stadiums, shopping malls, public transport hubs and underground metros, SIM-based devices can automatically switch from mobile data connections to local Wi-Fi networks. Transferring the data traffic to Wi-Fi networks reduces the load on the mobile network, which improves the coverage and the user experience. In addition, using Wi-Fi roaming services, such as Orion Wi-Fi or OpenRoaming, can further reduce costs when carriers can use these additional services for Wi-Fi offloading.
SIM-based devices can also switch voice calls from mobile networks to Wi-Fi networks, and this kind of call is known as Voice over Wi-Fi. As with data traffic, switching traffic from regular calls to Wi-Fi networks can help carriers and operators to reduce the load on the mobile network, enabling better call quality and continuity.
When a SIM-based device automatically joins a Wi-Fi network or switches to another one, this is called Wi-Fi roaming. Wi-Fi roaming is used to maintain an uninterrupted data connection when the user moves from location to location, or when the current Wi-Fi connection is overloaded or when the signal is weak. In these situations as well, using OpenRoaming and other Wi-Fi roaming services can expand the coverage for mobile carrier.
Wi-Fi SIM-based authentication is essential to making these capabilities work. Before a device is allowed to join a new Wi-Fi network, it must be authenticated using the IMSI*. For this reason, Wi-Fi SIM-based authentication is supported by the latest Android and iOS mobile devices. However, there are still some security issues with this type of authentication. As a result, mobile OS manufacturers are now pushing for even better security on Wi-Fi networks and they require IMSI Privacy Protection with all new OS versions.
The Radiator SIM Pack for Radiator AAA Server Software makes it easy for operators to enable IMSI Privacy Protection. It is the key component needed for secure and seamless switching between mobile and Wi-Fi networks using SIM-based authentication. The Radiator SIM Pack also provides all the functions required for a 3GPP AAA Server.
IMSI privacy is a key feature of the Radiator SIM Pack, and it provides server-side support for permanent identity protection during Wi-Fi SIM-based authentication, Wi-Fi offloading and VoWiFi, resulting in a higher quality user experience. You can read more about Radiator SIM Pack and IMSI Privacy protection from our IMSI Privacy whitepaper.
In addition to this, Radiator provides also all the services and products needed when joining to Wi-Fi roaming services, such as OpenRoaming, or when connecting to mobile carrier infrastructure by using Diameter interfaces.
If you would like to know more about Radiator, SIM authentication, IMSI Privacy, joining OpenRoaming etc., and how we can help you in your use case, you can always contact our team at info(a)radiatorsoftware.com. Looking forward to hearing from you!
In many of our new deployment projects, we face the common question “How much CPU, RAM and disk space does Radiator need for x users?” While conservative estimates can be given, there is much more to this question than a simple figure.
The requirements of the system depend on the use case, backend, and implementation. In this blog post we will go over the variables and why it actually is misleading from us to give an answer to this question - but at the same time, we are always happy to help you with the hardware correct sizing.
There are major differences between the requirements for different authentication methods. The differences can be divided to two: Number of transactions per authentication, and number of interim-accounting transactions per session. One PEAP or EAP-TTLS request can consist of many messages, while a fixed-line authorisation has less transactions.
In reality, AAA servers are usually not the hold-up. Database latency is often the limit for AAA server performance. The database just does not respond in time when the load is high enough. In networking authentication, some use cases are read-heavy and some write-heavy on the database. To allow for better system performance, the database model should be optimised based on the demand for writes over reads or the other way around. What can and should be done is separate VMs for Radiator and the database. It is always better to run AAA server and database on separate servers.
Network design plays an important role in ensuring your Radiator setup is sized sufficiently. Radiator can be configured to run as a loadbalancer for other Radiator instances. While there also are other loadbalancer options, a setup loadbalanced with Radiator loadbalancer configuration has better throughput than one without loadbalancing.
In conclusion, there are many factors that affect the system performance, and sizing Radiator depends heavily on the use case and preferred architecture. However, a conservative starting point that we give customers is that each Radiator instance requires 1 vCPU and 0.5 GB RAM and it runs around 1000 TPS. This may heavily vary depending on the use case.
As for disk space, Radiator itself takes around 20 MB of disk space. This does not take into account requirements of the operating system and log data generated by Radiator. However, the Radiator logs can be shipped off to another log host machine to assure the Radiator host’s disk is not filled with log data.
Radiator AAA server is known for its flexibility when it comes to unique use cases. This flexibility comes from the variety of supported protocols, authentication backends and logging destinations that are available in Radiator AAA server as an off-the-shelf product. This blog post will dig deeper into Radiator integration with library management systems and the 3M’s SIP2 protocol.
Previous Radiator blog posts have gone over how network authentication works for enterprises and hotels. Today’s blog post will look at how Radiator can utilise existing library management systems to authenticate library Wi-Fi access for customers (often known as patrons). In its essence, Radiator will utilise patrons’ existing library card credentials for the authentications. Typically these credentials are used to loan and return books. This method has many benefits. First, it gives library patrons easy access to the internet without handing a common public password. Second, the internet access can be modified or disallowed based on patron status or information, for example age restrictions can be applied.
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. The original use case for this protocol was and generally still is automated self-check devices for loaning and returning library books. However, this protocol can also be utilised for network authentication within the library, which is where Radiator comes in.
Radiator has a specific authentication function for this functionality. In Radiator AAA server Reference Manual Section 3.93., the function
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.
Would you be interested in getting your library a stable, proven and affordable Wi-Fi authentication solution? Please contact us sales@radiatorsoftware.com for more information on both commercial and technical matters.
Testing the solution is also an option. We offer a 30-day evaluation licences for testing purposes and Radiator evaluation comes with thorough documentation and resources like well documented example configurations and our reference manual. To get started with a Radiator evaluation, please fill the form at our evaluation page.