Platform for routing internet protocol packets using flow-based policies

Abstract

Policy-based routing of IP (Internet Protocol) packets is performed using a flow context. A system intercepts events associated with creation of a network connection by an operating system (OS). The system identifies a flow context associated with a network connection that includes a flow tuple. Based on the flow context, and according to a flow-based routing policy, the system determines a provider associated with the network connection. The system records an association between the flow tuple and the provider in a state database and instructs the OS to initiate a network connection. After creation of the network connection, the system intercepts IP packets associated with the network connection. Based on the header of the IP packet, the system identifies the flow tuple and initiates a provider-based action for the IP packet based on a result of querying the flow tuple to the state database.

Description

Background Art

[0001] Computer systems have been coupled to each other and to other electronic devices to form both wired and wireless computer networks, through which computer systems and other electronic devices can transmit electronic data. Thus, the execution of many computing tasks is distributed across a number of different computer systems and / or a number of different computing environments. Computer networks typically transmit data in the form of data packets, which most commonly include Internet Protocol (IP) packets, such as Transmission Control Protocol (TCP) packets, User Datagram Protocol (UDP) packets.

[0002] Due to various network architectures and network security requirements, many IP-based tunneling solutions have been developed, such as various forms of virtual private networks (VPNs), which intercept IP packets based on the IP subnet specified in each IP packet and route the IP packets to a remote system through a tunnel. Summary of the invention

[0003] In some aspects, the technology described herein relates to a method implemented at a computer system including a processor, the method for performing policy-based routing of IP packets using flow context, the method comprising: intercepting an event associated with creation of a network connection by an operating system (OS); identifying a flow context associated with the network connection, the flow context comprising a flow tuple; based on the flow context and in accordance with a flow-based routing policy: determining a provider associated with the network connection at the computer system; recording an association between the flow tuple and the provider in a state database; and instructing the OS to initiate a network connection; after creation of the network connection, intercepting an IP packet associated with the network connection; identifying the flow tuple based on a header of the IP packet; and initiating a provider-based action for the IP packet based on a result of querying the state database for the flow tuple.

[0004] In some aspects, the technology described herein relates to a computer system for policy-based routing of IP packets using flow context, comprising: a processor; and a computer storage medium storing computer-executable instructions, the computer-executable instructions being executable by the processor to cause the computer system to at least: intercept an event associated with creation of a network connection by an OS; identify a flow context associated with the network connection, the flow context comprising a flow tuple; based on the flow context and in accordance with a flow-based routing policy: determine a provider associated with the network connection at the computer system; record an association between the flow tuple and the provider in a state database; and instruct the OS to initiate the network connection; after the creation of the network connection, intercept an IP packet associated with the network connection; identify the flow tuple based on a header of the IP packet; and initiate a provider-based action for the IP packet based on a result of querying the state database for the flow tuple.

[0005] In some aspects, the technology described herein relates to a computer program product comprising a computer storage medium storing computer executable instructions executable by a processor to cause a computer system to implement policy-based routing for IP packets using flow contexts, the computer executable instructions including instructions executable by the processor to cause the computer system to at least perform the following operations: intercept an event associated with creation of a network connection by an OS; identify a context for the network connection, the context comprising a flow tuple; based on the context and in accordance with a flow-based routing policy: determine a provider associated with the network connection at the computer system; record an association between the flow tuple and the provider in a state database; and instruct the OS to initiate the network connection; after the creation of the network connection, intercept an IP packet associated with the network connection; identify the flow tuple based on a header of the IP packet; and initiate a provider-based action for the IP packet based on a result of querying the state database for the flow tuple.

[0006] This summary is provided to introduce a selection of concepts in a simplified form that will be further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed technical solution, nor is it intended to be used to help determine the scope of the claimed technical solution. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to describe the manner in which the advantages and features of the systems and methods described herein can be obtained, a more particular description of the embodiments briefly described above will be rendered by reference to specific embodiments thereof illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments of the systems and methods described herein and are, therefore, not to be considered limiting of their scope, certain systems and methods will be described and explained with additional particularity and detail through the use of the accompanying drawings, in which:

[0008] Figure 1 An example computer architecture is shown that provides a platform for routing IP packets using flow-based policies.

[0009] Figure 2 An example of the internal components of a flow-based routing component is shown.

[0010] Figure 3 An example of flow-based routing is shown.

[0011] Figure 4A A flow chart of an example method for establishing an IP connection according to a flow-based policy as part of a method for policy-based routing of IP packets using flow context is shown.

[0012] Figure 4B A flow chart of an example method for routing IP packets according to a flow-based policy as part of a method for policy-based routing of IP packets using flow context is shown. DETAILED DESCRIPTION

