Incremental application of resources to network traffic flows based on heuristics and business policies

Disclosed herein are system, method, and computer program product embodiments for increasingly applying network resources to traffic flows based on heuristics and policy conditions. A network determines that a traffic flow satisfies a first condition and transmits a first portion of the traffic flow to a network service. A network service then inspects the first portion of the traffic flow at a first level of detail and determines that the traffic flow satisfies a second condition. The network can then transmit a second portion of the traffic flow to the network service based on the determining the traffic flow satisfies the second condition. The network service can inspect the second portion of the traffic flow at a second level of detail, wherein the inspecting at the second level of detail requires a different amount of computing resources than the inspecting at the first level of detail.

BACKGROUND

1. Technical Field

Embodiments generally relate to network services.

In addition to routing data from one location to another, modern data networks provide personalized services. For example, many networks provide intrusion detection services that inspect sequences of packets to detect and prevent network attacks. Providing these services may require changes to routing of traffic flow. For example, traffic may be routed through a particular device that provides the service.

Traditional routing algorithms rely on local information each router has from its neighboring links and devices to route data. A router maintains such information in a routing table. Based on the destination address of an incoming packet, a router uses its routing table to forward the packet to a specific neighboring device.

A technique, referred to as Software Defined Networks (SDNs), separates the control and forwarding functions into separate devices. A control device may use a global knowledge of the network topology to determine a path through the network of forwarding devices for individual data flows. In this way, the control device may, for example, establish paths that minimize delay or maximize bandwidth through the network, or route a data flow through a particular device that provides a particular network service.

Routing data flows through network services introduces performance concerns. For example, intrusion detection systems may perform complex operations to detect attack patterns. These operations may increase latency and decrease bandwidth or may consume expensive network resources.

SUMMARY

In view of the above, it would be advantageous to provide a mechanism for providing increased application of network resources to traffic flows based on heuristics and policy conditions.

In an embodiment, a system determines that a traffic flow in a network satisfies a first condition and transmits a first portion of the traffic flow to a network service. A network service then inspects the first portion of the traffic flow at a first level of detail and determines that the traffic flow satisfies a second condition. The network can then transmit a second portion of the traffic flow to the network service based on the determining the traffic flow satisfies the second condition. The network service can inspect the second portion of the traffic flow at a second level of detail, wherein the inspecting at the second level of detail requires a different amount of computing resources than the inspecting at the first level of detail.

Method and computer-readable medium embodiments are also disclosed.

Further embodiments and features, as well as the structure and operation of the various embodiments, are described in detail below with reference to accompanying drawings.

DETAILED DESCRIPTION

In embodiments, network resources are increasingly applied to traffic flows based on heuristics and policy conditions. In an example, a lightweight network service first examines a small portion of a data flow. The lightweight network service may examine the portion of the data flow using a technique that uses limited computing resources. The lightweight service may examine the data flow to determine whether the data stream needs more detailed examination. Only if the network service determines that a more detailed examination is required, the entire data flow may be examined using a technique that requires more computing resources, and adds more to latency, or higher cost.

To apply increasing resources in this way, a network client may configure preferences or policies for network connections with other clients or services. For example, a client may provide a policy specifying that a particular type of traffic with a particular party be monitored by an intrusion detection system. In embodiments, a network can monitor traffic to and from the client to detect whether the traffic meets the policy conditions and, if it does, routes the portion of the traffic (or microflow) meeting the conditions through an intrusion detection system. For example, the network may route packets of the particular type and directed to the particular party through the intrusion detection system. Embodiments can also increase the amount of the flow inspected and the level of inspection based on policies and heuristics. In this manner, the network can provide economical handling of network traffic by increasingly applying network resources to traffic flows.

FIG. 1shows a block diagram of a network100that increasingly applies network resources to traffic flows, according to an embodiment.

Network100can be a traffic network configured to transmit data between client computing devices, such as, for example, personal computers, servers, mobile devices, local area networks (LANs), etc. In an embodiment, network100is a wide area network (WAN) or a metropolitan area network (MAN). In an embodiment, network100provides virtual networking services, such as, for example, virtual local area networks (VLANs), virtual private networks (VPNs), etc. In an embodiment, network100provides Ethernet connectivity between clients in remote locations. For example, network100can provide a virtual circuit with dedicated bandwidth for data communications between clients in remote locations. Network100may utilize any point-to-point, point-to-multipoint, or multipoint-to-multipoint networking protocols. Network access protocols used may include, for example, Ethernet, Asynchronous Transfer Mode (ATM), High-Level Data Link Control (HDLC), Frame Relay, Synchronous Optical Networking (SONET)/Synchronous Digital Hierarchy (SDH), Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Multiprotocol Label Switching (MPLS), etc.

