WO2017131765A1

WO2017131765A1 - Verifying a service function chain

Info

Publication number: WO2017131765A1
Application number: PCT/US2016/015747
Authority: WO
Inventors: Ying Zhang; Brendan TSCHAEN
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2016-01-29
Filing date: 2016-01-29
Publication date: 2017-08-03

Abstract

Example implementations relate to verifying a service function chain (SFC). For example, a system for verifying a service function chain may include a model network function engine to generate a model of a plurality of network functions comprising the SFC within a network. Further, the system may include a plan engine to generate a verification plan for the SFC using the model. Also, the system may include a verification engine to verify the SFC using the verification plan, during runtime of the network.

Description

VERIFYING A SERVICE FUNCTION CHAIN

Background

[0001 ] Network operators may enforce network policies using a combination of switches and network functions. A network policy refers to conditions, constraints, and/or settings that designate who is authorized to connect to the network and the circumstances under which they can or cannot connect. Policies may be complex, such as ensuring that unauthorized users are prevented from accessing sensitive servers or malicious traffic is eliminated from the network.

Brief Description of the Drawings

[0002] Figure 1 is a block diagram of an example system for verifying a service function chain (SFC) consistent with the present disclosure.

[0003] Figure 2 is a block diagram of an example system for verifying a SFC, consistent with the present disclosure.

[0004] Figure 3 illustrates an example method for verifying a SFC consistent with the present disclosure.

Detailed Description

[0005] Network operators may enforce network policies using a combination of switches and network functions. While these policies may be expressed in natural language, to enforce them may include complex configuration changes, including chaining multiple network functions. As a result of this complexity, configuration errors may occur, and such configuration errors may in turn result in network outages. Furthermore, in a Network Functions Virtualization (NFV), the scale and dynamics of chaining virtual network functions may increase significantly and such configuration errors may have a profound impact on network

performance.

[0006] Network functions may be "stateful", meaning that the handling of a packet depends not only on the current packet, but also on previously encountered packets, and in some cases, on the content of packets. For example, a firewall may allow packets from external hosts only if it has previously seen an outgoing packet from an internal host for that connection. As such, it may be desired to verify network functions and service chains given each network functions' current state, and capture configuration errors before deployment of the network. As used herein, a service chain refers to a sequence of actions that are applied to a data stream as it passes through an ingress or egress point in a physical or virtual network device. A service chain may define a sequence of network functions that are applied to the data stream during transmission in the network. Examples of network functions may include, but are not limited to: a network address translator (NAT), a load balancer, a stateful firewall, an intrusion detection system (IDS), a cache proxy, a virtual private network (VPN) gateway, and a packet data network (PDN) gateway.

[0007] Performing verification for network functions and their service chains may introduce several challenges. First, network functions maintain a state for each connection and may perform different actions based on those states. The states may also vary largely depending on the type of network function being verified. For example, a firewall may track a transmission control protocol (TCP) connection state where-as a deep packet inspection (DPI) may track application payload. As such, service function chaining (SFC) verification may require a mode! of disparate states for individual flows. Second, whereas verifying the functionality of one network function may be tractable, networks may consist of many network functions that are chained together. To verify a service chain, a framework may verify not just one network function but all network functions and switches that the flows will traverse: essentially, verifying the entire network.

[0008] in accordance with examples of the present disclosure, verifying a SFC may include generating a model for network functions that encodes domain specific knowledge about each network functions' behavior into a set of the actions, states, and the temporal relationships between states. Moreover, the model may allow for the representation of a network function by modeling the temporal relationship between states as high level primitives.

[0009] Figure 1 is a block diagram of an example system 100 for verifying a service function chain (SFC) consistent with the present disclosure. Generally speaking, verifying a SFC consistent with the present disclosure may be performed by the system 100 in three stages. First, a current network state may be

