What does Arch Red do?

Nowadays we are actually a company group, which consists of Finnish Internet Engineering Company Arch Red Oy and Australian security (AAA) software vendor Open System Consultants Pty Ltd. Since Arch Red Oy acquired Open System Consultants Pty Ltd, we have focused into developing products and services around Radiator AAA (authentication, authorisation, accounting) software as well as developing Radiator itself.

The Radiator products and services have become our primary focus and business. We have developed Radiator further, designed and implemented features, which make it even more suitable for operator and carrier use. This year we released our new NFV compatible Radiator product, Radiator VNF and have released already the second minor version (2017.1) of it. If you are interested about what Radiator VNF does, you should check this Good News from Finland article about us or see our Radiator VNF video in Youtube.

We do not post a lot to this Arch Red blog anymore, but you can find far more material and things what we do from our Radiator Cookbook blog.

verkkovieras.fi -- making enterprise Wi-Fi authentication easy

verkkovieras.fi for simple and secure federated Wi-Fi authentication

security by David Bleasdale

Verkkovieras is a Finnish word, which means network guest. Verkkovieras.fi is our cloud authentication service for organisation’s employee and guest network access control. The service also supports authentication roaming federations such as eduroam and roam.fi making the service an easy way to deploy and serve federated network access for employees, guests and partners.

We know that maintaining user databases and RADIUS servers for employee and guest access can be difficult, especially when there’s additional complexity such as federated roaming. With verkkovieras.fi we focused in building a service, which is easy to deploy and easy to use. We thought, designed, thought some more and improved our design to be as clean and clear as possible.

Easily deployed in any Wi-Fi network

To deploy verkkovieras.fi authenticaton service you only need RADIUS capable authenticated devices such as for example almost all Wi-Fi controllers and access points. The authenticating device, usually the Wi-Fi controller, needs to be able to communicate with our cloud based servers in Internet and that’s it -- only our server details and Wi-Fi networks need to be configured in the controller.

User account registration as easy as email

verkkovieras.fi registration screen in Finnish

Employees manage their user accounts themselves by requesting them from WWW page and after simple email-www page confirmation they activate their email address based user account. Account’s username is their email address and password is randomly generated string. We wanted to make sure that the network password is secure and on the other hand create a separate user account for network access. This was to keep more important or sensitive passwords such as Active Directory or other service passwords separate and safe. This way the employee cannot undermine the security by changing password to less secure or more sensitive one.

Federated roaming with a flick of a switch

Roaming federations and federated user access is even simpler, just select which federations and to activate or deactivate it. Your employees or visiting roaming guests are then able to roam free within federations and networks with same profiles they use for network access in your home network.

Easy guest user access or traditional vouchers -- you choose

Howard Lake: Sainsburys Active Kids vouchers

For guest user access there are two options, a simple time-limited guest user account for automated access and possibility to create and print more traditional time-limited guest user accounts before hand. Automated access means that the user account can be integrated for example with WWW page based authentication to provide guest short Internet access with just a click of a button on the authentication page. The traditional guest user accounts can be used like vouchers, the username and password must be entered on the authentication page or system dialog to get the access to network.

All this as a cloud service, ready to be deployed today

verkkovieras.fi architecture

We packaged all this in a redundant Amazon cloud based service distributed across two geographical regions, where we handle the difficult details such as scaling, server certificates, EAP methods (EAP-PEAP, EAP-TTLS, EAP-PWD) leaving you as a customer time to focus to your business and core functions.

If you are interested, contact Arch Red sales ( sales <at> archred.com ) for more details.

New blog about Radiator: Radiator Cookbook

Check out our new blog about Radiator -- Radiator Cookbook, where we share use cases, configuration recipes and roadmaps for success. :) We will likely concentrate our blogging there unless the blog post is clearly more about Arch Red's products and services (and even then, most of them are powered by Radiator).

What does Internet of Things mean for service providers?

Industry experts, vendors and conference organisers around the world are hyping about Internet of Things (IoT) and even more specific things such as Industrial Internet, but what does it all mean for network service providers, operators and enterprises?

To find answers to that question we must first select our viewpoint. In this blog post, we look IoT from the perspective of network service provider, for example, operator, enterprise or industrial IT department.  Let us start by looking first at the graph drafted accordingly to Gartner, IDC, Strategy Analytics, Machina Research, company filings and Business Insider Intelligence estimates.

According to business analysts and market research companies there will soon be a growing numbers of IoT devices entering into networks along the existing ones. The difference is that even when there has already been variation in tablets, smartphones and personal computers, variation will be far greater among the IoT devices. 

