Ethane: Taking Control of the Enterprise May 5, 2009

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

1. The paper describes a network architecture, Ethane, which features a centralized controller that implements administrator-specified policy and directs traffic by overseeing the handling of flows through the switches under its control. This means that most of the “intelligence” — route computation, policy enforcement etc. — is in the central controller. Switches operate under the instruction of the the controller and thus do not need to make routing decisions or implement policy — they simply need to maintain a connection to the controller, sending the controller link state information and unrecognized flows, and maintaining flow entries sent by the controller to implement packet routing.
2. To ensure scalability and avoid a single point of failure in the central controller, the paper specifies three techniques. The cold standby and warm standby techniques maintain one primary controller, but also keep multiple backup controllers which maintain some amount of state (exactly how much depends on the technique: warm standby maintains network binding state, cold standby does no). The fully replicated technique employs multiple active controllers which handles flow requests in a co-operative manner.
3. Centralizing control of the network leads to a number of interesting consequences. The authors state that they have found it easy to add new features (such as new policy mechanisms or routing algorithms). Changes to the network state can be maintained more consistently. Furthermore, the centralized controller may provide novel and potentially more efficient ways to handle broadcast and multicast traffic.

(ii) The most glaring problem with the paper:

Having a network be logically centralized might lead to some potential security problems which might be less of an issue in a decentralized network. A malicious denial of service attack on the centralized controller, for instance, could cripple the entire network. The paper itself also points out a dual problem: a broadcast request would cause the controller to potentially create a large number of flows in the network and allow the potentially malicious traffic to access all the end hosts.

(iii) The future research directions of the work:

One interesting thing to explore may be to compare the performance of the centralized network and a decentralized network with the corresponding topology (minus the central controller). It appears the architecture may also be used as a way for researchers to obtain information about a network (for example, to study traffic patterns) or to easily deploy new ideas.

Ethane: Taking Control of the Enterprise May 5, 2009

One of the authors of this paper, Scott Shenker, is well-known for his many opinionated papers in networking research. In his papers, he generally steps back from the minute details of his project, and instead has a keen eye for the “big picture” that he hopes the project is meant to achieve. This is one of his typical papers, where he tags the future direction of networks with the concept he describes. The main points as elucidated in the paper are:

1. Can the enterprise network architecture be modified to simplify management of the network? The paper highlights the importance of using fixed high-level names for users, hosts etc., as opposed to dynamically assigned ones like DHCP IP addresses — so that system administrators and users have an easy time identifying various components and services.
2. The paper makes a case that the policy should determine the path that a packet follows. This is generally a critical requirement of network management. For example, having packets from a guest flow through a proxy could be defined by the policy, as a security measure or for charging.
3. The network should enforce a strong binding between a packet and its origin. This is required to easily trace the source of a packet. The indirect effect of this is that users might become more responsible.

One problem I see can be described in this question: Is it scalable to assign a permanent (fixed) name to every entity or service in the network. As mentioned in the paper, extensive use of broadcast is a bad idea since it leads to multiplication in the number of packets, often rendered useless. Ethane relies on broadcast for discovery of services. Also, the authors argue for centralized systems, but there are well-known problems as single point failure and scalability as the network size increases.

This also provides an opening for future research: Can the registration of new services be standardized so there is a well-known point of contact to get information on new services?

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

Three major contributions:

1. Provides a centralized way to manage a network and enforce network level policy.
2. An incrementally deployable solution that can be integrated into existing networks without modification of current hardware.
3. Scalable flow-based software routing.

Major problem with the paper:

Even though they address the issues of fault tolerance for the centralized controller, they do not devote very much time to security. What happens if a centralized controller is compromised? This leaves the entire network vulnerable. Also, ethane does not address ARP storms during failures and network formation.

Future work:

Investigate how an ethane network can be made more secure. Also, do some larger scale experiments. Could this be a viable approach for a backbone ISP?

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

Paper proposes a network with centralized controller along with the extremely simple flow based Ethernet switches to implement network-wide fine-grain policy. Paper argues for new network architecture rather than building a new layer of complexity on top of the networks. Three fundamentals principles embedded in the ethane design philosophies are: network should be governed by policies declared over high level name. Policy should determine the path of the packet flow; network should enforce a strong bounding between a packet and its origin.

