In July 2018, the South Africa eduroam NRO introduced support for RadSec and dynamic realm routing on the two federation-level RADIUS servers. Coupled together, these two things dramatically improve the efficiency and security of international roaming.
In order to take advantage of this development, identity providers need to make a small change in their DNS. Any institution that regularly has users travelling outside South Africa is strongly encouraged to make this change.
You need to add the following DNS NAPTR record for each realm your users might use:
example.ac.za. IN NAPTR 100 10 "S" "x-eduroam:radius.tls" "" _radsec._tcp.eduroam.ac.za.If you have more than one realm (e.g. students.example.ac.za and staff.example.ac.za), you need to create a separate NAPTR record for each realm your users might use, even if you're relying on sub-realm routing in your RADIUS configuration.
How you do this will depend on what DNS software you use:
If you have any questions or need assistance, please get hold of us.
Our monitoring system checks for NAPTR records and ensure they're correctly formatted.
Institutions that have enrolled in eduroam CAT can use CAT's "Check realm reachability" function to check that everything is working (see the dynamic connectivity tab).
TL;DR - the following is background for those who're interested; you don't need to understand this to take advantage of NAPTR, and can stop reading if you want.
Dynamic realm routing uses DNS records to determine the correct RADIUS server to route requests to.
RadSec is an extension to RADIUS that allows it to run over TCP secured by TLS/SSL. eduroam's implementation of this uses mutual certificate authentication to establish the trust relationship between the various roaming operators who're implementing it. This way we can connect directly to another NRO (bypassing the ETLR servers) and they can still have confidence that we're really part of eduroam.
The NAPTR record you create in DNS tells other eduroam NROs that your realm can support RadSec, and where to find more details. It points at the SRV record at _radsec._tcp.eduroam.ac.za, which in turn provides details of the South African FLR servers that support RadSec. This separation puts you in control of how your realm routes, and puts the operational details of the FLR servers under our control.
By making use of DNS, we can connect directly to the correct roaming operator rather than following the traditional eduroam hierarchy via the top-level RADIUS servers in Europe. This means more efficient paths, fewer points of failure, and lower latencies for authentication. Historically, if a South African user travelled to Kenya and used eduroam there, their authentication would route from Kenya up the East coast of Africa, through the Mediterranean, across Europe to Denmark and then back to South Africa along the West cost of Africa; with dynamic realm routing, we can take advantage of the much shorter East-African fibre route and connect directly from Kenya to South Africa.
Cross-border RADIUS between NROs that support it will be done using RadSec, but our FLR servers will still talk traditional RADIUS-over-UDP to your institutional identity provider. This means you do not need to understand how to implement RadSec on your own RADIUS servers in order to take advantage of the improved efficiency.
GÉANT have published a more comprehensive explanation of how this works.