Network Traffic Identification Device

Abstract

A network traffic device is disclosed, comprising at least one network device adapted to receive network data packets, the at least one network device filtering the network data packets to identify the location of at least one identified packet and sampling the network data packets to select at least one sample packet. The at least one network device forwards the at least one identified packet and the at least one sample packet to an analyzer. A predetermined sampling rate determines the number of sample packets selected by the at least one network device.

Description

[Technical Field]

[0001] The present invention relates to identifying traffic on a network, and more particularly to processing data at line rate speeds. [Background technology]

[0002] Various networking protocols divide messages or data into small packets that are then sent individually to a destination address. The paths taken by each packet to the destination address may not be identical, but when the packets arrive, they are nevertheless reassembled to recreate the original message.

[0003] Each packet may have a header and optionally a payload. The payload may contain the application-specific data being sent. The header contains several identifying details, such as the source address of the packet, the destination address the packet is heading to, the protocol, and the port. The header may also contain other attributes, such as the packet length and protocol metadata, among other details.

[0004] Multiple packets of data transmitted for a given application are considered a stream of packets, forming a flow. The payload of a flow is the combined payload of all packets, which, when reassembled, reflects the original data transmitted. Each of the packets in a flow may have the same source address, destination address, and protocol. Other attributes, such as ports, may also be available.

[0005] If the source and destination addresses are known, the networks between which the flow is traveling can be identified. Similarly, the type of service of a flow can be determined by its protocol and port. Specific port numbers are typically assigned to common services and uses. For example, port 25 of the Transmission Control Protocol (TCP) refers to the Simple Mail Transfer Protocol (SMTP) and is used for routing email between servers. Similarly, port 80 of TCP refers to the Hypertext Transfer Protocol (HTTP) and is used for web services.

[0006] Packets are routed across the network by different devices including address routing switches, which look at the destination address of the packet, and flow routing switches, which look at the source / destination address and / or protocol and port.

[0007] These routers and switches are very high performance and specialized to perform specific tasks (routing and switching). For example, a small (1 rack unit) data center switch may have 32 ports, each capable of 100Gbps line rate wire speed, giving bidirectional bandwidth and 6.4Tbps throughput, with fixed port-to-port latency. This is possible because the switch hardware uses application-specific integrated circuits (ASICs) that are dedicated and specialized for the switching task.

[0008] These speeds are not achievable on general-purpose processors such as x86 processors without sacrificing throughput performance.

[0009] Additionally, there may typically be other appliances within a computer network that perform other specialized functions, such as firewalls, WAN optimization, deep packet inspection (DPI), or other network functions. Due to the more complex nature of these specialized functions, these appliances cannot achieve the same bandwidth and throughput as ASIC-based switches. For example, the top-of-the-line Fortinet Model 3980E Next-Generation Firewall occupies five rack units and has 10 ports capable of 100 Gbps speeds, but only 28 Gbps of NGFW (Next-Generation Firewall) throughput using an enterprise traffic mix.

[0010] The mismatch between the throughput of data center core switches and network appliances means that it is impractical to deploy several network appliances or functions throughout a large network for economic and logistical reasons of cost and scale. As networks grow in size, the core of the network tends to consist only of switches and routers, with network appliances residing on the perimeter of the network or between networks, such as in DMZs or perimeter networks. This is particularly true in telecommunications and data center networks.

[0011] This particular problem, where core switches have significantly greater throughput than network appliances, is well known.

[0012] In the specific scenario of deep packet inspection (DPI), a known solution to the problem is to bypass traffic. In this solution, network switches on either side of a DPI appliance route specific traffic only through that appliance, bypassing the rest around it. The idea is to reduce the amount of network traffic flowing through a DPI system with limited throughput. However, the problem with this approach is that network switches may only route traffic based on information contained in the packet headers, and this level of information is not accurate enough.

[0013] To illustrate this point, consider a typical mix of internet traffic, the majority of which is HTTP and QUIC (Quick User Datagram Protocol Internet Connections) followed by HTTPS (Hypertext Transfer Protocol Secure). A possible breakdown of internet traffic in Australia is 55% streaming video, 20% general web browsing, 15% downloads, and 10% other. Streaming video is delivered over HTTPS and QUIC, general browsing over HTTPS and HTTP, downloads over HTTPS and HTTP, and the rest is a mix. Network switches can only differentiate traffic by protocol port (HTTPS / HTTP / QUIC) and source / destination IP address ranges. To maximize the benefit of a DPI solution, streaming video would be bypassed, but without inspecting the packet payload—something that traditional network switches cannot do—it is not possible to reliably separate streaming video from other HTTPS and QUIC traffic.

[0014] To further illustrate this, consider the case of encrypted traffic, such as an HTTPS or QUIC stream. DPI solutions deployed in non-enterprise environments (where traffic decryption is not possible) can only extract information from the unencrypted headers of HTTPS and QUIC streams. In particular, Transport Layer Security (TLS) certificate information and Server Name Indication (SNI) fields are useful for determining which application / domain the stream is associated with. This information is usually available in one specific packet within the stream, the identifying packet. The rest of the packets in this stream are encrypted and unintelligible, and are only useful for measuring the number of packets and the size of the stream.

