acm sigcomm

Network functionalities such as intrusion detection and load balancing are often implemented in specialized expensive middleboxes plugged inside the network. But, with the advent of commodity hardware and network switches, it is time to think about leveraging these new and cheap resources to support the same functionalities with lower cost without compromising efficiency. This is in the same spirit that software radio, virtual machines and virtual routers, have been introduced. The implementation of network functionalities in a kind of software environment has the further advantage of making them easily manageable and extendable to other applications (on software timescales).
The architecture introduced in this paper is called Flowstream. It proposes the implementation of network functionalities in virtualized machines/servers/routers run on top of commodity PCs. The flow of traffic among these virtual network entities is controlled by a programmable network switch implementing Openflow. The papers motivates the problem and discusses the architecture and its main components, plus a description of some potential applications. Even though there are no validation results, all reviewers appreciate the idea and agree on the fact that it will trigger discussions among CCR readers and the members of the networking community. This is a new research area that involves several tradeoffs (technical vs. economical, reliability vs. programmability) to be clearly understood and evaluated.
Programmable flow forwarding using Openflow has been already proposed in an operating system context as for example in the NOX architecture that has appeared as an editorial note in the CCR July 2008 issue. The novelty of this new paper is in combining flow forwarding and virtualization to replace network middlebox functionalities.

Defense against DoS attacks is definitely an important practical problem given the fact that potential attackers may control botnets with hundreds of thousands of machines. This paper adopts the approach of marking IP traffic close at the source, which then gets encapsulated and tunneled to a decapsulator near the destination. A server under attack can ask the decapsulator to suppress certain traffic destined to that server:
In this case, the decapsulator determines the “entry point” encapsulator from which the unwanted traffic is coming and asks the encapsulator to filter the unwanted traffic. This approach has the advantage that the en- and decapsulation boxes are deployed at the edge of the network, not requiring any changes to the core network. The paper presents performance results showing that off-the-shelf HW is sufficient to perform en-/decapsulation at a speed of hundreds of Mbit/sec, which means that requiring packet rewrites (at least at the edge) is not a show-stopper any more.
However, efficient en-/decapsulation is only one piece of a successful DoS defense system. Such a system also critically relies on securely establishing the decapsulator-to-destination mapping and on the filtering mechanism to work reliably. Getting these functions deployed in a robust, large-scale fashion seems to be a major hurdle that limits the chances for this approach to get widely deployed. There exists already made a number of proposals for DoS defense systems as well as some commercial systems that have been successfully deployed. As the reviewers observed, this paper does not clearly state why the approach proposed is superior other DoS defense systems. Dismissing commercial systems on the basis they require "special boxes" does not convince given the fact that the solution proposed here requires the deployment of en-/decapsulator boxes.