First aspect allows the network management at user/host/access point level. Second principle is important to avoid situations where packet avoids the intermediate middlebox which are kept for intrusion detection or other security issues. First aspect requires strong binding between the packet origin and user/hosts.

Ventral controller determines the fate of all packets. Controller decides whether packet should flow or not if so then it provides the route for the packet.  Another component of the network is switches which are dumb components which consist of a flow table and its job is to forward packets under the direction of central controller. System allows using traditional Ethernet switches to be used along with the new switches.

Network does registration, bootstrapping, authentication, flow setup, and forwarding to achieve above goals. Different mechanism can be used to authenticate e.g. MAC address, public keys, username, and password. Switches bootstrap by creating a spanning tree rooted at the controller. Switches send the link-state information once a secure channel has been set. Authentication is performed by controller to which switch sends the packets for which flow entries does not exist in the switch. Communication between users can be decided with the help of controller.

Once switch has an entry it does the forwarding rather than sending it to the controller.

Controller further tracks the bindings which enable to describe policies in terms of users and hosts.  It also provides a namespace interface which can be used by any network managers, auditors. It can further limit the resources grated to a user through putting a filter in switch or by telling the switch to limit a flow’s rate.

Ethane handles the broadcasts and multicast. Controller can set bits and switch need to just forward these packets in case of multicast. Handling broadcast is also new because controller knows all about the network and it can reply the message without doing broadcast. This significantly reduces the traffic but on the cost of controller’s resource utilization.

Paper also addresses the fault tolerance and scalability by two methods. Either by cold-standby where servers comes to picture when primary fails. Disadvantage to this approach is the fact that everyone needs to re-authenticate with the controller. Warm-standby is more complex and it creates separate MST for each controller and monitors the aliveness continuously. Another approach is to replicate the servers and provide requests from the switches to be server in a distributed fashion. In fully-replicated mode switch needs to authenticate with only one controller.

Paper discusses the shortcomings when deploying Ethane on legacy networks.

These include impact of broadcast and service discovery. It has to trust that end-host should not relay traffic in violation of the network policy. Non standard use of ports can fool ethane. Similarly MAC address spoofing can cheat Ethane also.

Ethane: Taking Control of the Enterprise May 5, 2009

Most important contributions

This paper introduces a central management approach to administering an enterprise network in a central and policy-controlled way. It tries to emulate the features currently provided by patches to the Ethernet architecture like VLANs, 802.1x and NAT. In contrast to current enterprise networks where configuration and security policy is deployed on a large number of increasingly intelligent network switches, it tries to centralize this configuration information again on a single centralized entity, the Controller. The switches in this model perform forwarding based on network flows, which have to be permitted by the controller. A newly established flow is first forwarded to the controller, which checks his policy on whether it should be allowed. If the answer is positive, the central controller contacts all switches on the (policy-determined) path for this flow and fills their forwarding tables. Therefore, malicious flows can be blocked at the first switch which is encountered by the unwanted traffic and is not blocked at the destination or some intermediary point. Configuration information and mappings between host, user and MAC address are also centrally stored on the controller host, which potentially eliminates the need for broadcast traffic. This central controller can also enable Multicast on this managed network. With the switches instructed to ignore traffic that is outside the currently stored mappings, it is possible by implementing central logging of authentication and flow establishment to map traffic origins for any point in time on the network. Authentication of hosts and users is always enforced. A policy language is also defined, which allows reasoning about hosts, users, protocols and allows for redirection, denying and allowing certain traffic. Early results on performance look promising for the scalability of this central controller approach.

Most glaring problem

It has yet to be seen how this approach delivers any security improvements over the older mechanisms, as long as tunneling techniques exist and users can provide routing functionality on their own machines they are able to circumvent the centralized security measures.

Future work

An interesting research opportunity (at least from my experience as a network administrator from an heavily managed university network) would be to increase the interactivity of the management process. Expert users tend to use circumvention techniques because the administrative and managing process of the network takes a very long time, so making this process interactive and to directly integrate it into the network architecture (i.e. by providing an “apply for permitting this flow” website) would be interesting. Also, end users tend to know best when they’re looking for which traffic quality requirements, so interactive management systems for these issues are also interesting.