determined. Second, using this state, a stateful forwarding graph may be created, which represents how packets are forwarded in the network. Third, graph traversal algorithms may be applied on the stateful forwarding graph to answer various verification questions. As such, the system 100 may include a plurality of components, such as a model network function engine 106, a plan engine 108, and a verification engine 1 10. Each of the model network function engine 106, the plan engine 108, and the verification engine 1 10 may be a component of a SFC verifier, which includes a combination of hardware and programming, but at least hardware, to verify a SFC. The system 100 may include additional or fewer engines than illustrated to perform the various operations as will be described in further detail in connection with Figures 2-3. [0010] The number of engines may include a combination of hardware and programming, but at least hardware, to perform operations described herein. The number of engines may be stored in a memory resource and/or implemented as a hard-wired program, or logic". As used herein, "logic" is an alternative or additional processing resource to perform a particular action and/or operation, described herein, which includes hardware, various forms of transistor logic, application specific integrated circuits (ASICs), among others, as opposed to computer executable instructions or instructions stored in memory and executable by a processor.

[001 1 ] The model network function engine 106 may include hardware and/or a combination of hardware and programming, but at least hardware, to generate a model of a plurality of network functions comprising the SFC. The model may comprise two parts: a match-action table and a state machine. The match-action table may contain match-action rules, where match-action rules refer to rules that match on both the packet header and the internal states, and specify a particular action to be performed on the packet. The state machine refers to a natural representation of statefui processes. The nodes in the state machine are the states each network function maintains, and edges between each node capture the conditions that trigger transitions from one state to the next.

[0012] Put another way, each network function may have a different set of possible states and different state transitions, and a different model may be generated for each network function. For instance, for a NAT, the state maintained for each flow may be a mapping between a source IP or source port of an existing flow and a chosen port of the NAT. As such, there may be two states for NAT in a data flow: a state that indicates there is a mapping for the flow (indicated as "MAPPED"); and a state that indicates there is not a mapping for the flow, or that it is a new flow (indicated as "NEW"). The forwarding rules match on the packet header and the states, rewrite the source IP/port, and set the state for the NAT accordingly.

[0013] Similarly, for a load balancer, the state maintained for each flow may be dependent on the mapping received from the NAT. A server load balancer may select an instance from a server pool for a new request, and store the mapping between the source IP and the selected server instance W,. If a new flow arrives for the server, the load balancer may select an instance W,- and set the state for the flow using set (f, Wi). However, if the flow is mapped to an instance, then it gets the instance using get ( ). Regardless, in both cases the load balancer network function modifies the packet's destination IP to W,.

[0014] Further, for a stateful firewall, the state maintained for each flow may be a connection states. Each connection has three states: not seen before

(represented as "NEW^/"), waiting for TCP-handshake to finish (represented as "WAITING"), and TCP-handshake established (represented as "ESTABLISH"). A TCP primitive may abstract the stateful behavior and output TCP related events such as "Connection Open" or "Session Established". The match rules in the match-action table may then be defined using both the packet header fields and the output of the TCP protocol analyzer. The match rules may specify that an external packet will only be forwarded if it is a SYN/ACK of a connection initiated by internal hosts, or if it belongs to an established connection.

[0015] As described herein, the model network function engine 106 may receive a controller policy and topology 1 12 from a controller in the network and generate the model using the controller policy and topology 1 12. Further, the model network function engine 106 may receive a plurality of flow tables 1 14 (switches flow tables 1 14) from a plurality of switches in the network and generate the mode! using the flow tables 1 14. Similarly, the model network function engine 106 may receive a plurality of network function configurations 1 16 from a plurality of middleboxes in the network and generate the model using the network function configurations. As used herein, a middlebox refers to a device that is not a source or a destination for a packet, and performs functions on passing by packets. A middlebox may include a computer networking device that transforms, inspects, filters, or otherwise manipulates network traffic. However, examples are not so limited, and a middlebox may also passively observe packets.

[0016] The plan engine 108 may include hardware and/or a combination of hardware and programming, but at least hardware, to generate a verification plan for the SFC using the model. As used herein, a verification plan refers to a stateful forwarding graph. In a stateful forwarding graph, each node may be denoted as < H; D; S > representing any packet in the packet header space H arriving at a network device (switch or network function) D, when the network device is in a particular state S. An edge pointing from one node < H1; D1; Sf > to another < H2; D2; S2 > means when a packet in H1 arrives at Df with state SI, it will be modified to H2 and forwarded to a device D2 at state S2. if the device D does not modify the packet header, then HI is equal to H2, If the packet H1 does not trigger the state transition, then Sf is equal to S2.