[0013] The inventors have recognized that multiple IP-based tunnel providers cannot easily coexist at the same computer system because each tunnel provider is responsible for its own packet interception - possibly at a different network layer (e.g., a layer defined by the Open Systems Interconnection model). This can lead to conflicts and behaviors that are difficult to predict. In addition, because existing IP-based tunnel providers route IP packets based on the IP subnet specified in each IP packet, these existing IP-based tunnel providers cannot take into account the broader context of the IP packets, such as associated processes, users, domains, categories, etc.

[0014] At least some embodiments described herein provide a platform for routing IP packets using a flow-based routing strategy. The platform described herein can interoperate with various tunnel providers, thereby avoiding conflicts and unpredictable behavior that are conventionally present when implementing more than one IP-based tunnel solution at the same computer system.

[0015] In addition, the platform described herein routes IP packets based on IP streams (e.g., TCP / UDP streams), making it possible to make different routing decisions for each IP stream, and therefore the stream of the IP packet can be routed to a specific provider, the stream of the IP packet can be routed through the conventional path of the network stack (i.e., bypassing the provider completely), or blocking the IP packet. In an embodiment, the platform described herein links the stream context information obtained when the IP connection is established with subsequent IP packet filtering, so that the routing strategy based on the stream can consider various information associated with the IP stream, such as processes, users, domains, categories, etc., except for the limited information (e.g., subnets) that can be obtained from the IP packet itself. Therefore, the strategy based on the stream enables rich and extended routing options that were previously impossible.

[0016] Figure 1 An example computer architecture 100 providing a platform for routing IP packets using a flow-based strategy is shown. As shown, the computer architecture 100 includes a computer system 101, which includes a processor 102 (e.g., a single processor or multiple processors), a memory 103 (e.g., a system or main memory), a storage medium 104 (e.g., a single computer-readable storage medium or multiple computer-readable storage media), and a network interface 105 (e.g., one or more network interface cards connected to a network 107), all of which are interconnected via a bus 106 (or multiple buses).

[0017] Storage medium 104 is shown storing computer executable instructions implementing an operating system (OS) (OS 108), which in turn includes at least a network stack 109 and a set of application programming interfaces (APIs) (API 110). Storage medium 104 is also shown storing computer executable instructions implementing a flow-based routing component 111, which implements a platform for routing IP packets using one or more flow-based routing policies (e.g., policy 113).

[0018] In an embodiment, the flow-based routing component 111 uses one or more first APIs (e.g., IP connection filter APIs) of the API 110 and the policy 113 to control the establishment of an IP connection to a remote system via the network stack 109. In an embodiment, the policy 113 defines routing rules based on an IP tuple associated with the IP connection, such as an IP 4-tuple (e.g., source IP address, source port, destination IP address, and destination port), an IP 5-tuple (e.g., source IP address, source port, destination IP address, destination port, and protocol), etc. In an embodiment, the policy 113 also defines routing rules based on additional IP connection contexts such as the process identifier (PID) of the process initiating the IP connection, the owning user of the process, the user of the interactive session associated with the process, the destination domain for the IP connection, the destination domain category, etc. Additionally, in an embodiment, based on the state maintained during the establishment of the IP connection (e.g., the state database 114), the flow-based routing component 111 also uses one or more second APIs (e.g., packet filtering APIs) of the API 110 to control the routing of IP packets transmitted via the network stack 109. In an embodiment, the flow-based routing component 111 uses the state database 114 to redirect packets to one or more providers (e.g., provider 112), transmit packets along their normal path (e.g., from application to network stack 109, from network stack 109 to application), or drop packets. As used herein, provider 112 can consume packets, can analyze packets, and / or can output / send packets. As an example, provider 112 can be a tunnel provider (e.g., VPN), a firewall provider (e.g., packet filter), etc.

[0019] In an embodiment, by using the state maintained during the establishment of the IP connection when controlling the routing of the IP packets, in addition to implementing the policy 113 during the creation of the IP connection, the flow-based routing component 111 also implements the policy 113 during the routing of the IP packets. Therefore, the flow-based routing component 111 performs routing not only based on the subnet, but also based on rich IP connection context information, such as the PID of the process associated with the flow to which the IP packet belongs, the owning user of the process, the user of the interactive session associated with the process, the destination domain of the IP packet, the destination domain category, etc.

[0020] Figure 2 According to one or more embodiments, Figure 1 An example 200 of internal components of the flow-based routing component 111. Figure 2Each internal component of the flow-based routing component 111 depicted in the flow-based routing component 111 represents various functions that the flow-based routing component 111 can implement according to various embodiments described herein. However, it should be understood that the depicted components (including their identification and arrangement) are presented only as an aid to describe an example embodiment of the flow-based routing component 111. Now in conjunction with Figure 3 Description Figure 2 The operation of the internal components of the flow-based routing component 111 is shown, Figure 3 An example 300 of flow-based routing is shown.