In an embodiment, network100includes routers110a-f, a controller120, a network service provider130, a data collection module140, an analytics module142, a policy database144, and a client portal150. Each component is described in turn below. Each of routers110a-fmay be a layer2or layer3device that forwards packets.

Controller120may configure routers110a-fto route data based on, for example, client preferences, network policies, or heuristics. For example, controller120can configure the routing tables of routers110a-fto create a virtual circuit between two clients. Controller110can communicate with analytics module142to make decisions on how to configure routers110a-f.

Network service provider130may be a computing device configured to perform services on traffic flows. For example, network service provider130may be an intrusion detection system, firewall service, anti-virus system, anti-spam filter, etc., that can monitor, analyze, block, duplicate, or modify the packets of the traffic flow. In an embodiment, network service provider130is part of network100. In another embodiment, network service provider130is independently provided by an external third-party in communication with network100via, for example, the Internet.

In an embodiment, controller120configures routers to route a traffic flow, or portions of a traffic flow, through network service provider130. For example, a first party may wish to establish a traffic flow to communicate with a second party, but may wish to have the flow monitored by an intrusion detection system. Controller120may configure a set of routers to carry the traffic flow between the parties and to include service provider130in the route. In an embodiment, controller120may employ heuristics based on data gathered from the network to configure traffic flow routes and network services applied to the flows.

Data collection module140may collect data from the network flows based on policies associated with the flows and forwards the data to analytics module142for analysis. In an embodiment, a router110(e.g., any router110a-f) may detect a new data flow. When a packet from a new data flow is detected, the router may forward the packet, including both its header and its contents, to data collection module140.

Data gathering may depend on an amount of scrutiny desired for a particular flow. For example, a policy may specify a level of analysis for a flow, and data collection module140may gather information from packets based on the specified level of analysis. In one example, data collection module140gathers just the packet headers for a flow at an inspection level indicating moderate trust for the flow. In another example, data collection module140samples a subset of the headers at a lower inspection level indicating a higher level of trust for the flow. In yet another example, for a flow being inspected in more detail, data collection module140may collect the entire flow. In this manner, the level of detail of data collection and analysis can be adjusted based on analysis of the flow, as further explained below.

Analytics module142may analyze the data gathered by data collection module142to detect conditions that may trigger policy conditions or security flags. To detect the conditions, analytics module142gathers policy information from policy database144.

Policy database144may store policies associated with, for example, network clients, source and destination addresses, applications, etc. In an embodiment, a client specifies policies associated to its traffic flows. For example, a client and a server may communicate through network100. The client may specify that it wants its HTTP traffic with the server to be monitored by an intrusion detection system. Policy database144may also store policies based on heuristics. For example, a network manager may wish to evaluate anomalous traffic more closely than other traffic. The manager may establish a heuristics-based policy that states that a flow whose average packet size exceeds a certain threshold should be forwarded through an intrusion detection system for closer examination.

Using the policies in policy database144, analytics module142may evaluate the flow data obtained from data collection module140to determine whether any policies are satisfied. If any conditions are satisfied, analytics module142may communicate with controller120and instruct it to configure routers110a-fto route traffic in compliance with the satisfied policy. For example, if analytics module142detects a traffic flow's average packet size exceeds a threshold established by a heuristics-based rule, analytics module142can notify controller110, which in turn can configure routers to forward the flow through network service provider130for monitoring by an intrusion detection system.

Client portal150may receive policies and configuration information from network clients. In an embodiment, client portal150provides a user interface, such as a web interface, to clients where clients can provide policies and configuration information for their network communications. In another embodiment, client portal150may provide application program interfaces that enable clients to provide policies and configuration information for their network communications.

Client portal150may receive high-level indications of the security or performance desired for a particular flow, client, party, application, etc. Based on these indications, client portal150can configure policies in policy database144. In another embodiment, client portal150receives detailed policies of the inspection level or intrusion detection analysis desired for a particular flow.

