SYNTHESIS OF GUIDELINES FOR THE ENFORCEMENT OF GROUP-BASED GUIDELINES FOR UNKNOWN FLOWS

Abstract

A computer-executable procedure, comprising: Determining a first set of policies (152) defined for a switch (103) when handling a packet, wherein a policy includes at least one policy entry based on a target role and wherein the at least one policy entry includes a source role, a traffic attribute and an action to be performed for the packet; Receiving an incoming packet at the switch, where the destination of the incoming packet is unknown; Representing the first set of policies as a matrix, where a first entry in the matrix corresponds to the source role as a row and the destination role as a column, and specifies the traffic attribute and the action of the at least one policy entry; Replacing the action in the first entry with the target role if the action indicates that the packet should be allowed, and with a null value if the action indicates that the packet should be rejected, in order to obtain an initial data structure with entries that specify a multitude of traffic attributes for each source role and a corresponding set of allowed target roles for each traffic attribute; Resolving an overlapping pair comprising a first traffic attribute and a second traffic attribute to obtain a second data structure; Finding that a third traffic attribute for a source role in the second data structure does not comply with a policy; Removing the third traffic attribute from the second data structure to obtain a second set of synthesized policies (154), where a first decision model based on the first set of guidelines leads to the same result as a second decision model based on the second set of synthesized guidelines; Allowing or rejecting the forwarding of the incoming packet at the switch using the second decision model; in response to allowing the incoming packet to be forwarded to a local host; and as a reaction to the rejection, the dismissal of the incoming package.

Description

BACKGROUND area

[0001] This disclosure relates generally to the field of data management. More specifically, this disclosure relates to a method and system for policy synthesis to enforce group-based policies for unknown flows.

[0002] US 2016 / 0330125A1 refers generally to the area of ​​computer networks and, in particular, to the enforcement of policies via a physical network layer or hardware structure of a data center.

[0003] US 2016 / 0359913A1 refers to network policies, and in particular to network policies that can change dynamically based on security measurements for network endpoints.

[0004] The present invention is defined by independent claims 1, 13 and 19. Embodiments are the subject of the respective dependent claims. BRIEF DESCRIPTION OF THE FIGURES Fig. Figure 1 illustrates a network that enables the enforcement of policies based on source roles, in accordance with one aspect of the present application. Fig. Figure 2A shows a table of user-configured group-based policies (GBPs) according to one aspect of the present application. Fig. Figure 2B shows a table in which the GBPs configured by the user are presented in a matrix, according to one aspect of the present application. Fig. 2C shows a table that displays the user-configured GBPs in a matrix based on a transposed form in conjunction with Fig. 2B according to one aspect of the present application. Fig. Figure 2D shows a table that specifies a set of rules with transformed actions according to one aspect of the present application. Fig. 2E shows a table accordingly Fig. 2D, including placeholder expansion and overlap detection of entries, according to one aspect of the present application. Fig. 2F shows a table accordingly Fig. 2E, including implosion and truncation of entries for the source role “Admin”, according to one aspect of the present application. Fig. 2G displays a table of synthesized policies based on the user-configured policies from Fig. 2A and the result of the in the Fig. The processing shown in 2B-2F is based on an aspect of the present application. Fig. Figure 3 shows a flowchart illustrating a procedure that enables the synthesis of guidelines for the enforcement of GBPs for unknown flows, in accordance with an aspect of the present application. Fig. 4A shows a flowchart that represents a method for facilitating policy synthesis for the enforcement of GBPs for unknown flows, including implosion, overlap detection and treatment, pruning and merging, in accordance with an aspect of the present application. Fig. Figure 4B shows a flowchart that represents a method for facilitating policy synthesis for the enforcement of GBPs for unknown flows, including implosion, overlap detection and treatment, pruning and merging, in accordance with an aspect of the present application. Fig. Figure 5 shows a computer system that enables the synthesis of guidelines to enforce GBPs for unknown flows, in accordance with an aspect of the present application. Fig. Figure 6 shows a device that enables the synthesis of guidelines to enforce GBPs for unknown flows, in accordance with an aspect of the present application.

[0005] In the figures, identical numbers refer to the same figure elements. DETAILED DESCRIPTION

[0006] The following description is intended to enable the person skilled in the art to produce and use the aspects and examples and is given in connection with a specific application and its requirements. Various modifications of the disclosed aspects will be readily apparent to the person skilled in the art, and the general principles defined herein can be applied to other aspects and applications without departing from the spirit and scope of the present disclosure. Therefore, the aspects described here are not limited to those shown but have the broadest possible scope consistent with the principles and features disclosed herein.

[0007] The internet is the transmission medium for a multitude of applications running on physical and virtual devices. These applications generate increasing traffic demand. For this reason, device manufacturers continue to develop switches with versatile features. For example, network segmentation can be used to isolate user traffic and reduce the broadcast domain in a network. Traditionally, local virtual local area networks (VLANs) have been used to segment network traffic at Layer 2, and IP subdomains to segment network traffic at Layer 3. Traditional edge network segmentation (e.g., at a switch or access point where clients can connect directly to the switch, which enforces a role-based policy) can face some challenges, such as…The integration of traditional wired and wireless infrastructures, the ever-increasing number of mobile devices on a network, and the widespread use of Internet of Things (IoT) devices all present challenges. Furthermore, scaling a network can be difficult when supporting a large number of devices with varying access requirements and threat perceptions, as well as traditional manual and static configurations using Internet Protocol (IP) subnets and access control lists (ACLs).

[0008] Group-based policies (GBPs) can provide a solution for dynamic network segmentation. With GBPs, a network administrator can configure policies that define permitted traffic patterns between or within user roles. A GBP can be configured as a policy for a pair of source and destination roles and can assist with both micro-segmentation (within a subnet) and macro-segmentation (across multiple subnets). The system can profile the sender of a packet at the entry node and transmit the profiling information using transport encapsulation. In scenarios where the packet's destination is known, segmentation using GBPs can be efficient.

[0009] In some cases, however, the packet's destination may be unknown. For example, a packet with multiple destination addresses (or broadcast, unknown unicast, or multicast (BUM) traffic) might be addressed in such a way that a switch is unable to determine a destination host. The destination address of such a packet might be a multicast address that doesn't specify an individual destination host. As a result, the packet might not have a corresponding destination role. Consequently, it can be challenging for the switch to decide, based on the GBPs, whether to forward the packet to a local host.

[0010] The described aspects offer a solution for enforcing GBPs for unknown flows by taking an initial set of user-configured policies (which use a source role, a destination role, and traffic attributes as input to output an allow / deny action for a packet) and synthesizing a set of policies based on these user-configured policies. The resulting set of synthesized policies can take a source role and traffic attributes as input and output a list of allowed destination roles. Thus, a "first decision model" based on the user-configured policies can produce the same result for a given incoming packet as a "second decision model" based on the synthesized policies (also referred to as equivalent decision models).The second decision model can enable the system to enforce GBPs in scenarios of unknown target roles or flows (as in BUM traffic).

[0011] In this disclosure, the term "switch" is used in a general sense and can refer to any standalone or fabric switch operating at any network layer. The term "switch" is not to be understood as limiting aspects of the present invention to Layer 2 networks. Any device capable of forwarding traffic to an external device or another switch may be referred to as a "switch." Any physical or virtual device (e.g., a virtual machine or a switch operating on a computing device) capable of forwarding traffic to an end device may be referred to as a "switch." Examples of a "switch" include, but are not limited to, a Layer 2 switch, a Layer 3 router, a routing switch, a component of a Gen-Z network, or a fabric switch comprising a plurality of similar or heterogeneous smaller physical and / or virtual switches.

[0012] The term "packet" refers to a group of bits that can be transported together over a network. The term "packet" should not be interpreted as limiting aspects of the present invention to Layer 3 networks. The term "packet" can be replaced by other terms that refer to a group of bits, such as "message," "frame," "cell," "datagram," or "transaction." Furthermore, the term "port" can refer to the port that can receive or send data. The term "port" can also refer to the hardware, software, and / or firmware logic that enables the operation of that port. Enforcement of policies in an overlay topology

[0013] A switch can support various protocols and services. For example, a switch can support tunneling and virtual private networks (VPNs). The switch can then enable overlay routing for a VPN across the tunnels. An Ethernet VPN (EVPN), for instance, can be deployed as an overlay across a set of virtual extensible local area networks (VXLANs).

