Showing posts with label Radiator AAA. Show all posts
Showing posts with label Radiator AAA. Show all posts

Wednesday, November 13, 2024

Wifi Offloading POC with Radiator

 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.


  1. 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.

  2. 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.

  3. 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. 

  4. 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.


Tuesday, September 17, 2024

Chargeable User Identity - Billing and analytics with privacy

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 uses and benefits

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 deployment

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.

Want to know more?

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

Wednesday, August 28, 2024

Why 5G drives Wi-Fi offloading for operators?

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.

Solve coverage issues with existing infrastructure

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.

Wi-Fi has gotten better. Much better.

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.

5G and Wi-Fi 7: Better together

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.

Looking to deploy Wi-Fi offloading in your network?

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

Wednesday, June 19, 2024

How to speed up RADIUS authentication processing during peak hours with Radiator

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:

  • Split configuration into two separate files, one for authentication and one for accounting, and run Radiator as two separate running instances. This way there are two processes handling traffic with their own UDP buffers and backend dependencies that may even out the congestion. On Linux systems with systemd there are mechanisms readily available to help with that. More information: [How do I manage Radiator instances on a single host?].
  • Use a proxy instance to forward authentication and/or accounting requests to multiple worker instances (see first bullet). The requests can be spread out to worker instances so that request state is preserved (see [methods for load distribution and balancing] in documentation).
  • Within instances, use [FarmSize] to create a farm of server processes to add parallel processing of requests. Note: This is not compatible with many EAP protocols, such as EAP-TLS, EAP-TTLS, PEAP etc. This is because such protocols rely on authentication state being held within each server process, and it is necessary for all the requests for such protocols to go to the same Radiator process.
  • Incoming requests can be distributed from one or two proxying or load-balancing hosts to multiple hosts for processing.
  • Depending on use case, any combination of FarmSize, multiple instances per host and multiple hosts can be used together to enable more throughput. Separating processing on the Radiator side will create more separate connections to backends that may help even out backend load.
Additionally, the bottleneck might be the available resources
  • If the host is running other processes, make sure it has enough resources available for Radiator. The best would be to use dedicated hosts for each function.
  • If a virtualisation platform is used, make sure that it can provide the configured resources to Radiator virtual machines even during the peak hours when other vm's are running their peak loads.
  • Logging to external servers may cause some unneeded delays for Radiator. This can be mitigated by configuring Radiator to log locally, and then process and ship logs with a separate agent.
  • Outside of Radiator, performance of backends may be tuned depending on the backend itself. For example a database can be scaled up or replicated to multiple-server cluster. On the other hand, speeding up the database might be possible even without adding more hardware if queries can be optimised or suitable indexes created. For optimising backends, please refer to their respective documentation.
  • Running configuration or Radiator may contain some parts that can be optimised. At the end of this blog post, we tell a bit about our consultation services. 
How can we help?
 
In case you would like our assistance when tuning your Radiator and related infrastructure, please contact sales@radiatorsoftware.com. Our team of experts have a long experience on configuring Radiator, and also assisting with the best practices when integrating Radiator with existing or new infrastructure. 

Tuesday, December 19, 2023

