eduroam best practice

a few pointers to provide a better service for end users

firstly, ensure you have a policy in place on the RADIUS server to ensure that any local authentications MUST have a realm defined.

ie 'if SSID = eduroam , then User-Name must have @'

(this can be done in FreeRADIUS using unlang, in RADIATOR using a Handler or PERL hook, and ACS/NPS in the policy section)

what does this achieve/fix? read on...

well, if you allow local user authentication to eduroam without realm being defined, then your local users can authenticate to eduroam locally without their client being properly configured...so them .eduroam is working fine....its only when they DO go to other sites that they cannot connect (at which point they blame eduroam or the site that they are visiting). 

So, enforcing this policy ensures that your users ARE properly configured for eduroam....and will enjoy their roaming when they do travel

Secondly, dropping junk realms

You will need to check your logs for this as each site will find they have their own local typo issues (due to smartphone/tablet etc autocorrect).

You only need to send requests to the NRPS when there is a valid realm - otherwise the request should be dropped at the local RADIUS servers - valid realm is of the form  @[[string][dot]][string] where there is at least one dot with a string on each side of it and the strong may contain only the legal characters as per the NAI specification. basically, this means you can get rid of all the requests that have

1) no realm eg (@)

2) no dot in the realm (eg @realm

3) dots in succession (eg realm..com)

4) ends in a dot (eg realm.)

5) illegal characters (eg @test\realm)

6) realm that ends, contains or begins with whitespace (eg @realm .com, or @ realm.com)

further to this, you reject any typos of your own realm (eg @realm.ax.uk, @realm.uk.ac , @realm.a.uk)

(as previously said, you will need to look at the fail logs for your RADIUS server to see your best typos of the month)

sending valid traffic only the NRPS will ensure that they are dealing only with valid traffic...and not being loaded with invalid requests to be rejected/dropped (which cause back-pressure on outstanding requests in the proxy heirarchy)