Slices of Network Layouts

The second part of our abstractions in the network layout abstraction level looks at designing network layout slices that will be replicated as the high level network policy intention requires. This enables the replication of identical network layouts except for the allocation of IP addresses for the network devices in the proposed experiment. A good example of where slices of network layouts are used has to do with cyber security competitions abstractions. This is because all participating teams in such competitions need to have identical layouts so as to ensure a level playing field for all participants. A more comprehensive assessment of this network layout abstraction will be carried out in chapter7.

3.6

Closing Remarks

This chapter of the thesis introduced how network concepts can be abstracted so as to make the network management process easier. The chapter introduced template

CHAPTER 3. PHILOSOPHY OF NETWORK ABSTRACTIONS 44

design approaches to abstracting firewall policies; inter domain routing policies and network layout abstraction. This chapter was written so as to show how network processes can be abstracted for the user’s benefit. Many other network concepts such as tunnelling, datacenter and other services such as DNS, DHCP can be easily abstracted using techniques detailed in this section of the thesis. The layout diagram in Figure

3.9 below details how many other network concepts can be abstracted for network administrators. For example, policies such as all network traffic between the branch networks in the diagram and the HQNet will be encrypted using IPSEC or any other tunnelling protocols can be abstracted on a policy intention level using a between the realms and having a encryption property option.

Figure 3.9: Illustrational Topology Showcasing Network Concepts

The next chapter of the thesis will be used to introduce and give an overview of the system we developed to evaluate the scalability, flexibility and limitations of the network policy abstraction techniques proposed.

NePAS Framework Design

This section discusses the design consideration of a system that will be used to evaluate the abstraction techniques proposed for various network policies called Network Policy Abstraction System (NePAS).

NePAS is a framework that is used in compiling and deploying conflict free vendor- specific configuration from abstract high level network policy intentions and associated network topology graphs. The graphs that are generated for the high-level policy intentions are designed to be independent of the network layout devices. Likewise the graphs generated for the representation of the proposed network layout are independent of vendor-platform that will be used for compiling low-level configuration commands. Both the policy intention and network layout graphs are produced using graphical editors such as yED. The graphs to be generated use nodes and edges to express both the intended policy consideration and network layouts. The NePAS framework was developed using template design approach discussed in chapter 2.1.1. NePAS uses a combination of network policy template snippets and NIDB gotten from the various in order to generate Cisco VIRL configuration files that can be used to deploy the proposed network in Cisco VIRL. The NePAS framework is designed around five phases as follows:

• Phase I - Policy Intention: the first phase of NePAS is where the network policy intention is described independent of the network topology layout. Inter-domain routing policy intention, firewall access policy intention, cyber security exercise intentions are expressed in an abstract, simple, and easy manner using graphs in this case.

• Phase II - Network Layout: the second phase of NePAS is where the actual layout of the proposed network is represented in a vendor-independent manner using graphs. The various network policies designed in Phase I can then be assigned to various network devices in this phase of NePAS.

• Phase III - Anomaly Resolution: the third phase of NePAS is where the network layout devices with their respective high level policy intentions are passed through

CHAPTER 4. NEPAS FRAMEWORK DESIGN 46

various network anomaly resolution algorithms before low level configuration commands are compiled. This is to ensure the final deployments are conflict free and behave as intended by network administrators.

• Phase IV - Compilation: the fourth phase of NePAS is where a Cisco VIRL XML file with a set of conflict free vendor-specific device-centric configuration commands for all the devices of the proposed network are generated.

Figure 4.1: NePAS Framework

Figure4.1above illustrates the sequencing of phases of the system proposed in this thesis. A combination of high level network policy intention and a vendor-independent network layout are processed using template design approach so as to automatically generate Cisco VIRL configuration files that can then be deployed in VM Maestro workspaces. The following section provides and in-depth discussion of the design of the various phases of NePAS.

4.1

Policy Intention Abstraction Phase

This is the first phase of NePAS where the network policy intention of the proposed network is expressed. At this level of abstraction, network devices such as routers, firewalls, switches, and many other middle-boxes that are used in enterprise networks are in contention. NePAS is able to abstract that level of detail so as to give a network administrator the freedom of representing various network policy intentions such as firewall relationships, BGP routing policies or cyber security exercise approaches using graphical editors without thinking about how the actual layout of the network will look like or the type of devices that will be used for the proposed experiment. The following are the two major aspects used in specifying any type of network intention policy implemented by NePAS in this phase.