[0015] Long-lived streams ("elephant flows"), such as downloads or streaming video, consist of hundreds or thousands of packets over long periods of time and use disproportionately more bandwidth than short-lived streams ("mouse flows"), such as typical web browsing.

[0016] This places a significant burden on the DPI appliances, primarily due to the fundamental problem that the capabilities of the core switch technology cannot be realized due to the limitations of the network appliances.

[0017] Another problem in network management is attempting to identify specific uses. For example, consider the data flows illustrated in FIG. 1. Shown are four data flows related to traffic from Netflix 80, Facebook 79, YouTube® 77, and general email 78 transmitted across network link 82. For illustrative purposes, and while not realistic, assume each data flow has only five packets. Each application has its identifying packets 32 and 35, along with a non-identifying packet 31. If the goal is to identify use of Facebook 35, the obvious option is to adopt the solution of FIG. 2 and submit each packet for analysis 83, i.e., apply DPI and look at the full packet payload of each packet transmitted between source 10 and destination 14. This can be an expensive option and is impractical for networks of significant size.

[0018] An alternative to the brute force option of Figure 2 is to use address routing, as shown in Figure 3, where packets are filtered by network. In the example shown, all traffic from the 10.0.0.0 / 8 network is sent for analysis 11. This significantly reduces the amount of data that is subject to analysis, but there are obvious risks in using it where it is desirable to recognize that the data resides on a different network.

[0019] A further alternative is flow routing, as shown in Figure 4, where packets are filtered by service. In this case, only web service packets are sent for analysis 11. In practice, this is only a slight improvement over the option in Figure 2, given that a large proportion of all Internet traffic, perhaps 90%, is web service related.

[0020] Therefore, there is a problem that the amount of data transmitted makes it impossible to identify the purpose for which the data is being used.

[0021] Another problem facing network management is large-scale traffic analysis. In data centers and enterprise networks, it is desirable to manage data traffic on the network to reduce congestion and latency, i.e., to ensure that data flows freely and that user experience is not adversely affected. This can be a problem, for example, where a small number of elephant flows consume available bandwidth, adversely affecting a large number of mice flows. The difficulty is that in order to manage network traffic, network traffic must be analyzed to determine bottlenecks and network congestion.

[0022] Large networks and data centers may have thousands of network links, each capable of operating at high speeds of 10G to 100G+. Typically, diagnostic probes or test access points (TAPs) are inserted into specific points in the network to monitor data. These probes are expensive, can only be attached to a single port, and have a limited throughput of approximately 100G.

[0023] A probe device 41 can be manually attached to a specific port 84 of a data center network, as shown in FIG. 5. The entire traffic on that port can then be analyzed. The problem is that only a single port can be of interest, and changing the probe to a different port 40 can be time-consuming. FIG. 6 illustrates an alternative approach to the TAP switch 86, where each port is attached to a dedicated TAP switch 86 and a probe device 41 is also attached to the switch 86. While changing links and ports to be analyzed can be quick, the same problem exists: only a single port can be probed at a time 85. FIG. 7 replaces the TAP switch 86 with a TAP network 89, which sends selected flows from multiple ports 87, 88 to the probe device, rather than sending the entire traffic down a port or link. Similar to the limitations discussed above in connection with FIG. 4, the TAP network also has limitations in identifying which flows to send and the practical amount of data that can be analyzed.

[0024] The problem is that network administrators cannot proactively monitor and manage traffic flows, but rather can only reactively address problems as they occur. Summary of the Invention [Problem to be solved by the invention]

[0025] Therefore, there is a need for an alternative approach to distinguishing traffic on a network and preferably utilizing the throughput available when using core switches. [Means for solving the problem]

[0026] In general terms, a network device is provided that is capable of filtering identified packets from network traffic and further sampling a predetermined percentage of packets from the network traffic.

[0027] In a first aspect, 1. A network traffic device comprising at least one network device adapted to receive network data packets, A network traffic device is provided, where at least one network device filters the network data packets to locate at least one identified packet and samples the network data packets to select at least one sample packet.

[0028] The identified packets and sample packets can then be sent to an analyzer, which can perform deep packet inspection (DPI) on the received packets.

[0029] Network devices are expected to contain programmable application-specific integrated circuits (ASICs) and operate only in the data plane.

[0030] The number of sample packets selected by the network device can be based on a predetermined sampling rate. The sample packets may be selected randomly or by selecting every Nth network data packet, where N is a predetermined number. N may be selected taking into account the desired sampling rate.

[0031] Preferably, the analyzer estimates (or substantially reconstructs) the flow information of the network data packets from the received packets and a predetermined sampling rate, which may be approximately 4% or 5%. The device may further comprise a load balancer that determines to which analyzer each received packet should be forwarded.

[0032] In another aspect, the present invention provides a method for producing a at least one network device operating only in the data plane, the at least one network device adapted to receive data packets from a data stream forming network traffic, the at least one network device adapted to filter the data packets to identify a location of each identified packet and to sample the data packets to select a predetermined number of sample packets; at least one analyzer adapted to perform deep packet inspection on received packets, the received packets including at least one identification packet and at least one sample packet; The present invention provides a network traffic device comprising:

[0033] Exemplary embodiments of the invention are described below with reference to the accompanying drawings, in which: Further features and advantages of the invention will become apparent from the accompanying specification. [Brief explanation of the drawings]

