Beer and Food in Vilnius

Got feedback from conference participants and at least one Finnish tax payer that they want to see more research coverage on beer and food. :) So even if we have been busy attending sessions, debugging eduroam and in various discussions, we have also been able to research the opportunities Vilnius presents for enjoying good beer and food.

Based on the background research done by Stig and Matti, I have managed to map already few places to enjoy good beer and food after heavy conference day. I will try to update this map during conference and all participants are welcome to contribute if they have clarifications or new places to be added.

Beer places in Vilnius, Lithuania


View Beer places in Vilnius, Lithuania in a larger map

Defining the Y Generation

It is sometimes hard to figure out what is the definition of X generation, Y generation or even millennials. Hannes Lubich's presentation in today's plenary clarified among others what Y generation means and what are the characteristics of this generation.

The interesting thing was that at least I was able to pick up few Y generation characteristics from myself even if I guess I belong more to the previous generation based on my age. Or maybe it is just that I want to find some younger Y generation characteristics in me. :)

Blogging at Terena Networking Conference 2010

You know that you have done too much Web 2.0 when people invite you to blog about events. This year I am once again participating in Terena Networking Conference and the conference organiser asked if I would interested to blog about the event. Since I am already hanging around here (currently in Juniper's meeting) and taking photos I accepted and here we are, part of Terena Networking Conference 2010 coverage.

To make sure that my time was efficiently used, instead of just watching presentations, blogging and drinking beer :) I am also both invited speaker, paper and poster presenter here, which should keep me busy doing those slides and later by presenting them.
My first presentation is about RadSec/RADIUS based roaming paper and the second invited one is about the Internet bus from Tampere, Netti-Nysse. The poster is about ICT SHOK Future Internet Testbed and I just managed to bring it to conference lobby before coming to this Juniper presentation.

And speaking of presentations, I really have to now upload some placeholders for compatibility testing purposes to the presentation system, so more coverage and even some nice photos about Vilnius will have to wait to the next post. Luckily they have a nice working eduroam Wi-Fi network here complete with both public IPv4 and IPv6 addresses.

What is eduroam and roaming?

A promotional eduroam video produced by Australia's research and education network (AARnet) explains the concept of eduroam and the benefits of federated roaming:



For you, it is possible to get this technology to your home organisation or even a company by utilising Arch Red products and services to bring your network and users as a part of eduroam or other community networks such as Wireless Tampere (Langaton Tampere).

Building a mobile eduroam access point with RadSec and OpenWRT

A mobile Wi-Fi access point is a very useful way to both demonstrate and extend existing community network coverage over any third-party broadband connections. The problem usually is how the authentication traffic can be transferred over Internet jungle and secured from eavesdropping and man-in-the-middle attacks. Often this is done by deploying VPN solutions such as OpenVPN, but a new IETF draft, RadSec, makes it possible to achieve same security and functionality without having to rely on the use of VPNs.

Figure 1: the mobile eduroam access point network architecture

It has been in my plans to write this article for a while now, but now finally Easter holidays gave the opportunity to finalise the configuration and some free time to write these configuration instructions. This blog post describes how you can build a mobile eduroam access point by utilising RadSec and a popular open source access point firmware called OpenWRT. The network architecture is presented in the Figure 1 above and the rest of the instructions follow below.

The first thing to do is of course install OpenWRT on your access point. There are several different OpenWRT supported access point models and the installation instruction vary between models and manufacturers. In this case I assume that you have alredy OpenWRT based access point installed and continue from the actual eduroam and RadSec configuration.

The base OpenWRT distribution does not come with all the software we will require so we need a working Internet connection to install some additional packages. The most important of these are the tools for time synchronisation (for certificate validity verification) and radsecproxy for RadSec functionality.

From the OpenWRT command line you can install the needed packages by giving the following commands:

# opkg update
# opkg upgrade
# opkg install radsecproxy
# opkg install ntpclient

I recommend rebooting the access point and verifying the correct time with date command. The default OpenWRT timezone is UTC so the time is likely to be hours off from your local time. You can change the timezone, hostname and remote logging address from /etc/config/system displayed below:

config system
        option hostname mobile-ap
        option timezone UTC
        # remote syslog server, we used the syslog configured to radsec server
        option log_ip 10.10.10.10

The wireless settings for eduroam are configured in /etc/config/wireless. The important thing to notice is that the RADIUS server (radsecproxy) will be run on the OpenWRT access point.

