A method and apparatus for transmitting a deep packet fragmentation

Abstract

The application provides a deep packet fragmentation transmission method and device, and relates to the technical field of data processing. First, the original packet received by a front gateway is fragmented to obtain a first packet and a non-first packet. Then, source and destination port numbers of a transport layer protocol header are extracted from the original packet, and the source and destination port numbers are filled into an option field of an IP header of the non-first packet. After fragmentation, the front gateway sends all the fragmented packets to a firewall, and the source and destination port numbers in each fragmented packet are used for IP quintuple matching of the firewall on each fragmented packet. The method adds 4 bytes of identification to the optional field of the IP header, realizes four-layer source and destination port number matching through the identification, realizes accurate ACL matching of four-layer fragmented packets, solves the problem that the firewall in the existing network cannot accurately match and filter fragmented packets, and improves the efficiency and performance of four-layer fragmented traffic matching ACL.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and apparatus for transmitting deep packet fragmentation. Background Technology

[0002] In the TCP / IP protocol suite, the IP protocol provides unreliable, connectionless datagram transmission services, handling data encapsulation, addressing, and routing. Since the maximum length of an IP packet is limited by its MTU (Maximum Transmission Unit), packets exceeding this length need to be fragmented and reassembled at the destination. However, fragmentation introduces new problems, especially for IP packets containing TCP or UDP headers. Fragmentation can lead to the cutting of transport layer protocol headers, resulting in non-first fragments lacking headers, thus affecting the accurate matching of firewall or gateway ACLs.

[0003] Currently, the main methods used to address the above issues are as follows: One method is for the firewall to only perform ACL matching on the first fragment, allowing subsequent fragments to pass after successful matching. However, this method reduces security because subsequent fragments may not be adequately checked. Another method is to re-add TCP or UDP headers to the fragmented packets, but this increases device overhead and may lead to inefficiency and secondary fragmentation issues. Summary of the Invention

[0004] This application provides a method and apparatus for transmitting deep packet fragmentation to solve the aforementioned problems.

[0005] In a first aspect, embodiments of this application propose a deep packet fragmentation transmission method applied to a front-end gateway, the method comprising:

[0006] The original message received by the front-end gateway is fragmented to obtain a first fragment message and a non-first fragment message. The first fragment message contains a complete transport layer header, and the transport layer header contains source and destination port numbers.

[0007] Extract the source and destination port numbers from the transport layer protocol header of the original message, and fill the source and destination port numbers into the option field of the IP header of the non-first packet;

[0008] The front-end gateway sends all fragmented packets to the firewall, and the source and destination port numbers in each fragmented packet are used by the firewall to perform IP 5-tuple matching on each fragmented packet.

[0009] Optionally, the method further includes:

[0010] Determine the DO value of the first fragment and the non-first fragment. A first DO value indicates that the fragment offset of the fragment is accurate, and a second DO value indicates that the fragment offset of the fragment is the offset value rounded up.

[0011] Fill all DO values ​​into the first reserved field of the Flags field of the corresponding fragment message.

[0012] Optionally, determining the DO values ​​of the first packet and the non-first packets includes:

[0013] Calculate the fragment offset of the original message;

[0014] If the fragment offset of the original message is an integer, the DO value of the first fragment and the non-first fragment are determined to be the first value.

[0015] Optionally, determining the DO values ​​of the first packet and the non-first packets includes:

[0016] Calculate the fragment offset of the original message;

[0017] If the fragment offset of the original message is not an integer, the DO value of the first fragment message is determined to be the first value.

[0018] Calculate the fragment offset of the non-first fragment message;

[0019] If the fragment offset of the non-first fragment is not an integer, the DO value of the non-first fragment is determined to be a second value.

[0020] If the fragment offset of the non-first fragment is an integer, the DO value of the non-first fragment is determined to be the first value.

[0021] Optionally, the method further includes:

[0022] Determine whether the length of the original message is greater than the MTU value configured on the interface of the front-end gateway;

[0023] If the length of the original message is greater than the MTU value configured in the interface of the front-end gateway, determine whether the protocol stack type of the IP header of the original message is TCP or UDP.

[0024] If the protocol stack type of the IP header of the original message is TCP or UDP, determine whether the fragment offset of the original message is an integer.

[0025] In a second aspect, embodiments of this application propose a deep packet fragmentation transmission method applied to a firewall, the method comprising:

[0026] Receive messages sent by the front-end gateway;

[0027] If the message is not the first message, the source and destination port numbers are obtained from the options field of the IP header of the message;

[0028] Based on the source and destination port numbers, the 5-tuples of the non-first fragment packets are matched.

[0029] Optionally, the method includes:

[0030] If the message is the first message, the source and destination port numbers are obtained from the transport layer header of the message;

[0031] Based on the source and destination port numbers, the firewall matches the five-tuple of the first packet.

[0032] Optionally, the method includes:

[0033] Determine whether the protocol stack type in the IP header of the message is TCP or UDP;

[0034] If the protocol stack type in the IP header of the message is TCP or UDP, determine whether the message is a fragmented message;

[0035] If the message is a fragmented message, determine whether the message is the first fragment.

[0036] In a third aspect, embodiments of this application propose a deep packet fragmentation transmission apparatus for use in a front-end gateway, the apparatus comprising:

[0037] The fragmentation module is used to fragment the original message received by the front-end gateway to obtain a first fragment message and a non-first fragment message. The first fragment message contains a complete transport layer header, and the transport layer header contains source and destination port numbers.