[0017] Essentially, a stateful forwarding graph edge can represent one of two events: 1 ) a packet is modified and forwarded to a next hop or dropped; and 2) a device is changing its state to the next state. Accordingly, two different types of edges may be used to represent the different events. A forwarding edge from <H1, D1; Sf > to <H2; D2; S2 > means that D1 modifies packet H1 to H2 and forwards the modified packet to D2. A forwarding edge may be represented in the stateful forwarding graph as a solid edge, though examples are not so limited and other formats of edges may be used. Similarly, the statefui forwarding graph may include a state transition edge, in a statefui network function, a state transition may be triggered by the previous packets of a flow. Thus, packets of the same flow may be treated differently, depending on the internal states of the packet. A state transition edge, which indicates that a network function's state is modified because of the current packet traversal through the state, may be represented in the statefui forwarding graph separate from a forwarding edge. Each state transition edge may be associated with a transition condition. As used herein, a transition condition refers to a condition under which the network function will transition states. Examples of transition conditions may include a next packet, or an HTTP reply, which identify the event when said transition will happen. A state transition edge may be represented in the statefui forwarding graph as a dotted edge, though examples are not so limited and other formats may be used to represent a state transition edge.

[0018] The verification engine 1 10 may include hardware and/or a combination of hardware and programming, but at least hardware, to verify the SFC using the verification plan (i.e., using the statefui forwarding graph), during runtime of the network. Using the statefui forwarding graph, verification instructions may verify the dynamic and statefui behavior of the network. Essentially, only one node in a network function's state may be active at a given point in time. By activating different nodes corresponding to different states of a network function during the verification process, different forwarding scenarios across may be verified across network functions and states. To do this, the statefui forwarding graph may be augmented, such that each statefui network function node includes a bit to indicate if it is active at the current snapshot of the verification. [0019] The verification engine 1 10 may perform verification in a plurality of steps. First, the verification engine 1 10 may perform initialization. To initialize the stateful forwarding graph, a snapshot of the stateful forwarding graph may be created where all network functions are in their initial states. Next, the verification engine 1 10 may perform traversal. Given the snapshot of the network, graph traversal instructions may be executed to identify the paths that satisfy various verification queries. For example, to answer the query "Under what conditions, can A talk to B?", the verification engine 1 10 may search the stateful forwarding graph for ail paths from A to B. However, in order for the verification engine 1 10 to determine under what conditions A can talk to B, the verification engine 1 10 may determine the set of state transitions that are required to move the network from snapshot_0 to an alternate snapshot__N such that all nodes in the path discovered between A and B are activated. To do this, the verification engine 1 10 may search for all stateful nodes in the paths. For each such node, the verification engine 1 10 may identify if there is an incoming state transition edge connecting this node to another stateful node. If the verification engine 1 10 determines that an incoming state transition edge is connected to the node, then the verification engine 1 10 may try to find the conditions that must be met to activate this parent node. The process of activating the parent node may be recursive, as the parent itself may need activation. To do this the verification engine 1 10 may follow the state transition edge to the parent node, <H1; D1; SO > and determine that "e1 " is required for activation.

[0020] To activate nodes, the verification engine 1 10 may apply the appropriate event to the stateful forwarding graph and in doing so may create a new snapshot of the network. When activating a state node for NF__1 (network function 1 ), the verification engine 1 10 may ensure that other state nodes for NF__1 are deactivated. This process of applying an event to the current snapshot and of activating and deactivating nodes creates a new snapshot and therefore verifies that the service function chain, and the network functions comprising it, are properly configured.

[0021 ] Figure 2 is a block diagram of an example system 220 for verifying a SFC, consistent with the present disclosure. System 220 may include a computing device that is capable of communicating with a remote system. In the example of Figure 2, system 220 includes a processor 222 and a machine-readable storage medium 224. Although the following descriptions refer to a single processor and a single machine-readable storage medium, the descriptions may also apply to a system with multiple processors and multiple machine-readable storage mediums. In such examples, the instructions may be distributed across multiple machine- readable storage mediums and the instructions may be distributed across multiple processors. Put another way, the instructions may be stored across multiple machine-readable storage mediums and executed across multiple processors, such as in a distributed computing environment.

[0022] Processor 222 may be a central processing unit (CPU),