[0014] To establish a VPN over the tunnels, a corresponding tunnel endpoint can map a corresponding virtual local area network (VLAN) to a corresponding tunnel network identifier (TNI), which can identify a virtual network for a tunnel. The TNI can appear in a tunnel header, which encapsulates a packet and is used to forward the encapsulated packet over a tunnel. For example, if the tunnel is based on VXLAN, the TNI can be a virtual network identifier (VNI) of a VXLAN header, and a tunnel endpoint can be a VXLAN tunnel endpoint (VTEP). A TNI can also be mapped to the virtual routing and forwarding (VRF) associated with the tunnels if Layer 3 routing and forwarding is required.

[0015] A VPN can be established via tunnels between the backbone switches (or non-access switches) of a network. For example, if a network includes core, aggregation, and access switches, the core and aggregation switches can be referred to as the backbone switches. The set of tunnels between the backbone switches can form an overlay tunnel fabric. In other words, the backbone switches of the tunnel fabric can act as tunnel endpoints, enabling routing over the tunnels. On the other hand, the access switches can receive packets from hosts (or client devices) and provide the packet distribution underlay. Because a VPN can be distributed over a tunnel fabric, it can also be called a distributed tunnel fabric.

[0016] Fig. Figure 1 illustrates a network that enables the enforcement of policies based on source roles in accordance with an aspect of this application. A network 100 can comprise a number of switches and devices. The network 100 can be an Ethernet, InfiniBand, or other network using a suitable communication protocol, such as the Internet Protocol (IP), Fibre Channel over Ethernet (FCoE), or another protocol. The network 100 can include a distributed tunnel fabric 110 consisting of switches 101, 102, 103, 104, and 105. Switches 101 and 102 of fabric 110 can be connected to a core switch 106. Fabric 110 can be connected to an external network 120 via switch 106 (e.g., a Layer 3 router).

[0017] In Fig. 1. A corresponding connection in Fabric 110 can be a tunnel. The switches of Fabric 110 can form a network of tunnels. Examples of tunnels include VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization using GRE (NVGRE), Generic Networking Virtualization Encapsulation (Geneve), and Internet Protocol Security (IPsec). A VPN 130, such as an EVPN, can be deployed over Fabric 110. Fabric 110 can contain an aggregation layer 108, which can include aggregate switches 103, 104, and 105. A corresponding aggregate switch can aggregate traffic from one or more downstream access switches.

[0018] Furthermore, aggregate switches 103, 104, and 105 can be coupled with an access layer 118, which can include access switches 111, 112, 113, 114, 115, and 116. Access layer 118 can allow a number of hosts 122, 123, 124, 125, and 126 to access fabric 110. Examples of hosts include, but are not limited to, laptops, desktops, printers, mobile phones, tablets, IoT devices, and appliances. Access switch 115 can provide access to hosts 124 and 125. Similarly, access switches 111, 112, 113, and 116 can provide access to hosts 121, 122, 123, and 126, respectively. In this example, access switches 113 and 114 can be coupled with aggregate switch 104 to forward traffic to fabric 110. Consequently, packets forwarded by access switch 113 can reach fabric 110 via aggregate switch 104.

[0019] With existing technologies, when host 123 comes within range, switch 113 can authenticate host 123 against an authentication server 140. Authentication of host 123 can be based on an authentication method supported by access layer 118. For example, the authentication process can be port-based (e.g., IEEE 802.1X) or username / password-based authentication. If host 123 is successfully authenticated by authentication server 140, access switch 113 can determine a host role 134 for host 123 and assign a VLAN to host 123 based on that role. Host role 134 can be provided by authentication server 140 and specifies the relationship between a user of host 123 and the entity connected to VPN 130.Host role 134 can contain one or more of the following: a division of the user from host 123; an access level granted to the user; and a communication domain for host 123.

[0020] For example, if host 123 is associated with a user with administrative privileges, role 134 can be an administrator role. Conversely, if host 123 is associated with a guest user, role 134 can be a guest role. Similarly, the corresponding switches at access layer 118 can assign role 132 to hosts 121 and 125, role 134 to host 122, and role 136 to hosts 124 and 126. Roles thus define policies for accessing and routing traffic within fabric 110, rather than the physical location of the hosts or switches. By assigning host 123 to role 134, host 123 can be associated with a group of hosts that also belong to role 134. A host can be associated with one or more groups. A user (e.g.,An administrator can then configure GBPs for Fabric 110 to enable traffic segmentation based on roles 132, 134, and 136 determined during the authentication process. The GBPs thus allow the administrator to configure policies that define permitted traffic patterns for roles 132, 134, and 136 in Fabric 110.

[0021] In Fabric 110, GBPs can be deployed on the egress switches without distributing them across Fabric 110. For packets received over tunnels, Switch 103, for example, can act as a policy enforcement switch and maintain a policy table 150 containing a set of policies (e.g., GBPs or user-configured policies) 152 defined based on source and destination roles. A corresponding policy or GBP in the policy table 152 can specify whether a traffic class (e.g., with specific traffic attributes) may or should be forwarded from a source role to a destination role. For example, a GBP can specify whether role 134 is allowed to receive TCP (Transmission Control Protocol) traffic from role 132 on port 80. Since Switch 103 can act as an egress switch for a packet received over a tunnel, it can determine the destination role for the packet.Furthermore, Switch 103 can only activate a role-related policy if a host with that role is detected on a port of Switch 103. This allows Switch 103 to efficiently enforce the GBPs in the 110 structure.

[0022] In another example, after successful authentication, host 125 can send a packet to host 122. The access switch 115 can receive the packet and forward it to fabric 110. The ingress switch 105 can receive the packet and determine the source role associated with the packet (i.e., role 132 of the source host 125). Switch 105 can also determine a TNI (e.g., a VNI) that corresponds to the packet's VLAN. Furthermore, switch 105 can determine a remote tunnel endpoint, such as switch 103, in fabric 110 based on the packet's header information. Switch 105 can maintain a mapping between the VLAN and the TNI to determine the TNI. Switch 105 can then encapsulate the packet (e.g., with a GPO encapsulation (Group Policy Object)) with a tunnel header containing the TNI, a destination address corresponding to Switch 103, and the source role.Switch 105 can then forward the encapsulated packet over the tunnel to Switch 103. To identify Switch 103 as the remote tunnel endpoint, Switch 105 must participate in the routing process of VPN 130 based on the TNI. This participation may involve sharing routing information associated with the TNI with the rest of Fabric 110, including updating a MAC (Media Access Control) address table.

[0023] Egress switch 103, which may be the other tunnel endpoint, can extract the source role from the tunnel header and decapsulate the tunnel header to receive the packet. Using the packet's destination address, switch 103 can determine the destination role (i.e., role 134 of the destination host 122). Switch 103 can then iterate through policy 152 to determine whether the packet's traffic class is permitted to be forwarded from role 132 to role 134. If permitted, switch 103 can forward the packet to host 122. Otherwise, switch 103 may refrain from forwarding the packet to host 122 and potentially discard the packet. Fig. The network described in Figure 1 shows how segmentation with GBP requires an associated role for the sender (i.e., a source role) as well as the destination of each packet (i.e., a destination role), which can work successfully if the destination of the packet is known.

[0024] However, if, as described above, the destination of a packet is unknown (as with BUM traffic), the above regarding Fig. The communication described in section 1 may not be sufficient. For example, the destination address of a packet may be a multicast address that does not specify an individual destination host. As a result, the packet may not have an appropriate destination role. Consequently, it may be challenging for switch 103 to decide, based on policy 152, whether to forward the packet to a local host.

[0025] The described aspects can address this challenge by generating a set of synthesized policies 154 (as shown in policy table 150) based on user-configured policies 152. User-configured policies 152 can take a source role, a target role, and traffic attributes as input to output an allow / dismiss action for a packet. In contrast, synthesized policies 154 can take a source role and traffic attributes as input to output a list of allowed target roles. Synthesized policies 154 can thus provide an equivalent decision model to the user-configured policies 152. In other words, a packet evaluated against a decision model (i.e., the "second decision model") based on the synthesized policies 154 is treated the same as a packet evaluated against a decision model (i.e.,of the “first decision model”) is evaluated on the basis of the user-configured guidelines 152. First stage: Reorientation of user-configured group-based policies into a transposed matrix form

[0026] Group-based policies can conventionally be linked to destination roles. Each destination role can be assigned a single GBP. This single assigned GBP can define a set of tuples of source role and traffic attributes which, when matched, either allow or prohibit the delivery of a packet to the destination, as described below. Fig. 2A described.

[0027] Fig. Figure 2A shows a Table 200 containing user-configured group-based policies according to one aspect of the present registration. Table 200 can contain rows that indicate: a policy 201; an associated target role 202; and policy entries 203. Table 200 can contain three policies, including one policy for each of the three associated target roles: a policy P1 for Finance 204; a policy P2 for Admin 205; and a policy P3 for Security 206. Each policy can contain one or more policy entries, and each policy can specify or include: a sequence number (for example, "10," "20," and "30"); a source role; the target role; one or more traffic attributes; and an action (for example, "Allowed" or "Denied"). For example, policy P1 for the target role Finance 204 can contain two policy entries.The first policy entry can specify: a sequence number "10"; a source role "Admin"; a destination role "Finance"; traffic attributes "IP protocol TCP" and "L4 port 10-100"; and an action "Allowed". A second policy entry can specify: a sequence number "20"; a source role "Any"; a destination role "Finance"; traffic attributes "IP protocol TCP Traffic" and "L4 port 80"; and an action "Allowed". Table 200 thus shows how policies can be applied to incoming packets to segment traffic based on user roles.

[0028] The system can generate a set of synthesized policies step by step from the user-configured policies in Table 200. In a first step, the system can extract the user-configured policies from Fig. 2A mathematically model the processing that can be used by the system in subsequent stages, as below in relation to Fig. 2B and Fig. 2C described. In a second stage, the system can output a matrix from the first stage (e.g., the transpose of the matrix). Fig. 2C) and use the set of matching criteria as input to generate a set of synthesized policies that use only the source role for policy enforcement on inbound traffic (e.g., the "first data structure" of Fig. 2D). In the second stage, the system can also perform the detection and handling of overlaps, as well as the implosion and clipping of matching elements, as shown below in relation to the Fig. 2D, Fig. 2E and Fig. 2F described. In a third stage, the system can process the matching elements output by the second stage (e.g., the "second data structure"). Fig. 2F) further process for optimization by merging and sequencing, as below in relation to Fig. 2G described (e.g. the final “second set of synthesized guidelines”).

