Rethinking Enterprise Network Control
This post will cover three closely related papers together:
Rethinking Enterprise Network Control
NOX: Towards an Operating System for Networks
OpenFlow: Enabling Innovation in Campus Networks
These papers are all about simplifying the job of the network administrators, that is, that of monitoring and enforcing policies over a large network.
Existing approaches for network administration are hard to implement and maintain. One of these approaches is using middleboxes at network chokepoints (e.g., firewalls). Another is adding functionality to networks (e.g., using diagnostic tools, controls for VLANs, access-control lists, filters).
These papers advocate the use of an omniscient central controller to simplify the implementation and enforcing of policies and simplifying network equipment. The papers argue that despite its centralized nature, the controller has good scalability in this approach.
The three objectives of this approach are:
1) Network should be governed by policies declared over high-level names (user, server, host instead of IPs)
2) Network routing should be policy aware (network policies declare what each device and network can connect to)
3) Network should enforce a strong binding between a packet and its origin (this is difficult in traditional systems, ip addresses can be spoofed easily; controller manages to overcome theses spoofing attempts by taking over the authentication)
The controller is the brain of the system and is responsible for everything. All switches, users, hosts register with controller with credentials for authentication. Each new flow is sent to the controller, and the controller denies or accepts and provides the routing instructions. Finally, the controller tracks bindings to enable describing policies in terms of users and hosts.
The switches are similar to ethernet switches, but simpler, because the controller takes over many of the features of the switches. The Open Flow paper describes the switches and their interface to the controller in detail. Open Flow makes a pragmatic compromise; it allows researchers to run experiments without vendors to expose internal workings. The interface is basically the flow table, managed by the controller. Flow entries contain a Header (to match packets against), an Action (to tell the switch what to do with the packet), and Per-Flow Data (counters to collect stats). The switch forwards a the first packet of a flow, if the the packet does not match any active entries in its flow table. The control makes a decision; if the flow is allowed the controller computes the flow's route and adds a new entry to the flow tables of all switches along the path.
Going into more details, there are two types of entries in the flow table: 1) per flow entries describing flows to be forwarded, and 2) per host entries describing misbehaving hosts whose packets should be dropped. Obviously doing experiments at the flow level is simple with this architecture. You can also do experiments at the packet level, for this the papers recommends that the switch route these to a netfpga to do a line-rate packet inspection and processing.
NOX paper focuses on providing a programmatic interface over the architecture discussed above. The goal is to enable writing centralized programs that will be deployed on the controller to observe and control the network.
Question: Can this system handle spoofing of Ethernet address?
Answer: Not very easily, not very clear if it can do that.
Question: Can the controller use flow patterns to detect bittorrent activity?
Answer: Yes, but this may lead to false-positives, deep-packet inspection is needed.
Rethinking Enterprise Network Control
NOX: Towards an Operating System for Networks
OpenFlow: Enabling Innovation in Campus Networks
These papers are all about simplifying the job of the network administrators, that is, that of monitoring and enforcing policies over a large network.
Existing approaches for network administration are hard to implement and maintain. One of these approaches is using middleboxes at network chokepoints (e.g., firewalls). Another is adding functionality to networks (e.g., using diagnostic tools, controls for VLANs, access-control lists, filters).
These papers advocate the use of an omniscient central controller to simplify the implementation and enforcing of policies and simplifying network equipment. The papers argue that despite its centralized nature, the controller has good scalability in this approach.
The three objectives of this approach are:
1) Network should be governed by policies declared over high-level names (user, server, host instead of IPs)
2) Network routing should be policy aware (network policies declare what each device and network can connect to)
3) Network should enforce a strong binding between a packet and its origin (this is difficult in traditional systems, ip addresses can be spoofed easily; controller manages to overcome theses spoofing attempts by taking over the authentication)
The controller is the brain of the system and is responsible for everything. All switches, users, hosts register with controller with credentials for authentication. Each new flow is sent to the controller, and the controller denies or accepts and provides the routing instructions. Finally, the controller tracks bindings to enable describing policies in terms of users and hosts.
The switches are similar to ethernet switches, but simpler, because the controller takes over many of the features of the switches. The Open Flow paper describes the switches and their interface to the controller in detail. Open Flow makes a pragmatic compromise; it allows researchers to run experiments without vendors to expose internal workings. The interface is basically the flow table, managed by the controller. Flow entries contain a Header (to match packets against), an Action (to tell the switch what to do with the packet), and Per-Flow Data (counters to collect stats). The switch forwards a the first packet of a flow, if the the packet does not match any active entries in its flow table. The control makes a decision; if the flow is allowed the controller computes the flow's route and adds a new entry to the flow tables of all switches along the path.
Going into more details, there are two types of entries in the flow table: 1) per flow entries describing flows to be forwarded, and 2) per host entries describing misbehaving hosts whose packets should be dropped. Obviously doing experiments at the flow level is simple with this architecture. You can also do experiments at the packet level, for this the papers recommends that the switch route these to a netfpga to do a line-rate packet inspection and processing.
NOX paper focuses on providing a programmatic interface over the architecture discussed above. The goal is to enable writing centralized programs that will be deployed on the controller to observe and control the network.
Question: Can this system handle spoofing of Ethernet address?
Answer: Not very easily, not very clear if it can do that.
Question: Can the controller use flow patterns to detect bittorrent activity?
Answer: Yes, but this may lead to false-positives, deep-packet inspection is needed.
Comments