Collecting and processing contextual attributes on the host

Abstract

This disclosure relates to collecting and processing contextual attributes on a host. The disclosure provides an architecture for capturing contextual attributes on a host computer executing one or more machines, and for consuming the captured contextual attributes to perform services on the host computer. Some embodiments execute a guest introspection (GI) agent on each machine, from which contextual attributes are captured. In addition to executing one or more machines on each host computer, these embodiments also execute a contextual engine and one or more attribute-based service engines on each host computer. Through the GI agent of a machine on a host, the contextual engine of that host collects contextual attributes associated with network events and / or processing events on the machine in some embodiments. The contextual engine then provides the contextual attributes to the service engines, which in turn use the contextual attributes to identify service rules for processing.

Description

[0001] This application is a divisional application of the invention patent application filed on December 10, 2017, with application number 201780084597.4 and title "Collecting and Processing Contextual Attributes on a Host". Technical Field

[0002] This invention generally relates to computer networks, and more specifically to techniques for collecting and processing contextual attributes on a host. Background Technology

[0003] Historically, middlebox services have been hardware appliances implemented at one or more points in the network topology of an enterprise or data center. With the advent of Software-Defined Networking (SDN) and network virtualization, traditional hardware appliances cannot take advantage of the flexibility and control offered by SDN and network virtualization. Consequently, in recent years, various methods for providing middlebox services on hosts have been proposed. However, most of these middlebox solutions do not utilize the rich contextual data that can be captured for every data message flow on the host. One reason for this is that existing technologies do not provide an efficient distributed scheme for filtering thousands of captured contextual attributes to efficiently process service rules defined based on a smaller set of contextual attributes. Summary of the Invention

[0004] Some embodiments of the present invention provide a novel architecture for capturing context attributes on a host computer executing one or more machines, and for consuming the captured context attributes to perform services on the host computer. In some embodiments, the machine is a virtual machine (VM), in other embodiments it is a container, or in other embodiments it is a hybrid of VMs and containers.

[0005] Some embodiments execute a client introspection (GI) agent on each machine, from which contextual attributes need to be captured. In addition to executing one or more machines on each host computer, these embodiments also execute a context engine and one or more attribute-based service engines on each host computer. Through the GI agent on the machine, in some embodiments, the context engine on that host collects contextual attributes associated with network events and / or processing events on the machine. As further described below, the context engine then provides the contextual attributes to the service engine, which in turn uses these contextual attributes to identify service rules that specify the context-based services to be performed on the processing performed on the machine and / or data message streams sent by or received by the machine.

[0006] In some embodiments, the host's context engine collects context attributes from the machine's GI agent on that host in various ways. For example, in some embodiments, the GI agent on the machine registers hooks (e.g., callbacks) with one or more modules in the machine's operating system (e.g., kernel space modules or user space modules) for all new network connection events and all new processing events.

[0007] Upon the occurrence of a new network connection event, the GI agent receives a callback from the OS and provides a network event identifier to the context engine based on this callback. The network event identifier provides a set of attributes related to the network event. In some embodiments, these network event attributes include a 5-tuple identifier for the requested network connection (i.e., source port and IP address, destination port and IP address, and protocol), a process identifier for the process requesting the network connection, a user identifier associated with the process that issued the request, and a group identifier (e.g., an Active Directory (AD) identifier) ​​associated with the process that issued the request.

[0008] In some embodiments, the context engine instructs the GI agent to collect additional processing parameters from the OS module associated with the processing identifier (ID) received with the network event. In some embodiments, these additional processing parameters include the processing name, processing hash, processing path with command-line arguments, processing network connection, the module loaded by the processing, and one or more processing consumption parameters specifying the processing's consumption of one or more machine resources (e.g., CPU consumption, network consumption, and memory consumption). Instead of using the processing identifier to query the GI agent for additional processing parameters associated with the network event, in other embodiments, the context engine receives all processing parameters associated with the network event at once when the GI agent reports the network event to the context engine.

[0009] In some embodiments, the OS on the machine holds new network events (i.e., does not begin sending data messages for network events) until the GI agent on the machine instructs it to continue processing the network events. In some of these embodiments, the GI agent only allows the OS to continue processing network events after the context engine has collected all the necessary attributes for the event (e.g., after receiving a message from the context engine specifying that it has received all the necessary processing or network attributes for the new network event).

[0010] In some embodiments, the context engine uses the processing hash received from the GI agent to identify the name and version of the application (i.e., software product) to which the processing belongs. To this end, in some embodiments, the context engine stores the processing hash and the associated application name / version, compares the processing hash received from the GI agent with the stored processing hash to identify matching hashes, and then uses the application name / version of the matching hash as the application name and version of the processing associated with the event.

[0011] In some embodiments, the context engine obtains the processing hash and application name / version from one or more network or compute managers, which may operate on another device or computer. In other embodiments, the context engine provides a hash associated with a processing identifier to the network or compute manager, which then matches this hash with its processing hash record and provides the application name / version of the associated processing to the context engine. Once the context engine obtains the application name / version associated with the network event, it can provide the name and version attributes to attribute-based service engines, which can use this information (i.e., application name and / or version) to identify service rules to be enforced.

[0012] After a processing event occurs, the GI agent receives a callback from the OS and provides a processing event identifier to the context engine based on this callback. The processing event identifier provides a set of attributes related to the processing event. In some embodiments, this set of attributes includes the processing identifier. In some embodiments, this set also includes a user identifier and / or a group identifier (e.g., an Active Directory (AD) identifier).

[0013] In some embodiments, the GI agent provides the context engine with all processing parameters associated with the processing event (e.g., processing identifier, user ID, group ID, processing name, processing hash, loaded module identifier, consumption parameters, etc.) when reporting a processing event to the context engine. In other embodiments, the context engine instructs the GI agent to collect additional processing parameters associated with the processing identifier received by the context engine with the processing event from the OS module. In some embodiments, these additional processing parameters are the same as those mentioned above for reported network events (e.g., processing name, processing hash, loaded module identifier, consumption parameters, etc.).

[0014] In some embodiments, the context engine enhances the context attributes it receives from the GI agent by utilizing context attributes it receives from other modules executing on the host. For example, in some embodiments, a Deep Packet Inspection (DPI) module executes on the host. The context engine or another module (e.g., a firewall engine) instructs this DPI engine to examine data messages in a data message stream associated with a processing ID to identify the type of traffic sent in those data messages by the application associated with that processing ID.