[0029] The system can use the user-configured GBPs from Fig. 2A is represented using a mathematical model that can be used as input for a synthesis process defined by an algorithm. The system can label the set of user-configured GPBPs as P, which can be the entire set of policies, represented as: P :=∪i=1nPr where r=f(i) where r ∈ G and represents individual roles that have an assigned GBP P, and where n = |G|, where G is the complete set of roles participating in the GBP-based segmentation. Each individual policy can be an ordered set of a series of policy entries. A policy assigned to a target role r can be represented as follows: Pr :={Er,1,Er,2,...}

[0030] Each policy entry E r,x It can contain a match element and an action element. The match element can contain a source role and a series of match elements to define the traffic attributes. i to match an incoming packet. Each matching element m i This can be the most granular traffic attribute against which the incoming packet can be matched. For example, a policy that specifies matching against TCP port 80 can be transformed into the following set of matching elements: {Ethertype == 2048, IP_PROTO == 6, TCP_PORT == 80}. The user can specify the sequence number n, which determines the relative priority of the element in the event that a packet meets the matching condition of more than one matching element. Thus, the system can represent the policy entry as follows: Er,x4=( s:s∈R|*{...,mi,...}:mi∈M a:a∈A n:n∈N)

[0031] M can be the set of matching elements that define the matching to be performed with user traffic. M can be derived by examining the user-configured policies for the matching criteria present in the policies and adding each unique matching element to the set of matching elements M. Note that N can be the set of natural numbers and A can be the set of "actions," which can have two elements (e.g., "Allow" and "Deny"). Wildcard entries are possible for both the source role and the matching elements. At this stage, wildcard roles can be imploded, and a set of policy entries can be derived, where each policy entry can represent a policy for a specific target and source role.For a wildcard source role, the system can perform an implosion by copying the same entry for all possible source roles. The system can perform the implosion of wildcard entries at a later time. In this way, the system can derive a set of policy entries based on target / source role pairs, where each entry is a match / action pair and can be represented as follows: sdYi3≡({...,mi,...}:mi∈M a:a∈A n:n∈N)

[0032] For a given target / source role pair, multiple policy entries can exist, with each policy entry having a unique compliance criterion and a unique action. The system can create an ordered list of such policy entries to obtain a complete set of policy entries for a given target / source role pair. This set of policy entries based on target / source role pairs can be represented as follows: sdY≡∪i=1m sdYi2

[0033] This representation of policy entries allows the system to display the entire set of user-configured policies as an n x n matrix, where each axis represents the configured roles. Rows in this matrix can represent the target roles, and columns in this matrix can represent the source roles. A two-dimensional matrix representation of the entire policy set can therefore be displayed as follows: P≡[⋯sjdiY⋮⋱⋮⋯]

[0034] The system can therefore create a decision model based on this representation of the user-configured policies. A first decision model based on the user-configured policies can produce the same result for handling a packet as a second decision model based on the synthesized policies (as described below). These two decision models can be considered "equivalent" if, when applied independently to the same traffic and packets, both models lead to the same routing decision regarding the "Allow / Deny" action policy for all possible network traffic and packets. Thus, the system can subject each incoming packet to the first decision model to determine the resulting action for the packet, which can be either "Allow" or "Deny." This first decision model can be expressed as follows: d = Role of the target s = role of the source sdY=P[d][s] For each guideline element E in sdY For the set of matching elements T in E match=Λt∈Tft(k) where k is the incoming package for which the first decision model is executed, f t The matching function corresponds to the matching condition in `match element tent`, and `match` is a Boolean value indicating whether k satisfies the matching conditions of the matching element `t`. Thus, for the first policy element E that returns a `match` == TRUE, the system can apply the action associated with that specific policy entry to the package k.

[0035] At this point in the first stage, the system can represent the set of user-configured policies P as a two-dimensional matrix oriented according to the target roles. That is, the target roles are the rows and the source roles are the columns. The system can display this two-dimensional matrix (which is shown below in relation to...) Fig. 2B described) to use to derive the set of policy elements for a pair of destination / source roles in order to apply the policy to an incoming packet based on the matching traffic attribute.

[0036] Fig. Figure 2B shows a Table 210 that displays the user-configured GBPs in a matrix according to one aspect of the current login. Table 210 can contain the target roles as rows (e.g., Finance 214, Admin 215, and Security 216) and the source roles as columns (e.g., Admin 211, Security 212, and Finance 213). Each entry in the matrix of Table 210 can specify one or more traffic attributes and a corresponding action to be taken for a packet with matching traffic attributes. For example, an entry 217 for a target role Security 216 and a source role Admin 211 can specify the following two policy elements, or traffic attributes and actions: "10 IP protocol UDP, L4 port Any, rejected"; and "30 IP protocol Any, L4 port Any, allowed".

[0037] The system can transpose the matrix P, represented by Table 210, to obtain a matrix P Tto obtain, which can be oriented according to the source roles, as below in relation to Fig. 2C described. The transposed matrix P T Although it is oriented towards the source roles, it still requires the target roles.

[0038] Fig. Figure 2C shows a Table 220, which displays the user-configured GBPs in a matrix based on a transposed form that is Fig. 2B is connected, in accordance with an aspect of the present application. Table 220 can contain the source roles as rows (e.g., Admin 224, Security 225, and Finance 226) and the target roles as columns (e.g., Finance 221, Admin 222, and Security 223). Each entry in the matrix of Table 220 corresponds, in a transposed format, to an entry in Table 210. For example, an entry 227 in Table 220 for a source role Admin 224 and a target role Security 223 can correspond to an entry 217 in Table 210 and specify the same two policy elements or traffic attributes and actions: "10 IP protocol UDP, L4 port Any, denied"; and "30 IP protocol Any, L4 port Any, allowed". Second stage: Replacing the action with the target role to obtain a transformed action.

[0039] In the second stage, the system can transpose the matrix P. TUse this to derive a preliminary set of raw-synthesized guidelines that can be used by a second decision model. This second model enforces the same guidelines as in P, but without requiring the target role to be used as input for the search, as in the first decision model. The system can use the transposed matrix P. T and take the set of matching criteria M as input and a set of synthesized guidelines S S derive policies that use only the source role to determine policy enforcement for incoming traffic or packets. The system can isolate the policies of each source role from one another, i.e., the policies in a row (representing policies for a source role) of the transposed matrix P. T have no impact on the decision model for another row (which represents guidelines for a different source role).

