The eduroam SP section explains general basics of wireless LAN deployment, the administrative obligations for an eduroam SP, and the set up of several popular vendor WiFi environments for use in eduroam.
Reference Campus Setup
Campus networks vary widely in such things as topology, equipment used, software, and so on. In order to assist a campus administrator in setting up eduroam on their campus, this section presents the implementation of a typical setup. It is hoped that this will allow users of different topologies and/or equipment to understand the necessary steps to take. Furthermore, in the appendices the same setup will be expanded for a number of other common types of equipment and software. Lastly, we are planning to provide these and future example configurations on the website http://www.eduroam.org.
For the reference network we use a typical set of network equipment consisting of:
- A Cisco Catalyst 3550 (or similar) switch.
- A Cisco Aironet AP-1200 Access Point.
- A laptop with Windows XP.
- A Radiator RADIUS server.
The network topology is as follows:
Figure 3.1: Network Topology (NEED TO RE_CREATE DIAGRAM PAGE 23??)
In this setup, wireless users are separated in different VLANs: VLAN906 for administrative users and VLAN909 for normal eduroam users. The next table describes each VLAN used in this document:
VLAN for internet access – access to core routers
The Administrative VLAN of the hotspot (AP's; RADIUS; etc.)
VLAN with open SSID for giving information about the institute
VLAN reserved for administrative users
VLAN reserved for 'normal' eduroam users
Table 3.1: VLAN description
The next table describes the IP configuration for the router sub-interfaces and what networks are configured for each VLAN:
Interface IP Address
What is accessible in this network
Some public IP address
AP's; RADIUS Server
Table 3.2: Router Configuration
Configuring the Ethernet switch for eduroam
In order to gain access to the Internet the configuration of the Ethernet switch needs to be changed. You must create a VLAN in which the Access Points will be placed, and provide it with the correct IP-address and gateway information. This can be done with the commands described below.
The next table describes the VLAN associated with each Port of the switch and what equipment will be connected to that specific port.
What is connected to it
U (902) T (909)
U (901) T (902; 909)
Central Ethernet Switch
Table 3.3: Ethernet Switch Configuration
First configure the port where the RADIUS Server will be connected and put it on the Administrative VLAN:
switch(config-if)#description RADIUS Server
switch(config-if)#switchport mode access
switch(config-if)#switchport access vlan 902
Then configure all switch-ports that will connect Access Points for the VLAN's that users and Access Points can have access to (in trunk mode). At a minimum configure the administrative VLAN and the VLAN where authenticated users will be placed:
switch(config)#interface range fastethernet0/2 - 47
switch(config-if)#description eduroam Access Points
switch(config-if)#switchport trunk encapsulation dot1q
switch(config-if)#switchport trunk native vlan 902
switch(config-if)#switchport trunk allowed vlan 902, 909
switch(config-if)#switchport mode trunk
The uplink can be defined with:
switch(config-if)#switchport trunk encapsulation dot1q
switch(config-if)#switchport trunk native vlan 901
switch(config-if)#switchport trunk allowed vlan 901, 902, 909
switch(config-if)#switchport mode trunk
The following equipment was used for this section:
Cisco AP 1200 Series (802.11g Radio).
The configuration examples used in this document were tested and made on a Cisco Series 1200 with an 802.11g Radio Module and with the following Cisco software:
IOS Version: Cisco IOS Software, C1200 Software (C1200-K9W7-M), Version 12.3(8)JA2, RELEASE SOFTWARE (fc1) Bootloader: C1200 Boot Loader (C1200-BOOT-M) Version 12.2(8)JA, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
Setting the Name and IP address
First, an IP address on the BVI interface (the IP address that this Access Point will have for accessing
resources like the RADIUS server) needs to be configured. Also a unique name for this Access Point (ap1200)
will be configured.
ap#configure terminal ap1200(config)#hostname ap1200 ap1200(config)#interface BVI 1 ap1200(config-if)# ip address 192.168.10.200 255.255.255.0
In the authentication, authorisation and accounting configuration parameters (AAA), at least one group needs to
be defined (radsrv), which will be assigned later for the several AAA operations. More groups can be defined if
needed for various purposes; one for authentication, another for accounting, and so on. In this example the
RADIUS server has the IP address 192.168.10.253.
ap1200(config)#aaa new-model ap1200(config)#radius-server host 192.168.10.253 auth-port 1812 acct-port 1813 key <secret> ap1200(config)#aaa group server radius radsrv ap1200(config-sg-radius)#server 192.168.10.253 auth-port 1812 acct-port 1813 ap1200(config-sg-radius)#! ap1200(config-sg-radius)#aaa authentication login eap_methods group radsrv ap1200(config)#aaa authorization network default group radsrv ap1200(config)#aaa accounting send stop-record authentication failure ap1200(config)#aaa accounting session-duration ntp-adjusted ap1200(config)#aaa accounting update newinfo periodic 15 ap1200(config)#aaa accounting network default start-stop group radsrv ap1200(config)#aaa accounting network acct_methods start-stop group radsrv
Configuring the SSIDs
For each SSID one dot11 ssid <SSID NAME> must be configured. In this section the default VLAN for the SSID
will be configured as well as the authentication framework, the accounting and, if desired, the SSID to be
ap1200(config)#dot11 ssid eduroam ap1200(config-ssid)#vlan 909 ap1200(config-ssid)#authentication open eap eap_methods ap1200(config-ssid)#authentication network-eap eap_methods ap1200(config-ssid)#authentication key-management wpa optional ap1200(config-ssid)#accounting acct_methods ap1200(config-ssid)#guest-mode
More SSIDs can be configured. An open SSID for giving information about the institution and/or how to
connect to the eduroam SSID:
ap1200(config)#dot11 ssid guest ap1200(config-ssid)#vlan 903 ap1200(config-ssid)#authentication open ap1200(config-ssid)#accounting acct_methods
The Radio Interface
Now the configured SSID's will be mapped to the radio interface, and it will be specified what ciphers will be
used/allowed on each VLAN. If dynamic VLANs are planned, the ciphers for those VLANs must also be
configured even if there is no direct mapping on any SSID (this example shows the usage of the VLANs 906
and 909 for eduroam users)
ap1200(config)#interface Dot11Radio 0 ap1200(config-if)# encryption vlan 906 mode ciphers aes-ccm tkip wep128 ap1200(config-if)# encryption vlan 909 mode ciphers aes-ccm tkip wep128 ap1200(config-if)#ssid eduroam
To bind extra SSID's the previous command, for each SSID to be bound, needs to be repeated.
The following command sets the maximum time (e.g. 300 seconds, which is recommended) for
dot1x reauth-period 300
For each VLAN to be used for wireless clients, two virtual interfaces need to be defined: one on "the air"
(DotRadio) and another on the "wire" (FastEthernet) then they need to be bridged together with the same
bridge group. These VLANs are always tagged with the proper VLAN identifier.
An administrative VLAN needs to be configured as well (for maintenance/management and
authentication/accounting traffic). This VLAN is usually untagged (the command defining the VLAN has to be
suffixed with the keyword "native") and belongs to bridge-group 1. The Radio virtual interface for this VLAN
does not need to be defined since the default will keep the physical interface (Dot Radio 0) in bridge-group 1.
Because VLANs can be from 1 to 4094 and bridge-groups from 1 to 255, it is not necessary to have the same
bridge-group id as the vlan id.
ap1200(config)#interface dot11Radio 0.903 ap1200(config-subif)#encapsulation dot1Q 903 ap1200(config-subif)#bridge-group 3 ap1200(config)#interface fastEthernet 0.903 ap1200(config-subif)#encapsulation dot1Q 903 ap1200(config-subif)#bridge-group 3 ap1200(config)#interface dot11Radio 0.909 ap1200(config-subif)#encapsulation dot1Q 909 ap1200(config-subif)#bridge-group 9 ap1200(config)#interface fastEthernet 0.909 ap1200(config-subif)#encapsulation dot1Q 909 ap1200(config-subif)#bridge-group 9
The multiple (dynamic) VLAN assignment
The example configuration above did not configure dynamic VLAN assignment. Availability of this feature varies between models of the 1200 Series, so please exercise caution when procuring if you wish to make use of this feature. If multiple VLANs are configured on the Cisco AP, it is mandatory to associate each SSID to at least one VLAN, otherwise the Access Point will not activate the SSID's. It is possible however, to put different users who are connected to the same SSID (e.g. eduroam) on different VLANs based, for instance, on the user profile. To activate this feature it is necessary to enter
"aaa authorisation network default group radiusgroup"
in the Access Point's configuration. The AP then gives priority to the VLANs returned by RADIUS over the ones statically associated with the SSID. This enables the feature dynamic VLAN assignment.
Cisco's Access Points require that two virtual interfaces (a radio and an Ethernet port interface) are configured for each VLAN. If, for example, four VLANs are to be used for eduroam users (for students, admin staff, teachers and visiting eduroam users from other institutions for example) then it is necessary to define one Dot11Radio0.vlanID, and one FastEthernet0.vlanID, and ensure that both have the same encapsulation dot1Q vlanID and the same bridge-group for each VLAN.
Two commands that are also needed are the below, otherwise the access point will not change the user to the received VLAN:
encryption vlan vlanID mode ciphers aes-ccm broadcast-key vlan vlanID change 600 membership-termination capability-change
The required configuration can be downloaded as a file fromhttp://www.eduroam.org/downloads/docs/eduroam-cookbook-scripts.zip. You must then amend the file as indicated by the comments in the file, and then copy and paste the commands into the Access Point in configuration mode (telnet or console access).
3.3 Operating the Infrastructure
3.3.1 Regular safety precautions
Everyone is responsible for their own network. It is not in the scope for this document to describe regular network or system security measurements. Local "best current practices" for the network and system design should be followed in any case.
3.3.2 Tracking malicious users
If the requirements of the policy are followed, it should be possible to provide sufficient evidence to government agencies to allow them to pinpoint a malicious user, thereby protecting the service provider. The requirements are:
- Keeping authentication logs.
- Keeping a DHCP (or even better an ARP) sniffing log.
- Keeping clocks on time with NTP.
The tracing chain is:
- IP of logged in user that is operating in a malicious manner.
- IP is linked to MAC address [DHCP or ARP sniffing].
- Authentication session of this MAC is checked in logs [auth logs].
- timestamp of authentication and realm is extracted.
From this chain the realm of the offender and the time of login are known. This should be provided to government agencies when required. For example, the information could be: the malicious user is someone from restena.lu who logged in at April 1, 2007, 12:01:45.3221.
Note well: the eduroam service definition document only obliges the Identity Provider and FLR infrastructure to keep logs of all authentications that took place and maintain a synchronised time source. It is in the best interest of a Service Provider to keep sufficient log information themselves though to make sure that the link in steps 3 and 4, above, can be made to trace a user login efficiently. However, even if the SP does not keep the data, it is possible to retrieve the information from FLR logs if need be.
The eduroam operations team can link the realm to a physical point of contact (home federation operator). This federation contact can find the institution, and then in turn the user name of the offender, using the IdP logs with the precise login timestamp that was extracted above.
Note: The User-Name attribute may be obfuscated with an anonymous or even forged outer identity, so it can't be used to reliably identify the individual on the service provider's side. The only reliable User ID is with the IdP.
For the record, the points of the eduroam service definition deliverable DS5.1.1 in question are:
6.2.1: technical contact for federation
6.3.1, Confederation member servers, Bullet 5: logging of authentication attempts
6.3.1, Confederation member servers, Bullet 2: reliable time source
6.3.2, Service Providers, Bullet 2: sufficient layer-2 to layer-3 logging information
6.3.2, Identity Providers, Bullet 4: logging of authentication attempts
Formally, some of these requirements are signed by the federation but affect the institutions, and so should also be re-iterated in the national policies to make them binding for participating institutions. A formal nomination of technical contacts for each institution within a federation is also recommended. For example, Appendix B in DJ5.1.3,2, the national federation policy BCP therefore has sections:
- 4: Logging
- 6.2: Security contact nomination