Skip Navigation
 Search | Directories | Reference Tools
UW Home > UWIN > Computing and Networking > Wireless 

UW Technology Wireless Logo EasyReg Technical Overview

Overview

This document provides the architectural overview of the EasyReg system. EasyReg is meant to provide a replacement for the ambit authentication boxes that are currently used on our wireless subnets. We first describe all the pieces that make up the system, then provide a detailed walk-through of the system operation.

Definitions

The following terms are used throughout this document:

Diagram of the system components

EasyReg architecture

Detailed Component Descriptions

  1. DHCP Server

    The DHCP server is our standard ISC DHCP server, which handles all DHCP-related functions. In addition, we also have a script (dhcp_tailer) which tails the log files (/data/dhcp/log/dhcpd.log) and looks for state transition events for leases. We needed to modify the configuration slightly from our usual, so that we get more information about lease state transitions into the log files. We ask the DHCP server to log lease commit, release and expire events so that we can take the appropriate actions at each of these times as follows:

    • Lease Commit
      The time at which a lease is given to a client. It is either given as a result of a 'request' or a 'renew' request by a client. For our purposes there is no difference between these two cases and hence we treat them the same.

      When a Lease Commit event is seen in the log file (by dhcp_tailer), we consult the Registration Manager (using lease_info binary) to determine whether the client (based on the mac address) has been registered. If the client has been registered, we tell the Redirector to remove the DNS lying for this particular client. We also tell the Nullrouter to remove the null route. This means that the client has essentially 'clear' access to the Internet. If, however, the client has not registered, we turn on both nullrouting and DNS-lying to prevent the client access to the Internet and instead redirect them to our captive portal for registration.

    • Lease Expire
      This is the event caused by the lease expiration. At this point, we tell the Redirector to lie to this client from this point forward. We also tell the Nullrouter to reinstate the null route for this client. Note that we do both of these actions regardless of the state of the client as there's no harm in doing so, and having to keep extra state about the clients (or querying for it at the time of expiry) doesn't really give any additional benefits.

    • Lease Release
      This is handled exactly like Lease Expire.

  2. DNS Server

    DNS Server layout
    Physical layout of the hosts and a sample query/response sequence

    The DNS server is composed of three distinct components. For ease of discussion, we talk about all of them in the same section as one component. We run both the liar and truer on the same host, and simply assign the host two IP addresses (in addition to any 'real' IPs that it has). Each of the servers listens only on a particular IP address.

    1. DNS Liar
      DNS Liar is a DNS server that has been configured to respond to requests about campus resources with the correct information, but for any external resources, the server will respond with the address of the Web Redirector (IPwr). The purpose of this is to redirect the client to our captive portal in the event of outside web services. The configuration file for liar is: /etc/named/named.conf.dnser2.liar

    2. DNS Truer
      DNS Truer is simply a 'normal' DNS server. It always tells the truth whether the request is for inside or outside resources.

    3. Redirector
      Redirector is responsible for taking incoming DNS requests from clients and forwarding the request either to the liar or the truer depending on the particular client making the request.

    By default, all clients are lied to.

    1. Lying uses the iproute2 rules and forwards the packet to one of the DNS Servers.
    2. The router upstream from the Redirector, DNS Truer, and DNS Liar sends (by configuration) all traffic on the DNS servers IP address (IPdns) to that of Redirector. Note: IPDns must not exist anywhere, but be a 'virtual' IP because the rules on a Redirector operate on the source and destination IP of the query.
    3. The Redirector routes the query to either IPl or IPt depending on whether the Redirector has been instructed to lie to the client.
    4. One of the DNS servers then responds to this query and due to the default route on the machine, the response is sent via Redirector.
    5. On the Redirector, a kernel module rewrites all the udp packets with a source of either IPl or IPt with the source of IPdns prior to forwarding the packet. This is because that the client will not accept a response from a server that it didn't send the original query to.

    A SOAP service on the Redirector called CRouteRedirector is used to view and modify the current rules about to whom to tell the truth. If you are locally on the machine, you can also look at the rules directly by doing a
    /sbin/iptables -t nat -L


  3. Nullrouter

    Nullrouter is a service that allows you to prevent IP packets from the Internet from reaching a host on our local networks. This is achieved by running a Zebra (more specifically bgpd) on our server (currently on shivax2), which peers with a Gigapop routers and injects /32 routes with a specific community tag. These routes are then routed to /dev/null on the UW border routers.

    There is a SOAP service on the same machine as the Zebra, called CRouteNuller, which then interfaces with the Zebra command line interface behind the scenes. With CRouteNuller one can view/modify the set of hosts that are currently being null routed. There are command line tools (route_nuller) that allow you to verify state information for any given ip as well as modify it.

    You can also get information about the set of hosts that are currently being null routed from the Gigapop routers (XXX maybe even from UW border routers?) by looking at the routes for the specific IP in question. If a /32 for that route exists and is going to /dev/null, then that IP is indeed being null routed.


  4. Web Redirector

    Web Redirector is responsible for providing a 'captive portal' service to the client.

    If a client has not been registered and hence we are lying to it, then:
    1. When they try to access resources outside of the campus, they are lied to and are pointed to the IP address of the Web Redirector (IPwr) instead.
    2. Web redirector sees this request (and knows where they are trying to go to, for example http://www.google.com), and looks up the IP.
    3. If that IP is registered, the client then is proxies to the original URL by the Web Redirector. If that IP is not registered, the client is redirected to the Web Registration App.

    The Web Redirector is a proxy configured to only proxy if the command line tool, lease_info, reports that the ip making the request is registered. Otherwise the Web Redirector does a redirection to the Web Registration App passing along the original destination the client was trying to access.


  5. Web Registration App

    The Web Registration App provides a Web interface for clients to register the machine. It asks the client to authenticate using Pubcookie:

    1. Once a client successfully authenticates, the Web Registration App contacts the Registration Manager and sets the client state to registered. Also, the null route and DNS lying are removed for this client.
    2. Once these actions have been successfully completed, the client is redirected to their original destination (in our example http://www.google.com). Requests would go through the Apache proxy gateway if client still resolve their original destination to the ip of the registration host.

  6. Apache Proxy

    The Apache proxy act as a gateway for any URL request directed at the proxy server. This is to offset initial pre-registration DNS caching on the client host. If the proxy is not in place, client would have to reset or restart browser, in some cases restart host machine. The actual proxy utilizes Apache mod_rewrite to force proxy base on the condition that client is register as return by lease_info. See Apache module mod_rewrite.


  7. Registration Manager

    The Registration Manager manages which clients have registered and when. It also makes sure that the entries are in consistent state. For example, it makes sure that if a client is registered and it has a lease, then it is not being null routed. This is done by periodically running a cronjob and comparing Registration DB against null routed hosts and those that are currently being told the truth.

    Registration Manager also keeps track of when a host registration should be removed. Currently when a client authenticates, it will be considered valid for 12 hours. So even if the clients lease expires, and/or they move to another subnet, they will not need to re-authenticate until the validity of the registration expires (12 hours). So, the Registration Manager runs every so often, and finds clients that are currently registered, but whose registration was done more than 12 hours ago. In those cases, the registration is removed, DNS lying and null routing are reinstated. This forces the client to re-authenticate themselves at lease every 12 hours.


  8. Registration DB

    Registration information is currently kept in the DHCP lease information database in the form of HOST records. We keep a record of host records with a name <MAC>EZReg, for example 00601DF73BC0EZReg to distinguish them from any other kind of HOST records that we might have (like StaticDHCP, etc). You can view/modify these records with scripts (lease_info, register and unregister).