Simplifying Enterprise Configuration using Classes Cheng Tien Ee, UC Berkeley Scott Shenker, UC Berkeley Lakshminarayanan Subramanian, New York University Configuring large-scale enterprise networks is often a nightmare for network +administrators. The role of configuration has increased substantially with the +threats posed by worms, malware and attackers. To mitigate these threats, +network administrators have been forced to deploy a range of middleboxes +including firewalls, NATs, VLANs and NIDS that act on the network data path to +detect and drop undesirable traffic. However, the current model of implementing +access control in such networks is both cumbersome as well as error-prone; the +process involves a complex combination of bridging, routing and manual +installation of packet filters in routers along the data path. One of the fundamental reasons behind the difficulty in configuring such +networks is the incongruence in configurability of the control and the data +planes. Today, most of the middle-box configuration occurs in the data plane; +operators install, along the data path, packet filters which need to be +modified with each change in topology or routing. This incongruence stems from +the fact that routing and filtering are treated as separate problems. The +management burden increases with network size: in large-scale networks, +low-level views available to operators, that is, filters at each individual +router or switch, makes it difficult to reason about connectivity issues within +the overall network, increasing the likelihood of misconfiguration errors. To circumvent this problem, we propose the design of Sapheniea, a system that +introduces an explicit configuration binding between the control and data +planes using a single class parameter. In Sapheniea, traffic is first +classified based on some policy, where the granularity of a class is +configurable. Subsequently, middle-boxes in the data plane can apply policies +tailored for each class, and the control plane allows route determination on a +per-class basis. This explicit binding between the two planes eliminates the +need for operator intervention when routes change. Another important aspect of +Sapheniea is the flexibility in defining the most basic relationship between +classes, which is whether one class of traffic can be carried on links of +another. This relationship can be arbitrary and captured by a classgraph which +we require to be directed acyclic. We motivate routing with classes in Sapheniea using two examples: (a) access +control, and (b) traffic channeling through choke-points. Access Control: Operators add filters at routers to restrict access to certain +resources in the network. The placement of filters is very much topology +dependent, and legacy filters need to be accounted for when topology changes. +The difficulty of grasping the complete picture is compounded with the fact +that operators who installed seemingly cryptic legacy filters may no longer be +available to assist in the process. Sapheniea can help resolve this issue, +operators install, along the data path, packet filters which need to be +modified with each change in topology or routing. This incongruence stems from +the fact that routing and filtering are treated as separate problems. The +management burden increases with network size: in large-scale networks, +low-level views available to operators, that is, filters at each individual +router or switch, makes it difficult to reason about connectivity issues within +the overall network, increasing the likelihood of misconfiguration errors. To circumvent this problem, we propose the design of Sapheniea, a system that +introduces an explicit configuration binding between the control and data +planes using a single class parameter. In Sapheniea, traffic is first +classified based on some policy, where the granularity of a class is +configurable. Subsequently, middle-boxes in the data plane can apply policies +tailored for each class, and the control plane allows route determination on a +per-class basis. This explicit binding between the two planes eliminates the +need for operator intervention when routes change. Another important aspect of +Sapheniea is the flexibility in defining the most basic relationship between +classes, which is whether one class of traffic can be carried on links of +another. This relationship can be arbitrary and captured by a classgraph which +we require to be directed acyclic. We motivate routing with classes in Sapheniea using two examples: (a) access +control, and (b) traffic channeling through choke-points. Access Control: Operators add filters at routers to restrict access to certain +resources in the network. The placement of filters is very much topology +dependent, and legacy filters need to be accounted for when topology changes. +The difficulty of grasping the complete picture is compounded with the fact +that operators who installed seemingly cryptic legacy filters may no longer be +available to assist in the process. Sapheniea can help resolve this issue, +beginning with the assignment of classes to links and traffic. The level of +indirection brought about by this assignment reduces the complexity of filters: +rather than say ?filter packets from 1.2.3.0/24, 1.2.4.0/24?, we instead enlist +the assistance of the routing protocol to say ?never forward packets with +classes lower than B?. The association of a class to each link enables routing +based on classes and provides the following advantages: (1) if, at a point in +the network, no route to destination exists for a certain clas s, that information is automatically propagated by the routing protocol without +the need to add filters at that location; (2) the lack of any route and hence +visibility implies that traffic will not even begin to be forwarded through the +network and subsequently dropped only at the end-host, reducing the impact on +eligible traffic being carried; (3) the effect of link addition or removal on +the admission of traffic is updated automatically by the routing protocol +without further manual configuration; (4) by using the network and +class-graphs, the operator can, at a glance, deduce and control the type of +traffic allowed at a particular region. Traffic Channeling: The traditional method used for channeling of packets +through choke-points (such as firewalls, NIDS boxes) is the manipulation of h +we require to be directed acyclic. We motivate routing with classes in Sapheniea using two examples: (a) access +control, and (b) traffic channeling through choke-points. Access Control: Operators add filters at routers to restrict access to certain +resources in the network. The placement of filters is very much topology +dependent, and legacy filters need to be accounted for when topology changes. +The difficulty of grasping the complete picture is compounded with the fact +that operators who installed seemingly cryptic legacy filters may no longer be +available to assist in the process. Sapheniea can help resolve this issue, +beginning with the assignment of classes to links and traffic. The level of +indirection brought about by this assignment reduces the complexity of filters: +rather than say ?filter packets from 1.2.3.0/24, 1.2.4.0/24?, we instead enlist +the assistance of the routing protocol to say ?never forward packets with +classes lower than B?. The association of a class to each link enables routing +based on classes and provides the following advantages: (1) if, at a point in +the network, no route to destination exists for a certain clas s, that information is automatically propagated by the routing protocol without +the need to add filters at that location; (2) the lack of any route and hence +visibility implies that traffic will not even begin to be forwarded through the +network and subsequently dropped only at the end-host, reducing the impact on +eligible traffic being carried; (3) the effect of link addition or removal on +the admission of traffic is updated automatically by the routing protocol +without further manual configuration; (4) by using the network and +class-graphs, the operator can, at a glance, deduce and control the type of +traffic allowed at a particular region. Traffic Channeling: The traditional method used for channeling of packets +through choke-points (such as firewalls, NIDS boxes) is the manipulation of t +the need to add filters at that location; (2) the lack of any route and hence +visibility implies that traffic will not even begin to be forwarded through the +network and subsequently dropped only at the end-host, reducing the impact on +eligible traffic being carried; (3) the effect of link addition or removal on +the admission of traffic is updated automatically by the routing protocol +without further manual configuration; (4) by using the network and +class-graphs, the operator can, at a glance, deduce and control the type of +traffic allowed at a particular region. Traffic Channeling: The traditional method used for channeling of packets +through choke-points (such as firewalls, NIDS boxes) is the manipulation of +physical network connections. This requires careful planning and execution at +the ground level, and can typically result in tedious re-wiring of cables when +the network topology changes. Worse, unintentional connections, such as those +via wireless links, can bridge two otherwise separate networks. Rather than +attempting to control the physical connectivity, we instead only mandate that +the network be well connected physically, then create logical networks with +links that are a subset of the physical network. This is similar to VLANs, +except that this concept is extended to layer-3 networks, and, we also show +that the usage of classes and the ability to define inter-class relationships +adds a degree of flexibility which will also be beneficial to VLANs. Upon +entering the network, traffic can be classified based on some policy, w ith the traffic class subsequently resulting in a particular logical graph being +used for forwarding. Thus, middle-boxes? placement becomes much less dependent +on the physical topology: links? classes can be configured remotely such that +traffic of interest can be channeled accordingly. +that the usage of classes and the ability to define inter-class relationships +adds a degree of flexibility which will also be beneficial to VLANs. Upon +entering the network, traffic can be classified based on some policy, w ith the traffic class subsequently resulting in a particular logical graph being +used for forwarding. Thus, middle-boxes? placement becomes much less dependent +on the physical topology: links? classes can be configured remotely such that +traffic of interest can be channeled accordingly.