Ethane: Taking Control of the Enterprise May 5, 2009

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

1. An ethane switch uses a much simplified switch than a typical router.  Since its behavior will be preset by a controller unit, it no longer needs an expansive forwarding table and does not need to run routing protocols for discovery. This means that switches will be quick and inexpensive both in hardware and power throughout the network.

2. Ethane also can easily track all the names, ports and addresses even as users or machines change locations around the network.  This provides extra-security for the network while allowing routing to be easily specified by a higher level language. By taking care of this book keeping the network programmer can use the abstraction of users, conditions and actions to specify flows throughout the network. This allows you to create flows for performance or require flows to go through certain checkpoints if you desire, which can be useful for security or accounting reasons.

3. The most astounding and important findings of the paper is how well this architecture scales. The author projects that a single controller can host a network with over 20,000 hosts. He also suggests was that multiple controllers can be used synchronously which would increase the number of hosts but he does not say that it would expand the network linearly (e.g. 2 controllers = 40,000 etc.).

(ii) The most glaring problem with the paper:

The section on performance during failures was very hard to understand. There is very little given about the setup of the network. I must assume that the case that is tested is with just one controller and the reconvergence time is just the time it takes for the controller to discover the missing link, calculate new paths and send the new paths to all affected switches, yet this is unstated. It states that upon link failure the controller will be flooded with a flurry of requests and performance will fall but does not indicate the extent to which this may occur. It is therefore hard to guess what this will mean for different sized networks.

(iii) The future research directions of the work:

More research is necessary in using a network with multiple controllers in the configurations prescribed by the authors, since no performance number were provided. Another topic would be comparing actual power numbers from the Ethane solution against traditional networks for comparison. I could envision more of an adaptive approach to deciding the flows where the controller makes decisions based on recent measurements instead of only using preset rules. I would think that finding a way where you could specify rules such as mandatory flows and optional flows might allow the system to find better solutions depending on the current network conditions.

Ethane: Taking Control of the Enterprise May 5, 2009

This paper talks about a network architecture, Ethane for managing enterprise scale networks. The architecture consists of central controller that manages the admittance and routing of flows and is backward compatible by virtue of being incrementally deployable. It also emphasizes network security and reliability issues as if often the bane of enterprise networks.

The paper talks about three essential traits required of any network management solution:

• Network should be managed by higher level names for entities participating in the network, not in terms of low-level or dynamically-allocated addresses.
• Path taken by the packets should be dictated by the policy for finer-level control and greater visibility.
• A strong binding should be established between the packet and its source of origin.

The design of ethane ensures that security follows management, incrementally deployable and incorporates lessons from the deployment experience of the authors. The architecture consists of a central controller which is the brain of the network. All the named entities are registered with it. It provides the services of authentication for the named entities, tracks bindings, interfacing namespace to network managers, permission checks and access granting, and enforcing resource limits. One of the important highlights of Ethane is that keep tracking of bindings even when switches, hosts and user come and go out of the system in a dynamic fashion. The design also provides for fault-tolerance by deploying multiple controllers to ensure enough redundancy in case of failures. Another important highlight of the paper is its replication of controllers using three models, namely, cold standby, warm standby and fully-replicated models and the analysis of the three approaches. Each switch connected to controller through direction connection or via other switches runs a local switch manager. The task of this manager is to establish and maintain the secure channel to the controller, to monitor link status, and to provide an interface for any additional switch-specific management and diagnostics. Another important highlight is a language, Pol-Eth, for declaring policy in an Ethane network and is quite comprehensive and covers all the necessary network tasks.

The authors have also discussed the deployment of the architecture, the issues faced and the results. The paper also discusses some shortcomings of Ethane, namely, huge overhead from the traffic generated by the broadcast and service discovery protocols, spoofing Ethernet addresses, compromise of policy by application-layer routing and some malicious tasks performed by the user in the garb of different standard flows.

Future work can be done in making the system more robust to failures by managing the binding information provided by Ethane controllers.

Ethane: Taking Control of the Enterprise May 5, 2009

Three Important Contributions

