NOX at Home Logo

Solution Statement

There is more potential for NOX and OpenFlow in the home network than we could possibly develop in a semester. Our true goal is not to deliver the end-all-be-all of home networking. Our goal is simply to get the process started -- to provide the proper "jumping off point" from which future home/SOHO networking tools can be built. This means we must cater to two separate audiences: the technical audience of people wishing to do network research or develop specific network "applications" for the home, and nontechnical consumers who simply wish to take advantage of these tools.


Our solution can actually take some hints from the three principles that drove the development of Ethane:


The network should be governed by policies declared over high-level names. The average home "WiFi router" does have some ability to set policies -- port forwarding, port filtering, sometimes even time-based access control -- but these policies are universally set over IP addresses which mean nothing to average end-users. We need provide the ability to set policies on the names of users and groups of users ("Perry", "The Kids"), recognizable machine names ("John's laptop", "Susan's Dell", "Canon Printer"), and useful network names ("WiFi", "The Internet", "House Network").


Network routing should be policy-aware. In the context of Ethane, this meant the selection of specific network paths based on policy. For NOX At Home, the situation is much simpler (the paths over which we have control are very few), but the basic idea still holds: policy decides what packets are sent where (and which are dropped altogether).


The network should track bindings between network traffic and the high-level entities that are its source and destination.. The final principle behind Ethane was "The network should enforce a strong binding between a packet and its origin." This principle makes sense for enterprise networks where security is of primary concern -- the ability to tie network traffic to specific users and machines closes many avenues of attack for network intruders. However, the home network differs from the enterprise network here: in an enterprise network, globally managed users with strong and explicit authentication are the norm, and this is not the case for the home network. Given this, it is suitable to somewhat relax this final principle. We also wish to slightly expand on this statement, because not only the origin (or source) of the traffic but also the destination may factor in to to policy selection. What we are really saying here is that we need to be able to associate traffic with high-level names in order to correctly make policy decisions for that traffic.


Finally, our solution has some "user experience" aspects that were not part of Ethane at all:


An ordinary consumer end-user should be able to operate the system with a minimal investment of time. While we hope that the use of high-level names will be a great step in this direction, this also very clearly calls for a graphical user interface that leverages the investment that users have already made in operating personal computers.


Users should not find the system to be a burden to use.. Our goal is to enable users to get more power, more usability, and more security from their home network. Our goal is not to to make their network more annoying or waste more of their time. This principle mandates some compromises. For example, while we may be able to get more security by requiring explicit logins, we do not feel that this would be acceptable to many users: despite any improvements we may be able to offer, users will feel that our system is annoying and is getting in their way. We must aim to make whatever improvements we can while impacting user experience as little as possible.


These high level goals motivate the development of a framework that enables the development of tools to improve home/SOHO networking. However, a framework based purely on high level goals is both difficult to design and difficult to evaluate. To this end, we have identified and will build some prototypical home/SOHO network tools. The successful completion of these tools will then not only serve to provide the capabilities of the tools themselves, but to validate the design and implementation of the framework and the achievement of the high level goals. The specific features we have identified are:

  • Identify machines by MAC address
  • Identify users using passive methods (snooping on Instant Messaging and website account logins)
  • Identify users actively -- through an explicit web login/logout page
  • Maintain and display a view of the network -- which machines are online, and which users are using them
  • Allow certain users/hosts to be disallowed LAN access and given only Internet access
  • Allow certain users/hosts to be allowed only HTTP and have other traffic filtered
  • Give users feedback on events that have occurred (access to the LAN denied, etc.)

While these features are certainly not the most compelling that this platform should have to offer, we feel that their implementation will properly guide the development of the platform and the implementations of further components. Specifically, we have identified the following major components (or classes of components) that will be needed to support these features:

  • Evidence Sources. Evidence Sources provide a mapping between network traffic and our high-level names -- users and machines. An "active" source would be a explicit login over a "captive portal" type web page, but we believe the more important sources will be passive and based on the interpretation of network traffic. For example, an evidence source could be written that monitors for network traffic for instant message conversations and knows how to associate one of the network's users with a particular instant messaging account.
  • Network View. The Network View maintains a view of the network state -- which users are on the network, which machines are on the network, which users are on which machines, etc. This is done primarily through the evaluation of evidence given by Evidence Sources. We suspect that evidence will seldom be as complete, authoritative, and non-conflicting as we would like, so evidence must be combined and arrive at a "best guess" of the truth. This will probably be done using existing research done on this subject, such as that done by Bayes, Dempster, Shafer, and Hooper.
  • Policies. Policies actually affect network traffic. In some cases, these may be relatively simple, such as "never allow traffic to example.com". In many cases, however, we believe that effective policies will involve high-level names, such as "disallow VNC access to Tom's Linux Box to any user except Tom" or "don't allow Guests access to anything on the LAN except for Printer2". For this reason, many policies will query the Network View to gain insight into these high level names.
  • User Interface. We wish to be able to allow for easy user/machine management, as well as the selection of policies. We also wish for future components to easily integrate with this same user interface. A web based user interface is ideal for our system, as it will allow users to access the interface from any machine on the network and requires nothing to be installed, which plays nicely with our "minimal investment of time" and "not a burden" principles.

The user interface's "web app" portion will be built using the qooxdoo framework, though we have not yet identified solution to the user interface back-end. Evidence Sources, the Network View, and Policies are all individual NOX applications. Evidence Sources and Policies will generally provide their own user interfaces (seamlessly integrated into our web app).