[0021] As shown, in example 200, flow-based routing component 111 includes connection interception component 201. In some embodiments, connection interception component 201 is a kernel mode component, but other embodiments may implement connection interception component 201 in user mode. In an embodiment, connection interception component 201 interfaces with one or more of API 110 to intercept events initiated by a process executing at OS 108 requesting to create a network connection (e.g., an IP connection). Figure 3 In the embodiment, these APIs are shown as OS connection filter API 301, wherein the double arrows between OS connection filter API 301 and connection interception component 201 represent the two-way communication between these components. As an example, OS connection filter API 301 can be Windows Filtering Platform (WFP) API (WINDOWS), content filter API (MACOS) or Netlink API (LINUX). In an embodiment, when intercepting an event requesting the creation of a network connection by connection interception component 201, the creation of the requested network connection is suspended until connection interception component 201 instructs OS connection filter API 301 to proceed.

[0022] As shown in the figure, in example 200, the connection interception component 201 includes a flow context identification component 201a and a connection action determination component 201b. In an embodiment, the flow context identification component 201a identifies an IP flow-based context for creating an event for an intercepted network connection. In an embodiment, the context based on the IP flow includes at least a portion of the IP tuple associated with the requested network connection (i.e., one or more of the following: source IP address, source port, destination IP address, destination port, or protocol). In an embodiment, the context based on the IP flow also includes at least one of the following: the PID of the process that initiated the event, the owning user of the process that initiated the event, the user of the interactive session associated with the process that initiated the event, the destination domain, or the destination domain category (e.g., streaming service, news, etc.).

[0023] In an embodiment, based on the identified IP flow-based context, the connection action determination component 201b determines a connection action to be taken for the requested IP connection. In an embodiment, available connection actions include provider actions (e.g., tunneling IP packets associated with the IP connection to a selected provider (such as provider 112)), blocking actions (e.g., blocking the creation of an IP connection), and bypass actions (e.g., allowing IP packets associated with the IP connection to bypass any consumer by traveling through the normal path of the network stack 109).

[0024] In an embodiment, according to the identified context based on IP flow, the connection action determination component 201b determines which connection action to take based on the evaluation of policy 113. In examples 200 and 300, the evaluation of policy 113 is performed by policy evaluation component 203. In some embodiments, policy evaluation component 203 is a user mode component, but other embodiments can implement policy evaluation component 203 in kernel mode. In an embodiment, policy 113 includes one or more rules, each of which maps the desired action (e.g., provider, blocking or bypassing) to the corresponding matching criteria according to the context based on IP flow (e.g., IP tuple, process PID, process owner, session owner, domain, domain category). In an embodiment, there are multiple policies, and policy evaluation component 203 evaluates these policies in a prioritized manner. In an embodiment, when a rule specifies a provider action, the rule also specifies a target provider.

[0025] In an embodiment, based on the connection action for a specific IP connection determined by the connection action determination component 201b, the connection interception component 201 transmits an instruction to the OS connection filter API 301. In an embodiment, when the connection action is a provider action or a bypass action, the connection interception component 201 instructs the OS connection filter API 301 to resume the creation of the IP connection (i.e., initiate the IP connection). In an embodiment, when the connection action is a blocking action, the connection interception component 201 instructs the OS connection filter API 301 to terminate the creation of the IP connection.

[0026] In an embodiment, and as Figure 3As shown, in some embodiments, the connection interception component 201 updates the state database 114 for one or more intercepted IP connections. In an embodiment, the state database 114 is (at least conceptually) a table including key-value pairs, where the key includes an IP tuple (e.g., a 4-tuple, a 5-tuple), and the value is based on a determination of the connection interception component 201. In an embodiment, when the connection action for the IP connection is a provider action, the connection interception component 201 updates the state database 114 with an entry including a key for the IP tuple of the IP connection and a value including a consumer. In an embodiment, when the connection action for the IP connection is a bypass action, the connection interception component 201 updates the state database 114 with an entry including a key for the IP tuple of the IP connection and a value including an indication of bypassing. In an embodiment, when the connection action is a blocking action for the IP connection, the connection interception component 201 updates the state database 114 with an entry including a key for the IP tuple of the IP connection and a value including an indication of blocking. In some embodiments, when the connection action is a bypass action and / or a blocking action, the connection interception component 201 may omit updating the state database 114. As described below, omitting state for bypass and / or blocking actions may still inherently convey state that is available during later IP packet interception.

[0027] As shown, in example 200, flow-based routing component 111 also includes a packet interception component 202. In some embodiments, packet interception component 202 is a kernel mode component, but other embodiments may implement packet interception component 202 in user mode. In an embodiment, packet interception component 202 interfaces with one or more APIs in API 110 to intercept IP packets traveling through network stack 109. Figure 3 In the embodiment, these APIs are shown as OS packet filter API 302, where the double arrows between OS packet filter API 302 and packet intercept component 202 represent bidirectional communication between these components. As an example, OS packet filter API 302 can be a lightweight filter (LWF) API (WINDOWS) or a tunnel (TUN) interface (MACOS or LINUX).