1) Ethane uses the existing network architecture. Users authenticate with a centralized controller before allowed on the network similar to wifi hotspots. The controller manage switch forwarding tables to add routes on a flow basis. Controllers can be replicated for fault tolerance. The controller knows the entire network topology so it can route flows in the network.

2) High level names uses by policy declarations. Secure bindings are used to identify a host attached to the network. Ethane will identify a host by the switch port  and MAC address.

3) A policy language Pol-Eth was implemented. Ethane has been deployed at Stanford with about 300 hosts and the paper draws on the experience. NetFPGAs were used to design Ethane switches and the Controller was implemented on a standard Linux PC.

Weaknesses

Hosts will have to be trusted not to forward packets in violation of network policy. The paper also implements an Ethane switch which is necessary despite saying it will run on existing network architectures.

Further Research

Further research can be done on fixing the shortcomings of Ethane being able to deal with relaying traffic to untrusted hosts, spoof MAC addresses, better VLAN support, common port usage for malicious purposes, and develop new protocols or ways of minimizing traffic of broadcast discovery protocols.

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

The Ethane architecture demonstrates the integration of protocol layers. Switching decisions in an Ethane cloud are based on information gathered from layers 2 through 7. A central controller makes decisions based on shortest path and policy. This allows security and traffic management requirements to be managed at a single location and implemented throughout the switching cloud. Managing network service and security from a single location greatly simplifies network management.

The Ethane system is incrementally deployable. Ethane switches can be delpoyed incrementally in an existing network. Previous systems required that all switches in a cloud be upgraded together. Incremental deployment allows network operators to target trouble areas with upgraded equipment improving service while limiting cost. Additional deployments will futher improve service as needed.

Ethane switches are much simpler than standard Ethernet switches. Switching decisions are made at the central controller. Switches take decision information from the controller on a per flow bases. The forwarding task in the switch is reduced to a table lookup for the relatively few flows that pass through the switch. The spanning tree algorithm and other switching and routing functions are not required to by performed by Ethane switches. Intelligence is removed from switches and placed in the central controller.

The switches are unable to make path routing decisions without consulting the contoller. This places extra overhead on all connections akin to a signalled call-setup. Many flows are extemely short lived and the overhead of the path selection signalling exceeds the otherwise short duration of the flow. The completion time of short exchanges, e.g., DNS queries, is extended by the delay in path setup.

The Ethane system could benefit from the use of default paths for traffic identified as short lived. Short exchange services could be implemented at or near the controller in order to expedite these exchanges. Servicing the query-type traffic locally allows the return path to be establishing in parallel with the completion of the request.

Additional work need to be done on routing decisions. Centralized routing decisions allows the exploitation of multiple parallel routes. Widest path routing can allow greater network utilization and higher throughput. Routing can be optimized and path decisions can be dynamically updated as traffic patterns emerge.

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

Important Things:
1) A network built with very simple switching elements and an intelligent and modifiable central controller can be used to implement advanced network features, provide tight security, and extend the capabilities of the network in new ways.
2) Through the use of bindings between users, hostnames, addresses, and physical ports, network policies specifying what traffic is allowed and what path it should take can be expressed in terms of users and hostnames. Also, bindings allows protocols that use broadcast for discovery (such as ARP) to be handled by a query to the central controller.
3) Questions of scalability are addressed. Specifically, they estimate how large of a network a single controller could handle, how large the switches’ flow tables need to be, and how the controller might be replicated for redundancy and load balancing.

Problem:
While providing user-authenticated network access is an attractive and flexible way to implement network security in the enterprise, their implementation of this relies on a one-to-one mapping between users and hosts. This falls apart in the presence of multi-user systems. Sensitive applications should implement their own user authentication system anyway, but faulty user authentication at the network level may give administrators a false sense of security.

Future Work:
There are many unexplored applications for a network like Ethane. The framework provides a lot of flexibility in introducting new functionality into the network. Future work should explore this flexibility in a variety of network environments and applications.

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.

Ethane: Taking Control of the Enterprise May 5, 2009

