WO2016171690A1

WO2016171690A1 - Pre-filter rules for network infrastructure devices

Info

Publication number: WO2016171690A1
Application number: PCT/US2015/027257
Authority: WO
Inventors: Joseph A. Curcio; Wei Lu; Bruce E. Lavigne
Original assignee: Hewlett Packard Enterprise Development Lp
Priority date: 2015-04-23
Filing date: 2015-04-23
Publication date: 2016-10-27

Abstract

Example embodiments disclosed herein relate to pre-filtering using network infrastructure devices. In one example, a first network infrastructure device is used to forward first network packets on a network. The first network infrastructure device including a first logic to implement a first subset of pre-filter rules. In the example, a second network infrastructure device is used to forward second network packets on the network. The second network infrastructure device including a second logic to implement a second subset of the pre-filter rules. The first subset and the second subset are different. The first logic is to identify one of the first network packets using the first subset of pre-filter rules to forward to a deep packet inspection device of the network for further scrutiny.

Description

PRE-FILTER RULES FOR

NETWORK INFRASTRUCTURE DEVICES

BACKGROUND

[0001] Computing networks can include multiple network devices such as routers, switches, hubs, servers, desktop computers, laptops, workstations, network printers, network scanners, etc. that are networked together across a local area network (LAN), wide area network (WAN), wireless networks, etc. Networks can include deep packet inspection devices, such as an intrusion prevention system (IPS) and/or an intrusion detection system (IDS) to detect unwanted activity acting on the computer network.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The following detailed description references the drawings, wherein:

[0003] FIG. 1 is a block diagram of a network system including two network infrastructure devices capable of implementing different pre-filter rules on packets, according to an example;

[0004] FIG. 2 is a block diagram of a network system including multiple network infrastructure devices capable of implementing pre-filter rules on packets, according to an example;

[0005] FIG. 3 is a block diagram of a software defined networking controller capable of controlling configuration of implementation of pre-filter rules on network infrastructure devices, according to an example;

[0006] FIG. 4 is a block diagram of a system including a software defined networking controller capable of controlling configuration of implementation of pre-filter rules on network infrastructure devices of the system, according to an example; [0007] FIG. 5 is a flowchart of a method tor controlling configuration of implementation of pre-filter rules on network infrastructure devices, according to an example;

[0008] FIG. 6 is a block diagram of a device capable of controlling configuration of implementation of pre-filter rules on network infrastructure devices, according to an example; and

[0009] FIG. 7 is a flowchart of a method for selecting pre-filter rules for network infrastructure devices based on a classification of network activity at the respective network infrastructure devices, according to an example.

DETAILED DESCRIPTION

[0010] The set of possible malware (e.g., viruses, worms, spyware, etc.) signatures and signatures of other interesting patterns of network traffic is ever- increasing. Thus, a large quantity of rules may be implemented to detect the patterns (e.g., malware). Deep Packet Inspection devices can examine network packets and flows of packets to detect the patterns, for example, to help defend against malware. However, deep packet inspection devices tend to be slow relative to current network speeds, with the performance gap widening. Increasing deep packet inspection device capacity, and/or capability, to check all network data is expensive. Examples of deep packet inspection devices include Intrusion Detection Systems (IDS), Intrusion Prevention Systems (IPS), and Next Generation Firewalls (NGFW).

[0011] One option is to pre-filter the traffic according to rules to determine whether deep packet inspection should be applied. Pre-filtering is an approach to select packets (e.g., flows of packets) to send to a network appliance such as a deep packet inspection device if the packets meet criteria (e.g., if the packets are suspicious or in some other way interesting to the inspection device based on the criteria). Thus, packets and/or packet flows can be sent or not sent to the deep packet inspection device based on the pre-filtering. Advantageously, deep packet inspection need not be performed on each packet on the network. On a campus network, which is a computer network made up of an interconnection of Local Area Networks (LANs) within a geographical area, network traffic may travel through multiple network infrastructure devices (e.g., switches, routers, wireless access points, etc.) to go from a source to a destination. With the growing quantity of rules increasing, it can be desirable to scale the approach to use these network infrastructure devices.

[0012] Accordingly, various embodiments disclosed herein relate to using network infrastructure devices to implement different subsets of rules that may be implemented to detect malware or other traffic identification. When a flow of packets travels from a source to a destination, a first network infrastructure device can tag packets with the information determined from rule implementation of a first subset of rules that the first network infrastructure device uses. In certain examples, implementation of a rule can mean the application and/or execution of the rule. The first network infrastructure device can then pass the packets to a second network infrastructure device, which can perform additional pre-filtering with a second set of rules. The second subset of rules can include additional pre-filtering rules compared to the first subset of rules.