We may have sensor devices sending data only once in a day in our networks, and also devices sending high definition camera feed over the same network. If we take this a step further, in the old networks, all or most of the devices and sensors have been provided and maintained by a single vendor or service provider. In the future, in the same networks, there will a growing number of IoT devices that are controlled and maintained by different service providers and vendors. 

This means that IoT brings also new and escalated challenges for network service providers in addition to normal capacity challenges:

• managing and provisioning configurations to the ever growing variety of devices
• defining, creating and configuring subscriptions and subscription parameters to the ever growing variety of customers and devices
• handling security configurations in multi-service provider environment, separating service providers and networks from each other
• federating identity management instead of providing a single source identity management
• scaling the authentication, authorisation and accounting (AAA) infrastructure from single identity provider model to multiple identity providers model
• coping with multi-access (WiFi, LTE, 3G, 2G), multi-homing devices and their AAA
• connecting services and AAA with various IoT service providers

There are three key approaches to be considered in solving these issues:

• utilising and favouring open standard APIs, protocols and interfaces
• measuring and monitoring everything
• automating everything (for example, service/subscription provisioning, configuration provisioning, security, identity federation) 

Requiring and selecting products and solutions with open standard APIs, protocols and interfaces ensures that the components can be connected together regardless of the supplier. It also means that both the old and new components can be combined into common infrastructure without having to upgrade all other components at the same time. 

Decisions cannot be made without data. Measuring and monitoring the infrastructure, network, devices, sensors and nodes makes it possible to gather data about current situation. Measured data is used for historical or future trend analysis. Based on the data and/or analysis, automated decisions can be made and provisioned to the infrastructure components utilising standard interfaces and protocols. 

As the number of nodes, for example, devices, sensors, network equipment, in a network grows, automation becomes the only feasible way to cope with the amount of effort needed for provisioning, configuring, authenticating and authorising of the devices. Per customer and node, configuration must be created automatically based on the service provider databases. Access decisions and connection parameters for nodes need to be formed automatically based on the operator customer and network monitoring data. Customer service and customer configuration must be made so easy that the customers self-serve themselves without needing operator support resources.

By combining these three approaches, the objective for service providers is to do for the Internet service production the same that has already been done by automation in the factories -- automate as much of the actual production as possible, monitor and measure to gather data and make informed, even automated decisions based on the data.

Open, measured and automated service infrastructure is the best way to prepare for the challenges of Internet of Things and Industrial Internet. It provides cost savings and efficiency improvements even with the current customers. Together with our partners, we here at Arch Red are willing to help you to start migrating and improving your service infrastructure toward this goal. The technologies and components for this are already available and the work can be started by automating selected parts of the infrastructure without the need for big infrastructure changes.

There is no Free Wi-Fi, but there can be Sustainable Wi-Fi

Today Engadget reported that Free WiFi provider admits to making up 90 percent of its revenues. The company, Gowex, runs networks in 85 cities around the world (according to company WWW pages) offices in Madrid, Paris, London, Buenos Aires and Shanghai. The company claimed that it had developed a sustainable business model for free Wi-Fi based on the idea that company makes its revenues from partnerships with local governments, carriers with Wi-Fi offloading and from premium fees (i.e. selling premium user accounts).

Some may view this as a proof that Gowex's business idea and model did not work, but I would not claim that without looking into if they managed to get any revenues at all. Running company badly and falsifying revenues and accounting are very different things from the actual business idea and model not working.  I actually think that those ideas from where Gowex planned to get revenues are valid ones and they seem to have made real roaming deals with roaming brokers such as iPass, Boingo etc. These revenues could then be used to subsidise the service costs of running WiFi networks or related services, but naturally the company should get more revenues from the service it provides than the costs of producing it. And that is actually why I do not believe Free Wi-Fi exists.



The Free Wi-Fi is an illusion for consumers. Somebody always ends up with the bill. It may be the company, organisation or city providing or buying the Free Wi-Fi service out of hospitability. It may be an airport or a shopping mall deploying or buying a service for tracking customer movements or web surfing, but like many other free Internet services, Free Wi-Fi is not really free. You as a consumer may think that with Free Wi-Fi that you are still customer, but the reality is that the one providing and paying for Free Wi-Fi service, needs to get enough benefits and/or revenue from providing the free service to you and their benefit maybe the data about you.

Where Gowex was on a right is that providing Wi-Fi for free needs to be sustainable. The Wi-Fi network service needs to provide so much benefits for the one paying for it, that the payer is willing to cover the costs of running, maintaining and developing the network. Too often in many hospitability guest networks (hotel/conference Wi-Fi, company guest Wi-Fi) the deployed network may serve its users when it was first deployed, but the development of it (Internet bandwidth capacity, better radios) is neglected until enough users are complaining about it. In city-wide Wi-Fi networks similar kind of problems occur, when city-wide Wi-Fi is setup with development project money from government or EU without any plan how to cover the costs after the development project has ended.