[0038] The first padding module is used to extract the source and destination port numbers of the transport layer protocol header from the original message and fill the source and destination port numbers into the option field of the IP header of the non-first packet.

[0039] The transmission module is used by the front-end gateway to send all fragmented packets to the firewall, and the source and destination port numbers in each fragmented packet are used by the firewall to perform IP 5-tuple matching on each fragmented packet.

[0040] In a fourth aspect, embodiments of this application propose a deep packet fragmentation transmission apparatus for use in a firewall, the apparatus comprising:

[0041] The receiving module is used to receive messages sent by the front-end gateway;

[0042] The first acquisition module is used to obtain the source and destination port numbers from the option field of the IP header of the packet when the packet is not the first packet.

[0043] The first matching module is used to match the five-tuples of the non-first packet based on the source and destination port numbers.

[0044] This application offers the following advantages: A method and apparatus for deep packet fragmentation transmission is proposed. First, the original packet received by the front-end gateway is fragmented to obtain a first fragment and non-first fragment packets. The first fragment packet contains a complete transport layer header, which includes source and destination port numbers. Then, the source and destination port numbers from the transport layer protocol header are extracted from the original packet and filled into the option field of the IP header of the non-first fragment packet. After fragmentation, the front-end gateway sends all fragmented packets to the firewall. The source and destination port numbers in each fragmented packet are used by the firewall to perform IP 5-tuple matching on each fragmented packet. This method adds a 4-byte identifier to the optional field of the IP header, enabling Layer 4 source and destination port number matching and precise ACL matching of Layer 4 fragmented packets. This solves the problem that firewalls in existing networks cannot accurately match and filter fragmented packets, improving the efficiency and performance of Layer 4 fragmented traffic matching ACLs. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a schematic diagram of a UDP header encapsulation structure proposed in existing technology;

[0047] Figure 2 This is a schematic diagram of a TCP header encapsulation structure proposed in existing technology;

[0048] Figure 3 This is a schematic diagram of IP packet fragmentation proposed by existing technology;

[0049] Figure 4 This is a schematic diagram of the structure of a raw IP packet header proposed by existing technology;

[0050] Figure 5 This is a schematic diagram of the encapsulation structure of a UDP packet fragment after fragmentation, as proposed in existing technologies;

[0051] Figure 6This is a schematic diagram of an internet service network proposed using existing technology;

[0052] Figure 7 This is a schematic diagram of a fragmentation structure for replicating a four-layer UDP header proposed in existing technology;

[0053] Figure 8 This is a flowchart illustrating the steps of a deep packet fragmentation transmission method applied to a front-end gateway, as proposed in an embodiment of this application.

[0054] Figure 9 This is a schematic diagram of the IP header structure of a deep fragmented packet according to an embodiment of this application;

[0055] Figure 10 This is a schematic diagram of an IP packet fragmentation structure for a deep fragmentation packet proposed in an embodiment of this application;

[0056] Figure 11 This is a schematic flowchart of a deep packet fragmentation transmission method for a front-end gateway proposed in an embodiment of this application;

[0057] Figure 12 This is a flowchart illustrating the steps of a deep packet fragmentation transmission method for a firewall proposed in an embodiment of this application.

[0058] Figure 13 This is a flowchart illustrating a deep packet fragmentation transmission method for firewalls proposed in an embodiment of this application.

[0059] Figure 14 This is a schematic diagram of a transmission device for deep packet fragmentation applied to a front-end gateway, as proposed in an embodiment of this application.

[0060] Figure 15 This is a schematic diagram of a transmission device for deep packet fragmentation applied to a firewall, as proposed in an embodiment of this application. Detailed Implementation

