ISP Project

FIXME

Wen Xu Xu Zhao Josep Puigdemont Karthigeyan Reddy

S TOCKHOLM 2004

Contents
1 Topology 1.1 The ISP Core Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 The Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer access 2.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Extra service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Services 3.1 Routing with OSPF 3.2 DNS . . . . . . . . 3.3 DHCP . . . . . . . 3.4 WWW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 2 3 3 4 4 4 4 4 5 5 6 7 7 7 8 8 8 8 8

Selected service: RADIUS 4.1 Background . . . . . . . . . . . . . 4.2 Setup . . . . . . . . . . . . . . . . 4.3 Installation . . . . . . . . . . . . . 4.4 Conguration . . . . . . . . . . . . 4.5 OpenSSL . . . . . . . . . . . . . . 4.6 Testing . . . . . . . . . . . . . . . . 4.6.1 Access Point . . . . . . . . 4.6.2 FreeRADIUS . . . . . . . . 4.6.3 XP Client (Supplicant) Setup Lessons learned

List of Figures
1 2 3 Network Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802.1X on 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open Source solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 6 6

List of Tables
1 2 3 4 ISPs Core Networks values . . . Area Networks values . . . . . . Area Networks values (Ethernet) . Area Networks values (wireless) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 3 3

Introduction
This paper describes our ISP Project (FIXME1 ), and how we congured and prepared all services to work together. For this we set the goal for our ISP to provide the basic services to the whole Sweden. The ISP should provide services to private users as well as for corporations, although the implementation was only for the former.

Topology

Our ISP has been assigned the network 10.14.0.0/16, but although for this project well hardly run out of addresses, we still decided to rationally split them, instead of using, for instance, a class C network for each of our networks. As well describe later, we used subnetting for all our networks, and it was done more for practicing this rather than for a real necessity.
10.0.0.0/24
Lab Network

.114 .1

R1 ix ns.fixme.lab 10.14.0.0/28 .3

ISPs Core Netwok

.2 R2 hugin .33
Acc ess

Area Network

.34

R3 munin ns2.fixme.lab 10.14.0.32/27 .36

el Wir

ess

.35 .126 .62 uppland01 R4 ns.uppland01.fixme.lab 10.14.1.0/26 .2

H02

W01

10.14.1.64/26

R5

.65

Access Network
.1
H01

Access Network

Figure 1: Network Layout

1.1

The ISP Core Network

The topology is the same as suggested in the ISP project assignment, and it is shown in Figure 1. We have one interface of our Internet eXchange (IX) computer connected to the lab backbone, and the other connected into our internal backbone, which we called ISP Core Netowrk, which is a /28 IP
1 The name of our ISP has a funny story. When we rst met, we didnt want to spend time on naming our ISP, so we gured that someone would come up with cunning name before presenting the paper with the ISP project proposal, and instead of leaving the space for the name empty in the document, we put the string FIXME, which is commonly used in programming, indicating that it is something to be xed. What happened is that we simply forgot about it, and we handed in the document without actually having decided a name. Its not a very nice name for an ISP, but the good side is that it turned out that we didnt have to spend time to make a decision about the name :-)

      

        

  

C1

network where routers would probably connect different parts of the country. That network is composed of routers R1, R2 and R3 in Figure 1. We though that we could also have a computer on that network acting as a NAT gateway and rewall for a demilitarized zone (DMZ) where we could host our web, mail, DNS and other services, which is common practice, but we discarded this for lack of computers and time. Table 1 provides with the values for this network. Network First host Last host Broadcast Netmask Total hosts R1 (ix) R2 (hugin) R3 (munin) 10.14.0.0/28 10.14.0.1 10.14.0.14 10.14.0.15 255.255.255.240 14 10.14.0.1 10.14.0.2 10.14.0.3

Table 1: ISPs Core Networks values

1.2

The Area Network