[0034] [Figure 1] FIG. 1 illustrates an exemplary scenario. [Figure 2] FIG. 2 illustrates one possible solution to the scenario of FIG. 1 using a brute force approach. [Figure 3] FIG. 2 illustrates another possible solution to the scenario of FIG. 1 using address routing. [Figure 4] FIG. 2 illustrates another possible solution to the scenario of FIG. 1 using flow routing. [Figure 5] FIG. 1 illustrates a network diagnostic approach using manual probes. [Figure 6] FIG. 6 shows an alternative approach to FIG. 5 using a TAP switch. [Figure 7] FIG. 6 illustrates another alternative approach to FIG. 5 using a TAP network. [Figure 8]FIG. 1 illustrates a possible hardware setup using the present invention. [Figure 9] 9 is an alternative view of FIG. 8 illustrating the vertical expansion capabilities of the present invention. [Figure 10] FIG. 10 illustrates the horizontal expansion feature of the present invention. [Figure 11] FIG. 1 illustrates a possible system setup using the present invention. [Figure 12] FIG. 10 is a screenshot of an HTTP packet. [Figure 13] FIG. 10 is a screenshot of an HTTPS packet. [Figure 14] FIG. 1 is a flow diagram of one approach to configuring a programmable network switch in accordance with the present invention. [Figure 15] FIG. 1 illustrates the approach of the present invention. [Figure 16] FIG. 2 illustrates a possible solution to the scenario of FIG. 1 using the present invention. [Figure 17] FIG. 6 illustrates an alternative approach to FIG. 5 using the present invention. [Figure 18] FIG. 1 illustrates a possible traffic management approach using the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0035] The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

[0036] The present invention describes a novel approach to identifying traffic on a network. The system is capable of operating at line-rate speeds, thereby avoiding the bottlenecks faced by current techniques that rely on known network appliances. In a preferred embodiment, the present invention sends a copy of network traffic through a device that filters identified packets and sends only those identified packets to a DPI appliance. In a preferred configuration, the device also samples non-identified packets and sends a predetermined percentage, such as 1 in 1000, to the DPI appliance for counting or analysis. This device advantageously operates at the speed of a network switch and can send only useful packets to the DPI for processing.

[0037] The present invention can utilize a programmable ASIC chip, such as Tofino, available from Barefoot Networks. The ASIC chip can be programmed using a software development kit (SDK) in the P4 programming language and can operate at line-rate speeds. This chip can function as a powered network switch and can be configured to send copies of packets that match certain packet header conditions and / or certain packet payload conditions to other devices for processing / inspection.

[0038] Another embodiment of the invention is a server (x86 or similar) that processes and inspects packets extracted by the chip. The output of this analysis process can be fed to other devices / systems, made available for viewing by an operator, and / or collected for later use.

[0039] In its basic configuration, as shown in Figure 8, one embodiment comprises a hardware network device 11 that includes a fully programmable switching ASIC chip operating at line rate with multiple high-speed ports (e.g., 32 x 100 Gbps ports). Network device 11 receives input from a source network 10, for example, via either a Switch Port Analyser (SPAN) port or an optical TAP. In one embodiment, the output of network device 11 is passed to analysis device 12 for processing identified packets, preferably a sampled packet stream, to generate a desired analysis output 13.

[0040] In this configuration, the source network 10 provides a copy of the network traffic to the network device 11. This is not required, but is applicable when the network device 11 is operating out-of-band, as it passes traffic when operating inline. The network device 11 can also be located within the source network 10 itself, and can perform traditional network switching functions in addition to the specific functions of the present invention. In either case, the programmable network device 11 receives input from the source network 10.

[0041] An analysis device 12 is connected to the network device 11 to receive the output after filtering and packet encapsulation.

[0042] According to one embodiment, everything from the source network 10 through the network device 11 to just before the analysis device 12 operates in the data plane at line rate. No control plane involvement is required, eliminating sources of latency and potential bottlenecks. That is, throughput is equal to the available bandwidth, there are no throughput limitations, and the network device 11 operates at line rate. Therefore, the analysis device 12 should be scaled sufficiently to handle the configured amount of network traffic output by the network device 11 after filtering. In this regard, this configuration can be changed by an operator as needed, allowing anything from all packets, to none, to a certain percentage of packets to be passed to the analysis device 12. Applicant believes that in realistic scenarios, a sampling rate of approximately 4% to 5% is sufficient to identify network flow applications and accurately estimate network flow statistics.

[0043] The network device 11 may be configured to act as a filter, for example, the network device 11 may be configured to receive a copy of each packet flowing through the source network 10 and send only those packets that meet the filter criteria to the analysis device 12.

[0044] A typical network device 11 might have 32 ports, each operating at a speed of 100 Gbps. One or two of those ports can be used as outputs, and up to 30 ports are provided for input. Applying a 4% sampling rate to a 30 x 100 Gbps input results in an output of 3,000 Gbps * 4% = 120 Gbps. If the network link is always only 80% utilized on average at peak, this results in an output of 120 Gbps * 80% = 96 Gbps. This can be accommodated by a single 100 Gbps output port, and depending on the size of the analysis device, by one or more analysis devices 12.