The authors of the paper propose and implement Ethane, a flow based enterprise network architecture with a centralized control manager and a simplified data plane. Enterprise networks run a wide variety of applications and require high reliability and security for error-free operation. There have been earlier approaches which propose solutions like the introduction of middle boxes in congested portions of the network and others which require network functionality augmentation. But these approaches are not without shortcomings and require careful reconsideration. Ethane takes a departure from them and proposes a network architecture governed by the principles of name based policies, policy based path determination and packet-origin binding. To this end Ethane is architected using a centralized controller that makes policy based flow decisions and relatively dumb switches that carry out the forwarding function with minimal overhead. Ethane builds upon an earlier SANE architecture by adding broad management techniques with implicit security and incremental deployability of network functions. The main points discussed in the paper are Ethane’s implementation detail, Pol-Eth policy language and Ethane’s performance and scalability.

Ethane implementation draws from the basic guideline that, end hosts without explicit permissions should not be allowed to communicate. Per flow, per host routing decisions are made by the central controller which reads the protocol headers and compares it against the global policy information to determine the flow type. Ethane switches bootstrap the spanning tree of the network topology to the controller to enable it to determine the best route between any two end hosts. Flow and route information is then populated in the tables contained in the switches which consult them to forward packets appropriately. Ethane controls the binding of addresses with ports and it requires all hosts to authenticate and register themselves. This way the controller can track host movement and make minimal updates to the routing information. Also this state information can be used to journal activities in the network and perform efficient auditing. Any unregistered flow is first routed to the controller by a switch and the controller then accepts or denies it by checking the flow against policy information and registers/de-registers it appropriately before forwarding it back to the switch. Flow tables inside Ethane switches are simple and small for fast lookup and memory overhead reduction (eliminating TCAM use). Each flow table contains per-flow and per-host entries for application level forwarding and host authentication. A local switch manager inside the switches communicates the neighbor-discovery based topology information to the controller to enable it to construct optimal routes. Further switches outside a controller’s domain are controlled by requiring them to create IP tunnels to that controller’s domain. The controller’s job thus in a nutshell is to provide registration and authentication services, perform access and rights checking on incoming flows, communicate the optimal routing information to switches based on the network’s spanning tree and use journaling information to keep a tab on resource usage by the network’s leaves.

The author’s implement and maintain the network policy information inside the controller using a condition-action style language called Pol-Eth. Conditions are predicates based on user, host and access point source and destinations and the application protocols used by them. Based on a condition, actions like denying, granting access are determined. The authors use a two stage compiled form of Pol-Eth (from Pol-Eth to C++ and C++ to binary) to avoid the overhead of interpreting it. Ethane’s scalability is demonstrated in terms of the number of endhosts it can support without significant overhead on the controller. The authors do a relatively naïve comparison with LBL and Stanford networks and claim a possible seamless extension of Ethane to 10,000 hosts. Fault tolerance of Ethane stems from the cold-standby controllers which are stateless replicated controllers maintained in the network leveraged in case of failure by having the switches bootstrap onto them. The approximate reconfiguration times for cold-standby boot up (re-populating state, routing and flow table information) are demonstrated by the authors as being few tens of seconds.

Ethane’s support for broadcast is limited by the number of flow-port bitmaps that can maintained at any given switch. Further Ethane is vulnerable to the endhosts transmitting application packets violating network policies and of malicious hosts spoofing their Ethernet addresses. Even with these shortcomings Ethane opens up a new arena of centralized control based enterprise networks for achieving better security, routing performance and scalability. As suggested in the paper, future research can be conducted to make Ethane switches smarter and to find alternatives to service discovery to leverage the power of multicast and broadcast.

Ethane: Taking Control of the Enterprise May 5, 2009

i)

1) While the internet infrastructure and protocols are fully decentralized (as they should be) an enterprise can benefit from a more centralized internal networking infrastructure. While initially this might seem bad since there could be a single point of failure, with replication and distributing replicas of the central authority throughout the internal topology, a high degree of redundancy can be achieved.

2) With all traffic going through a central authority that knows the entire network topology it is feasible for that authority to calculate static routes for flows which allows the Ethane switches to be very “dumb” and significantly cuts down on the hardware cost of these switches.

3) Security policies should be in terms of high level abstractions such as users, departments, or hosts, rather than low level information such as IP address, etc.

ii) I think one flaw of this paper is not addressing how important the security of the controller is. If an attacker can compromise the controller then they can potentially see every packet going through the network as well as gain access to the entire network. It is very important that the controller be made as secure as possible.