FIG. 2shows a block diagram illustrating further details of a system providing increased application of network resources to network flows, in accordance to an example embodiment.

A flow may be configured to travel through routers110aand110b.FIG. 2illustrates how the flow may be handled based on the inspection level determined for the flow, according to an example embodiment.

In an embodiment, routers110can detect new flows and perform flow analysis and route flows to a corresponding module. In an embodiment, a router110detects a packet from a new flow and forwards the packet to data collection module140for analysis by analytics module142. Analytics module142can provide analysis instructions to controller120, for example, by providing an inspection level for a flow. Controller120can then configure routers110to route flows based on their respective inspection levels.

In an embodiment, routers110may be configured to perform heuristics analysis of metadata about flows. For example a router110, such as router110a, may be configured to monitor the average packet size of flows. If the average packet size deviates from a specified range, router110acan forward packets from the flow to data collection module140, and analytics module142may determine whether to increase the inspection level of the flow.

In an embodiment, controller120may configure routers110to route a microflow of the flow's packets to service provider130based on the inspection level of the flow. For example, for a flow at a first inspection level, router110amay be configured to not route any packets through provider130and may perform a heuristics analysis of the flow metadata and route the flow directly to router120b. In this way, the first level of inspection may be conducted at router110a.

Beyond the first level of analysis, to conduct the different levels of inspection, the packets may be transmitted to various modules provided by service provider130: a packet sampler module232, a flow optimizer module234, a traffic sampler module236, and a continuous analyzer238.

In particular, at a second inspection level, router110amay be configured to route a microflow comprised of samples of the packet headers (e.g., randomized header samples) to network service provider130for analysis. A packet sampler module232at provider130can then analyze this microflow. At a third inspection level, router110amay be configured to route a microflow comprised of the packet headers to provider130, in which a flow optimizer module234can analyze the microflow. At a fourth inspection level, router110amay be configured to route a microflow comprised of packets including header and contents through provider130, in which a traffic inspector module236can analyze the microflow. At a fifth inspection level, router110amay be configured to route an entire flow through provider130, in which a continuous analyzer238can analyze the flow. The inspection levels and microflows described are merely examples meant to illustrate the functionality of embodiments of network100, and other examples suitable for different methods of packet flow analysis will be appreciated by those skilled in the relevant arts.

Provider130can perform analysis of the microflows, such as, for example, intrusion detection, firewall, anti-spam filtering, etc. Provider130can then perform other actions with the flow depending on the results of the analysis, such as, for example, blocking packets that are determined to pose security risks, sending an alert, etc. In an embodiment, provider130can communicate with analytics module142to adjust the inspection level of the flow based on the results of a previous analysis.

FIG. 3shows a diagram illustrating the functionality of different levels of flow analysis, according to an example embodiment.

At level302, no particular analysis is performed on the flow, and only a generic heuristic analysis for the flow's metadata is performed. For example, the analysis can include determining the average size of packets, number of packets, bytes transmitted, etc.

At level304, packet sampling may be performed that can, for example, identify a microflow. At this level, the analysis can include looking at random samples of packet headers and determining if they meet certain criteria. For example, packet sampling can be used to identify a microflow to which a policy applies (e.g., Layer3and layer4IP, port, protocol information, even HTTP packets from a particular address). The policy may then be applied by controller110.

At level306, flow optimization may be performed that can, for example, look at an entire flow while assuring a level of performance. The performance level may be defined in an application performance database which, when the flow is identified and looked up from, may dictate a particular service level (guaranteed bandwidth, latency, jitter, packet loss, etc. . . . ) At this level, the analysis can include looking at the header of all packets in a flow or microflow to detect conditions that match policies or rules.

At level308, traffic inspection may be performed that can, for example, look at the payload of some packets. For example, the analysis can include looking at the payload of random packets in a flow or microflow, and looking for attack patterns associated with a particular type of traffic.

At level310, continuous analysis may be performed that can, for example, look at an entire flow or microflow. For example, the analysis can include looking at the header and payload of all packets in a flow or microflow, and detecting attack patterns associated with a particular type of traffic.

FIG. 4is a flowchart illustrating a method400of performing increased application of network resources to a microflow based on policies, according to an example embodiment.