[0045] As the number of input ports increases, the solution of the present invention can also be scaled by deploying more hardware and adding intermediate tiers, an option not available in conventional systems. As shown in FIG. 10, multiple network devices 11 and 16 interconnect to receive and filter data from source networks 10, and distribute the filtered output across multiple analysis devices 12. This can be scaled horizontally as needed until the aggregation network device 16 is operating beyond capacity. According to one embodiment, the entire solution can now be replicated and scaled indefinitely, with flow data 13 records deduplicated and consolidated as needed.

[0046] To illustrate this, in FIG. 11 , assume there is a network in which 21 Tbps of traffic 90 flows between a user 15 and the Internet 17. This represents nearly double the residential Internet connection capacity of the Australian National Broadband Network as of September 2019. For purposes of exercise, the network is assumed to have an unrealistically high utilization rate of 80%, and the system is sampling at a rate of 4%. With this configuration, in the present invention, a copy 91 of the 21 Tbps of traffic flowing between the user and the Internet is fed to an 18x network device 11 operating at the edge. Each 100 Gbps bidirectional link 93 is converted to a pair of 100 Gbps unidirectional link inputs 92. Each of the edge programmable network switches filters and samples the data 97 to an approximately 96 Gbps output 96. This is fed to an analysis device 12 via an intermediate network device 16 that performs an aggregation function. The requirements for the 45x analysis devices would normally be very high capacity, but we will assume that each can only handle 40 Gbps of network traffic.

[0047] This may be preferable compared to currently available network packet broker solutions that are unable to perform network packet sampling. To attempt to replicate the present invention, a network packet broker configuration may require the addition of 1,350x servers (each handling 40G of input) or dedicated "service appliances." Thus, currently available network packet broker solutions may lead to a bottleneck in that sampling 4% of total traffic requires enough servers / service appliances to handle all of the network traffic flowing through the network in addition to the network packet broker switch itself.

[0048] The present invention can sample packets, both randomly and selectively, identifying packets only in the data plane at line-rate speeds while still performing cut-through processing. Advantageously, as presented herein, it may not require routing to other devices, sacrificing line-rate speeds, delaying packets, or involving the control plane. Furthermore, since it is not a flow-based solution, there is no limit to the number of flows that may be processed.

[0049] Because existing analysis tools / probe devices expect to receive a complete feed of network traffic rather than sampled data, the analysis device 12 of embodiments of the present invention receives a different data structure. Along with the identified packets, the analysis device 12 also receives other randomly sampled packets, de-encapsulates them, and performs analysis. This is beneficial because it can generate other outputs along with the flow data.

[0050] The analysis device 12 may be implemented in a general purpose computer (x86), an FPGA (Field Programmable Gate Array), or dedicated hardware.

[0051] Switch Configuration In one embodiment, network device 11 is configurable (eg, via a "table") to allow for the identification of packets of interest and to determine how identified packets are to be treated.

[0052] Preferably, a matching table is constructed that matches packets with specific headers of interest, ideally against at least the first six bytes of the payload. While exact matches can be effective, for efficiency, this matching should be ternary / wildcard based. Ternary matching allows the operator to easily configure "don't care" values ​​rather than having to exhaustively enumerate all possible match values.

[0053] [Table 1]

[0054] Using the above matching table, a matching rule is created to detect HTTP and HTTPS identified packets, as well as sample 4% of HTTP and HTTPS traffic (ignoring all other traffic) as follows: 1.HTTP a. Select TCP packets with either a source or destination port of 80 (HTTP) that have a payload that starts with "GET / " (HTTP GET) and sample them at 100% with rule priority 1. b. Select TCP packets with either a source or destination port of 80 (HTTP) and sample them at 4% with rule priority 2. 2. HTTPS a. Select TCP packets with either a source or destination port of 443 (HTTPS) that have a first byte of payload of 0x16 (hex) and a sixth byte of payload (HTTPS Client Hello) of 0x01 (hex), and sample them at 100% with rule priority 1. b. Select TCP packets with either a source or destination port of 443 (HTTPS) and sample them at 4% with rule priority 2 The first rule in each set extracts all of the identified packets, and the second rule in each set samples 4% of the non-identified packets.

[0055] HTTP Identification Packet In one embodiment, for HTTP connections, the invention is interested in packets containing a Host header. Typically, an HTTP request begins by issuing a packet containing one of the following request methods from a client to a server: GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, or PATCH. These appear at the beginning of the packet payload, so the system can match using wildcards to select packets that begin with those words. It is possible that other packets may randomly begin with those characters, but this is very rare and may be treated by the analysis server as a random sample.

[0056] The screenshot in Figure 12 shows an HTTP packet from a GET request. The packet protocol 20 is TCP, the destination port 21 is 80, and the first few bytes of the packet payload 22 are GET / . A filter can be applied in the network device 11 to send a copy of this packet to the analysis device 12. The analysis device 12 can then look more closely at the packet payload to find Host: 23 to determine the name of the server to which the HTTP GET request is being sent.

[0057] The content may be of interest because HTTP is unencrypted; however, most Internet traffic is typically encrypted. By applying random sampling to HTTP packets, network device 11 can send a small, representative portion of the HTTP packets to an analysis device. This allows the analysis device to estimate the number of packets in a flow, the size of the flow, when the flow began, and when the flow ended. By knowing the sampling rate applied to select a given packet, the analysis device can estimate the number of packets in the flow and the size of the flow by simple extrapolation. For example, if a sampled packet is received with a 1 in 20 probability, the system can add 20 to the number of packets in the flow, multiplying the size of the packet by 20 to the size of the flow.

