To obtain all the advantages of enterprise middleboxes and NFV, we are modifying home consumer- grade routers to support OpenFlow and communicate with a controller in the cloud. In doing so, the controller gains full control over the network flows and can divert these flows through a series of virtual middleboxes, which can implement the functions of enterprise equipment in software. Since residential users have lower performance requirements, these software approaches can meet the user’s demands while having flexibility in their use.
We now describe the key elements of our ReSDN infrastructure, including the modifications to the consumer-grade router including a software agent and the control systems in the cloud.
5.2.1
Consumer Router Modifications
To achieve our goals, we must modify the consumer’s router to support the OpenFlow protocol, and unlike prior work, we must place OpenFlow on a consumer router and use a controller that is outside of the router’s LAN. We use OpenWrt’s [45] Open vSwitch [144] implementation to outsource this functionality to a cloud controller.
While it may be tempting to outsource all functionality to the cloud, a more robust solution retains some functionality locally. In particular, we continue operating a DHCP server and client locally, as well as the NAT and DNS services. This approach allows a router to safely failover to local operation when connectivity with the cloud is interrupted or if the cloud controller requires maintenance. However, even with these services running locally, our default flow management causes these flows to be elevated to the cloud, allowing it to authorize or deny DHCP leases or new NAT entries.
Host1
PPE FGFC
Figure 5.1: Our proposed ReSDN architecture with residential routers supporting OpenFlow. Our controller supports fine-grained flow control (FGFC) and runs a partial path encryption module that supports directing traffic to waypoints in the cloud.
In Figure 5.1, we visually depict how OpenFlow traffic is elevated to the cloud-based controller and how the commodity router directs traffic through cloud waypoints with the help of a route agent. Unlike traditional uses of OpenFlow, which may use coarse-grain rules (i.e., a rule using a
wildcard for one or more fields in the flow-tuple), we focus on fine-grain rules in which the flow is fully specified, including network and transport layer source and destination identifiers. This ensures that every new flow is seen by the controller, allowing the controller to decide whether to authorize or deny each network flow as the flow initiates. Importantly, the controller may choose to divert the network flow through a proxy by requiring the router to tunnel the traffic associated with the flow through an intermediary. The route agent, which is outside of OpenFlow, can manage and negotiate the appropriate tunnels, allowing the OpenFlow controller to simply specify the targeted middlebox application, causing traffic to traverse the tunnel transparently. As we being to target more network functions, the agent will be key to deploying richer sets of middlebox functionality.
5.2.2
Cloud Controller Considerations
There are a few important considerations for the controller: its network proximity with the con- sumer router, the controller’s software, and the approach the controller takes for managing the user’s traffic. While we describe the important considerations for the controller, we note that these decisions need not directly involve the user since they can be handled automatically.
End-users may choose amongst numerous commercial cloud providers based on a variety of factors, such as cost and the computational resources provided. For a cloud controller, it is partic- ularly important to minimize network latency. Depending on the user’s geographical location and the connectivity of the user’s ISP, some cloud data centers may be more appealing than others. Since the controller must be consulted at the initiation of each request, a low latency connection will minimize any delay for new flows. Software on the router can perform latency tests across a series of candidates and present the user with options, comparing likely performance with other considerations, such as cost, and let the user choose.
The user, or software acting on behalf of the user, must install and configure an OpenFlow controller. There are many options for OpenFlow controllers. We use the POX controller in our approach since it has a modular implementation that enables fast prototyping. A controller’s mod- ularity is key to enabling support for arbitrary residential network functionality, since components can be added and removed with minimal overhead.
The controller can leverage a variety of applications to make traffic control decisions. These applications can be divided into two key classes: 1) elevation-centric applications, which make decisions based only on the initial OpenFlow packet, and 2) payload-centric applications that examine all the packets in a flow. The needs, and the approach to meet these needs, differ dramatically. The elevation-centric applications can run as a traditional module in the OpenFlow controller and can make decisions based on the flow as it is elevated. Such applications may include IP-based blacklists or firewalls based on network or transport layer information. Once these applications make a decision, the controller can approve or deny the flow, completing the controller’s involvement.
Payload-centric applications, such as IDS software, deep packet inspection tools or stateful firewalls, require more than a pure OpenFlow approach. In this case, the OpenFlow controller must order the consumer router to divert the flow’s traffic using a tunnel to a proxying device that will inspect the flows. Importantly, this proxying device does not need to be co-located with the
controller and can be selected using other criteria (such as throughput and bandwidth costs). The proxying device can inspect the traffic and asynchronously inform the controller if the flow ever needs to be terminated or modified.