[0015] The identified traffic type identity is commonly referred to today as an AppID. Furthermore, multiple DPI modules currently analyze data message streams to generate AppIDs. In some embodiments, the context engine combines the AppID obtained for a network event with other contextual attributes identified for that event (e.g., associating the AppID with collected contextual attributes using the event's 5-tuple identifier) ​​to produce a very rich set of attributes that the service engine can use to execute its services. This rich set of attributes provides the true application identity (i.e., application name, application version, application traffic type, etc.), upon which the service engine can execute its services.

[0016] Furthermore, in some embodiments, the threat detection module executes on the host computer along with the context engine. Once the context engine obtains a set of processing parameters indicating that a specified process has been initiated or is sending data messages on the machine, in some embodiments, the context engine provides the threat detection module with one or more processing parameters (e.g., processing hash, application name, application version, AppID, other processing parameters, etc.). The threat detection module then generates a threat level indicator (e.g., low, medium, high) for the identified process and provides this threat level indicator to the context engine. The context engine then provides this threat level indicator to one or more service engines as another contextual attribute for performing services on data messages related to new processing events or new network events; the service engines can use the threat level indicator as another attribute to identify service rules to be enforced.

[0017] In some embodiments, the context engine uses a push model to distribute collected context attributes to service engines, while in other embodiments it uses a pull model. In still other embodiments, the content engine uses a push model for some service engines and a pull model for others. In the push model, the context engine distributes to service engines the context attributes it has collected for processing events or network events, which have a processing identifier and / or a flow identifier for the network event (e.g., a 5-tuple identifier for the flow). In some embodiments, the context engine only distributes context attributes related to the service rules of that service engine to the service engine.

[0018] In the pull model, the context engine receives queries from the service engine for context attributes that the context engine has collected for a specific process or network connection. In some embodiments, the context engine uses the query from the service engine to receive a process ID or flow identifier (e.g., a 5-tuple identifier) ​​and uses the received identifier to identify the set of attributes it must provide to the service engine. In some embodiments, the context engine generates a service token (also called a service tag) for the set of attributes associated with the service engine and provides this service token to another module (e.g., a GI agent or another module on the host) to pass to the service engine (e.g., in the encapsulation header of a data message). The service engine then extracts the service token and provides it to the context engine to identify the context attributes that the context engine must provide to the service engine.

[0019] In some embodiments, the context engine provides context attributes to several context-based service engines on its host computer. In some embodiments, both the context engine and the service engine are kernel-space components of the hypervisor, on which multiple VMs or containers execute. In other embodiments, the context engine and / or one or more service engines are user-space processes. For example, in some embodiments, one or more service engines are service VMs (SVMs).

[0020] Different embodiments use different types of context-based service engines. For example, in some embodiments, the attribute-based service engine includes (1) a firewall engine that performs context-based firewall operations on data messages sent by or received by the machine, (2) a processing control engine that enforces context-based processing control operations (e.g., processing evaluation and termination operations) on processing initiated on the machine, (3) a load balancing engine that performs context-based load balancing operations to distribute data message streams from the machine to different destinations or service nodes in one or more destination / service node clusters, and (4) an encryption engine that performs context-based encryption or decryption operations to encrypt data messages from the machine or decrypt data messages received by the machine.

[0021] In some embodiments, another context-based service engine is a discovery service engine. In some embodiments, the discovery engine captures new processing events and new network events from the context engine, along with context attributes collected by the context engine for these processing and network events. The discovery service engine then relays these events and their associated context attributes to one or more network managers (e.g., servers) that provide a management layer that allows network administrators to visualize events in the data center and specify policies for computing and network resources in the data center.

[0022] When relaying these events and attributes to the network management layer, the discovery module in some embodiments performs some form of preprocessing on these events and attributes. For example, in some embodiments, the discovery module filters some of these network or processing events while aggregating some or all of these events and their attributes. Furthermore, in some embodiments, the discovery engine instructs the context engine to collect additional contextual attributes for processing or network events through a GI agent or other modules (e.g., a DPI engine or a threat detection engine), or to capture other types of events (such as file events and system events).

[0023] For example, in some embodiments, the discovery engine instructs the context engine to build an inventory of applications installed on the machine and refresh that inventory periodically. The discovery engine may instruct the context engine based on requests from the management plane or based on operational configurations specified for the discovery engine by the management or control plane. In response to requests from the discovery engine, in some embodiments, the context engine causes each GI agent on each host's machine to discover all installed processes and all running processes and services on the machine.

[0024] After building an inventory of installed applications and running processes / services, the host computer discovery engine in the data center provides this information to the network / compute manager in the management plane. In some embodiments, the management plane collects context attributes from sources other than the host computer discovery and context engine. For example, in some embodiments, the management plane collects compute context (e.g., cloud context from a cloud provider, or compute virtualization context via data center virtualization software) from one or more servers, identity context from a directory service server, mobility context from a mobility management server, endpoint context from DNS (Domain Name Server) and application inventory servers, network context from a network virtualization server (e.g., virtual network context), etc.

[0025] By collecting contextual information (e.g., information from the discovery and context engines and / or from other context sources), the management plane can provide a user interface to network / compute administrators to visualize compute and network resources in the data center. Furthermore, the collected contextual attributes allow the management plane to provide control through this user interface, enabling administrators to specify context-based service rules and / or policies. These service rules / policies are then distributed to host computers, allowing service engines on those computers to perform context-based service operations.

[0026] The foregoing summary is intended as a brief introduction to some embodiments of the invention. It is not intended to be a description or overview of all inventive subjects disclosed in this document. The following detailed description and the accompanying drawings mentioned in the detailed description will further describe the embodiments described in the summary, as well as other embodiments. Therefore, a thorough review of the summary, detailed description, drawings, and claims is necessary to understand all the embodiments described in this document. Furthermore, the claimed subject matter is not limited to the illustrative details in the summary, detailed description, and drawings. Attached Figure Description

[0027] The novel features of the present invention are set forth in the appended claims. However, for illustrative purposes, several embodiments of the invention are illustrated in the following figures.

[0028] Figure 1 The illustration shows a host computer using a context engine and a context-based service engine according to some embodiments of the present invention.

[0029] Figure 2 A more detailed example of a host computer is illustrated. In some embodiments, the host computer is used to establish a distributed architecture for configuring and executing context-rich, attribute-based services in a data center.

[0030] Figure 3 The illustration shows the processing performed by the context engine of some embodiments.

[0031] Figure 4 Examples of load balancing rules for some implementations are illustrated.

[0032] Figure 5 The illustrations show load balancers that distribute web server traffic among several application servers, representing some embodiments.

[0033] Figure 6 The illustration shows the processes performed by the load balancer in some embodiments.

[0034] Figure 7 Several examples of such firewall rules are illustrated.

[0035] Figure 8 Several more detailed examples of context-based firewall rules from some embodiments are illustrated.

[0036] Figure 9-12 Various examples are presented, illustrating how firewall engines enforce various context-based firewall rules.

[0037] Figure 13 The diagram illustrates the process the context engine performs to collect user and group identifiers whenever a new network connection event is received from the GI agent.

[0038] Figure 14 The illustration shows the processing performed by the firewall engine in some embodiments.

[0039] Figure 15 An example of this context-based encryption rule is illustrated.

[0040] Figure 16 The illustrations show some embodiments of an encryptor performing processing to encrypt data messages sent by a VM on a host.

[0041] Figure 17 The diagram illustrates the process by which the encryption engine performs the decryption of encrypted data messages received on the destination host of the destination VM at the forwarding element port.

[0042] Figure 18 The diagram illustrates the process performed by the encryption engine to decrypt an encrypted data message, including the key identifier in its header.

[0043] Figure 19 Several examples of processing control rules are illustrated.

[0044] Figure 20 The illustration shows the processes performed by the control engine in some embodiments.

[0045] Figure 21 The illustration shows an example of how the service engine is managed in some embodiments.

[0046] Figure 22 A computer system for implementing some embodiments of the present invention is conceptually illustrated. Detailed Implementation

[0047] In the following detailed description of the invention, numerous details, examples, and embodiments of the invention are set forth and described. However, it will be clear and apparent to those skilled in the art that the invention is not limited to the described embodiments, and that the invention can be practiced without some of the specific details and examples discussed.

[0048] Some embodiments of the present invention provide a novel architecture for capturing context attributes on a host computer executing one or more machines, and for consuming the captured context attributes to perform services on the host computer. Some embodiments execute a client introspection (GI) agent on each machine from which context attributes need to be captured. In addition to executing one or more machines on each host computer, these embodiments also execute a context engine and one or more attribute-based service engines on each host computer. Through the GI agent of a machine on a host, in some embodiments, the context engine of that host collects context attributes associated with network events and / or processing events on the machine. The context engine then provides the context attributes to the service engine, which in turn uses these context attributes to identify service rules that specify context-based services to be performed on the processing executed on the machine and / or data message streams sent by or received by the machine.

[0049] As used in this document, a data message refers to a set of bits in a specific format that is transmitted across a network. Those skilled in the art will recognize that the term "data message" can be used herein to refer to various formatted sets of bits that can be transmitted across a network, such as Ethernet frames, IP packets, TCP fragments, UDP datagrams, etc. Furthermore, as used in this document, references to L2, L3, L4, and L7 layers (or layers 2, 3, 4, and 7) refer to the second data link layer, third network layer, fourth transport layer, and seventh application layer of the OSI (Open Systems Interconnection) layer model, respectively.

[0050] Figure 1 The illustration shows a host computer 100 using a context engine and a context-based service engine according to some embodiments of the present invention. As shown, the host computer 100 includes several data computing nodes 105, a context engine 110, several context-based service engines 130, a threat detector 132, and a deep packet inspection (DPI) module 135. The context-based service engines include a discovery engine 120, a processing control engine 122, an encryption engine 124, a load balancer 126, and a firewall engine 128. It also includes a context-based service rule storage device 140 and an attribute storage device 145.

[0051] A DCN is an endpoint machine that runs on host computer 100. In some embodiments, a DCN is a virtual machine (VM), in other embodiments it is a container, or in other embodiments it is a hybrid of VMs and containers. On each DCN, a GI agent 150 executes to collect context attributes from the context engine 110. In some embodiments, the context engine 110 collects context attributes from the GI agent 150 of the DCN on its host in various ways. For example, in some embodiments, the GI agent on the DCN registers hooks (e.g., callbacks) with one or more modules in the DCN's operating system (e.g., kernel space modules or user space modules) for all new network connection events and all new processing events.

[0052] Upon the occurrence of a new network connection event, GI agent 150 receives a callback from its DCN's OS and, based on this callback, provides a network event identifier to context engine 110. The network event identifier provides a set of attributes associated with the network event. In some embodiments, these network event attributes include a 5-tuple identifier for the requested network connection (i.e., source port and IP address, destination port and IP address, and protocol), a process identifier for the process requesting the network connection, a user identifier associated with the process that issued the request, and a group identifier (e.g., Active Directory (AD) identifier) ​​associated with the process that issued the request.

[0053] In some embodiments, the context engine instructs GI agent 150 to collect additional processing parameters from the OS module associated with a processing identifier (ID) received with a network event. In some embodiments, these additional processing parameters include a processing name, a processing hash, a processing path with command-line arguments, a processing network connection, a module loaded by the processing, and one or more processing consumption parameters specifying the processing's consumption of one or more machine resources (e.g., CPU consumption, network consumption, and memory consumption). Instead of using the processing identifier to query GI agent 150 for additional processing parameters associated with a network event, in other embodiments, the context engine 110 receives all processing parameters associated with a network event at once when the GI agent reports a network event to the context engine.

[0054] In some embodiments, the OS of the DCN holds new network events (i.e., does not begin sending data messages for network events) until the GI agent 150 on that DCN instructs it to continue processing the network event. In some of these embodiments, the GI agent 150 only allows the OS to continue processing the network event after the context engine 110 has collected all the necessary attributes for the event (e.g., after receiving a message from the context engine specifying that it has received all the processing or network attributes it needs for the new network event).

[0055] In some embodiments, the context engine 110 uses the processing hash it receives from the GI agent 150 to identify the name and version of the application (i.e., software product) to which the processing belongs. To this end, in some embodiments, the context engine 110 stores the processing hash and the associated application name / version, compares the processing hash it receives from the GI agent with the stored processing hash to identify matching hashes, and then uses the application name / version of the matching hash as the application name and version of the processing associated with the event.

[0056] In some embodiments, the context engine 110 obtains a processing hash and application name / version from one or more network or compute managers, which may operate on another device or computer. In other embodiments, the context engine provides a hash associated with a processing identifier to the network or compute manager, which then matches this hash with its processing hash record and provides the context engine with the application name / version of the associated processing. Once the context engine 110 obtains the application name / version associated with a network event, it can provide the name and version attributes to attribute-based service engines, which can use this information (i.e., application name and / or version) to identify service rules to be enforced.

[0057] After a processing event occurs on DCN 105, in some embodiments, DCN's GI agent 150 receives a callback from DCN's OS and provides a processing event identifier to context engine 110 based on this callback. The processing event identifier provides a set of attributes related to the processing event. In some embodiments, this set of attributes includes a processing identifier. In some embodiments, this set also includes a user identifier and / or a group identifier (e.g., an Active Directory (AD) identifier).

[0058] In some embodiments, the GI agent provides the context engine with all processing parameters associated with the processing event (e.g., processing identifier, user ID, group ID, processing name, processing hash, loaded module identifier, consumption parameters, etc.) when reporting a processing event to the context engine. In other embodiments, the context engine instructs the GI agent to collect additional processing parameters associated with the processing identifier received by the context engine with the processing event from the OS module. In some embodiments, these additional processing parameters are the same as those mentioned above for reported network events (e.g., processing name, processing hash, loaded module identifier, consumption parameters, etc.).

[0059] In some embodiments, the context engine 110 utilizes context attributes it receives from other modules executing on the host to enhance the context attributes it receives from the GI agent 150. The DPI module 135 (also known as a deep packet detector) and the threat detector 132 (also known as a threat inspection module) are two such modules that provide context attributes to enhance those collected by the context engine from the GI agent 150. In some embodiments, the DPI module is guided by the context engine 110 or another module (e.g., firewall engine 128) to examine data messages in the data message stream associated with the processing ID to identify the type of traffic sent in this data by the application associated with the processing ID.

[0060] The identified traffic type identity is now commonly referred to as AppID. Furthermore, multiple DPI modules exist that analyze messages in a data message stream to generate its AppID. In some embodiments, the context engine combines the AppID obtained for a network event with other context attributes identified for that event to produce a very rich set of attributes that the service engine can then use to execute its services. This rich set of attributes provides the true application identity (i.e., application name, application version, application traffic type, etc.) upon which the service engine can execute its services. In some embodiments, the context engine 110 uses the 5-tuple identifier of the network event to associate the AppID of the data message stream for that event with context attributes collected by the context engine from the GI proxy of the DCN associated with the data message stream (e.g., the DCN from which the data message stream originates).

[0061] Threat detector 132 provides a threat level indicator that specifies the threat level associated with a particular application running on the DCN. Once the context engine obtains a set of processing parameters indicating that a specified process has been initiated on the machine or is sending data messages on the machine, in some embodiments, the context engine provides one or more processing parameters (e.g., processing hash, application name, application version, AppID, other processing parameters, etc.) to the threat detection module.

[0062] The threat detection module then generates a threat level indicator (e.g., low, medium, high) for the identified processes and provides this threat level indicator to the context engine. In some embodiments, the threat detector assigns a threat score to the application running on the DCN based on various application behavior factors, such as (1) whether it performs poor input validation, (2) whether it transmits authentication credentials over an unencrypted network link, (3) whether it uses weak passwords and account policies, (4) whether it stores configuration secrets in plaintext, (5) whether it can transfer files, (6) whether it knows that the application is spreading malware, (7) whether the application deliberately evades detection, (8) whether the application has known vulnerabilities, etc. In some embodiments, the threat detector is a third-party whitelisted application, such as Bit9.

[0063] In some embodiments, the context engine provides a threat level indicator generated by the threat detector 132 to one or more service engines as another context attribute for performing services on data messages of new processing events or new network events; the service engine may use the threat level indicator as another attribute to identify service rules to be enforced.

[0064] Context engine 110 stores context attributes it collects for network events and processing events in attribute storage device 145. In some embodiments, the context engine stores each set of context attributes together with one or more network event identifiers and / or processing identifiers. For example, in some embodiments, context engine 110 stores the collected context attributes for new processing events that have a processing identifier or a reference to that identifier. The context engine then uses the processing identifier to provide the collected context attributes to a service engine (e.g., processing control engine 122) that performs the service for the processing event.

[0065] In some embodiments, the context engine stores collected context attributes for a 5-tuple identifier of a network connection event or a new network connection event having a reference to that 5-tuple identifier. In some of these embodiments, the context engine provides the service engine with context attributes for a network event and the 5-tuple identifier of that event. The data message for that network event will use this 5-tuple identifier, so the service engine can use the provided 5-tuple identifier to identify the context attributes associated with the data message stream.

[0066] In some embodiments, the context engine uses a push model to distribute collected context attributes to service engine 130, while in other embodiments, the engine uses a pull model to distribute these attributes to service engine 130. In still other embodiments, the content engine uses a push model for some service engines and a pull model for others. In the push model, the context engine distributes to the service engines the context attributes it has collected for processing events or network events, as well as the identifier of the processing event and / or the stream identifier of the network event (e.g., a stream 5-tuple identifier).

[0067] In some embodiments, the context engine distributes context attributes only to the service engine that are relevant to the service rules of that service engine. In other words, in these embodiments, the context engine compares each collected attribute from the collected attribute set (e.g., for network events or processing events) with the list of attributes used by the service engine's service rules and discards each collected attribute that is not used by the service rules. The context engine then provides the service engine only with a subset of the collected attributes (within the collected attribute set) that are being used by the engine's service rules. In other embodiments, the service engine performs this filtering operation to discard unwanted context attributes.

[0068] In the pull model, the context engine receives queries from the service engine for context attributes that the context engine has collected for a specific process or network connection. In some embodiments, the context engine uses the query from the service engine to receive a process ID or stream identifier (e.g., a 5-tuple identifier) ​​and uses the received identifier to identify the set of attributes it must provide to the service engine.

[0069] In some embodiments, the context engine generates a service token (also called a service tag) for a set of attributes associated with the service engine and provides this service token to another module (e.g., a GI proxy or another module on the host) to pass to the service engine (e.g., in the encapsulation header of a data message). The service engine then extracts the service token and provides it to the context engine to identify the context attributes that the context engine must provide to the service engine.

[0070] In some embodiments, the context engine 110 and the service engine 130 are both kernel space components of the hypervisor, on which multiple VMs or containers run, as shown in the following references. Figure 2Further described. In other embodiments, the context engine and / or one or more service engines are user-space processing. For example, in some embodiments, one or more service engines are service VMs (SVMs). In some embodiments, one or more service engines reside in the ingress and / or egress data paths of the DCN to receive access to data message streams going to and from the DCN, and to perform services on these data message streams. In other embodiments, one or more other modules on host 100 intercept data messages from the ingress / egress data paths and forward these messages to one or more service engines so that these engines perform services on the data messages. Reference will be made below. Figure 2 Describe one such method.

[0071] Different implementations use different types of context-based service engines. Figure 1 In the example shown, service engine 130 includes discovery engine 120, processing control engine 122, encryption engine 124, load balancer 126, and firewall engine 128. Each of these service engines 130 has an attribute-based service rule storage device. Figure 1 The collective representation represents all context-based service rule storage devices of these service engines having context-based service rule storage devices 140, in order to simplify the illustration presented in this diagram.

[0072] In some embodiments, each service rule in the context-based service rule store 140 has a rule identifier for matching with a process or flow identifier to identify the rule enforced against a process or network event. In some embodiments, the context-based service rule store 140 is defined hierarchically to ensure that rule checks match higher-priority rules before matching lower-priority rules. Furthermore, in some embodiments, the context-based service rule store 140 includes default rules specifying a default action for any rule check, as explained further below.

[0073] Firewall engine 128 performs firewall operations on data messages sent by or received by DCN 105. These firewall operations are based on firewall rules in context-based service rule storage device 140. Some of these firewall rules are defined purely based on Layer 2-4 attributes, such as quintuple identifiers. Other firewall rules are defined based on context attributes, which may include one or more collected context attributes such as application name, application version, AppID, resource consumption, threat level, user ID, group ID, etc. In some embodiments, other firewall rules are defined based on both L2-L4 parameters and context attributes. Because firewall engine 128 can resolve firewall rules defined by referencing context attributes, this firewall engine is referred to as a context-based firewall engine.

[0074] In some embodiments, the context-based firewall engine 128 can allow, block, or reroute data message flows based on any number of context attributes, because its firewall rules can be identified based on any combination of the collected context attributes. For example, when a user is part of a nurse user group, when a firewall rule specifies that data messages should be blocked when a flow is associated with a nurse group ID, when the AppID identifies the traffic type as email, and when the application name is Chrome, this firewall engine can block all email traffic from chrome.exe. Similarly, context-based firewall rules can block data message flows associated with video conferencing, online video viewing, or the use of older versions of software. Examples of such rules would be blocking all Skype traffic, blocking all YouTube video traffic, blocking all HipChat audio / video conferencing when the application version number is earlier than a specific version number, blocking data message flows for any application with a high threat score, and so on.

[0075] Load balancing engine 126 performs load balancing operations on data messages sent by DCN 105 to distribute the data message stream to different destinations or service nodes in one or more destination / service node clusters. These load balancing operations are based on load balancing rules in context-based service rule storage device 140. In some of these embodiments, each load balancing rule may specify one or more load balancing criteria (e.g., round-robin criteria, weighted round-robin criteria, etc.) for distributing traffic, and each criterion may be limited to a specific time range. In some embodiments, load balancing operations involve replacing the destination network address (e.g., destination IP address, destination MAC address, etc.) of the data message stream with another destination network address.

[0076] Some load balancing rules are defined purely based on L2-L4 attributes, such as 5-tuple identifiers. Other load balancing rules are defined based on context attributes, which may include one or more collected context attributes such as application name, application version, AppID, resource consumption, threat level, user ID, group ID, etc. In some embodiments, other load balancing rules are defined based on both L2-L4 parameters and context attributes. Because load balancing engine 126 can resolve load balancing rules defined by referencing context attributes, this load balancing engine is called a context-based load balancer.

[0077] In some embodiments, the context-based load balancer 126 can distribute data message flows based on any number of context attributes, as its load balancing rules can be identified based on any combination of the collected context attributes. For example, the data distribution of the load balancer 126 can be based on any combination of user and application data. Examples of such load balancing operations include: (1) distributing data message flows associated with the finance department across all load balancing pools, (2) redirecting all traffic to the finance department to another pool to make the traffic to that department highly available when the primary pool for that department decreases, and (3) making all traffic associated with the doctor's user group highly available. In some embodiments, load balancing rules can also be defined based on collected resource consumption to distribute traffic to provide more or less resources to applications consuming large amounts of resources on the DCN.

[0078] Encryption engine 124 performs encryption / decryption operations (collectively, encryption operations) on data messages sent by or received by DCN 105. These encryption operations are based on encryption rules in context-based service rule storage device 140. In some embodiments, each of these rules includes an encryption / decryption key identifier, which the encryption engine can use to retrieve an encryption / decryption key from a key manager on the host or operating externally to the host. In some embodiments, each encryption rule also specifies the type of encryption / decryption operation that the encryption module must perform.

[0079] Each encryption rule also has a rule identifier. For some encryption rules, the rule identifier is defined purely based on L2-L4 attributes, for example, based on a quintuple identifier. Other encryption rules are defined based on context attributes, which may include one or more collected context attributes such as application name, application version, AppID, resource consumption, threat level, user ID, group ID, etc. In some embodiments, other encryption rules are defined based on both L2-L4 parameters and context attributes. Because encryption engine 124 can parse encryption rules defined by referring to context attributes, this encryption engine is called a context-based encryption engine.

[0080] In some embodiments, the context-based encryption module 124 can encrypt or decrypt data message streams based on any number of context attributes, because its encryption rules can be identified based on any combination of the collected context attributes. For example, the encryption / decryption operations of the encryption engine 124 can be based on any combination of user and application data. Examples of such encryption operations include: (1) encrypting all traffic from Outlook (started on any computer) to Exchange Server, (2) encrypting all communication between applications in the Tier 3 web server, application server, and database server, (3) encrypting all traffic originating from the administrator Active Directory group, and so on.

[0081] Processing control engine 122 enforces context-based processing control operations (e.g., processing evaluation and termination operations) on processes initiated on DCN 105. In some embodiments, whenever context engine 110 receives a new processing event from GI agent 150 of DCN, it provides processing parameters associated with that processing event to processing control engine 122. This engine then uses the received set of processing parameters to examine its context-based service rule store 140 to identify matching context-based processing control rules.

[0082] Processing control engine 122 can instruct the context engine to instruct the DCN's GI agent to perform processing control operations on the processing. Examples of such processing control operations include (1) terminating a video conferencing application with a specific version number, (2) terminating a browser displaying YouTube traffic, and (3) terminating an application with a high threat level score.

[0083] Discovery engine 120 is another context-based service engine. In some embodiments, discovery engine 120 captures new processing events and new network events from the context engine, as well as context attributes collected by the context engine for these processing and network events. As further described below, the discovery service engine then relays these events and their associated context attributes to one or more network managers (e.g., servers), where the network managers provide a management layer that allows network administrators to visualize events in the data center and specify policies for computing and network resources in the data center.

[0084] When relaying these events and attributes to the network management layer, the discovery module in some embodiments performs some form of preprocessing on these events and attributes. For example, in some embodiments, the discovery module filters some of these network or processing events while aggregating some or all of these events and their attributes. Furthermore, in some embodiments, the discovery engine 120 instructs the context engine 110 to collect additional contextual attributes of processing or network events through the GI agent 150 or other modules (e.g., a DPI engine or a threat detection engine), or to capture other types of events, such as file events and system events.

[0085] For example, in some embodiments, the discovery engine instructs the context engine to build an inventory of applications installed on the machine and refresh that inventory periodically. The discovery engine may instruct the context engine based on requests from the management plane or based on operational configurations specified for the discovery engine by the management or control plane. In response to requests from the discovery engine, in some embodiments, the context engine causes each GI agent on each machine of its host to discover all installed processes and all running processes and services on the machine.

[0086] After building an inventory of installed applications and running processes / services, the host computer discovery engine in the data center provides this information to the network / compute manager in the management plane. In some embodiments, the management plane collects context attributes from sources other than the host computer discovery and context engine. For example, in some embodiments, the management plane collects compute context (e.g., cloud context from a cloud provider, or compute virtualization context via data center virtualization software) from one or more servers, identity context from a directory service server, mobility context from a mobility management server, endpoint context from DNS (Domain Name Server) and application inventory servers, network context (e.g., virtual network context from a network virtualization server), etc.

[0087] By collecting contextual information (e.g., information from the discovery and context engines and / or from other context sources), the management plane can provide a user interface to network / compute administrators to visualize compute and network resources in the data center. Furthermore, the collected contextual attributes allow the management plane to provide control through this user interface, enabling administrators to specify context-based service rules and / or policies. These service rules / policies are then distributed to host computers, allowing service engines on those computers to perform context-based service operations.

[0088] In some of the embodiments described above, the same service engine 130 (e.g., the same firewall engine 128) performs the same type of service (e.g., firewall service) based on service rules that can be defined based on a message flow identifier (e.g., a 5-tuple identifier) ​​or based on collected context attributes associated with the data message flow (e.g., AppID, threat level, user identifier, group identifier, application name / version, etc.). However, in other embodiments, different service engines provide the same type of service based on both the message flow identifier (e.g., a 5-tuple identifier) ​​and the context attributes of the collected data message flow. For example, some embodiments use a flow-based firewall engine that performs firewall operations based on rules defined according to the flow identifier, and another context-based firewall engine that performs firewall operations based on rules defined according to context attributes (e.g., AppID, threat level, user identifier, group identifier, application name / version, etc.).

[0089] Figure 2 A more detailed example of host computer 200 is illustrated. In some embodiments, host computer 200 is used to establish a distributed architecture for configuring and executing context-rich, attribute-based services in a data center. This host computer 200 includes many of the same components as host computer 100, such as a context engine 110, a service engine 130, a threat detector 132, a DPI module 135, a context-based service rule store 140, and a context attribute store 145. Figure 1 The same as in the middle, Figure 2 The service engine 130 includes a discovery engine 120, a processing control engine 122, an encryption engine 124, a load balancer 126, and a firewall engine 128.

[0090] exist Figure 2 In this context, DCN is a VM 205 running on the hypervisor. Furthermore, in... Figure 2 In this configuration, host computer 200 includes a software forwarding element 210, an attribute mapping storage device 223, a connection state cache storage device 225, a MUX (multiplexer) 227, and a context engine policy storage device 143. In some embodiments, the context engine 110, software forwarding element 210, service engine 130, context-based service rule storage device 140, connection state cache storage device 225, context engine policy storage device 143, and MUX 227 operate in the hypervisor's kernel space, while the VM 205 operates in the hypervisor's user space. In other embodiments, one or more service engines are user-space modules (e.g., service VMs).

[0091] In some embodiments, VM 205 serves as a data endpoint in a data center. Examples of such machines include web servers, application servers, database servers, etc. In some cases, all VMs belong to a single entity, such as the enterprise operating the host. In other cases, host 200 operates in a multi-tenant environment (e.g., in a multi-tenant data center), and different VMs 205 may belong to one or more tenants.

[0092] Each VM 205 includes a GI agent 250, which interacts with the context engine 110 to provide the engine with a set of context attributes and to receive instructions and queries from the engine. The interaction between the GI agent 250 and the context engine 110 is similar to the interaction between the GI agent 150 and the context engine 110 described above. However, as Figure 2 As shown, in some embodiments, all communication between the context engine 110 and the GI agent 250 is relayed via the MUX 227. An example of such a multiplexer is the one used by VMware's ESX hypervisor's Endpoint Security (EPSec) platform.

[0093] In some embodiments, the GI agent communicates with the MUX 227 via a fast communication channel (such as the VMCI channel of ESX). In some embodiments, this communication channel is a shared memory channel. As mentioned above, in some embodiments, the attributes collected by the context engine 110 from the GI agent 250 include a rich set of parameters (e.g., layer 7 parameters, process identifier, user identifier, group identifier, process name, process hash, loaded module identifier, consumption parameters, etc.).

[0094] As shown in the figure, in some embodiments, each VM 205 also includes a Virtual Network Interface Card (VNIC) 255. Each VNIC is responsible for exchanging messages between its VM and the Software Forwarding Unit (SFE) 210. Each VNIC is connected to a specific port 260 of the SFE 210. The SFE 210 is also connected to the host's physical network interface card (NIC) (not shown). In some embodiments, the VNIC is a software abstraction created by the hypervisor of one or more physical NICs (PNICs) of the host.

[0095] In some embodiments, SFE 210 maintains a single port 260 for each VNIC of each VM. SFE 210 connects to the host PNIC (via a NIC driver (not shown)) to send outgoing messages and receive incoming messages. In some embodiments, SFE 210 is defined to include port 265, which is connected to the PNIC driver to send messages to and receive messages from the PNIC. SFE 210 performs message processing operations to forward messages received on one of its ports to its other port. For example, in some embodiments, SFE attempts to match the message with flow-based rules using data in the message (e.g., data in the message header), and upon finding a match, performs an action specified by the matching rule (e.g., passing the message to one of its ports 260 or 265, indicating that the message is to be provided to the destination VM or PNIC).

[0096] In some embodiments, SFE 210 is a software switch, while in other embodiments it is a software router or a combination of software switches / routers. In some embodiments, SFE 210 implements one or more logical forwarding elements (e.g., logical switches or logical routers), wherein the SFE executes on other hosts in a multi-host environment. In some embodiments, the logical forwarding elements may span multiple hosts to connect VMs that execute on different hosts but belong to a single logical network.

[0097] Different logical forwarding elements (SFEs) can be defined to assign different logical networks to different users, and each logical forwarding element can be defined by multiple software forwarding elements on multiple hosts. Each logical forwarding element isolates the traffic of VMs in one logical network from VMs in another logical network served by another logical forwarding element. Logical forwarding elements can connect to VMs running on the same host and / or different hosts. In some embodiments, the SFE extracts a logical network identifier (e.g., VNI) and a MAC address from data messages. In these embodiments, the SFE uses the extracted VNI to identify logical port groups and then uses the MAC address to identify ports within the port group.

[0098] Software switches (e.g., software switches with hypervisors) are sometimes called virtual switches because they operate in software and they provide VMs with shared access to one or more PNICs on the host. However, in this document, software switches are referred to as physical switches because they are physical objects. This term also distinguishes software switches from logical switches, which are abstractions of the connection types provided by software switches. Various mechanisms exist for creating logical switches from software switches. VXLAN provides one way to create such logical switches. The VXLAN standard is described in Mahalingam, Mallik; Dutt, Dinesh G.; et al. (2013-05-08) VXLAN: A Framework for Overlaying Virthalized Layer 2 Networks over Layer 3 Networks, IETF.

[0099] In some embodiments, the port of SFE 210 includes one or more function calls to one or more modules that implement specific input / output (I / O) operations on incoming and outgoing messages received at the port. Examples of I / O operations implemented by port 260 include ARP broadcast suppression and DHCP broadcast suppression operations, as described in U.S. Patent 9,548,965. In some embodiments of the invention, other I / O operations (such as firewall operations, load balancing operations, network address translation operations, etc.) may be implemented. By implementing a stack of such function calls, in some embodiments, the port may implement a series of I / O operations on incoming and / or outgoing messages. Moreover, in some embodiments, other modules in the data path (such as VNIC 255, port 265, etc.) replace or are combined with port 260 to implement the I / O function call operations.

[0100] In some embodiments, one or more function calls to SFE port 260 may be one or more service engines 130 that process context-based service rules in context-based service rule storage device 140. In some embodiments, each service engine 130 has its own context-based service rule storage device 140, attribute mapping storage device 223, and connection state cache storage device 225. Figure 2Only one context-based service rule store 140, attribute mapping store 223, and connection state cache store 225 are presented for all service engines to avoid obscuring the representation in this diagram with unnecessary detail. Furthermore, in some embodiments, each VM has its own instance of each service engine 130 (e.g., its own instance of discovery engine 120, processing control engine 122, encryption engine 124, load balancer 126, and firewall engine 128). In other embodiments, a service engine can serve data message flows for multiple VMs on a host (e.g., VMs on the same logical network).

[0101] In order to perform its service operations on the data message stream, in some embodiments, the service engine 130 attempts to match the stream identifier (e.g., a 5-tuple identifier) ​​and / or the stream's associated set of context attributes to the rule identifier of its service rules in its context-based service rule store 140. Specifically, in order for the service engine 130 to perform its service check operations on the data message stream, the service engine's SFE port 260 is invoked to provide the attribute set of messages received by the port. In some embodiments, this attribute set is a message identifier (such as a conventional 5-tuple identifier). In some embodiments, one or more of the identifier values ​​may be logical values ​​defined for a logical network (e.g., IP addresses defined in a logical address space). In other embodiments, all identifier values ​​are defined in the physical domain. In still other embodiments, some of the identifier values ​​are defined in the logical domain, while others are defined in the physical domain.

[0102] Then, in some embodiments, the service engine uses the attribute set of the received message (e.g., the message's 5-tuple identifier) ​​to identify the set of context attributes that the service engine has stored in the attribute mapping storage 223 for this stream. As mentioned above, in some embodiments, the context engine 110 supplies the context attributes for new streams (i.e., new network connection events) and for new processing, along with stream identifiers (e.g., 5-tuple identifiers) or processing identifiers, to the service engine 130. The context engine policy storage 143 contains rules that control the operation of the context engine 110. In some embodiments, these policies instruct the context engine to generate rules for the service engine or instruct the service engine to generate rules (e.g., when a high-threat application is running on a VM, instructing the encryption engine to encrypt their data message traffic for all other VMs on the same host). In these embodiments, the service engine 130 stores the context attributes it receives from the context engine in the attribute mapping storage 223.

[0103] In some embodiments, service engine 130 stores the context attribute set of each new stream or new process having an identifier for that stream (e.g., a quintuple identifier) ​​or an identifier for that process in an attribute mapping storage device. In this way, the service engine can identify the context attribute set of each new stream it receives from SFE port 260 by searching its attribute mapping storage device 223 for a context record with a matching stream identifier. A context record with a matching stream identifier includes the context attribute set of that stream. Similarly, in order to identify the context attribute set of a processing event, in some embodiments, the service engine searches its attribute mapping storage device 223 for a context record with a matching processing identifier.

[0104] As mentioned above, in some embodiments, some or all of the service engines pull the context attribute set for new flows or new processing from the context engine. For example, in some embodiments, the service engine supplies the 5-tuple identifier of the new flow it receives from SFE port 260 to the context engine 110. The engine 110 then examines its attribute storage device 145 to identify the attribute set stored for the 5-tuple identifier, and then supplies the attribute set (or a subset of the attribute set obtained by filtering the attribute set identified by the service engine) to the service engine.

[0105] As described above, some embodiments implement a pull model by using a service token to encode a set of attributes for a new message stream. When a new network connection event is notified, in some embodiments, context engine 110 (1) collects a set of context attributes for the new event, (2) filters this set to discard attributes irrelevant to the execution of one or more services on the stream, (3) stores the remaining filtered subset of attributes along with the service token in attribute storage device 145, and (4) provides the service token to GI agent 250. GI agent 250 then causes this token to be delivered either in-band (e.g., in the header of a data message sent from the agent's VM to the destination) or out-of-band (i.e., separately from the data message sent from the agent's VM to the destination) to service engine(s).

[0106] When the service engine receives a new flow through SFE port 260, it provides the service token for that flow to the context engine, which uses this service token to identify the context attributes to be provided to the service engine in its attribute storage device 145. In embodiments where the SFE port does not provide the service token to the service engine, the service engine must first identify the service token by searching its data storage using the flow's identifier before providing the service token to the context engine.

[0107] After identifying the context attribute set of the data message stream, in some embodiments, the service engine 130 performs its service operations based on service rules stored in the context-based service rule storage device 140. To perform its service operations, the service engine 130 matches a received subset of attributes with the corresponding attribute set stored for the service rules. In some embodiments, each service rule in the context-based service rule storage device 140 has a rule identifier and a set of action parameters.

[0108] As mentioned above, in some embodiments, the rule identifier of a service rule can be defined based on one or more context attributes that are not L2-L4 header parameters (e.g., L7 parameters, process identifiers, user identifiers, group identifiers, process names, process hashes, loaded module identifiers, consumption parameters, etc.). In some embodiments, the rule identifier may also include L2-L4 header parameters. Furthermore, in some embodiments, one or more parameters in the rule identifier can be specified based on individual values ​​or wildcard values. Moreover, in some embodiments, the rule identifier may include a set of individual values ​​or group identifiers, such as security group identifiers, computational construct identifiers, network construct identifiers, etc.

[0109] To match the received attribute set with the rules, the service engine compares the received attribute set with the association identifier of the service rule stored in the context-based service rule storage device 140. After identifying a matching rule, the service engine 130 performs a service operation (e.g., firewall operation, load balancing operation, encryption operation, other middleware operation, etc.) based on the action parameter set of the matching rule (e.g., based on allow / drop parameters, load balancing criteria, encryption parameters, etc.).

[0110] In some embodiments, the context-based service rule store 140 is defined hierarchically to ensure that message rule checks match higher-priority rules before matching lower-priority rules when multiple rules match a subset of message attributes. Furthermore, in some embodiments, the context-based service rule store 140 includes a default rule that specifies the default action for any message rule check that does not recognize any other service rules; in some embodiments, this default rule will match all possible subsets of attributes and ensure that the service rule engine returns an action for all received subsets of attributes. In some embodiments, the default rule will not specify a service.

[0111] For example, when a message is part of a stream associated with a communication session between two machines, multiple messages may have the same set of message identifier attributes. Therefore, after matching a data message against service rules in the context-based service rule storage 140 based on the identified set of context attributes, the service engine in some embodiments stores the service rule (or a reference to a service rule) in the connection state cache storage 225 so that this service rule can later be used for subsequent data messages in the same stream.

[0112] In some embodiments, the connection-state cache storage device 225 stores service rules or references to service rules identified by the storage engine 130 for different sets of message identifiers (e.g., different 5-tuple identifiers for identifying different data message streams). In some embodiments, the connection-state cache storage device 225 stores each service rule or reference to a service rule, as well as identifiers generated from the matching set of message identifiers (e.g., the 5-tuple identifier of the stream and / or the hash value of the 5-tuple identifier of the stream).

[0113] Before examining a specific message using the context-based service rule storage device 140, in some embodiments, the service rule engine 130 checks the connection state cache storage device 225 to determine if this storage device has previously identified service rules for the message stream. If not, the service engine 130 identifies a set of context attributes for the message stream and then checks the context-based service rule storage device 140 to find service rules that match the identified attribute set and / or its 5-tuple identifier for the message. When the connection state data storage device has an entry for a specific message, the service engine performs its service operation based on the action parameter set of this service rule.

[0114] exist Figure 2 In the service architecture, the DPI module 135 performs deep packet inspection on the data message stream in the direction of the firewall engine 128. Specifically, when the firewall engine 128 receives a new data message as part of a new data message stream, in some embodiments, the firewall engine instructs the DPI module to inspect the new data message and one or more subsequent data messages in the same stream. Based on this inspection, the DPI engine identifies the type of traffic sent in this data message stream (i.e., online application), generates an AppID for this traffic type, and stores this AppID in the attribute storage device 145. In some embodiments, a set of context attributes is stored in the attribute storage device based on the stream identifier and / or processing identifier. Thus, in some embodiments, the DPI engine 135 stores the AppID of the new data message stream in the attribute storage device 145 based on the 5-tuple identifier of that stream.

[0115] In some embodiments, once the DPI engine stores the AppID in the attribute storage device 145, the context engine 110 pushes the AppID for a new data message stream to the service engine 130. In other embodiments, the context engine 110 retrieves the AppID from the attribute storage device 145 whenever the service engine queries the context attributes of a data message stream. In some embodiments, the context engine 110 uses the stream's 5-tuple identifier to identify records in the attribute storage device 145 that have a matching record identifier and AppID.

[0116] Figure 3 The illustration shows a process 300, executed by the context engine 110 in some embodiments, each time a new processing or network connection event is notified. From the GI agent 250 of VM 205, process 300 initially receives (at 305) a notification about a new processing or network connection event. Next, at 310, process 300 collects all expected context attributes regarding the notified event.

[0117] As described above, in some embodiments, the context engine 110 interacts with the reporting GI agent 250 (at 310) to collect additional information about the reported events. In some embodiments, the GI agent interacts with the network stack and / or processing subsystem in the VM's OS kernel space to collect context attributes about processing or network events. In some embodiments, the GI agent also collects this information from user-space modules (e.g., user-mode dynamic link libraries, DLLs) operating in user-space processing (e.g., VMtool.exe) to collect context attributes. On VMs using Microsoft Windows, in some embodiments, the GI agent registers hooks in the Windows Filtering Platform (WFP) to receive network events, while also registering with the Windows processing subsystem to collect processing-related attributes. In some embodiments, the GI agent hooks reside in the WFP's Application Layer Enforcement (ALE) layer, allowing it to capture all socket connection requests from application processing on the VM.

[0118] In some embodiments, the context engine 110 interacts with the management or control plane to collect context attributes and / or receive records it can inspect to identify context attributes for identified network or processing events. In some of these embodiments, the context engine interacts with a management or control plane agent (operating on its host) to obtain data from a management or control plane server operating outside the host. In some of these embodiments, the context engine operates in kernel space.

[0119] After collecting context attributes at 310, the process uses (at 315) the attributes of the received event or the context attributes collected for the received event to identify one or more policies in the context engine policy storage device 143. At 315, the process identifies any policy with a policy identifier that matches the collected attributes and event attributes.

[0120] Next, at 320, the processing generates context attribute mapping records for one or more service engines based on the strategy identified at 315. One or more of the identified strategies may specify that for a particular processing or network event, a notification of the event (e.g., related to a new data message stream) needs to be sent to a specific set of service engines, where each service engine receives a subset of context attributes associated with that service engine to perform processing for that event. In some embodiments, this operation involves the context engine excluding attributes that are not specific to each service engine within the subset of context attributes it provides to that particular service engine.

[0121] In some embodiments, certain events may require the creation of new service rules for one or more service engines. For example, when a high-threat application is identified on a VM, a policy might specify that other VMs on that host may need to begin encrypting their data message traffic. In some such embodiments, the context engine policy storage device 143 includes a policy that instructs the context engine to generate service rules for the service engine under certain circumstances or instructs the service engine to generate such service rules. For such embodiments, if needed, processing (at 320) generates service rules for the service engine under certain circumstances or instructs the service engine to generate such service rules.

[0122] At point 325, process 300 distributes the mapping record and / or generated service rules / instructions to one or more service engines. As mentioned above, the context engine may employ a push or pull model to distribute such records and / or rules / instructions. When using a pull model, in some embodiments, process 300 performs operation 325 not only in response to a query from a service engine, but also some or all of operations 320 in response to that query. After 325, the process ends.

[0123] The load balancing engine 126 is a context-based load balancer that performs its load balancing operations based on load balancing rules, which can be specified not only according to L2-L4 parameters but also according to context attributes. Figure 4The illustration shows an example of this context-based load balancing rule. These rules are used independently by different load balancing engines 126 on different hosts 500 to distribute data messages from different web server VMs 505 on these hosts to different application server VMs 510, such as... Figure 5 As shown in the diagram. In some embodiments, host 500 is similar to host 200, and web server VM 505 and application server VM 510 are similar to... Figure 2 The VM 205. To avoid blurring the graphics with unnecessary details, Figure 5 The only components of the host 500 shown are the load balancer 126 and the web server VM 505, with the load balancer appearing as a service module in the egress path of the web server VM 505.

[0124] exist Figure 5 In the example shown, load balancers 126 collectively form a distributed load balancer (i.e., a single conceptual logical load balancer) that spans multiple hosts to evenly distribute web server VM traffic across application server VMs. As further described below, in some embodiments, the load balancing criteria for the load balancing rules used by the different load balancers 126 are identical to ensure uniform processing of web server VM traffic. As shown by host 500b, multiple web server VMs 505 can run on the same host 500, each of these web server VMs being served by a different load balancer 126. In other embodiments, a single load balancer can serve multiple VMs on the same host (e.g., multiple VMs for the same tenant on the same host). Furthermore, in some embodiments, multiple application server VMs can run on the same host alongside each other and / or with web server VMs.

[0125] exist Figure 4-5 In the example shown, load balancer 126 performs Destination Network Address Translation (DNAT), which translates the Virtual IP (VIP) address of the application server into the IP address of the specific application VM, referred to as the Destination IP address or DIP. In other embodiments, DNAT operations can translate other network addresses; for example, it can translate MAC addresses to achieve MAC redirection. Moreover, although... Figure 4-5 Load balancers distribute web server traffic among application servers in an application server group (cluster), but load balancers can also be used to distribute traffic from any set of one or more service or compute nodes among service or compute nodes in any service / compute node cluster.

[0126] Figure 4The diagram illustrates a load balancing (LB) rule storage device 140 storing several LB rules, each LB rule being associated with a load-balanced compute or service cluster. Each load balancing rule includes (1) a rule identifier 405, (2) several IP addresses 410 of several nodes in the load-balanced node group, and (3) a weight value 415 for each IP address. Each rule identifier 405 specifies one or more data tuples that can be used to identify a rule that matches a data message flow.

[0127] In some embodiments, the rule identifier may include the VIP address of the rule's associated DCN group (such as...). Figure 5 (The VIP address of the application server group in the diagram). As shown, in some embodiments, the rule identifier may include any L2-L4 parameters (e.g., source IP address, source port, destination port, protocol, etc.). Furthermore, as shown, the rule identifier used for LB rules may include context attributes such as AppID, application name, application version, user ID, group ID, threat level, resource consumption, etc. In some embodiments, the load balancer searches the LB data storage device by comparing one or more message attributes (e.g., 5-tuple header value, context attributes) with the rule identifier 405 to identify the highest priority rule with a matching rule identifier.

[0128] Each LB rule's IP address 410 is the IP address of a compute or service node that is a member of the load balancing compute or service group associated with the rule (e.g., a member of the load balancing group associated with the VIP address specified in the rule's identifier 405). As further described below, in some embodiments, these node addresses are supplied by configuring the load balancer's controller set. In some embodiments, the load balancer translates the destination IP address of received data messages into one of the IP addresses 410 (e.g., translating the VIP contained in the data message into a DIP).

[0129] In some embodiments, a load balancer performs its load balancing operations based on one or more load balancing criteria. Some embodiments include LB rules that specify, within each rule, how the load balancer should spread traffic across nodes in the load balancing group when a message flow matches that rule. Figure 4 In the example shown, the load balancing criterion is a weighted round-robin scheme, defined by a weight value of 415 for each rule. Specifically, the weight value of 415 for each IP address used in each LB rule provides the load balancer with a criterion for distributing traffic to the nodes in the LB node group.

[0130] For example, Figure 5The application server group has five application servers. Assume the load balancing rules used to distribute web server traffic among these five application servers assign weight values ​​of 1, 3, 1, 3, and 2 to the five IP addresses of the five application servers. Based on these values, the load balancer will distribute data messages as part of ten new flows in the following order: the first flow to the first IP address, the second through fourth flows to the second IP address, the fifth flow to the third IP address, the sixth through eighth flows to the fourth IP address, and the ninth and tenth flows to the fifth IP address. According to this scheme, the assignment of the next batch of new flows will cycle through these IP addresses (e.g., the eleventh flow will be assigned to the first IP address, and so on).

[0131] In some embodiments, the weight values ​​for LB rules are generated and adjusted by a controller set based on LB statistics, wherein the LB statistics are collected (1) by the load balancers regarding the data message flows they distribute among nodes in one or more LB node groups and (2) provided to the controller set. Furthermore, to facilitate smooth switching between different load balancing criteria, in some embodiments, LB rules specify time periods for different load balancing criteria that are valid for LB rules at different time periods. Thus, in some embodiments, load balancing rules may specify multiple different sets of destination network addresses having different time values ​​specifying when each set of addresses is valid. In some embodiments, each of these sets may include its own set of LB criteria (e.g., its own set of weight values).

[0132] Figure 6 The illustration shows a process 600 performed by load balancer 126 in some embodiments. As shown, process 600 begins when the load balancer receives a data message (at 605) from its corresponding SFE port 260. This port relays the message when it receives it from or for its VM. In some embodiments, the port relays the data message by passing a reference to the data message or the header value of the data message (e.g., a handle identifying the location in memory where the data message is stored) to the load balancer.

[0133] The process determines (at 610) whether the connection-state cache 225 stores a record identifying the destination to which a data message should be forwarded. As mentioned above, each time the load balancer directs a new data message stream to a node in the load balancing node group using LB rules, in some embodiments, the load balancer creates a record in the connection-state cache 225 to store the physical IP address of the selected node so that when the load balancer receives another data message in the same stream (i.e., with the same 5-tuple identifier), it can forward it to the same node it used for the previous data message in the same stream. The use of the connection-state cache 225 allows the load balancer 126 to process data message streams more quickly. In some embodiments, each cache record in the connection-state cache 225 has a record identifier defined according to the data message identifier (e.g., a 5-tuple identifier). In these embodiments, the process compares the identifier of the received data message (e.g., a 5-tuple identifier) ​​with the record identifier of the cached record to identify any record with a record identifier that matches the identifier of the received data message.

[0134] When process 600 identifies (at 610) a record in connection state cache 225 for the stream of received data messages, process 600 (at 615) then replaces the message's destination address (e.g., VIP address) with the destination address (e.g., DIP) stored in the record in connection state cache 225. At 615, the process sends the address-translated data message along its data path. In some embodiments, this operation requires returning communication to SFE port 260 (which is referred to as the load balancer to initiate process 600) to instruct the load balancer to complete its processing of the VM data message. SFE port 260 can then either hand over the data message to the SFE or invoke another service engine in the I / O chain operators to perform another service operation on the data message. At 615, process 600 also updates its maintained statistics regarding the processing of its data message stream in some embodiments. After 615, process 600 terminates.

[0135] When process 600 determines (at 610) that the connection state cache 225 does not store a record for the stream of received data messages, process 600 identifies (at 620) one or more context attributes of this data message stream. As mentioned above, the service engines in different embodiments perform this operation in different ways. For example, in some embodiments, load balancer 126 checks attribute mapping storage 223 to find a record with a record identifier that matches the header value (e.g., its 5-tuple identifier) ​​of the received data message. It then uses (at 620) the set of context attributes of this matching record as the set of context attributes for the received data message stream.

[0136] In other embodiments, load balancer 126 queries the context engine to obtain a set of context attributes for the received data message. Using this query, the load balancer supplies the flow identifier (e.g., a 5-tuple identifier) ​​or its associated service token for the received message. The context engine then uses the message's flow identifier or its associated service token to identify the set of context attributes in its context attribute storage device 145, and then provides the identified set of context attributes to load balancer 126, as explained above.

[0137] Once process 600 has obtained the set of context attributes for the received data message, it uses this set of attributes, along with other identifiers for the message, to identify (at 625) the LB rule in LB rule store 140 for the data message received at 605. For example, in some embodiments, the LB rule has a rule identifier 405, defined based on one or more of the five-tuple attributes and one or more context attributes (such as application name, application version, user ID, group ID, AppID, threat level, resource consumption level, etc.). To identify the LB rule in LB rule store 140, in some embodiments, the process compares the context attributes and / or other attributes (e.g., the five-tuple identifier) ​​of the received data message with the rule identifier of the LB rule (e.g., rule identifier 405) to identify the highest priority rule with an identifier that matches the set of attributes of the message.

[0138] In some embodiments, the process uses different sets of message attributes to perform the comparison operation. For example, in some embodiments, the message attribute set includes the destination IP address of the message (e.g., the VIP of the addressed node group) and one or more context attributes. In other embodiments, the message attribute set includes other attributes, such as one or more of other 5-tuple identifiers (e.g., one or more of source IP, source port, destination port, and protocol). In some embodiments, the message attribute set includes logical network identifiers, such as Virtual Network Identifier (VNI), Virtual Distributed Router Identifier (VDRI), logical MAC address, logical IP address, etc.

[0139] As mentioned above, in some embodiments, each LB rule includes two or more destination addresses (e.g., IP address 410), which are the destination addresses (e.g., IP addresses) of nodes that are members of the load balancing node group. When the process identifies an LB rule (at 630), it selects one of the rule's destination addresses (e.g., IP address) to replace the virtual address (e.g., VIP address) in the message. Furthermore, as mentioned above, in some embodiments, each LB rule stores a set of load balancing criteria to facilitate the process in selecting one of the LB rule's destination addresses to replace the message's virtual destination identifier. In some embodiments, the stored criteria are those referenced above. Figure 4 and 5 The weights and / or time values ​​described. Therefore, in some embodiments, process 600 selects one of the destination addresses matching the rules based on selection criteria stored in the rules, and changes the message's destination address to the selected destination address.

[0140] After changing the destination address of the data message, the process (at 630) sends the data message along its data path. Similarly, in some embodiments, this operation requires returning communication to SFE port 260 (which calls the load balancer to initiate process 600) to instruct the load balancer to complete its processing of the VM data message. SFE port 260 can then hand the data message over to the SFE or VM, or it can call another service engine in the I / O chain operators to perform another service operation on the data message.

[0141] After 630, the process proceeds to 635, where, in the connection state cache storage 225, it creates a record to identify the compute or service node in the load balancing group (i.e., the node destination identifier) ​​for use in forwarding data messages that are part of the same stream as the data message received at 605. At 635, process 600 also updates the statistics it maintains for the node to which process 600 addresses the message. This update reflects the transmission of new data messages to this node. After 635, the process ends.

[0142] Because it uses context attributes to define the rule identifiers for LB rules, the context-based load balancer 126 can distribute data message flows based on any number of context attributes. Examples of such load balancing operations, as mentioned above, include: (1) distributing data message flows associated with the finance department across all load balancing pools; (2) redirecting all traffic from the finance department to another pool in the event of a failure of the primary pool used for this department, thereby making the traffic for this department highly available; (3) making all traffic associated with the doctor user group highly available; and (4) distributing data message flows for the finance application among service nodes in the low latency service node group. In some embodiments, load balancing rules can also be defined based on collected resource consumption to distribute traffic to provide more or less resources to applications consuming large amounts of resources on the DCN.

[0143] In some embodiments, the management plane obtains an inventory of all processes and services running on VMs on hosts in a data center. In some embodiments, the discovery engine 120 of host 200 assists in collecting this data from the VMs running on its host. In some embodiments, the processes / services in the inventory are referred to as applications in the inventory, which include all client processes, services, or daemons that utilize network input / output, as well as all server processes that have registered to listen for (i.e., receive messages) certain network connections. In some embodiments, the discovery engine uses GI agent 250 and MUX 227 to collect this data.

[0144] Based on data collected by all discovery engines across all hosts, the management server (e.g., the network manager and / or compute manager) builds an inventory of running applications. In some embodiments, each application is identified by comparing its file hash obtained from VM 205 with the hash of the application file stored in the application data store in the management plane. In some embodiments, the management plane causes the discovery engines to update their data sets, allowing the management plane to refresh its inventory on a scheduled basis.

[0145] Then, in some embodiments, the management plane provides a rule creation interface for allowing administrators to create context-based LB rules and / or policies for LB engine 126 (and service rules for other service engines 130). The rule creation interface allows administrators to define advanced LB policies (and other service policies) based on applications listed through data collected by discovery engine 120 and context attributes collected by context engine 110 and by the management plane's interfaces with other management server clusters.

[0146] Once high-level load balancer policies (and other service policies) are defined in the management plane, the management plane directly supplies some or all of these policies to management agents (not shown) on host 200, and / or indirectly supplies some or all of these policies to these agents through a set of controllers (e.g., network controllers). In some embodiments, the management agent publishes the received policies as rules to context-based service rule store 140. In some embodiments, the agent transforms these policies before publishing them to context-based service rule store 140. For example, in some embodiments, policies are published with AppliedTo tuples that identify the service nodes and / or logical networks they are associated with. In some of these embodiments, the management agent on the host removes the AppliedTo tuples from each service policy before pushing the policies as service rules to service rule store 140. Moreover, as mentioned above, in some embodiments, the context engine 110 on host 200 parses the policies based on collected context attributes to generate rules for the service engine.

[0147] Firewall Engine 128 is a context-based firewall engine that performs its firewall operations based on firewall rules, which can be specified not only based on L2-L4 parameters but also based on context attributes. Figure 7 Several examples of such firewall rules are illustrated. This figure illustrates a firewall rule data repository 140 of some embodiments. As shown, each firewall rule includes a rule identifier 705 and firewall action parameters 710.

[0148] In some embodiments, firewall action parameter 710 can specify any of the traditional firewall actions, such as allow, drop, reroute, etc. Each rule identifier 705 specifies one or more data tuples that can be used to identify a rule matching the data message flow. As shown, in some embodiments, the rule identifier can include any L2-L4 parameters (e.g., source IP address, source port, destination port, protocol, etc.). One or more of these parameters can be virtual parameters (e.g., the VIP of the destination cluster) or logical identifiers (e.g., logical network identifiers).

[0149] In some embodiments, the rule identifier may also include contextual attributes such as AppID, application name, application version, user ID, group ID, threat level, and resource consumption. In some embodiments, the firewall engine searches the firewall data storage device by comparing one or more message attributes (e.g., 5-tuple header values, contextual attributes) with the rule identifier 705 to identify the highest priority rule that matches the rule identifier.

[0150] In some embodiments, different firewall engines 128 on different hosts enforce the same set of firewall rules. For example, in some embodiments, different firewall engines 128 process the same firewall rules on different hosts of VMs in a logical network to provide security levels for data messages sent by or received by these VMs. For such a logical network, these firewall engines 128 collectively form a distributed firewall engine (i.e., a single conceptual logical firewall engine) spanning multiple hosts.

[0151] Figure 8 Several more detailed examples of context-based firewall rules from some embodiments are illustrated. In these examples, each rule's rule identifier 705 is represented by a 5-tuple identifier and one or more context attributes. Each rule has one or more attributes in its 5-tuple identifier, which are wildcard values ​​represented by asterisks, so that specifying the values ​​of these attributes is irrelevant (i.e., the data message flow can have any value for these attributes without failing to match the rule).

[0152] Rule 835 specifies that all data message streams from Skype version 1024 should be discarded. The rule identifier for this rule is defined solely based on the context attributes of the data message stream. As mentioned above and further described below, each time firewall engine 128 identifies a new data message stream, it identifies the context attributes of the stream by interacting with the context engine or by examining records in its attribute mapping storage device 223 to identify the record of the context attributes of the five-tuple identifier specifying the stream.

[0153] Rule 830 specifies that all data message streams with a group ID equal to the nurse's and an AppID equal to the YouTube traffic should be dropped. By enforcing this rule, firewall engine 128 can ensure that nurses logged into its VM 205 cannot view YouTube traffic. Similarly, the rule identifier for this rule is defined solely by the context attributes of the data message stream. In this example, the context attributes are the group ID and the AppID.

[0154] Figure 9An example of firewall engine 128 enforcing rule 830 is presented. Specifically, it shows that firewall engine 128 allows a first data message 905 from browser 910 to pass through while blocking a second data message 915 from the same browser. As shown, both data messages are associated with an action performed by nurse 920 on the browser. The first data message stream is allowed to pass because it relates to an email sent by the nurse through the browser. Firewall engine 128 allows this message to pass because it does not match any firewall rule that requires blocking the message. On the other hand, firewall engine 128 blocks the second data message because it relates to the nurse attempting to watch a YouTube video, and rule 830 prohibits this type of data message stream.

[0155] Figure 8 Rule 825 in the document specifies that if data messages destined for a specific destination IP address A, then all data message flows associated with a high threat level indicator should be blocked. The rule identifier for this rule is defined based on the contextual attribute (i.e., the high threat level indicator) and one attribute (destination IP address) in the data message's 5-tuple identifier.

[0156] Figure 10 An example of firewall engine 128 enforcing rule 825 is presented in two phases. Specifically, in phase 1002, firewall engine 128 allows data message 1010 to be passed from VM 205 to another VM 1020 (outside the host) with a specific destination IP address A. In phase 1004, application 1005 is installed on VM 205. This application is designated as a high-threat application by threat detector 132. Whenever a new data message stream is started on a VM, the context engine associates this data message stream with a high-threat level flag. Therefore, in phase 1004, firewall engine 128 blocks data message 1050 from VM 205 to another VM 1020 because this data message is associated with a high-threat level, and rule 815 prohibits sending such a data message to IP address A of VM 1020.

[0157] Figure 8Rules 820 and 815 of the fourth and fifth rules specify that data messages associated with the Doctors and Nurses groups can access the VMs associated with VIP address A, while data messages associated with the Accounting group cannot access these VMs. The rule identifier for the fourth rule is defined based on two contextual attributes (i.e., the Doctors and Nurses group identifier) ​​and one attribute (VIP destination address A) in the data message's five-tuple identifier. The rule identifier for the fifth rule is defined based on one contextual attribute (i.e., the Accounting group identifier) ​​and one attribute (VIP destination address A) in the data message's five-tuple identifier. In some embodiments, the VIP address is the address of a cluster of VMs performing the same function, and the load balancer translates this VIP address into the IP address of one of the VMs in the cluster.

[0158] Figure 11 The illustration shows an example of firewall engine 128 enforcing rules 820 and 815, respectively. Specifically, it shows two users simultaneously logged into a VM that acts as a terminal server. One of these users is Nurse X, and the other is Accountant Y. Figure 11 It also shows that firewall engine 128 allows the first data message 1105 from nurse X's session to be delivered to a VM in VM cluster 1150 identified by the destination IP address VIP A. It further shows that the firewall engine blocks the second data message 1110 from accountant Y's session from reaching any VM in this VM cluster because rule 815 5 blocks data messages associated with the accountant group ID from reaching the destination IP address VIP A.

[0159] exist Figure 11 In this case, the two data messages are for two different actual users logged into the VM simultaneously. In other cases, only one user might actually be logged into the VM, but management processing, along with processing run by applications started by the logged-in user, might be running on the VM. Management processing could be a service / daemon running in a VM within a different user context than the logged-in user. Services typically run in the admin / root context, not the logged-in user's context. This is a potential security vulnerability, as it could allow any application running in a non-logged-in user context to access network resources. Therefore, even when only a single user is logged into the VM, it is desirable to specify firewall rules that treat data messages associated with background management processing differently from data messages associated with processing run from applications started by the logged-in user.

[0160] As an example, Rule 6 810 allows data messages associated with applications operated by individuals within a high-security group to access other VMs containing sensitive data (in this example, these VMs are part of a VM cluster associated with IP address VIP B), while Rule 7 805 blocks data messages associated with background administrative processes from accessing these VMs. This is very useful for ensuring that IT personnel or hackers cannot create backdoors to access sensitive data by installing administrative processes that access high-security VMs, which can piggyback user login sessions through appropriate gaps.

[0161] Figure 12 The illustration presents an example of firewall engine 128 enforcing rules 810 and 805, numbers six and seven. Specifically, it shows two data message streams originating simultaneously from a single VM. One data message stream is associated with the CEO, while the other is associated with a background IT utility process called Utility Q. Figure 12 The diagram further illustrates that firewall engine 128 allows data messages 1205 from the CEO's session to be delivered to the VM identified by VIP address B in the high-security cluster 1250. It also shows that the firewall engine blocks a second data message 1210 from the utility Q's session from reaching any VM in the high-security cluster because rule 805 7 blocks data messages associated with management processes (such as utility Q processes) from reaching VIP address B.

[0162] The firewall engine can distinguish between two different data message streams running concurrently on a VM for two different login / management credentials because when each stream begins, the context engine collects user and group identifiers for each data message stream and associates each stream with its user and group identifiers. Figure 13 The diagram illustrates the process 1300 that the context engine performs to collect user and group identifiers each time it receives a new network connection event from the GI agent.

[0163] Processor 1300 initially receives a notification of a new network connection event from GI agent 250 on VM 205 (at 1305). As mentioned above, in some embodiments, the GI agent provides the following information in the new network connection notification: a five-tuple identifier of the connection, an identifier of the process requesting the network connection, a user identifier associated with the process that issued the request, and a group identifier associated with the process that issued the request.

[0164] Next, at 1310, process 1300 queries the GI agent to collect any additional context attributes required for new network connection events. Examples of these additional parameters include those associated with the process requesting the network connection. At 1315, process 1300 then publishes one or more context attribute records to one or more service engines. In some embodiments, each context attribute record to each service engine includes a five-tuple identifier for the connection and a set of one or more context attributes, including a user identifier and / or a group identifier. The service engines then store the provided context attribute records in their attribute mapping storage 223 so that they can use these records to identify the set of context attributes associated with the different data message streams they process. For service engines with different service rules for different processes running concurrently on the VM for different user accounts, the set of context attributes includes a user identifier or a group identifier to allow these service engines to associate different data message streams from the VM with different user / group identifiers.

[0165] In some embodiments, the context engine does not include context attributes that the service engine does not need in the service engine's context attribute record. Furthermore, in some embodiments, the context engine provides different context attribute records to different context engines for the same network connection event because different service engines require different sets of context attributes. As described above, in some embodiments, the context engine 110 does not push the context attribute set for a new network connection to some or all service engines, but instead allows these service engines to pull these attribute sets.

[0166] In some embodiments, the context engine can associate a data message stream on a source host having a source VM (i.e., the VM that is the source of the data message stream) with context attributes of a destination VM on the same host or a different destination host. The firewall engine 128 in these embodiments can then use this destination-based context attribute to resolve firewall rules. For example, the firewall engine can drop all data messages addressed to a specific type of server (e.g., a SharePoint server). To support such destination-based rules, the context engine in some embodiments instructs the GI agent to identify the processing that registers notifications on a specific port and uses this information along with a processing identifier and hash to identify the application acting as the destination of the data message stream. Information collected by the context engines on different hosts is gathered by the management plane (e.g., by a management server operating on a separate computer or on the same host executing the VM), which aggregates this data and distributes the aggregated data to other context engines. The distributed information can then be used by the context engines on the hosts to resolve context policies on those hosts in order to supply context-based rules to the context-based service engines on those hosts.

[0167] Figure 14 The illustration depicts process 1400 performed by firewall engine 128 in some embodiments. As shown, process 1400 begins when the firewall engine receives a data message (at 1405) from its corresponding SFE port 260. This port relays the data message when it receives it from or for its VM. In some embodiments, the port relays the data message by passing a reference to the data message or the header value of the data message (e.g., a handle identifying the location in memory where the data message is stored) to the firewall engine.

[0168] The process determines (at 1410) whether the connection state cache 225 stores a record identifying a firewall action for a message stream used for a received data message. As mentioned above, each time the firewall engine processes a new data message using firewall rules, in some embodiments, the firewall engine creates a record in the connection state cache 225 to store the firewall action performed, so that when the firewall engine receives another data message in the same stream (i.e., with the same 5-tuple identifier), it can perform the same firewall action performed on the previous data message in the same stream. The use of the connection state cache 225 allows the firewall engine 128 to process data message streams more quickly. In some embodiments, each cached record in the connection state cache 225 has a record identifier defined according to the data message identifier (e.g., a 5-tuple identifier). In these embodiments, the process compares the identifier of the received data message (e.g., a 5-tuple identifier) ​​with the record identifier of the cached record to identify any record with a record identifier that matches the identifier of the received data message.

[0169] When process 1400 identifies a record of the received data message stream in connection state cache 225 (at 1410), the process (at 1415) then executes the firewall action specified in that record (e.g., allow, drop, reroute, etc.). Assuming the firewall action does not require dropping the data message, process 1400 sends the processed data message along its data path. In some embodiments, this operation requires returning communication to SFE port 260 (which invokes the firewall engine to initiate process 1400) to instruct the firewall engine to complete its processing of the VM data message. SFE port 260 can then hand the data message over to the SFE or VM, or it can invoke another service engine in the I / O chain operators to perform another service operation on the data message.

[0170] When a firewall action performed at 1415 causes a data message to be dropped, process 1400 notifies SFE port 260 of this operation (at 1415). Furthermore, when a firewall action performed at 1415 requires a rerouting of the data message, process 1400 performs network address translation on the data message (at 1415) to achieve this rerouting, and then returns the data message (at 1415) to the SFE port so that the data message can be sent along its data path. After 1415, process 1400 terminates.

[0171] When process 1400 determines (at 1410) that the connection state cache 225 does not store a record for the stream of received data messages, process 1400 identifies (at 1420) one or more context attributes of this data message stream. As mentioned above, the service engines in different embodiments perform this operation in different ways. For example, in some embodiments, firewall engine 128 checks attribute mapping storage 223 to find a record with a record identifier that matches the header value (e.g., its 5-tuple identifier) ​​of the received data message. It then uses (at 1420) the set of context attributes of this matching record as the set of context attributes for the received data message stream.

[0172] In other embodiments, firewall engine 128 queries the context engine to obtain a set of context attributes for the received data message. Using this query, the firewall engine supplies the flow identifier (e.g., a 5-tuple identifier) ​​or its associated service token for the received message. The context engine then uses the message's flow identifier or its associated service token to identify the set of context attributes in its context attribute storage device 145, as explained above.

[0173] Once process 1400 has obtained the set of context attributes for the received data message, it uses this set of attributes, along with other identifiers for the message, to identify (at 1425) the firewall rules in firewall rule data repository 140 for use with the received data message at 1405. For example, in some embodiments, the firewall rule has a rule identifier 705, defined based on one or more of the five-tuple attributes and one or more context attributes (such as application name, application version, user ID, group ID, AppID, threat level, resource consumption level, etc.). To identify the firewall rules in firewall rule data repository 140, in some embodiments, the process compares the context attributes and / or other attributes (e.g., the five-tuple identifier) ​​of the received data message with the rule identifier of the firewall rule (e.g., rule identifier 705) to identify the highest priority rule with an identifier that matches the set of attributes of the message.

[0174] In some embodiments, the process uses a different set of message attributes to perform the comparison operation. For example, in some embodiments, the message attribute set includes one or more of other five-tuple identifiers (e.g., one or more of source IP, source port, destination port, and protocol) and one or more context attributes. In some embodiments, the message attribute set includes logical network identifiers, such as Virtual Network Identifier (VNI), Virtual Distributed Router Identifier (VDRI), logical MAC address, logical IP address, etc.

[0175] After identifying the firewall rule (at 1425), it executes (at 1430) the firewall action (e.g., allow, drop, reroute, etc.) for the received data message. Assuming the firewall action does not require dropping the data message, process 1400 sends the processed data message along its data path (at 1430). In some embodiments, this operation requires returning communication to SFE port 260 (which invokes the firewall engine to initiate process 1400) to instruct the firewall engine to complete its processing of the VM data message. SFE port 260 can then switch the data message to the SFE or VM, or it can invoke another service engine in the I / O chain operators to perform another service operation on the data message.

[0176] When a firewall action performed at port 1430 results in the dropping of a data message, process 1400 notifies SFE port 260 of this action (at port 1430). Furthermore, when a firewall action performed at port 1430 requires rerouting of the data message, process 1400 performs network address translation (at port 1430) for the data message to enable this rerouting, and then returns the data message (at port 1430) to the SFE port so that the data message can be sent along its data path.

[0177] After performing the firewall action at 1430, the process creates a record (at 1435) in the connection state cache storage device 225. This record identifies the firewall action of the received data message stream. In some embodiments, this record has a record identifier defined by referencing the identifier of the data message stream (e.g., its 5-tuple identifier). After 1435, the process ends.

[0178] As mentioned above, in some embodiments, the management server interacts with the discovery engine 120, which runs on host 200 in the data center, to obtain and refresh an inventory of all processes and services running on VMs on the host. In some embodiments, the management server (also referred to above and below as the management plane) then provides a rule creation interface that allows administrators to create context-based firewall rules and / or policies for firewall engine 128 (and service rules for other service engines 130). The rule creation interface allows administrators to define advanced firewall policies based on applications stored in the database collected by discovery engine 120 and context attributes collected by context engine 110 and by the management plane interface with other management server clusters.

[0179] Once advanced firewall policies (and other service policies) are defined in the management plane, the management plane directly provides some or all of these policies to management agents (not shown) on host 200, and / or indirectly to these agents through a set of controllers (e.g., network controllers). In some embodiments, the management agent publishes the received policies as rules to context-based service rule store 140. In some embodiments, the agent transforms these policies before publishing them to context-based service rule store 140. For example, in some embodiments, policies are published with AppliedTo tuples that identify the service nodes and / or logical networks they are associated with. In some of these embodiments, the management agent on the host removes the AppliedTo tuple from each service policy before pushing the policies as service rules to service rule store 140. Moreover, as mentioned above, in some embodiments, the context engine 110 on host 200 parses the policies based on collected context attributes to generate rules for the service engine.

[0180] Encryption engine 124 is a context-based encryptor that performs its encryption / decryption operations based on encryption rules, which can be specified not only according to L2-L4 parameters but also according to context attributes. Figure 15An example of such context-based encryption rules is illustrated. These rules are used independently by different encryption engines 124 on different hosts 200 to encrypt / decrypt data messages sent and received by VMs 205 on these hosts. In this way, encryption engines 124 enforcing the same encryption rules on different hosts (e.g., for a tenant or a logical network) collectively form a distributed encryption engine (i.e., a single conceptual logical encryption engine) that spans multiple hosts to uniformly perform the desired encryption and decryption operations. In some embodiments, each VM 205 has its own encryption engine, while in other embodiments, one encryption engine 124 may serve multiple VMs 205 on the same host (e.g., for multiple VMs of the same tenant on the same host).

[0181] Figure 15 The diagram illustrates an encryption rule data repository 140 storing several encryption rules. Each encryption rule includes (1) a rule identifier 1505, (2) an encryption type identifier 1510, and (3) a key identifier 1515. Each rule identifier 1505 specifies one or more data tuples that can be used to identify a rule that matches a data message stream. In some embodiments, the rule identifier may include any L2-L4 parameters (e.g., source IP address, source port, destination port, destination IP, protocol, etc.). In some embodiments, these L2-L4 parameters may be defined in a physical domain or a logical domain. Moreover, as shown, the rule identifier may include contextual attributes such as AppID, application name, application version, user ID, group ID, threat level, and resource consumption.

[0182] In some embodiments, the encryptor 124 searches the encryption rule data repository 140 to identify the highest priority rule with a matching rule identifier by comparing one or more message attributes (e.g., 5-tuple header values, context attributes) with the rule identifier 1505. Furthermore, in some embodiments, the encryption rule data repository 140 has a default rule used when no other rule matches the data message stream. In some embodiments, the default rule does not specify an encryption key because no rule exists for encrypting the data message stream. Moreover, in some embodiments, when the default rule is returned to the encryptor 124, the encryptor 124 does not encrypt the data message stream it is currently inspecting.

[0183] The encryption type 1510 of each encryption rule specifies the type of encryption / decryption to be used, while the key identifier 1515 of each rule identifies the key used for encryption / decryption. In some embodiments, the encryption rule only specifies the key identifier 1515 and does not specify the encryption type 1510, because the key identifier identifies both the key and the type of encryption / decryption, or these types are otherwise specified in the encryptor (e.g., pre-configured).

[0184] Now refer to Figure 16-18 The encryption and decryption operations of encryption engine 124 are described. In some embodiments, the encryption and decryption operations use the same key or a transpose of the same key, because these embodiments use symmetric encryption schemes, where the same key is used to encrypt and decrypt messages, or a transpose of the same key is used to encrypt and decrypt messages. Other embodiments use asymmetric encryption schemes (e.g., a source encryptor using its private key and a destination encryptor using the public key of the source encryptor).

[0185] Figure 16 The illustration depicts a process 1600 performed by encryptor 124 to encrypt a data message sent by VM 205 on host 200. As shown, process 1600 begins when encryptor 124 receives a data message from its corresponding SFE port 260 (at 1605). This port relays the data message upon receiving it from its VM. In some embodiments, the port relays the data message by passing a reference to the data message or the header value of the data message (e.g., a handle identifying the location in memory where the data message is stored) to the encryptor.

[0186] Next, at 1610, the encryptor determines whether its connection state cache 225 stores a cached encryption record for the received data message. In some embodiments, each time the encryptor finds an encryption rule for the VM data message, it creates a cached encryption record in the connection state cache 225, which stores the encryption rule, a reference to the encryption rule, an encryption key, and / or an identifier of the encryption key.

[0187] The encryptor creates this cache record so that when it receives another data message for the same data message stream, the encryptor does not need to search the encryption rule data repository 140 to identify the encryption rule for the subsequently received data message in the same stream. In some embodiments, each cached record in the connection state cache 225 has a record identifier defined according to the data message identifier (e.g., a 5-tuple identifier). In these embodiments, the process 1600 compares the identifier of the received data message (e.g., a 5-tuple identifier) ​​with the record identifier of the cached record to identify any record with a record identifier that matches the identifier of the received data message.

[0188] When process 1600 identifies (at 1610) a cached encrypted record of a received data message in connection state cache 225, the process (at 1615) then uses the key identified by the identified encrypted record to encrypt the received data message. In embodiments where the cached record contains encryption rules or references to encryption rules, process 1600 retrieves a key identifier from the stored or referenced rules and uses this identifier to retrieve a key from a key data repository stored on host 200 or from a key manager located on or outside the host. Similarly, in embodiments where the cached record contains a key identifier, process 1600 retrieves the key identifier from the cached record and uses this identifier to retrieve a key from a local or remote key data repository or key manager.

[0189] In some embodiments, the process encrypts (at 1615) the payload of the data message (e.g., the L2 payload) using an identified encryption key, while generating some or all of the integrity check value (ICV) hash of the payload and header values ​​(e.g., physical L3 and L4 header values ​​and / or logical L2 or L3 header values) so that the destination of the message will (1) decrypt the encrypted portion of the data message and (2) verify the authenticity and integrity of the payload and header values ​​used for ICV calculation.

[0190] For some or all of the data messages, in some embodiments, encryption process 1600 also encrypts (at 1615) a portion of the data message header. For data messages exchanged between machines associated with a logical network, some embodiments encrypt all physical header values ​​of the data message. Some of these embodiments perform ICV operations on the logical network identifier (e.g., VNI) and payload, enabling a decryptor at the destination host to verify the authenticity and integrity of the encrypted data message.

[0191] Following the encryption of the data message, the process (at 1615) sends the encrypted data message along its data path. In some embodiments, this operation requires returning communication to SFE port 260 (which invokes the encryptor to initiate process 1600) to inform the port that the encryptor has completed its processing of the data message. SFE port 260 can then either hand the data message over to SFE 210 or invoke another I / O chain operator to perform another operation on the data message. After 1615, process 1600 ends.

[0192] When process 1600 determines (at 1610) that the connection state cache 225 does not store any cached record matching the received data message, process 1600 identifies (at 1620) one or more context attributes of the data message stream. As mentioned above, the service engines of different embodiments perform this operation in different ways. For example, in some embodiments, the encryption engine 124 checks the attribute mapping storage device 223 to find a record with a record identifier that matches the header value (e.g., its 5-tuple identifier) ​​of the received data message. It then uses (at 1620) the context attribute set of this matching record as the context attribute set of the received data message stream.

[0193] In other embodiments, the encryption engine 124 queries the context engine 110 to obtain a set of context attributes for the received data message. Using this query, the encryption engine supplies the stream identifier (e.g., a 5-tuple identifier) ​​or its associated service token for the received message, and the context engine then uses this identifier to identify the set of context attributes in its context attribute storage device 145, as explained above.

[0194] Once process 600 has obtained the set of context attributes for the received data message, it uses this set of attributes, or along with other identifiers of the message (e.g., a 5-tuple identifier), to identify (at 1625) encryption rules in encryption rule data repository 140 that match the attributes of the received data message. For example, in some embodiments, encryption rules have rule identifiers defined based on one or more of non-context attributes (e.g., 5-tuple attributes, logical attributes, etc.) and / or one or more context attributes (such as application name, application version, user ID, group ID, AppID, threat level, resource consumption level, etc.). To identify encryption rules in encryption rule data repository 140, in some embodiments, the process compares the context attributes and / or other attributes (e.g., the 5-tuple identifier) ​​of the received data message with the rule identifier of the encryption rule (e.g., rule identifier 1505) to identify the highest priority rule with an identifier that matches the set of attributes of the message.

[0195] After step 1625, the process determines (at step 1630) whether it has identified an encryption rule that specifies the received data message should be encrypted. As mentioned above, the encryption rule data repository 140 has a default encryption rule that matches all data messages and returns when no other encryption rule matches the received data message. In some embodiments, the default encryption rule specifies that the received data message should not be encrypted (e.g., specifies a default key identifier corresponding to a non-encrypted operation).

[0196] When process 1600 determines (at 1630) that the data message should not be encrypted, the process sends an unencrypted message along the message's data path (at 1635). This operation 1630 requires notifying its SFE port 260 that it has finished processing the data message. After 1635, the process proceeds to 1645, where it creates a record in the connection-state cache storage 225 indicating that encryption should not be performed on the received data message stream. In some embodiments, this record is addressed in the connection-state cache 225 based on the stream's 5-tuple identifier. After 1645, the process ends.

[0197] When the process determines (at 1630) that the data message should be encrypted, the process then (at 1640) retrieves a key identifier from the identified rules, uses this identifier to retrieve a key from a local or remote key data repository or manager, as described above, and encrypts the received data message with the retrieved key. This encryption of the data message (at 1640) is exactly the same as the encryption operation 1615 described above. For example, as described above, process 1600 encrypts the payload of the data message (e.g., L2 payload) using the identified encryption key, while performing ICV operations on the payload and some or all of the header values ​​(e.g., physical L3 and L4 header values, logical L2 or L3 header values, and / or logical network identifiers, such as VNI and VDRI). For some or all of the data message, in some embodiments, encryption process 1600 also encrypts (at 1640) some or all of the headers of the data message.

[0198] Following the encryption of the data message, the process sends the encrypted data message along its data path (at position 1635). Similarly, in some embodiments, this operation requires returning communication to SFE port 260 so that the port knows the encryptor has completed processing the data message. SFE port 260 can then either hand the data message over to SFE 210 or invoke another I / O chain operator to perform another operation on the data message.

[0199] When the encryption rule identified at 1630 is a rule dynamically created after an event is detected, the encryptor must ensure (at 1640) that the key identifier for the key used to encrypt the data message is included in the data message header before it is sent. Processing 1600 achieves this in different ways in different embodiments. In some embodiments, processing 1600 passes the key identifier (at 1640) to SFE port 260 (which calls it) so that the port or I / O chain operator it calls can insert the key identifier into the data message header. For example, in some embodiments, a service engine (e.g., another I / O chain operator) encapsulates the data message with a tunnel header for establishing an overlay logical network. In some of these embodiments, SFE port 260 passes the key identifier it receives from processing 1600 to this service engine so that it can include the key identifier in its header.

[0200] In other embodiments, process 1600 does not pass the key identifier to the SFE port, and this port does not allow another service engine to encapsulate the key identifier in the tunnel header of the overlay network. In some of these embodiments, SFE port 260 simply allows the service engine to include an indication that the data message is encrypted in the tunnel header of the overlay network. In these embodiments, a decryptor (e.g., encryption engine 124) executing on a host with a destination DCN can identify the correct key for decrypting the data message based on pre-configured information (e.g., a white-box solution that allows the decryptor to select the correct key based on a previous key specified for communication with the source DCN, or based on header values ​​of the data message stream) or based on out-of-band communication with a controller or module on the source host regarding the appropriate key to use.

[0201] After 1640, the process transitions to 1645, where, in the connection-state cache storage device 225, a record is created to store the encryption rule identified at 1625, a reference to that encryption rule, a key identifier specified in that encryption rule, and / or a retrieved key specified by that key identifier. As mentioned above, this cached record has a record identifier, which in some embodiments includes an identifier of the received data message (e.g., a quintuple identifier). After 1645, the process ends.

[0202] Figure 17The illustration shows a process 1700 in which encryption engine 124 performs a process to decrypt encrypted data messages received on the destination host of the destination VM of the data message via SFE port 260 or 265. This encryption engine is referred to below as the decryptor. In some embodiments, the decryptor performs this operation when it calls itself on its corresponding SFE port to check whether the received data message is encrypted, and if so, then decrypts the message.

[0203] In some embodiments, when the SFE port determines that a received data message is encrypted, the SFE port invokes encryption engine 124. For example, in some embodiments, the data message is sent along a tunnel to the destination host, and the header of this tunnel contains an identifier specifying that the data message is encrypted. In some embodiments, the decryptor performs this process only if the header value of the received data message does not specify a key identifier that identifies the key used to decrypt the data message. When the header value does specify such a key identifier, the decryptor uses... Figure 18 The decryption process 1800 will be described below.

[0204] Furthermore, in some embodiments, the received data message has a value (e.g., bits) indicating whether the message is encrypted. By analyzing this value, the decryptor will know whether the message is encrypted. When this value indicates that the message is not encrypted, the decryptor will not invoke process 1700 or 1800 to decrypt the encrypted message. Instead, the decryptor informs the SFE port that it can send data messages along its data path.

[0205] As shown in the figure, process 1700 initially identifies (at 1705) a set of message attributes used to identify the encryption rules applicable to the received data message. In different embodiments, the set of message attributes used to retrieve the rules can be different. For example, in some embodiments, this message-attribute set includes a 5-tuple identifier of the received data message. In some embodiments, this message-attribute set also includes a logical network identifier associated with the received data message.

[0206] After 1705, the decryptor determines (at 1710) whether its encryption state cache 225 stores a cached encryption rule for the message attribute set identified at 1705. Similar to the encryptor, in some embodiments, each time the decryptor finds an encryption rule for a data message, it stores the encryption rule, a reference to the encryption rule, a key identifier for the rule, or the key for the rule in the connection state cache 225 so that when it receives another data message with the same identified message-attribute set (e.g., when it receives another data message as part of the same data stream as the original data message), the decryptor does not need to search one or more encryption rule data repositories to identify encryption rules for subsequently received data messages. As mentioned above, in some embodiments, the connection state cache 225 stores encryption rules based on the quintuple identifier of the data message. Therefore, before searching the encryption rule data repository 140, in some embodiments, the decryptor first determines whether the connection state cache 225 stores a matching cache record for the received data message.

[0207] When process 1700 identifies (at 1710) a matching cache record in connection state cache 225 for a received data message, the process (at 1715) then uses that record to identify a key, which is then used to decrypt the encrypted portion of the received data message. In some embodiments, the cache record includes the key, while in other embodiments, the record includes a key identifier or a rule or reference to a rule containing the key identifier. In later embodiments, the process uses the key identifier in the cache record or a stored or referenced rule to retrieve the key from a local or remote key data repository or manager, and then uses the retrieved key to decrypt the encrypted portion of the received data message.

[0208] In some embodiments, a portion of the decryption operation (at 1715) is the hashing of the data message header and payload generated by the ICV. Specifically, when the encryptor hashes a portion of the received data message (e.g., its physical (e.g., L3 or L4) header value or its logical (e.g., VNI) header value) along with the payload via the ICV operation, the decryption operation verifies this portion to verify the authenticity and integrity of the encrypted data message.

[0209] After decrypting the data message (at 1715), the process (at 1715) sends the decrypted data message along its data path. In some embodiments, this operation requires returning communication to the SFE port (which calls the decryptor to initiate process 1700) so that the port knows the decryptor has completed its processing of the data message. The SFE port can then either allow the data message to reach its destination VM or call another I / O chain operator to perform another operation on the data message. After 1715, process 1700 ends.

[0210] When process 1700 determines (at 1710) that the connection state cache 225 does not store encryption rules for the attribute set identified at 1705, process 1700 searches (at 1720) the encryption rule data repository 140 to identify encryption rules for the received data message. In some embodiments, the destination host receives out-of-band communication from the source host (directly or via a set of controllers), which provides the destination host with data from which it can identify a key identifier, or encryption rules with the key identifier, for decrypting encrypted data messages. In some of these embodiments, the out-of-band communication includes an identifier for the data message (e.g., a quintuple identifier).

[0211] In other embodiments, the encryption engine 124 on the destination host identifies the correct key for decrypting the data message based on pre-configured information. For example, in some embodiments, the encryption engines 124 on both the source and destination hosts use a white-box solution that either (1) iterates through each encryption key according to a pre-configured scheme, or (2) selects an encryption key based on attributes of the data message (e.g., a 5-tuple identifier). By making the source and destination encryption engines follow the same scheme to iterate through or select encryption keys, the white-box solution ensures that the encryption engine at the encryption unit 124 on the destination host can select the same encryption key used by the encryption unit 124 on the source host to decrypt the received data message.

[0212] When process 1700 cannot find an encryption rule for the identified key, in some embodiments, process 1700 initiates an error handling process to resolve the unavailability of the decryption key used to decrypt the encrypted message. In some embodiments, this error handling process queries a network agent to determine whether it or the controller set stores an encryption rule for the message attribute set identified at 1705. When the agent has such an encryption rule, it provides it to the process (at 1720). However, in other embodiments, the error handling process does not contact the network agent to obtain the key. Instead, it simply flags the problem for administrator resolution.

[0213] When the process identifies (at 1720) a key identifier or an encryption rule with a key identifier, the process (at 1725) retrieves a key from a local or remote key data repository or manager using the key identifier, and decrypts the received data message with the retrieved key. In some embodiments, a portion of the decryption operation (at 1725) is used to authenticate the hash of the data message header and payload generated by the ICV. Specifically, when a portion of the received data message (e.g., its physical (e.g., L3 or L4) header value or its logical (e.g., VNI) header value) is hashed by the encryptor along with the payload through the ICV operation, the decryption operation verifies this portion to verify the authenticity and integrity of the encrypted data message.

[0214] After decrypting the data message, the process (from 1725) sends the decrypted data message along its data path. In some embodiments, this operation requires returning communication to the SFE port (which calls the decryptor to initiate process 1700) so that the port knows the decryptor has completed its processing of the data message. The SFE port can then either allow the data message to reach its destination VM or call another I / O chain operator to perform another operation on the data message.

[0215] After 1725, the process proceeds to 1730, where, in the link-state cache storage 225, a record is created to specify either a decryption key or an identifier of that key that should be used to decrypt a data message (e.g., to decrypt a data message that is part of the same stream as the received data message) using a set of message attributes similar to the set identified at 1705. In some embodiments, this record is addressed in the link-state cache storage 225 based on the quintuple identifier of the received data message. After 1730, the process ends.

[0216] In some embodiments, the header value (e.g., tunnel header) of the received encrypted data message stores a key identifier that identifies the key used to decrypt the data message. The encryption engine 124 on the host device then performs its decryption operation using the key identified by the key identifier. Figure 18 The illustration depicts a process 1800 performed by encryption engine 124 to decrypt an encrypted data message whose header includes a key identifier. In some embodiments, this operation is performed when a decryptor in encryption engine 124 calls itself on its corresponding SFE port 260 or 265 to check whether a received data message is encrypted, and if so, decrypts the message. In some embodiments, the decryptor performs this process only if the header value of the received data message specifies a key identifier that identifies the key used to decrypt the data message.

[0217] As shown in the figure, process 1800 initially extracts the key identifier (at 1805) from the received data message. Next, the process uses the key identifier (at 1810) to retrieve a key from a local key data repository / manager on the destination host or a remote key data repository / manager not on the destination host, and then uses this key (at 1815) to decrypt the received data message. As mentioned above, part of the decryption operation (at 1815) is authenticating the hash (of the header and payload of the received data message) generated by the ICV encrypted with the payload of the data message. In some embodiments, process 1800 stores the key in a cached data repository 225, so that it does not need to recognize this key for other data messages in the same data message stream as the received data message.

[0218] After decrypting the data message, the process sends the decrypted data message along its data path (at 1820). In some embodiments, this operation requires returning communication to the SFE port (which calls the decryptor to initiate process 1800) so that the port knows the decryptor has completed its processing of the data message. The SFE port can then either allow the data message to reach its destination VM or call another I / O chain operator to perform another operation on the data message. After 1820, process 1800 ends.

[0219] Because it uses context attributes to define the rule identifiers for encryption rules, the context-based encryptor 124 can distribute data message streams based on any number of context attributes. Examples of such encryption operations, as mentioned above, include: (1) encrypting all traffic from Outlook (started on any machine) to Exchange Server, (2) encrypting all communication between applications in the Tier 3 web server, application server, and database server, (3) encrypting all traffic originating from the administrator's Active Directory group, and so on.

[0220] As mentioned above, in some embodiments, the management server interacts with the discovery engine 120, which runs on host 200 in the data center, to obtain and refresh the inventory of all processes and services running on VMs on the host. Then, in some embodiments, the management plane provides a rule creation interface that allows administrators to create context-based encryption rules and / or policies (and service rules for other service engines 130) for encryption engine 124. The rule creation interface allows administrators to define advanced encryption policies (and other service policies) based on the application inventory collected through the discovery engine 120 and contextual attributes collected by the context engine 110 and the management plane's interfaces with other management server clusters.

[0221] Once advanced encryption policies (and other service policies) are defined in the management plane, the management plane directly supplies some or all of these policies to management agents (not shown) on host 200, and / or indirectly supplies some or all of these policies to these agents through a set of controllers (e.g., network controllers). In some embodiments, the management agent publishes the received policies as rules to a context-based service rule store 140. In some embodiments, the agent transforms these policies before publishing them to the context-based service rule store 140. For example, in some embodiments, policies are published with AppliedTo tuples that identify the service nodes and / or logical networks they are associated with. In some of these embodiments, the management agent on the host removes the AppliedTo tuple from each service policy before pushing the policies as service rules to the service rule store 140. Moreover, as mentioned above, in some embodiments, the context engine 110 on host 200 parses the policies based on collected context attributes to generate rules for the service engine.

[0222] Processing control (PC) engine 122 is a context-based PC engine that performs its PC operations based on PC rules that can be specified according to context attributes. Figure 19 Several examples of such PC rules are illustrated. This figure illustrates a PC rule data repository 140 of some embodiments. As shown, each PC rule includes a rule identifier 1905 and a PC action 1910. In some embodiments, PC action 1910 may be (1) allow, (2) stop and disallow, or (3) stop and terminate.

[0223] Each rule identifier 1905 specifies one or more data tuples that can be used to identify rules that match a data message stream. As shown, the rule identifier may include contextual attributes such as AppID, application name, application version, user ID, group ID, threat level, resource consumption, etc. In some embodiments, the PC engine searches the PC data storage device by comparing one or more message attributes (e.g., contextual attributes) with the rule identifier 1905 to identify the highest priority rule with a matching rule identifier. In some embodiments, the rule identifier 1905 may also include L2-L4 parameters (e.g., a quintuple identifier) ​​associated with the data message stream, and the PC engine performs its PC operations on a per-stream basis. In other embodiments, the PC engine 122 performs its PC operations only for processing events, leaving that to the firewall engine 128 to perform PC operations on a per-stream basis. Thus, in some embodiments, the rule identifier 1905 for PC rules used by the PC engine does not include any L2-L4 parameters.

[0224] In some embodiments, different PC engines 122 on different hosts enforce the same set of PC rules. For example, in some embodiments, different PC engines 122 process the same PC rules on different hosts for VMs in a logical network in order to provide a level of security for processing running on these VMs. For this logical network, these PC engines 122 collectively form a distributed PC engine (i.e., a single conceptual logical PC engine) spanning multiple hosts.

[0225] Figure 19 Three detailed examples of context-based PC rules from some embodiments are illustrated. The first rule, 1920, specifies that Skype version 1024 should be stopped and disabled. In some embodiments, each time the PC engine 122 identifies a new processing event, it identifies the event's context attributes by interacting with the context engine or by examining records in its attribute mapping storage device 223 to identify records that specify context attributes for the processing identifier.

[0226] Rule 1925 specifies that all processes with a high threat level should be stopped and disallowed. As mentioned above, the context engine 110 or service engine 130 may interact with the threat detector 132 to assess the threat level associated with the process. In some embodiments, the threat detector generates a threat score, where the context engine, PC engine, or other service engine quantifies the threat into one of several categories. For example, in some embodiments, the threat detector generates a threat score from 0 to 100, and one of the engines 110 or 130 designates a score between 0 and 33 as a low threat level, a score between 34 and 66 as a medium threat level, and a score between 67 and 100 as a high threat level.

[0227] The third rule, 1930, specifies that all processing that generates YouTube traffic should be stopped and terminated. In some embodiments, this rule is enforced by the PC engine, while in other embodiments, a similar rule is enforced by the firewall engine. When the firewall engine enforces such a rule, it enforces it on a per-flow basis, and its action is to drop packets associated with that flow. The PC engine can enforce this rule when inspecting processing events, or when SFE port 260 calls it to perform a PC inspection on a specific flow.

[0228] Figure 20 The illustration depicts process 2000 executed by PC engine 122 in some embodiments. As shown, process 2000 begins when the PC engine receives a process identifier (at 2005) from context engine 110. The context engine relays this process ID when it receives a process notification from GI agent 250 on VM 205.

[0229] Process 2000 determines (at 2010) whether the connection state cache 225 stores a record identifying a PC action used for a received processing ID. Each time the PC engine uses PC rules to process a new processing identifier, in some embodiments, the PC engine creates a record in the connection state cache 225 to store the executed PC action, so that it can subsequently rely on this cache to process the same processing identifier more quickly. In some embodiments, each cached record in the connection state cache 225 has a record identifier defined according to the processing identifier. In these embodiments, the process compares the received identifier with the record identifier of the cached record to identify any record having a record identifier that matches the received processing identifier.

[0230] When process 2000 identifies a record of a received processing event in the connection state cache 225 (at 2010), the process (at 2015) then executes the PC action specified in that record. If this action is disallowed or terminated, the PC engine instructs the context engine 110 to disallow or terminate the processing. To do this, the context engine 110 instructs the GI agent that reported the event to disallow or terminate the processing. The GI agent then instructs the OS's processing subsystem to disallow or terminate the processing. After 2015, process 2000 terminates.

[0231] When process 2000 determines (at 2010) that the connection state cache 225 does not store a record of the received processing identifier, process 2000 identifies (at 2020) one or more context attributes of this processing identifier. As mentioned above, the service engines in different embodiments perform this operation in different ways. In some embodiments, the PC engine instructs the context engine to collect additional processing attributes of the received processing events, and the context engine collects this information by interacting with the GI agent.

[0232] Once process 2000 has obtained the set of context attributes for the received data message, it uses this set of attributes to identify (at 2025) the PC rules in the PC rule data repository 140. In some embodiments, the PC rule has a rule identifier 1505 defined based on one or more context attributes, such as application name, application version, user ID, group ID, AppID, threat level, resource consumption level, etc. To identify the PC rule in the data storage device 140, in some embodiments, the process compares the collected context attributes with the rule identifier of the PC rule (e.g., rule identifier 1905) to identify the highest priority rule with an identifier that matches the collected set of attributes.

[0233] When the process recognizes a PC rule (at 2025), it executes the PC action of that rule (e.g., allow, stop and disallow, stop and terminate, etc.) on the received processing event. When the operation is disallowed or terminated, the PC engine instructs the context engine 110 to disallow or terminate the processing. To do this, the context engine 110 instructs the GI agent that reported the event to disallow or terminate the processing. The GI agent then instructs the OS's processing subsystem to disallow or terminate the processing. After executing the PC action at 2030, the process creates a record in the connection state cache storage device 225 (at 2035). This record identifies the PC action of the received processing event. After 2035, the processing ends.

[0234] As mentioned above, in some embodiments, the management server interacts with the discovery engine 120, which runs on host 200 in the data center, to obtain and refresh the inventory of all processes and services running on VMs on the host. Then, in some embodiments, the management plane provides a rule creation interface that allows administrators to create context-based PC rules and / or policies (and service rules for other service engines 130) for PC engine 122. The rule creation interface allows administrators to define advanced PC policies (and other service policies) based on the application of the inventory collected through discovery engine 120 and context attributes collected by context engine 110 and the management plane's interfaces with other management server clusters.

[0235] Once advanced PC policies (and other service policies) are defined in the management plane, the management plane directly provides some or all of these policies to management agents (not shown) on host 200, and / or indirectly provides some or all of these policies to these agents through a set of controllers (e.g., network controllers). In some embodiments, the management agent publishes the received policies as rules to the context-based service rule store 140. In some embodiments, the agent transforms these policies before publishing them to the context-based service rule store 140. Moreover, as mentioned above, in some embodiments, the context engine 110 on host 200 parses the policies based on collected context attributes in order to generate rules for the service engine.

[0236] Figure 21The diagram illustrates an example of how service engine 130 is managed in some embodiments. This diagram illustrates multiple hosts 200 in a data center. As shown, each host includes several service engines 130, a context engine 110, a threat detector 132, a DPI module 135, several VMs 205, and SFEs 210. It also illustrates a controller set 2110 for managing service engines 130, VMs 205, and SFEs 210. As mentioned above, in some embodiments, context engine 110 collects context attributes passed to a management server in the controller set via network 2150 (e.g., via a local area network, wide area network, network of networks (e.g., the Internet)). The controller set provides a user interface for administrators to define context-based service rules based on these collected context attributes and communicates with hosts via network 2150 to provide these policies. Hosts are also communicatively connected to each other via this network 2150.

[0237] Many of the aforementioned features and applications are implemented as software processing, which is specified as a set of instructions recorded on a computer-readable storage medium (also known as a computer-readable medium). When these instructions are executed by one or more processing units (e.g., one or more processors, processor cores, or other processing units), they cause that processing unit(s) to perform the actions indicated in the instructions. Examples of computer-readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard disk drives, EPROMs, etc. Computer-readable media do not include carrier waves and electronic signals transmitted wirelessly or via wired connections.

[0238] In this specification, the term "software" refers to firmware residing in read-only memory or an application stored in a magnetic storage device that can be read into memory for processing by a processor. Furthermore, in some embodiments, multiple software inventions may be implemented as sub-parts of a larger program while maintaining a distinct software invention. In some embodiments, multiple software inventions may also be implemented as separate programs. Finally, any combination of separate programs that together implement the software inventions described herein is within the scope of this invention. In some embodiments, when a software program is installed to operate on one or more electronic systems, the software program defines one or more specific machine implementations that run and perform the operations of the software program.

[0239] Figure 22A computer system 2200 implementing some embodiments of the present invention is conceptually illustrated. The computer system 2200 can be used to implement any of the aforementioned host, controller, and manager. Therefore, it can be used to perform any of the aforementioned processes. The computer system includes various types of non-transitory machine-readable media and interfaces for various other types of machine-readable media. The computer system 2200 includes a bus 2205, one or more processing units 2210, system memory 2225, read-only memory 2230, permanent storage device 2235, input device 2240, and output device 2245.

[0240] Bus 2205 uniformly represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of computer system 2200. For example, bus 2205 communicatively connects one or more processing units 2210 to read-only memory 2230, system memory 2225, and permanent storage device 2235.

[0241] From these various memory units, one or more processing units 2210 retrieve instructions to be executed and data to be processed in order to perform the processing of the present invention. The one or more processing units may be a single processor or a multi-core processor in different embodiments. Read-only memory (ROM) 2230 stores static data and instructions required by the one or more processing units 2210 and other modules of the computer system. On the other hand, permanent storage device 2235 is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the computer system 2200 is turned off. Some embodiments of the present invention use mass storage devices (such as magnetic or optical discs and their corresponding disk drives) as permanent storage device 2235.

[0242] Other embodiments use removable storage devices (such as floppy disks, flash drives, etc.) as permanent storage devices. Like permanent storage device 2235, system memory 2225 is a read-write memory device. However, unlike storage device 2235, system memory is volatile read-write memory, such as random access memory. System memory stores some instructions and data required by the processor during operation. In some embodiments, the processing of the present invention is stored in system memory 2225, permanent storage device 2235, and / or read-only memory 2230. From these various memory units, processing unit(s) 2210 retrieves instructions to be executed and data to be processed in order to perform the processing of some embodiments.

[0243] Bus 2205 is also connected to input and output devices 2240 and 2245. Input devices enable users to pass information and select commands from the computer system. Input device 2240 includes an alphanumeric keypad and a pointing device (also known as a "cursor control device"). Output device 2245 displays images generated by the computer system. Output devices include printers and display devices such as cathode ray tube (CRT) or liquid crystal display (LCD). Some embodiments include devices such as touchscreens that serve as both input and output devices.

[0244] Finally, as Figure 22 As shown, bus 2205 also couples computer system 2200 to network 2265 via a network adapter (not shown). In this way, the computer can be part of a network of computers (such as a local area network (“LAN”), a wide area network (“WAN”), or an intranet, or a network of networks such as the Internet), and any or all components of computer system 2200 can be used in conjunction with the present invention.

[0245] Some embodiments include electronic components such as microprocessors, storage devices and memories that store computer program instructions in machine-readable or computer-readable media (which may alternatively be referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Examples of such computer-readable media include RAM, ROM, read-only discs (CD-ROM), recordable discs (CD-R), rewritable discs (CD-RW), read-only digital multifunction discs (e.g., DVD-ROM, dual-layer DVD-ROM), various recordable / rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, miniature SD cards, microSD cards, etc.), magnetic and / or solid-state hard disk drives, read-only and recordable Blu-ray discs... Disks, high-density optical discs, any other optical or magnetic media, and floppy disks. Computer-readable media can store computer programs that are executable by at least one processing unit and include a set of instructions for performing various operations. Examples of computer programs or computer code include machine code generated by a compiler, and files that include higher-level code executed by a computer, electronic components, or a microprocessor utilizing an interpreter.

[0246] While the above discussion primarily refers to microprocessors or multi-core processors that execute software, some embodiments are executed by one or more integrated circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions stored on the circuit itself.

[0247] As used herein, the terms “computer,” “server,” “processor,” and “memory” refer to electronic or other technical devices. These terms do not include people or groups of people. For the purposes of this specification, the terms “displayed” or “being displayed” mean displayed on an electronic device. As used herein, the terms “computer-readable medium,” “multiple computer-readable media,” and “machine-readable medium” are strictly limited to tangible, physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, or any other transient or temporary signals.

[0248] While the invention has been described with reference to many specific details, those skilled in the art will recognize that the invention may be embodied in other specific forms without departing from its spirit. For example, several figures conceptually illustrate the processes. Specific operations of these processes may not be performed in the exact order shown and described. Specific operations may not be performed in a series of consecutive operations, and different specific operations may be performed in different embodiments. Furthermore, a process may be implemented using several subprocesses or as part of a larger macroprocess. Therefore, those skilled in the art will understand that the invention is not limited to the foregoing illustrative details but is defined by the appended claims.

Claims

1. A method for supporting context-based services on a host computer, wherein multiple machines and one or more service engines are executed on the host computer, the method comprising: At the context collector running on the host computer: Collect and store the contextual properties of events that occur on a set of machines; Receive the identifier associated with the event from the group of service engines; The received identifier is used to identify the set of context attributes stored by the context collector, which is then provided to the group of service engines for processing the data message stream associated with the event.

2. The method according to claim 1, further comprising: For one of the events, a specific service rule is generated for a specific service engine, and the specific service engine uses the specific service rule to perform a service operation on at least one data message stream.

3. The method of claim 2, wherein generating the specific service rule includes instructing the specific service engine to generate the service rule.

4. The method of claim 2, wherein generating the specific service rule comprises generating the specific service rule at the context collector and providing the generated service rule to the specific service engine.

5. The method of claim 1, wherein the received identifier includes a data message stream identifier, and using the data message stream identifier includes matching the data message stream identifier to match an attribute associated with a set of collected context attributes stored by the context collector.

6. The method of claim 1, wherein each service engine uses a provided set of context attributes to identify service rules, the service rules specifying the service operation that the service engine must perform on a data message stream processed by the service engine.

7. The method of claim 1, wherein the received identifier is a token, each token identifying a different subset of the collected context data.

8. The method according to claim 7, further comprising: The token is generated and provided to the machine for transmission along with the data message forwarded by the machine. The service engine provides the token to the context collector to receive any context attributes related to the data message processed by the service engine.

9. The method of claim 1, wherein the event includes a new network connection event.

10. The method of claim 1, wherein the event includes a new process event.

11. The method of claim 1, wherein collecting the set of context attributes comprises: Receive at least one subset of the set of context attributes from a client introspection agent that runs on two or more machines.

12. The method of claim 1, wherein collecting the set of context attributes includes receiving a set of context attributes having an identifier of an associated stream.

13. The method of claim 1, wherein each of the plurality of context attribute sets includes one or more attributes other than the layer 2 (L2), layer 3 (L3), and layer 4 (L4) data message header values.

14. A method for supporting context-based services on a host computer, wherein multiple machines and one or more service engines are executed on the host computer, the method comprising: At the context collector running on the host computer: Collect and store the contextual properties of events that occur on a set of machines; The service engines are provided with a set of context attributes stored by the context collector for the service engines to use in processing data message streams associated with the event; For one of the events, a specific service rule is generated for a specific service engine, and the specific service engine uses the specific service rule to perform a service operation on at least one data message stream.

15. The method of claim 14, wherein generating the specific service rule includes instructing the specific service engine to generate the service rule.

16. The method of claim 14, wherein generating the specific service rule comprises generating the specific service rule at the context collector and providing the generated service rule to the specific service engine.

17. The method of claim 14, wherein providing the set of context attributes comprises: Receive data message stream identifiers from this group of service engines; Match the data message stream identifier with the set of collected context attributes stored by the context collector; In response to the received data message stream identifier, a matching set of context attributes is provided to the group of service engines. Each service engine uses the set of context attributes to identify service rules that specify the service operation that the service engine must perform on the data message stream processed by the service engine.

18. The method of claim 14, wherein providing the set of context attributes includes providing a mapping record to the group of service engines, the mapping record mapping the collected set of context attributes to data message stream identifiers, each service engine matching an identifier of a data message stream processed by the service engine with one or more mapping records to identify a set of context attributes associated with the processed data message stream, and using the identified set of context attributes to identify service rules specifying service operations that the service engines must perform on the data message streams processed by the service engines.

19. The method of claim 14, wherein the event includes a new network connection event.

20. The method of claim 14, wherein the event includes a new process event.

21. The method of claim 14, wherein collecting the set of context attributes comprises receiving at least one subset of the set of context attributes from a client introspection agent executed on two or more machines.

22. A machine-readable medium storing a program that, when executed by at least one processing unit, implements the method according to any one of claims 1-21.

23. An electronic device, comprising: A set of processing units; and A machine-readable medium storing a program that, when executed by at least one of the processing units, performs the method according to any one of claims 1-21.

Images