...
The following sections provide detailed information for the two roles eduroam IdP and eduroam SP, respectively.
The eduroam SP section explains the obligations for an eduroam SP and lists what should be taken into account in a wireless LAN deployment, and the set up of a RADIUS server for use in eduroam.
The eduroam IdP section explains the administrative obligations for an eduroam IdP, the set up of several popular RADIUS servers, and means to provision configuration details of supplicants to end users.The
Include Page | ||
---|---|---|
|
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
|
Include Page | ||||
---|---|---|---|---|
|
Include Page | ||||
---|---|---|---|---|
|
Include Page | ||||
---|---|---|---|---|
|
Testing and supporting end users
In order to test the eduroam setup from an end user perspective, please check out the Section How to offer support to end users. Also use this for helping end users get on to the newly-established eduroam network on campus.
Wired eduroam
There are use cases for securing access to a wired port in the same way as to a wireless Access Point. This use case is often not primarily intended for roaming though, as it is much more difficult for an incoming guest to locate a physical port in a building than it is to pick up a wireless broadcast signal from an access point. Much rather, an IdP who has already turned his users into eduroam users might want to benefit from the existing configuration in his end-users' devices to secure dormitories and similar locations, where finding the attachment point is less of an issue.
Connecting wired infrastructure to eduroam
The eduroam consortium is media-agnostic and welcomes wired eduroam. Wired eduroam works a lot like wireless - instead of an Access Point with 802.1X support, an eduroam SP needs a wired switch with that same 802.1X support. The SP configures it to authenticate the physical port users to the same RADIUS server that his access points do, too (i.e. the switch becomes a RADIUS client for the eduroam SP RADIUS server) - and that's all, the switch is then part of the eduroam infrastructure proper without further changes needed.
End user experience
Experience for end users is somwhat grim compared to wireless.The IEEE 802.1X revisions of 2001 and 2004 lack some of the features eduroam users are used to in the wireless world where IEEE 802.11 augments the missing features of IEEE 802.1X. The following text describes the shortcomings of versions prior to IEEE 802.1X-2010, because as of this writing, no single switch and/or supplicant is known which would support the new features of IEEE 802.1X-2010. Deployers of wired eduroam should be aware of the following differences for end users.
Network indication
When connecting to eduroam, users are usually made aware that the network they are connecting to is an eduroam network - simply by observing the SSID "eduroam" occuring on their computing device. In wired IEEE 802.1X networks, the concept of SSIDs does not exist. The user needs to plug in his device and try to connect in the usual way (using his supplicant, the usual EAP configuration and his eduroam credentials) - which will work on the configured eduroam ports, but not at any other network ports. eduroam Service Providers are advised to give clear indication which ports in a building are eduroam ports and which are not. One means to achieve this is by putting an eduroam logo besides the ports in question, or announcing the existence of eduroam on a building's wired ports on a signpost near the entrance to the building.
Info | ||
---|---|---|
| ||
With IEEE 802.1X-2010, so-called "Network Announcements" are supported. After plugging in the device, the user's supplicant is presented with a list of strings which identify the network. This feature provides the equivalent of SSIDs from wireless networks and can help end users identify usable wired network plugs. |
Support for multiple configurations
Computing devices typically allow multiple independent configurations for the wireless network interface; the configurations are usually seperated by the SSID they belong to. That way, users can configure their eduroam credentials for the "eduroam" SSID, and can have any number of other configurations for other networks at work or at home. In wired IEEE 802.1X, supplicants typically only allow "the" IEEE 802.1X configuration (likely due to the missing network indication as described above, which makes it impossible for the supplicant to determine which configuration is to be used for the wired connection). Users who have a need for multiple wired IEEE 802.1X configurations will probably be dissatisfied with that situation.
Info | ||
---|---|---|
| ||
With IEEE 802.1X-2010's network announcements, it becomes easy for supplicants to distinguish between different configurations. It is expected that, once IEEE 802.1X-2010 support on the attachment points becomes common, supplicant implementations will follow suit and enable storing and choosing different configurations per network identifier. This is implementation-specific per supplicant though, and support for this can and will vary. |
Encryption of payload
In IEEE 802.11 enterprise wireless, the end-user's network payload data is encrypted between his device and the Access Point. This happens automatically when using EAP and RADIUS, and is also highly desirable for the user's security because it prevents snooping of his private data by bystanders in the broadcast domain of the access point.
In wired networks, user payload is not broadcast, but is instead directed on a copper or fibre wire directly to the switch. This makes encryption of the payload a less pressing problem. Consequently, IEEE 802.1X does not foresee encryption of user payload data.
This is not particularly alarming because of the point-to-point nature of wires, but is a difference to the wireless use case deployers of IEEE 802.1X should be aware of.
Info | ||
---|---|---|
| ||
IEEE 802.1X-2010 includes support for a previously standalone feature called "MACsec" (previously IEEE 802.1AE). This feature allows to encrypt payload data on the wire between the end-user device and the switch. Implementations of supplicants and switches supporting this feature have not yet been observed in the wild though |
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 | 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
...
. |