RU2786178C1 - Method for tracking sessions in network traffic - Google Patents

Abstract

FIELD: data networks.

SUBSTANCE: invention relates to the field of systems for monitoring and analyzing data networks. The effect is achieved by extracting Ethernet, IP and TCP/UDP headers from the packet and forming a descriptor based on them. Based on the header fields of the IP address packet, L4 protocol code, TCP/UDP ports, the HASH sum of the session is calculated. In the RAM cell, the address of which is equal to the received HASH sum of the session, a search is made for information about the already received packet with the same HASH sum of the session. Based on the results of comparison with the data from the descriptor, the package is assigned an identifier - the value of the ACTION field, on the basis of which a decision is made about further actions on the package.

EFFECT: enabling the operation of traffic pre-processing devices with ensuring the integrity of information flows transmitted via TCP/UDP sessions.

1 cl, 7 dwg, 1 tbl

Description

Technical field

The invention relates to the field of building systems for monitoring and analyzing data transmission networks, and in particular to methods for high-speed search and tracking of TCP / UDP sessions in high-load networks, can be used in pre-processing devices for deep network traffic analysis systems that support the TCP / IP protocol stack. The claimed method is aimed at providing network packet processing functions, such as filtering and balancing, taking into account belonging to TCP or UDP protocol sessions and can be applied in network traffic preprocessing devices.

State of the art

Known methods for tracking sessions for load balancing on server systems "Global server load balancing", patent US 7454500 B1, G06F 15/173, 11/18/2008, "Server load balancing using IP option field approach to identify route to selected server", US patent 7088718 B1, H04L 12/28, 08/08/2006, their disadvantages are the impossibility of ensuring the integrity of information flows transmitted over TCP / UDP sessions, as well as the impossibility of implementing traffic pre-processing devices based on a reprogrammable logic integrated circuit (FPGA) or ultra-large integrated circuit (VLSI).

The technical result of the proposed invention is to ensure the functioning of traffic pre-processing devices with ensuring the integrity of information flows transmitted via TCP/UDP sessions.

The stated technical result is achieved by the fact that a method for tracking sessions in network traffic is proposed, which consists in tracking sessions for load balancing on server systems, where the network packet, after receiving, is transmitted to the packet analysis unit, in which Ethernet, IP and TCP / UDP are separated from the packet headers, the L4 protocol code and the formation of an information block - a descriptor on their basis, then the packet is stored in the packet buffer, and the descriptor - in the descriptor buffer and then in the session search block, in which the HASH sum of the session is calculated using the Galois authentication counter algorithm IP addresses of the recipient and sender, TCP / UDP ports of the recipient and sender, and the L4 protocol code, while in order to resolve collisions that occur when tracking a session based on the HASH sum of the session, one cell of the session RAM contains records with information on at least four sessions, then the session lookup block checks the session RAM location whose address is en HASH-sum of the session, the presence of information consisting of the fields of the headers of the packet, according to which the calculation of the HASH-sum of the session was performed, about the already received packet with the same HASH-sum of the session, if the cell already contains information, then it is compared with the data from descriptor, if information about the session is not found, then the descriptor is transferred to the session processing block, the set of rules that defines the switching rules is stored in the RAM memory of the rules, the session processing block searches for the rule that the descriptor falls under, which is carried out until the first match, if the match is not found, then the packet is discarded, the value of the ACTION field is set to the descriptor based on the results of the search, and the descriptor is transferred to the session search block, which writes the ACTION value from the descriptor to the corresponding cell of the sessions RAM memory, then the switching block, based on the ACTION value, either removes the packet from the packet buffer, or passes the packet to the appropriate output interface.

The analysis of the prior art makes it possible to determine that the proposed technical solution is new and has an inventive step, and the possibility of its use in industry determines it as industrially applicable.

These and other aspects will become apparent and will be explained with reference to the drawing and the embodiment described below.

The invention is illustrated by the following graphics:

Fig. 1 is a diagram illustrating the functional blocks that implement the proposed method for tracking sessions in network traffic.

Fig. 2 is a diagram illustrating an example of balancing while maintaining the integrity of information sessions.

Fig. 3 is a diagram illustrating the structure of the descriptor.

Fig. 4 is a diagram illustrating the structure of a session record in RAM memory.

Fig. 5 is a diagram illustrating the structure of a rule in the rule RAM.

6 is a diagram illustrating the storage structure of session information in RAM memory.

Fig. 7 is a diagram illustrating the session tracking algorithm in network traffic.

Implementation of the invention

The proposed method of tracking sessions allows you to save the result of packet processing in memory and apply it to process subsequent packets of this session. A packet session is a set of packets that have the same source and destination addresses, source and destination ports, and protocol (IP and TCP/UDP headers, protocol code L4). At the same time, the IP packet format is described in more detail in the RFC 791 "Internet Protocol DARPA Internet Program Protocol Specification", September 1981. The TCP protocol is described in the RFC 793 "Transmission Control Protocol" specification, September 1980, the UDP protocol is described in the specification
RFC 768 "User Datagram Protocol", August 1980.