[0058] HTTPS Identification Packet In one embodiment, for HTTPS packets, the system looks at the Server Name indication field 24 present in the Client Hello 25 handshake packet and / or the Common Name field present in the certificate after the Server Hello handshake packet.

[0059] HTTPS packets can be identified by their TCP protocol 20 and port 21, which is 443. Client Hello handshake packets are sent from a client to a server, which results in a destination port of 443. Server Hello handshake packets are sent from a server to a client, which results in a source port of 443. TLS handshake packets have a first payload (handshake) of 0x16 hex bytes and a sixth payload of either 0x01 hex bytes (Client Hello) or 0x02 hex bytes (Server Hello).

[0060] 13 is a screenshot showing an HTTPS network packet containing a Client Hello. Deeper within the packet's payload, a Server Name indication 24 extension indicates the name of the server to which the request was sent.

[0061] A similar approach may be used to identify packets for other protocols, such as QUIC, although it will be appreciated that other matching criteria may be used, such as packet signatures discovered by machine learning models.

[0062] Flow Hash Once a packet is selected by the matching table and a rule recognizes that it may not be sent if it has a sampling rate of less than 100%, a decision is made as to whether to send the packet to an analysis device 12. While a single analysis device 12 is sufficient for a small network, to scale the invention horizontally, the system would ideally distribute the load across multiple analysis devices, in which case the system could decide to which analysis device 12 to send the packet.

[0063] In doing so, to avoid correlation problems when packets of a single flow are sent to different analysis devices, it may be desirable for all packets of a single flow to be sent to the same analysis device 12. To aid in this process, a preferred implementation of the present invention calculates a flow hash of the packets.

[0064] Each flow can be uniquely identified by protocol and source / destination addresses and ports. Depending on the network, additional packet headers such as VLAN or MPLS tags may also be required. Flows operate in both upload and download directions (client to server and server to client). Strictly speaking, each is a separate flow. However, the system may prefer that packets from both the upload and download directions are sent to the same analysis device 12. This is to more easily correlate upload and download packets; when an identifying packet is detected on, for example, an upload flow, the system can simultaneously apply that information to the corresponding download flow.

[0065] The flow hash can be calculated by using a one-way hash of the flow as follows: 1. If the protocol is not TCP or UDP (which is relatively rare), the system calculates the flow hash of the packet from the EtherType and payload bytes 1 to 6. This results in packets being randomly distributed among the analysis devices. 2. The system then decides whether the flow is an "upload" or a "download" flow. This can be done deterministically. For TCP and UDP flows, one option is to use the source and destination ports, and if the source port is higher than or equal to the destination port, consider the flow to be an "upload", otherwise it is considered to be a "download" flow. 3. For "upload" flows, the system calculates a flow hash from the protocol, source address, destination address, source port, and destination port. 4. For "download" flows, the system calculates a flow hash from the protocol, destination address, source address, destination port, and source port.

[0066] The order of the flow hashes is reversed for each upload and download flow to ensure that the flow hash for a download flow is the same as the corresponding upload flow. The actual flow hash value is not determinative, and alternate flow hashes can be used if desired. The important thing is to ensure that the same hash value is output for a given flow regardless of which direction the packets are traveling.

[0067] Once the flow hash is determined, the system looks up the output table and load balances the packet.

[0068] Output table If multiple analysis devices 12 are present, an output table can be used to determine to which analysis device 12 a given packet should be sent for processing.

[0069] [Table 2]

[0070] According to the above table, a range of possible flow hash values ​​(e.g., 0 to 65535) may be entered, with a portion of this range associated with each available analysis device 12. Overlapping ranges are allowed, and ties can be broken using rule priorities to remove one analysis device 12 by falling back to an alternate device or default to ensure uninterrupted operation.

[0071] Network Devices In a preferred configuration, although it will be appreciated that alternative configurations are possible, the network device may be configured according to the flowchart of Figure 14. The network device 11 receives an incoming packet 20 and then parses the packet header and packet payload, or preferably at least the first six bytes of the payload 21. Ideally, at least the headers Ethernet, IPv4 / IPv6, TCP / UDP, and the payload are parsed.

[0072] The next step in the flowchart of Figure 14 is to calculate a flow hash to assist with load balancing. 22 However, this step is optional and may instead be performed later, if preferred. To calculate the flow hash, a decision is made as to which fields should be identified to uniquely identify the flow. (For example, as discussed above, these may be the protocol, source address, destination address, source port, and destination port.)

[0073] Those fields that are swapped when packets are flowing in the opposite direction need to be identified; for example, the source and destination addresses can be swapped, as can the source and destination ports. An arbitrary decision can be made as to whether to swap swappable fields for the "upload" or "download" direction, and then a flow hash can be calculated by applying a one-way hash function to fields that uniquely identify the flow, swapping the packets' swappable fields in one direction. The result should be the same for any packet in a flow going either way.

[0074] For example, if there is a TCP connection between host A address 10.0.0.1, port 1111 and host B address 10.0.0.2, port 2222, the flow hash can be calculated as follows: [Table 3]

