OpenFlow based WiFi authentication - how else could you do it?

With OpenFlow, it is very straightforward to do user authentication and sign-on in a WiFi network using MAC authentication.

In an OpenFlow network when a user attaches to the WiFi network, the switch passes the new/unknwon user's packet to the controller for authentication. The controller can then check the user's MAC address against a database to see if it is known and then the user can be either routed to a public network or redirected to an authentication page. Once the user has authenticated, the authentication process can inform the controller and the controller can push a new rule for that MAC address.

So how could this functionality be achieved in another way without using OpenFlow?

In order to use the MAC address we need to operate at Layer 2.  We can't use the IP address unless we introduce another stage to obtain the MAC address from the assigned IP address.

So let's walk through how we might be able to do this using existing networking technology.

So a user attaches to a WiFi HotSpot. The WiFi Access Point can then assign an IP address using DHCP. We could have a custom DHCP server that allows us to query the database to verify MAC addresses. The DHCP server can then assign an IP address.

OK we have now authenticated a user but not solved the problem of routing to either a landing page or allowing the user to connect to the internet.  How could we solve this?  Well we could assign a different IP address subnet based on whether the user is known or unknown or maybe use different VLANs depending on whether the user is known or unknown.

So once the user has visited the landing page and authenticated they should now be allowed to have unhindered access to the internet. The problem is the routing policy is based on the users IP address.  We now either need to expire the users IP address and repeat the DHCP process or introduce more controls into the routing domain. Probably the easiest to do is to issue short lease DHCP addresses.

If we let the IP address continue we need more sophisticated controls in the routing layer. One way to achieve this would be to use a Deep Packet Inspection (DPI) box to apply these routing policies. DPI is actually overkill since we don't need to look deep into the packet. We actually only need the IP or MAC address. Using APIs off the DPI box we can control how the user's traffic is routed.  OK maybe a load balanced is a better option.  We can use the API on the load balancer to route traffic that way. It will need to look up the IP address to find out whether it is authentication. We still need to use the DHCP and load balancer as the solution. The DPI or loadbalancer will need to cache the authentication state to avoid repetitive look-ups.

OK let's ignore the DHCP option.  Let's use just a load balancer. We assign the user an IP address and the traffic arrives at the load balancer. The load balancer now looks up the IP address to find the MAC address and whether it is authenticated or unauthenticated. We can then route the traffic. The load balancer will need to store the authentication state locally to determine the routing policy and avoid looking every packet up and creating database load.

OK it is possible to implement comparable functionality to OpenFlow for WiFi MAC authentication using existing technology.  What this thought experiment has shown that it ends up being more complex and a rather bespoke design.  If I decided to change the requirements it is possible I may need to restart the design from scratch or add more complexity.  In OpenFlow I suspect the additional requirements can achieved pro grammatically by the controller