iii) I think the future research for Ethane is investigating if it can be deployed to enterprises that have multiple locations around the world. For instance would it be feasible to have an authority at each location that handles traffic for that location but then have the real central authority at the enterprises headquarters.

Ethane: Taking Control of the Enterprise May 5, 2009

The paper presents a new network architecture that should ease the network management.

The main idea of the proposed approach is that both the host and the user of such host must be registered by a central registry, the Controller, in order to be allow to use the network. The Controller is also responsible for propagating the network policies, created by the network operators, among the different switches present in system. The Controller stores the entire network configuration file and it also has a complete knowledge about the network structure.

The three best points of this approach are:

1. Centralized architecture. This facilitates a lot the management and the understanding of the network. A policy change results in only a single local update. This means that there are not interrelated policies between two or more nodes (switch, router) over the network anymore. All the policies are fully expressed and defined in the Controller. It then provides to update the forwarding rules in the appropriate nodes of the network.
2. Network structure always available. By storing the entire network configuration, the Controller always has a complete overview and knowledge of the network configuration and structure. This facilitates a much better general understanding of the system that can help with diagnosing and fixing errors, as well as it eases the reasoning about possible updates and changes of policies. In a distributed environment this is usually a quite hard and complex task that is extremely error prone and time consuming.
3. Incremental deployment. Introducing a new technique, approach, protocol etc. is always a very difficult and challenging task in the network environment. The proposed approach can be implemented in incremental steps, by gradually increasing  the number of Ethane switches deployed alongside existing Ethernet switches. This can be a key factor for the success of Ethane.

As major drawbacks I can list at least the following:

1. Ethane requires a massive change in the network hardware. For a complete deployment it would require to change all the switches of the network. This can really be a limiting factor.
2. Ethane does not work with multi-user operating systems since it is not possible to distinguish among different users operating concurrently on the same machine. It is also not clear to me whether Ethane would work with a machine hosting multiple virtual machines sharing the same NIC. My guess is no.
3. In the performance analysis section of the paper, Ethane is not compared with another implementation. In this way, it is not possible to understand whether Ethane has brought some real improvements. Since Ethane was tested on an already existing network, it would have been interesting to compare its performance and its claimed management easiness with the previous system.

As direction for future research, I would definitely try to provide support for virtualization techniques. Nowadays, it is hard to think to a network that does not have several machines running VMs on top of them.

Ethane: Taking Control of the Enterprise May 5, 2009

One of the primary contributions of the paper is that the authors identified that the enterprise environment is very different from the internet and has very different requirements from that of the internet. More strict guarantees etc. are expected for the enterprise. But it has been in the past done by manual labor by patching up protocols that run over the internet. But with a single administrative domain, it is possible to have a lot of centralization. Centralization is not a bad thing since commodity PC’s today can handle several thousands of requests per second, also replication can help boost performance and scalability without having a single point of failure or a bottleneck for performance.

Another contribution is that their approach uses extremely simple commodity Ethernet switches (hardware) and couples them with the centralized controller which manages all the routing decisions and other fine grained policy decisions. The central controller is responsible for imposing the different admittance rules for network traffic by inserting appropriate flow entries into the ‘dumb’ switches.

One of the strengths of the paper is the fact that they have implemented their ideas on Stanford University’s network and the deployment supports a few hundred users. A working prototype that is actually being used for running user traffic adds a lot of credibility to their work.

Their approach is essentially similar to a software router except that they have decided to use one single PC as the central controller for several switches instead of separate software controllers running on each single switch. The central controller is the main authority with the global picture.

One potential weak point that I see in the paper is that in their deployment, the authors state that the policy file for the network is 132 lines long. They do not state the average complexity of such policies in typical deployment scenarios. If most deployments usually have just 100-200 lines, then centralization of the controller for specifying policy might not be a huge gain. The real complexity of deploying the policy over separate switches is not brought out by the paper. Another challenge to their approach is that the installed switches need to be replaced with Ethane switches to support the central controller. Most existing switches do not have support for connecting to external controllers.