[0040] The system can transpose the matrix P T Write it as a union of the sets of guidelines for each source role, where each set is independent of every other set. Although the agreement criterion may match in a particular source role, this has no effect on the decision model. PT≡∪i=1nPsT where s = f(i), s is the source role, and s ∈ G. Furthermore, each policy can be viewed as a set of policy entries for the source role. A given target role can be represented as follows: PsT≡∪j=1nPs,dT where f(j), d is the target role, and d ∈ G. As described above, the policy entries for the source / target role pair can be PS, dT represented as a set of policy elements, where the policy elements for the source role s are for the transposed matrix P T can be written as follows: sdYi3≡({…,mi,…}:mi∈Ma:a∈An:n∈N)

[0041] The system can begin converting policy elements by dropping the target role as an index and instead making the target role part of the action to convey the intent of the policy originally configured by the user. The system can replace the action for each element with the target role if it indicates that the package should be allowed, and with a null value if the action indicates that the package should be rejected. Thus, a converted policy element might be represented as follows: s∗¥i3≡(mm∈M{fn(d,a)}:a∈Ann∈N) where fn(x,y)={x, if y=='Allow'∅, if y=='Reject'}

[0042] The system can thus transform the policy from the intent "Traffic from source role s to target role d with traffic attribute matching m should have action a" to the intent "Traffic from source role s with traffic attribute matching m should be allowed on target role d if a is 'Allow'." The resulting data structure can contain entries that specify a variety of traffic attributes for each source role and a corresponding set of allowed target roles for each traffic attribute. The system can use the wildcard character "*" instead of the target role d as a superscript for the transformed policy element to indicate that the same policy element now matches any or all target roles. An example of transformed policy elements is given below with respect to... Fig. Described in 2D.

[0043] Fig. Figure 2D shows a Table 230 that specifies a rule set with transformed actions according to an aspect of the present application. Table 230 may contain fields that include: a source role 231, one or more matching elements 232, and one or more permitted target role sets 233. Table 230 may contain entries for the following source roles: Admin 234; Security 235; and Finance 236.For example, the row or entry for the source role Admin 234 can contain a variety of traffic attributes and, for each traffic attribute, a corresponding set of allowed target roles, including: a match 232 "10 IP protocol TCP, L4 port 10-100" and a corresponding set of allowed target roles 233 "{Finance}"; a match 232 "20 IP protocol TCP traffic, L4 port 80" and a corresponding set of allowed target roles 233 of "{Finance}"; a match 232 "20 IP protocol TCP, L4 port 10-1000" and a corresponding allowed target role group 233 "{Admin}"; a match 232 "10 IP protocol UDP, L4 port Any" and a corresponding allowed target role group 233 "{}"; and a matching element 232 “30 IP protocol Any, L4 port Any” and a corresponding allowed target role group 233 “{Security}”.”.

[0044] Any role not included in or listed in the Allowed Target Roles List 233 (or an "Allowed List") is implicitly rejected for traffic corresponding to a given policy element. Therefore, a "Rejected List" or "Rejected Target Role Set" is not required for the decision model. However, similar to the Allowed List, the system can maintain a "Rejected List" for each policy. The Rejected List can contain the roles that have an explicit "Reject" action in the policy entry. The system can use the Rejected List to trim or remove disallowed roles while merging policy entries with conflicting intents, as described below.

[0045] Various translated policy elements s∗¥i3, Entries corresponding to the same source role may have an overlap in their matching condition. This overlap can result from the use of a wildcard in the matching condition or from the use of a range in a field of the matching element. The system can compare multiple overlapping entries with a matching pattern against the data traffic and remove the overlap to ensure that the policies and decision model lead to a deterministic decision. Second stage: Detection and treatment of overlaps; implosion and circumcision

[0046] The system can detect overlaps and merge common matching conditions to obtain a new set of crossover policy elements (raw-synthesized policies). This set of raw-synthesized policies can correspond to a second "equivalent" decision model of the first decision model (which is based on the user-configured policies of Fig. (2A based). The system can detect overlaps by first converting all values, ranges, and wildcards into a possible set of natural numbers in each matching element. A converted value can result in a set of a single element containing only that value. The system can convert wildcards and ranges into sets of elements with all possible values ​​for the wildcard field or range.

[0047] For example, if a placeholder "Any" is used for the match in the IP_PROTO field of an incoming packet, the system can interpret this placeholder entry as {0, ..., 2 8 - 1}. Similarly, the system can represent a placeholder "Any" in the Ethertype field as {0, ..., 2}. 16 - 1}. The system can use a similar approach for other traffic attributes, such as TCP / UDP port numbers, etc. The system can first expand all matching conditions using this approach to detect overlaps. The system can record or mark the degree of expansion by adding an attribute to the list that has the value "0" for a list derived from an exact value, the value "1" for a list derived from a range, and the value "2" for a list derived from a wildcard.

[0048] Fig. 2E shows a table 240, which Fig. 2D, including wildcard expansion and overlap detection of entries, complies with one aspect of the present application. Table 240 may contain fields comprising: a source role 241; one or more matching elements 242; and one or more permitted target role sets 243. Table 240 may contain entries for the following source roles: Admin 244 (corresponds to Admin 234); Security 245 (corresponds to Security 235); and Finance 246 (corresponds to Finance 236). There are no wildcard entries in Table 240 because the system has replaced all wildcard entries with a suitable range for the given attribute (e.g., replacing wildcard elements 237 and 238 with elements 247 and 248, respectively). Overlapping matching element entries are highlighted in bold, e.g., For example, for Admin 244: “20 IP protocol TCP traffic, L4 port 80-80”; “10 IP protocol UDP, L4 port 1-65535”; and “30 IP protocol 1-255, L4 port 1-65535”.Only policy entries belonging to the same source role can be candidates for new crossover policy elements, since entries belonging to different source roles do not affect the decision model for a package (because the package can only belong to a single source role).

[0049] In Table 240, the system can also add the source role to the allowed target role set 243 to permit traffic between clients belonging to the same role (“intra-role traffic”), unless there is an explicit denial policy for intra-role traffic. For example, for the source role Security 245, traffic on TCP port 90 is denied and therefore does not include the “Security” role.

[0050] When detecting overlaps, the system can only check for attributes of the same type. For example, a match element with Ethertype in one match condition is only checked for overlap with a match element with Ethertype in another match condition. Overlaps can occur between some or all match elements, or between two match conditions. Two types of overlap are possible within match conditions: a complete overlap, where a first match condition is completely contained within a second match condition, and a partial overlap, where only a portion of the match set is shared. Two match conditions C and D can be defined as completely overlapping if and only if C ⊂ D and C ≠ D.Two agreement conditions C and D can be defined such that they only partially overlap if C ∩ D ! = ∅ and C \ D ! = ∅ and D \ C ! = ∅.

[0051] Specifically, a pair of agreement conditions with completely overlapping agreement sets A and B can be partitioned into three agreement sets X, Y, Z such that X = {x: x < y ∀ y ∈ Y, x ∈ D} and Y == C and Z = {z: z > y ∀ y ∈ Y, x ∈ D}. The agreement set D is then replaced by the three agreement sets X, Y, Z because D == X ∪ Y ∪ Z. No change is made to C because C is the common set in the intersection and the two agreement elements have C in common.

[0052] A pair of agreement conditions with partially overlapping agreement sets A and B can be decomposed into three agreement sets X, Y, Z such that X = {x: x < y ∀ y ∈ Y, x ∈ C} and Y = C ∩ D and Z = {z: z > y ∀ y ∈ Y, z ∈ D}. The agreement set C is replaced by two sets X and Y because C == X ∪ Y, and D is replaced by two sets Y and Z since D ≡ Y ∪ Z.

[0053] Each element split in this way due to overlaps can be replaced by more than one matching element. It is possible for multiple matching elements belonging to the same matching condition to be split. The system can begin the crossover of the overlapping policy elements by creating a new crossover policy element using the matching set Y. For both types of overlap (full and partial), Y is the common matching set, so Y can contribute to the creation of the crossover policy element. The matching element is defined by the set Y, and the lowest sequence number of the two matching elements can be used as the sequence number of the crossover matching element. A similar approach can be used for the expansion level to be assigned to the new crossover policy element.The system can derive the action of the new crossover policy element by uniting the roles in the allowed target role sets of the two policy entries C and D. However, the system will remove any entry that is included in the explicit reject list of the policy entry with the lower degree of expansion (i.e., with a more specific match) from the new set of allowed target roles.