Sustainable Wi-Fi networks should be planned so that they can be maintained and even developed with the revenues coming from organisations and companies benefitting from the network service, or from something measurable the network provides. There even exists a successful example of this kind of sustainable global Wi-Fi network concept -- eduroam (*).

In eduroam, universities, research institutions, government organisations and even cities have seen the benefits of joining their existing Wi-Fi networks via federated RADIUS authentication and providing this way a free Wi-Fi around the world for researchers, teachers and students. Every organisation deploys, maintains and develops their own network service with their own funding and shares it with the other eduroam organisations. There is no single vendor, service provider or organisation controlling anything. Instead, every vendor, service provider or organisation which is ready to fulfil the open requirements and standard interfaces is welcome to join or provide equipment or services to other eduroam organisations. There are not a lot of revenues or profits moved around, just normal network and authentication business for companies, but the benefits are clear for participants to justify the costs of basically running the Wi-Fi networks, which they are going to do anyway.

eduroam is real, sustainable Wi-Fi and I am hoping that we (Arch Red and Open System Consultants) may help in bringing its benefits also to wider audience in a very near future. eduroam itself still limits its use to universities and research organisations and networks and cannot unfortunately yet be used as a common global concept to provide sustainable Wi-Fi for all.



* eduroam is a registered trademark of TERENA. Arch Red and Open System Consultants are independent of TERENA".

Australian RADIUS experts and Finnish Internet engineers combine forces

The Finnish Internet engineering company Arch Red Oy expands its global operations by acquiring a controlling interest in Australian software company Open System Constultants Pty Ltd (OSC). OSC's main product Radiator RADIUS server is one of the most comprehensive RADIUS servers on the market. It is a base component for implementing both wireless (WLAN, 3G, 4G) and wired customer authentication solutions, which Arch Red has delivered to its operator and company customers in cooperation with OSC for several years.

Through this cooperation Arch Red gains access to OSC's active resellers in almost 50 countries and direct customer contacts with many operators and an even larger number of enterprises, universities and organisations around the world.

"By combining Arch Red and OSC, we can serve our existing and new customers even more efficiently and comprehensively than before." Arch Red managing director, Karri Huhtanen, explains and continues:

"In addition to developing Radiator further, we will also develop new customer services by offering, for example, ready-to-use RADIUS authentication solutions as subscription based cloud services.

For more information, please contact:

Karri Huhtanen

managing director, Arch Red Oy

+358 44 087 6546 www.archred.com

About the companies

Arch Red Oy is a Finnish Internet engineering company, which offers both products and services to service providers for wireless (Wi-Fi, 3G, 4G) user authentication, management and roaming. Arch Red also offers solutions and services for white-label Wi-Fi and community network user and guest authentication.

Open System Consultants Pty Ltd is an Australian software company. Its main product is Radiator RADIUS server software, which has customers in 180 countries and resellers in over 46 countries around the world. Radiator RADIUS server software is used in operator and service provider networks around the world for user authentication, provisioning and configuration management. Radiator RADIUS server is also a central component in deploying Wi-Fi network authentication and when Wi-Fi authentication is connected to the 3G/4G network authentication infrastructure.

What about CAs in mobile devices?

The Diginotar case encouraged finally most operating system and browser vendors to remove the DigiNotar CA from their trusted CAs. In case you are not familiar with the case, I suggest you check the following links where the case has been analysed more carefully:

• Google Online Security: An update on attempted man-in-the-middle attacks
  
• Operation Black Tulip: Fox IT's report on the DigiNotar breach
  
• F-Secure blog: DigiNotar hacker comes out
  
• (Sophos) Naked Security: Microsoft revokes DigiNotar certificates from Windows, Mac users still vulnerable
  
• (Sophos) Naked Security: Firefox 6.0.2 fixes yet more DigiNotar certificate fallout
  

In addition to the analyses you may also want to see a Black Hat 2011 presentation from:

• Moxie Marlinspike about SSL And The Future of Authenticity.
  

An executive summary of the would be:

One of the generally trusted certificate authorities (DigiNotar) failed to protect its services and was compromised. There now exists DigiNotar signed certificates in the wild free for attackers to use for several online and software update services including companies such as Microsoft, Google and organisations like Mozilla(Firefox). This means that if your operating system or browser certificate stores are not updated, your device is vulnerable to attacks based on these certificates. Attacks can for example install malware on your computer in the form of updates or collect your passwords for various services.

But since most of the operating system and browser vendors already reacted and I have installed updates I am now secure, right?

