Methods, computer systems, and computer-readable storage media for strategy synthesis

Abstract

This disclosure relates to policy synthesis for implementing group-based policies on unknown flows. A system determines a first group of policies, wherein at least one policy entry for a destination role includes a source role of the group, a business attribute, and an action to be taken. The system represents the policies as a matrix, wherein a first entry in the matrix indicates the source and destination roles, the business attribute, and the action of at least one policy entry. In the first entry, if the action indicates that the grouping is allowed, the system replaces the action with the destination role; if the action indicates that the grouping is rejected, the system replaces the action with a null value to obtain a first data structure with entries indicating the business attribute of the corresponding source role and the corresponding allowed destination roles for each group. The system parses overlapping pairs including a first business attribute and a second business attribute to obtain a second group of policy synthesis.

Description

Technical Field

[0001] This disclosure generally relates to the field of data management. More specifically, this disclosure relates to methods and systems for policy synthesis to implement group-based policies on unknown flows. Attached Figure Description

[0002] Figure 1 A network facilitating source role-based policy implementation is illustrated according to one aspect of this application;

[0003] Figure 2A A table showing a user-configured group-based policy (GBP) according to one aspect of this application is illustrated;

[0004] Figure 2B A table showing a user-configured GBP in matrix form according to one aspect of this application is illustrated;

[0005] Figure 2C This application illustrates one aspect based on and Figure 2B The associated transpose form indicates the user-configured GBP table in matrix form;

[0006] Figure 2D A table showing a set of strategies with transformed actions according to one aspect of this application is provided;

[0007] Figure 2E This illustrates an aspect of the application, including wildcard expansion and overlap detection of entries. Figure 2D Corresponding table;

[0008] Figure 2F This illustrates the implosion and pruning of an entry including the source role "Admin" according to one aspect of this application. Figure 2E Corresponding table;

[0009] Figure 2G An example based on one aspect of this application is shown. Figure 2A User configuration policies and Figures 2B-2F The table describes the synthesis strategy of the processing results;

[0010] Figure 3 A flowchart illustrating a method for implementing GBP to an unknown flow according to one aspect of this application is presented.

[0011] Figure 4A A flowchart illustrating a method for implementing GBP to an unknown stream according to one aspect of this application is presented, including implosion, overlap detection and processing, pruning and merging;

[0012] Figure 4BA flowchart illustrating a method for implementing GBP to an unknown stream according to one aspect of this application is presented, including implosion, overlap detection and processing, pruning and merging;

[0013] Figure 5 A computer system for implementing GBP to an unknown stream is shown, according to one aspect of this application, to facilitate strategy synthesis; and

[0014] Figure 6 An apparatus for promoting strategy synthesis to implement GBP to an unknown stream is shown according to one aspect of this application.

[0015] In the accompanying drawings, the same reference numerals refer to the same elements. Detailed Implementation

[0016] The following description is presented to enable any person skilled in the art to make and use these aspects and examples, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed aspects will be apparent to those 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 this disclosure. Therefore, the aspects described herein are not limited to those shown, but should be given the broadest scope consistent with the principles and features disclosed herein.

[0017] The Internet is the delivery medium for a wide range of applications running on physical and virtual devices. These applications generate ever-increasing business demands. Therefore, equipment vendors continue to build switches with multiple functionalities. For example, network segmentation can be used to isolate user traffic and reduce the broadcast domain in the network. Traditionally, local Virtual LANs (VLANs) have been used for network traffic segmentation at L2, while IP subdomains have been used for L3. Traditional edge network segmentation (e.g., at switches or access points where clients can directly attach to switches that enforce role-based policies) can face challenges such as: integration of traditional wired and wireless infrastructure; the increasing number of mobile devices in the network; and the deployment of a large number of Internet of Things (IoT) devices. Furthermore, supporting a large number of devices with different access requirements and threat awareness levels, as well as traditional manual and static configuration using Internet Protocol (IP) subnets and Access Control Lists (ACLs), can be challenging when expanding the network.

[0018] Group-based policy (GBP) can provide a solution for dynamic network segmentation. GBP allows network administrators to configure policies that define permitted service patterns across user roles or within user roles. GBP can be configured as a policy between a source role and a destination role, and can facilitate both micro-segmentation (within the same subnet) and macro-segmentation (across different subnets). The system can analyze the sender of packets at the ingress node and carry the analytical information using transport encapsulation. Segmentation using GBP works effectively when the destination of the packet is known.

[0019] However, in some scenarios, the destination of a packet may be unknown. For example, multi-destination packets (or broadcast, unknown unicast, or multicast (BUM) services) may be addressed in a way that makes it impossible for the switch to determine the destination host. The destination address of such a packet could be, for example, a multicast address that does not indicate an individual destination host. Therefore, the packet may not have a corresponding destination role. Consequently, determining whether to forward a packet to a local host based on GBP can be challenging for the switch.

[0020] The described aspect provides a solution for implementing GBP on unknown flows by taking an initial set of user-configured policies (taking source roles, destination roles, and business attributes as inputs to output allow / deny actions for groups) and synthesizing a set of policies based on the user-configured policies. The resulting set of synthesized policies can take source roles and business attributes as inputs and can output a list of allowed destination roles. Therefore, the "first decision model" based on user-configured policies can produce the same results for a given incoming group as the "second decision model" (also known as the equivalent decision model) based on synthesized policies. The second decision model allows the system to implement GBP in scenarios with unknown destination roles or flows (such as in BUM services).

[0021] In this disclosure, the term "switch" is used in a general sense and can refer to any standalone or structured switch operating at any network layer. "Switch" should not be construed as limiting aspects of the invention to Layer 2 networks. Any device that can forward traffic to external devices or other switches can be called a "switch". Any physical or virtual device (e.g., a virtual machine or switch running on a computing device) that can forward traffic to end devices can be called a "switch". Examples of "switch" include, but are not limited to, Layer 2 switches, Layer 3 routers, routing switches, components of Gen-Z networks, or structured switches, including multiple similar or heterogeneous smaller physical and / or virtual switches.

[0022] The term "packet" refers to a group of bits that can be transmitted together over a network. "Packet" should not be construed as limiting aspects of the invention to Layer 3 networks. "Packet" can be replaced by other terms referring to a group of bits, such as "message," "frame," "cell," "datagram," or "transaction." Furthermore, the term "port" can refer to a port that can receive or transmit data. "Port" can also refer to the hardware, software, and / or firmware logic that facilitates the operation of that port.

[0023] Policy implementation in coverage topology

[0024] Switches can support different protocols and services. For example, switches can support tunneling and Virtual Private Networks (VPNs). Therefore, switches can facilitate VPN overlay routing over tunnels. For example, an Ethernet VPN (EVPN) can be deployed as overlay over a set of Virtual Extensible Local Area Networks (VXLANs).

[0025] To deploy a VPN over a tunnel, the corresponding tunnel endpoint can map the corresponding client Virtual Local Area Network (VLAN) to the corresponding Tunnel Network Identifier (TNI), which identifies the virtual network used for the tunnel. The TNI can appear in the tunnel header encapsulating packets and is used to forward the encapsulated packets via the tunnel. For example, if the tunnel is based on VXLAN, the TNI can be the Virtual Network Identifier (VNI) in the VXLAN header, and the tunnel endpoint can be a VXLAN Tunnel Endpoint (VTEP). If Layer 3 routing and forwarding are required, the TNI can also be mapped to the Virtual Router and Forwarder (VRF) associated with the tunnel.

[0026] VPNs can be deployed over tunnels formed between backbone (or non-access) switches in a network. For example, if a network includes core switches, aggregation switches, and access switches, the core and aggregation switches can be referred to as backbone switches. A set of tunnels between backbone switches can form an overlay tunnel structure. In other words, the backbone switches in the tunnel structure can operate as tunnel endpoints and facilitate routing over the tunnels. On the other hand, access switches can receive packets from hosts (or client devices) and facilitate packet distribution at the underlying layer. Because VPNs can be distributed over tunnel structures, a VPN over a tunnel structure can also be called a distributed tunnel structure.

