num="0000">Ip-Domain Table

IP-Domain table 180 is used to ensure that FQDN rules are properly applied to packets even though the rules may be dynamically and frequently updated in firewall policy 190. Specifically, IP-Domain table 180 is used to ensure that a mapping, stored in an expression table 170 (described in detail later), between FQDN expressions and corresponding IDs is reliable even if the rules stored in firewall policy 190 are repeatedly modified. It should be noted that IP-Domain table 170 may also be implemented as any other type of data structure, not necessarily a table.

IP-Domain table 180 may represent a mapping between IP addresses, domain names and expression IDs used in FQDN rules implemented in a firewall. Entries in IP-Domain table 180 may be first populated when DNS packets to resolve the IP addresses are detected, and then validated each time when a new connection to any of the resolved IP addresses is established by a host computer.

IP-Domain table 180 may have associated a global version number. Initially, the global version number may be set to 1, or any other initial value. The global version number may be advanced, e.g., incremented or decremented (and eventually reset if it reaches a certain threshold value), each time any of the rules in firewall policy 190 is modified.

IP-Domain table 180 may include a plurality of entries, and each entry in table 180 may have associated an entry version number. Initially, an entry version number for each entry may be set to 1, or any other initial value. As described later, an entry version number of a particular entry in IP-Domain table 180 may be compared with a global version number of IP-Domain table 180 to determine whether a particular FQDN expression entry in expression table 170 needs to be updated so that the rule that relies on the particular FQDN expression is properly applied to packets.

An example of the already-populated IP-Domain table 180 is shown in FIG. 1A. The example is provided herein to merely illustrate a simple table 180 and is not meant to be limiting in any way. The already populated entries include: “IP Address 1: *goo.com ID1 Version 1,” “IP Address 2: *face.com ID2 Version 1,” “IP Address 3: *abc.com ID3 Version 1,” and “IP Address 4: *xyz.com ID4 Version 1.” An example process of populating IP-Domain table 180 is described in FIG. 1B.

Populating an IP-Domain Table

FIG. 1B is an example flow chart for populating an IP-Domain table. As described above, entries in IP-Domain table 180 may be first populated when DNS packets to resolve the IP addresses for domains are detected. IP-Domain table 180 may be populated by, for example, a local manager 152 executing on host 110. In some embodiments, local manager 152 may be executing in a user space of host 110 (as shown in FIG. 1A). In other embodiments (not shown), a local manager may be implemented in hypervisor 101. For example, a local manager may be implemented in policy engine 102 of hypervisor 101, or as an agent implemented in hypervisor 101 and cooperating with policy engine 102.

Suppose that a request to access the domain having a domain name http://www.xyz.com/ is sent by data compute node 120 to a DNS server (not shown). Upon receiving the request, the DNS server resolves the domain name to an IP address. Continuing with our example, the DNS response, also referred to herein as a DNS packet, is from the DNS server addressed to the originating device, e.g., data compute node 120. This DNS packet may include the resolved IP address and the domain name, which can be extracted by hypervisor 101 using a deep packet inspection routine (not shown). The domain name and corresponding IP address are then passed to policy engine 102.

Referring to FIG. 1B, in step 103, a DNS packet is received or intercepted at hypervisor 101. The DNS packet may be a response packet from a DNS server or cache that includes an IP address for a domain name. Continuing with the above example, suppose that the IP address resolved for http://www.xyz.com/is IP_Address_4.

In step 104, policy engine 102, or a slowpath process 140, searches expression table 170 for all expressions that match on the partial domain name xyz.com. As shown in FIG. 1A, expression table 170 includes an entry “expression 4: *xyz.com ID4”, where *xyz.com matches on the partial domain name xyz.com. This is because *xyz.com matches on xyz.com. (The wild card * indicates any character or a string of characters that may precede xyz.com.) An expression identifier that is included in “expression 4: *xyz.com ID4” is the ID4. Hence, the ID4 is an expression identifier that is included in the expression that matches on xyz.com.