[0028] As shown, in example 200, the packet interception component 202 includes a flow identification component 202a and a routing action determination component 202b. In an embodiment, after the packet interception component 202 has intercepted an IP packet, the flow identification component 202a determines the IP flow context for the IP packet. In an embodiment, the flow identification component 202a does this by determining an IP tuple (e.g., 4-tuple, 5-tuple) from the IP header data of the IP packet. In an embodiment, based on the determined IP flow context, the routing action determination component 202b determines the routing action for the IP packet. In an embodiment, the routing action determination component 202b determines the routing action for the IP packet based on querying the state database 114 using the determined IP flow context, such as by querying the state database 114 for a key including the determined IP tuple.

[0029] In some embodiments, based on querying the state database 114, the routing action determination component 202b identifies the provider 112 (e.g., based on a key including an IP tuple for the IP packet and a value including the provider 112). In these embodiments, the routing action determination component 202b determines a provider-oriented routing action. In some embodiments, the provider 112 is a tunnel provider, and the IP packet is an outbound packet (e.g., outbound from a process that initiates a corresponding IP connection); in these embodiments, the provider-oriented routing action includes routing the IP packet to the provider 112 (e.g., so that the provider 112 can transmit the IP packet through a tunnel). In an embodiment, routing the IP packet to the provider 112 may include communicating the IP packet to the provider 112 and instructing the OS packet filter API 302 to drop the IP packet. In some embodiments, the provider 112 is a tunnel provider, and the IP packet is an inbound packet (e.g., incoming from the network interface 105); in these embodiments, the provider-oriented routing action includes routing the IP packet to the OS 108. In some embodiments, the provider 112 is a firewall provider. In these embodiments, routing action determination component 202b determines a routing action based on forwarding the IP packet to provider 112 (eg, dropping the IP packet, modifying the IP packet, or transmitting the IP packet).

[0030] In some embodiments, routing action determination component 202b determines a bypass routing action based on querying state database 114. In embodiments, the bypass routing action is determined based on one of: identifying a key that includes an IP tuple for the IP packet and a value that includes a bypass indication, or failing to identify a key that includes an IP tuple for the IP packet. In these embodiments, based on determining the bypass routing action, routing action determination component 202b routes the IP packet to network stack 109.

[0031] In some embodiments, based on querying the state database 114, the routing action determination component 202b determines a blocking routing action. In an embodiment, the blocking routing action is determined based on one of the following items: identifying a key including an IP tuple for an IP packet and a value including a blocking indication, or failing to identify a key including an IP tuple for an IP packet. In these embodiments, based on determining a bypass routing action, the routing action determination component 202b discards the IP packet. It is noteworthy that in an embodiment, the routing action determination component 202b may not determine a blocking routing action because the creation of any corresponding IP connection will have been blocked by the connection interception component 201.

[0032] In example 200, flow-based routing component 111 is shown as including state management component 204, and in example 300, connection interception component 201 and packet interception component 202 are shown as interacting with state management component 204. In examples 200 and 300, state management component 204 represents functionality for writing to and reading from state database 114. In some embodiments, state management component 204 is a separate component for managing state database 114. However, in other embodiments, the functionality of state management component 204 is integrated into connection interception component 201 and packet interception component 202 (e.g., such that these components interact directly with state database 114).

[0033] In some embodiments, flow-based routing component 111 monitors IP connections established by network stack 109 , and upon detecting that an IP connection has been terminated / destroyed, flow-based routing component 111 removes the corresponding entry (if any) from state database 114 .

[0034] In some embodiments, when performing a provider connection action, the connection interception component 201 may prompt a user (e.g., a user of an interactive session associated with the process that initiated the event) to provide cloud-based credentials to initiate an IP connection. In an embodiment, based on policy 113, the connection interception component 201 also caches these credentials for establishing subsequent IP connections. This improves the user experience by avoiding repeated prompts for the same cloud credentials. In an embodiment, IP connections using the same credentials are grouped into channels, which can be used to manage those IP connections as a group (e.g., if necessary, the IP connections are destroyed together as a group). In an embodiment, a separate channel set is maintained for different users (e.g., based on an interactive session user identifier).

[0035] Now combine Figure 4A and Figure 4B describing components of the flow-based routing component 111, Figure 4A and Figure 4BA flow chart of an example method for policy-based routing of Internet Protocol packets based on flows is shown, including a method 400a for establishing an IP connection according to a flow-based policy, and a method 400b for routing IP packets according to a flow-based policy. In some embodiments, method 400a and method 400b are separate methods. In other embodiments, method 400a and method 400b are different stages of a single method; for example, method 400a is shown as advancing to method 400b, and method 400b is shown as continuing method 400a.