[0027] Figure 1A network facilitating source role-based policy implementation according to one aspect of this application is illustrated. Network 100 may include multiple switches and devices. Network 100 may be Ethernet, InfiniBand, or other networks, and may use corresponding communication protocols such as Internet Protocol (IP), Fibre Channel over Ethernet (FCoE), or other protocols. Network 100 may include a distributed tunneling structure 110, which includes switches 101, 102, 103, 104, and 105. Switches 101 and 102 of structure 110 may be coupled to a core switch 106. Structure 110 may be coupled to an external network 120 via switch 106 (e.g., a Layer 3 router).

[0028] exist Figure 1 In this architecture, the corresponding links in structure 110 can be tunnels. The switches in structure 110 can form a tunnel network. Examples of tunnels include, but are not limited to, VXLAN, Generic Routing Encapsulation (GRE), Network Virtualization Using GRE (NVGRE), Geneve, and Internet Protocol Security (IPsec). VPN 130 (such as EVPN) can be deployed on top of structure 110. Structure 110 can include an aggregation layer 108, which can include aggregation switches 103, 104, and 105. The respective aggregation switches can aggregate traffic from one or more downstream access switches.

[0029] Furthermore, aggregation switches 103, 104, and 105 can be coupled to access layer 118, which may include access switches 111, 112, 113, 114, 115, and 116. Access layer 118 can facilitate access from fabric 110 to multiple hosts 122, 123, 124, 125, and 126. Examples of hosts may include, but are not limited to, laptops, desktops, printers, mobile phones, tablets, IoT devices, and appliances. Access switch 115 can provide access coverage for hosts 124 and 125. Similarly, access switches 111, 112, 113, and 116 can provide access coverage for hosts 121, 122, 123, and 126, respectively. In this example, access switches 113 and 114 can be coupled to aggregation switch 104 to forward traffic to fabric 110. Therefore, packets forwarded by access switch 113 can enter fabric 110 via aggregation switch 104.

[0030] Using existing technology, when host 123 joins the coverage area of ​​access switch 113, access switch 113 can authenticate host 123 from authentication server 140. Authentication of host 123 can be based on an authentication process supported by access layer 118. For example, the authentication process can be based on 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 the host role 134 of host 123 and assign a VLAN to host 123 based on the host role. Host role 134 can be provided by authentication server 140 and can indicate the affiliation between users of host 123 and entities associated with VPN 130. Host role 134 can indicate one or more of the following: the department of the user of host 123; the access level granted to the user; and the communication domain of host 123.

[0031] For example, if host 123 is associated with a user with administrative privileges, role 134 could be an administrator role. Conversely, if host 123 is associated with a guest user, role 134 could be a guest role. Similarly, the corresponding access switch at access layer 118 can determine role 132 for hosts 121 and 125, role 134 for host 122, and role 136 for hosts 124 and 126. Therefore, these roles can define policies for accessing and forwarding services within structure 110, rather than the physical location of hosts or switches. By associating host 123 with role 134, host 123 can be assigned to a group of hosts belonging to role 134. A host can be associated with one or more groups. Users (e.g., administrators) can then configure GBP for structure 110 to facilitate service segmentation based on roles 132, 134, and 136 determined during the authentication process. Therefore, GBP allows administrators to configure policies that define permissible service patterns across roles 132, 134, and 136 within structure 110.

[0032] In architecture 110, GBPs can be deployed at the egress switch without being distributed across architecture 110. For example, for packets received via tunnel, switch 103 can act as a policy and maintain a policy table 150, which includes a set of policies (e.g., GBPs or user-configured policies) 152 defined based on source and destination roles. The corresponding policy or GBP in policy 152 can indicate whether to allow or permit the forwarding of a service category (e.g., having certain service attributes) from the source role to the destination role. For example, a GBP can indicate whether role 134 is permitted to receive Transmission Control Protocol (TCP) traffic from role 132 at port 80. Since switch 103 can act as the egress switch for packets received via tunnel, switch 103 can determine the destination role of the packets. Furthermore, switch 103 can enable policies associated with a role only if a host with that role is detected at a port of switch 103. In this way, switch 103 can effectively implement GBPs within architecture 110.

[0033] In another example, after successful authentication of host 125, host 125 can send a packet to host 122. Access switch 115 can receive the packet and forward it to structure 110. Ingress switch 105 can receive the packet and determine the source role associated with the packet (i.e., role 132 of source host 125). Switch 105 can also determine the TNI (e.g., VNI) corresponding to the VLAN of the packet. Switch 105 can further determine the remote tunnel endpoint in structure 110, such as switch 103, based on the packet's header information. Switch 105 can maintain a mapping between VLANs and TNIs to determine the TNI. Switch 105 can then encapsulate the packet with a tunnel header having the TNI, the destination address corresponding to switch 103, and the source role (e.g., using Group Policy Object (GPO) encapsulation). Subsequently, switch 105 can forward the encapsulated packet to switch 103 via the tunnel. In order to identify switch 103 as a remote tunnel endpoint, switch 105 needs to participate in the routing process of VPN 130 based on the TNI. This participation may include sharing routing information associated with the TNI with the rest of structure 110, including updating the Media Access Control (MAC) address table.

[0034] The exit switch 103, which can be another tunnel endpoint, can obtain the source role from the tunnel header and decapsulate the tunnel header to obtain the packet. Based on the destination address of the packet, switch 103 can determine the destination role (i.e., role 134 of destination host 122). Switch 103 can traverse policy 152 to determine whether to allow forwarding the packet's service class from role 132 to role 134. If allowed, switch 103 can forward the packet to host 122. Otherwise, switch 103 can avoid forwarding the packet to host 122 and can discard the packet. Therefore, Figure 1 The network described in the document depicts how fragmentation using GBP requires the sender's relevant role (i.e., the source role) and the destination of each packet (i.e., the destination role), which can work successfully when the destination of the packet is known.

[0035] However, as mentioned above, when the destination of the packet is unknown (such as in BUM operations), as discussed above... Figure 1 The described communication may not be sufficient. For example, the destination address of a packet could be a multicast address that does not indicate an individual destination host. Therefore, the packet may not have a corresponding destination role. Consequently, determining whether to forward a packet to a local host based on policy 152 may be challenging for switch 103.

[0036] The described aspect addresses this challenge by generating a set of synthetic policies 154 (as shown in policy table 150) based on user-configured policy 152. User-configured policy 152 can take source role, destination role, and business attribute as input to output allow / drop actions for grouping. Conversely, synthetic policy 154 can take source role and business attribute as input to output a list of allowed destination roles. Synthetic policy 154 can thus produce a decision model equivalent to user-configured policy 152. In other words, grouping evaluated using the decision model based on synthetic policy 154 (i.e., the "second decision model") is considered the same as when evaluated using the decision model based on user-configured policy 152 (i.e., the "first decision model").

[0037] Phase 1: Redirect the user-configured group-based policies to the transpose matrix form.

[0038] Group-based policies are traditionally associated with destination roles. A single GBP can be associated with each destination role. This single associated GBP can define a tuple of source roles and business attributes that, when matched, can allow or disallow packets from being sent to the destination, as shown below. Figure 2A As stated above.