The purpose of the area network is to connect all access routers of each area into the same network. We called access router those routers that are directly connected to the end customer. Since Sweden has 25 Landskap, and assuming one access router for each Landskap, then we would do ne with a /27 network (30 hosts). We named our example access router as uppland01. The Area Network is composed of computers R2, R3 and R4 on Figure 1. We chose to name those routers hugin and munin2 . Table 2 provides with the values for this network. Network First host Last host Broadcast Netmask Total hosts R2 (hugin) R3 (munin) R4 (uppland01) 10.14.0.32/27 10.14.0.33 10.14.0.62 10.14.0.63 255.255.255.224 30 10.14.0.33 10.14.0.34 10.14.0.35

Table 2: Area Networks values

Customer access

Each private customer (customer) accesses the Internet via what we called Access Network, which is an Ethernet LAN congured to be a /26 IP network. The default gateway, or access router as we named it, on the Access Network (R4), also provides IP conguration for the hosts via DHCP. Costumers have
2 Hugin and Munin are two scandinavian mythical creatures representng the thought the memory respectively, we thought they made good names for our routers and secondary DNS server.

no restrictions on Internet access, i.e.: no blocked ports whatsoever. Table 3 provides with the values for this network (10.14.1.0/26). Network First host Last host Broadcast Netmask Total hosts R4 (uppland01) H1 (h01) H2 (h02) ... H61 (h61) 10.14.1.0/26 10.14.1.1 10.14.1.62 10.14.1.63 255.255.255.192 62 10.14.1.62 10.14.1.1 10.14.1.2 ... 10.14.1.61

Table 3: Area Networks values (Ethernet)

2.1

Limitations

One of the limitations with this conguration is that a bad customer could manually congure its own IP address, which could be a duplicated from one that the DHCP server would have normally assigned, thus confusing all the hosts on that network about which link address belongs to that ill congured IP address (and possible DoS). Another problem is eavesdropping on that network, notice though that this could be solved by using a switch on the access network.

2.2

Extra service

As an extra service, the access router is also congured to be a wireless access point, which is running a RADIUS server for authorization and authentication of wireless hosts. This will be explained later in more detail later in section 4.1. Table 4 provides with the values for the wireless network (10.14.1.64/26). Network First host Last host Broadcast Netmask Total hosts R4 (uppland01) W1 (w01) W2 (w02) ... W61 (w61) 10.14.1.64/26 10.14.1.65 10.14.1.126 10.14.1.127 255.255.255.192 62 10.14.1.126 10.14.1.65 10.14.1.66 ... 10.14.0.125

Table 4: Area Networks values (wireless)

Services

The basic services we provide are dynamic routing with OSPF, DHCP for dynamic host conguration, DNS with bind9 from ISC, Apache as http server, and as an extra service RADIUS.

3.1

Routing with OSPF

Our routing protocol of choice was OSPF, we didnt cogure several areas, instead we put all our routers into the same one: 0.0.0.0. This area is composed of R1, R2, R3, and R4. We congured each router to advertise their respective networks to their neighbours, and R4 was set up as being the AS border router. Of course neither R1 nor R4 advertised anything to the lab backbone or to the Access Network, respectively. Routes to the other ISPs are congured statically. We tested the dynamic routing by simply disconnecting one of the routers from one of the networks and tracing the route to our internet exchange computer. It took a while to update the routes and establish a new designated router, but, a part from that, it worked awlessly.

3.2

DNS

DNS is a hierarchial name space where the top level is ruled by the root server. The top level domain in our project is the .lab. This corresponds to .root in the Internet hierarchy. The domain for our group is placed in the next level, it is called fixme.lab. To demonstrate delegation, we added a subdomain called uppland01.fixme.lab. Our primary and secondary DNS servers for fixme.net are situated in R1 (ns.fixme.lab) and R3 (ns2.fixme.lab) in Figure 1, while the access router (uppland01), acts as a primary server for the subdomain uppland.fixme.lab, each DHCP congured host (a customer) has its own host name under this domain. We provide as well reverse look up in each DNS server. To test DNS we asked some other group to try to determine the IP address of one of our customers computers (h01.uppland01.fixme.lab), and also make a reverse lookup. We also disabled the named daemon running on our primary DNS server to see that the secondary server would take the role on answering DNS queries.

