Ethane: Taking Control of the Enterprise May 5, 2009

1. centralized — require strong consistency, easy to set network state and change policy; simplifies switch tasks
2. simple switches — low cost, fast

One issue that bothers me is the case where, say, a business has multiple locations. If we use a single controller, and one plant gets cut off from the other, one might use a backup at the location disconnected, but this might require a massive rebuild of the MST. If we use multiple controllers, an authorization system would be required for machines outside the network, unless the two controllers communicate, which would provide a good deal of overhead.

Possible future work may involve tinkering with the queuing at the switch level. For example, if huge amounts of data are being transferred (let’s say it’s a render farm) using the restrictions placed by the controller, one might implement some sort of fair queuing.

Ethane: Taking Control of the Enterprise May 5, 2009

This paper presents the Ethane system, which is designed to manage an enterprise security policy in an efficient and easy-to-use fashion. It does this by providing a centralized point (or points, in the case of cold/warm backups or full replication) which contain all of the policy information and create flows through which network data travels between hosts.

The three most important things the paper says are:

1. Even though it is counter to the traditional network management mantra, maintaining a centralized policy has many advantages. It simplifies monitoring traffic and authenticating users, and ensures that all of the policies which were traditionally implemented by filters and firewalls distributed throughout the network are actually affecting traffic in the desired fashion. This is primarily because all flows (or at least the first packets from all flows) are rerouted to the controller. Any packet belonging to an unregistered flow is either dropped or routed to the controller, and thus it is impossible for traffic to escape the policies implemented on the router. A centralized authority is made possible by the fact that modern hardware is very powerful (i.e. one controller can manage many thousands of end users) and the fact that the controller is only involved in the establishment of the flow, with all other traffic (assuming the flow is approved and installed) being routed directly (and efficiently, another benefit of an omniscient controller) from end user to end user.
2. The use of a flow-based system allows the Ethane switches throughout the network to be much simpler than a traditional Ethernet switch. While it is possible to optimize them by adding multiple queues for different traffic classes or implementation-specific flow entries to reduce traffic to the controller, the Ethane switch is mostly comprised of just a flow entry table, which consists of much less state than all of the routing tables found in a traditional Ethernet switch. Further, even though the Ethane switch is simpler, not all switches need to be switched from Ethernet to Ethane immediately, since the controller will still manage the spanning tree if it contains traditional Ethernet switches.
3. Network policy is most effective when it is maintained over high-level names. One of the handy features of the Ethane controller is that it binds hosts and users together in a centralized location. This makes auditing connections much more straightforward since there is a permanent record of which user was using which host at a given location in the network (switch port) at any point in time. In addition to making auditing much easier, it makes maintaining the policy information much more straightforward as well, since it provides flexible ways to restrict or allow classes of traffic.

I believe the most glaring problem with this paper is that, even though Ethane is an elegant solution for network policy management, and it can be implemented without immediately switching all Ethernet switches to Ethane switches, there is still a deployment issue. All of the custom hardware deployed by enterprises already has security policies built in, and it is quite possible that the combination of transferring these policies to Ethane and then deactivating them (to avoid conflicts or lost traffic) could cost a considerable amount of resources to ensure that no functionality is lost either by under- or over-restrictive end policies.

While they did implement this system on their 300-host network for a few months and provided data which indicated that Ethane would easily scale to many thousands of users, I think one avenue of future research would be to actually implement it on a sizable network. It is possible that there are issues at the 1000+ host count which were not foreseen on the 300-host network. Another research path would be to determine which “value-added” features to add to the Ethane switches to provide better network performance (in throughput, traffic reduction, latency, etc.) while still maintaining their simplicity, which is valuable if hardware is going to be produced. They mention adding multiple queuing to the switches, but it would be interesting to see what kinds of queues provide the greatest benefit.

Ethane: Taking control of the enterprise May 5, 2009

(i) The three most important things the paper says:

1) Keep the switches simple and add the complexity in the centralized controller.  They showed that the performance of having a centralized controller to manage the flows performed better than expected.  This was important because it went “against the grain”, since it was thought that a centralized approach would perform poorly compared against a de-centralized approach.

2) The support and performance numbers for a “fault” was acceptable.  This was pivotal in their argument, because the most glaring problem for a centralized approach was the issue of a “single point of failure”.  However they quickly dispelled this by providing the feasibility of three different solutions (cold standby, warm standby, and fully replicated).  In addition, they also showed that using “cold standby” the numbers aren’t so bad (for 1 failure, it adds only 4.8% to the response time.

3)  Current techniques to make network management more secure is to add tools ontop of existing solution, but this is just a “band-aid”.  This was a keen observations, since issues in the underlying architecture is still not addressed, those tools wont be able to add additional functionality.  For example, tools on top cannot add the ability to enforce a strong binding between a packet and its origin, which is very useful for manageability and future security features.

(ii) The most glaring problem with the paper:

While Ethane proposes a good solution to make the network more manageable through a centralized “controller”, it may not be a good enough reason to change the way things are done now.  Since it doesn’t really offer any advancement in security (e.g. tunneling of information through higher level applications), it may deter users from adopting this new system.  What would be more interesting would be presentation of performance numbers, with some of the features to support additional security features in the controller.

(iii) The future research directions of the work:

The future research of the work would have to involve performance metrics for different “type” of networks.  While the research and results from the Stanford network are quite large, the traffic of schools may vary compared to a company (e.g. Google).  In another type of environment where traffic characteristics are different, this centralized approach may quickly become a bottleneck, even if there were multiple controllers due to convergence issues.

Ethane: Taking Control of the Enterprise May 5, 2009

Ethane is a network architecture for providing enterprise-wide policy enforcement. The basis of the design is to use a central Controller to authenticate and authorize each flow between hosts. To accomplish this, the design calls for the use of customized switches to route new packets to the Controller for authorization and then to route authorized packet flows between hosts. The Controller receives all new packets from a customized switch that are not part of an existing flow. The Controller identifies the packets’ source and destination, and allows or disallows the flow according to the network policy.  For the Controller to be able to do so, it must keep track of which users are on which hosts and which hosts have which addresses.

The prospect of a central Controller keeping track of the entire network (topology included) and enforcing a network policy is a powerful one. It seems that the main contributions of this paper are two fold. First, because of the need for a custom layer 2 switch, filtering, QoS, load balancing, and other layer 3/7 features can be implemented in layer 2. This results from the fact that the Controller specifies if and where to route flows by adding entries in the custom switch flow tables. Implementing these features in layer 2 allows for very high processing speeds.

The other contribution is the case study of how well this design can perform in a real use scenario. Ethane was deployed at LBL and Standford University. Many proposed centralized designs can argue that they can scale, but until they are deployed and used the assertions are simply estimates. The authors provide flow request rates for both deployments over a period of days (on the order of a month). This metric is the most appropriate as it represents the heaviest load on the system’s bottleneck, the Controller. The results suggest that a single Controller (on a modest PC) can accommodate 20,000 hosts and up to 10,000 flow requests per second. This provides strong evidence that a centralized design can scale to a reasonable number of nodes.

The major flaw with this design (as pointed out by the authors), is that the Controller must be familiar with all protocols running over the network. Because all packets (not already authorized as part of a flow) are routed to the Controller, the Controller must understand all protocols from which it might receive a packet.

I think toady’s networks are running a huge number of protocols and network policy is constantly trying to keep up. It seems like Ethane is a good approach to enforcing a policy across the network. But it seems that further research may yield a similar approach in a decentralized manner. Perhaps using the same constructs, but by virtually partitioning the network.