microprocessor, and/or other hardware device suitable for retrieval and execution of instructions stored in machine-readable storage medium 224. In the particular example shown in Figure 2, processor 222 may receive, determine, and send instructions 226, 228, 230, for verifying a SFC. As an alternative or in addition to retrieving and executing instructions, processor 222 may include an electronic circuit comprising a number of electronic components for performing the operations of the instructions in machine-readable storage medium 224. With respect to the executable instruction representations or boxes described and shown herein, it should be understood that part or ail of the executable instructions and/or electronic circuits included within one box may be included in a different box shown in the figures or in a different box not shown.

[0023] Machine-readable storage medium 224 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, machine-readable storage medium 224 may be, for example, Random Access Memory (RAM), an Electrically-Erasable Programmable Readonly Memory (EEPROM), a storage drive, an optical disc, and the like. Machine- readable storage medium 224 may be disposed within system 220, as shown in Figure 2. in this situation, the executable instructions may be "installed" on the system 220. Machine-readable storage medium 224 may be a portable, external or remote storage medium, for example, that allows system 220 to download the instructions from the portable/external/remote storage medium. In this situation, the executable instructions may be part of an "installation package". As described herein, machine-readable storage medium 224 may be encoded with executable instructions for verifying a SFC.

[0024] Referring to Figure 2, generate a model instructions 226, when executed by a processor such as processor 222, may cause system 220 to generate a model of temporal relationships between states of a plurality of network functions comprising a SFC, where the model models each of the plurality of network functions as a transfer function that transfers a packet within the SFC.

[0025] Create a statefui forwarding graph instructions 228, when executed by a processor such as processor 222, may cause system 220 to create a statefui forwarding graph of the SFC using the model, where the statefui forwarding graph includes a plurality of forwarding rules. The instructions to create a statefui forwarding graph include instructions to determine an action to take for each of the plurality of network functions by matching a packet sequence, an input port, and an input flow with information received from each of the plurality of network functions. The instructions to create a stateful forwarding graph may include instructions to incorporate a state for each of a plurality of niiddleboxes in a match-action table, as described in relation to Figure 1.

[0026] Verify the service function chain instructions 230, when executed by a processor such as processor 222, may cause system 220 to verify the SFC using temporal verification of the stateful forwarding graph. For example, as discussed in relation to Figure 1 , a verification engine (1 10 illustrated in Figure 1 ) may verify the SFC using a verification plan (i.e., the stateful forwarding graph), and using graph traversal instructions. The instructions to perform the temporal verification may include instructions to verify all packet sequences in the SFC that have an intersection with a packet sequence in the stateful forwarding graph. In some examples, the instructions to perform temporal verification may include instructions to determine all packet sequences in the SFC that have a union with a packet sequence in the stateful forwarding graph. The instructions to perform temporal verification may include instructions to verify a packet sequence using a wildcard state for a particular packet in the SFC. In some cases, the instructions to perform temporal verification may include instructions to verify a packet sequence using the union of ail possible states.

[0027] As discussed herein, nodes within the stateful forwarding graph may be activated during verification. The process of activating a node may include exploring and potentially recursively activating other nodes. As such, the order of traversal may determine the number of nodes that need to be recursively activated, which in turn may impact the runtime of the system (e.g., system 100). As such, domain specific knowledge may be used to determine which parent node has a smaller set of potential dependencies. For example, a parent node requiring a 'SYN' packet event has a smaller than dependency than a parent node requiring a 'HTTP Request' - as the latter requires three packets (e.g. 'SYN', 'SYN-ACK', 'ACK+Request'). Therefore, to reduce runtime, nodes may be activated based on the number of dependencies associated with the node, such that nodes with a smaller number of dependencies may be activated before a node with a larger number of dependencies.

[0028] Figure 3 illustrates an example method 340 for verifying a SFC consistent with the present disclosure. At 342, the method 340 may include generating a model of temporal relationships between states of a plurality of network functions comprising the SFC within a network, where the model models each of a plurality of network functions as a transfer function that transfers a packet of data within the SFC. As described in relation to Figure 1 , the SFC may include a plurality of middieboxes. Each of the plurality of middieboxes may be one of a stateful firewall, an intrusion detection system (IDS), a network address translator (NAT), a load balancer (LB), a cache proxy, a virtual private network (VPN) gateway, and a packet data network (PDN) gateway.

[0029] in some examples, generating the model may include generating a match-action table corresponding to the plurality of network functions, and generating a state machine for each state of each of the plurality of network functions. Further, generating the model may include generating a plurality of nodes, each of the plurality of nodes representing a state of a network function, and a plurality of edges representing conditions under which an associated node among the plurality of nodes will transfer from one state to another state.