3.3

DHCP

Since we decide that all the server of fixme.lab should be designed with a xed address, DHCP server is provided only for the hosts which connect to access network via R4. Since R4 is attached with a wireless and a wired LAN, DHCP will enable hosts of the two subnets to get the necessary information for dynamically conguring their interfaces for accessing the Internet. The conguration of dhcpd is not that interesting for our simple topology. Putting the correct value of subnets in the pre-dened style in the le /etc/dhcpd.conf will make our hosts know each other. Some essential options about DNS server and routers will give hosts full capacity to explore the Internet. To test DHCP we simply executed dhclient on the access network and made sure we got the right conguration parameters, including IP, default route, DNS information.

3.4

WWW

Apache version 2 is chosen to implement our web services. Since WWW is just one of the mandatory services we are to provide, we decided to install it on R1 and enable it with PHP support. As we mentioned before, we could have put it behind a rewall on a DMZ, but for simplicity R1 was chosen. The steps to set up the server are not complex and have been experienced in the labs before. We even decide to compile the server by ourselves, downloading source code, unzipping, compiling and

then install the build results. Editing the conguration les and then start deamons. Our goal is to enable the Apache, PHP and postgresql on R1, FIXMEs gateway to the lab network. They are not designed for any other complicated purposes (authentication, etc.) other than support PHP for our simple web server. The result is that our apache can serve http requests from different locations in the lab network. It satises our pre-dened goal perfectly, although we only had the default Apache testing page, but it also supports PHP, which can be used to connect our postgresql data base server. Users were allowed to have their own web pages on the server by simply creating an account on the server for each user, and letting them upload with sftp (public and private keys were created).

4
4.1

Selected service: RADIUS

Background

First, a brief review of AAA3 mechanism to enable the following discussion of 802.1Xs properties. Network Access Authentication is a mechanism by which access to the network resources is limited to authorized entities.Once authenticated,the session needs to be authorized.Accounting,the third A,provides the methodology for collecting information about the end users resource consumption, which can then be processed for billing, auditing, and capacity-planning purposes. What is more important is that it can afford non-repudiation with the logs. The Remote Access Dial-in User Service(RADIUS)is the best-known and most widely deployed AAA protocol.Its functional attributes consist of: Client-server-based operations Network security Flexible authentication Attribute/value pairs IEEE 802.1X, Port based network access control protocol, enables authentication and key management for IEEE 802 LANs.It is not purely a wireless standard but it is the security enhancement solution to WLAN. But we should notice that IEEE 802.1X is not a cipher; it is not the substitute for WEP or any other cipher. It is a framework for authentication and key management. It derives keys which can be used to provide per-packet authentication, integrity and condentiality. It can also be used to periodically refresh keys and re-authenticate so as to make sure that the keying material is fresh which can mitigate the reuse vulnerability. And typically, it is used along with well-known key derivation algorithms, such as TLS, SRP, etc. . . The protocol consists of three important components: Supplicant, Authenticator, and Authentication Server. Supplicant is the entity to send the access request, which is the station in WLAN. The station should support the EAP over Wireless (EAPOW) protocol. Authenticator is the entity to permit Supplicants access to the network, such as, the AP, but it can be somewhere else. It has two logic ports: the controlled and uncontrolled ports.The uncontrolled port is always open to transport the EAPOW frames. The controlled one can be opened to the authorized users only after the successful authentication. Authentication server is the entity to afford the AAA service to the Supplicant. From Figure 2 [1],we can better understand the 802.1X mechanism on 802.11. The 802.1X + RADIUS solution provides more security than WEP. 802.1X offers not only the authentication and encryption but also the key management, which 802.11 standard lacks. So, we choose RADIUS + 802.1X as our selected service from the point of view of security.
3 Authentication,