Suppose, however, that expression table 170 also includes an entry “expression 10: *yz.com ID7” (not shown) and an entry “expression 11: *z.com ID8” (not shown). Since *yz.com matches on xyz.com, the identifier ID7 would also be recognized as an identifier that is included in an expression that matches on the partial domain name xyz.com. Furthermore, since *z.com also matches on xyz.com, the identifier ID8 would also be recognized as an identifier included in the expression that matches on the partial domain name xyz.com. In this hypothetical example, all three IDs (i.e., ID4, ID7 and ID8) would be recognized as included in the expressions that match on xyz.com.

However, for the clarity of the description, let us assume that expression table 170 includes only expressions 1-4, and does not include expressions 7-8. Hence, the ID that is included in the expression that matches on xyz.com is only the ID4.

In step 106, the agent populates, in IP-Domain table 180, an entry for IP_Address_4, and includes, in that entry, IP_Address_4, the expression (taken from expression table 170) that has the ID4, and the ID4. Hence, the populated entry includes IP_Address_4, *xyz.com, ID4.

In step 108, an entry version number for the entry in IP-Domain table 180 is determined and added to the entry in IP-Domain table 180. Since the entry is being populated, not updated, the entry version number will correspond to the global version number of IP-Domain table 180. Continuing with our example, since the global version number of IP-Domain table 180 is 1, the entry version number for the populated entry in IP-Domain table 180 is also 1. Thus, the populated entry now includes IP_Address_4, *xyz.com, IP4, Version 1.

Entries for other IP addresses are populated in IP-Domain table 180 using the same approach as the approach described above. Continuing with our example, the populated IP-Domain table 180 will include “IP Address 1: *goo.com ID1 Version 1,” “IP Address 2: *face.com ID2 Version 1,” “IP Address 3: *abc.com ID3 Version 1,” and “IP Address 4: *xyz.com ID4 Version 1.”

The exemplary architecture described in FIG. 1A is provided merely as an example of many possible configuration for a system implementing the disclosed methods for revalidating FQDN ruleset in firewalls. In other embodiments, the firewall rules are implemented in, for example, software implemented forwarding element 130 or in MEM 160 of the slowpath process implemented in a user space. In some other embodiments, MEM 160 may be implemented in a virtualization software kernel. In addition, in some embodiments, policy engine 102 is part of a datapath for a software forwarding element port that does not connect directly to VNIC 125 of data compute node 120. In some embodiments, a gateway forwarding element equipped with ports is deployed to exchange logical network traffic with physical networks external to the logical network, and the ports may be configured with their own individual policy engines and/or expression matchers.

Example Expressions

As described above, a management plane or local manager 152 provides rules to policy engine 102, and also provides expressions that an expression engine 160 stores in expression table 170. Expression engine 160, also referred to as a multi-expression matcher (“MEM”) 160, may receive the expressions at the time when the rules and polices are being generated and stored in firewall policy 190. When expression engine 160 receives the expressions, expression engine 160 also receives the expression identifiers that have been assigned to the expressions by a system administrator or a user.

Suppose that expression engine 160 received an expression and an expression identifier that has been assigned to the expression by a system administrator. Upon receiving the expression and the expression identifier, expression engine 160 stores the expression and the identifier in expression table 170. It should be noted that expression table 170 may also be implemented as any other type of data structure, not necessarily a table.

In the example depicted FIG. 1A, expression table 170 includes four expressions. A first expression includes *goo.com and an assigned identifier “ID1.” A second expression includes *face.com and an assigned identifier “ID2.” A third expression includes *abc.com and an assigned identifier “ID3.” A fourth expression includes *xyz.com and an assigned identifier “ID4.”

Expression engine 160 may receive updates to the expressions when the rules are modified. Receiving the updates is triggered by a rule modification. The rule and expression modifications are described in detail in FIG. 2A-2B.

Rule Modifications

Rules stored in firewall policy 190 may be modified, and the modification may be requested by a management plane or a local manager in response to receiving rule modification requests from a system administrator or a user. A modification to a rule may include, for example, replacing, in a list of expressions included in the rule, one expression with another expression. Other modifications may include adding an expression to a rule or removing an expression from a rule. Other modifications may include deleting an entire rule from firewall policy 290 and/or adding a new rule to firewall policy 290.

FIG. 2A is a block diagram depicting an example of a rule modification and FIG. 2B is an example flow chart for updating an expression table in response to a rule modification.

In step 202 of FIG. 2B, a policy engine detects a rule change. Suppose, that the change pertains to replacing, in a list of expression for one rule, one expression with another expression.