Radiator 4.28 released!

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 usability improvements

  • Multiple logging improvements for easier debugging
  • AuthBy REST and SIP2 improvements according to customer feedback
  • Ready to use profiles for Linux firewalls: firewalld (Red Hat, Alma Linux, Rocky Linux) and ufw (Ubuntu, Debian)
  • New attributes ensuring interoperability

    New vendor specific attributes included in the standard dictionary:

  • 3GPP release 17 and 5G internetworking attributes
  • Wi-Fi Alliance (WFA) Passpoint release 3 Hotspot 2.0 attributes
  • Wireless Broadband Alliance (WBA) attributes, used especially in OpenRoaming (latest from Github).
  • New vendor specific attributes for Aruba, Juniper, Meraki and PaloAlto, and new Huawei dictionary and attributes
  • 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.

    Would you like to know more?

    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!

    Tuesday, May 30, 2023

    Radiator RADIUS for library Wi-Fi authentication

    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.

    Library Guest Wi-Fi Authentication

    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.

    AuthBy SIP2

    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 and its usage is explained. authenticates patrons based on their username and password, for example library card number and PIN code. 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.

    Want to know more?

    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.

    Thursday, April 20, 2023

    Radiator as Steel-Belted RADIUS Replacement

    Recently we have received many inquiries on whether Radiator AAA would be a good solution for replacing Juniper’s Steel-Belted RADIUS. As the aforementioned SBR has reached End of Engineering date in February, its support ending in September and with seemingly no alternative from the OEM, many operators are looking to replace their existing SBR setups with alternative established robust AAA solution. If you are among these companies, Radiator AAA is the solution for you.

    Why choose Radiator AAA?

    Known for its reliability and flexibility, Radiator AAA has been in the market for decades. Radiator is an actively developed and support AAA server with RADIUS and TACACS+ functionalities. With modules, Radiator AAA can also be complemented with Diameter relay, SIM-based authentication and other mobile network functionalities.

    Like SBR, Radiator AAA Server offers support for both Linux, Windows and Solaris installations with various different operating systems (See our Supported Platforms for more information. Radiator has extensive support for different databases and authentication backends (SQL-based, LDAP, AD etc.) as well as support for MFA solutions with TOTP capable authenticators and tokens (Google and MS authenticator, Yubikey, DIGIPASS etc.)

    The Radiator technical team consists of experts with vast experience in migration from other AAA solutions. We offer migration support and configuration assistance so you do not need to worry about meeting project schedule before SBR EoSL. Radiator can integrate with existing database and in nearly all cases no changes to schema are needed.

    Like Steel-Belted RADIUS, Radiator AAA has multi-vendor support and can be installed flexibly on different platforms on physical or virtual machines. With Radiator, you can compile your AAA use cases under one product: RADIUS, Diameter, TACACS+, SIGTRAN, you name it, we have it!

    Want to know more?

    For any questions or other inquiries about Radiator as SBR replacement, please contact sales@radiatorsoftware.com

    Tuesday, April 4, 2023

    Enterprise network authentication with Radiator

    Is your Wi-Fi password written on the conference room wall? Can your guests just plug a cable in and be connected to your enterprise network? These are situations where Radiator could help your network security. Once a company grows out of the founder’s garage, gains some employees and takes up an office space, this office in most cases needs a networking solution for both the company internal network and access to the internet for employees. At the beginning these might be resolved with one router with open Wi-Fi and a shared folder over the internet. However, companies should implement some form of security for their enterprise network. The goal for these implementations is that the right people have access to the right networks and other people do not. And once these basic needs are met, then flexibility and user experience should also be taken into account.

    Radiator as enterprise network AAA Server

    Enterprise network authentication is a bread-and-butter use case for Radiator. The key differentiator in the market for Radiator is flexibility. Radiator offers a variety of options for when it comes to what the users are authenticated against (SQL database, LDAP or Active Directory, REST etc.), as well as what hardware your enterprise uses for their network. Radiator also offers multi-vendor support for network devices.

    This is a basic setup which can be altered depending on your organisation’s needs. Multi-factor authentication with TOTP or HOTP can also be added to the solution for enterprises who want to add another layer of security to their network. Radiator supports a great variety of options for TOTP and HOTP implementations. On the other hand, Radiator can also be used for network device administration as a TACACS+ server (more information about this use case in our previous blog post). Another key differentiator for Radiator is access to active and competent support. Both Radiator email and telephone support grant you straight access to experienced Radiator developers so you can be sure your issues are resolved swiftly. While many company flagship RADIUS server products like Cisco’s ACS and Junipers Steel Belted RADIUS have been announced End-of-Life, Radiator is actively developed and supported.

    Managed solution for Wi-Fi Authentication

    Radiator also offers enterprise Wi-Fi authentication as a service: Radiator Auth.Fi. Radiator Auth.fi is a RADIUS based Wi-Fi authentication cloud service for authenticating network users and guests. It provides user authentication as a service for Wi-Fi, wired network and VPN. Subscription based cloud service works globally, one service covering all customer locations. Radiator Auth.fi also provides an easy way to connect to eduroam and govroam. The starting requirements for this service is RADIUS capable Wi-Fi controller. The starting solution enables simple username-password authentication for both employees and guests. This solution can be customised to include certificate authentication in collaboration with certificate provisioning solutions and PKIs such as for example SCEPman, Microsoft NDES, Intune. For more information about the managed solution for Wi-Fi authentication Radiator Auth.Fi, please see the previous blog post and our Radiator Auth.Fi product presentation.

    Want to know more?

    If you would like to know more about how Radiator can help your organisations enterprise network AAA needs, please contact our sales team via e-mail sales@radiatorsoftware.com or via our contact form.

    Monday, March 27, 2023

    Radiator team take part in IETF 116 in Yokohama

    We at Radiator take pride in applying the latest industry standards into Radiator. Part of these efforts include actively engaging with the relevant IETF working groups. Following up on the widely supported reboot of the RADIUS Extensions working group at IETF 115 in London, Radiator team is flying out to Japan to participate in IETF 116 in person. We’re especially looking forward to these two sessions:

  • RADIUS EXTensions (radextra)
  • EAP Method Update (emu)

    Meet the team

    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. If you’re in Yokohama, come find us at the and say hi! The point of contact is Radiator developer Heikki Vatiainen, who is available to meet at Pacifico venue. Everyone else, please drop us an email!

    Want to know more?

  • IETF 116 Yokohama
  • IETF 116 RADIUS EXTensions meeting
  • IETF EAP Method Update meeting
  • Our blog from IETF 115 highlights
  • info@radiatorsoftware.com
  • Monday, March 13, 2023

    Radiator SIM Pack 2.8 released! Major scalability improvement and other enhanced features

    We are pleased to announce the release of Radiator SIM Pack version 2.8. This new release contains major scalability improvement and many enhanced features.

    Scalability improvement and other enhanced features

    To make it easier to manage large installations and improve performance, Radiator 3GPP AAA Server now supports configuration with multiple parallel workers that use the same Diameter identity. This update was also reflected in earlier Radiator Service Provider Pack release. 

    In addition, Radiator SIM Pack has supported IMSI Privacy since release 2.5 and 2.8 release now adds support for certificate revocation and expiration notifications. For more info about IMSI Privacy features in Radiator SIM Pack, please see our new whitepaper.

    Also, customers using SIGTRAN will be pleased to learn that SIGTRAN stack upper layers have been rearranged to better support additional MAP dialogues. For more detailed changes, please see the Radiator SIM Pack revision history.

    Would you like to know more?

    If you like to know more about Radiator, the new release and how it can help you in your use case, you can always contact our team at info(a)radiatorsoftware.com - or fill out the contact form.

    Thursday, December 22, 2022

    Radiator 4.27 now available!

    We are pleased to announce the release of Radiator version 4.27!

    The main new feature in the release is support for EAP-TLS v. 1.3 - as specified in the RFC 9190. TLS v. 1.3 is available also for RadSec and for all TLS-based EAP methods. TLSv1.3 is disabled by default, but can be turned on by the customer when needed. TLSv1.3 will be enabled by default in future Radiator releases.

    At the same time, we continue to monitor TLSv1.3 interoperability with EAP-TTLS and PEAP. At the moment TLSv1.3 session resumption is disabled because of interoperability problems. To help with this, we are participating in IETF work that aims to solve the pending issues.

    In addition, significant update work for LDAP connection and TLS debugging has been made - as well as support for different Linux distributions.
     
    For other new features, enhancements, interoperability, and bug fixes, please see below.
     
    Selected compatibility notes, enhancements and fixes

    • Significant LDAP updates to connection and TLS handling.
    • Red Hat Enterprise Linux 9 and its derivatives are now supported.
    • Ubuntu 22.04 is now supported.
    • Session resumption is enabled for EAP-TLS with TLSv1.3 but remains disabled for the other TLS based EAP methods.
    • TLSv1.3 is supported by EAP-TLS, EAP-TTLS and PEAP but remains disabled by default.
    • TLSv1.3 is tested with RadSec and other Stream modules but remains disabled by default.
    • Radiator can log TLS key material to a file to allow fully decrypting EAP and Stream SSL/TLS sessions.
    • TLS handshake and state trace logging is now enabled for EAP and Stream modules, such as PEAP and RadSec, when Trace 4 (debugging) or PacketTrace is configured.
    • Radiator SIM Pack 2.7 and Carrier Pack 1.7, or later, are strongly recommended.

     

    Known caveats and other notes

    • TLSv1.3 remains disabled by default for TLS based EAP methods and Stream based classes, such as RadSec. TLSv1.3 testing reports are welcome.
    • Fix and enhance EAP-FAST. Requires Net::SSLeay 1.94 or later with OpenSSL 1.1.1 and later.

    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.


    Would you like to know more?


    If you like to know more about Radiator, the new release and how it can help you in your use case, you can always contact our team at info(a)radiatorsoftware.com

    Friday, November 4, 2022

    Radiator Service Provider Pack 1.8 released!

    We are happy to announce that Radiator Service Provider Pack (formerly known as Radiator Carrier Pack) has been released!

    The main new development is a new Diameter relay functionality. With Diameter relay, incoming Diametet traffic load can be distributed to multiple instances. The workers can be optionally made visible only as a single Diameter node to the rest of the Diameter nodes. This enhances Diameter performance when Radiator is used as 3GPP AAA server or in other use cases. For the relay functionality, we have also provided configuration examples, for Radiator SIM Pack, Radiator 3GPP AAA Server and Radiator Policy and Charging Pack.

    At the same time, new release contains performance enhancements for Diameter protocol and enhanced logging for Diameter request and answers messages. More info can be found out from Radiator Service Provider Pack revision history.

    Would you like to know more?

    If you would like to know more about Radiator Service Provider Pack and how it could be used in your use case, please contact our team at info(a)radiatorsoftware.com

    Friday, October 28, 2022

    Using Radiator as the flexible, powerful AAA for FTTH service providers

     
    Recently, we have seen a big rise in the number with projects where service providers are implementing new FTTH (Fibre to the Home) services – using different PON (Passive optical network) technologies, such as GPON, XG-PON1, XGS-PON. Based on different estimates for consumer services in the industry, high-performance fibre access is needed more than ever.

    Because of this, one the most common new use cases for Radiator AAA server software, and especially to our Radiator Service Provider Pack is the flexible and high-powered AAA for FTTH operators – that may also run fixed line and WiFi hotspot operations at the same time. With our flexible licensing options, these Radiator installations can be run either by service providers themselves, or they can use a managed service provided by a 3rd party.



    Often these enterprise use cases also include private APN (Access Point Name) service for their enterprise customers. We are happy to tell more about our experiences on providing Radiator to different environments and use cases.

    With the experience from a wide range of use cases, the key benefit of Radiator is flexibility in different network infrastructures – especially when integrating AAA with different technological generations. Readymade configurations are available, as well as support for different back-ends and logging and management solutions. As we are actively participating in different standardisation efforts, Radiator is always up-to-date with the latest industry practices and security developments.

    Would you like to know more? 

    We are always happy to help you with your use case. Please contact our sales team at sales(a)radiatorsoftware.com for more information.

    Tuesday, September 27, 2022

    Radiator Policy and Charging Pack - apply credit control for your prepaid and postpaid data plans

    One of our key products for service providers is Radiator Policy and Charging Pack.

    Radiator Policy and Charging Pack extends Radiator by allowing direct connections to your 3GPP infrastructure through Diameter interfaces - a protocol commonly used in telecommunication networks.

    The existing authentication, authorization and accounting features in Radiator are available for Diameter – RADIUS integration in Radiator Policy of Charging Pack. With this, examples of use include Wi-Fi offloading, integrating Diameter online and offline charging with RADIUS based infrastructure, integrating RADIUS accounting with Diameter online and offline charging - and much more.

    How it is used by our customers

    In many use cases operators and carriers have a need to expand their mobile data coverage with Wi-Fi hotspots and other Wi-Fi networks where authentication can be connected to their infrastructure with roaming. This way they can complement their mobile service with for example Wi-Fi offloading or Voice over WiFi  - at the same time keeping in track the data use of their subscribers.

    With its RADIUS to Diameter conversion, Radiator Policy and Charging pack enables you to apply credit control in your network using RADIUS accounting, both with prepaid and postpaid data plans. When using prepaid data plans, the credit control features will enforce that subscriber data is limited to the amount they have paid.

    Also, the credit control policies can be done in a way that the end of quota will be handled based on your business needs. For example, the customer network access can be throttled and directed to purchase additional data for renewed access. 

    On more technical level, the functionality is shown in the flowchart below. Please note, how Radiator Policy and Charging Pack is situated to integrate RADIUS and Diameter interfaces, and is connected to WiFi controllers or BNG devices and with Online Charging System (OCS) or with Policy and Charging Rules Function (PCRF).

    Flow chart showing the credit control functionality of Radiator Policy and Charging Pack
     

    As Radiator Policy and Charging Pack is highly extensible for different customer cases, we are happy to tell you more about how your use case can be implemented. In addition, it can be integrated with other Radiator products (such Radiator SIM Pack for EAP-SIM, EAP-AKA and EAP-AKA' authentication), and we are happy to share our expertise in this as well.

    Woud you like to know more?

    If you would like to know more about Radiator Policy and Charging Pack and how it can be used in your use case, please contact our team at info(a)radiatorsoftware.com


    Wednesday, August 10, 2022

    Cisco ACS is reaching end of life - Radiator has got you covered

    As announced already some time ago, Cisco will no longer support either the hardware or the software of their Access Control System (Cisco ACS) product line. If your network administration still runs Cisco ACS, it’s time to take action and upgrade it into a product with a clear future for updates and support. Radiator AAA Server software, often referred to as the Swiss Army Knife of AAA Servers, can pick up from there.

    As mentioned in a previous Radiator Cookbook post in 2018, Radiator AAA Server Software offers TACACS+ support and can be integrated with existing hardware to replace current solution’s TACACS+ and RADIUS functionalities. This means that Radiator can replace the authentication functions Cisco ACS did in your previous system. All that is required is an external database for user credentials that Radiator integrates to.


    Radiator is actively developed, with multiple updates per year, so continuous support for your solution is given. And most importantly, Radiator’s support team consists of experienced professionals who have developed and actively develop Radiator AAA, so your support requests are always handled by capable RADIUS and TACACS+ experts.

    These same professionals will be handling the transition work from ACS to Radiator AAA, if you so wish. Our technical team consists of experienced seniors with vast experience in enterprise, ISP, CSP and other AAA solution integrations and have done these transition projects even before the EOL was announced.

    Radiator, being a flexible AAA Server with TACACS+ support, can replace ACS’s TACACS+ and RADIUS functions. Radiator does not have the built-in database, but rather integrates to a customer’s existing database. If need be, we are happy this database solution through our partner. The flexibility of Radiator also includes multi-vendor support for NAS devices. This means that changing NAS devices will not be troubled by vendor lock-in.

    Want to know more?

    If you want to know more about Radiator AAA Server software as the flexible and supported replacement for Cisco ACS, do not hesitate to contact our sales team sales(at)radiatorsoftware.com.

    Thursday, July 14, 2022

    Radiator supports EAP-TLS 1.3

    One of the most used authentication methods for Radiator users is EAP-TLS. It is widely supported among wireless vendors and the support for EAP-TLS is needed for different certifications for wireless authentication. Radiator has supported different versions of EAP-TLS from the start. As we want to be in the forefront of industry standards, we are happy to announce that Radiator now supports EAP-TLS 1.3 - our team has also been involved in the standardisation work for EAP-TLS and other TLS-based EAP methods.

    What is new in EAP-TLS 1.3?

    The key feature in EAP-TLS 1.3 is increased privacy and security. Like the RFC document says “TLS 1.3 is in large part a complete remodeling of the TLS handshake protocol including a different message flow, different handshake messages, different key schedule, different cipher suites, different resumption mechanism, different privacy protection, and different record padding.” This new remodeled TLS handshake protocol ensures faster TLS connections as well as patches previous security errors TLS 1.2 had.

    Especially important in this new version for EAP-TLS is that no information about the underlying peer identity is disclosed. In other words this means that with EAP-TLS 1.3 the certificate of the user is delivered encrypted. In previous versions of EAP-TLS the client certificate was delivered without encryption, providing a possibility of tracking the users. This has been an issue for some users of EAP-TLS discouraging its deployment. To increase the security of your organization, Radiator configuration allows you to enable EAP-TLS 1.3 for devices that support it, while the earlier versions of EAP-TLS are still available for older devices. Radiator AAA Server Software and its modules are actively developed and updated to support state-of-the-art AAA security features. With the most recent Radiator SIM Pack patch, Radiator now supports IMSI Privacy as well - as one of the few AAA software vendors. So, in short, Radiator is committed to stay in the frontlines of all AAA security features at all times.

    Would you like to know more?

    While the support for TLS v1.3 in some operating systems varies, the Radiator implementation of TLS v1.3 and EAP-TLS is currently available in the testing branch of Radiator, but will be included in the next stable release as well. If ou are interested please test and give us feedback about the implementation.

    If you want to know more about Radiator and EAP-TLS 1.3, please do not hesitate to contact our sales team at info(a)radiatorsoftware.com. For full list of Radiator technical features, you can also visit the Radiator AAA Server Software product page.

    Wednesday, June 22, 2022

    Radiator FAQ page out now!

    You have asked, and we have answered. In the past years working with Radiator AAA, we have encountered hundreds of interesting questions in support e-mails and calls, RFPs and in other inquiries. We have collected some of the more frequently asked questions onto a FAQ page, which has recently been published. Go check it out at https://faq.radiatorsoftware.com!

    What topics are covered?

    The FAQ page contains answers to great variety of questions about Radiator AAA Server Software. Currently the FAQ covers our core product, Radiator AAA Server Software. At the first stage, the FAQ page focuses on Radiator AAA Server Software, our core product. We will gradually push updates and expand the FAQ based on feedback and the needs of our audience, to include our modules and general questions about Radiator Software as a company.

    What if my question is not in the FAQ?

    If you do not find the question that is on your mind on the FAQ page, however, please do not hesitate to contact us via e-mail to info (at) radiatorsoftware.com.

    Tuesday, May 24, 2022

    More flexibility to authentication with Ut interface and Radiator GBA/BSF Pack

    One of the carrier products in our Radiator product line is the Radiator GBA/BSF Pack. The main use case for this product has been providing the authentication for VoLTE supplementary services in carrier networks and Radiator GBA/BSF Pack has been in this use for many years. 

    In addition to self-provisioning VoLTE supplementary services (call forwarding, call barring, knocking, etc.) the same GBA/BSF functionalities can be used for proxying authentication to different services as well - such as Rich Communication Services or different services for IoT devices, for example.

    The main functionality in GBA/BSF is that after the initial authentication, end user authentication can be proxied directly to Application Specific servers via Ut interface. The basic architecture is shown on the diagram below.


    The Ut interface and authentication proxying can also be used for example in secure IoT authentication for different products, such as IoT devices that need to be authorised and authenticated. In this use case as well, the IoT device is supplied with SIM/eSIM that authenticates with carrier HSS. After the initial authentication, the later authentications can be proxied using the Authentication Proxy provided by Radiator GBA/BSF Pack.  

    Radiator provides flexibility when working with Ut interface

    For Ut interface, there is a wide range of different vendor specific implementations from device manufacturers. This causes differences in user equipment behaviour across vendors.

    This is where Radiator GBA/BSF shows its strengths: wide interoperability accommodating different user equipment within the same systems makes our Radiator GBA/BSF easy to integrate to different network environments. Radiator GBA/BSF’s implementation allows tweaking the configuration when unexpected behaviour is encountered and adjust accordingly.

    This focus to accommodate multiple vendor-specific implementations is what we have been doing in recent releases of Radiator GBA/BSF Pack - latest release in April 2022: providing more interoperability based on real observed behaviour of the devices. In this development work, the feedback from our live carrier customer has been extremely valuable.

    Would you like to know more?

    If you would like to know more about Radiator GBA/BSF and how it can be used in your use case, please contact our team at info(a)radiatorsoftware.com


    Wednesday, March 2, 2022

    In-flight Connectivity with Radiator

    For many of our customers we have been implementing WiFi roaming for different use cases: for example, carriers offloading traffic from their mobile network to WiFi hotspots or for providing VoWiFi (Voice over WiFi) calling to their customers.

    One case for Radiator is to implement in-flight connectivity for airline carriers, providing authentication to onboard WiFi that is connected by other means (such as satellite connection) to the internet.

    In this scenario, Radiator provides the necessary interfaces for WiFi roaming when subscribers of mobile operators are using their phones during the flight. With smooth WiFi roaming provided by Radiator AAA Server Software, end user devices can connect automatically to the in-flight WiFi network, and continue their use based on the roaming policy agreements between mobile operators and in-flight network operators.

    Some of the benefits for this kind of solution are:

    • For the airline carrier: More value for service as a provider of smoothly connected onboard WiFi as a part of their in-flight services.
    • For the end user: Better user experience when connecting to onboard WiFi.
    • For the mobile operator: New product opportunities for mobile operator roaming with airline onboard WiFi.
    • For the onboard Wi-Fi technology provider: A flexible product with Radiator that provides connectivity to carrier networks via different interfaces.


    At the same time, the solution with Radiator AAA server can of course be used in cruise ships and platforms where a smoothly run, commercial onboard WiFi is needed. 

    How does it work?

    On the technical side, Radiator AAA Server, combined with Radiator SIM Pack, is used to provide EAP-SIM, EAP-AKA and EAP-AKA’ authentication and connectivity to different HSS / HLR systems used by different roaming partner carriers and mobile operators. In these cases, the flexibility of Radiator helps to connect to various different systems needed via multiple interfaces.

    With this configuration, in addition to handling the authentication traffic, Radiator AAA Server also proxies the accounting traffic to policy enforcement or traffic monitoring solutions that can then use it to provide access to end users, based on their data plan or subscriber profile. The following diagram shows Radiator as part of the architecture for in-flight connectivity.


    Radiator provides EAP-SIM / EAP-AKA / EAP-AKA’ authentication and connecting to roaming partners HSS / HLR. 
     

    Would you like to know more?

    For commercial contact and more in-depth technical discussion, please do not hesitate to contact our sales team at sales(a)radiatorsotware.com . We are happy to discuss about your requirements, suitable license and configuration assistance needed for your service.


    Wednesday, February 23, 2022

    Radiator used for secure authentication in power companies

    For many years, Radiator AAA Server Software has been used in different utilities: from mobility solutions to water monitoring. In addition to this, Radiator is used more and more in power companies that require secure ways for authentication and accounting in their networks.  Radiator, being the most flexible AAA server software in the market, is easy to configure to these case kind of use cases.

    In some use cases, Radiator (and RADIUS protocol in general) is used to get accounting information from electric meters over the internet. Another use case, where secure access is critical, is the power system system management.

    Radiator providing secure authentication for power system management

    In power system networks, secure access and authentication to management systems is crucial. In times of cyber attacks, proper authentication methods ensure that only authorized personnel and equipment are able to manage power system equipment.

    The standard way to do this secure authentication is role-based access control (RBAC) for power system management. RBAC assigns human users, automated systems, and software applications to specific roles, and restricts their access to only those resources, which the security policies identify as necessary for their roles.

    As a part of being compliant to industry standards, Radiator also supports role-based access control (IEC 62351-8) in power systems and the related RADIUS attributes specified in the standard. 

    Would you like to know more?

    If you are interested in using Radiator in power system authentication and accounting, please do not hesitate to contact our sales team at sales@radiatorsoftware.com. Radiator, being the flexible AAA server in the market, may be just the solution for your authentication use case.