[0075] A random number is optionally generated that can be used in conjunction with the sampling rate 23. This random number can be generated in different steps if preferred.

[0076] The network device 11 matches the parsed data from the packet header and the packet payload against a matching table 24. This matching table must be defined to match packets of interest and must include at least the identified packet. The sampling rate may also be configured in the matching table, or may be configured elsewhere. The matching table may be divided into several different tables, possibly with variable fields to match. In each scenario, the matching table determines whether the packet is of interest. Fields may be tested for matching using exact ternary ranges or other matching methods.

[0077] If the data matches, the random number can be used in conjunction with the sampling rate to determine if the packet will be sampled and analyzed. This can be done in a number of ways. For example, if the random number is given as a number between 0 and 1024 and the sampling rate is 50%, then if the random number is below 512 the packet will be sampled, and if the random number is above 512 it will not be sampled.

[0078] The flow hash is then optionally matched 26 against an output table to determine which analysis device 12 the packet goes to, and the packet is then forwarded to the destination analysis server 12. This particular load balancing method is optional; alternatively, a single analysis device 12 is used, or separate load balancing mechanisms are used.

[0079] Variations on this process may also depend on the implementation. For example, if load balancing is done differently, it may not be necessary to calculate and use the flow hash and output. Similarly, if the sampling rate were 100% for a small network, it may not be necessary to generate a random number. Additionally, rather than using a random number, one out of every N packets (e.g., N>1) may be selected instead.

[0080] analytical devices The analysis device 12 can be configured to perform a range of tasks. According to one embodiment, the basic use mentioned above is to handle identified packets and reconstruct flow information from sampled data.

[0081] Assuming the matching table configuration described above is available to the analysis device 12, the analysis device 12 should have enough information to construct the necessary data. If a matching table is not available, the packet is encapsulated with the applied sampling rate information. The analysis device 12 can determine which sampling rate was applied to the packet and use that to extrapolate the number of packets in the flow and / or the size of the flow. The analysis device 12 can also attempt to read the contents of any identified packets to identify more information about the flow. Metadata about the flow itself can be kept in a cache so that it can be updated as more flow packets arrive, and an expiration mechanism on the cache can be used to detect the end of the flow.

[0082] Many alternatives are available. For example, if desired, the functionality of the analysis device can be split and performed by separate components. Flow information may not be cached but sent to a data store for correlation by other processes. Flow termination may also be detected by looking more closely at the contents of packets, such as TCP FIN packets.

[0083] According to one embodiment, the analysis device 12 is configured to estimate the size of the flow (number of packets and total size in bytes) from the sampled packets it has been provided with. This estimation can be performed in several different ways. Preferably, the analysis device 12 has at least the sampled packets that have been delivered and also has knowledge of the probability / sampling rate at which each packet was extracted.

[0084] The analysis device 12 (or some component) may further examine the identifying packet to extract that information and add it to the flow's metadata.

[0085] In response, in one embodiment, the analysis device 12 receives the sampled packet and determines the sampling rate / probability at which it was extracted. Upon obtaining this data, the analysis device 12 updates the packet flow metadata based on the packet content (e.g., the identification packet) and estimates of the number of flow packets and the total size of the flow. For example, in a simple approach, if a 20% sampling rate is applied, the analysis device 12 adds 5 to the number of packets and multiplies the size of the packets by 5 for the total size. That is, the data analyzed by the analysis device 12 is extrapolated to estimate the results if the sampling rate were 100%.

[0086] When looking at the contents of a packet, the analyzing device 12 may determine if there is further useful information that can be extracted. For example, in the case of an HTTP packet, the analyzing device 12 may check if it is a GET, POST, PUT, PATCH, DELETE, OPTIONS, HEAD, or TRACE request and extract the host accordingly. Similarly, in the case of an HTTPS packet, the analyzing device 12 may check if it is a handshake packet with a Client Hello or Server Hello and extract the Server Name Indication or Certificate Common Name.

[0087] Sampling Approach According to one embodiment, a low sampling rate (e.g., 4%) is applied to all packets, and all identified packets are sampled. If the sampling rate is sufficient for the network traffic profile (typically 4% to 5%), the size of the sample from the total number of packets provides a good estimate of the true number of packets and the size of each flow. Smaller, more simplified flows are less accurate than larger, long-lived flows. However, large, long-lived flows typically have the greatest impact on the network, and therefore are of greater interest to network operators. Evidence of smaller flows can still be seen by extracting their identified packets.

[0088] By extracting all identified packets, the present invention can extract packets of interest from a flow without having to process the entire flow, as configured by the system operator.

[0089] This illustration is shown in Figure 15, where a source 10 sends packets to a destination 14. A network device 11 of the present invention sits in the middle and selectively extracts packets.

[0090] In this example, there are four flows, each with five packets 31 (although more generally each flow may have any number of packets), numbered 1, 2, 3, and 4. Flows 1, 2, and 4 contain an identifying packet 32. Note that only one packet (or very few packets compared to the number of other packets in the flow) is the identifying packet; the rest of the flow is not of interest for this application.

[0091] To analyze the data, conventional solutions may need to inspect and process a total of 4 x 5 = 20 packets. However, by randomly sampling some packets and sampling all identified packets, the present invention achieves a similar result without having to process all 20 packets. In this case, network device 11 still inspects all 20 packets, but in this example, assume that only 5 packets terminate at analysis device 12 as identified packets 98 and some randomly sampled packets 99.

