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

(i) the three most important things the paper says

One of the most important observations of the claims in the paper, although subtle, seems to be the claim that current computer hardware is advanced enough to handle a moderately-sized network’s worth of traffic from a central point.  This is a point that has been shown as false in the past, as the traffic alone is usually enough to congest the single host.  This claim seems quite radical.  Another important observation is that the switches themselves, due to the centralized control in Ethane, can be very simple–other than the massive amount of storage required for flow tables.  This means, as the authors claim, that ASICs can be designed that are much cheaper to develop and manufacture (and thereby would also be cheaper for the consumer).  This means that expanding a network may not be as expensive as it is currently, assuming that the current central hardware is advanced enough to handle the extra traffic to be generated.  Lastly, the observation that all communication can be tracked using flows brings a different view to how one can manage a network.  This takes away a bit of the complexity of having to access rules for each packet that goes through a switch.  Instead, the packet can be analyzed deeply once and then a simple lookup can be done to verify that the transmission can proceed.  This could greatly simplify the computing requirements of each switch.

(ii) the most glaring problem with the paper

The biggest problem with the paper is that it doesn’t function as well with broadcast-based traffic.  Specifically, the paper mentions ARP and other similar discovery protocols.  My biggest problem with this observation is what would happen if an entire network failed and needed to be completely cold-restarted (say, a power outage).  It would seem that this system could be inundated with ARPs, etc. and the delay in getting each workstation/server/etc. back online would take quite some time.  The paper also doesn’t address stressing the network with a flood of ARP requests and whether or not this would hinder the operation of the switching or control hardware.

(iii) the future research directions of the work

The authors did a great job in pinpointed what still needed to be fixed with the system.  Before listing my own ideas for research directions, it seems that the project should fix the kinks that are present now (a network without broadcast protocols using just Ethane constructs, more realistic switch memory sizing, dynamically loaded rulesets, fully-redundant control hardware/software, etc.).  One observation that I came across that would merit further research are the semantics of the policy language itself.  The language seems quite cumbersome and not clear to read (human-readably, at least).  It would seem that this file could get very cluttered quite quickly.  Some work in this area would greatly simplify how this language works and would make it much easier for operators/administrators to edit this file.  Another future research topic would include using this hardware on a larger, more demanding enterprise network to explore the demands on the switching hardware in a more stressful environment.  Lastly, some more security research could be in order.  Maybe some more software could be developed for end-hosts that would try to guarantee a more end-to-end coverage would be a good research direction.

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) Three most important things

1. The network should be governed by policies declared over high level names. The Ethane network the paper discusses defines the network in terms of users, hosts, and access points rather than low-level because it is convenient to declare which services a user is allowed to use and to which machines they can connect to.

2. Network policy should determine the path that packets follow. Policy should dictate the paths because policy might require packets to pass through an intermediate middlebox such as a proxy and traffic can receive more appropriate service if a path is controlled. Ethane controls the network by implementing a Controller containing the global network policy that determines the path of all packets.

3. The network should enforce a strong binding between a packet and its origin. Addresses are dynamic and change frequently and this loose binding between users and their traffic is a constant target for attacks in networks. Ethane enforces strong bindings by taking over all binding of addresses. The Controller of the network knows where all users and machines are attached and all bindings associated with them.

(ii) Most glaring problem

The most glaring problem would be that broadcast discovery protocols cause disaster on networks by generating huge of overhead traffic. The Ethane network creates larges numbers of flow entries for the Ethane switches and it leads to lots of traffic which could have access to every end-host if malicious.

(iii) Future Research Directions

Future research directions for this work would be to implement the Ethane on a larger network (over 10,000 machines) and see how replicated Controllers handle failures of the primary Controller and how Ethane switches handle larger sized flow tables.

Ethane: Taking control of the Enterprise May 5, 2009

The paper presents Ethane, a network architecture that allows administrators enforce a fine-grain network-wide policy by using a centralized controller that is coupled with flow-based Ethane switches in order to manage admittance and routing of flows. It’s based on the principle of least privilege, where network entities (hosts, switches, etc) need to register and authenticate with the controller before being allowed access to the network resources. Ethane aims to ease network administration, while offering backwards compatibility and incremental deployment, and without the need to modify end hosts. The paper is well-thought and most potential problems with the design are already pointed out by the authors. Some of the main contributions of this paper are:

1. Centralized administration: A centralized control architecture can be practical in administrating a network, while additional controllers can be used to avoid a single point-of-failure. Network management is difficult to compute in a distributed environment, thus a centralized system would be a plus in easing network administration of a distributed network. By directing all traffic to the centralized controller, the controller can manage all the network resources: it can decide who has permission to access the network, set limits on the amount of traffic transmitted in certain flows, etc. It could also protect the network from resource exhaustion attacks by overseeing all network resource allocation. This also reduces broadcast storms, as all broadcast messages are directed to the controller, which can respond with the required information, as opposed to forwarding the broadcast message along to all other hosts (ie all ARP messages can terminate at the controller).
2. Flow-based Admittance: Flow-based admittance makes it easy to put fine-grain requirements on specific traffic flowing through the network, thus adding flexibility to network administration. Switches can restrict the traffic per flow, and set quotas. While flow-based admittance eases administration, at the same time it reduces memory requirements on the switches, because the flow tables can be orders of magnitude smaller than forwarding tables (Ethane only needs to remember the active flows, which at a given time is far less than the number of forwarding packets to remember). Another advantage is that the controller can determine the route that a packet takes, thus having a fine-grain control over routing traffic.
3. Strong binding between a packet and its origin: Ethane is able to manage the network by placing the controller at the heart of the network. That is, the controller also needs to take over address bindings (DHCP), etc. This ownership of name/address binding gives the controller full knowledge about the identity of a sender. Thus, it becomes easy for the controller to identify the source of any network traffic, and apply a centralized policy on this traffic. Without this knowledge, it would be difficult to apply the same security policies, as most would require knowledge of who the sender is. Ethane can do so by being the sole entity that registers and authenticates network users.

Pitfalls: On receipt of new flows, the switches forward the flow packets to the controller, which then needs to decide whether to allow the flow or to drop the packets. This extra step in routing the flow adds one hop, but also could add additional delays due to the controller having to authenticate the flow. While this might not affect bandwidth, it would affect the latency, and time to receive the first byte would increase compared to the usual case. This might be quite problematic for bursty traffic, where each burst could be categorized as a separate flow. Also section 7 claims that 90% of the traffic the researchers observed were broadcast. While Ethane can drastically reduce broadcast messages through the use of the controller, it is my understanding that it would delay the broadcast messages significantly. A broadcast is usually handled by the hardware and is forwarded immediately, whereas with Ethane, it has to go through the controller and be processed before being handed to its destination. This could potentially produce some extra latency in the network.

Future research: While the paper proposes the fully replicated model for the controller, there is not much study presented about it in the paper. For Ethane to be practical, is needs to be decentralized. Though it is true that a single controller can handle traffic from thousands of nodes, the situation could change in busier networks. In either case, there would be networks where a single controller would not be able to cope with administrating all traffic. Therefore it seems essential to build a working model of the proposed fully replicated model of the controller.