As more applications and services are delivered through the network, the security and reliability of the network are attracting increasing attention. To minimize disruptions, network operators want to maintain more control over the network traffic and behavior. Areas of concern are access and admission control, traffic engineering, detection and mitigation of network anomalies, and attack isolation to name a few. 

As more of these devices are deployed across the network, often incrementally, policy  management of all these devices becomes a problem. For these devices to provide effective traffic policing, up-to-date and coherent configurations are required. Also, problems arise with detecting conflicts among distributed rulesets, troubleshooting network anomalies, and verifying  conformity of network security requirements when multiple administrators are involved in manually managing policing devices distributed across the network. The tasks are not only tedious and contribute to a significant portion of operating costs, but are also error-prone, which can cause network downtime. 

The requirements, and even the definition of a network control system, are not universally applicable. Some networks may require simple access control while financial institutions are required by law to have strict controls on information flows between their systems. We believe facilitating innovations at the network control and management layer promotes more effective and useful network controls.

Our proposed architecture embraces the ideas from the 4D project, which used centralized components for control and management. We employ simple (or dumb) forwarding devices, called Enforcement Agents (EAs), on the data-plane to handle network traffic. A set of servers, called Supervisors, acts as the centralized component that governs the network control decisions and dynamically disseminates them in a just-in-time manner. The decision engines correspond to the network control and management layer. The resulting system consists of mainly light-weight forwarding devices sharing a few heavy-weight decision engines through a small number of Supervisors. Lightwall is an overall light-weight architecture compared to the traditional architecture, which deploys many heavy-weight devices throughout the network. 

Supervisors focus on determining and maintaining up-to-date network control decisions, and making those decisions available across the network in a robust, consistent, and scalable manner.  EAs focus on packet forwarding while inquiring and enforcing network control decisions in a just-in-time manner. Through the set of Supervisors, decision engines are presented with packets and information that originated from the data-plane.  Decision engines do not need to worry about disseminating actions and keeping them up-to-date. Similarly, EAs do not need to know how the actions are determined nor the specification of the underlying control policies. 

This separation of duties offers several benefits:Open platformThe network operator can now choose its set of network control features, policy representation, and management platform independent of the enforcement mechanism deployed in the network. In fact, there can be multiple platforms potentially provided by different vendors. Similarly, this architecture allows the co-existence of traditional policing devices and EAs, potentially from multiple vendors with different sets of features. This not only offers flexibility to administrators on choosing networking equipment, but also opens up opportunities for innovations in the equipment vendor industry.ManageabilityNetwork control policies can be updated anytime. Instead of manually identifying the relevant policing devices on which to install or update policies, changes can now be made at their respective decision engines with the knowledge that the Supervisors will automatically and consistently enforce the latest policies in the distributed EAs. 

With centralized decision engines, conflicts or potential policy induced anomalies can be more readily discovered and resolved with existing algorithms before deployment. By maintaining a version control on the policy and a global view on a central repository of flow-initiation statistics, network anomalies and troubleshooting will be more manageable. Deployments of  EAs can be done incrementally and involve only minimal configuration. Once connected to the network, a new EA is ready to forward traffic and enforce network control decisions provided by Supervisor.

We set up a physical network testbed consisting of Linux software routers, a Cisco hardware router, and Linux-based servers and traffic generators. We use a modified pktgen Linux kernel traffic generator for our testbed experiments. EAs are implemented with kernel modules using the Linux Netfilter framework and deployed in Linux-based software routers. A Supervisor is implemented as three multi-thread, C++ user-level applications running on an Intel Core 2 Duo 1.86GHz Linux server. A stateless firewall decision engine is implemented using the Netfilter framework. Also, a simple C++ program that emulates a constant packet classification time of 700us per packet is used as an additional decision engine. EA implementations, such as hardware add-ons and firmware updates to existing switches and routers, are currently in progress.