[0036] In an embodiment, instructions for implementing methods 400a and 400b are encoded as computer executable instructions (e.g., flow-based routing component 111) stored on a computer storage medium (e.g., storage medium 104), which can be executed by a processor (e.g., processor 102) to cause a computer system (e.g., computer system 101) to perform methods 400a and 400b.

[0037] The following discussion now relates to various methods and method actions. Although method actions may be discussed in certain orders, or may be shown in flowcharts as occurring in a particular order, no particular ordering is required unless specifically stated or required, or because an action depends on the need for another action to be completed before the action is performed.

[0038] refer to Figure 4A , method 400a includes an action 401 of intercepting the creation of an IP connection. In the example, based on interfacing with the OS connection filter API 301, the connection interception component 201 intercepts an event corresponding to the creation of an IP connection. In an embodiment, interception of the event pauses / suspends the creation of the IP connection by the OS 108.

[0039] The method 400a also includes an action of identifying a flow-based IP connection context 402. In the example, the flow context identification component 201a identifies a context including an IP tuple, and in an embodiment further identifies a context including the following items: a PID of a process initiating an event, an owning user of the process initiating the event, a user of an interactive session associated with the process initiating the event, a destination domain, a destination domain category, etc.

[0040] Method 400a also includes an action 403 of determining a connection action based on the flow-based connection context and the policy for each flow. In the example, using the context identified in action 402, the connection action determination component 201b determines the connection action based on consulting the policy 113 (e.g., using the policy evaluation component 203). As shown, in an embodiment, the possible connection actions in action 403 include one or more of the following: a provider action 403a (e.g., when an IP packet associated with the IP connection should be routed to a provider 112), a blocking action 403b (e.g., when an IP connection should be blocked), or a bypass action 403c (e.g., when an IP packet associated with the IP connection should follow a normal path through the network stack 109 to bypass any provider 112).

[0041] Method 400a may also include an action 404 of updating a state database. In the example, when the determined connection action is a provider action 403a, connection interception component 201 updates state database 114 to include an entry that includes an IP tuple for an IP connection plus an indication of an associated provider. In some embodiments, connection interception component 201 may also update state database 114 based on blocking action 403b and / or bypassing action 403c, but in other embodiments, connection interception component 201 avoids updating state database 114 in one or more of these scenarios.

[0042] Method 400a also includes an action 405 to instruct the OS about the IP connection. In the example, based on the connection action determined in action 403, the connection interception component 201 instructs the OS to allow or block the IP connection. As shown, the instructions in action 403 include instructions to continue with the creation 405a of the IP connection (e.g., for provider action 403a or bypass action 403c), or instructions for terminating the creation 405b of the IP connection (e.g., for blocking action 403b).

[0043] The technical effects of method 400a include granting or denying the creation of an IP connection based on policy 113, which may include things such as IP tuples, process PIDs, process owners, session owners, domains, domain categories, and the like. The technical effects of method 400a also include persistently storing (e.g., in state database 114) information that can be used to implement the policy 113 during IP packet filtering. Notably, this information can be persistently stored explicitly (e.g., by creating an entry in state database 114 for a provider action) or implicitly (e.g., by omitting entries in state database 114 for block and / or bypass actions).

[0044] In an embodiment, upon creation of an IP connection in conjunction with method 400a, an inbound or outbound IP packet associated with the IP connection is sent, thereby triggering execution of method 400b. Figure 4B , the method 400b includes an action 406 of intercepting IP packets on the established IP connection. In the example, based on interfacing with the OS packet filter API 302, the packet interception component 202 intercepts the IP packets.

[0045] The method 400b also includes an act of identifying a flow-based IP packet context 407. In an example, based on IP header information extracted from the IP packet, the flow identification component 202a identifies IP flow information, such as an IP tuple, associated with the IP packet.

[0046] Method 400b also includes an action 408 of determining a routing action based on the flow-based IP packet context and the state database. In an example, using the context identified in action 407, routing action determination component 202b determines a routing action based on consulting state database 114 (e.g., using state management component 204). As shown, the connection action in action 408 may include one or more of: a provider action 408a (e.g., when the IP tuple identified in action 407 is associated with a provider in state database 114), a transmit IP packet action 408b (e.g., when the IP tuple identified in action 407 is associated with a bypass indication in state database 114, or when the IP tuple is not found in state database 114), or a drop IP packet action 408c (e.g., when the IP tuple identified in action 407 is associated with a blocking indication in state database 114, or when the IP tuple is not found in state database 114).

[0047] A technical effect of method 400b includes using implicitly or explicitly persistently stored state information (eg, state database 114) to enforce policy 113 during IP packet filtering.