A potential direction for research could be to explore areas other than the enterprise network where their approach could be useful. Another direction could be standardizing the protocol for communication between the central controller and the individual switches. This would allow the use of a single central controller which can control switches from several different vendors. One of the primary uses of separating the routing software from the actual hardware is extensibility. However, to get extensibility, one challenge is to come up with the right set of primitives that the hardware must support. Features such as rewriting MAC addresses, modifying TTLs, checksums etc in hardware are usually common in routers, but not so common in L2 switches. So exploring the right set of primitives that a switch or router must support for suitable extensibility would be a useful direction for research.

Ethane: Taking control of the Enterprise May 5, 2009

1. Centralized control

The Ethane design proposed by the paper cetralizes control. Centralized control, while having its issues, simplifies structure and makes it possible to explore solutions and implementations not possible with distributed control. Broadcasting and the learning process that a network device such as a switch might have to go through when it comes up is made unnecessary. All it would need to do would be to contact the central controller to obtain information abotu the network. It also makes it easier to implement new policies, make changes, etc, since they would have to be made only at central controller. In addition, since the central controller is a single device used for a specific purpose, it can be customized and provided with the required computational capacity.

2. Policies determined in terms of high level names.

Ethane performs bindings between users, hosts and address. This makes spoofing difficult. Using high level names to declare policies seems natural and logical. It also allows different users of the same host to be governed by different policies. It also provodes for a flexibility by making it easy for hosts and users to move around in the network without having to declare the policies all over again.

3. Ethane switches. Simple and efficient

Ethane uses switches to inter-connect multiple hosts to the controller. These switches are a lot simpler than the ones used by Ethernet. Since all control and routing occurs at the central controller, these switches are not required to posses large memories or the computational power to check for source-address spoofing, support for VLAN etc. They are only required to maintain much smaller flow tables and a few per flow statistics.

Oversights

It is a tough job to design an efficient, secure system with minimum overhead. There exist several trade-offs between security and overhead that needed to be made in the design of Ethane. Providing for a central controller and requiring every flow to be registered and authenticated by the central controller would add a bottleneck in the network. Conections between end hosts or switches and the controller would be used frequently and by several hosts hence increasing the load on these connections. Accomodating dynamically changing policies, provinding for syncronization between multiple central controllers, etc adds overhead as well.

Future Work

The design can be extended to support multiple central controllers, thereby distributing central control to an extent. A policy to achieve  sycronization between these multiple central units would need to be developed. This would speed up the flow authentication process, reduce the load on each central controller and provide resiliency.

Ethane: Taking Control of the Enterprise May 5, 2009

Three Important Things:

• The authors gave an outline for what they believed should be the fundamental principles behind any network management solution. Governing policies should deal with high-level names such as users, devices etc. This is opposed to applying filters at lower levels like IP addresses, which are in constant dynamic churn. Policy enforcement entails directing the flow of packets explicitly, and ensuring a strong binding between a packet and its high-level origin. A network control architecture called Ethane is proposed to implement these ideas.
• At the heart of the Ethane solution lies the centralized controller. The idea is that every network transaction is monitored and moderated by the controller. It handles registration and authentication of users and devices. This allows it to assign track the bindings between low-level entities and high-level identifiers. On the basis of these identifiers the controller can perform access control on packet flows, enforce resource limits on users, and program switches to implement multicast and anycast.
• A major concern for a centralized network architecture is scalability, as the controller is involved in the setup of every distinct packet flow in the network.  Experimental results on a small network showed worst case setup times of 1.5ms. Results for a large network trace showed latencies of .6ms for 6,000 setup requests per second and .4ms for 2,000 reqs/sec. This lead the authors to conclude that a single controller could handle up to 20,000 hosts.

Glaring Problem:

There are many enterprise class organizations such as universities, corporations, and governments that might benefit from adopting Ethane. However many of these logically contiguous networks are physically separated across numerous offices scattered around the globe.  The paper claims to present an enterprise solution but makes little or no mention of such a deployment and its associated implementation concerns.

Future Work:

The Ethane project showed that it is possible to administer a fairly large network with numerous users and device classes using a central controller. Having a viable centralized network management solution is a powerful tool, and I would like to see exploration of other possible settings for Ethane deployments. These could include high demand settings like server farms, or high security settings like internal government networks.

Ethane: Taking Control of the Enterprise May 5, 2009