[0061] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0062] In the TCP / IP protocol suite, the IP protocol (Internet Protocol, a network layer protocol within the TCP / IP architecture) provides unreliable, connectionless datagram transmission services for data encapsulation, decapsulation, addressing, and routing. Since IP packets vary in length, with a maximum length of 65535 bytes, the physical network has a limited capacity to encapsulate and forward IP packets. To improve IP packet forwarding efficiency, fragmentation is necessary, followed by reassembly at the destination. While IP fragmentation and reassembly solve the packet transmission problem, they also introduce many new challenges. The fragmentation of transport layer packets is a significant issue. IP packet fragmentation involves dividing the IP packet payload into smaller segments. When the IP payload contains TCP (Transmission Control Protocol, a connection-oriented, reliable, byte-stream-based transport layer communication protocol) or UDP (User Datagram Protocol, a connectionless transport layer protocol in the OSI (Open Systems Interconnection) reference model, fragmentation can lead to the transport layer protocol header being split, or only the first fragment containing the transport layer protocol header while subsequent fragments contain only the pure data portion. Ethernet data is encapsulated layer by layer, with the fourth layer being the transport layer, which primarily uses TCP and UDP protocols. The UDP packet header is 8 bytes long, and its encapsulation structure is as follows: Figure 1 As shown ( Figure 1 This is a schematic diagram of a UDP header encapsulation structure proposed in existing technology. The TCP header is 20 bytes long, and its encapsulation structure is as follows: Figure 2 As shown ( Figure 2 This is a schematic diagram of a TCP header encapsulation structure proposed in existing technology. The maximum length of an IP packet sent within a device is determined by the MTU (Maximum Transmission Unit) value of the device interface. This MTU value indicates the maximum size of the data service unit that the sender can accept, specifying the payload size that the sender can accept. The maximum length of an IP packet cannot exceed the MTU value. If a packet longer than the MTU value of the device interface is received, the IP packet payload (IP data packet portion) will be fragmented. Figure 3 As shown ( Figure 3 This is a schematic diagram of IP packet fragmentation proposed by existing technology. In other words, the maximum transmission unit (MTBF) is calculated as the sum of the IP header and the IP data packet, while fragmentation only divides the IP data packet into smaller pieces. When fragmenting an IP data packet containing transport layer protocols, a second fragment is formed; the third fragment does not contain the transport layer protocol header.

[0063] The raw IP header is a fixed 20 bytes long. The structure following bytes 20 is the options field. The 7th byte contains the Flags and Fragmented Offset fields. The Flags field has three bits: the first is reserved, the second is the DF (Don't Fragment) bit, indicating whether fragmentation is allowed. A DF bit of 1 indicates that fragmentation is not allowed, and 0 indicates that fragmentation is allowed. The third bit is the MF (More Fragments) bit, used to indicate whether there are more fragments after the initial fragmentation. An MF bit of 1 indicates that this fragment is not the last fragment and that more fragments follow; a MF bit of 0 indicates that this fragment is the last fragment. The Fragmented Offset field is a 13-bit field that indicates the distance between this fragment and the first fragment, in bytes. The entire raw IP header structure is as follows: Figure 4 As shown ( Figure 4 This is a schematic diagram of the structure of a raw IP packet header proposed by existing technology.

[0064] Taking UDP packet fragmentation as an example, such as Figure 5 As shown ( Figure 5 This is a schematic diagram of the encapsulation structure of fragmented UDP packets proposed in the prior art. In the IP header of the first fragment, MF=1, DF=0, fragment offset=0, and the IP data packet contains a UDP header. The IP data packets of the second and third fragments do not contain a UDP header.

[0065] When these Layer 4 fragmented packets pass through firewalls or gateways, ACLs (Access Control Lists, which filter packets on an interface based on set conditions, allowing or dropping them; widely used in routers and Layer 3 switches to effectively control user access to the network and maximize network security) cannot accurately match the IP 5-tuple, resulting in fragmented packets not being precisely matched. Figure 6 As shown ( Figure 6This is a diagram illustrating an existing internet service network topology. Users access various services provided by enterprise intranet servers via the internet, which requires routing through a front-end gateway and filtering by a firewall. When a Layer 4 fragmented packet from the internet reaches the enterprise intranet, it's impossible to match the IP 5-tuple for non-first fragments because subsequent fragments don't carry TCP or UDP headers, making it impossible to obtain the source and destination port numbers. The IP 5-tuple consists of five key parameters used in network communication to uniquely identify a network connection. These five parameters include: Source IP address: the IP address of the device initiating the connection; Source Port: the port number used by the application on the device initiating the connection; Destination IP address: the IP address of the device receiving the connection; Destination Port: the port number used by the application on the device receiving the connection; and Transport Layer Protocol: the type of protocol used to transmit data, most commonly TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).

[0066] The above problems are currently being addressed primarily through the following methods:

[0067] (1) The firewall only performs ACL matching on the first fragment of the packet. If the first fragment matches successfully, subsequent fragments are allowed to pass. (2) The fragmented TCP or UDP packets are re-encapsulated with a Layer 4 header to non-first fragments, and a transport layer header is added to the IP payload. Taking the UDP protocol as an example, the fragmentation structure is as follows: Figure 7 As shown ( Figure 7 This is a schematic diagram of a fragmentation structure for replicating a four-layer UDP header proposed in existing technology.

[0068] The above method has the following problems:

[0069] (1) If only the first fragment is filtered, and subsequent fragments are allowed after the first fragment passes, the security of the firewall will be greatly reduced. Traditional firewalls only perform ACL matching on the first fragment. If the first fragment matches successfully, subsequent fragments are allowed to pass. This can only guarantee the compliance and security of the first fragment, making it vulnerable to attacks from maliciously constructed non-first fragment fragments. Common fragmented flood attacks exploit this vulnerability, greatly reducing the security of the firewall.

[0070] (2) Adding TCP or UDP headers to fragmented packets increases device overhead and fragmented packet length. Adding TCP or UDP headers to fragmented packets requires re-encapsulation of the fragmented packets, which incurs high CPU overhead and reduces device forwarding efficiency. Furthermore, adding a fourth-layer header further increases packet length, especially since the TCP header is 20 bytes, easily leading to secondary fragmentation after re-encapsulation, making the problem even more complex.

[0071] (3) Adding TCP or UDP headers to fragmented packets is essentially still Layer 4 parsing, which is inefficient. Adding TCP or UDP headers to fragmented packets adds a Layer 4 header to the IP payload of the fragmented packets. When performing five-tuple matching and querying the source and destination port numbers at Layer 4, it is still necessary to perform parsing above the IP layer, resulting in low forwarding efficiency and high equipment requirements.

[0072] Based on this, this application proposes a deep packet fragmentation transmission method, which mainly adds 4 bytes of identifiers by applying optional fields in the IP header. These identifiers enable the matching of source and destination port numbers at Layer 4. Simultaneously, by modifying and applying reserved fields in the IP header, a Decimal Offset field is defined, optimizing the current situation where fragment offsets cannot be rounded due to changes in IP header length and MTU configuration values.

[0073] See Figure 8 , Figure 8 This is a flowchart illustrating the steps of a deep packet fragmentation transmission method applied to a front-end gateway, as proposed in an embodiment of this application. The method includes the following steps:

[0074] Step 801: Fragment the original message received by the front-end gateway to obtain the first fragment message and non-first fragment messages. The first fragment message contains a complete transport layer header, and the transport layer header contains source and destination port numbers.

[0075] After the front-end gateway receives the original packet sent from the Internet, it performs fragmentation on the original packet to obtain the first fragment packet and the non-first fragment packets. The original packet can be an IP packet.

[0076] It should be noted that the number of non-first packets is determined based on the length of the original packet and the MTU value of the front-end gateway interface, but there must be at least one non-first packet.

[0077] When fragmenting a message, only the data packets are fragmented. For the first fragment, it contains a complete transport layer header, and the transport layer header contains the source and destination port numbers. If the protocol stack type in the original message is UDP, its transport layer header contains a UDP header. If the protocol stack type in the original message is TCP, its transport layer header contains a TCP header. The source and destination port numbers are contained in the UDP header or the TCP header.

[0078] It should be noted that the source and destination port numbers in the embodiments of this application are both source port numbers and destination port numbers.

[0079] Step 802: Extract the source and destination port numbers of the transport layer protocol header from the original message, and fill the source and destination port numbers into the option field of the IP header of the non-first packet.

[0080] Because only data packets are fragmented when messages are fragmented, and the transport layer header is given to the first fragment, non-first fragments do not contain the transport layer header. Therefore, when the firewall receives non-first fragments, it cannot perform IP 5-tuple matching on them.

[0081] Based on this, this method extracts the source and destination port numbers from the transport layer protocol header of the original packet and fills them into the option field of the IP header of non-first fragment packets. This ensures that each non-first fragment packet contains source and destination port numbers for IP 5-tuple matching. During fragmentation, only the data packets of the original packet are cut. Whether or not the layer 4 protocol header is cut, or whether subsequent fragmented packets do not contain the layer 4 protocol header, does not affect the identification of the source and destination port numbers. This further enables the firewall to match and filter all packets, improving the security of packet transmission.

[0082] For example, see Figure 9 , Figure 9 This is a schematic diagram of the IP header structure of a deep fragmented packet proposed in an embodiment of this application. As can be seen, the header length of the original packet is a fixed 20 bytes. The structure after the 20 bytes is the options field. Four bytes have been added to the Options field of the original packet IP header. The first two bytes represent the source port number of the Layer 4 protocol header, and the last two bytes represent the destination port number of the Layer 4 protocol header.

[0083] Step 803: The front-end gateway sends all fragmented packets to the firewall, and the source and destination port numbers in each fragmented packet are used by the firewall to perform IP 5-tuple matching on each fragmented packet.

[0084] After fragmentation is completed, the front-end gateway sends all fragmented packets to the firewall. The source and destination port numbers in each fragmented packet are used by the firewall to perform IP 5-tuple matching on each fragmented packet.

[0085] This application proposes a deep packet fragmentation transmission method. First, the original packet received by the front-end gateway is fragmented into a first fragment and non-first fragments. The first fragment contains a complete transport layer header, which includes source and destination port numbers. Then, the source and destination port numbers from the transport layer protocol header are extracted from the original packet and filled into the option field of the IP header of the non-first fragment. After fragmentation, the front-end gateway sends all fragmented packets to the firewall. The source and destination port numbers in each fragment are used by the firewall to perform IP 5-tuple matching on each fragment. This method adds a 4-byte identifier to the optional field of the IP header, enabling Layer 4 source and destination port number matching and precise ACL matching for Layer 4 fragmented packets. This solves the problem that firewalls in existing networks cannot accurately match and filter fragmented packets, improving the efficiency and performance of Layer 4 fragmented traffic ACL matching.

[0086] Considering the increased length of the header including the option field and the configuration of the MTU value, the original header length is a fixed 20 bytes. After adding the source and destination port numbers to the option field, the header length becomes 24 bytes, which will cause the fragment offset to be a non-integer. This application embodiment optimizes the situation where the fragment offset cannot be rounded due to the change in the original header length and the configuration of the MTU value by modifying and applying the reserved fields in the header.

[0087] In an optional implementation, the method further includes the following steps:

[0088] Step 804: Determine the DO value of the first fragment and the non-first fragment. A first DO value indicates that the fragment offset of the fragment is accurate, and a second DO value indicates that the fragment offset of the fragment is the offset value rounded up.

[0089] The DO value mentioned above is Decimal Offset, which defines whether the fragment offset of a packet is an integer. Since the fragment offsets of the first and non-first fragments differ, the DO value for each fragment may be different. Therefore, it is necessary to first determine the DO values ​​for the first and non-first fragments. If the DO value is the first value, it indicates that the fragment offset of that fragment is accurate; if the DO value is the second value, it indicates that the fragment offset of that fragment is the offset value rounded up. The Offset value corresponds to the Fragmented Offset field (representing the fragment offset field), is 13 bits long, and indicates the fragment offset distance of this fragment from the first fragment, in bytes, typically 8 bytes.

[0090] In one example, the first value mentioned above can be 0. When the DO value is set to 0, it means that the slice offset of the slice is accurate and there is no need to round up the offset value. The second value mentioned above can be 1. When the DO value is set to 1, it means that the slice offset of the slice is equal to the offset value plus 0.5 bytes, that is, the offset value is rounded up.

[0091] It should be noted that during the transmission of deep IP fragmentation, this field is set to 0 for packets without Layer 4 protocols.

[0092] Step 805: Fill all DO values ​​into the first reserved field of the Flags field of the corresponding fragment packets.

[0093] After determining the DO value for each fragment, the DO value corresponding to each fragment is filled into the first reserved field of the Flags field of each fragment. The specific filling position of the DO value is as follows: Figure 9 As shown, it replaces the first reserved field (R) of the Flags field in the original message header. See [link / reference] Figure 4 .

[0094] In an optional implementation, step 804 above, determining the DO values ​​of the first packet and the non-first packets, further includes the following sub-steps:

[0095] Step 8041: Calculate the fragment offset of the original message.

[0096] First, calculate the fragment offset of the original message. The calculation method is: subtract the message header length from the MTU value and convert it into the fragment offset value to obtain the fragment offset of the original message.

[0097] In one example, if the length of the original message is 4000 bytes, the length of the message header is 20 bytes, and the fragment offset field is 8 bytes, the fragment offset of the original message = (4000-20) / 8.

[0098] Step 8042: If the fragment offset of the original message is an integer, determine the DO value of the first fragment message and the non-first fragment message as a first value.

[0099] When the fragment offset of the original message is an integer, the DO value of both the first fragment and non-first fragment messages is determined to be the first value. This indicates that in this case, the fragment offset of all fragmented messages is accurate and does not need to be rounded up, i.e., floated up by 0.5 bytes.

[0100] In an optional implementation, step 804 above, determining the DO values ​​of the first packet and the non-first packets, further includes the following sub-steps:

[0101] Step 8043: Calculate the fragment offset of the original message.

[0102] This step is the same as the calculation in step 8041, and will not be repeated here.

[0103] Step 8044: If the fragment offset of the original message is not an integer, determine the DO value of the first fragment message as a first value.

[0104] When the fragment offset of the original message is not an integer, the fragment offset of the first message is 0. Therefore, the DO value of the first message is determined as the first value, indicating that the fragment offset of the first message is accurate and there is no need to round up.

[0105] Step 8045: Calculate the slice offset of the non-first slice message.

[0106] If the fragment offset of the original packet is not an integer, the fragment offset of a non-first fragment packet may be either an integer or a non-integer. Based on this, the fragment offset of each non-first fragment packet is calculated. Since an options field has been added to the header of non-first fragment packets, meaning the header length of a non-first fragment packet is now 24 bytes, the fragment offset of a non-first fragment packet needs to be calculated by subtracting 24 bytes from the MTU value before converting it to the fragment offset value.

[0107] In one example, if the length of the original message is 4000 bytes, the MTU value is 1500 bytes, the fragment offset field is 8 bytes, the length of the first fragment is 1500 bytes = 20 bytes + 1480 bytes, the length of the second fragment is 1500 bytes = 24 bytes + 1476 bytes, and its fragment offset = (1500 - 24) / 8.

[0108] Step 8046: If the fragment offset of the non-first fragment is not an integer, determine the DO value of the non-first fragment as a second value;

[0109] If the fragment offset of a non-first fragment is not an integer, the DO value of the non-first fragment is set to the second value, indicating that the fragment offset of the non-first fragment needs to be rounded up.

[0110] In one example, if the original message length is 4000 bytes (20 bytes + 3980 bytes), the MTU value is 1500 bytes, the fragment offset field is 8 bytes, the length of the first fragment is 1500 bytes (20 bytes + 1480 bytes), the length of the second fragment is 1500 bytes (24 bytes + 1476 bytes), and its fragment offset is (1500 - 24) / 8 = 185. The length of the third fragment is 1048 bytes (24 bytes + 1024 bytes), and its fragment offset is (1480 + 1476) / 8 = 369.5. Since the fragment offset of the third fragment is not an integer, it needs to be rounded up to the nearest integer, which is 370.

[0111] Step 8047: If the fragment offset of the non-first fragment is an integer, determine the DO value of the non-first fragment as a first value.

[0112] If the fragment offset of a non-first fragment is an integer, the DO value of that non-first fragment is set to the first value, indicating that the fragment offset is accurate and does not need to be rounded up. Based on the example above, the fragment offset of the second fragment is 185, which is an integer and does not need to be rounded up.

[0113] For example, after the gateway device enables the DIF (Deep IP Fragmentation) function, when fragmenting large TCP or UDP packets, assuming the IP packet length is 4000 bytes and the MTU value is 1500, the fragmentation calculation process is shown in Table 1. Data packet fragment 1 is 1500 bytes long, DO=0, MF=1, DF=0, Offset=0. The second fragment is 1500 bytes long, DO=0, MF=1, DF=0, Offset=185. The third fragment is 1048 bytes long, DO=1, MF=0, DF=0, Offset=370.

[0114] Table 1. Example of fragment offset calculation for IP packets with DIF enabled.

[0115]

[0116] Data packet fragment 1 is fragmented normally. In the IP header of data packet fragment 1, MF=1, DF=0, and Offset=0, and it includes a transport layer header in the IP packet. Data packet fragment 2's IP header becomes 24 bytes, with an added 4-byte Option field. This Option field extracts the source and destination port numbers from the transport layer protocol header of the original packet and fills them at the end of the IP header. In data packet fragment 2, MF=1, DF=0, and the Offset (fragment offset) is calculated from the MTU. The DO value is also set to 1 to indicate whether the Offset is a decimal. Subsequent fragments are consistent with data packet fragment 2, including the source and destination port numbers of all four layers of the protocol in the IP header, and the DO value is set to 1 according to the MTU value. For example, consider a UDP packet as data packet fragment 3. Figure 10 As shown ( Figure 10 This is a schematic diagram of an IP packet fragmentation structure for a deep fragmented packet proposed in an embodiment of this application. After the device enables the DIF function, only data packet fragment 1 has a complete UDP header. The UDP source and destination port numbers of subsequent fragments are mapped to the Option field of the IP header, and the DO bit is assigned a value according to the actual situation.

[0117] Based on the above embodiments, the method further includes the following steps:

[0118] Step 806: Determine whether the length of the original message is greater than the MTU value configured for the interface of the front-end gateway.

[0119] When the front-end gateway receives the original packet, it first determines whether the length of the original packet is greater than the MTU value configured in the front-end gateway interface. If the length of the original packet is less than the MTU value, there is no need to fragment it, and it is directly forwarded to the next normal node.

[0120] Step 807: If the length of the original message is greater than the MTU value configured in the interface of the front-end gateway, determine whether the protocol stack type of the IP header of the original message is TCP or UDP.

[0121] If the length of the original packet exceeds the MTU value configured on the interface of the front-end gateway, the protocol stack type of the IP header of the original packet is determined. If the protocol stack type of the IP header of the original packet is not TCP or UDP, then the original packet is fragmented normally without adding source and destination port numbers to the packet header.

[0122] Step 808: If the protocol stack type of the IP header of the original message is TCP or UDP, determine whether the fragment offset of the original message is an integer.

[0123] If the protocol stack type of the IP header of the original message is TCP or UDP, calculate whether the fragment offset of the original message is an integer, and then perform different processing on the original message based on this.

[0124] See Figure 11 , Figure 11 This is a flowchart illustrating a deep packet fragmentation transmission method for a front-end gateway proposed in this application. After receiving an IP packet, the front-end gateway device's protocol stack first checks if the IP packet length is greater than the gateway interface's MTU value. If not, it forwards the packet normally to the next node. If it is greater than the MTU value, further checks are performed. The protocol stack type in the IP header is checked to see if it is TCP or UDP. If not, the fragmentation process proceeds normally. If it is a TCP or UDP packet, further checks are performed. The fragment offset is calculated by subtracting the IP header length from the MTU value. It is then determined whether this value is an integer. If not, the IP packet is fragmented. The first fragment is fragmented normally, and the DO value is set to 0. Other fragments modify the IP header, extracting the source and destination port numbers of the four layers of the protocol from the original packet and adding them as Option fields to the last 4 bytes of the IP header. Simultaneously, the fragment offset is calculated; if it is not an integer, the DO value is set to 1, and the Offset value is rounded down and up. The remaining fragmentation process is consistent with the original fragmentation process. If the value is an integer, the IP packet is fragmented. The first fragment is fragmented normally with its DO value set to 0. Other fragments have their IP headers modified, extracting the source and destination port numbers from the original packet's Layer 4 protocols and adding them as Option fields to the last 4 bytes of the IP header. The remaining fragmentation process is the same as the original fragmentation process, with the DO value set to 0. After the fragmentation process is complete, the packet is forwarded to the next node.

[0125] The method proposed in this application solves the problem of difficult IP 5-tuple matching for Layer 4 fragmented packets, while improving the efficiency and performance of ACL matching without increasing CPU overhead.

[0126] See Figure 12 , Figure 12 This is a flowchart illustrating the steps of a deep packet fragmentation transmission method applied to a firewall, as proposed in an embodiment of this application. The method includes the following steps:

[0127] Step 1201: Receive the message sent by the front-end gateway.

[0128] After the front-end gateway performs deep fragmentation on all the original packets, it transmits them to the next normal node, which receives all the packets sent by the front-end gateway and parses the packets to match and filter them.

[0129] Step 1202: If the message is not the first message, obtain the source and destination port numbers from the options field of the IP header of the message.

[0130] If the message is not the first message, it indicates that the source and destination port numbers of the message need to be obtained from the options field of the IP header of the message.

[0131] Step 1203: Match the 5-tuples of the non-first packet based on the source and destination port numbers.

[0132] Based on the source and destination port numbers obtained from the options field of the IP header of the packet, the five-tuple of the non-first packet is matched to achieve the matching and filtering of the packet.

[0133] In an optional implementation, the method further includes the following steps:

[0134] Step 1204: If the message is the first message, obtain the source and destination port numbers from the transport layer header of the message.

[0135] If this message is the first message, it indicates that the source and destination port numbers of this message need to be obtained from the transport layer header of the message.

[0136] Step 1205: Based on the source and destination port numbers, the firewall matches the five-tuple of the first packet.

[0137] Based on the source and destination port numbers obtained from the transport layer header of the packet, the firewall matches the five-tuple of the first packet to achieve packet matching and filtering.

[0138] Based on the above embodiments, the method includes the following steps:

[0139] Step 1206: Determine whether the protocol stack type in the IP header of the message is TCP or UDP.

[0140] Before obtaining the source and destination port numbers, the firewall first determines whether the protocol stack type in the IP header of the packet is TCP or UDP. If it is not TCP or UDP, the firewall obtains the source and destination port numbers from the transport layer header of the packet, enabling the firewall to match and filter the packet.

[0141] Step 1207: If the protocol stack type in the IP header of the message is TCP or UDP, determine whether the message is a fragmented message.

[0142] If the protocol stack type in the IP header of the packet is TCP or UDP, it can be determined whether the packet is a fragmented packet by parsing the packet's MF and Offset. If MF=1 and Offset is not empty, the packet is considered a fragmented packet. If the packet is not a fragmented packet, the source and destination port numbers can be obtained from the packet's transport layer header, enabling the firewall to match and filter the packet.

[0143] Step 1208: If the message is a fragmented message, determine whether the message is the first fragment.

[0144] In the case of a fragmented message, to determine whether the message is the first fragment, we can parse the message's MF and Offset. If MF=1 and Offset=0, the message is considered to be the first fragment.

[0145] See Figure 13 , Figure 13 This is a flowchart illustrating a deep packet fragmentation transmission method for firewalls proposed in this application. After receiving an IP packet from the front-end gateway, the firewall checks whether the protocol stack type in the IP header is TCP or UDP. If not, the packet is filtered based on normal matching and filtering using the IP 5-tuple. The Layer 4 protocol source and destination port numbers are obtained from the Layer 4 packet header. If it is a TCP or UDP packet, the process continues. It checks whether the IP packet is a fragmented packet (MF=1 and Offset is not empty). If not, the packet is filtered based on normal matching and filtering using the IP 5-tuple. The Layer 4 protocol source and destination port numbers are obtained from the Layer 4 packet header. If it is a fragmented packet, the process continues. It checks whether the packet is the first fragment (MF=1, Offset=0). If it is the first fragment, the packet is filtered based on normal matching and filtering using the IP 5-tuple. The Layer 4 protocol source and destination port numbers are obtained from the Layer 4 packet header. If it's not the first fragment of a packet, filtering is performed normally based on the IP 5-tuple. The source and destination port numbers of the Layer 4 protocol are obtained by parsing the Option field in the IP header. After passing through the firewall's filtering, the packet is forwarded normally to the next node.

[0146] See Figure 14 , Figure 14 This is a schematic diagram of a transmission device for deep packet fragmentation applied to a front-end gateway, as proposed in an embodiment of this application. The device includes:

[0147] Fragmentation module 1401 is used to fragment the original message received by the front-end gateway to obtain a first fragment message and a non-first fragment message. The first fragment message contains a complete transport layer header, and the transport layer header contains source and destination port numbers.

[0148] The first filling module 1402 is used to extract the source and destination port numbers of the transport layer protocol header from the original message and fill the source and destination port numbers into the option field of the IP header of the non-first packet.

[0149] The transmission module 1403 is used by the front-end gateway to send all fragmented packets to the firewall, and the source and destination port numbers in each fragmented packet are used by the firewall to perform IP 5-tuple matching on each fragmented packet.

[0150] The device further includes:

[0151] The first determining module is used to determine the DO value of the first fragment and the non-first fragment. The first DO value indicates that the fragment offset of the fragment is accurate, and the second DO value indicates that the fragment offset of the fragment is the offset value rounded up.

[0152] The second padding module is used to fill all DO values ​​into the first reserved field of the Flags field of each corresponding fragment packet.

[0153] The determining module includes:

[0154] The first calculation submodule is used to calculate the fragment offset of the original message;

[0155] The first determining submodule is used to determine the DO value of the first fragment and the non-first fragment of the original message as a first value when the fragment offset of the original message is an integer.

[0156] The determining module further includes:

[0157] The second calculation submodule is used to calculate the fragment offset of the original message;

[0158] The second determining submodule is used to determine the DO value of the first fragment of the packet as a first value when the fragment offset of the original packet is not an integer.

[0159] The third calculation submodule is used to calculate the fragment offset of the non-first fragment packet;

[0160] The third determining submodule is used to determine the DO value of the non-first fragment packet as a second value when the fragment offset of the non-first fragment packet is not an integer.

[0161] The fourth determining submodule is used to determine the DO value of the non-first fragment packet as a first value when the fragment offset of the non-first fragment packet is an integer.

[0162] The device further includes:

[0163] The second determining module is used to determine whether the length of the original message is greater than the MTU value configured in the interface of the front-end gateway;

[0164] The third determining module is used to determine whether the protocol stack type of the IP header of the original message is TCP or UDP when the length of the original message is greater than the MTU value configured in the interface of the front-end gateway.

[0165] The fourth determining module is used to determine whether the fragment offset of the original message is an integer when the protocol stack type of the IP header of the original message is TCP or UDP.

[0166] See Figure 15 , Figure 15 This is a schematic diagram of a transmission device for deep packet fragmentation applied to a firewall, as proposed in an embodiment of this application. The device includes:

[0167] The receiving module 1501 is used to receive messages sent by the front-end gateway;

[0168] The first acquisition module 1502 is used to obtain the source and destination port numbers from the option field of the IP header of the packet when the packet is not the first packet.

[0169] The first matching module 1503 is used to match the five-tuples of the non-first packet based on the source and destination port numbers.

[0170] The device further includes:

[0171] The second acquisition module is used to acquire the source and destination port numbers from the transport layer header of the message when the message is the first message.

[0172] The second matching module is used to match the five-tuple of the first packet based on the source and destination port numbers.

[0173] The device further includes:

[0174] The fifth determining module is used to determine whether the protocol stack type in the IP header of the message is TCP or UDP;

[0175] The sixth determining module is used to determine whether the message is a fragmented message if the protocol stack type in the IP header of the message is TCP or UDP.

[0176] The seventh determining module is used to determine whether the message is the first fragment when the message is a fragmented message.

[0177] Based on the same concept, this application also discloses an electronic device, which includes a memory and a processor. The memory of the electronic device is not less than 12G, the processor has a main frequency of not less than 2.4GHz, the memory and the processor are connected via a bus for communication, and the memory stores a computer program that can run on the processor to implement a deep packet fragmentation transmission method disclosed in this application.

[0178] Based on the same concept, embodiments of this application also disclose a computer-readable storage medium storing a computer program / instructions thereon, which, when executed by a processor, implements a deep packet fragmentation transmission method disclosed in embodiments of this application.

[0179] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0180] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, electronic devices, and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0181] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0182] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0183] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0184] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0185] The above provides a detailed description of the deep packet fragmentation transmission method and apparatus provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for transmitting deep packet fragmentation, characterized in that, Applied to a front-end gateway, the method includes: The original message received by the front-end gateway is fragmented to obtain a first fragment message and a non-first fragment message. The first fragment message contains a complete transport layer header, and the transport layer header contains source and destination port numbers. Extract the source and destination port numbers from the transport layer protocol header of the original message, and fill the source and destination port numbers into the option field of the IP header of the non-first packet; The front-end gateway sends all fragmented packets to the firewall, and the source and destination port numbers in each fragmented packet are used by the firewall to perform IP 5-tuple matching on each fragmented packet. Determine the DO value of the first fragment and the non-first fragment. A first DO value indicates that the fragment offset of the fragment is accurate, and a second DO value indicates that the fragment offset of the fragment is the offset value rounded up. Fill all DO values ​​into the first reserved field of the Flags field of the corresponding fragment message.

2. The method for transmitting deep packet fragments according to claim 1, characterized in that, Determining the DO values ​​of the first fragment and the non-first fragments includes: Calculate the fragment offset of the original message; If the fragment offset of the original message is an integer, the DO value of the first fragment and the non-first fragment are determined to be the first value.

3. The method for transmitting deep packet fragments according to claim 1, characterized in that, Determining the DO values ​​of the first fragment and the non-first fragments includes: Calculate the fragment offset of the original message; If the fragment offset of the original message is not an integer, the DO value of the first fragment message is determined to be the first value. Calculate the fragment offset of the non-first fragment message; If the fragment offset of the non-first fragment is not an integer, the DO value of the non-first fragment is determined to be a second value. If the fragment offset of the non-first fragment is an integer, the DO value of the non-first fragment is determined to be the first value.

4. The method for transmitting deep packet fragments according to claim 2 or 3, characterized in that, The method further includes: Determine whether the length of the original message is greater than the MTU value configured on the interface of the front-end gateway; If the length of the original message is greater than the MTU value configured in the interface of the front-end gateway, determine whether the protocol stack type of the IP header of the original message is TCP or UDP. If the protocol stack type of the IP header of the original message is TCP or UDP, determine whether the fragment offset of the original message is an integer.

5. A method for transmitting deep packet fragmentation, characterized in that, Applied to a firewall, the method includes: Receive a message sent by the front-end gateway; wherein, the first reserved field of the Flags field of the message is the DO value; if the DO value is the first value, it indicates that the fragment offset of the fragmented message is accurate; if the DO value is the second value, it indicates that the fragment offset of the fragmented message is the Offset value rounded up; If the message is not the first message, the source and destination port numbers are obtained from the options field of the IP header of the message; Based on the source and destination port numbers, the 5-tuples of the non-first fragment packets are matched.

6. The method for transmitting deep packet fragments according to claim 5, characterized in that, The method includes: If the message is the first message, the source and destination port numbers are obtained from the transport layer header of the message; Based on the source and destination port numbers, the firewall matches the five-tuple of the first packet.

7. The method for transmitting deep packet fragments according to claim 5 or 6, characterized in that, The method includes: Determine whether the protocol stack type in the IP header of the message is TCP or UDP; If the protocol stack type in the IP header of the message is TCP or UDP, determine whether the message is a fragmented message; If the message is a fragmented message, determine whether the message is the first fragment.

8. A transmission apparatus for deep packet fragmentation, characterized in that, The device, applied to a front-end gateway, includes: The fragmentation module is used to fragment the original message received by the front-end gateway to obtain a first fragment message and a non-first fragment message. The first fragment message contains a complete transport layer header, and the transport layer header contains source and destination port numbers. The first padding module is used to extract the source and destination port numbers of the transport layer protocol header from the original message and fill the source and destination port numbers into the option field of the IP header of the non-first packet. The transmission module is used by the front-end gateway to send all fragmented packets to the firewall, and the source and destination port numbers in each fragmented packet are used by the firewall to perform IP 5-tuple matching on each fragmented packet. The first determining module is used to determine the DO value of the first fragment and the non-first fragment. The first DO value indicates that the fragment offset of the fragment is accurate, and the second DO value indicates that the fragment offset of the fragment is the offset value rounded up. The second padding module is used to fill all DO values ​​into the first reserved field of the Flags field of each corresponding fragment packet.

9. A deep packet fragmentation transmission apparatus, characterized in that, The device, used in a firewall, includes: The receiving module is used to receive messages sent by the front-end gateway; wherein, the first reserved field of the Flags field of the message is the DO value; if the DO value is the first value, it indicates that the fragment offset of the fragmented message is accurate; if the DO value is the second value, it indicates that the fragment offset of the fragmented message is the Offset value rounded up. The first acquisition module is used to obtain the source and destination port numbers from the option field of the IP header of the packet when the packet is not the first packet. The first matching module is used to match the five-tuples of the non-first packet based on the source and destination port numbers.

Images