Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Introduction

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 ID

...

Propose

...

901

...

VLAN for internet access – access to core routers

...

902

...

The Administrative VLAN of the hotspot (AP's; RADIUS; etc.)

...

903

...

VLAN with open SSID for giving information about the institute

...

906

...

VLAN reserved for administrative users

...

909

...

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

...

802.1Q Tag

...

Interface IP Address

...

DHCP Pool

...

What is accessible in this network

...

FE0.901

...

901

...

Some public IP address

...

N/A

...

FE0.902

...

902

...

192.168.10.254

...

N/A

...

AP's; RADIUS Server

...

FE0.906

...

906

...

10.9.6.254

...

10.9.6.0/24

...

administrators

...

FE0.909

...

909

...

10.9.9.254

...

10.9.9.0/24

...

eduroam clients

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.

Port

VLAN configuration
(T – Tagged; U – Untagged)

What is connected to it

1

U (902)

RADIUS Server

2-47

U (902) T (909)

Access Points

48

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)#interface fastethernet0/1
switch(config-if)#description RADIUS Server
switch(config-if)#switchport mode access
switch(config-if)#switchport access vlan 902
switch(config-if)#spanning-tree portfast

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)#interface fastethernet0/48
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:

Code Block
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.

Code Block
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
RADIUS/AAA section

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.

Code Block
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
broadcast (guest-mode).

Code Block
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:

Code Block
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)

Code Block
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
rekeying/reauthentication:

Code Block
dot1x reauth-period 300
VLAN interfaces

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.

Code Block
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

Code Block
 "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:

Code Block
encryption vlan vlanID mode ciphers aes-ccm

broadcast-key vlan vlanID change 600 membership-termination capability-change
Sample configuration

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:

  1. IP of logged in user that is operating in a malicious manner.
  2. IP is linked to MAC address [DHCP or ARP sniffing].
  3. Authentication session of this MAC is checked in logs [auth logs].
  4. 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

Include Page
eduroam SP
eduroam SP

...