Ethane allows network managers to define a single network-wide fine-grain policy and enforce it directly. They use a centralized controller and very simple switches to manage policies by controlling routing of flows. The other solutions to managing a enterprise network hides complexity but does not remove it.

Important Parts of the Paper:
1.) Centralize Controller
The centralize controller allows Ethane to enforce its policies throughout the network. Every host basically has to ask permission to do something to the controller, if it hasn’t been ask before. This design is simple but make the controller a very complex entity. The controller needs to keep track of the host via addresses and ports, what policies to use, controlling resources and needs to keep track of the switches and other controllers used. It keeps track of host via an authentication step similar to the authentication used for wifi at UCSD. Having a centralize controller gives a single point of failure so the controller is replicated throughout the network. They suggest different types of replications that can be used with Ethane including: cold-standby, warm-standby and fully replicated. From their performance evaluation though they show it is possible for one controller to manage a network of 20,000 host.
2.) policy language
Pol-Eth is the sample policy language that was developed but not require for a Ethane network. The policy language allows the network administrator to configure the network based on users, groups, hosts, access points, protocols and services. Configuring using higher level terms like these instead of addresses were the authors attempt to minimize the human errors in configurable networks. The implementation of Pol-Eth requires a compilation process and a just in time search function. The problem with this is the controller needs to be relinked when policies are changed.
3.) Switches
The authors of Ethane kept the switches stupid compare to it’s counterpart ethernet switches. Ethane switches are very simple as they only need to manage flow tables that are an order magnitude smaller than ethernet switches, because Ethernet switches need flow tables for all possible encounters while Ethane just needs flow tables for all active flows. Allowing Ethane to work on such simple switches allows Ethane to be more flexible. Anyone can create or edit switches in their network to help better configure and manager their network. Having the Ethane switches simpler than their Ethernet switches allows for smaller and lighter power consuming switches.

Glaring Problem:
Ethane still has problems with security. A user can spoof a mac address to make the controller send to a certain host. In the case of Ethane, a higher level application can go around the policies. For example A can talk to B but cannot talk to C, so A sends a message to B to send to C. This goes around the policy set by the controller. It also is not obvious how many switches and controllers are needed to produce a network that is efficient and scales.

Future Work:
Ethane is a good step in controlling routing flows in a enterprise network which is important in certain companies. Although it won’t be able to scale the internet, it can easily scale a enterprise of 20,000 host. Since Ethane uses simple switches and a centralize controller that know everything, Ethane is very flexible. From their work Ethane was also easier to manage then expected.

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.

Ethane: Taking Control of the Enterprise May 5, 2009

The purpose of this article was to describe a new network architecture called Ethane, a centralized control design that is intended to improve network performance in the areas of flow control, security, origin identification, and incremental deployability. The key points in this article were:

1.Centralized control via registration to the controller allows for extremely simple policy management and implementation. This centralized structure also allows for the greatest amount of control for the administrator. The method described in this paper allows for extremely fine grained control over the network capabilities and actions of the end-users and also allows for superior auditing of all activities.

2.The use of a system that could be deployed incrementally and alongside legacy hardware was critical to the deployment of a working prototype that could be used for realistic testing and development. This type of system has implications for many other new network technologies and their deployement in the future. The ability of the authors to deploy and test a working system was invaluable to their understanding of how the system needed to be set up and implemented for optimal performance.

3.This system design assumes trusted end-users who obey the rules associated with the controller regarding ports used, MAC addresses, etc. This is a serious concern on networks that have many computers joining and leaving on a regular basis as well as for those that allow any user to join and something that would likely need to be addressed in future work as a way to improve the functionality of the system.

One issue that I saw with the paper is that while they state that they believe that a controller could handle 10,000 hosts, there was no data to back this up and there was not a large amount of scalability measurements. The did have a thorough discussion of the number of switches needed and the performance implications but the controller did not receive as much. Admittedly, the scalability is one of the hardest things to measure so this is a minor complaint.

The future research of this paper would be to extend such a system to a larger target network, improve the security functionality regarding untrusted end-users, and the implementation of other incrementally deployable network hardware and services. Another area would be the improvement of the centralized control system as a model for network administration. All areas are being actively researched now and several show promise for what the future network might look like.