[0048] In some embodiments, the technology described herein relates to a method, system, and computer program product for policy-based routing of IP packets using flow context. As a first example, and with reference to method 400a, in an embodiment, the technology described herein includes intercepting an event associated with the creation of a network connection by an OS (e.g., action 401). In an embodiment, the technology described herein also includes identifying a flow context associated with a network connection (e.g., action 402), the flow context including a flow tuple. In an embodiment, the technology described herein also includes determining a provider associated with a network connection at a computer system based on the flow context and according to a flow-based routing policy (e.g., action 403, provider action 403a); recording an association between a flow tuple and a provider in a state database (e.g., action 404); and instructing the OS to initiate a network connection (e.g., action 405, continuing to create an IP connection 405a). The technical effects of this first example application of method 400a include allowing the creation of an IP connection based on a policy including an IP tuple and a provider, and persistent storage that can be used to route IP packets matching the IP tuple to the provider during IP packet filtering.

[0049] Continuing with the first example, and referring to method 400b, in an embodiment, the techniques described herein also include, after creation of the network connection, intercepting IP packets associated with the network connection (e.g., action 406). In an embodiment, the techniques described herein also include identifying the flow tuple based on the header of the IP packet (e.g., action 407). In an embodiment, the techniques described herein also include initiating a provider-based action for the IP packet based on the result of querying the state database for the flow tuple (e.g., action 408, provider action 408a). The technical effect of this application of method 400b includes routing the IP packet to the identified provider during packet filtering using the state information explicitly persistently stored in method 400a.

[0050] Continuing with the first example, in some embodiments, the provider is a tunnel component, the IP packet is an outbound packet, and the provider-based action includes routing the IP packet to the provider. Alternatively, in some embodiments, the provider is a tunnel component, the IP packet is an inbound packet, and the provider-based action includes routing the IP packet to the OS. Alternatively, in some embodiments, the provider is a firewall component, and the provider-based action includes dropping the IP packet. Alternatively, in some embodiments, the provider is a firewall component, and the provider-based action includes one or more of: modifying the IP packet or transmitting the IP packet.

[0051] Continuing with the first example, in some embodiments, the flow context also includes at least one of the following: a PID of the process initiating the event, an owning user of the process initiating the event, a user of an interactive session associated with the process initiating the event, a destination domain, or a destination domain category.

[0052] Continuing with the first example, in some embodiments, the flow tuple includes one or more of: a source IP address, a source port, a destination IP address, a destination port, and a protocol.

[0053] Continuing with the first example, in some embodiments, the techniques described herein also include determining that the network connection has been broken; and removing the association between the flow tuple and the provider from the state database.

[0054] Continuing with the first example, in some embodiments, the techniques described herein also include grouping the plurality of network connections into channels based on each of the plurality of network connections being associated with a common network identity.

[0055] As a second example, and with reference to method 400a, in an embodiment, the techniques described herein include intercepting an event associated with the creation of a network connection by the OS (e.g., action 401). In an embodiment, the techniques described herein also include identifying a flow context for the network connection (e.g., action 402), the flow context including a flow tuple. In an embodiment, the techniques described herein also include determining a blocking action for the network connection (e.g., action 403, blocking action 403b), and terminating the creation of the network connection (e.g., action 405, terminating the creation of an IP connection 405b) based on the flow context and according to a flow-based routing policy. The technical effects of this application of method 400a include blocking the creation of an IP connection based on a policy, and (even if implicitly) persistently storing information that can be used to block packets that match the IP tuple (if any) during IP packet filtering.

[0056] In some embodiments, due to the blocking of the IP connection in act 405, method 400b in the second example is not reached.

[0057] Continuing with the second example, in some embodiments, the techniques described herein also include recording an association between a flow tuple and a blocking action in a state database (i.e., explicit persistent storage of information that can be used to block IP packets matching the IP tuple during IP packet filtering).

[0058] In an embodiment, the second example can operate independently of the first example, or in conjunction with the first example (e.g., before or after the first example). For example, in one embodiment of the second example, the event is a second event, the network connection is a second network connection, the flow context is a second flow context, and the flow tuple is a second flow tuple.

[0059] As a third example, and with reference to method 400a, in an embodiment, the techniques described herein include intercepting an event associated with the creation of a network connection by the OS (e.g., action 401). In an embodiment, the techniques described herein also include identifying a flow context for the network connection (e.g., action 402), the flow context including a flow tuple based on a second flow context, and according to a flow-based routing policy: determining a bypass action for the second network connection (e.g., action 403, bypass action 403c), and instructing the OS to continue the creation of the second network connection (e.g., action 405, proceed with creation 405a of an IP connection). The technical effects of this application of method 400a include allowing policy-based creation of IP connections, and (even if implicitly) persistently storing information that can be used to bypass providers for packets matching the IP tuple during IP packet filtering.

