ICT SHOK Future Internet Testbed Architecture v2.0 published

Together with CSC, TUT also had a poster about ICT SHOK Future Internet Testbed here at Terena Networking Conference. Earlier we had only few printed copies of the testbed architecture document available, but now the same document is also published in the Internet at address:

http://www.futureinternet.fi/publications/ict-shok-future-internet-testbed-architecture-v20-web-version.pdf

The central idea with our testbed is that instead of building yet another testbed, we will combine existing and new services into a concept, which is supposed to grow and evolve serving various research programs and cooperation both in Finland and abroad.

If you are interested to learn more about our concept, check the architecture specification or contact either me or CSC's Jari Miettinen or Pekka Savola.

Debugging eduroam at TNC2010

Yesterday Matti was having trouble with Helsinki University user accounts and the eduroam network here at TNC2010. Together with few eduroam guys (Stefan Winter and Miroslav Milinovic) and Heikki Vatiainen from our company we tried to find out why the authentication process did not seem to go through. What made it harder was that for example Radiator does not log enough information about failing authentication process unless it clearly ends in success or failure. Increasing log level to debug levels of course helps and we were able to see that the Helsinki University RADIUS server did send response messages to authentication requests even if the process did not go through.

Other servers in Finland worked fine (I have been able to use eduroam the whole time with my TUT accounts) and only difference we first found was that Helsinki University certificate was bigger than the ones in some of the working organisations. This lead us to suspect RADIUS message fragmentation problems somewhere in between European Top Level RADIUS and Matti's device. We then remembered the one Radiator configuration directive, which we found was missing from Helsinki University RADIUS server configuration.

Adding EAPTLS_MaxFragmentSize 1024 solved this problem so if you are having similar problems with eduroam and your home organisation is running Radiator RADIUS, we suggest checking at least this setting found in Radiator manual:

EAPTLS_MaxFragmentSize

For TLS based EAP types such as TLS, TTLS and PEAP, this optional parameter specifies the maximum size in octets permitted for each TLS message fragment. Defaults to 2048, but many EAP clients, routers and wireless Access Points have limitations that require EAPTLS_MaxFragmentSize to be set as low as 1000 or less. Setting this number too small can result in excessive RADIUS request round trips during EAP TLS authentication, slowing down the authentication process. Setting this number too large can result in failure to complete TLS authentication for some types of clients and devices.