In step 204 of FIG. 2B, the rule is updated in the expression table. As indicated using an operation 210 in FIG. 2A, the example Rule_3 in firewall policy 290 has been modified by replacing, in a list of expressions included in the Rule_3, the expression “*xyz.com” with “*news.com.” Note, however, that the ID in the list for the Rule_3 has not been changed. That means that {*xyz.com (ID4)} in the expression list for the Rule_3 is modified to {*news.com (ID4)}.

In step 206 of FIG. 2B, in response to modifying the Rule_3 in firewall policy 290, an expression table 270 is also modified. As indicated using an operation 220 in FIG. 2A, “Expression 4: *xyz.com.com ID4” is modified to “Expression 4: news.com ID4”. Once expression table 270 is modified to reflect the rule modification, the modified rule is “realized,” i.e., its modification is completed.

In step 208 of FIG. 2B, a global version number that is assigned to an IP-Domain table 280 is modified. As indicated using an operation 230 in FIG. 2A, the global version number is increased from 1 to 2. Hence, the current global version number is 2. This example is provided to provide a clear description and is not limiting in any way.

Updating an Ip-Domain Table

In a stateful firewall, whenever a rule in a firewall policy is modified, a state for the rule needs to be validated. Thus, if a rule is modified, then the IP-Domain table needs to be updated.

FIG. 3A is a block diagram depicting an example of updating an IP-Domain table, and FIG. 3B is an example flow chart for updating an IP-Domain table in response to a rule modification.

Continuing with the example described in FIG. 3A, suppose that the Rule_3 was changed by replacing the expression *xyz.com in a list for the Rule_3 with the expression *news.com, but an ID in the list has not been changed. Once Rule_3 is modified, a particular IP address, corresponding to a domain name that matches on the expression *news.com, needs to be resolved.

In step 302 of FIG. 3B, the particular IP address, corresponding to the domain name that matches on the expression *news.com” is resolved As explained above, an IP address may be resolved by performing a lookup in a cache or DNS table for an IP address that was already proactively (or previously) queried using a DNS query (that included a domain name that matches on the expression *news.com)—provided that the DNS TTL value for storing that entry in the cache has not expired. However, if the IP address is taken from the cache, but a new rule requires that packets cannot be forwarded to a corresponding particular domain, then the new rule would affect existing communications to the particular domain until the DNS mapping is forgotten (i.e., when the DNS TTL for that IP address entry expires) and a new DNS response is received. Alternatively, an IP address may be resolved by issuing a DNS query including a domain name that matches on the “*news.com” expression and waiting for a DNS response with the particular IP address. Suppose that the particular IP address is IP_Address_5.

Assuming that the IP address is resolved, in step 304 of FIG. 3B, a new entry in an IP-Domain table 380 is created. The entry is filled in with the IP address, the expression that is included in the modified rule, and the expression identifier that is assigned to the expression in the modified rule. Continuing with the example described in FIG. 2A, if the Rule_3 was modified by replacing the expression *xyz.com in a list for the Rule_3 with the expression *news.com, but the expression ID4 was not changed, then the new entry in IP-Domain table 380 will include the IP_Address_5, *news.com, and ID4.

In step 306 of FIG. 3B, an entry version number for the new entry is determined and assigned to the entry. The entry version number corresponds to the global version number of IP-Domain table 380. If, for example, the global version identifier is 2, then the entry version number for this particular entry is also 2. Continuing with the above example, if the global version number is 2, then the new entry would be “IP_Address_5, #news.com, ID4, Version 2.”

This is depicted using an operation 322 in FIG. 3A, to show that the new entry includes “IP Address 5: *news.com ID4 Version 2.”

Validation

An IP-Domain table is validated each time a new connection to any IP address is established. In an embodiment, each time a new connection to any IP address is established, each and every entry in the IP-Domain table is validated. In other embodiments, however, when a new connection to a particular IP address is established, an entry, in the IP-Domain table, that includes the particular IP address is validated, but other entries are not validated so that the amount of churn caused by the frequent updating may be reduced.

FIG. 3C is an example flow chart for validating an IP-Domain table in response to establishing a new connection to a particular IP address. In step 308, it is detected that a new connection to the particular IP address is established.