Authorization and Accounting.

Laptop Computer

RADIUS server

Association

Access denied
802.11 AssociateRequest

802.11

RADIUS

802.11 AssociateResponse

EAPOW
EAPOWStart EAPRequest (Identity) EAPResponse (Identity) EAPRequest (Credential) EAPResponse (credential) EAPSuccess EAPOWKey (WEP) RadiusAccessRequest RadiusAccessChallenge RadiusAccessRequest RadiusAccessAccept

Access allowed
Figure 2: 802.1X on 802.11

4.2

Setup

Our setup is based on Linux and open source software, which we found to be a kind of challenging and interesting task. Our Access Point is equiped with: HostAP driver + FreeRADIUS + OpenSSL (we choose EAP-TLS), and we choose one laptop working on Windows XP as a client. The solution is as seen in Figure 3.
Supplicant
11 Mbps Wireless Link

Authenticator RADIUS server

10.14.1.80/26 (IP handed out via DHCP after authentication) (IEEE 802.11b Wireless card) Windows XP + SP2

10.14.1.126/26 Linux + FreeRADIUS + HostAP Driver + OpenSSL

Figure 3: Open Source solution with FreeRADIUS and HostAP

Access Point

wireless

Ethernet

4.3

Installation

There are good news from Adam Sulmicki [2]. We just need to grab FreeRadius 1.0.0-pre0 or later and it wil do the right stuff, i.e., its not needed to modify the Makele in the ./radiusd/src/modules/rlm eap/types/rlm eap tls/ during the installation of freeradius. We also need to get and compile the sources for the other components, like OpenSSL-0.9.7d, hostap-driver-0.2.5, and hostapd-0.2.5. There were some errors during installation of the driver because the PCMCIA and CONFIG NET RADIO wasnot compiled in the kernel, so we needed to compile and rebuild the kernel. Our older kernel was 2.4.20-8 which didnt seem to support the latest hostap driver; we updated the kernel to the lates current versionfor the 2.4 series (2.4.26). We still had some problems caused by CONFIG MODVERSIONS, sowe disabled it.

4.4

Conguration
RADIUS server radius.conf eap.conf clients.conf users

The details of some les can be found in the appendix. Here well just list the name of the les:

Authenticator access point hostap.conf wireless.opts hostapd.conf Problems arised when trying to load the module for the Prism2/2.5 wireless network card. The problem was that the wrong module was loaded, by default it loaded a module for the orinoco cards, so we had to dig into hostap.conf, and nd the entry for that card, locate itsmansid, so the right module was loaded successfully. The infomation can be checked by typing the following command. $ cardctl ident And we should see some parameters, and the AP and the server should have the same shared-key.

4.5 OpenSSL
This is the open protocol for TLS (before known as SSL), which will be used to enable EAP-TLS, and also to generate our certicates for both client and server. We had to edit the le openssl.conf and set some parameters which would be used to generate the certicates. There is an interesting HOWTO that explains how to generate them. We created some scripts also to make the generation a bit more smoother. The certicates have to be imported to the supplicant host (a Windows XP client in our case), this was done without trouble. After the typical trial and error, we succeeded in using the EAP-TLS for FreeRADIUS.

4.6
4.6.1

Testing
Access Point

After installing the hostap driver, we can insert the card andmaybe even restart the pcmcia daemon, also it is good to look for special kernel messages with tail /var/log/messages If the HostAP driver is loaded correctly, the new network interface wlan0is ready to be congureed. We can congure some parameters for the interface, such as mode (master), ESSID,etc.Herewe assignthe IP 10.14.1.126/26, and 10.14.1.80/26 (no DHCP, as we are just testing the AP)for the wireless interface of the supplicant. Now it can work well if the supplicant can associate to the AP and succeed in pinging it, but unfortunately, and like if the name of our ISP had casted a curse on us, the supplicant, which we assigned a static IP address, could not detect the HostAP while another wireless card had no problem with it, and associate with it. We veried that HostAP driver was loaded correctly, and it was, but we got stuck. 4.6.2 FreeRADIUS