[0013] According to various examples, a list of pattern signatures is processed to arrive at a set of rules. The rules can signify that a particular pattern is present in a packet or packet flow. A rule can be considered matched if the pattern associated with the rule exists in the packet or packet flow being examined. In some examples, if a particular rule is matched, the packet flow is directed towards a deep packet inspection device for further inspection. In other examples, multiple rules can be matched to determine that a flow should be directed to the deep packet inspection device for further inspection. The network infrastructure device can tag the packets in the flow with information determined from implementation of the rules. In one example, the rules can be applied as executable instructions executed by a processor. In another example, the rules can be applied in hardware as discussed below. In another example, implementation of the rules can mean validating against the rules. The tag can be placed in a header of the packets and can be read by other network infrastructure devices. Thus, a second network infrastructure device can look at a tagged packet and know that a particular rule was matched in a previous processing of the packet. The second network infrastructure device can also know that a second rule that the second network infrastructure device implemented also matched. The combination of these two matched rules can signify that further inspection should be performed by a deep packet inspection device.

[0014] Even though various examples discussed herein relate to patterns of malware, other types of patterns can be searched for. Examples of these patterns include patterns signifying an application running, transactions, particular messages, particular content (e.g., copyrighted works), etc.

[0015] The rule set can be configured to be conservative so as not to miss packets that include malware such as viruses. As such, the approach may also select packets which are not part of malware to be further inspected. The intention is to find flows of packets that may be suspicious because particular patterns have been found. Further inspection from a deep packet inspection device can be performed to determine whether the activity is malicious.

[0016] Some portion of the full rule set can be scanned for in hardware of the network infrastructure devices (e.g., switch hardware). As noted, the rules can be split between multiple network infrastructure devices to enable scaling compared to attempting to perform all of the rules on a single network infrastructure device.

[0017] As used herein, a network infrastructure device includes a network chip and can be used to forward packets. In one example, the network infrastructure device can have a number of network ports for the device for receiving and transmitting packets therefrom, and logic that is encoded with application specific integrated circuit (ASIC) primitives to check header fields and payload content in the packets. In other examples, logic can be implemented using other electronic circuitry (e.g., field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), etc.), instructions executable by a processor, etc. In certain examples, the logic can perform pattern matching on the header fields and the payload content, such as according to a number of rules included in a subset of rules from among all rules offered in association with a checking functionality. In some examples, logic included in network infrastructure devices can include all of the rules and the subset of rules is chosen to implement on respective devices. In other examples, the logic included in network infrastructure devices can include the subset of rules to implement.

[0018] FIG. 1 is a block diagram of a network system including two network infrastructure devices capable of implementing different pre-filter rules on packets, according to an example. The network system 100 can include a deep packet inspection device 102 that communicates with devices via a communication network. The communication network can include network infrastructure devices 104a and 104b. In some embodiments, the network infrastructure devices 104a, 104b can include special purpose machines. Further, according to some examples, the deep packet inspection device 102 and/or the network infrastructure devices 104a, 104b can be implemented via a processing element, memory, and/or other components such as ASICs. The network infrastructure devices 104a, 104b can include logic 120a, 120b. Part of the logic 120a, 120b can be used to implement pre-filter rules 122a, 122b.

[0019] As used herein, the term deep packet inspection device 102 is used to mean a network appliance or an add-on device, e.g., plug-in or application module or device, to a network with checking functionality as contrasted with a "network infrastructure device" 104, e.g., router, switch, access point, and/or hub, etc., which are sometimes considered more as "backbone" component devices to a network. A checking functionality can be provided in the form of software, application modules, ASIC logic, and/or executable instructions operable on the systems and devices shown herein or otherwise.

[0020] The packets can be determined to be network packets of interest based on pre-filtering applied by network infrastructure devices 104. As noted above network infrastructure devices 104 include a network chip and can be used to forward packets. In one example, the network infrastructure device 104 can have a number of network ports for the device for receiving and transmitting packets therefrom, and logic 120 that is encoded with ASIC primitives and/or other logic to check header fields and/or payload content in the packets. In certain examples, the logic 120 can perform pattern matching on the header fields and the payload content, such as according to a number of rules included in a subset of rules from among rules offered in association with a checking functionality such as a deep packet inspection device.

[0021] In certain examples, the logic 120 can be used to match patterns in the packets and/or packet flow according to the pre-filter rules 122. The patterns can be byte patterns and/or packet patterns and/or regular expression patterns. The logic can look for stateful patterns, "stateful" in that patterns can be detected across packet boundaries (e.g., a pattern can extend across packets). Packet(s) matching pattern(s) are deemed to satisfy the rule. In an example, the pre-filter rules 122 can be based on at least one Bloom filter. A Bloom filter can be used to test whether an element (e.g., a byte pattern from packet(s)) is a member of a set (e.g., interesting byte patterns). In another example, the pre-filter rules 122 can be based on a regular expression filter. A regular expression filter searches for byte patterns in the packets using regular expressions. In another example, the pre-filter rules 122 can be based on a packet order tracker that tracks ordering of packets (e.g., the order of packets in a Transmission Control Protocol (TCP) stream). In another example, the pre-filter rules can be based on a packet size tracker that searches for packets that match suspicious packet sizes. The pre-filter rules can include any combination of such examples, in addition to like type byte pattern and/or packet pattern matching.