[0092] Returning to the example of Figure 1 and the goal of identifying Facebook usage, the present invention provides an ideal tool. As shown in Figure 16, the present invention can receive data from source 10, detect each of the identification packets 32 for analysis, and thereby locate the Facebook identification packets 35. In this example, three packets are sent for analysis, which is very beneficial since the analysis compares them to the 20 packets that needed analysis in the example of Figure 2.

[0093] Similarly, the present invention can provide significant improvements in analyzing traffic flows. The examples of Figures 5 through 7 illustrate the limitations faced by network operators, or at least their inability to monitor all of a network's internal traffic. Adopting the approach illustrated in Figure 15 of selecting identifying packets 98 and random packets 99, an improved approach to network monitoring is shown in Figure 17. In this scenario, all ports 40 are attached to a network device 11 of the present invention, which may further be connected to a diagnostic probe device 41. This approach allows a network operator to identify all of the internal traffic on the network. By analyzing the identifying packets, the system can identify applications running on the network. The system can also provide data feeds for intrusion detection, application monitoring, traffic analysis, and network diagnostics.

[0094] This data can be particularly useful in traffic management, where a general goal is to improve customer experience, especially during peak hours. Large elephant flows, such as software updates, which are generally not critical, can consume a large portion of available bandwidth for an extended period of time. This can have the effect of blocking other flows, such as web browsing traffic. For the end consumer, this can mean delays in loading web pages, and the responsibility usually lies with the service provider.

[0095] By employing the present invention, unwanted, bandwidth-intensive elephant flows can be identified, and Quality of Service (QoS) policies can be applied to limit their impact. For example, a distinction can be made between game play and game downloads of popular games. Once this distinction is made, game downloads, but not game play, can be rate-limited to achieve bandwidth savings, allowing other data to move more freely on the network. Similarly, updates to other software and operating systems can be limited to ensure that mice flows are not adversely affected.

[0096] This can be achieved by the configuration shown in Figure 18. The optical TAP 45 can use an out-of-line copy of all upload and download traffic 46 and feed this to the network device 11 of the present invention. The network device 11 detects all identified packets and forwards them to the analysis device 12 for packet inspection. A percentage of samples of the remaining packets can be transmitted.

[0097] The analysis device, which may be x86, performs packet inspection on incoming packets to the fingerprint application and can track flow counters to detect elephant flow start and end events. Elephant flows can be matched against a table of undesired applications, and if a match is found, an undesired application flow notification 49 can be sent to network policy enforcement 50. Network policy enforcement 50 can then limit the flow volume of the violating application or take any other corrective action that may be selected. For example, elephant flows can be marked to be placed in a low priority queue.

[0098] The present invention is advantageous because it addresses the scaling problem, overcoming the technical limitations of current technology, which cannot view all data on a network or scale to encompass the entire network. The present invention allows for filtering of network packets at line rate, at relatively low cost, and at scale, something existing systems have been unable to achieve.

[0099] Compared to network packet brokers, the present invention offers a unique combination of features, including random sampling of packets from flows that match criteria, and extraction of packets from flows that match criteria, where the criteria includes portions of the packet payload as well as the packet header. Existing network packet brokers cannot perform both of these functions unless they are connected to some other device. Relying on such connections means they cannot operate at the speeds of data center network switches. The present invention enables both of these features to operate at line-rate speeds.

[0100] Additionally, while matching against packet payloads in commercially available network packet brokers is typically limited to the first 128 bytes of the packet, the present invention allows for very detailed matching of over 300 bytes.

[0101] The present invention can be deployed at scale across a network as a network packet broker, with the added benefit of enabling analysis of network traffic at scale, and can therefore be used to proactively identify network problems, collect flow metadata records for analysis and feeding into security systems, provide real-time protocol (DHCP, DNS) data extraction, and provide new levels of granular network visibility.

[0102] In comparison to a standalone DPI appliance, the present invention does not rely on receiving a complete copy of a given packet stream, but rather only extracts packets of interest and a random sample of other packets of interest. The present invention can see every packet, but does not have the processing overhead requirements of a DPI appliance.

[0103] Similar to standard flow-based network switches (e.g., OpenFlow), the present invention can count streams / flows in terms of packet count and byte size. However, flow-based network switches are limited in the number of simultaneous flows they can handle, typically only a few million. When a flow-based network switch runs out of its limited flow table memory, the switch will evict other active streams from the flow table, causing congestion and placing additional load on the switch's SDN (Software Defined Networking) controller. Simply put, flow-based switches do not function at scale. The present invention, on the other hand, can be scaled as needed.

[0104] While this embodiment has been described in the context of a switch or filter, the core of the invention is the extraction of identifying packets from a data stream. This, along with the extraction of samples of other packets from the stream, allows an analyzer to derive data necessary for a particular implementation. For example, an application could be monitoring traffic flowing through a network to proactively manage available bandwidth. An alternative could be monitoring traffic from a source or to a destination, or the effectiveness of a particular application on a network. In a further alternative, it could be used to limit the dissemination of unwanted information, such as from known terrorist groups. These applications cannot currently be undertaken except with a largely token effort. The inventive feature of extracting identifying packets along with a random sample of packets significantly reduces the data to be analyzed without relying on a large portion of the data being bypassed. Those skilled in the art will appreciate that the underlying invention can be used for many different applications, such as those described above.