[0039] Figure 2ATable 200 shows a group-based policy with user configuration according to one aspect of this application. Table 200 may include rows indicating: policy 201; associated destination role 202; and policy entry 203. Table 200 may include three policies, including policies for each of the three associated destination roles: policy P1 for Finance 204; policy P2 for Admin 205; and policy P3 for Security 206. Each policy may include one or more policy entries, and each policy may indicate or include: a sequence number (e.g., "10", "20", and "30"); a source role; a destination role; one or more service attributes; and an action (e.g., "allow" or "deny"). For example, policy P1 for the destination role Finance 204 may include two policy entries. The first policy entry may indicate: a sequence number of "10"; a source role of "Admin"; a destination role of "Finance"; service attributes of "IP protocol TCP" and "L4 port 10-100"; and an action of "allow". The second policy entry can indicate: sequence number "20"; source role "Any"; destination role "Finance"; service attributes "IP protocol TCP service" and "L4 port 80"; and action "Allow". Therefore, Table 200 describes how to apply the policy to incoming packets in order to segment services based on user roles.

[0040] The system can generate a set of synthetic policies in stages from the user-configured policies in Table 200. In the first stage, the system can... Figure 2A The user-configured strategy is mathematically modeled for processing, and this strategy can be used by the system in subsequent stages, as shown below. Figure 2B and Figure 2C As described above. In the second stage, the system can use the matrix output from the first stage (e.g., Figure 2C The transpose of the matrix and the set of matching criteria are taken as input to generate a set of synthetic strategies that use only the source role for policy enforcement on incoming services (e.g., Figure 2D (The "first data structure"). In the second stage, the system can also perform overlap detection and processing, as well as implosion and pruning of matching elements, as follows regarding... Figure 2D , Figure 2E and Figure 2F As described above. In the third stage, the system can further process the matching elements output from the second stage (e.g., Figure 2F The "second data structure" is optimized through merging and sorting, as follows: Figure 2G The aforementioned (e.g., the final "second combination strategy").

[0041] This system can represent mathematical models. Figure 2A The system uses user-configured GBPs, which can be used as input to a synthesis process defined by an algorithm. The system can label a set of user-configured GPBPs as P, which can be the entire set of policies, as follows:

[0042] ,in

[0043] in This represents an individual role with associated GBP P, and where... , where G is the complete set of roles participating in GBP-based segmentation. Each individual policy can be an ordered set of multiple policy entries. The policy associated with the destination role r can be represented as:

[0044]

[0045] Each strategy entry It can contain a match element and an action element. The match element can contain a source role and (multiple) business attributes used to match incoming groups. A set of matching elements. Each matching element This can be the finest-grained business attribute that can match the incoming packets. For example, a strategy intended to match TCP port 80 can be transformed into the following set of matching elements: The user can provide a sequence number n, which defines the relative priority of elements when matching conditions for multiple matching elements are grouped. Therefore, the system can represent a strategy entry as follows:

[0046]

[0047] M can be the set of matching elements that define the matching to be performed on the user's business. M can be derived by checking the user-configured policy for matching criteria present in the policy and adding each unique matching element to the set of matching elements M. Note that N can be a set of natural numbers, and A can be a set of "actions" that can have two elements (e.g., "Allow" and "Deny"). Wildcard entries can be used for both source roles and matching elements. At this stage, wildcard roles may implode, and a set of policy entries can be derived, where each policy entry can represent a policy for a given destination role and source role. For wildcard source roles, the system can perform implosion by copying the same entry for all possible source roles. The implosion of wildcard entries can be processed at a later stage. Therefore, the system can derive a set of policy entries based on destination / source role pairs, where each entry is a match / action pair, and can be represented as:

[0048]

[0049] For a given destination / source role pair, there can be multiple policy entries, where each policy entry can have a unique matching criterion and action. The system can generate an ordered list of such policy entries to obtain a complete set of policy entries for a given destination / source role pair. This set of policy entries based on the destination / source role pair can be represented as:

[0050]

[0051] Given this representation of policy entries, the system can represent the entire set of policies configured for that group of users as follows: A matrix, where each axis can represent a configured role. Rows in this matrix can represent destination roles, and columns can represent source roles. Therefore, the entire strategy set can be represented as a two-dimensional matrix:

[0052]

[0053] Therefore, the system can generate a decision model based on this representation of the user-configured policy. The first decision model based on the user-configured policy can produce the same packet processing results as the second decision model based on the synthetic policy (described below). If both models are applied independently to the same traffic and packets, they can be considered "equivalent" according to the "allow / deny" action policies for all possible network traffic and packets. Therefore, the system can make each incoming packet conform to the first decision model to determine the final action to be taken on the packet, which can be "allow" or "deny". The first decision model can be represented as follows:

[0054] d = the role of the destination

[0055] s = source role

[0056]

[0057] for Each policy element E in

[0058] For the matching element T in E

[0059]

[0060] Where k is the input group on which the first decision model is run. `match` is the matching function corresponding to the matching condition in the matching element `t`. `match` is a Boolean value indicating whether `k` satisfies the matching condition of matching element `t`. Therefore, for the first policy element `E` that results in `match` == TRUE, the system can apply the action associated with the specific policy entry to group `k`.

[0061] At this point in the first phase, the system can represent the policy P configured for this group of users as a two-dimensional matrix oriented towards destination roles. That is, destination roles are rows, and source roles are columns. The system can use this two-dimensional matrix (see below) Figure 2B (Description) to derive the group of policy elements for a pair of destination / source roles, so that the policy is applied to the incoming group based on the matching business attributes.

[0062] Figure 2B Table 210, according to one aspect of this application, is shown. Table 210 indicates user-configured GBPs in matrix form. Table 210 may include destination roles as rows (e.g., Finance 214, Admin 215, and Security 216) and source roles as columns (e.g., Admin 211, Security 212, and Finance 213). Each entry in the matrix of Table 210 may indicate one or more business attributes of a group with matching business attributes and the corresponding action to be taken. For example, entry 217 for the destination role of Security 216 and the source role of Admin 211 may indicate the following two policy elements or business attributes and actions: "10 IP protocol UDP, L4 port Any, Deny"; and "30 IP protocol arbitrary, L4 port Any, Allow".

[0063] The system can transpose the matrix P represented by Table 210 to obtain the matrix The matrix It can be targeted to the source role, as shown below. Figure 2C The transpose matrix is ​​described above. Although it is geared towards the source role, the destination role is still required.

[0064] Figure 2C Table 220 is shown according to one aspect of this application, Table 220 is based on and Figure 2BThe associated transposed form indicates the user-configured GBP in matrix form. Table 220 may include source roles as rows (e.g., Admin 224, Security 225, and Finance 226) and destination roles as columns (e.g., Finance 221, Admin 222, and Security 223). Each entry in the matrix of Table 220 corresponds to an entry in Table 210 in transposed format. For example, entry 227 in Table 220 for the source role of Admin 224 and the destination role of Security 223 may correspond to entry 217 in Table 210 and may indicate the same two policy elements or business attributes and actions: "10 IP protocol UDP, L4 port Any, deny"; and "30 IP protocol arbitrary, L4 port Any, allow".

[0065] Phase Two: Replace the action with the destination character to obtain the transformed action.

[0066] In the second stage, the system can use the transpose matrix. A set of intermediate original synthetic strategies is derived, which can be implemented using a second decision model that executes the same strategy as in P without having to use the destination role as input for lookup, as in the first decision model. The system can then use the transpose matrix... The matching criteria M are taken as input, and a set of synthesis strategies is derived. This strategy uses only the source role to determine the policy enforcement for incoming traffic or packets. The system can isolate the policies of each source role from each other, i.e., the transpose matrix. The strategy in one row (representing the strategy of one source role) does not affect the decision model in another row (representing the strategy of another source role).

[0067] This system can transpose a matrix This is written as the union of the policy sets for each source role, where each set is independent of the others. Although matching criteria in a given source role may match, this does not affect the decision model.

[0068]

[0069] in s is the source character. Furthermore, each strategy can be viewed as a set of strategy entries for the source role. A given destination role can be represented as:

[0070]

[0071] in d is the destination role. As mentioned above, source / destination roles The strategy entries can be represented as a set of strategy elements, where the transpose matrix is ​​used for the source character s. The strategy element can be written as:

[0072]

[0073] This system can begin transforming policy elements by discarding the destination role as an index, instead using the destination role as part of the action to carry the intent of the original user-configured policy. If the action indicates that grouping is allowed, the system can replace the action of each element with the destination role; otherwise, if the action indicates that grouping is denied, it replaces the action of each element with a null value. Therefore, the transformed policy element can be represented as:

[0074]

[0075] in

[0076] Therefore, the system can transform the policy from the intent "A service from source role s with business attribute matching m to destination role d should have action a" to the intent "If a is 'allowed', then a service from source role s with business attribute matching m should be allowed on destination role d". The resulting data structure can include entries indicating multiple business attributes for the corresponding source role and a corresponding set of allowed destination roles for each business attribute. The system can use wildcards " "Replace destination role d with the superscript of the transformed strategy element to indicate that the same strategy element will now match every or any destination role. (See below for more details.)" Figure 2D The description shows an example of the transformed policy element.

[0077] Figure 2DTable 230 according to one aspect of this application is shown. Table 230 indicates a set of policies with transformed actions. Table 230 may include fields including: source role 231; (multiple) matching elements 232; and (multiple) allowed destination role sets 233. Table 230 may include the following entries for the source role: Admin 234; Security 235; and Finance 236. As an example, a row or entry for the source role Admin 234 may include multiple business attributes and a corresponding set of allowed destination roles for each business attribute, including: matching element 232 "10 IP Protocol TCP, L4 Port 10-100" and the corresponding allowed destination role set 233 "{Finance}"; matching element 232 "20 IP Protocol TCP Service, L4 Port 80" and the corresponding allowed destination role set 233 "{Finance}"; matching element 232 "20 IP Protocol TCP, L4 Port 10-1000" and the corresponding allowed destination role set 233 "{Admin}"; matching element 232 "10 IP Protocol UDP, L4 Port Any" and the corresponding allowed destination role set 233 "{}"; and matching element 232 "30 IP Protocol Any, L4 Port Any" and the corresponding allowed destination role set 233 "{Security}".

[0078] For a given policy element, any role not included or listed in the allowed destination role set 233 (or the "allowed list") is implicitly rejected. Therefore, the decision model does not require a "rejection list" or a "rejected destination role set." However, similar to the allowed list, the system can maintain a rejection list for each policy. The rejection list can include roles with explicit "reject" actions in policy entries. The system can use the rejection list to prune or remove disallowed roles while merging policy entries with conflicting intents, as described below.

[0079] Various transformed strategy elements corresponding to the same source character s Overlapping conditions can be included in their matching criteria. Overlapping may occur due to the use of wildcards in the matching criteria or due to the use of ranges in the fields of the matched elements. The system can match multiple overlapping entries with business logic that has a matching pattern, and can remove overlaps to ensure that the strategy and decision-making model produces deterministic decisions.

[0080] Phase Two: Detection and handling of overlap; implosion and trimming

[0081] This system can detect overlaps and merge common matching conditions to generate a new set of cross-policy elements (original synthetic policies). This set of original synthetic policies can correspond to a second "equivalent" decision model of the first decision model (which is based on...). Figure 2A (User-configured strategy). The system can detect overlap by first converting all values, ranges, and wildcards into a set of possible natural numbers in each matching element. The converted values ​​can produce a single set of elements containing only that value. The system can convert wildcards and ranges into a set of elements with all possible values ​​for the wildcard field or for the range.

[0082] For example, if the wildcard “Any” is used to match the IP_PROTO field of an incoming packet, the system can represent that wildcard entry as Similarly, the system can represent the "Any" wildcard in the Ethertype field as... The system can use a similar approach for other business attributes, such as TCP / UDP port numbers. The system can first use this method to expand all matching conditions to detect overlaps. The system can record or mark the expansion level by adding attributes to a list: a value of "0" for an exact value exported list; a value of "1" for a list exported from outside the range; and a value of "2" for a wildcard exported list.

[0083] Figure 2E This application illustrates one aspect of wildcard expansion and overlap detection of entries. Figure 2D The corresponding table is 240. Table 240 may include the following fields: source role 241; (multiple) matching elements 242; and (multiple) allowed destination role sets 243. Table 240 may include the following entries for the source role: Admin 244 (corresponding to Admin 234); Security 245 (corresponding to Security 235); and Finance 246 (corresponding to Finance 236). No wildcard entries exist in Table 240 because the system has replaced all wildcard entries with the appropriate range for the given attribute (e.g., wildcard elements 237 and 238 are replaced with elements 247 and 248, respectively). Overlapping matching element entries are highlighted in bold, for example, for Admin 244: “20 IP protocol TCP service, L4 port 80-80”; “10 IP protocol UDP, L4 port 1-65535”; and “30 IP protocol 1-255, L4 port 1-65535”. Only strategy entries belonging to the same source role can become candidates for new cross-strategy elements, because entries belonging to different source roles will not affect the grouping decision model (since a group can only belong to a single source role).

[0084] In Table 240, the system can also add source roles to the allowed destination role set 243 to allow 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 of Security 245, traffic on TCP port 90 is denied, therefore the role “Security” is not included.

[0085] When detecting overlap, the system can only check attributes of the same type. For example, a matching element with Ethertype in one matching condition will only be checked for overlap with matching elements with Ethertype in another matching condition. Some or all matching elements may overlap, or there may be overlap between two matching conditions. There are two possible overlaps in matching conditions: complete overlap, where the first matching condition is completely contained within the second matching condition; and partial overlap, where only a portion of the matching sets is common. An overlap occurs if and only if... and At this point, two matching conditions C and D can be defined as completely overlapping. This is true if and only if... and and When two matching conditions C and D are partially overlapping, they can be defined as having a partial overlap.

[0086] Specifically, a pair of matching conditions where matching sets A and B completely overlap can be decomposed into three matching sets X, Y, and Z, such that... , and Then replace the matching set D with three matching sets X, Y, and Z, because... There is no change to C, because C is the common set in the overlap, and the two matched elements will have a common C.

[0087] A pair of matching conditions that partially overlap between matching sets A and B can be decomposed into three matching sets X, Y, and Z, such that... and and The matching set C is replaced with two sets X and Y because... so D is replaced by two sets Y and Z.

[0088] Each element split in this way due to overlap can be replaced by multiple matching elements. Multiple matching elements belonging to the same matching condition can be split. The system can begin with a cross-strategy element by creating a new cross-strategy element using a matching set Y. For both types of overlap (complete and partial), Y is a common matching set, thus Y can help generate cross-strategy elements. Matching elements are defined by set Y, and the smallest sequence number of two matching elements can be used as the sequence number of the cross-matching element. A similar approach can be used for the extension level associated with the new cross-strategy element. The system can derive the action of the new cross-strategy element using the union of the roles in the allowed destination role sets of strategy entries C and D. However, the system will remove any entries with lower extension levels (i.e., those with more specific matches) from the explicit rejection list of the new allowed destination role set.

[0089] Therefore, the system can remove set Y from two overlapping policy elements because the intent of the matching set Y from both policies can be overridden by the new cross-policy element. This overlap between the two policy elements can be eliminated by creating a new cross-policy element using this cross-policy method.

[0090] Some match sets within a single match element can be replaced with multiple match sets. This may require imploding match elements, as each match element must set a match set for a business attribute. A new strategy element can be created by taking all combinations of these match sets to create a match element with a single match set for each business attribute present in the match conditions. This corresponds to imploding match elements within the same match conditions of a single strategy element, as shown below regarding... Figure 2F As described, this system can create these implosion policy elements using each matching element from the parent policy element. These implosion policy elements can carry or store other parameters, such as sequence number, expansion level, and action from the original matching element.

[0091] However, not all combinations of these implosion matching elements are likely to be valid for the initially configured matching conditions, even if the individual matching sets that contribute to the matching elements are individually valid. Therefore, the system must check the validity of all these implosion policy elements against the original policy element to determine if combinations of matching elements in their matching sets are valid. All policy elements that did not lead to successful validation against the original policy can be pruned from the newly created list of policy elements, leaving only valid policy elements in the implosion list. This implosion list (where invalid policy elements have been pruned or removed) can be used to replace the parent policy element, as shown below regarding... Figure 2F and Figure 2G What is depicted.

[0092] The system can perform the same processing on both elements of a pair as part of the overlap processing. After processing both elements of the pair, the system can eliminate all overlap between the pair by creating multiple new implosion policy elements and one cross policy element. The system can perform the same process on the entire set of policy elements until all pairs in the set have been checked and any possible overlaps in their matching conditions have been processed. After the system completes the cross, implosion, and pruning process, it can determine multiple non-overlapping policy elements whose actions are represented as a set of allowed destination roles for matching groups. These non-overlapping policy elements can produce a decision output ("second decision model") equivalent to the original user-configured set of policies ("first decision model").

[0093] This system can take a more optimized approach to the intersection of wildcard entries. Since wildcard entries will be treated as overlapping matches of all policy entries, the system will not use the method described above to split wildcard entries. Instead, wildcard entries can be treated as overlapping, and the union of wildcard destination roles can always be included in the more specific entry, unless the more specific entry causes a conflict (i.e., includes the "reject" policy of the destination role that exists in the set of allowed destination roles of the wildcard).

[0094] Figure 2F The implosion and pruning of an entry including the source role "Admin" according to one aspect of this application are shown. Figure 2E The corresponding table is 250. Table 250 may include the following fields: source role 251; (multiple) matching elements 252; and (multiple) allowed destination role sets 253. Table 250 may include (multiple) matching elements 252 for the source role Admin 254 (corresponding to Admin 244). Table 250 may include all implosion entries for the source role Admin 254. Policy entries in dashed boxes 255 are indicated as needing pruning due to failed validation of policies configured for the original user, and policy entries listed in bold are retained due to successful validation of policies configured for the original user.

[0095] The second processing phase can conclude by deriving these non-overlapping and valid policy element sets as the first composition policy set. The system can then use this first composition policy set to implement user-configured GBPs, even for unknown flows, because this first composition policy set can provide a list of allowed destination roles in the actions of the policy elements.

[0096] Phase 3: Optimization through merging and sorting

[0097] In the third processing stage, the system can perform several operations, including: optimizing the first set of synthesized policies; ensuring the correct ordering of elements that may have the same sequence number but define conflicting decisions; and converting the original synthesized policy elements into appropriate policy syntax.

[0098] The system can begin the third processing phase by examining all policy elements belonging to a source role for possible merging. If the matching elements of two policy elements contain matching sets that are identical or consecutive to each other, the system can merge the two policy elements. If a merge is determined, the system can merge the two policy elements to form a new scope within the new policy element. The action of the new policy element can be defined by the union of the two allowed destination role sets from the two policy elements. The policy entries in dashed box 256 of Table 250 are examples of candidate entries for merging because their matching sets are adjacent to each other. The system can create a single policy entry from the merging of these candidate entries in box 256, as follows regarding... Figure 2G What is depicted.

[0099] Because the merging of policy elements belonging to different destination roles may occur during the export of the composite policy set, the user-configured sequence numbers may not have a significant impact. This is because the user-configured sequence numbers have previously specified the relative priority of a class of entries associated with a destination role. Since the system can remove all overlaps between policy elements (as described above), grouping can now only match single policy elements, and therefore the sequence numbers may no longer be relevant to the second decision model.

[0100] However, an exception to this sequence number importance is wildcard entries. To achieve more optimized entry implosion, overlaps with wildcard entries are not removed. The system can use expansion levels to determine relative ordering, with less specific wildcard entries having higher sequence numbers than more specific entries (i.e., lower matching priority). This ensures that wildcard entries do not incorrectly overwrite operations managed by more specific policies. Elements with lower expansion levels can represent more specific entries, so the system can assign lower sequence numbers to these elements in the composition policy set. The system can refer to this composition policy set as... Similarly, the system can represent the set of derived matching elements that include the matching conditions of these strategy elements as... .

[0101] Figure 2G An example based on one aspect of this application is shown. Figure 2A User configuration policies and Figures 2B-2F The table describes the synthesis strategy of the processing results.

[0102] This system can convert the set of optimization policy entries (as shown in Table 260) into user-readable policy syntax. The system can first perform a reverse transformation on the matching sets in each policy element. Each matching set representing a complete matching space can be replaced with the string "any". Each matching set with a single element can be converted to a single value instead of a set. Each list representing a set of consecutive values ​​can be converted to a range with the notation "a:b". After this transformation of the matching sets is performed by the system, the synthesized policy elements can be converted into policy entries using the actual policy syntax, as described below.

[0103] A strategy element can be represented as:

[0104]

[0105] Where L is a set of destination roles, representing the derived action of a composition strategy element. The system can use strategy syntax to represent this strategy element, such as: "The strategy sequence number n of the source role s with matching condition m allows business to the set of destination roles L".

[0106] The decision model for this set of optimized synthesis strategies ("second decision model") can first identify the source roles s of the input group k. Then, the system can retrieve the strategy entries associated with the source roles s. The second decision model can be represented as:

[0107] s = source role

[0108]

[0109] for Each policy element E in

[0110] For the matching element T in E

[0111]

[0112] For the first strategy element that causes "match" == TRUE The system can apply actions associated with specific policy entries to group k. Actions in a composite policy element are not members of action set A, but rather a list of allowed destination roles to which services will be permitted to reach. The system can represent each destination role set as a "role-policy-aware distribution list" (or RPADL), which may include a list of ports. If at least one client connected via a given port belongs to a role in the destination role set, the system can include the given port in the RPADL of the destination role set. This indicates that services are permitted only if the port belongs to the RPADL corresponding to the action of the policy element. (As described above) Matching packets are forwarded on the port.

[0113] Once the system has exported the RPADL for an incoming packet, it can allow the packet to pass through the forwarding pipeline, making forwarding decisions independent of GBP. After making a forwarding decision and performing possible replication of the incoming packet based on the forwarding lookup, the system can pass each replicated packet to the egress pipeline for egress processing. At this stage, each replicated packet can carry RPADL information in its packet metadata. Before the system finally decides whether to forward the packet on a particular port, it can apply the RPADL to the packet to determine whether that port is allowed as an egress port for the incoming packet, i.e., compliant with any configured GBP.

[0114] The described aspect provides a solution for creating a list of allowed distributions or a set of destination roles for a stream (e.g., by combining these into a strategy, such as...). Figure 2G (As shown), and prohibited ports can be masked from the distribution of incoming packets. If clients with permitted roles for a flow exist, the described aspect allows traffic on the port; therefore, if multiple clients exist on a single port belonging to different roles, the system cannot further filter traffic. Because the system performs role-based policy enforcement at the edge of the architecture, the issue of multiple clients on a single port belonging to different roles may not be a practical limitation of the described aspect, as multiple clients on a single port may not be desirable.

[0115] Therefore, the aforementioned aspects of the system can provide equivalence between the second decision model and the first decision model. That is, packets that would be dropped if a destination role-based policy were directly applied for a given source role and business attributes (as in the first decision model) can now be filtered out from ports containing only clients belonging to that role (as in the second decision model).

[0116] Methods for facilitating policy synthesis to implement GBP on unknown flows

[0117] Figure 3 Flowchart 300 is presented, illustrating a method for facilitating policy synthesis to implement GBP to an unknown flow according to one aspect of this application. During operation, the system determines a first set of policies defined for the switch when processing packets, wherein the policies include at least one policy entry based on the destination role, and wherein the at least one policy entry includes the source role of the packet, service attributes, and the action to be taken (operation 302) (as described above regarding...). Figure 2AThe policies in the first group of policies can be user-configured policies or group-based policies (GBP). The system represents policies as matrices, where the first entry in the matrix corresponds to the source role as a row and the destination role as a column, and indicates the business attributes and actions (operation 304) of at least one policy entry (as mentioned above). Figure 2B and Figure 2C (As described above). In the first entry, if the action indication allows grouping, the system replaces the action with the destination role; if the action indication denies grouping, the system replaces the action with a null value to obtain a first data structure with entries indicating multiple business attributes of the corresponding source role and a corresponding set of allowed destination roles for the corresponding business attributes (operation 306) (as mentioned above regarding...). Figure 2D (as described).

[0118] The system parses the overlapping pairs of the first and second business attributes from multiple business attributes in the first data structure to obtain the second data structure (operation 308) (as mentioned above). Figure 2E and Figure 2F The system determines that the third set of business attributes of the source role and the corresponding set of allowed destination roles in the second data structure do not match the policy (e.g., user-configured policy or GBP) (operation 310), and removes the third set of business attributes and the corresponding set of allowed destination roles from the second data structure to obtain the second combination policy, wherein the first decision model based on the first set of policies produces the same processing grouping result as the second decision model based on the second combination policy (operation 312) (as described above). Figure 2F and Figure 2G (as described).

[0119] Figure 4AFlowchart 400 is presented, illustrating a method for facilitating policy synthesis to implement GBP on an unknown flow according to one aspect of this application, including implosion, overlap detection and handling, pruning, and merging. The operations in Flowchart 400 provide additional details for the operations in Flowchart 300. The system transforms a wildcard value of a first business attribute into a set of elements having all possible values ​​of the first business attribute (operation 422). The system indicates the expansion level associated with the transformed wildcard value in the first business attribute (operation 424). The system detects overlapping pairs based on at least one of the following: wildcards used in the first or second business attribute; the range of values ​​used in the first or second business attribute; complete overlap; and partial overlap (operation 406). The system resolves overlapping pairs by identifying three sets, including: two sets of non-overlapping business attributes and associated permitted destination roles; and a set including cross-policy elements derived based on the union of permitted destination roles corresponding to the first and second business attributes (operation 408). The system indicates, in each of the three identified sets, an extension level associated with at least one of the corresponding non-overlapping service attributes, the first service attribute, and the second service attribute (operation 410), and the operation continues to... Figure 4B Tag A.

[0120] Figure 4B Flowchart 420 is presented, illustrating a method for facilitating policy synthesis to implement GBP on an unknown flow according to one aspect of this application, including implosion, overlap detection and processing, pruning, and merging. The system assigns a third sequence number to the cross-policy elements, the third sequence number comprising the lower of a first sequence number of a first business attribute and a second sequence number of a second business attribute (operation 422). The system replaces overlapping pairs with the identified three sets to obtain a second data structure (operation 424). The system determines that a fourth business attribute and a fifth business attribute in the second data structure are identical or consecutive to each other (operation 426). The system merges the fourth and fifth business attributes into a new business attribute corresponding to the union of allowed destination roles corresponding to the fourth and fifth business attributes (operation 428), and the operation returns.

[0121] Computer systems and devices

[0122] Figure 5A computer system is illustrated according to one aspect of this application for promoting strategy synthesis to implement GBP to an unknown stream. The computer system 500 includes a processor 502, volatile memory 506, and storage device 508. In some aspects, the computer system 500 may include a controller 504 (indicated by dashed lines). The volatile memory 506 may include, for example, random access memory (RAM), which serves as managed memory and can be used to store one or more memory pools. The storage device 508 may include persistent storage that can be managed or accessed via the processor 502 (or controller 504). Furthermore, the computer system 500 may be coupled to peripheral input / output (I / O) user equipment 510, such as a display device 511, a keyboard 512, and a pointing device 514. The storage device 508 may store an operating system 516, a content processing system 518, and data 536.

[0123] Content processing system 518 may include instructions that, when executed by computer system 500, can cause computer system 500 or processor 502 to perform the methods and / or processes described in this disclosure. Specifically, content processing system 518 may include instructions (communication module 520) for receiving and transmitting data packets, requests, and responses.

[0124] Content processing system 518 may further include instructions for determining a first set of policies defined for the switch when processing packets, wherein the policies include at least one policy entry based on destination roles, and wherein the at least one policy entry includes the source role of the packet, service attributes, and the action to be taken (GBP management module 522). Content processing system 518 may include instructions for representing the policies as a matrix, wherein the first entry in the matrix corresponds to the source roles as rows and the destination roles as columns, and indicates the service attributes and actions of at least one policy entry (data transformation module 524). Content processing system 518 may include instructions for: in the first entry, if the action indicates that the packet is allowed, replacing the action with the destination role, and if the action indicates that the packet is rejected, replacing the action with a null value, to obtain a first data structure with entries indicating multiple service attributes of the corresponding source role and a corresponding set of allowed destination roles for the corresponding service attributes (data transformation module 524). Content processing system 518 may further include instructions for parsing an overlap pair including a first service attribute and a second service attribute to obtain a second data structure (overlap management module 526). The content processing system 518 may include instructions (policy pruning module 528 and synthesis policy management module 534) for determining that the third business attribute of the source role in the second data structure does not match the policy and removing the third business attribute from the second data structure to obtain a second synthesis policy.

[0125] The content processing system 518 may additionally include instructions for: detecting and processing overlap (overlap management module 526), ​​implosion strategy elements (data implosion module 532), trimming strategy elements (strategy trimming module 528), and merging strategies (strategy merging module 530), including the above regarding Figure 4A and Figure 4B The described operation. Content processing system 518 may include instructions for creating a second decision model based on a second combination strategy, wherein the first decision model based on the first combination strategy produces the same processing grouping results as the second decision model based on the second combination strategy (composition strategy management module 534).

[0126] Data 536 may include any data required as input or generated as output by the methods and / or processes described in this disclosure. Specifically, data 536 may store at least: data; requests; responses; policies; user-configured policies; group-based policies; a set of policies; policy entries; source roles; destination roles; service attributes; matching elements; matching conditions; actions; matrices; transpose matrices; entries; replaced actions; null values; allowed destination roles; overlapping pairs; resolved overlapping pairs; a first data structure; a second data structure; a transformed data structure; a composition policy; a set of composition policies; wildcards; wildcard values; extension levels; a set of non-overlapping service attributes; cross policy elements; the union of allowed destination roles; sequence numbers; user-configured sequence numbers; matching priorities; ranges of values; complete overlap; partial overlap; a set of disallowed destination roles; an allowed list; a denied list; network protocols; port numbers; switch configuration information; characteristics of network services; a first decision model; a second decision model; inputs; and outputs.

[0127] Figure 6 An apparatus 600 is shown that facilitates strategy synthesis to implement GBP to an unknown stream according to one aspect of this application. Apparatus 600 may include multiple units or devices that can communicate with each other via wired, wireless, quantum optical, or electrical communication channels. Apparatus 600 may be implemented using one or more integrated circuits and may include more than Figure 6 The device 600 may be a fewer or more units or devices. Furthermore, the device 600 may be integrated into a computer system or implemented as one or more separate devices capable of communicating with other computer systems and / or devices.

[0128] Device 600 may also include a non-volatile memory system or a memory management unit. Device 600 may include modules or units 602-616, which are configured to perform actions similar to... Figure 5The functions or operations of modules 520-534 of the computer system 500 include: a communication unit 602; a GBP management unit 604; a data transformation unit 606; an overlap management unit 608; a policy pruning unit 610; a policy merging unit 612; a data implosion unit 614; and a synthesis policy management unit 616.

[0129] Typically, the disclosed aspects provide a system for facilitating policy synthesis to implement GBP (Guided Boundary Policy) on unknown flows. In one aspect of this application, the system determines a first set of policies defined for a switch when processing packets, wherein the policies include at least one policy entry based on destination roles, wherein the at least one policy entry includes the source role of the packet, a service attribute, and an action to be taken. The system represents the policies as a matrix, wherein the first entry in the matrix corresponds to the source role as rows and the destination role as columns, and indicates the service attribute and action of the at least one policy entry. In the first entry, if the action indicates that the packet is allowed, the system replaces the action with the destination role, and if the action indicates that the packet is rejected, the system replaces the action with a null value to obtain a first data structure with entries indicating multiple service attributes of the corresponding source role and a corresponding set of allowed destination roles for the service attributes. The system parses overlapping pairs including the first service attribute and the second service attribute to obtain a second data structure. The system determines that a third service attribute of the source role in the second data structure does not match the policy. The system removes the third service attribute from the second data structure to obtain a second set of synthesized policies, wherein a first decision model based on the first set of policies produces the same result as a second decision model based on the second set of synthesized policies.

[0130] In a variant of this approach, before parsing overlapping pairs in the first data structure, the system performs the following operations: The system transforms the wildcard value of the first business attribute into a set of elements having all possible values ​​of the first business attribute, and indicates the expansion level associated with the transformed wildcard value in the first business attribute. The expansion level is based on at least one of the following: a list derived from exact values; a list derived from a range of values; and a list derived from wildcard values.

[0131] In another variant, the system parses overlapping pairs in the first data structure by identifying three sets: two sets of non-overlapping business attributes and associated permitted destination roles; and a set comprising cross-policy elements derived from the union of a first set of permitted destination roles corresponding to the first business attribute and a second set of permitted destination roles corresponding to the second business attribute. In each of the three identified sets, the system indicates an extension level associated with at least one of the corresponding non-overlapping business attribute, the first business attribute, and the second business attribute. The system then replaces the overlapping pairs with the three identified sets to obtain the second data structure.

[0132] In another variant, the corresponding service attribute is associated with a user-configured sequence number. The system assigns a third sequence number to the cross-policy element, which is the lower of the first user-configured sequence number associated with the first service attribute and the second user-configured sequence number associated with the second service attribute.

[0133] In another variant, the system assigns sequence numbers to corresponding policy elements or business attributes in the second combination strategy based on the indicated extension level. Compared to a second policy element with a higher extension level and a higher sequence number, a first policy element with a lower extension level and a lower sequence number indicates a more specific policy, and the higher sequence number indicates a lower matching priority in the second combination strategy for the source role.

[0134] In another variant, the system detects overlapping pairs based on at least one of the following: wildcards used in the first business attribute or the second business attribute; a range of values ​​used in the first business attribute or the second business attribute; complete overlap, wherein the first business attribute is contained in the second business attribute; and partial overlap, wherein a portion of the first business attribute matches a portion of the second business attribute.

[0135] In another variant, after removing the third business attribute from the second data structure, the system removes the corresponding third set of permitted destination roles from the second data structure. In response to determining that the fourth and fifth business attributes in the second data structure are identical or consecutive, the system merges the fourth and fifth business attributes into a new business attribute, which corresponds to the union of the fourth set of permitted destination roles corresponding to the fourth business attribute and the fifth set of permitted destination roles corresponding to the fifth business attribute.

[0136] In another variant, the entries in the first data structure also indicate a corresponding set of disallowed destination roles for the respective source role and business attribute. The system determines a mismatch between the third business attribute and the policy based on this corresponding set of disallowed destination roles.

[0137] In another variant, service attributes include multiple attributes associated with at least one of the following: network protocol; port number; information related to switch configuration; and characteristics of network services.

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

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

[0140] In another variation, before representing the policies as a matrix, the method further includes the system performing the following operations: The system represents a first set of user-configured policies as an initial matrix, wherein the first entry in the initial matrix corresponds to the source role as rows and the destination role as columns, and indicates the business attributes and actions of at least one policy entry. The system transposes the initial matrix to obtain a matrix, wherein the first entry in the initial matrix indicates the same information as the first entry in the matrix.

[0141] 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 (compressed discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or hereafter developed.

[0142] The methods and processes described in the detailed description section may be embodied in code and / or data, which may be stored in 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 methods and processes embodied in data structures and code and stored within the computer-readable storage medium.

[0143] Furthermore, the methods and processes described above may be included in a hardware device or apparatus. For example, the hardware device or apparatus may include, but is not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), dedicated or shared processors that execute specific software programs or code at specific times, and other programmable logic devices now known or developed later. When the hardware device or apparatus is activated, the hardware module executes the methods and processes included therein.

[0144] The foregoing descriptions of the aspects are presented for illustrative and descriptive purposes only. They are not intended to be exhaustive or to limit the aspects described herein to the disclosed forms. Therefore, many modifications and variations will be apparent to those skilled in the art. Furthermore, the foregoing disclosure is not intended to limit the aspects described herein. The scope of the aspects described herein is defined by the appended claims.

Claims

1. A method of policy synthesis, comprising: determining a first set of policies defined for a switch in handling packets, wherein a policy comprises at least one policy entry based on a destination role, and wherein the at least one policy entry comprises a source role, traffic attributes, and an action to be taken for the packet; receiving an incoming packet at the switch, wherein a destination of the incoming packet is unknown; representing the first set of policies as a matrix, wherein a first entry in the matrix corresponds to the source role as a row and the destination role as a column, and the first entry in the matrix indicates the traffic attributes and the action of the at least one policy entry; in the first entry, replacing the action with the destination role if the action indicates to allow the packet, and replacing the action with a null value if the action indicates to reject the packet, to obtain a first data structure having entries indicating a plurality of traffic attributes for respective source roles and a corresponding set of allowed destination roles for respective traffic attributes; resolving overlapping pairs comprising a first traffic attribute and a second traffic attribute to obtain a second data structure; determining that a third traffic attribute for a source role and a corresponding set of allowed destination roles in the second data structure do not match a policy; removing the third traffic attribute and the corresponding set of allowed destination roles from the second data structure to obtain a second synthesized policy, wherein a first decision model based on the first set of policies produces a same result as a second decision model based on the second synthesized policy; using the second decision model to allow or reject the incoming packet to be forwarded at the switch; in response to allowing, forwarding the incoming packet to a local host; and in response to rejecting, discarding the incoming packet.

2. The method of claim 1, wherein prior to resolving the overlapping pairs in the first data structure, the method further comprises: converting a wildcard value for the first traffic attribute to a set of elements having all possible values for the first traffic attribute; and indicating an expansion level associated with the converted wildcard value in the first traffic attribute, wherein the expansion level is based on at least one of: a list derived based on exact values; a list derived based on ranges of values; and a list derived based on wildcard values.

3. The method of claim 2, wherein resolving the overlapping pairs in the first data structure comprises: identifying three sets, the three sets comprising: two sets of non-overlapping traffic attributes and associated allowed destination roles; and one set comprising cross-policy elements derived based on a union of a first set of allowed destination roles corresponding to the first traffic attribute and a second set of allowed destination roles corresponding to the second traffic attribute; indicating an expansion level associated with at least one of a respective non-overlapping traffic attribute, the first traffic attribute, and the second traffic attribute in each of the identified three sets; and replacing the intersecting pair with the identified three sets to obtain the second data structure.

4. The method of claim 3, wherein respective service attributes are associated with user configuration sequence numbers, and wherein the method further comprises: assigning a third sequence number to the cross policy element, the third sequence number comprising a lower one of a first user configuration sequence number associated with the first service attribute and a second user configuration sequence number associated with the second service attribute.

5. The method of claim 4, further comprising: based on the indicated expansion level, assigning sequence numbers to respective policy elements or service attributes in the second composed policy, wherein a first policy element having a lower expansion level and a lower sequence number indicates a more specific policy than a second policy element having a higher expansion level and a higher sequence number, and wherein the higher sequence number indicates a lower matching precedence in the second composed policy for the source role.

6. The method of claim 1, further comprising: detecting the intersecting pair based on at least one of: wildcards used in the first service attribute or the second service attribute; ranges of values used in the first service attribute or the second service attribute; full intersection, wherein the first service attribute is contained in the second service attribute; and partial intersection, wherein a portion of the first service attribute matches a portion of the second service attribute.

7. The method of claim 1, wherein after removing the third service attribute from the second data structure, the method further comprises: removing a corresponding third set of allowed destination roles from the second data structure; and in response to determining that a fourth service attribute and a fifth service attribute in the second data structure are identical or consecutive to each other: merging the fourth service attribute and the fifth service attribute into a new service attribute corresponding to a union of a fourth set of allowed destination roles corresponding to the fourth service attribute and a fifth set of allowed destination roles corresponding to the fifth service attribute.

8. The method of claim 1, wherein the entries in the first data structure further indicate a corresponding set of disallowed destination roles for respective source roles and respective service attributes, and wherein determining that the third service attribute does not match the policy is based on the corresponding set of disallowed destination roles.

9. The method of claim 1, wherein a service attribute comprises a plurality of attributes associated with at least one of: a network protocol; a port number; information associated with a configuration of the switch; and a characteristic of network traffic.

10. The method of claim 1, wherein the first decision model takes as input a source role, a destination role, and a service attribute for the incoming packet, and returns as output an action for the incoming packet, and wherein the second decision model takes as input a source role, a destination role, and a service attribute for the incoming packet, and returns as output a sequence number for the incoming packet. wherein the second decision model takes as input a policy sequence number, the source role, and the traffic attribute for the incoming packet and returns as output a set of allowed destination roles.

11. The method of claim 1, wherein the policies in the first set of policies comprise at least one of: a user-configured policy; and a group-based policy.

12. The method of claim 1, wherein prior to representing the policies as the matrix, the method further comprises: representing the first set of policies as an initial matrix, wherein a first entry in the initial matrix corresponds to the source role as a row and the destination role as a column, and the first entry in the initial matrix indicates the traffic attribute and the action of the at least one policy entry; and transposing the initial matrix to obtain the matrix, wherein the first entry in the initial matrix indicates the same information as the first entry in the matrix.

13. A computer system comprising: a processor; and a memory coupled to the processor and storing instructions which, when executed by the processor, cause the processor to perform a method comprising: determining a first set of policies defined for a switch in handling packets, wherein a policy comprises at least one policy entry based on a destination 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; representing the first set of policies as a matrix, wherein a first entry in the matrix corresponds to the source role as a row and the destination role as a column, and the first entry in the matrix indicates the traffic attribute and the action of the at least one policy entry; in the first entry, if the action indicates to allow the packet, replacing the action with the destination role, and if the action indicates to reject the packet, replacing the action with a null value, to obtain a first data structure having entries indicating a plurality of traffic attributes for respective source roles and a corresponding set of allowed destination roles for respective traffic attributes; resolving overlapping pairs comprising a first traffic attribute and a second traffic attribute to obtain a second data structure; determining that a third traffic attribute for a source role and a corresponding set of allowed destination roles in the second data structure do not match a policy; and removing the third traffic attribute and the corresponding set of allowed destination roles from the second data structure to obtain a second set of composed policies, wherein a first decision model based on the first set of policies produces the same result as a second decision model based on the second set of composed policies.

14. The computer system of claim 13, wherein prior to resolving the overlapping pairs in the first data structure, the method further comprises: converting a wildcard value for the first traffic attribute to a set of elements having all possible values for the first traffic attribute; and indicating in the first traffic attribute an extension level associated with the converted wildcard value, ​ wherein the expansion level is based on at least one of: a list derived based on exact values; a list derived based on ranges of values; and a list derived based on wildcard values.

15. The computer system of claim 14, wherein resolving the overlap pair in the first data structure comprises: identifying three sets, the three sets comprising: two sets of non-overlapping traffic attributes and associated allowed destination roles; and one set comprising a cross-policy element derived based on a union of a first set of allowed destination roles corresponding to the first traffic attribute and a second set of allowed destination roles corresponding to the second traffic attribute; indicating, in each of the identified three sets, an expansion level associated with at least one of a respective non-overlapping traffic attribute, the first traffic attribute, and the second traffic attribute; and replacing the overlap pair with the identified three sets to obtain the second data structure.

16. The computer system of claim 13, wherein the method further comprises: detecting the overlap pair based on at least one of: a wildcard used in the first traffic attribute or the second traffic attribute; a range of values used in the first traffic attribute or the second traffic attribute; a full overlap, wherein the first traffic attribute is contained in the second traffic attribute; and a partial overlap, wherein a portion of the first traffic attribute matches a portion of the second traffic attribute.

17. The computer system of claim 13, wherein after removing the third traffic attribute from the second data structure, the method further comprises: removing a corresponding third set of allowed destination roles from the second data structure; and in response to determining that a fourth traffic attribute and a fifth traffic attribute in the second data structure are identical or consecutive to each other: merging the fourth traffic attribute and the fifth traffic attribute into a new traffic attribute corresponding to a union of a fourth set of allowed destination roles corresponding to the fourth traffic attribute and a fifth set of allowed destination roles corresponding to the fifth traffic attribute.

18. The computer system of claim 13, wherein the first decision model takes as input a source role, a destination role, and a traffic attribute for an incoming packet and returns as output an action for the incoming packet, and wherein the second decision model takes as input a policy sequence number, the source role, and the traffic attribute for the incoming packet and returns as output a set of allowed destination roles.

19. A non-transitory computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform a method comprising: determining a first set of policies defined for a switch in handling a packet, wherein a policy comprises at least one policy entry based on a destination role, and wherein the at least one policy entry comprises a source role, a traffic attribute, and an action to take for the packet; ​ representing the first set of policies as a matrix, wherein a first entry in the matrix corresponds to the source role as a row and the destination role as a column, and the first entry in the matrix indicates the traffic attribute and the action of the at least one policy entry; in the first entry, replacing the action with the destination role if the action indicates to allow the packet, and replacing the action with a null value if the action indicates to reject the packet, to obtain a first data structure having entries indicating a plurality of traffic attributes for respective source roles and a corresponding set of allowed destination roles for respective traffic attributes; parsing an overlapping pair comprising a first traffic attribute and a second traffic attribute to obtain a second data structure; determining that a third traffic attribute of a source role and a corresponding set of allowed destination roles in the second data structure do not match a policy; removing the third traffic attribute and the corresponding set of allowed destination roles from the second data structure to obtain a second combined policy, wherein a first decision model based on the first set of policies produces a same result as a second decision model based on the second combined policy; and using the second decision model to allow or reject an incoming packet to be forwarded at the switch; wherein allowing causes the switch to forward the incoming packet to a local host; and wherein rejecting causes the switch to drop the incoming packet.

20. The non-transitory computer-readable storage medium of claim 19, wherein the method further comprises: detecting the overlapping pair based on at least one of: a wildcard used in the first traffic attribute or the second traffic attribute; a range of values used in the first traffic attribute or the second traffic attribute; a full overlap, wherein the first traffic attribute is contained in the second traffic attribute; and a partial overlap, wherein a portion of the first traffic attribute matches a portion of the second traffic attribute. ​

Images