[0022] Network infrastructure device 104a can be used to forward network packets on a network. Network infrastructure device 104b can also be used to forward network packets on the network. In some examples, packets can flow through network infrastructure device 104a, network infrastructure device 104b, or a combination thereof. As noted above, multiple sets of pre-filter rules 122 can be used in network system 100. As such, pre-filter rules 122a can be different from pre-filter rules 122b. In some examples, the sets of pre-filter rules can be mutually exclusive. In other examples, the sets of pre-filter rules can overlap.

[0023] The packets can be inspected at logic 120a to identify packet flows from a source to a destination that match a pre-filter rule or multiple pre-filter rules. If a rule matches, the packet and/or packet flow can be tagged with the information. In certain examples, if rules do not match, that information is included (e.g., rules A, B, and C were implemented for, but did not match).

[0024] In one example, the network infrastructure device 104a can further determine whether the packet flow should be sent to the deep packet inspection device 102 for further scrutiny, to another network infrastructure device 104a for implementation of additional pre-filter rules 122b, and/or clear the flow to travel from the source to the destination. In one example, a match of a single rule can represent that further scrutiny should be applied. As such, the packet flow including the packets can be sent to the deep packet inspection device 102 for further scrutiny. In another example, a match of a rule may indicate that another set of rules should be implemented to determine whether the flow should be further scrutinized by a deep packet inspection device 102.

[0025] The deep packet inspection device 102 can perform the further scrutiny (e.g., deep packet inspection) and determine whether the flow is clear of the malware signatures searched for or include the malware signatures searched for. In one example, the malware signatures are not present and the flow can be cleared to travel from the source to the destination. In some examples, this information can be tagged to the flow and network infrastructure devices 104 can choose not to implement the logic 120 on the cleared flows. In another example, deep packet inspection device 102 can determine that the flow matches a malware signature according to a rule. In this example, a security action can be performed. The security action can include blocking a packet or multiple packets of the flow, block the flow, log in the occurrence for metrics, send a message for indicating that the match occurred, sending to another deep packet inspection device for further analysis (e.g., redirecting the flow to monitor for security analysis), etc. [0026] The deep packet inspection device 102 and network infrastructure devices 104a, 104b can be part of a communication network. The communication network can use wired communications, wireless communications, or combinations thereof. Further, the communication network can include multiple sub communication networks such as data networks, wireless networks, telephony networks, etc. Such networks can include, for example, a public data network such as the Internet, local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), cable networks, fiber optic networks, combinations thereof, or the like. In certain examples, wireless networks may include cellular networks, satellite communications, wireless LANs, etc. Various communications structures and infrastructure can be utilized to implement the communication network(s).

[0027] By way of example, the devices can communicate with each other and other components with access to the communication network via a communication protocol or multiple protocols that define how nodes of the communication network interact with other nodes. Further, communications between network nodes can be implemented by exchanging discrete packets of data or sending messages. Packets can include header information associated with a protocol (e.g., information on the location of the network node(s) to contact, time stamp, identifier of the protocol, other supplemental information, combinations thereof etc.) as well as payload information. In some examples, the tag can be embedded in the payload.

[0028] Although not shown, the connections 130, 132, 134 between the devices can include other devices, such as other network infrastructure devices. Moreover, in some examples, some of these other network infrastructure devices can include logic to implement pre-filter rules described herein. In other examples, some of the other network infrastructure devices may not include the logic to implement pre-filter rules. Further, in some examples, tags including pre-filter information may be passed through the other network infrastructure devices. In some examples, these tags may be in the form of additional headers which the other network infrastructure devices ignore. [0029] FIG. 2 is a block diagram of a network system including multiple network infrastructure devices capable of implementing pre-filter rules on packets, according to an example. The network system 200 can include a deep packet inspection device 202 that communicates with devices via a communication network. Further, network system 200 may be implemented as part of a campus network that can be connected to other networks (e.g., the Internet). The communication network can include network infrastructure devices 204a, 204b, 204c. In some examples, the network infrastructure devices 204a, 204b, 204c can include special purpose machines such as switches, routers, access points, hubs, etc. Further, according to some examples, the deep packet inspection device 202 and/or the network infrastructure devices 204a, 204b, 204c can be implemented via a processing element, memory, and/or other components. The network infrastructure devices 204a, 204b, 204c can include logic 220a, 220b, 220c. Part of the logic 220a, 220b, 220c can be used to implement pre-filter rules 222a, 222b, 222c.

[0030] For the purpose of a simple explanation, in one example, pre-filter rules 222a may include rule sets A, B, and C, pre-filter rules 222b may include pre-filter rules D, E, and F, and pre-filter rules 222c may include pre-filter rules G, H, and I. In this example, the following rule combinations can be indicative of scenarios where further scrutiny should be conducted by the deep packet inspection device 202 {A, BC, BE, BDG, CH, EH}.

[0031] In one example, a packet flow can go from a first computing device 230a to a second computing device 230b. Network infrastructure device 204a receives the packets in the flow. The logic 220a can be implemented to determine results. The results can be tagged to the packet flow (e.g., as part of a header). For example, if a rule matches, the information can be tagged to the packet flow and/or if a rule does not match, information that the rule was checked, but not matched can be tagged.