[0030] At 334, the method 340 may include creating a stateful forwarding graph of the SFC using the model, a plurality of controller policies, a plurality of switch flow tables, and a plurality of network function configurations. Additionally, at 336, the method 340 may include verifying the SFC using temporal verification of the statefu! forwarding graph, as described in more detail in relation to Figures 1 and 2.

[0031 ] In the foregoing detailed description of the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how examples of the disclosure may be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples may be utilized and that process, electrical, and/or structural changes may be made without departing from the scope of the present disclosure.

[0032] The figures herein follow a numbering convention in which the first digit corresponds to the drawing figure number and the remaining digits identify an element or component in the drawing. Elements shown in the various figures herein can be added, exchanged, and/or eliminated so as to provide a number of additional examples of the present disclosure. In addition, the proportion and the relative scale of the elements provided in the figures are intended to illustrate the examples of the present disclosure, and should not be taken in a limiting sense. As used herein, "a number of an element and/or feature can refer to one or more of such elements and/or features.

Claims

What is claimed:

1 A system, comprising:

a model network function engine to generate a model of a plurality of network functions comprising a service function chain (SFC);

a plan engine to generate a verification plan for the SFC using the model; and

a verification engine to verify the SFC using the verification plan, during runtime of the network.

2. The system of claim 1 , wherein the model network function engine generates the model using a controller policy and a topology.

3. The system of claim 1 , wherein the model network function engine generates the model using a plurality of flow tables from a plurality of switches.

4. The system of claim , wherein the model network function engine receives a plurality of network function configurations from a plurality of middleboxes in the network and generates the model using the plurality of network function configurations.

5. A non-transitory machine-readable medium containing instructions executable by a processor to:

generate a model of temporal relationships between states of a plurality of network functions comprising a service function chain (SFC), wherein the model models each of the plurality of network functions as a transfer function that transfers a packet within the SFC; create a statefu! forwarding graph of the SFC using the model, wherein the stateful forwarding graph includes a plurality of forwarding rules; and

verify the SFC using temporal verification of the stateful forwarding graph.

6. The non-transitory medium of claim 5, wherein the instructions to create a stateful forwarding graph include instructions to determine an action to take for each of the plurality of network functions by matching a packet sequence, an input port, and an input flow with information received from each of the plurality of network functions.

7. The non-transitory medium of claim 5, wherein the instructions to create a stateful forwarding graph include instructions to incorporate a state for each of a plurality of middleboxes in a match-action table.

8. The non-transitory medium of claim 5, wherein the instructions to perform the temporal verification include instructions to verify all packet sequences in the SFC that have an intersection with a packet sequence in the stateful forwarding graph.

9. The non-transitory medium of claim 5, wherein the instructions to perform temporal verification include instructions to determine all packet sequences in the SFC that have a union with a packet sequence in the stateful forwarding graph.

10. The non-transitory medium of claim 1 , wherein the instructions to perform temporal verification include instructions to verify a packet sequence using a wildcard state for a particular packet in the SFC.

1 1. A method, comprising:

generating a model of temporal relationships between states of a plurality of network functions comprising a service function chain (SFC) within a network, wherein the model models each of a plurality of network functions as a transfer function that transfers a packet of data within the SFC;

creating a stateful forwarding graph of the SFC using the model, a plurality of controller policies, a plurality of switch flow tables, and a plurality of network function configurations; and

verifying the SFC using temporal verification of the stateful forwarding graph. 2. The method of claim 1 1 , wherein generating the model includes generating a model of temporal relationships between states of a plurality of middleboxes.

13. The method of claim 12, wherein generating the model includes generating a model of temporal relationships between:

a stateful firewall;

an intrusion detection system (IDS);

a network address translator (NAT); and

a load balancer (LB).

14. The method of claim 1 , wherein generating the model includes generating a match-action table corresponding to the plurality of network functions, and generating a state machine for each state of each of the plurality of network functions.

15. The method of claim 1 wherein generating the model includes generating: a plurality of nodes, each node of the plurality of nodes representing a state of a network function; and

a plurality of edges representing conditions under which an associated node among the plurality of nodes will transfer from one state to another state.