[0054] Thus, the system can remove the set Y from the two overlapping policy elements, since the intent for the matching set Y from both policies can be covered by the new crossover policy element. This can eliminate the overlap between the two policy elements by creating a new crossover policy element with this crossover procedure.

[0055] Some of the matching sets within a single matching element can be replaced by more than one matching set. This may require an implosion of matching elements, as each matching element must have a single matching set for a traffic attribute. New policy elements can be created by taking all combinations of these matching sets to create matching elements with single matching sets for each traffic attribute present in the matching condition. This is equivalent to an implosion of matching elements within the same matching condition of a single policy element, as shown below with respect to Fig. 2F is shown. The system can create these imploded policy elements by using each matching element of the parent policy element. These imploded policy elements can carry or store other parameters, such as the sequence number, expansion level, and action of the original matching element.

[0056] However, it is possible that not all combinations of these imploded compliance elements are valid for the originally configured matching condition, even if the individual compliance sets contributing to the compliance element were valid on their own. Therefore, the system must check all these imploded policy elements for their validity against the original policy elements to determine whether the combination of compliance elements in their compliance set is valid. Any policy elements that do not result in a successful check against the original policy can be removed from the list of newly created policy elements, leaving only the valid policy elements in the imploded list.This imploded list (with the invalid policy elements that have been trimmed or removed) can be used to replace the parent policy element, as shown below in relation to the . Fig. 2F and Fig. 2G is shown.

[0057] The system can perform the same process for both elements of the pair that were part of the overlap processing. After processing both elements of the pair, the system can eliminate all overlaps between the pairs by creating a set of new imploded policy elements and one crossover policy element. The system can perform the same process for the entire set of policy elements until all pairs in the set have been checked and handled for potential overlaps in their matching condition. After the system has completed this process of crossover, implosion, and pruning, it can determine a number of non-overlapping policy elements, with the action represented by a set of allowed target roles for the matching packages.These non-overlapping control elements can lead to an equivalent decision output (“second decision model”) as the control set originally configured by the user (“first decision model”).

[0058] The system can choose a more optimized approach for wildcard entry crossover. Because wildcard entries overlap with all policy entries, the system does not split the wildcard entries according to the procedure described above. Instead, wildcard entries can be treated as an overlap, and a union of wildcard target roles can always be included in the more specific entry, unless the more specific entry results in a conflict (i.e., it contains a "reject" policy for a target role that is included in the allowed target role group of wildcards).

[0059] Fig. 2F shows a table 250, which Fig. 2E corresponds, including implosion and truncation of entries for the source role "Admin", to one aspect of the present application. Table 250 may contain fields that include: a source role 251; matching element(s) 252; and allowed target role set(s) 253. Table 250 may contain matching element(s) 252 for a source role Admin 254 (corresponding to Admin 244). Table 250 may contain all imploded entries for the source role Admin 254, with policy entries shown in a dashed field 255 that must be removed due to a failed validation against the original user-configured policies, and policy entries shown in bold that are retained due to a successful validation against the original user-configured policies.

[0060] This second processing stage can culminate in the derivation of this non-overlapping and valid set of policy elements as a set of first synthesized policies. The system can now use this set of first synthesized policies to enforce the user-configured GBPs, even for unknown flows, since the set of first synthesized policies can provide a list of permitted target roles for the policy element's action. Third stage: Optimization through merging and sequencing

[0061] In the third processing stage, the system can perform several operations, including: optimizing the synthesized first set of policies; ensuring the correct order for elements that may have the same sequence number but define a conflicting decision; and converting the raw synthesized policy elements into a suitable policy syntax.

[0062] The system can begin the third processing stage by examining all policy elements belonging to a source role for potential merges. The system can merge two policy elements if the matching elements of both policy elements contain matching sets that are either identical or contiguous. If a merge is detected, the system can combine the two policy elements into a new scope within a new policy element. The action of the new policy element can be defined by uniting the two permitted target role sets from both policy elements. The policy entries in a dashed cell 256 of Table 250 are an example of candidate entries for a merge because their matching sets are contiguous.The system can create a single policy entry from the merging of these candidate entries in field 256, as shown below in relation to . Fig. 2G is shown.

[0063] Because the derivation of the set of synthetic policies can result in the merging of policy elements belonging to different target roles, the user-configured sequence number may no longer have a significant impact. This is because the user-configured sequence number previously indicated the relative priority with a class of entries associated with a target role. Since the system can remove all overlaps between policy elements (as described above), a package can now only be matched against a single policy element, so the sequence number may no longer be relevant for the second decision model.

[0064] However, wildcard entries are an exception to this meaning of the sequence number. Overlaps with wildcard entries are not removed in order to achieve an optimized implosion of the entries. The system can use the expansion stage to determine the relative order, with the less specific wildcard entries having a higher sequence number (i.e., a lower matching priority) than the more specific entries.

[0065] This ensures that a placeholder entry does not erroneously override traffic regulated by a more specific policy. Elements with a lower degree of expansion can represent a more specific entry, allowing the system to assign them a lower sequence number in the synthesized policy set. The system can refer to this synthesized policy set as P'. Similarly, the system can designate the collection of derived compliance elements, which comprise the compliance conditions of these policy elements, as M'.

[0066] Fig. 2G displays a table of synthesized policies based on the user-configured policies of Fig. 2A and the result of the in the Fig. The processing shown in 2B-2F is based on an aspect of the present application.

[0067] The system can translate the set of optimized policy entries (as shown in Table 260) into user-readable policy syntax. The system can first perform a reverse transformation of the match sets in each policy element. Any match set representing the entire match space can be replaced with the string "Any". Any match set with a single element can be translated into a single value instead of a set. Any list representing a contiguous set of values ​​can be converted into a range with the notation "a:b". After the system has performed this transformation of the match sets, the synthesized policy element can be translated into policy entries using actual policy syntax as described below.