In step 310, it is determined whether IP-Domain table 380 includes any entry that has an entry version number different than the global version number of the IP-Domain table 380.

If, in step 312, it is determined that IP-Domain table 380 includes no entry that has an entry version number different than the global version number of the IP-Domain table 380, then, step 318 is performed. Otherwise, step 316 is performed.

For example, as shown in FIG. 3A, an entry that includes IP_Address_5 is the entry “IP Address 5: *news.com ID4 Version 2”. The entry version number for that entry and the global version number of IP-Domain table 380 are the same. Hence, IP-Domain table 380 for that entry is up-to-date.

However, for an entry in IP-Domain Table 380 that includes IP_Address_4, the entry version number of that entry and the global version number are different. This is because the entry that includes IP_Address_4 is the entry “IP Address 4: *xyz.com ID4 Version 1”, and its entry version number is 1, which is different than the global version number that is 1. Thus, the validation continues in step 316.

Generating Update Information

Continuing with the example described in FIG. 3A, as shown using an operation 324, if it is determined that IP-Domain table 380 includes one or more entries that have their corresponding entry version numbers different than the global version number of the IP-Domain table 380, then, in step 316 of FIG. 3C, the entry version numbers for those entries are updated to the global version number.

Furthermore, also in step 316 of FIG. 3C, for each of those entries, the validation process includes generating update information. The use of the update information (e.g., a “dummy packet”) leverages the existing mechanisms of passing packet header information and the update information between policy engine 102 and slowpath process 140. However, any mechanism for passing packet header information that can trigger an update of the expression table may be used.

In some embodiments, update information for a particular entry includes information extracted from that particular entry and includes the IP address and the expression included in that entry.

Continuing with the above example, if the entry is “IP Address 4: *xyz.com ID4 Version 1”, its entry version number is 1, which is different than the global version number that is 2. Hence the update information is generated for that entry. The update information may include IP_Address_4 and *xyz.com.

Referring again to step 316 in FIG. 3C, the update information may be communicated to a slowpath process, to cause the slowpath process to update an expression table, and more specifically, to update an entry, in the expression table, that contains the expression *xyz.com.

In the example depicted in FIG. 3A, expression table 270 does not have an entry that includes the expression *xyz.com. Hence, no entry in expression table 270 is updated. However, had expression table 270 included the expression *xyz.com, then that entry would be updated by, for example, removing, from that entry, an identifier that was included in that entry.

Referring again to FIG. 3C, once execution of step 316 is completed, in step 318, the expression table is used to enforce FQDN-based policy on the connection.

Implementation Mechanisms

The present approach may be implemented using a computing system comprising one or more processors and memory. The one or more processors and memory may be provided by one or more hardware machines.

FIG. 4 depicts an example of a basic hardware machine that may be used to implement the present approach. Hardware machine 400 and its hardware components, including their connections, relationships, and functions, are meant to be exemplary only, and not meant to limit implementations of the present approach. Other hardware machines suitable for implementing the present approach may have different components, including components with different connections, relationships, and functions.

Hardware machine 400 includes a bus 402 or other communication mechanisms for addressing a main memory 406 and for transferring data between and among the various components of hardware machine 400.

Hardware machine 400 also includes a processor 404 coupled with bus 402 for processing information. Processor 404 may be a microprocessor, a system on a chip (SoC), or another hardware processor. Main memory 406, such as a random-access memory (RAM) or other dynamic storage device, is coupled to bus 402 for storing information and software instructions to be executed by processor 404. Main memory 406 also may be used for storing temporary variables or other intermediate information during execution of software instructions to be executed by processor 404.

Software instructions, when stored in storage media accessible to processor 404, render hardware machine 400 into a special-purpose computing machine that is customized to perform the operations specified in the software instructions. The terms “software”, “software instructions”, “computer program”, “computer-executable instructions”, and “processor-executable instructions” are to be broadly construed to cover any machine-readable information, whether or not human-readable, for instructing a machine to perform specific operations, and including, but not limited to, application software, desktop applications, scripts, binaries, operating systems, device drivers, boot loaders, shells, utilities, system software, JAVASCRIPT, web pages, web applications, mobile applications, plugins, embedded software, microcode, compilers, debuggers, interpreters, virtual machines, linkers, and text editors.