No you are not. While most of the operating system and browser have removed the CA certificate in question we still have a huge number of devices which may have those CA certificates installed -- the mobile devices. I have not yet received an update for my Android phone (Samsung Google Nexus S) and I think it is pretty much the same for all other mobile phone vendors too, Windows Phones, old and new S40, Symbian, Maemo phones and iPhones included. And it does not even stop to mobile phones, nowadays we have already tablets and all kinds of embedded devices, which may have the operating system included certs installed. Our mobile devices continue to be vulnerable to those leaked certificates and in most cases the users cannot even check or do anything to remove the certificates!

One glimmer of hope is that DigiNotar has not perhaps been in all mobile devices' CA certificate storage, but then again we still have Comodo there and now GlobalSign has stopped signing certificates and is checking their systems for intrusion. Another glimmer of hope is that maybe perhaps now industry will take a closer look at the current certificate authority structure and the system will be improved or fixed for example like Moxie Marlinspike suggests.

Microsoft recommends _not_ to disable IPv6

In IPv6 seminars you often hear the claim that Microsoft recommends not to disable IPv6. The source for this recommendation is not often presented, but now I did look it up for further reference and discussion with IT departments, which disable IPv6 from their computers.

The Argument against Disabling IPv6

It is unfortunate that some organizations disable IPv6 on their computers running Windows Vista or Windows Server 2008, where it is installed and enabled by default. Many disable IPv6-based on the assumption that they are not running any applications or services that use it. Others might disable it because of a misperception that having both IPv4 and IPv6 enabled effectively doubles their DNS and Web traffic. This is not true.

From Microsoft's perspective, IPv6 is a mandatory part of the Windows operating system and it is enabled and included in standard Windows service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, Microsoft does not perform any testing to determine the effects of disabling IPv6. If IPv6 is disabled on Windows Vista, Windows Server 2008, or later versions, some components will not function. Moreover, applications that you might not think are using IPv6—such as Remote Assistance, HomeGroup, DirectAccess, and Windows Mail—could be.

Therefore, Microsoft recommends that you leave IPv6 enabled, even if you do not have an IPv6-enabled network, either native or tunneled. By leaving IPv6 enabled, you do not disable IPv6-only applications and services (for example, HomeGroup in Windows 7 and DirectAccess in Windows 7 and Windows Server 2008 R2 are IPv6-only) and your hosts can take advantage of IPv6-enhanced connectivity.

-- Joseph Davies in Microsoft Technet article: http://technet.microsoft.com/en-us/library/2009.07.cableguy.aspx

Open System Consultants Ltd. and Arch Red Ltd. to enhance Radiator expert services via cooperation agreement

Open System Consultants, the maker of the "Swiss Army knife of RADIUS Servers" and Finnish Internet architecture expertise company Arch Red have signed a joint agreement to strengthen their cooperation in providing expert services based on OSC's Radiator RADIUS server.

Arch Red brings 8 years experience with Radiator, building RADIUS implementations for eduroam(tm) in Finland, its commercial application, the Wireless Tampere community network as well as for traditional Internet and mobile service providers.

The new closer cooperation between Open System Consultants and Arch Red provides new opportunities for both expert services and product development, Arch Red managing Director, Karri Huhtanen says.

Mike McCauley, OSC's managing director welcomes the synergies this new cooperation offers. With Arch Red's application experience, we can together provide the highest quality access solutions and technical support to our mutual customers.

Cloud Computing Business Models

As a part of my postgraduate studies I attended a TUT seminar course about cloud computing and chose to do my presentation about the cloud computing business models. Obviously this only covers only small part of them, but the presentation gives a general idea about what models are available and on what level of cloud computing solutions (IaaS, PaaS, SaaS etc.).

Cloud Computing Business Models

View more presentations from khuhtanen.

Feel free to comment or ask questions about the presentation and I will try to answer them in the comments.

Arch Red Guest Server v3.0 is coming

A new version (v3.0.0) of Arch Red's guest management software (Arch Red Guest Server v3.0) is nearing its release. A pre-release demo version (2.9.13) is already installed to our demo site. For more information about the demo and user credentials see:

http://www.archred.com/products/arch-red-guest-server/arch-red-guest-server-demo

Arch Red Blog is now IPv6 enabled

Yesterday we found out a way to enable IPv6 for our Google hosted services such as our English and Finnish blogs.

It seems that while Google only enables IPv6 on its on services by request of the IPv6 service provider or IPv6 block owner, it is possible to enable IPv6 on those Google hosted services which are offered under your own domain name.

Since Arch Red blogs are under our own domain name service (archred.com and archred.fi), we can allow them to be accessed also with IPv6 with a simple change in DNS by changing CNAME for them to point to ghs46.google.com instead of IPv4-only ghs.google.com.

Heikki changed our DNS already yesterday and you should be now able to read even this blog entry over IPv6.

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.

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