At step402, the network receives a policy from a client regarding one or more of its network communications. A client can specify policies for all or some of its communications, based on parameters such as, for example, source and destination addresses (e.g., IP addresses), source and destination ports (e.g., TCP or UDP ports), protocol (e.g., HTTP, RTP), application, etc. In an embodiment, a network client may specify performance and security required for all or some of its communications. A client may provide a high level description of the performance or security desired for particular communications (e.g., high security for communications with ABC Corp., high throughput for communications XYZ Inc.), or may provide particular low level policy details (e.g., a particular IDS service for communications between particular IP addresses and ports).

At step404, the network stores policies associated with client communications in a policy database. In an embodiment, the network creates low level policies based on high level input provided by the client, as described in step402.

At step406, the network collects data samples from a flow for analysis. In an embodiment, the network can collect a first packet from a new data flow and determine whether the flow satisfies a condition established in the policy database, as shown in step408. For example, the network can determine based on analysis of the packet that the flow has a source and destination IP addresses that match a policy that specifies the flow must pass through an intrusion detection system.

If at step408, the network determines the data flow satisfies a policy condition, the network adjusts its flow routes to forward the flow, or a microflow of the flow, according to the policy, as shown in step410. For example, the network may adjust the routers' routing tables to route a microflow, such as, for example, the headers of the packets, through an intrusion detection system.

The network may continuously collect data from the flows to determine if policy conditions occur, as shown in the flowchart's return to step406.

FIG. 5is a flowchart illustrating a method500for increasing the allocation of network resources to traffic flows in a network, according to an example embodiment.

At step502, the network may set the traffic inspection level of a flow to an initial level.

At step504, the network may inspect the network traffic of the flow based on the inspection level set for flow. Inspecting the traffic may involve, for example, transmitting a portion of the flow, e.g., a microflow, through a network service. The transmitting may involve rerouting a portion of the flow, e.g., a microflow, through a network service or duplicating the packet flow through the network service in parallel. In an embodiment, at every higher inspection level, a larger portion of the flow is inspected and increased network resources are applied to inspecting the flow.

At step506, the network may detect an event of interest in the flow. For example, an intrusion detection system may detect a sequence of packets in the flow that matches an attack pattern for compromising a particular type of server. When the network detects an event of interest, the network can increase the traffic inspection level of the flow, as show in step508. Increasing the traffic inspection level of the flow may involve inspecting additional packets in the flow's sequence of packets at a higher level illustrated inFIG. 3The network can then continue inspecting the flow, as shown in504, at a high inspection level to further determine whether an attack is actually occurring and to handle it appropriately.

Similarly, the network may continue to monitor the flow to determine whether the event of interest continues. In the intrusion detection system example, the network may monitor to determine whether the flow continues to match the sequence matching the attack pattern. In examples where the event is tied to the size of the packets or a number or rate of packets in the data flow, the network may continue to monitor to determine whether the size, number or rate of the packets is outside of a normal range. When the event no longer exists, the network may decrease the level of inspection. By decreasing the level of inspection, additional packets in the flow's sequence of packets at a lower level illustrated inFIG. 3, thereby freeing up network resources to evaluate other areas of potential attack.

CONCLUSION

Policy database144may be any stored type of structured memory, including a persistent memory. In examples, a database may be implemented as a relational database or file system.

Each of the blocks and modules inFIGS. 1 and 2may be implemented in hardware, software, firmware, or any combination thereof.

Each of the blocks and modules inFIGS. 1 and 2may be implemented on the same or different computing devices. Such computing devices can include, but are not limited to, a personal computer, a mobile device such as a mobile phone, workstation, embedded system, game console, television, set-top box, or any other computing device. Further, a computing device can include, but is not limited to, a device having a processor and memory, including a nontransitory memory, for executing and storing instructions. The memory may tangibly embody the data and program instructions. Software may include one or more applications and an operating system. Hardware can include, but is not limited to, a processor, memory, and graphical user interface display. The computing device may also have multiple processors and multiple shared or separate memory components. For example, the computing device may be a part of or the entirety of a clustered computing environment or server farm.

Identifiers, such as “(a),” “(b),” “(i),” “(ii),” etc., are sometimes used for different elements or steps. These identifiers are used for clarity and do not necessarily designate an order for the elements or steps.

The breadth and scope of the present embodiments should not be limited by any of the above-described examples, but should be defined only in accordance with the following claims and their equivalents.