Topology and Policy Models

This section presents the model that describes the physical topology, paths, and flows.

Also, this model describes network operations such as flows, policies, and conflicts. After the model is set up, the relation of correspondence is used to write the model in predicate logic and other Alloy expressions.

5.2.1 Network topology and paths

The model for network G and path p ∈ P used in this chapter is based on the definition of § 3.1.1. Also it includes three network invariants such as the connection to all nodes, the self–loop restriction, and the links consistency. However, there are some differences from the model shown in the previous chapter. Nodes in this model do not represent a datapath, a node denotes a device port. Then, under this abstraction, node transitions represent physical links in the topology and forwarding rules. At this point, it is appropriated to describe the transitive closure. This characteristic is needed to tackle the reachability property when describing a path. A binary relation R is transitive if it contains tuples in the way a → b and b → c, and also contains a → c. This relation is noted as R⁺and contains R. Let the function links⁺(n) be the set of all nodes that can be reached from n. A path has no loops if @n ∈ Np|n ∈ links⁺(n). Also for convenience, we denote a path as a node sequence as hs, n₁, n₂, . . . , ti. The wildcard symbol (∗) is included in this model to denote any unspecified node or sequence of nodes. For example, the path p= hA, ∗, Ci is the path that starts at node A and ends at C.

5.2.2 Traffic flows

Flow is a fundamental abstraction for the model. It is similar to communication session supported by a set of paths and device configurations. Traffic flow defines network parameters needed to create a competent communication channel. A flow provides enough detail to describe a set of feasible sessions, and provides a way to group and manage these sessions.

Definition 5.1 (Traffic flow). A traffic flow is a sequence of packet–header constraints f = ( f1, . . . , fn). Each term fiis a restriction over a traffic characteristic, strongly related to filters on packet fields.

Due to flow is defined as a set of traffic constraints, this model indicates that header–fields match those constraints. The used definition allows us to construct flexible and composed communication flows. A term of flow involves transport-layer protocol, source / destination at third layer, and some application fields. Also, this model uses a set of operators over these packet fields to define the flow. For instance, f low_a = {protocol = TCP, src_ip = 192.168.5.10, dst_ip = 192.168.7.10}

details a traffic flow between those IP addresses and TCP as transport protocol. Note that this flow only defines the traffic in one way. It means that the other direction is not included in this definition. Note that this flow definition is only associated to communication characteristics and packet fields, but not to the set of paths that supports the flow. Paths were considered on § 3.1.1.

5.2.3 Policy conflicts and semantics

In order to define the set of paths that implement a flow and then identify policy conflicts and violation, we use modeling language Ł to describe a syntactic domain L_L, a semantic domain S_L and a semantic function M_L : L_L → S_L. We use the tradition schema as it is shown in § 3.1.6.

As we define in § 3.1.5, a policy is a set of rules, and a rule is a tupleπ = (p, f, C, α) where f is the target flow composed of packet–field values, p is a path that supports the flow, C is a set of conditions, over the flow f or path p, andα is an action, regularly {per mit, deny}. Then, a policy is a set of rules that achieves a management procedure.

Forwarding rule is the action that a node executes to forward a packet into a datapath. For example, forwarding rules are stored in the iptable application to configure the firewall in Linux kernel. Those rules are described in terms of flows, by the previous definition.

The semantic policy is the result of the semantic functionJπ, GK which determines a set of configurations,ω in this model. Then, ω implements the flow over a path on the topology G and complies the policyπ. As was shown in § 3.1.6, the semantic of all policiesJΠK = Ω

produces the set of all network implementation. The complete network configuration is denoted by Ω. The semantic functionJπ, GK of a policy contains the sets of paths, flow definitions, conditions and the network G that satisfy the policyπ. Obviously, the policy π is valid in a network G, ifJπ, GK is not empty.

Essentially, a policy resolves whether allowing the flow f over the set P concludes on a specific actionα. The semantics over the policy produces a configuration network that allows or denies the traffic flow according to the policy. For example, a network administrator wants to apply the policy: Ana is a user with profile of IT member, who is in the subnetwork 192.168.5.*/24 (S1), is allowed to access the database at subnetwork 192.168.7.*/24 (S6) and port 1521, and her traffic must go through the router S3.

Now the manager has to detail the policy. In order to do that she solves the following steps:

1. path S1_S6 := <S1,*,S3,*,S6>, 2. transport protocol:= TCP,

3. port number:= 1521;

4. the conditions user = Ana, and Ana ∈ IT member;

5. finally, the policy decision: permit

In this way, finding ω means finding the configuration set and instructions that implement the paths and the policyπ. Note that IP addresses, user groups, traffic class and protocols should be modeled as sets. On the other hand, ordered items, such as time, are modeled as sequences to be able to compare them using ≤ and ≥ operators.

ω = impl(p : path|(S1_S6) ∧ protocol = TCP ∧ port = 1521

∧ Ana: user ∈ IT member) (5.3)

Equation (5.3) represents the policy as a conjunctive normal form predicate (CNF), and logically solve it. Later, it allow us to check a formal solution using a model finder as Alloy [Jac06], compare solutions, and find inconsistencies.

A policy conflict occurs when a set of policies are not implemented by any configuration or there are inconsistencies that prevent the generation of any of them. See definition 3.8.

Essentially, if the semantics of a policy is empty, it means that there is not configuration set that satisfies the policy. Given two valid policiesπ₁ andπ₂, they are not conflicting in the network G ifJπ1∪π₂, GK is not empty. That is, two policies are not conflicting if there

is a set of paths, flows, and restrictions in the network G that satisfies both policies. In contrast, we say that two policiesπ₁ andπ₂are conflicting in G if |Jπ1∪π₂, GK|= ∅.

On the other hand, the semantics over the minimum set of policies without conflicts is the minimal diagnosis. It is the littlest configuration applicable and functional from a set of policies. See definition 3.9. Where a set of policiesπ ⊆ Π such thatJΠ\πK ,∅, the minimal setπ is the minimal diagnosis.

After the model is proposed, a verification engine is needed to calculate the semantic function Jπ, GK and verify if the result set is empty, or the minimal diagnosis of that set. Similar methodology and tools are also used for validating paths on network infrastructure [MLCD14], and we show how to use the minimal diagnosis to detect and prevent firewall–rule conflicts on software–defined networking [MLCD15].