Abstract The various services used to manage enterprise networks can take a toll on network operators. The fragility and cumbersome task of updating code can cause a type of overhead all to itself that can hinder a network operators time
Download 20.64 Kb.
|
- Navigate this page:
- Problem Statement
- I. Introduction
- II. Related Work
- III. Proposed Solution
- IV. Conclusion and Direction for Further Work
| Giant Declarative Network Management
Sherod J Emerson Columbus State University Network Management - Spring Semester 2010 CPSC-6157-V01 May 1, 2010
The various services used to manage enterprise networks can take a toll on network operators. The fragility and cumbersome task of updating code can cause a type of overhead all to itself that can hinder a network operators time. Here is submitted a method that will address configuration of several network management services and an improvement which will allow its application to large scale networks. Problem Statement Application level languages in the form of declarative languages have been adopted to successfully declare controls and policies as well as filter information. However, the use of VLANS, ACL and NATS for management of enterprise networks has been necessary. These approaches are not optimal as they are composed of an inordinate amount of code that may or may not be compatible with the current needs of the network. The question posed by the author is can the use of declarative management techniques via declarative languages be used to replace the aforementioned approaches for enterprise networks (NAT, ACL, VLANs) in order to make network configuration more efficient. I. Introduction FML is a high-level declarative language created by Hinrichs, T. L., Gude, N. S., Casado, M., Mitchell, J. C., and Shenker, S., hereinafter Hinrichs et al, for establishing network policies. FML’s implementation is in polynomial time in general and can be in some instances linear time. The importance of linear time is that it can allow network speed decisions [1]. This language is applied to NOX, which enforces policies on flows and authenticates all network principles. NOX is a general control platform upon which network wide control applications can be built. NOX provides a global view of the network topology and notification abilities for network events. Applications can also control the behavior of the network by setting up flows in the network switches and sending packets. FML intercepts all new flows on the network and checks them against the current policy. Permitted flows routed via the NOX routing library to calculate a compliant route, and adds the flow to the flow-table of each switch along the path. FML works via manipulation of variables of source and target users and host (us, ut, hs, ht respectively), source and target access points, (as, at respectively), Protocol (prot), and whether a flow is requested or not (request). Keywords can be applied to variables to perform such functions as allowing, disallowing or forcing flow through a specific node.FML information can be disparate across several different files such as remote databases for names. FML allows for distributed authorship and provides for conflict resolution via keywords and FML cascade. A FML policy is a collection of FML rules that are non-recursive. In FML policy the order of statements is irrelevant, so statements can be reordered. This gives the advantage of making the combination of a set of independently authored policies simple by just collecting all statements made in the policies. Every rule in an FML policy applies to every flow. FML resolves any conflicts that arise from conflicting parts in a policy by allowing keywords to have priority. All constraints except those with the highest priority are thrown away. Keywords differ from application to application and thus so does priority structure. A benefit of permitting conflicts is that administrators can leverage the resolution scheme to write more concise policies. Such a benefit can allow an administrator to implicitly allow or deny activities across a swath of users. Ordering is supported via FML cascades. This means that a policy of higher priority takes precedence over one with lower priority (priority is decided by keywords, in an example deny can have priority over all other keywords, causing a policy that denies something that another policy allows to be denied instead of allowed). The highest ranked policy that says anything about a particular flow is the only policy that says anything about that flow. This can also be expressed as an unordered set of FML rules in linear time this is to achieve linear run-time evaluation. The evaluation engine consist of a decision tree and an algorithm for evaluating a given set of rules. This is done for efficiency to minimize the number of rules evaluated per flow concerning the tree. The decision tree identifies the subset of the original policy that needs to be evaluated, and the evaluation algorithm computes the set of constraints imposed by the selected rules on the given flow. All rules that constrain the eight flow fields (Us, Hs, As, Ut, Ht, At, Prot, Req) the same way are partitioned by the tree into the same partition. This compacts the rule set in eight-dimensions. In the authors implementation “all language features are supported with the exception that predicates other than keywords are restricted to one argument and strongly typed” [1]. For an implementation of policy files of increasing size from 0 to 10,000 rules the performance and memory overhead of FML is as expected , where an increase in number of rules matching a given flow yields a performance degradation in larger policy files. This fits in well with today’s computer landscape in that the solution of the author presents a method of using one tool for the purpose formerly encompassed by such services as NAT, VLANs and ACLs. This is of course relevant as it is a relatively new application of an old technology that is still in the stages of development. This solution will allow several policies to be implemented in modern small and medium sized networks easily since one central policy can be spread across several services. Distributed authorship gives a chance for weakness in the language in that it can allow a hacker of malicious agent to override former commands that are the basis of policy. Conflict resolution is confusing, trying to keep mind the constraints and order of particular policies as given in cascades as well as configurations which can cause keyword conflicts can cause problems. However, keyword conflicts and cascades can be eliminated with algorithms. Specific segments of code should be modularized so that previous batches of code can be allowed to have precedence. Possible whole segments of code should be replaced instead of allowing distributed authorship. A possible IDE to help network operators to adapt to the concept and process of using the semantics of FML should be implemented. This will make it easier for transitions from older systems to FML, which would help speed its adaptation. The paper does highlight a method that has been applied to and is successful in managing network services. This method is not properly compared to other methods as for as speed and amount of lines of code explicitly. However it does display that FML can be easier on a network operator in implementing policies for several services at once. Section 2 overviews related work. Section 3 details the proposed solution to the problem, evaluates the solution, and shows why it should achieve more than the one proposed in the chosen paper. Section 4 concludes this paper." II. Related Work The author mentions DATALOG as a related technology. FML is based on DATALOG, with special caveats. It is a more restricted form that allows negation [1]. FML was based on DATALOG because of efficient implementation, accessibility to network operators and inexpressible true disjunction. Inexpressible disjunction is needed because an FML policy could deny one or more flows without specifying which. At present time I have not found anything that improves on this technology. First-order logic [3], modal logic [4], or linear logic [5] are mentioned as alternatives but DATALOG is seen by the authors as superior for the reasons listed above. I was unable to find a similar improvement to mine concerning the authors proposed scheme, but this is assumed to be because of the relative newness of the technology. III. Proposed Solution Several possible improvements are hinted at by the authors. User friendly tools for operators to debug FML policies, such as resolving conflicts. Automatic decomposition is suggested to support distributed enforcement, to lessen the impact of a centralized controller, which would enable centralized, authoritative policy authoring and analysis as well as retain the robustness of a regular network to allow the infrastructure to be applied to large and international networks. Allowance of administrator created keywords by writing additional policy statements axiomatizing the meaning of those keywords, and the FML implementation can compile those statements to imperative code. This would allow administrators to impose constraints on flows not anticipated by NOX developers. In my solution I will be attempting to find a solution to the problem of network size that this scheme can address by combining the technology of Hinrichs et al with that of Ritu Chadha, Hong Cheng, Yuu-Heng Cheng, Jason Chiang, A. Ghetie, Gary Levin, Harshad Tanna, hereinafter Chadha et al. In reference to to possible improvements that were suggested by the author, automatic decomposition will be addressed as a method in order to get more utility out of the concept. I will attempt to establish a framework for distributed enforcement of FML. Synchronization of specific policies that affect all nodes across a network is essential. For this a system similar to one shown by Chadha et al would be used. Chadha et al’s structure is more geared towards mobile networks, so some of the features are not needed. In this system a node would be designated that receives all changes in the system. This would take the place of Chadha et al’s configuration database, however instead of the configuration all nodes that have not been updated with changes in the system is kept. The configuration database is not really needed since configuration is handled by the policies checks on flows via FML and NOX. A flow database and bandwidth broker should also not be needed since having a wired network which will probably have redundancy as well as large bandwidth readily available respectively is expected. The policy manager agent and managed element relationship can be adapted to the scheme of Hindrich to simulate decomposition. In my implementation the relationship will be as a go between various nodes and the modified configuration node aforementioned. This will modularize the network into units that can be treated as separate parts to be addressed and managed by their respective policy manager agents. This will allow a particular node to shoulder the responsibility of reporting which nodes have updated policies and which do not. Using a specialized node for this is suggested because by using something similar to an MIB all nodes that are under the specialized node in the hierarchy can be both broadcast to at once with updates and collected data from at once for transmittal when several nodes are found to have older versions of policies. A middleware program will be needed to update the policies on nodes, but this can also be done via streamed add, delete, modify commands from the policy manger agent conceivably in a database intensive environment. This solution is simple to implement as it can be done by doing a few modifications to the structure of a network. This solution will achieve more than the solution of Hinrich et al because it addresses the weakness in Hinrich et al’s original architecture in that it allows for expansion of the concept to larger sized networks by allowing updates of policies easily across a various nodes. IV. Conclusion and Direction for Further Work The simplicity of the approach is its advantage as it can be easily implemented across a network as described by Hinrichs et al. The biggest limitation of this approach is that it adds another level of hierarchy to the structure of Hinrichs et al’s scheme. This will cause extra hops in the network structure as well as another set of nodes that can be compromised by malicious attacks. Updates to nodes will cause extra traffic across the network, but it is not expected that it should be oppressive, as policy changes that span an entire network are not expected on a consistent basis. Further work still needs to be done concerning the developing a user friendly interface as well as testing the application outlined in this paper. References
Directory: cae-ia -> studentpapers studentpapers -> The Effectiveness of McAfee Host Intrusion Prevention Download 20.64 Kb. Share with your friends:
|