[0105] References throughout this specification to "one embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. Thus, appearances of the phrase "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment.

[0106] Moreover, in interpreting this disclosure, all terms should be interpreted in the broadest reasonable manner consistent with the context. In particular, the terms "comprises" and "comprising" should be interpreted as referring non-exclusively to elements, components, or steps, and indicate that a referenced element, component, or step may be present in, utilized with, or combined with other elements, components, or steps not expressly referenced.

[0107] As used herein, terms such as "switch," "server," "port," "processor," and the like, unless the context requires, should be understood to refer to a range of possible implementations of devices, apparatus, and systems comprising a combination of hardware and software.

[0108] Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more combinations. Those skilled in the art will recognize that the invention may be implemented in ways other than those described above, and that variations may be made without departing from the spirit and scope of the invention.

[0109] Any description of documents, devices, acts, or knowledge in this specification is included to explain the context of the invention and is not to be construed as an admission that any of the foregoing constitutes prior art or part of the relevant art, any country, or general common knowledge at or before the filing date of this application to which this specification pertains. [Explanation of symbols]

[0110] 10 Source 11 Network Devices 12 Analytical Devices 13 Flow Data 14 Destination

Claims

1. receiving network data packets, each having a packet header and a packet payload; performing filtering to filter the network data packets according to predetermined criteria, the filtering including inspecting at least a portion of a packet payload of the received network data packets, identifying each of the inspected portions of the packet payload as at least one identified packet if it satisfies the predetermined criteria, and identifying the received network data packets that do not satisfy the predetermined criteria as non-identified packets; sampling the non-identified packets according to a sampling rule to select at least one sample packet; A network device that transmits at least one identification packet and at least one sample packet to an analyzer.

2. 10. The network device of claim 1, wherein the network device comprises a programmable Application Specific Integrated Circuit (ASIC).

3. The network device according to claim 1 or 2, wherein the network device operates only in the data plane.

4. The network device according to claim 1 , wherein the sampling rule includes a predetermined sampling rate that defines a number of sample packets.

5. 5. The network device of claim 1, wherein the analyzer performs deep packet inspection on received packets, the received packets including the at least one identification packet and the at least one sample packet.

6. The network device of claim 4 , wherein the analyzer estimates flow information of the network data packets from the received packets and the predetermined sampling rate, the flow information including the number of packets in a flow and the size of the flow.

7. The network device further transmits the at least one identifying packet and the at least one sample packet to a load balancer; 7. The network device of claim 1, wherein the load balancer determines to which of the at least two analyzers the at least one identifying packet and the at least one sample packet are sent.

8. The network device of claim 4 , wherein the predetermined sampling rate is approximately 4% or 5%.

9. The network device of claim 1 , wherein the sampling rule randomly determines the at least one sample packet.

10. 10. The network device of claim 1, wherein the sampling rule defines every Nth network data packet as a sample packet, where N is a predetermined number.

11. At least one network device operating only in the data plane, receiving network data packets, each having a packet header and a packet payload; performing filtering to filter the network data packets according to predetermined criteria, the filtering including inspecting at least a portion of a packet payload of the received network data packets, identifying each of the inspected portions of the packet payload as at least one identified packet if it satisfies the predetermined criteria, and identifying the received network data packets that do not satisfy the predetermined criteria as non-identified packets; sampling the non-identified packets according to a sampling rule to select at least one sample packet; a network device that transmits at least one identification packet and at least one sample packet to an analyzer; at least one analyzer that performs deep packet inspection on received packets, the received packets including the at least one identification packet and the at least one sample packet; A network traffic device comprising:

12. 2. The network device of claim 1, wherein the filtering further comprises inspecting at least a portion of the packet headers of the received network data packets and identifying at least one identified packet for which both the inspected portion of the packet payload and the inspected portion of the packet header satisfy the predetermined criteria.

13. The network device of claim 1 , wherein the filtering includes examining at least the first 6 bytes of the packet payload.

14. The network traffic device of claim 11 , wherein the at least one network device comprises a programmable ASIC.

15. The network traffic device of claim 11 , wherein the sampling rules include a predetermined sampling rate that defines a number of sample packets.

16. 16. The network traffic device of claim 15, wherein the predetermined sampling rate is approximately 4% or 5%.

17. 16. The network traffic device of claim 15, wherein the analyzer estimates flow information including a number of packets in a flow of network data packets and a size of the flow from the received packets and the predetermined sampling rate.

18. Further, the system includes a load balancer and at least two analyzers; sending the at least one identifying packet and the at least one sample packet to the load balancer; The network traffic device of claim 11 , wherein the load balancer determines to which of the at least two analyzers the at least one identifying packet and the at least one sample packet are sent.

19. 12. The network traffic device of claim 11, wherein the filtering further comprises inspecting at least a portion of the packet headers of the received network data packets and identifying at least one identified packet for which both the inspected portion of the packet payload and the inspected portion of the packet header satisfy the predetermined criteria.

20. The network traffic device of claim 11 , wherein the filtering includes examining at least the first six bytes of the packet payload.

Images