[0060] Continuing with the third example, and referring to method 400b, in an embodiment, the techniques described herein also include, after creation of the network connection, intercepting an IP packet associated with the network connection (e.g., action 406). In an embodiment, the techniques described herein also include identifying a flow tuple based on a header of the IP packet (e.g., action 407). In an embodiment, the techniques described herein also include routing a second IP packet to a network stack based on a result of querying a state database for a second flow tuple (e.g., action 408, transmitting an IP packet action 408b). The technical effect of this application of method 400b includes transmitting an IP packet during packet filtering using the state information that was persistently stored (even if implicitly) in method 400a.

[0061] Continuing with the third example, in some embodiments, routing the IP packet to the network stack is based on a result of querying the state database for the flow tuple, the result including a failure to locate the flow tuple in the state database.

[0062] Continuing with the third example, in some embodiments, the techniques described herein also include recording an association between the second flow tuple and the bypass action in a state database (i.e., explicit persistent storage of information that can be used to transmit IP packets matching the IP tuple during IP packet filtering). In these embodiments, routing the IP packet to the network stack is based on a result of querying the state database for the flow tuple, which identifies a bypass action for the flow tuple.

[0063] In an embodiment, the third example can operate independently of the first example, or in conjunction with the first example (e.g., before or after the first example). For example, in one embodiment of the third example, the event is a second event, the network connection is a second network connection, the flow context is a second flow context, the flow tuple is a second flow tuple, and the IP packet is a second IP packet.

[0064] Embodiments of the present disclosure may include or utilize a dedicated or general-purpose computer system (e.g., computer system 101) that includes computer hardware, such as, for example, one or more processors (e.g., processor 102) and system memory (e.g., memory 103), as discussed in more detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that can be accessed by a general-purpose or dedicated computer system. Computer-readable media that store computer-executable instructions and / or data structures are computer storage media (e.g., storage media 104). Computer-readable media that carry computer-executable instructions and / or data structures are transmission media. Therefore, as an example, embodiments of the present disclosure may include at least two distinct computer-readable media: computer storage media and transmission media.

[0065] Computer storage media are physical storage media that store computer executable instructions and / or data structures. Physical storage media include computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid-state drive (SSD), flash memory, phase change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device that can be used to store program code in the form of computer executable instructions or data structures that can be accessed and executed by a general or special purpose computer system to implement the disclosed functions.

[0066] Transmission media may include networks and / or data links, which may be used to carry program codes in the form of computer executable instructions or data structures, and may be accessed by general or special computer systems. "Network" is defined as one or more data links that enable electronic data to be transmitted between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer system via a network or another communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computer system may view the connection as a transmission medium. The above combination should also be included within the scope of computer-readable media.

[0067] In addition, upon reaching various computer system components, program code in the form of computer executable instructions or data structures can be automatically transferred from transmission media to computer storage media (or vice versa). For example, computer executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., network interface 105) and then ultimately transferred to computer system RAM and / or less volatile computer storage media at the computer system. Thus, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

[0068] Computer executable instructions include, for example, instructions and data that, when executed at one or more processors, cause a general purpose computer system, a special purpose computer system, or a special purpose processing device to perform a specific function or group of functions. Computer executable instructions may be, for example, binary files, intermediate format instructions (such as assembly language), or even source code.

[0069] It should be understood that the disclosed system and method can be practiced in a network computing environment with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc. The embodiments of the present disclosure can also be practiced in a distributed system environment, wherein the local and remote computer systems linked by a network (by a hardwired data link, a wireless data link or by a combination of a hardwired and wireless data link) all perform tasks. Like this, in a distributed system environment, a computer system can include multiple component computer systems. In a distributed system environment, a program module can be located in a local and remote memory storage device.

[0070] It should also be understood that embodiments of the present disclosure can be practiced in a cloud computing environment. The cloud computing environment can be distributed, although this is not required. When distributed, the cloud computing environment can be distributed internationally within an organization and / or have components owned across multiple organizations. In this specification and the appended claims, "cloud computing" is defined as a model for implementing on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The cloud computing model can consist of various features, such as on-demand self-service, extensive network access, resource pooling, rapid elasticity, measured services, etc. The cloud computing model can also take the form of various service models, such as software as a service (SaaS), platform as a service (PaaS), and infrastructure as a service (IaaS). The cloud computing model can also be deployed using different deployment models, such as private cloud, community cloud, public cloud, hybrid cloud, etc.

[0071] Some embodiments, such as a cloud computing environment, may include a system that includes one or more hosts that are each capable of running one or more virtual machines. During operation, the virtual machines emulate an operating computing system, supporting an operating system and possibly one or more other applications. In some embodiments, each host includes a hypervisor that emulates the virtual resources of the virtual machine using physical resources abstracted from the virtual machine's view. The hypervisor also provides appropriate isolation between virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with physical resources, even though the virtual machine is only docked with the appearance of physical resources (e.g., virtual resources). Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, and the like.