[0032] In one example, if rule A and/or rules B and C are matched, the network infrastructure device 204a can identify the packets of the flow as to be forwarded to the deep packet inspection device 202 for further scrutiny. The network infrastructure device 204a can then forward the packets to the deep packet inspection device 202 on its way to computing device 230b.

[0033] In another example, the logic 220a determines that rule B was matched and tags the information to the packet flow. When the network infrastructure device 204a forwards the packet flow to network infrastructure device 204b, logic 220b can check against rules D, E, and F. The results can be tagged to the packet flow. Further, the network infrastructure device 204b can know that the rule B was matched by reading the tag in the packet flow. In this example, the logic 220b can identify the packets of the flow as to be forwarded to the deep packet inspection device 202 for further scrutiny if rule E is matched because then the rule combination of B and E is known to be matched. In another example, if D is matched, that information can be tagged and the flow can be forwarded to network infrastructure device 204c. Logic 220c can implement rules 222c on the packets and tag results into the packet flow. Moreover, if rule G is matched, then the packet flow can be forwarded to the deep packet inspection device 202 based on a match to rules B, D, and G via multiple pre-filtering tiers. Similarly, if rules C and H were both matched for the same packet flow or E and H were both matched for the same packet flow, the flows would be sent to the deep packet inspection device 202 for further scrutiny.

[0034] In another example, the flow is initially set to go towards the deep packet inspection devices 202. In this example, the flow can go from computing device 230b to computing device 230a. In a simple example, network infrastructure device 204c implements rules {A, B, C}, another network infrastructure device 204b in the path implements rules {D, E, F}. In this example, the following rule combinations can indicate that further scrutiny should be conducted by a deep packet inspection device 202 {AB, BF, CD}.

[0035] In one example, the flow matches rules B and C at network infrastructure device 204c, is tagged, and goes to network infrastructure device 204b on its path to a deep packet inspection device 202. In one example, network infrastructure device 204b can match rule D. In this example, the information is tagged to the flow and the flow is sent to the deep packet inspection devices 202 because the flow matches rules C and D.

[0036] In another example, the flow matches rules B and C at network infrastructure device 204c, is tagged, and goes to network infrastructure device 204b on its path to a deep packet inspection device 202. In this example, network infrastructure device 204b can match rule E or not match any additional rules from matched rules B and C. Further, in this example, the information can be tagged to the flow and the flow can be redirected to the computing device 230a via network infrastructure device 204a because match criteria indicating that deep packet inspection should be performed on the flow cannot be fulfilled.

[0037] The examples above are a simple examples for explanatory purposes. An X number of rules can be implemented in various combinations among a Y number of network infrastructure devices. Moreover, a Z number of rule combinations signifying packet flows to further scrutinize can be used. Further, some of the network infrastructure devices can implement logic with pre-filter rules while other network infrastructure devices may not.

[0038] Moreover, in some examples, classifications of network traffic traveling through particular network infrastructure devices, for example, network infrastructure device 204c, can be associated with the network infrastructure device 204c and associated with the pre-filter rules 222c implemented on the network infrastructure device. In one example, the network infrastructure device 204c is directly in between a set of computing devices (e.g., computing device 230b) and the other components in the network. In this example, the classification of the computing devices and/or network activity associated with the computing devices can be used to choose pre-filter rules specific to the clients. For example, if the computing devices were all user devices, rules affecting server devices need not be implemented on packet flows going to or from the computing devices. Examples of classes of network activity may include server network activity, desktop network activity, mobile device network activity, etc. The network activity can be associated with the respective device types. In other examples, other types of classifications may be used, for example, the type of operating system(s) implemented by the devices, types of applications implemented, etc. As such, classifications can be based on criteria that can be used to select rules to implement. Moreover, in another example, a set of network infrastructure devices may similarly be between the set of clients and the other components of the network.

[0039] Further, in another example, the pre-filter rules can be distributed to the network infrastructure devices based on network topology. For example, edge devices of a campus network may include a first set of pre-filter rules and non-edge devices of the campus network may include a second set of pre-filter rules. In other examples, the edge devices may further implement rules based on rules associated with classes of network traffic associated with computing devices connected to the edge device.

[0040] FIG. 3 is a block diagram of a software defined networking controller capable of controlling configuration of implementation of pre-filter rules on network infrastructure devices, according to an example. FIG. 4 is a block diagram of a system including a software defined networking controller capable of controlling configuration of implementation of pre-filter rules on network infrastructure devices of the system, according to an example. Software defined networking (SDN) controller 300 can be used to manage network elements such as network infrastructure devices such as switches, routers, access points, etc. In one example, the SDN controller 300 can include an interface engine 310 and a pre-filter determination engine 320. In another example, the SDN controller 300 can further include a classification engine 322, a processor 330, and memory 332. In some examples, the SDN controller 300 can be used to select pre-filter rules for respective network infrastructure devices and/or control configuration of the implementation of the pre-filter rules.

