- Advisory services
- Consultations
- Network and technology policies
- Network and technology service docs
- Using Jisc community
- Network and technology service docs
- Domain name registration
- How to sign up
- Janet Support Manual
- Janet CSIRT
- Back-up services
- eduroam
- Backup Web Hosting
- Certificate Service
- Connection timeline
- Eligibility
- Janet 3G Buyer's Guide
- Janet 3G eduroam interoperablity authentication methods
- Janet Mail Services
- Janet Network Charges
- Janet Reach
- Janet Videoconferencing Feedback results
- Primary connections
- Supporting Business Continuity
- Business and Community Engagement (BCE) using Janet
- Cost
- Interconnect connections
- Connecting student accommodation
- Customer-owned routing equipment
- Obtaining a Janet IP Address Range
- Terms for the Provision of the Janet Service
- Upgrading your existing bandwidth and Janet router
- Fault reporting
- IP address assignment
- Janet Aurora
- Janet Netsight
- Janet txt
- Routers
- Network set-up
- Guest access
- Network time service
- Training
- Contact
- Primary Nameserver Service
- Secondary Nameserver Service
- Vscene
- eduroam
- eduroam(UK) Policy
- Advisories
- FAQs
- Information for users
- eduroam Visitor Access service (eVA)
- eduroam Web Sites Accessibility Documents
- Information for tech admins
- Information for management and general enquirers
- Joining eduroam and terms of membership
- Technical Reference Docs
- Advisories
- 2021-04 Advisory: Android 11 configuration issues, geteduroam, server certificates
- 2020-11 Advisory: CA Certificate Validation on Android devices
- 2020-11 Advisory: Implications of MAC address randomisation on eduroam(UK) members
- 2020-07 Advisory: EAP server certificate considerations
- Advisory: EAP-PWD Vulnerability
- Advisory: Ending of RADIUS Accounting within eduroam(UK) (May 2016)
- Advisory: Filtering of Invalid Realms in Auth Requests sent to the NRPS
- Advisory: FreeRADIUS 2.1.10,11,12 Security
- Advisory: Impact of change of Certificate Service CA on eduroam Home service providers
- Advisory: Injection of Operator-Name Attribute at the NRPSs (Oct 2018)
- Advisory: Injection of Operator-Name attribute (July 2012)
- Advisory: Measures to Improve Stability of eduroam in UK
- Advisory: NAPTR records - Improving Efficiency of International Authentication through utilisation of RadSec at National Level
- Advisory: OpenSSL TLS Heartbleed Vulnerability
- Advisory: Tier 2 changes and WPA/TKIP obsolescence
- Advisory: Use at least SHA-1 for RADIUS server certificates (Apr 2014)
- Advisory: Use of Status-Server (Jul 2015)
- Advisory: WPA2 Key Reinstallation Attacks vulnerability, KRACK
- Advisory: Windows Mobile 8 and certificate verification (Apr 2014)
- Advisory: eduroam SSID broadcast policy announcement
Advisory: Use of Status-Server (Jul 2015)
Download as PDFStatus-Server (RADIUS Code Type 12 packet) uses RFC 5997 - http://www.ietf.org/rfc/rfc5997.txt - to deliver a method of one RADIUS server or client to know the status of an upstream or downstream server.
With a classic proxied RADIUS hierarchy, the RADIUS works in a 'fire and forget' UDP mode - if the server gets no response from the upstream/downstream server then it may mark it as dead/zombie and the next request from the NAS would be sent to another server in the proxy list...or the server may send it to the same remote RADIUS that did not respond until the NAS finally marks the RADIUS server as dead.
In either case, the NAS client does not know the real status of the server it talks to (it doesnt understand that the request may be having issues elsewhere) or the RADIUS server does not know. In this scenario it can be seen that a badly configured RADIUS end site (home IDP) with a local visitor from that site present at another site may induce an effect by failed logins with no responses that may mark National Proxies as dead within very few authentication attempts
Status-Server packets resolve this issue in that the RADIUS server, when it gets no response, can immediate fire off a Status-Server packet and see that the proxies are alive - just not responding to that request. This is far more efficient and minimizes 'zombie' proxy states. We have strongly advised using Status-Server from your RADIUS server to the National proxies, if your server supports such functionality, for several years - the National Proxies have been able to respond to such requests for many years.
However, new software on the National Proxies mean that we can now reciprocate these requests - and use Status-Server to check the status of your RADIUS servers. On the eduroam UK support server there are new options in the Create/Update RPS section (define/update your ORPS) that allow you to turn on the Status-Server flag for your RADIUS server.
Be aware, this function is not yet enabled on the NRPS (still in testing/beta phase) BUT when it does come live if your RADIUS server DOES NOT answer Status-Server queries then it WILL be marked as 100% dead and not be used(!!). Therefore ONLY enable this Status-Server function if you know and have verified that your RADIUS server can deal with status-server queries.
There will be some additional tools appearing on the support server that will enable verification of Status-Server capability - on the test page there will be a Status-Server check that will fire off Status-Server checks from each NRPS to each of your ORPS so you can check/verify that your configuration is correct (some RADIUS servers will need explicit configuration to allow Status-Server packets to be honored)
At this point in time, the following RADIUS servers work with Status-Server packets (latest software noted due to bugs/issues with previous versions)
FreeRADIUS 2.2.8
FreeRADIUS 3.0.9
RADIATOR 4.15 (with all latest patches!)
radsecproxy 1.6.6