[0068] A policy element can be represented as follows: s∗¥i3≡(m:m∈M'L:L≡{r:r∈G}n:n∈N) where L is a set of target roles that represent the derived action for the synthesized policy element. The system can represent this policy element using policy syntax such as the following: "Policy sequence number n for source role s with compliance condition m allows traffic to a target role set L."

[0069] The decision model for this set of optimized, synthesized policies (“second decision model”) can first identify the source role s for an incoming package k. The system can then retrieve the set of policy entries that are associated with the source role s. The second decision model can be expressed as follows: s = role of the source s∗Y=P'[s] For each guideline element E in s∗Y For the set of matching elements T in E match=∧t∈Tft(k)

[0070] For the first policy element E' that evaluates to 'match'==TRUE, the system can apply the action associated with that specific policy entry to packet k. The action in the synthesized policy element is not a member of the action set A and is instead an "allow list" represented by a set of permitted target roles for which traffic is allowed. The system can represent each target role set as a "Role Policy Aware Distribution List" (RPADL), which can contain a list of ports. The system can include a specific port in the RPADL for a target role set if at least one client connected via that port belongs to one of the roles in the target role set.This can mean that a packet matching a policy element E' (as described above) may only be forwarded on a port if the port belongs to the RPADL that corresponds to the action of the policy element.

[0071] Once the system has derived the RPADL for an incoming packet, it can process the packet through the forwarding pipelines, making forwarding decisions independently of the GBPs. After making these forwarding decisions and performing any necessary replications of the incoming packets based on the forwarding lookups, the system can forward each replicated packet to the egress pipeline for egress processing. At this stage, each replicated packet can contain the RPADL information in its packet metadata. Before making a final decision on whether to forward the packet to a specific port, the system can apply the RPADL to the packet to determine if the port is permitted as an egress packet for the incoming packet, i.e., if it matches the configured GBPs.

[0072] The described aspects provide a solution that uses an approved distribution list or a target role set (e.g., via the set of synthesized policies, as in Fig. 2G) is created for a flow and can mask forbidden ports from the distribution of an incoming packet. The described aspects allow traffic on a port if a client with the permitted roles for a flow exists, so the system cannot further filter traffic if multiple clients with different roles exist on a single port. Because the system performs role-based policy enforcement at the edge of the fabric, the problem of multiple clients with different roles on a single port may not pose a practical limitation of the described aspects, as multiple clients on a single port are not expected.

[0073] Thus, the described aspects of the system can ensure the equivalence of the second decision model with the first. That is, a packet that would have been dropped under the direct application of a target-role-based policy for a given source role and traffic attributes (as in the first decision model) can now be masked by ports containing only clients belonging to that role (as in the second decision model). Methods for enabling policy synthesis for the enforcement of GBPs in cases of unknown flow

[0074] Fig. Figure 3 shows a flowchart 300 illustrating a procedure that enables policy synthesis to enforce GBPs for unknown flows, in accordance with an aspect of the present application. During operation, the system determines an initial set of policies defined for a switch when handling a packet, wherein a policy comprises at least one policy entry based on a target role, and wherein the at least one policy entry comprises a source role, a traffic attribute, and an action to be taken for the packet (Operation 302) (as above in relation to Fig. 2A). A policy in the first set of policies can be a user-configured policy or a group-based policy (GBP). The system represents the policies as a matrix, where the first entry in the matrix corresponds to the source role as a row and the destination role as a column, and specifies the traffic attribute and the action of the one or more policy entries (Operation 304) (as described above in relation to the Fig. 2B and Fig. 2C described). In the first entry, the system replaces the action with the target role if the action indicates that the packet should be allowed, and with a null value if the action indicates that the packet should be rejected, in order to obtain an initial data structure with entries that specify a multitude of traffic attributes for each source role and a corresponding set of allowed target roles for each traffic attribute (Operation 306) (as described above in relation to Fig. 2D described).

[0075] The system resolves an overlapping pair comprising a first traffic attribute and a second traffic attribute from the multitude of traffic attributes in the first data structure to obtain a second data structure (Operation 308) (as above in relation to the Fig. 2E and Fig. (described in 2F). The system determines that a third set of traffic attributes and a corresponding set of allowed target roles for a source role in the second data structure do not match a policy (e.g., a user-configured policy or a GBP) (Operation 310) and removes the third set of traffic attributes and the corresponding set of allowed target roles from the second data structure to obtain a second set of synthesized policies, where a first decision model based on the first set of policies yields the same result for handling the package as a second decision model based on the second set of synthesized policies (Operation 312) (as described above in relation to the Fig. 2F and Fig. 2G described).

[0076] Fig. Figure 4A shows a flowchart 400 that presents a method for enabling policy synthesis for enforcing GBPs for unknown flows, including implosion, intersection detection and handling, pruning, and merging, in accordance with an aspect of the present application. The operations in flowchart 400 provide additional details for the operations in flowchart 300. The system transforms a placeholder value for the first traffic attribute into a set of elements with all possible values ​​for the first traffic attribute (operation 422). The system specifies in the first traffic attribute an expansion degree associated with the transformed placeholder value (operation 424).The system identifies the overlapping pair based on at least one of the following: a wildcard used in the first or second traffic attribute; a range of values ​​used in the first or second traffic attribute; a full overlap; and a partial overlap (Operation 406). The system resolves the overlapping pair by identifying three sets, comprising: two sets of non-overlapping traffic attributes and associated permitted destination roles; and one set comprising a crossover policy element derived from a union of permitted destination roles corresponding to the first and second traffic attributes (Operation 408).The system displays a degree of expansion in each of the three identified sets, which is associated with at least one of the respective non-overlapping traffic attributes, the first traffic attribute and the second traffic attribute (Operation 410), and the operation is executed at Label A in . Fig. Continued in 4B.

[0077] Fig. Figure 4B shows a flowchart 420 illustrating a procedure that enables policy synthesis to enforce GBPs for unknown flows, including implosion, crossover detection and handling, pruning, and merging, according to one aspect of the present application. The system assigns a third sequence number to the crossover policy element, comprising a lower sequence number from a first sequence number for the first traffic attribute and a second sequence number for the second traffic attribute (Operation 422). The system replaces the overlapping pair with the three identified sets to obtain the second data structure (Operation 424). The system determines that a fourth traffic attribute and a fifth traffic attribute in the second data structure are identical or contiguous (Operation 426).The system combines the fourth traffic attribute and the fifth traffic attribute into a new traffic attribute that corresponds to a union of the permitted target roles corresponding to the fourth and fifth traffic attributes (Operation 428), and the operation returns. Computer system and device

[0078] Fig. Figure 5 shows a computer system that enables the synthesis of policies to enforce GBPs for unknown flows, in accordance with one aspect of the present application. The computer system 500 comprises a processor 502, volatile memory 506, and a storage device 508. In some aspects, the computer system 500 may include a controller 504 (indicated by the dashed lines). The volatile memory 506 may, for example, include random-access memory (RAM) that serves as managed memory and can be used to store one or more memory pools. The storage device 508 may include persistent memory that is managed or accessible via the processor 502 (or the controller 504). Furthermore, the computer system 500 may be coupled with peripheral I / O user devices 510, such as a display device 511, a keyboard 512, and a pointing device 514.The storage device 508 can store an operating system 516, a content processing system 518 and data 536.

[0079] The content processing system 518 may contain instructions which, when executed by the computer system 500, can cause the computer system 500 or the processor 502 to perform the procedures and / or processes described in this disclosure. In particular, the content processing system 518 may contain instructions for receiving and sending data packets, requests, and responses (communication module 520).

[0080] The Content Processing System 518 can further include commands for determining an initial set of policies defined for a switch when handling a packet, wherein a policy comprises at least one policy entry based on a target role, and wherein the at least one policy entry includes a source role, a traffic attribute, and an action to be taken for the packet (GBP Management Module 522). The Content Processing System 518 can include commands for representing the policies as a matrix, wherein a first entry in the matrix corresponds to the source role as a row and the target role as a column, and specifies the traffic attribute and the action of the at least one policy entry (Data Transformation Module 524).Content Processing System 518 can include commands to replace the action in the first entry with the target role if the action indicates that the packet should be allowed, and with a null value if the action indicates that the packet should be rejected, in order to obtain a first data structure with entries that indicate a variety of traffic attributes for each source role and a corresponding set of allowed target roles for each traffic attribute (Data Transformation Module 524). Content Processing System 518 can also include commands to resolve an overlap pair comprising a first traffic attribute and a second traffic attribute to obtain a second data structure (Overlap Management Module 526).The content processing system 518 can contain commands to determine that a third traffic attribute for a source role in the second data structure does not match a policy, and to remove the third traffic attribute from the second data structure to obtain a second set of synthesized policies (Policy Trimming Module 528 and Synthesized Policy Management Module 534).

[0081] The content processing system 518 can additionally include commands for detecting and handling overlaps (Overlap Management module 526), ​​imploding policy elements (Data Implosion module 532), trimming policy elements (Policy Trimming module 528), and merging policies (Policy Merge module 530), including those mentioned above in relation to the Fig. 4A and Fig. 4B described. The content processing system 518 can include commands for creating the second decision model based on the second set of synthesized policies, where a first decision model based on the first set of policies yields the same result for handling a package as a second decision model based on the second set of synthesized policies (module 534 for managing synthesized policies).

[0082] The data 536 may include all data required as input or generated as output by the procedures and / or processes described in this disclosure. In particular, the data 536 may store at least the following: data; a request; a response; a policy; a user-configured policy; a group-based policy; a set of policies; a policy entry; a source role; a destination role; a traffic attribute; a match element; a match condition; an action; a matrix; a transposed matrix; an entry; a substituted action; a null value; a set of allowed destination roles; an overlapping pair; a resolved overlapping pair; a first data structure; a second data structure; a transformed data structure; a synthesized policy; a set of synthesized policies; a placeholder; a placeholder value; an expansion stage;a set of non-overlapping traffic attributes; a crossover policy element; a union of allowed destination roles; a sequence number; a user-configured sequence number; a match priority; a range of values; a full overlap; a partial overlap; a set of disallowed destination roles; an allow list; a deny list; a network protocol; a port number; configuration information for a switch; a feature of network traffic; a first-line decision model; a second-line decision model; an input and an output.

[0083] Fig. Figure 6 shows a device 600 that enables the synthesis of guidelines for enforcing GBPs for unknown flows in accordance with an aspect of the present application. The device 600 can comprise a plurality of units or devices that can communicate with each other via a wired, wireless, quantum light, or electrical communication channel. The device 600 can be implemented with one or more integrated circuits and can comprise fewer or more units or devices than those shown in Figure 6. Fig. The device 600 can be integrated into a computer system or implemented as a separate device or devices that can communicate with other computer systems and / or devices.

[0084] The device 600 may also include a non-volatile memory system or a memory management unit. The device 600 may include modules or units 602-616 configured to perform similar functions or operations to the modules 520-534 of the computer system 500. Fig. 5 execute, including: a Communication Unit 602; a GBP Management Unit 604; a Data Transformation Unit 606; an Overlap Management Unit 608; a Policy Trimming Unit 610; a Policy Merging Unit 612; a Data Implosion Unit 614; and a Synthesized Policy Management Unit 616.

[0085] In general, the disclosed aspects provide a system that enables policy synthesis to enforce GBPs for unknown flows. In one aspect of the present application, the system determines an initial set of policies defined for a switch when handling a packet, wherein a policy comprises at least one policy entry based on a target role, the at least one policy entry comprising a source role, a traffic attribute, and an action to be taken for the packet. The system represents the policies as a matrix, with a first entry in the matrix corresponding to the source role as a row and the target role as a column, and specifying the traffic attribute and the action of the at least one policy entry.In the first entry, the system replaces the action with the target role if the action indicates allowing the packet, and with a null value if the action indicates rejecting the packet. This creates an initial data structure containing entries that specify a variety of traffic attributes for each source role and a corresponding set of allowed target roles for each traffic attribute. The system then resolves an overlapping pair comprising a first traffic attribute and a second traffic attribute to obtain a second data structure. The system determines that a third traffic attribute for a source role in the second data structure does not match a policy.The system removes the third traffic attribute from the second data structure to obtain a second set of synthesized policies, where a first decision model based on the first set of policies yields the same result as a second decision model based on the second set of synthesized policies.

[0086] In one variation of this aspect, the system performs the following operations before resolving the overlapping pair in the first data structure. The system transforms a placeholder value for the first traffic attribute into a set of elements with all possible values ​​for the first traffic attribute and specifies an expansion level associated with the transformed placeholder value in the first traffic attribute. The expansion level is based on at least one of the following: a list derived from an exact value; a list derived from a range of values; and a list derived from a placeholder value.

[0087] In another variant, the system resolves the overlapping pair in the first data structure by identifying three sets comprising: two sets of non-overlapping traffic attributes and associated permitted destination roles; and one set comprising a crossover policy element derived from the union of a first set of permitted destination roles corresponding to the first traffic attribute and a second set of permitted destination roles corresponding to the second traffic attribute. The system displays an expansion degree in each of the three identified sets that is associated with at least one of the non-overlapping traffic attributes, the first traffic attribute, and the second traffic attribute. The system replaces the overlapping pair with the three identified sets to obtain the second data structure.

[0088] In another variant, each traffic attribute is associated with a user-configured sequence number. The system assigns a third sequence number to the crossover policy element, which comprises a lower number than the first user-configured sequence number assigned to the first traffic attribute and the second user-configured sequence number assigned to the second traffic attribute.

[0089] In another variant, the system assigns a sequence number to each policy element or traffic attribute in the second group of synthesized policies, based on the specified degree of expansion. A first policy element with a lower degree of expansion and a lower sequence number indicates a more specific policy than a second policy element with a higher degree of expansion and a higher sequence number, and the higher sequence number indicates a lower compliance priority in the second set of synthesized policies for the source role.

[0090] In another variant, the system recognizes the overlapping pair based on at least one of the following features: a placeholder used in the first or second traffic attribute; a range of values ​​used in the first or second traffic attribute; a complete overlap where the first traffic attribute is contained in the second traffic attribute; and a partial overlap where part of the first traffic attribute matches part of the second traffic attribute.

[0091] In another variant, after removing the third traffic attribute from the second data structure, the system removes a corresponding third set of permitted target roles from the second data structure. Upon detecting that a fourth and a fifth traffic attribute in the second data structure are identical or adjacent, the system merges the fourth and fifth traffic attributes into a new traffic attribute. This new traffic attribute is a union of a fourth set of permitted target roles corresponding to the fourth traffic attribute and a fifth set of permitted target roles corresponding to the fifth traffic attribute.

[0092] In another variant, the entries in the first data structure for each source role and traffic attribute indicate a corresponding set of unauthorized destination roles. The system determines that the third traffic attribute does not comply with the policy based on this set of unauthorized destination roles.

[0093] In another variant, a traffic attribute comprises a variety of attributes that are associated with at least one of the following: a network protocol, a port number, information associated with a switch configuration, and a characteristic of the network traffic.

[0094] In another variant, the first decision model takes a source role, a destination role, and traffic attributes as input for an incoming packet and returns an action for the incoming packet as output. The second decision model takes a policy sequence number, the source role, and the traffic attributes as input for the incoming packet and returns a set of allowed destination roles as output.

[0095] In another variant, the policies in the first set of policies include at least one of the following: a user-configured policy and a group-based policy.

[0096] In another variant, the procedure, prior to displaying the policies as a matrix, further includes the system performing the following operations. The system displays the initial set of user-configured policies as an initial matrix, where the first entry in the initial matrix corresponds to the source role as a row and the target role as a column, and specifies the traffic attribute and the action of the one or more policy entries. The system transposes the initial matrix to obtain the matrix, where the first entry in the initial matrix provides the same information as the first entry in the matrix.

[0097] The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which can be any device or medium capable of storing code and / or data for use by a computer system. Computer-readable storage media include, but are not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tapes, CDs (Compact Discs), DVDs (Digital Versatile Discs or Digital Video Discs), or other media capable of storing computer-readable media known today or developed in the future.

[0098] The procedures and processes described in the "Detailed Description" section can be embodied as code and / or data, which can be stored on a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system executes the procedures and processes that are embodied as data structures and code and stored on the computer-readable storage medium.

[0099] Furthermore, the procedures and processes described above can be integrated into hardware devices or apparatus. These hardware devices or apparatus may include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), dedicated or shared processors that execute a specific software program or piece of code at a specific time, and other programmable logic devices known today or developed later. When the hardware devices or apparatus are activated, the hardware modules execute the procedures and processes they contain.

[0100] The foregoing descriptions of aspects serve only for illustration and description. They do not claim to be exhaustive and do not limit the aspects described herein to the disclosed forms. Accordingly, many modifications and variations will be obvious to those skilled in the art. Furthermore, the above disclosure is not intended to limit the aspects described herein. The scope of the aspects described herein is defined by the attached claims.

Claims

[1] A computer-executable procedure comprising: Determining a first set of policies (152) defined for a switch (103) when handling a packet, wherein a policy includes at least one policy entry based on a target role and wherein the at least one policy entry includes a source role, a traffic attribute and an action to be performed for the packet; Receiving an incoming packet at the switch, where the destination of the incoming packet is unknown; Representing the first set of policies as a matrix, where a first entry in the matrix corresponds to the source role as a row and the destination role as a column, and specifies the traffic attribute and the action of the at least one policy entry; Replacing the action in the first entry with the target role if the action indicates that the packet should be allowed, and with a null value if the action indicates that the packet should be rejected, in order to obtain an initial data structure with entries that specify a multitude of traffic attributes for each source role and a corresponding set of allowed target roles for each traffic attribute; Resolving an overlapping pair comprising a first traffic attribute and a second traffic attribute to obtain a second data structure; Finding that a third traffic attribute for a source role in the second data structure does not comply with a policy; Removing the third traffic attribute from the second data structure to obtain a second set of synthesized policies (154), where a first decision model based on the first set of guidelines leads to the same result as a second decision model based on the second set of synthesized guidelines; Allowing or rejecting the forwarding of the incoming packet at the switch using the second decision model; in response to allowing the incoming packet to be forwarded to a local host; and as a reaction to the rejection, the dismissal of the incoming package. [2] The computer-executable method according to claim 1, wherein the method further comprises, prior to resolving the overlapping pair in the first data structure: Converting a placeholder value for the first traffic attribute into a set of elements with all possible values ​​for the first traffic attribute; and Specifying an expansion degree assigned to the converted placeholder value in the first traffic attribute, where the degree of expansion is based on: a list derived on the basis of an exact value, a list derived on the basis of a range of values, and / or a list derived on the basis of a placeholder value. [3] The computer-executable method according to claim 2, comprising resolving the overlapping pair in the first data structure: Identifying three sets, including: two sets of non-overlapping traffic attributes and associated permitted target roles; and a set comprising a crossover policy element derived on the basis of a union of a first set of permitted target roles corresponding to the first traffic attribute and a second set of permitted target roles corresponding to the second traffic attribute; Specify, in each of the identified three sets, a degree of expansion that is assigned to at least one of a respective non-overlapping traffic attribute, the first traffic attribute and the second traffic attribute; and Replacing the overlapping pair with the identified three sets to obtain the second data structure. [4] The computer-executable method according to claim 3, wherein a respective traffic attribute is assigned to a user-configured sequence number, and wherein the method further comprises: Assigning a third sequence number to the crossover policy element, comprising a lower number from a first user-configured sequence number associated with the first traffic attribute and a second user-configured sequence number associated with the second traffic attribute. [5] The computer-executable method of claim 4, further comprising: Assigning a sequence number to a respective policy element or traffic attribute in the second set of synthesized policies based on the specified degree of expansion, where a first policy element with a lower degree of expansion and a lower sequence number specifies a more specific policy than a second policy element with a higher degree of expansion and a higher sequence number, and where the higher sequence number indicates a lower matching priority in the second set of synthesized guidelines for the source role. [6] The computer-executable method of claim 1, further comprising: Identifying the overlapping pair based on at least one of: a placeholder used in the first or second traffic attribute a value range used in the first or second traffic attribute a complete overlap, whereby the first traffic attribute is subsumed under the second traffic attribute, and / or a partial overlap, where part of the first traffic attribute coincides with part of the second traffic attribute. [7] The computer-executable method according to claim 1, wherein the method after removing the third traffic attribute from the second data structure further comprises: Removing a corresponding third set of permitted target roles from the second data structure; and in response to the finding that a fourth traffic attribute and a fifth traffic attribute in the second data structure are identical or adjacent to each other: Merging the fourth traffic attribute and the fifth traffic attribute into a new traffic attribute that corresponds to a union of a fourth set of permitted target roles corresponding to the fourth traffic attribute and a fifth set of permitted target roles corresponding to the fifth traffic attribute. [8] The computer-executable method according to claim 1, wherein the entries in the first data structure further specify a corresponding set of disallowed destination roles for the respective source role and traffic attribute, and the finding that the third traffic attribute is not in accordance with the directive is based on the corresponding quantity of non-approved target roles. [9] The computer-executable method according to claim 1, wherein a traffic attribute comprises a plurality of attributes which are assigned as follows: a network protocol a port number, Information associated with a switch configuration, and / or a characteristic of network traffic. [10] The computer-executable method according to claim 1, where the first decision model takes a source role, a destination role, and traffic attributes as input for the incoming packet and returns an action for the incoming packet as output, and where the second decision model takes as input for the incoming packet a policy sequence number, the source role and the traffic attributes and returns as output a set of allowed destination roles. [11] The computer-executable method according to claim 1, wherein the guidelines in the first set comprise: a user-configured policy and / or a group-based policy. [12] The computer-executable method according to claim 1, wherein the method further comprises, prior to displaying the guidelines as a matrix: Representing the initial set of policies as an initial matrix, where a first entry in the initial matrix corresponds to the source role as a row and the destination role as a column, and specifies the traffic attribute and the action of the one or more policy entries; and Transposing the initial matrix to obtain the matrix where the first entry in the initial matrix provides the same information as the first entry in the matrix. [13] A computer system (500), comprising: a processor (502) and a memory coupled to the processor (508) which stores instructions which, when executed by the processor, cause the processor to perform a procedure comprising: Determining a first set of policies (152) defined for a switch (103) when handling a packet, wherein a policy includes at least one policy entry based on a target role and wherein the at least one policy entry includes a source role, a traffic attribute and an action to be performed for the packet; Representing the first set of policies as a matrix, where a first entry in the matrix corresponds to the source role as a row and the destination role as a column, and specifies the traffic attribute and the action of the at least one policy entry; Replacing the action in the first entry with the target role if the action indicates that the packet should be allowed, and with a null value if the action indicates that the packet should be rejected, in order to obtain an initial data structure with entries that specify a multitude of traffic attributes for each source role and a corresponding set of allowed target roles for each traffic attribute; Resolving an overlapping pair comprising a first traffic attribute and a second traffic attribute to obtain a second data structure; Determine that a third traffic attribute for a source role in the second data structure does not match a policy; and Removing the third traffic attribute from the second data structure to obtain a second set of synthesized policies (154), where a first decision model based on the first set of guidelines leads to the same result as a second decision model based on the second set of synthesized guidelines. [14] The computer system according to claim 13, wherein the method further comprises, prior to resolving the overlapping pair in the first data structure: Converting a placeholder value for the first traffic attribute into a set of elements with all possible values ​​for the first traffic attribute; and Specifying an expansion degree assigned to the converted placeholder value in the first traffic attribute, where the degree of expansion is based on: a list derived on the basis of an exact value, a list derived on the basis of a range of values ​​and / or a list derived from a placeholder value. [15] The computer system according to claim 14, comprising resolving the overlapping pair in the first data structure: Identifying three sets, including: two sets of non-overlapping traffic attributes and associated permitted target roles; and a set comprising a crossover policy element derived on the basis of a union of a first set of permitted target roles corresponding to the first traffic attribute and a second set of permitted target roles corresponding to the second traffic attribute; Specify, in each of the three identified sets, a degree of expansion that is assigned to at least one of a respective non-overlapping traffic attribute, the first traffic attribute and the second traffic attribute; and Replacing the overlapping pair with the identified three sets to obtain the second data structure. [16] The computer system according to claim 13, wherein the method further comprises: Identifying the overlapping pair based on: a placeholder used in the first or second traffic attribute a range of values ​​used for the first or second traffic attribute, a complete overlap, whereby the first traffic attribute is subsumed under the second traffic attribute, and / or a partial overlap, where part of the first traffic attribute coincides with part of the second traffic attribute. [17] The computer system according to claim 13, wherein the method after removing the third traffic attribute from the second data structure further comprises: Removing a corresponding third set of permitted target roles from the second data structure and in response to the finding that a fourth traffic attribute and a fifth traffic attribute in the second data structure are identical or adjacent to each other: Merging the fourth traffic attribute and the fifth traffic attribute into a new traffic attribute that corresponds to a union of a fourth set of permitted target roles corresponding to the fourth traffic attribute and a fifth set of permitted target roles corresponding to the fifth traffic attribute. [18] The computer system according to claim 13, where the first decision model takes as input for an incoming packet a source role, a destination role and traffic attributes and returns as output an action for the incoming packet, and where the second decision model takes as input for the incoming packet a policy sequence number, the source role and the traffic attributes and returns as output a set of allowed destination roles. [19] A non-transitory computer-readable storage medium (508) which stores instructions which, when executed by a computer (500), cause the computer to perform a procedure comprising: Determining a first set of policies (152) defined for a switch (103) when handling a packet, wherein a policy includes at least one policy entry based on a target role and wherein the at least one policy entry includes a source role, a traffic attribute and an action to be performed for the packet; Representing the first set of policies as a matrix, where a first entry in the matrix corresponds to the source role as a row and the destination role as a column, and specifies the traffic attribute and the action of the at least one policy entry; Replacing the action in the first entry with the target role if the action indicates that the packet should be allowed, and with a null value if the action indicates that the packet should be rejected, in order to obtain an initial data structure with entries that specify a multitude of traffic attributes for each source role and a corresponding set of allowed target roles for each traffic attribute; Resolving an overlapping pair comprising a first traffic attribute and a second traffic attribute to obtain a second data structure; Determine that a third traffic attribute for a source role in the second data structure does not match a policy; Removing the third traffic attribute from the second data structure to obtain a second set of synthesized policies (154), where a first decision model based on the first set of policies leads to the same result as a second decision model based on the second set of synthesized policies, and Allowing or rejecting the forwarding of an incoming packet at the switch using the second decision model, where allowing causes the switch to forward the incoming packet to a local host, and Rejecting the request causes the switch to discard the incoming packet. [20] The non-transitory computer-readable storage medium according to claim 19, wherein the method further comprises: Identifying the overlapping pair based on: a placeholder used in the first or second traffic attribute a range of values ​​used for the first or second traffic attribute, a complete overlap, whereby the first traffic attribute is subsumed under the second traffic attribute, and / or a partial overlap, where part of the first traffic attribute coincides with part of the second traffic attribute.

Images