[0041] In another example, SDN controller 300 can be part of a system 400, which can include a software defined network that can be connected to the SDN controller 300 via a control plane (not shown). One or more SDN controllers can be used to control the SDN. The SDN 410 can be implemented using a network fabric that may include wired and wireless network elements such as network infrastructure devices 404a - 404I, 406a - 406m, edge network infrastructure devices 408a - 408n, etc. In certain examples, a network fabric is a network topology in which devices pass data to each other via the network infrastructure devices. Network infrastructure devices 404a - 4041 can include logic 420a - 4201 to implement pre-filter rules. As noted above, the pre-filter rules can be different among different devices. Further, the SDN 410 can include other network infrastructure devices 406 can do not include the logic to implement pre-filter rules and/or devices that are not controlled by the SDN controller 300. These network infrastructure devices 406 can forward packets, including packets with tags.

[0042] The interface engine 310 of the SDN controller 300 can be used to communicate with network infrastructure devices 404, 406, 408. The interface engine 310 can also be used to configure logic 420, 422 to implement pre-filter rules.

[0043] As noted previously, network infrastructure devices 404, 408 can include logic to implement respective pre-filter rules. The pre-filter rules are used to identify packets to forward to one or more deep packet inspection devices 402 implemented at the SDN 410 for further scrutiny.

[0044] The pre-filter determination engine 320 can be implemented by the SDN controller 300 to determine pre-filter rules to implement at respective network infrastructure devices 404, 408. In one example, the pre-filter determination engine 320 can determine a first subset of a complete set of the pre-filter rules to implement at one of the network infrastructure devices 404, 408. Further, in another example, the pre-filter determination engine 320 can determine a second subset of the complete set of pre-filter rules to implement at another one of the network infrastructure devices 404, 408. Moreover, the pre- filter determination engine 320 can generate a configuration message for the respective selected sets of pre-filter rules and send the message, via the interlace engine 310, to the network infrastructure devices 404, 408. In one example, the configuration message includes the rules and/or subset of rules. In another example, the configuration message can provide the respective network infrastructure devices with a location to obtain the rules. Moreover, in some examples, the configuration message can instruct the network infrastructure devices 404, 408 to get rules from another device or set of devices. In a further example, the rules are at the respective network infrastructure devices and the configuration message includes selection information describing the subset of the pre-filter rules for the respective network infrastructure devices 404, 408 to implement. In some examples, the configuration is the set of pre-filter rules to implement. In other examples, the configuration can include an update for programming particular logic of the respective network infrastructure devices 404, 408 with the rules. As noted above, the subsets can be different to allow splitting the workload between multiple network infrastructure devices 404, 408.

[0045] As noted, the pre-filter rules can be based on signatures of malicious activity. The signatures are abstracted to the rules. The rules can further be split in a manner such that a combination of rules can lead to a determination that a flow of packets should be provided to a deep packet inspection device 402 for further scrutiny.

[0046] The pre-filter determination engine 320 can determine the rules to implement based on a number of factors. The factors can include, for example, network topology, work load, network infrastructure device capability, client identities, network flow traffic activity, applications run on the network, etc.

[0047] In one example, the network topology is set such that there are a number of network infrastructure devices 404 that are non-edge nodes and a number of edge network infrastructure devices 408. Edge nodes are network infrastructure devices that can connect to a final consumer of the packets. Non- edge nodes are network infrastructure devices that are not connected to a final consumer of the packets. Note that in some examples, a same model of network infrastructure device (e.g., a switch) can act as an edge node or a non- edge node depending on the network topology. The rules can be split in such a way that each of the edge network infrastructure devices 408 include a particular set of the pre-filter rules while other sets of rules can be distributed among the non-edge nodes. This way, pre-filter rules implemented at the edge nodes need not be replicated at non-edge nodes because network traffic will go through an edge node that implements the respective pre-filter rules. In a further example, implementing the same or similar types of rules on the edge devices can help with the workload of the SDN 410 because traffic is not diverted to other edge nodes not in the path of a particular flow of traffic between computing devices 430, 432. Moreover, the rules can be spread throughout the network infrastructure devices so that there is a path between each of the clients where each of the split set of rules can each be implemented on the path.

[0048] Further, the logic capabilities of network infrastructure devices can be taken into account. For example, some network infrastructure devices may include more logic to implement rules than others. As such, additional rules may be implemented at these network infrastructure devices compared to others.

[0049] The SDN controller 300 and/or the network infrastructure devices can know the topology of the network as well as the pre-filter rules implemented at each network infrastructure device. The SDN controller 300 may provide the topology information including pre-filter rule implementation via the interface engine 310.