config wifi-device  wl0
        option type     broadcom
        option channel  5 
        option country  FI
        # REMOVE THIS LINE TO ENABLE WIFI:
        # option disabled 1

config wifi-iface
        option device           wl0
        option network          lan
        option mode             ap
        # in case you are already running eduroam in your organisation you might
        # want to consider different ssid to prevent causing denial of service for
        # your users
        option ssid             eduroam

        option encryption       mixed-wpa
        # as we use radsecproxy on localhost for converting RADIUS to RADSEC
        # the RADIUS server is the radsexproxy on localhost
        option server           127.0.0.1
        option port             1812
        option key              RadiusSecretHere
        option nasid            nas.id.here
        option wpa_group_key    600
        option ieee80211d       1

Radsecproxy is an open source implementation of the RadSec protocol. The RadSec protocol is essentially TLS-secured RADIUS over TCP making it more reliable and more secure for setting up connections over unreliable or unsecure networks (such as most Internet connections).

There are however few pre-requirements for configuring RadSec and eduroam:

• Home organisation must be part of the national eduroam federation and international confederation to have an access to eduroam infrastructure
  
• a RadSec capable server (either radsecproxy (also on server side) or commercial RadSec capable server such as Radiator)
  
• existing Certificate Authority (CA) for signing certificates for RadSec server and clients
  

In our company we already had Radiator RADIUS server and own CA configured so making certificates and server configuration was not very difficult. The client side (OpenWRT) configuration was done in the /etc/radsecproxy.conf file.:

listenUDP               127.0.0.1:1812
ListenAccountingUDP     127.0.0.1:1813

# Optional log level. 3 is default, 1 is less, 4 is more
LogLevel                3
#Optional LogDestinatinon, else stderr used for logging
# Logging to file
#LogDestination         file:///tmp/rp.log
# Or logging with Syslog. LOG_DAEMON used if facility not specified
# The supported facilities are LOG_DAEMON, LOG_MAIL, LOG_USER and
# LOG_LOCAL0, ..., LOG_LOCAL7

# Syslog is nice as you can direct it to external host via OpenWRT's
# system configuration
LogDestination          x-syslog:///log_daemon

tls mobile-ap-to-radsec-server {
    # In Arch Red we have multiple levels of CA servers with root CA and server CA
    # so the CACertificateFile is a bundle of root CA and server CA. The server CA
    # is the actual CA certifying both the server and mobile-ap certificates.
    CACertificateFile    /etc/certs/ca-servers-bundle-cert.pem
    CertificateFile     /etc/certs/mobile-ap-cert.pem
    CertificateKeyFile  /etc/certs/mobile-ap-key.pem
    # Optionally enable CRL checking
    # CRLCheck on
    # Optionally specify how long CAs and CRLs are cached, default forever
    # CacheExpiry 3600
}

# configuration for OpenWRT's local RADIUS
client 127.0.0.1 {
        type    udp
        # the secret between OpenWRT nas/hostapd and radsecproxy
        secret  RadiusSecretHere
}

# in the real configuration the IP address of the RadSec server
server 10.10.10.10 {
        type    TLS
        # the RADIUS shared secret between mobile-ap and RadSec server
        secret  SecretBetweenMobileAPandRadServer
        port    2083
        tls     mobile-ap-to-radsec-server
        certificateNameCheck off
        matchCertificateAttribute CN:/^radsecserver\.hostname\.here$/
        retryCount      3
        retryInterval   5
}

# The realm below is equivalent to /.*
realm * {
        # the IP addresses of the RadSec server
        server 10.10.10.10 
        accountingServer 10.10.10.10
}

I copied the necessary (CA and client) certificates manually to a directory /etc/certs I had created on the wireless access point file system. A larger deployment of RadSec access points would of course require either a scalable way to deploy and install client certificates or utilising only one client certificate for all mobile access points. Solving this issue can however be a topic for paper or some future blog post, when actual need arises. I did not yet configure the certificate revokation list (CRL) retrieval, but it is in my plans to document also this aspect.

Right, so now we have the actual configuration pretty much set up and we can start testing. Before running radsecproxy as a service I did a prelimanry testing by running it on OpenWRT console with the following command:

# radsecproxy -c /etc/radsecproxy.conf -d 3 -f

I was now able to check if the radsecproxy was able to connect to the home organisation RADIUS server and thus verify the radsecproxy configuration. After this was verified I enabled the radsecproxy permanently with the following command:

# /etc/init.d/radsecproxy enable