[0072] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the above-described features or acts, or the order of the above-described acts. Instead, the described features and acts are disclosed as example forms of implementing the claims.

[0073] The present disclosure may be embodied in other specific forms without departing from its essential features. The described embodiments are to be considered in all respects as illustrative and non-restrictive only. All changes within the meaning and range of equivalents of the claims will be included within their scope.

[0074] When introducing elements in the appended claims, the articles "a," "an," "the," and "said" are intended to mean that there are one or more of the elements. The terms "comprising," "including," and "having" are intended to be inclusive and mean that there may be additional elements other than the listed elements.

Claims

1. A method implemented at a computer system including a processor for performing policy-based routing of IP (Internet Protocol) packets using flow context, the method comprising: Intercepting events associated with the creation of a network connection by the OS (operating system); identifying a flow context associated with the network connection, the flow context comprising a flow tuple; Based on the flow context, and according to the flow-based routing policy: determining a provider associated with the network connection at the computer system, recording the association between the stream tuple and the provider in a state database, and Instructing the OS to initiate the network connection; After said creation of said network connection, intercepting IP packets associated with said network connection; Based on a header of the IP packet, identifying the flow tuple; as well as Based on the result of querying the state database for the flow tuple, a provider-based action is initiated for the IP packet.

2. The method of claim 1, wherein the provider is a tunnel component, the IP packet is an outbound packet, and the provider-based action comprises routing the IP packet to the provider.

3. The method of claim 1, wherein the provider is a tunnel component, the IP packet is an inbound packet, and the provider-based action comprises routing the IP packet to the OS. 4 . The method of claim 1 , wherein the provider is a firewall component and the provider-based action comprises dropping the IP packet.

5. The method of claim 1, wherein the provider is a firewall component, and the provider-based action comprises one or more of: modifying the IP packet or transmitting the IP packet.

6. The method according to claim 1, wherein the flow context further includes at least one of the following: a process identifier of the process initiating the event, an owning user of the process initiating the event, a user of an interactive session associated with the process initiating the event, a destination domain, and a destination domain category.

7. The method according to claim 1, wherein the flow tuple includes one or more of the following: source IP address, source port, destination IP address, destination port, protocol.

8. The method according to claim 1, further comprising: determining that the network connection has been disrupted; as well as The association between the flow tuple and the provider is removed from the state database.

9. The method according to claim 1, further comprising: intercepting a second event associated with creation of a second network connection by the OS; identifying a second flow context for the second network connection, the second flow context comprising a second flow tuple; as well as According to the second flow context and according to the flow-based routing policy: determining a blocking action for the second network connection, and The creation of the second network connection is terminated.

10. The method according to claim 9, further comprising: An association between the second flow tuple and the blocking action is recorded in the state database.

11. The method according to claim 1, further comprising: intercepting a second event associated with creation of a second network connection by the OS; identifying a second flow context for the second network connection, the second flow context comprising a second flow tuple; According to the second flow context and according to the flow-based routing policy: determining a bypass action for the second network connection, and instructing the OS to continue the creation of the second network connection; subsequent to said creation of said second network connection, intercepting a second IP packet associated with said second network connection; identifying the second flow tuple based on a second header of the second IP packet; as well as Based on the result of querying the state database for the second flow tuple, the second IP packet is routed to a network stack.

12. The method of claim 11, wherein routing the second IP packet to the network stack is based on a result of querying the state database for the second flow tuple, the result comprising a failure to locate the second flow tuple in the state database.

13. The method according to claim 11, further comprising: recording the association between the second flow tuple and the bypass action in the state database, Routing the second IP packet to the network stack is based on a result of querying the state database for the second flow tuple, the result identifying the bypass action for the second flow tuple.

14. The method according to claim 1, further comprising: The plurality of network connections are grouped into channels based on each of the network connections being associated with a common network identification.

15. A computer system for policy-based routing of IP (Internet Protocol) packets using flow context, comprising: processor; as well as A computer storage medium storing computer executable instructions executable by the processor to cause the computer system to at least: Intercepting events associated with the creation of a network connection by the OS (operating system); identifying a flow context associated with the network connection, the flow context comprising a flow tuple; Based on the flow context, and according to the flow-based routing policy: determining a provider associated with the network connection at the computer system, recording the association between the stream tuple and the provider in a state database, and Instructing the OS to initiate the network connection; After said creation of said network connection, intercepting an IP packet associated with said network connection; identifying said flow tuple based on a header of said IP packet; as well as Based on the result of querying the state database for the flow tuple, a provider-based action is initiated for the IP packet.

Images