[0050] The rules can be tagged with metadata describing activity the rules are associated with. For example, if malware is particular to infecting a mail server, a rule associated with the signature can include a mail tag, a server tag, and/or a mail server tag. Similarly, when rules are abstracted and split, the tag with the malware signature can propagate to each of the rules. In certain examples, pre-filter rules can be derived from rules implemented at a deep packet inspection device. In one example, the pre-filter determination engine 320 selects the pre-filter rules based on sizes of logic available. In other examples, the pre-filter determination engine 320 can select pre-filter rules for respective network infrastructure devices based on a classification of the rules (e.g., based on tags) and traffic at the particular network infrastructure devices. For example, rules selected for a particular network infrastructure device may be associated with network traffic at the network infrastructure device.

[0051] Classification engine 322 can be used to classify network activity traveling through each of the network infrastructure devices 404, 408. One or more classifications can be associated with network traffic at the particular network infrastructure devices 404, 408. The SDN controller 300 can collect, via the interface engine 310 acting on a control plane, network statistics (e.g., from a data plane of the SDN 410). This can be performed in a standardized manner (e.g., using Openflow). Classification methods can then be performed on those statistics. The classification methods can include searching for particular types of information, for example, communication protocols used, identifiers of applications, identifiers of operating systems, etc. Further, the SDN controller 300 may receive additional information about known topology (e.g., via input). In other examples, network infrastructure devices may collect classification information and send the classification information to the SDN controller 300 and/or to other devices for data collection and processing. As such, the SDN controller 300 may receive classification information about the respective network infrastructure devices 404, 408 from the network infrastructure devices 404, 408 themselves and/or other data collection and/or processing devices.

[0052] In one example, edge network infrastructure device 408a may include network traffic to a computing device 430 or set of computing devices that is in a particular classification (e.g., server, desktop, mobile, etc.). The rules for that particular edge network infrastructure device 408a can be selected to protect that particular classification. This can be particularly useful because rules related to protecting a mail server may not be the same rules related to protecting desktops, which have user interaction. As such, each of the rules of the complete set may not need to be implemented on network traffic proceeding through edge network infrastructure device 408a.

[0053] In some examples, the SDN controller 300 can dynamically control which rules are implemented at network infrastructure devices 404, 408. For example, the SDN controller 300 can receive feedback of packets being processed by a network infrastructure device. The feedback can include, for example, classification information, such as an application associated with a particular flow or network activity at the network infrastructure device in general.

[0054] The engines 310, 320, 322 include hardware and/or combinations of hardware and programming to perform functions provided herein. Moreover, the modules (not shown) can include programing functions and/or combinations of programming functions to be executed by hardware as provided herein. When discussing the engines and modules, it is noted that functionality attributed to an engine can also be attributed to the corresponding module and vice versa. Moreover, functionality attributed to a particular module and/or engine may also be implemented using another module and/or engine.

[0055] A processor 330, such as a central processing unit (CPU) or a microprocessor suitable for retrieval and execution of instructions and/or electronic circuits can be configured to perform the functionality of any of the engines described herein. In certain scenarios, instructions and/or other information, such as topology, classifications, rules, etc., can be included in memory 332 or other memory. Moreover, in certain embodiments, some components can be utilized to implement functionality of other components described herein.

[0056] Modules (not shown) may include, for example, hardware devices including electronic circuitry for implementing the functionality described herein. In addition or as an alternative, each module may be implemented as a series of instructions encoded on a machine-readable storage medium and executable by at least one processor. It should be noted that, in some embodiments, some modules are implemented as hardware devices, while other modules are implemented as executable instructions.

[0057] FIG. 5 is a flowchart of a method for controlling configuration of implementation of pre-filter rules on network infrastructure devices, according to an example. FIG. 6 is a block diagram of a device capable of controlling configuration of implementation of pre-filter rules on network infrastructure devices, according to an example.

[0058] Although execution of method 500 is described below with reference to computing device 600, other suitable components for execution of method 500 can be utilized (e.g., SDN controller 300). Additionally, the components for executing the method 500 may be spread among multiple devices. Method 500 may be implemented in the form of executable instructions stored on a machine- readable storage medium, such as storage medium 620, and/or in the form of electronic circuitry.

[0059] Processor 610 may include at least one central processing unit (CPU), at least one semiconductor-based microprocessor, at least one graphics processing unit (GPU), at least one network processor, other hardware devices suitable for retrieval and execution of instructions stored in machine-readable storage medium 620, or combinations thereof. For example, the processor 610 may include multiple cores on a chip, include multiple cores across multiple chips, multiple cores across multiple devices (e.g., if the computing device 600 includes multiple node devices), or combinations thereof. Processor 610 may fetch, decode, and execute instructions 622, 624, 626, 628 to implement method 500. As an alternative or in addition to retrieving and executing instructions, processor 610 may include at least one integrated circuit (IC), other control logic, other electronic circuits, or combinations thereof that include a number of electronic components for performing the functionality of instructions 622, 624, 626, 628.

[0060] Machine-readable storage medium 620 may be any electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. Thus, machine-readable storage medium may be, for example, Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage drive, a Compact Disc Read Only Memory (CD-ROM), and the like. As such, the machine- readable storage medium can be non-transitory. As described in detail herein, machine-readable storage medium 620 may be encoded with a series of executable instructions for selecting pre-filter rules to implement at network infrastructure devices. Further, in some examples, the various instructions 622, 624, 626, 628 can be stored on different media.