We started the radiusd daemon in debug mode with the proper SSL libraries. If everything is congured correctly, the server should inform us that it islistening for requests. In another session we typed radtest test test localhost0test. If the RADIUS server was working correctly, an Access-Accept should be returned. If you get an Access-Reject or no response, than recheck to make sure you congured FreeRADIUS correctly by reviewing the previous sections [4]. 4.6.3 XP Client (Supplicant) Setup

There are many details for this in [4], well not repeat them here. When we tested it at home, the authentication failed for various reasons. The rst time, we missed to use the latest version of openssl to generate certicates which caused the RADIUS server to not write the attributes of the supplicant. It seemed to show the error message: sslv3 cannot write the file x.x.. FreeRADIUS in general will require stable version of SSL, but the EAP-TLS module requires the latest snapshot (or any stable release after 1st March 2002, that is OpenSSL 0.9.7 or later) [4]. Thenwe installed the older stable version of openssl and the latest SNAP version. This time we used the stable version to generate the certicates, but it failed again. We guessed that the problem lied in the generation of certiates and the use of openssl library for freeRADIUS. We tried to install another version of freeRADIUS, however we didnt suceed to compile it, if we modied the Makele in ./radiusd/src/modules/rlm eap/types/rlm eap tls/. Then we used version 1.0.0 again, but the supplicant could not be autheticated.

Lessons learned

This project was very interesting for its contents, although we had already worked them on previous lab sessions, we could put everything together, which proved to be a bit of a challenge, but fun as well. We learned about subnetting, which is not hard, but one needs to get used to it (and it is error prone). We also learned a lot with the Ethereal network analyzer. Tools like this often make it easier to better understand how a protocol works. It was especially interesting to view the neighbour greeting of the OSPF routers, specially when one loses one of its links. Regarding DNS, even though weve studied it on the lectures, and have worked with it on a lab session, the project gave us a clearer picture about the DNS and its hierarchy, particularly the delegation part. Since we used openSSL for EAP-TLS, and came across some problems, we think theres room for improvement there, but nevertheless it is a good implementation, and it is open. Another thing about it,

is to make the it t for FreeRADIUS. In other words, it is about how to use a correct version of openSSL so that it can work well with FreeRADIUS (without errors in building or running). Several HOWTOs give a lot of hints about how to chose correct sources. But many of them are a bit out of date. After wasting much time on incorrect matching, we found that if you just download the latest stable source of OPENSSL and FreeRADIUS, build them seperately instead of confusing operations stated in those HOWTOs, the task will be completed perfectly. It was a challenging and valuable attempt, although we could not success in providing the selected service. we also faced some conguration problems with Red Hat Linux 9, but it might be due to our lack of knowledgeabout it, we had to recompile the kernel and t new drivers, and hack a bit the pcmcia les, but in general we think it was worth it. We still dont know what failed during the demonstration. The selected service in itself is not very complicated, the most complicated part was getting everything well congured. The day before the demonstration we could authenticate and authorize a suplicant with our settings, but somehow we must have misscongured it again during the presentation. It could have been that we were using the wrong certicate, or that we misscongurated unadvertedly some le, although we reviewed everything during the demonstration session.

References
[1] Joshua Hill, An Analysis of the RADIUS Authentication Protocol, InfoGard Laboratories, Nov 24 2001. http://www.untruth.org/josh/security/radius/radius-auth.html [2] Adam Sulmicki, HOWTO on EAP/TLS authentication between FreeRADIUS and XSupplicant, http://www.missl.cs.umd.edu/wireless/eaptls/ , 2004 [3] Raymond McKaym, EAP/TLS on XP Howto Version 1.2, http://www.freeradius.org/doc/EAPTLS.pdf [4] Raymond McKay, FreeRADIUS EAP/TLS -- WinXP HOWTO, 2004

10