Then I rebooted the access point and verified once again that time was correct, radsecproxy was running as a daemon and wireless settings were correct before proceeding to eduroam authentication tests using my own TUT user account.

Like you have probably guessed, the testing was successful and I was able to now have my own mobile eduroam access point to be deployed wherever I may roam. :) Of the difficulties I ran into while doing this, I think the most difficult was once again setupping and configuring the X.509 certificates properly. The radsecproxy default was to check if the certificate CN contained the IP address mentioned in the server block and I had to check from the documentation how this check could be replaced with hostname check without having to use DNS hostname in the configuration block. The result is documented above there in the radsecproxy configuration.

RadSec as a technology felt very solid and functional for connecting devices and services to eduroam and the radsecproxy open source implementation was so well implemented and documented that I think it could be used as an official open source implementation to join to the eduroam federation with RadSec and this way as a roaming proxy replacing for example FreeRADIUS. Even the current radsecproxy implementation has better functionality set (for example dead realm marking) for eduroam proxy usage than the current FreeRADIUS has.

<commercial>Or then again, you can get a Radiator RADIUS+RADSEC server from us, Open System Consultants or some other reseller.</commercial>

Finding rogue IPv6 routers on Mac OS X

In one of the larger wireless campus networks there was a problem of an annoying host advertising 6to4 (2002) and fec0 prefixes to a network segment which already had an official IPv6 router. This is the same kind a situation as rogue DHCP server in IPv4 network. All traffic is sent to go through the advertising host and if that can either route or drop the traffic making IPv6 services slow or unusable. There exists few extensions for IPv6 to secure router advertisements and only accept proper ones, but those extensions are rarely implemented in the mobile devices.

So to find the owner of the misbehaving host, one option is to find the IPv4 address from the 6to4 prefix and inform NOC (Network Operations Center) about it. In 6to4 addresses the original IPv4 address is part of the IPv6 address so we can find out the corresponding IPv4 address this way (example IPv6 prefix 2002:c0a8:2a2a::/48):

% printf "%d\n" 0xc0
192
% printf "%d\n" 0xa8
168
% printf "%d\n" 0x2a
42

The IPv4 address corresponding to 2002:c0a8:2a3a::/48 prefix is thus 192.168.42.42. The IPv4 address is often enough to find the host and its owner, but in large wireless networks the IPv4 addresses may get reassigned so also the time of the problem must be recorded. Then the host and owner can be checked from the DHCP server logs or from the wireless network management system such as Airwave.

There exists also a way to identify the host faster and that is to find out its ethernet mac address. In IPv4 there is ARP, which is used to find out the mac addresses of the corresponding IPv4 addresses. In IPv6 the similar protocol is called Neighbor Discovery Protocol (NDP). The problem was where and how to find this information. In Linux it is possible to use ip utility for this (the addresses in these example are not related to the 6to4 culprit):

% ip -6 neighbor list
fe80::224:36ff:fe9d:c1dc dev br0 lladdr 00:24:36:9d:c1:dc router REACHABLE

It took me for a while to find out what I could use on Mac OS X, but the manual pages hinted that Mac OS X's IPv6 stack conformed to the NetBSD implementation documentation found at:

• http://www.netbsd.org/docs/network/ipv6/
  

The command needed for neighbor discovery protocol control on Mac OS X is called ndp. With this command it is possible to display and manipulate neighbor discovery protocol tables and find out the corresponding ethernet mac addressed for default router IPv6 addresses (listed with netstat -nr):

% netstat -nr
Internet6:
Destination                             Gateway                         Flags      Netif Expire
default                                 fe80::212:3400:9c56:7890%en1    UGc         en1
% ndp -a
Neighbor                        Linklayer Address  Netif Expire    St Flgs Prbs
fe80::212:3400:9c56:7890%en1    0:12:34:56:78:90     en1 23h59m9s  S  R

The more hardcore IPv6 specialists may read the ethernet mac address directly from the link level IPv6 address. The problem is that the link level address may not be always formed from the actual linklayer address so this method is preferable and also a bit more friendlier to user

eduroam(tm) expands in Japan

RADIUS based authentication roaming federation eduroam(tm) expands in Japan according to Terena's translated news item. The expansion is done in cooperation between the Japanese National Institute of Informatics (NII) and Livedoor, a Japanese provider of commercial WLAN services.

These kind of cooperation announcements give additional validation to Arch Red's vision on utilising eduroam(tm) tried technology to increase community network coverage through roaming instead of building overlapping Wi-Fi networks or trying to form only one dominating one.