[0061] At 502, the computing device 600 can communicate with network infrastructure devices of a network (e.g., a campus network) via a control plane by executing communication instructions 622 at processor 610. The computing device 600 can be used to configure one or more of the network infrastructure devices. The network infrastructure devices can include logic to implement a subset of pre-filter rules. The pre-filter rules are used to identify packets to forward to a network appliance, such as a deep packet inspection device of the network for further scrutiny. In certain examples, the further scrutiny can include a full deep packet inspection of one or more packets of a packet flow. As noted above, different pre-filter rules can be used for the respective network infrastructure devices.

[0062] The computing device 600 can execute pre-filter rule determination instructions 624 to determine subsets of pre-filter rules to implement at the respective network infrastructure devices at 504. In some examples, pre-filter rules for sets of the respective network infrastructure devices can be the same, while the pre-filter rules for other sets of the respective network infrastructure devices can be different.

[0063] As noted above, the determination of the pre-filter rules can be based on a network topology of the network. In one example, a first subset of the pre- filter rules can be determined for distribution network infrastructure devices. These network infrastructure devices are not directly connected to a final consumer of the packets (e.g., a client, a server, etc.). Further, in another example, a second subset of the pre-filter rules can be determined for a set of edge network infrastructure devices. These edge network infrastructure devices can be directly connected to a final consumer of packets. Additional subsets of pre-filter rules can be determined for other sets of the network infrastructure devices.

[0064] In one example, one of the sets of network infrastructure devices can be monitored to determine classifications of network activity traveling through the set. Classification instructions 626 can be executed by the processor 610 to determine the classifications. The rules selected for that set can be based on the classifications. This can be desirable, for example, for a set of edge network infrastructure devices that provide a connection to the network to particular computing devices, for example, the computing devices of a datacenter connected to the network. [0065] Different rules may be useful to protect communications for the datacenter than a set of desktop computers in an office section of the network. As such, a set of pre-filter rules related to desktop computer activity can be implemented on an edge network infrastructure device with desktop computer activity, while a different set is implemented on an edge network infrastructure device with server activity, and yet another set is implemented on an edge network infrastructure device with both desktop and mobile activity. Accordingly, some sets of pre-filter rules can include other sets of pre-filter rules or a portion of the sets of pre-filter rules.

[0066] In certain examples, the computing device can determine the subsets from a complete set of pre-filter rules derived from rules to search for signatures at a deep packet inspection device. In one example, the determination can be a selection of the subsets. In another example, the computing device 600 can provide criteria (e.g., via a query) and receive the subset of rules. It can be desirable for the computing device 600 to choose subsets of pre-filter rules in a manner such that the complete set of pre-filter rules can be implemented on a packet flow. Moreover, in some examples, pre-filter rules can be optimized for packet flows associated with classifications of activity. Once the pre-filter rules are set, associated traffic can be routed through that path.

[0067] At 506, the computing device can execute configuration instructions 628 to generate configuration messages for the respective sets of network infrastructure devices. As noted above, in one example, the configuration messages can include the sets of rules to implement, where the respective network infrastructure devices have the full set of pre-filter rules. In another example, the configuration message can include an update that can be implemented on logic at the respective network infrastructure devices to allow the logic to implement the pre-filtering rules. At 508, the communication instructions 622 can be executed to cause sending of the configuration messages to the respective network infrastructure devices.

[0068] FIG. 7 is a flowchart of a method for selecting pre-filter rules for network infrastructure devices based on a classification of network activity at the respective network infrastructure devices, according to an example. Although execution of method 700 is described below with reference to computing device 600, other suitable components for execution of method 700 can be utilized (e.g., SDN controller 300). Additionally, the components for executing the method 700 may be spread among multiple devices. Method 700 may be implemented in the form of executable instructions stored on a machine- readable storage medium, such as storage medium 620, and/or in the form of electronic circuitry.

[0069] Communication instructions 622 can be used to communicate with network infrastructure devices to monitor network activity traveling through the respective network infrastructure devices (702). For example, the computing device 600 can periodically collect, via a control plane of a network, information regarding network statistics of a data plane of the network. This can be performed in a standardized manner (e.g., using Openflow, operational support system technologies, business support system technologies, etc.).

[0070] At 704, the classification instructions 626 can be executed to determine classifications for the network activity at the respective network infrastructure devices based on the statistics. Classification methods can include searching for particular types of information used (e.g., communications protocols), identifiers of applications, identifiers of operating systems, etc.

[0071] At 706, the subset of pre-filter rules for the respective classified network infrastructure devices can be selected based on the classification as discussed above. As noted, pre-filter rules can be split to increase scalability and/or efficiency. As such, in certain examples, a set of connected network infrastructure devices with the same classification may each include a subset of a set of rules selected for a relationship to the classification. Thus, a packet flow forwarded through the set of network infrastructure devices that relates to the classification can be pre-filtered using the most relevant pre-filters.

Claims

CLAIMS What is claimed is:

1. A software defined networking controller comprising:

an interface engine to communicate with a plurality of network infrastructure devices of a network via a control plane,

wherein the network infrastructure devices each include logic to implement a subset of pre-filter rules, wherein the pre-filter rules are used to identify packets to forward to a deep packet inspection device of the network for further scrutiny; and

a pre-filter determination engine to: determine a first subset of the pre-filter rules to implement at a first one of the network infrastructure devices and generate a first configuration message to configure the first network infrastructure device with the first subset of the pre-filter rules, and to determine a second subset of the pre-filter rules to implement at a second one of the network infrastructure devices and to generate a second configuration message to configure the second network infrastructure device with the second subset of the pre-filter rules, wherein the first subset is different than the second subset; and

wherein the interface engine is further to send the first configuration message to the first network infrastructure device and send the second configuration message to the second network infrastructure device.

2. The software defined networking controller of claim 1 , wherein the first subset and the second subset are selected based on a network topology of the network.

3. The software defined networking controller of claim 2, further comprising:

a classification engine to determine a classification of network activity traveling through each of the respective network infrastructure devices, wherein the first subset and the second subset are selected based on the respective classification of the first network infrastructure device and the second network infrastructure device.

4. The software defined networking controller of claim 3, wherein the classification of network activity includes at least one of: server network activity, desktop network activity, and mobile network activity.

5. The software defined networking controller of claim 2, wherein the network topology includes whether respective network infrastructure devices are at an edge of the network, wherein the first subset is distributed to the first one network infrastructure device because the first one network infrastructure device is located at the edge of the network.

6. The software defined networking controller of claim 5, wherein the second subset is distributed to the second one network infrastructure device because the second one network infrastructure device is not located at the edge of the network.

7. A non-transitory machine-readable storage medium storing instructions that, if executed by at least one processor of a device, cause the device to: communicate with a plurality of network infrastructure devices of a campus network via a control plane,

wherein the network infrastructure devices each include logic to implement a subset of pre-filter rules, wherein the pre-filter rules are used to identify packets to forward to a deep packet inspection device of the campus network for further scrutiny; and

determine a first subset of the pre-filter rules to implement at a first set of the network infrastructure devices and generate a first configuration message to configure the first set of network infrastructure devices with the first subset of the pre-filter rules;

determine a second subset of the pre-filter rules to implement at a second subset of the network infrastructure devices and to generate a second configuration message to configure the second set of network infrastructure devices with the second subset of the pre-filter rules, wherein the first subset of pre-filter rules is different than the second subset of pre-filter rules;

send the first configuration message to the first set of network infrastructure devices via the control plane; and send the second configuration message to the second set of network infrastructure devices via the control plane.

8. The non-transitory machine-readable storage medium of claim 7, wherein the first subset of pre-filter rules is based on a network topology of the campus network.

9. The non-transitory machine-readable storage medium of claim 8, wherein the set of network infrastructure devices include distribution network infrastructure devices,

wherein the second subset of rules is based on the network topology of the campus network, and

wherein the second set of network infrastructure devices includes edge network infrastructure devices.

10. The non-transitory machine-readable storage medium of claim 9, wherein network activity traveling through the second set of network infrastructure devices is associated with a classification,

wherein the second set of rules is further based on the classification.

11. The non-transitory machine-readable storage medium of claim 10, wherein the classification of network activity includes at least one of: server network activity, desktop network activity, and mobile network activity.

12. The non-transitory machine-readable storage medium of claim 10, further comprising instructions that, if executed by the at least one processor, cause the device to:

determine a third subset of the pre-filter rules to implement at a third set of the network infrastructure devices that is different from the first subset and the second subset; and

generate a third configuration message to configure the third set of the network infrastructure devices with the third subset of the pre-filter rules,

wherein the third subset includes at least a portion of the second subset of rules.

13. A network system comprising:

a first network infrastructure device to forward first network packets on a network, the first network infrastructure device including a first logic to implement a first subset of pre-filter rules; and

a second network infrastructure device to forward second network packets on the network, the second network infrastructure device including a second logic to implement a second subset of the pre-filter rules, wherein the first subset and the second subset are different, and

wherein the first logic is to identify one of the first network packets using the first subset of pre-filter rules to forward to a deep packet inspection device of the network for further scrutiny.

14. The network system of claim 13,

wherein the first subset is associated with a first class of network activity the network system further comprising:

a first set of clients corresponding to the first class of the network activity, wherein the first network infrastructure device is topologically located between the first set of computing devices and other components of the network.

15. The network system of claim 13, further comprising:

a software defined network (SDN) controller to configure the first network infrastructure device to implement the first subset of pre-filter rules and the second network infrastructure device to implement the second subset of pre-filter rules,

wherein the SDN controller determines a first class of network activity to associate with the first network infrastructure device based on analysis of network activity that is passed through the first network infrastructure device,

wherein the first subset of pre-filter rules is selected based on the first class of network activity,

wherein the first class of network activity includes at least one of: server network activity, desktop network activity, and mobile device network activity.