To achieve the set technical result, the following stages of operations are performed:

Receiving a packet through the input interface (101), after receiving the packet, analysis and extraction of packet headers is performed. To do this, the packet is transferred to the packet analysis block (102), in which the Ethernet, IP and TCP / UDP headers, the L4 protocol code are extracted from the packet and an information block - descriptor is formed on their basis.

The packet is stored in the packet buffer (103) until a decision is made on the set of actions to be performed on the packet. Based on the information about the packet and its headers, the descriptor shown in FIG. 3, which is stored in a separate descriptor buffer (104).

It is possible that different packets with different values of the header fields: IP addresses, L4 protocol code and TCP / UDP ports can get the same HASH sum and an erroneous decision can be made with respect to the packet so that this does not happen in memory at one address, which is the value of the HASH sum of the session, is stored up to 4 descriptors, if the calculated HASH sum of the session for these descriptors is the same.

It has been established that when storing information about 4 sessions, the probability of a collision is negligible. One cell of the session RAM (105) contains records with information about four sessions (HASH #1, HASH #2, HASH #3, HASH #4), where the cell address equals the HASH sum of the session, as shown in FIG. 6. The information about previously received sessions has the structure shown in FIG. 4. Thus, to resolve collisions arising from session tracking, records with information about four sessions are needed. In the case of balancing, flows can be diluted to different interfaces without the risk of being lost / dropped on other switches in the future, and when aggregating, packets from different interfaces can be collected into one, which generally ensures the integrity of the flow in network traffic.

The HASH sum of the session is calculated based on the descriptor data on the IP addresses of the recipient and source, the TCP / UDP ports of the recipient and sender, the L4 protocol code, for example, using the counter algorithm with Galois authentication. You can perform, for example, a bitwise logical XOR operation on the corresponding bits of the destination IP address (32 bits), source IP address (32 bits), L4 protocol code (8 bits), destination port (16 bits) , sender port (16 bits) and send the results of the bitwise exclusive OR (XOR) operation to the randomizer and generate a HASH sum having Y-bits, where Y is a positive integer, for example, for the specified example - 10 bits.

In the Galois Authenticated Counter (GCM) algorithm, the input blocks of a byte vector are numbered sequentially, the block number is encoded in a block algorithm. The output of the encryption function is used in an XOR ("exclusive OR") operation with plain text to obtain a HASH sum. The scheme is a stream cipher, so using a unique byte vector guarantees a unique HASH sum.

The session lookup block (106) calculates the session HASH sum based on the descriptor fields (destination and source IP addresses, destination and source TCP/UDP ports, L4 protocol code), for example, using a counter algorithm with Galois authentication and looks for matches in RAM -session memory (105), if information about the session is not found, then the descriptor is passed to the session processing block (108), while n is the record number for resolving collisions. Thus, in the cell of the session RAM memory (105), the address of which is equal to the HASH sum, the presence of information consisting of the header fields of the packet on which the HASH sum was calculated is checked about the already received packet with the same HASH sum, if in the cell already contains information, then it is compared with the data from the descriptor, if the information matches, but the packet contains the SYN flag in the TCP header, then a new identifier for the action being performed ACTION is assigned and information about the current packet is entered into the session RAM memory cell, if the information matches and the packet does not contain the SYN flag in the TCP header, then it is considered that the packet belongs to an already existing session and the ACTION identifier stored in this cell of the session RAM memory is added to the packet descriptor, if the information does not match, then in a similar way the remaining three records are checked, if there is no match, a new record is created in the session RAM cell.

The TCP protocol provides the SYN flag for the beginning of the session, as soon as the flag is accepted, it will be clear that the session is open and information about it needs to be written to memory. There is no similar flag in the UDP protocol, so the decision on whether it is possible to close the session is made if no packets with the same controlled fields from the header arrived during the “LIMIT_T” time. Thus, for UDP sessions, the time interval between two session packets is checked, and if it exceeds the set T threshold (for example, more than 30 seconds), then it is considered that the incoming packet belongs to a new session, and information about the outdated session is deleted.

The rules RAM (107) stores a set of rules that defines the rules for switching to a specific output interface (110). The rule consists of a value and a mask, the mask determines which value fields are taken into account when comparing, for example, IP_DST & RULE_IP_DST_MASK == RULE_IP_DST_VAL & RULE_IP_DST_MASK.

Table 1. Rule RAM example

Possible types of rules:

0 - IP_DST

1-IP_SRC

2 - PORT_DST

3 - PORT_SRC

4 - PROTOCOL_CODE

Processing example:

A packet is received with the following parameters IP_DST = 192.168.0.32, IP_SRC = 192.168.0.15, PORT_DST = 443, PORT_SRC = 32457, PROTOCOL_L4 = 6 (TCP).

When searching for rules, the package parameters are sequentially compared with the values in the rule.

For rule #0

The value of the packet parameter after masking is calculated: 192.168.0.32 & 0.0.0.255 = 0.0.0.32. The value of the rule after the mask is applied is calculated: 0.0.0.171 & 0.0.0.255 = 0.0.0.171. A comparison is made with 0.0.0.32 = 0.0.0.171, which means that the packet does not fall under rule #0.

For rule #1

The value of the package parameter is calculated after applying the mask:
443 & 65535 = 443. The value of the rule is calculated after the mask is applied: 443 & 65535 = 443. A comparison is made with 443 = 443, which means that the packet falls under rule No. 1 and it will be sent to port 3.

The session processing block (108) searches for a rule, as shown above, under which the descriptor falls. The search is carried out until the first match, if no match is found, then the packet is discarded. Based on the results of the search, the value of the ACTION field is set to the descriptor ("255" - unknown, "0" - discard, "1: N" - send to port from 1 to N) and the descriptor is transferred to the session search block (106). Based on the ACTION identifier, a decision is made about the action to be performed on the package.

The session lookup block (106) writes the ACTION value from the descriptor to the corresponding cell in the session RAM (105). Different rules work for different descriptors: either drop the packet or redirect it to a specific port. Thus, the switching unit (109), based on the ACTION value "0", "255", either removes the packet from the packet buffer when the value "0" or "1:N" passes the packet to the corresponding egress interface (110).

Transferring traffic of one TCP/UDP session to one output port or traffic of one pair of IP ports (IP addresses, TCP/UDP ports) to one output port or traffic from one user to one output port ensures that the integrity of the sessions is maintained during network transmission. traffic on a network with many network traffic processors and routers.

In a preferred embodiment of the invention, the above logical blocks: packet analysis block (102), session search block (106), session processing block (108), switching block (109), can be implemented or implemented on the basis of an FPGA or VLSI. Blocks can be implemented by a state machine and several registers with appropriate internal logic and are implemented automatically, for example, from the provided XML description of the network protocol, they are controlled by microcode stored in on-chip memory. It is obvious to the specialist that the above logical blocks, processing schemes/algorithms can be executed using a memory element that records processed data from the processing processor, which can be used as a general purpose processor, computer-readable medium, state machine or other hardware-programmable logic device , discrete logic element or transistor logic, or any combination thereof, to perform the functions described above.

The proposed method for tracking sessions in network traffic is focused on use in devices based on FPGA or VLSI, for example, in network packet brokers (NPB), which operate at the packet level, where the rules for distribution and aggregation of traffic in network packet brokers are completely determined by the settings. In NPB, there are no standards for building forwarding tables (MAC tables) and exchange protocols with other switches (such as STP), so the range of possible user settings and interpreted fields in them is much wider. A broker can evenly distribute traffic from one or more input ports to a given range of output ports with an output load balancing feature. You can also set rules for copying, filtering, classifying, deduplicating and modifying traffic to different groups of NPB input ports, as well as applying them sequentially one after another in the device itself. An FPGA or VLSI can be programmed to perform the proposed method and placed anywhere on the computer network of the data center or NPB.

The inventive method for tracking sessions in network traffic may be performed by one or more computer programs containing computer program code or pieces of software executing on a computer or processor. The computer program contains computer program code elements or portions of program code that cause the computer to perform the proposed method.

Embodiments of the invention are not exhaustive and are provided only for the purpose of explaining and confirming industrial applicability, and those skilled in the art are able to create alternative embodiments without departing from the scope of the claims, but within the essence of the invention reflected in the description.

Claims (1)

A method of tracking sessions in network traffic, which consists in tracking sessions, where the network packet, after receiving, is transferred to the packet analysis block, in which the Ethernet, IP and TCP / UDP headers, the L4 protocol code are extracted from the packet and an information block is formed on their basis - descriptor, then the packet is stored in the packet buffer, and the descriptor is stored in the descriptor buffer and then in the session search block, in which the HASH sum of the session is calculated for individual fields: IP addresses of the recipient and sender, TCP / UDP ports of the recipient and sender, codes protocol L4, while one cell of the RAM-memory of sessions contains records with information about at least four sessions, then the session search block checks in the cell of the RAM-memory of sessions, the address of which is equal to the HASH sum of the session, the presence of information consisting of packet header fields, which were used to calculate the session HASH sum, about the already received packet with the same session HASH sum, if the cell already contains information, then execute it is compared with the data from the descriptor, if information about the session is not found, then the descriptor is transferred to the session processing unit, while the set of rules that defines the switching rules is stored in the RAM-memory of the rules, the session processing unit searches for the rule that the descriptor falls under, which is conducted until the first match, if a match is not found, then the packet is discarded, according to the results of the search, the value of the ACTION field is set to the descriptor and the descriptor is transferred to the session search block, which writes the ACTION value from the descriptor to the corresponding cell of the session RAM, then the switching block to Based on the ACTION value, either removes the packet from the packet buffer or passes the packet to the appropriate egress interface.

Images