Communication device and method therein facilitating IPSEC communication

By calculating and notifying MTU between communication devices, the problem of ESP packet segmentation in IPsec communication is solved, router error handling and service interruption are avoided, and communication performance and reliability are improved.

CN119892484APending Publication Date: 2025-04-25TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510154273.X
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2022-02-22
Publication Date
2025-04-25

AI Technical Summary

Technical Problem

In untrusted networks, IPsec communication can lead to segmentation of ESP packets, resulting in router error handling and service interruption, especially in NAT-based IKE scenarios, IP segmentation can be more problematic.

Method used

The ESP packet of the initial segment is received from the second communication device by the first communication device, the MTU in the path from the second communication device to the first communication device is calculated, and the calculated MTU is notified to the second communication device. The second communication device then segments the original IP packet according to the received MTU or notifies the packet sender to adjust the packet size to avoid segmentation.

Benefits of technology

Effectively prevent ESP packets from segmenting along the path, avoid router error handling and service interruption, and improve the performance and reliability of IPsec communication.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119892484A_ABST
    Figure CN119892484A_ABST
Patent Text Reader

Abstract

The present disclosure provides a method (200) performed by a first communication device. The method (200) comprises: receiving (210) an encapsulated secure payload (ESP) packet as an initial segment from a second communication device; calculating (220) a maximum transmission unit (MTU) in a path from the second communication device to the first communication device from the ESP packet; and notifying (230) the second communication device of the calculated MTU.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] This application is a divisional application of the PCT international application PCT / CN2022 / 077258, filed on February 22, 2022, with the invention name “Communications equipment and methods therein for facilitating IPSEC communications”, which entered the Chinese national phase patent application 202280092271.7. Technical Field

[0002] The present disclosure relates to communication technology, and more particularly to a communication device and method therein for facilitating Internet Protocol (IP) security (IPsec) communications. Background Art

[0003] IPsec provides confidentiality, data integrity, access control, and data origin authentication to IP datagrams. These services are provided by maintaining a shared state between the source and destination of the IP datagram. The state defines, among other things, the specific services provided to the datagram, which encryption algorithms will be used to provide these services, and the keys used as input to the encryption algorithms.

[0004] Internet Engineering Task Force (IETF) Request for Comments (RFC) 7296, Internet Key Exchange Protocol Version 2 (IKEv2), the entire contents of which are incorporated herein by reference, describes Version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec that is used to perform mutual authentication and to establish and maintain security associations (SAs).

[0005] IKE performs mutual authentication between two parties and establishes an IKE security association (SA) that includes shared secret information and a set of encryption algorithms SA. The shared secret information can be used to effectively establish an SA (called a child SA) for Encapsulating Security Payload (ESP) or Authentication Header (AH). The encryption algorithm set is used by the SA to protect the traffic they carry.

[0006] IETF RFC 8900, "IP Fragmentation Considered Fragile," which is incorporated herein by reference in its entirety, describes IP fragmentation and reassembly. Internet datagrams need to be fragmented when they originate from a local network that allows large packet sizes and must traverse a local network that limits packets to smaller sizes in order to reach their destination. The IP fragmentation and reassembly process needs to be able to break a datagram into a nearly arbitrary number of parts that can later be reassembled.

[0007] For example, when IP traffic is to traverse an untrusted network, IPsec is needed to protect the transmission security. However, the maximum transmission unit (MTU) of each router in the untrusted network is unknown to the IPsec application at both ends and cannot be modified by the IPsec application. From the application's perspective, the application does not know whether the packet size needs to be changed, and if so, what the appropriate packet size to change to. Therefore, ESP packets may be fragmented when traversing an untrusted network.

[0008] IP fragmentation may bring many defects. Here are some defects described in RFC 8900. IP fragmentation consumes more central processing unit (CPU) and random access memory (RAM) for reassembly, but routers have limited RAM. When reassembling, all unused packets need to be put into buffers and queued, which has a great impact on the system; for IPsec, this is very serious because IPsec focuses on performance. If any fragment is lost during transmission, all data needs to be retransmitted; for example, a large packet is split into 7 small packets for transmission, and if any small packet is dropped, the 7 packets will be retransmitted. After fragmentation, the large packet will become an initial fragment (the first packet) and non-initial fragments (the second and subsequent packets). The non-initial fragment packet contains only three layers of information (layer 1 to layer 3). If there is disorder during data transmission, and if the first packet received is a non-initial fragment, some firewalls will discard the first packet. Summary of the invention

[0009] IP fragmentation can be even more problematic in IKE scenarios based on Network Address Translation (NAT). Figures 1A to 1C The packet format used in the IKE scenario based on NAT is shown. Specifically, Figure 1A shows the packet format of UDP encapsulation, Figure 1B shows the packet format of the initial fragment in the case of segmentation, and Figure 1C The packet format of non-initial fragments in the fragmentation case is shown. In the IKE scenario based on NAT, the protocol identifier (ID) in the IP header is UDP (17). Figure 1A As shown, the IP header is followed by the UDP header and then the ESP header. However, in the case of fragmentation, only the initial fragment carries the correct UDP header, as shown in Figure 1B As shown, each non-initial fragment carries an IP payload following the IP header, such as Figure 1C Therefore, the non-initial fragment may be mistakenly identified as a packet of a different protocol (for example, when the payload data after the IP header is the same as its protocol ID), and thus mistakenly processed by a router on the transmission path, which may cause service interruption.

[0010] The object of the present disclosure is to provide a communication device and a method therein that can solve or at least alleviate the above problems.

[0011] According to a first aspect of the present disclosure, a method performed by a first communication device is provided. The method includes: receiving an ESP packet as an initial fragment from a second communication device; calculating an MTU in a path from the second communication device to the first communication device according to the ESP packet; and notifying the second communication device of the calculated MTU.

[0012] In an embodiment, the calculation operation may include calculating the MTU as the payload length of the ESP packet.

[0013] In an embodiment, the notifying operation may include sending an IKEv2 message indicating the MTU to the second communications device.

[0014] In an embodiment, the IKEv2 message may be an IKEv2 information message.

[0015] According to a second aspect of the present disclosure, a first communication device is provided. The first communication device comprises a communication interface, a processor and a memory. The memory contains instructions executable by the processor, whereby the first communication device is operable to perform the method according to the first aspect above.

[0016] According to a third aspect of the present disclosure, a computer program is provided, wherein the computer program includes instructions, and when the instructions are executed by a processor of a first communication device, the first communication device is configured to perform the method according to the first aspect.

[0017] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided. The computer-readable storage medium stores computer-readable instructions. When the computer-readable instructions are executed by a processor of a first communication device, the first communication device is configured to execute the method according to the first aspect above.

[0018] According to a fifth aspect of the present disclosure, a method performed by a second communication device is provided. The method includes: receiving a notification of an MTU in a path from the second communication device to the first communication device from a first communication device; receiving an original IP packet to be sent to the first communication device in the path from a packet sender; calculating a packet size with an additional ESP header and an additional tunnel header for the original IP packet; and when the packet size exceeds the MTU: notifying the packet sender that the original packet is too large; or segmenting the original IP packet based on the MTU.

[0019] In an embodiment, the notifying operation may include sending an Internet Control Message Protocol (ICMP) message to the packet sender, the ICMP message indicating that the original packet is too large.

[0020] In an embodiment, the ICMP message may indicate "Destination Unreachable" using type 3 and code 4 for IP version 4 (IPv4) or "Too Big" for IP version 6 (IPv6).

[0021] In an embodiment, the original IP packet may be fragmented such that each resulting fragment with the additional ESP header and the additional tunnel header has a size less than or equal to the MTU.

[0022] In an embodiment, the method may further include: after the segmentation operation, encrypting and encapsulating each resulting fragment to send to the first communication device.

[0023] In an embodiment, the notification may include an IKEv2 message indicating the MTU.

[0024] In an embodiment, the IKEv2 message may be an IKEv2 information message.

[0025] According to a sixth aspect of the present disclosure, a second communication device is provided. The second communication device comprises a communication interface, a processor and a memory. The memory contains instructions that can be executed by the processor, whereby the second communication device is operable to perform the method according to the second aspect above.

[0026] According to a seventh aspect of the present disclosure, a computer program is provided, wherein the computer program includes instructions, and when the instructions are executed by a processor of a second communication device, the second communication device is configured to perform the method according to the second aspect.

[0027] According to an eighth aspect of the present disclosure, a computer-readable storage medium is provided, on which computer-readable instructions are stored, and when the computer-readable instructions are executed by a processor of a second communication device, the second communication device is configured to execute the method according to the second aspect.

[0028] Through the embodiments of the present disclosure, when the first communication device receives an ESP packet as an initial fragment from the second communication device, it can calculate the MTU in the path from the second communication device to the first communication device based on the ESP packet, and notify the second communication device of the calculated MTU. Upon receiving the notification of the MTU, the second communication device can calculate the packet size with the additional ESP header and the additional tunnel header for the original IP packet received from the packet sender, and when the packet size exceeds the MTU, notify the packet sender that the original packet is too large; or segment the original IP packet based on the MTU. In this way, segmentation of the ESP packet along the path can be prevented, thereby avoiding erroneous processing of the fragments as described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The above and other objects, features and advantages will become more apparent from the following description of the embodiments with reference to the accompanying drawings, in which:

[0030] Figures 1A to 1C is a schematic diagram showing a packet format used in a NAT-based IKE scenario;

[0031] Figure 2 is a flowchart illustrating a method according to an embodiment of the present disclosure;

[0032] Figure 3 is a schematic diagram showing the format of an IP header;

[0033] Figure 4A and Figure 4B The message format of a notification message according to an embodiment of the present disclosure is shown;

[0034] Figure 5 is a flowchart illustrating a method according to another embodiment of the present disclosure;

[0035] Figure 6 is a block diagram illustrating a first communication device according to an embodiment of the present disclosure; and

[0036] Figure 7 is a block diagram illustrating a second communication device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0037] As used herein, the term "communication device" refers to any device or node in a wired or wireless communication network. For example, a communication device may be a network device or node, such as an access network node or a core network node. Alternatively, a communication device may be a terminal device that can access a communication network, such as a user equipment (UE).

[0038] References in this specification to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Furthermore, these phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it should be considered that it is within the knowledge of those skilled in the art to implement such feature, structure, or characteristic in conjunction with other embodiments (whether or not explicitly described).

[0039] It should be understood that although the words "first" and "second" etc. can be used to describe various elements in this article, these elements should not be limited by these words. These terms are only used to distinguish elements from each other. For example, without departing from the scope of the exemplary embodiment, a first element can be referred to as a second element, and similarly, a second element can also be referred to as a first element. As used herein, the word "and / or" includes any and all combinations of one or more related listed words.

[0040] The terms used herein are only for the purpose of describing specific embodiments and are not intended to limit the exemplary embodiments. As used herein, the singular forms "a", "an" and "the" are intended to also include the plural forms, unless the context clearly indicates otherwise. It will be further understood that when used herein, the words "comprise", "have", "include" indicate the presence of stated features, elements and / or components, etc., but do not exclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0041] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs.

[0042] Figure 2 2 is a flow chart showing a method 200 according to an embodiment of the present disclosure. The method 200 may be performed by a first communication device.

[0043] At block 210, the first communications device receives an ESP packet as an initial fragment from the second communications device.

[0044] Specifically, upon receiving the ESP packet, the first communications device may determine whether it is a fragment, and if so, whether it is an initial fragment. Figure 3 The IP header format is shown. As shown, when the More Fragments (MF) bit in the Flags field is set and the Fragment Offset field has a value of 0, the packet is an initial fragment.

[0045] At block 220, the first communication device calculates the MTU in the path from the second communication device to the first communication device according to the ESP packet. Here, the MTU may be, for example, the minimum value among the MTUs of the nodes in the path.

[0046] For example, the MTU may be calculated as the payload length of the ESP packet.

[0047] At block 230, the first communications device notifies the second communications device of the calculated MTU.

[0048] For example, in block 230, the first communications device may send an IKEv2 message indicating the MTU to the second communications device.

[0049] Specifically, the IKEv2 message may be an IKEv2 information message with a notification type of "ALLOWED_MTU" to notify the second communication device of the MTU allowed for the current IKEv2 session. For example, the first communication device may send a message including HDR, SK{N[ALLOWED_MTU]} to the second communication device. The payload included in the message is indicated by the name listed below. Representation Payload ---------------------------- HDR IKE header (not payload) N Notification SK encrypted and authenticated

[0050] Figure 4A and Figure 4B The message format of the notification message used to carry the above-mentioned "ALLOWED_MTU" notification is shown. Here, the notification message type ALLOWED_MTU is defined as follows: Value notification message type --------------------------------- 16448 ALLOWED_MTU

[0051] Figure 4A The fields in can be defined as follows: - Next Payload – N (41), indicating that this is a notification payload; -C=0 - If the receiver does not understand the payload type code, skip the payload; - Protocol ID - This field MUST contain either (2) to indicate AH or (3) to indicate ESP; -SPI size – length in octets of the sub-SA SPI; - Notification message type - ALLOWED_MTU (16448) -Allowed_MTU notification data - 4 octets, such as Figure 4B shown.

[0052] refer to Figure 4B , "MTU Value" indicates the MTU allowed on the current forwarding path of the current IKEv2 session.

[0053] Figure 5is a flow chart showing a method 500 according to another embodiment of the present disclosure. The method 500 may be performed by a second communication device.

[0054] At block 510, the second communication device receives a notification of an MTU in a path from the second communication device to the first communication device from the first communication device. Here, the MTU may be, for example, the minimum value among the MTUs of the nodes in the path.

[0055] In an example, the notification may include an IKEv2 message indicating the MTU. The IKEv2 message may be an IKEv2 information message with an "ALLOWED_MTU" notification type, as described above in conjunction with Figure 4A and Figure 4B described.

[0056] At block 520, the second communication device receives an original IP packet from a packet sender (which may be an application running on the second communication device or another device) to be sent to the first communication device in the path.

[0057] At block 530, the second communications device calculates a packet size with the additional ESP header and the additional tunnel header for the original IP packet.

[0058] At block 540, when the packet size exceeds the MTU, the second communication device may notify the packet sender that the original packet is too large. In an example, the second communication device may send an ICMP message to the packet sender indicating that the original packet is too large. For example, for IPv4, the ICMP message may indicate "destination unreachable" (fragmentation required and DF (don't fragment) bit set) with type 3 and code 4, or for IPv6, the ICMP message may indicate "too large". Upon receiving the ICMP message, the packet sender may then follow the ICMP protocol to reduce the IP packet size.

[0059] Alternatively, at block 540, when the packet size exceeds the MTU, the second communication device may segment the original IP packet based on the MTU. For example, the original IP packet is segmented so that each resulting segment with an additional ESP header and an additional tunnel header has a size less than or equal to the MTU. The second communication device may then encrypt and encapsulate each resulting segment to send to the first communication device. Thus, any node along the path will not segment the segments. Upon receiving the segments, the first communication device simply follows conventional procedures to decapsulate and decrypt the segments and forward them to the corresponding application for reassembly.

[0060] Figure 6 is a block diagram of a first communication device 600 according to an embodiment of the present disclosure.

[0061] The first communication device 600 includes a communication interface 610, a processor 620, and a memory 630. The memory 630 may contain instructions executable by the processor 620, so that the first communication device 600 can be operated to perform, for example, the previously described Figure 2 Specifically, the memory 630 may contain instructions executable by the processor 620, whereby the first communication device 600 may be operable to: receive an ESP packet as an initial fragment from the second communication device; calculate the MTU in the path from the second communication device to the first communication device according to the ESP packet; and notify the second communication device of the calculated MTU.

[0062] In an embodiment, the calculation operation may include calculating the MTU as the payload length of the ESP packet.

[0063] In an embodiment, the notifying operation may include sending an IKEv2 message indicating the MTU to the second communications device.

[0064] In an embodiment, the IKEv2 message may be an IKEv2 information message.

[0065] Figure 7 is a block diagram of a second communication device 700 according to an embodiment of the present disclosure.

[0066] The second communication device 700 includes a communication interface 710, a processor 720, and a memory 730. The memory 730 may contain instructions executable by the processor 720, so that the second communication device 700 can be operated to perform, for example, the previously described Figure 5 Specifically, the memory 730 may contain instructions executable by the processor 720, whereby the second communication device 700 may be operable to: receive a notification of the MTU in the path from the second communication device to the first communication device from the first communication device; receive an original IP packet to be sent to the first communication device in the path from the packet sender; for the original IP packet, calculate the size of the packet with the additional ESP header and the additional tunnel header; and when the packet size exceeds the MTU: notify the packet sender that the original packet is too large; or segment the original IP packet based on the MTU.

[0067] In an embodiment, the notifying operation may include sending an ICMP message to the sender of the packet indicating that the original packet was too large.

[0068] In an embodiment, the ICMP message may indicate "Destination Unreachable" using type 3 and code 4 for IPv4, or "Too Big" for IPv6.

[0069] In an embodiment, the original IP packet may be fragmented such that each resulting fragment with the additional ESP header and the additional tunnel header has a size less than or equal to the MTU.

[0070] In an embodiment, the memory 730 may further contain instructions executable by the processor 720, whereby the second communication device 700 is operable to: after the segmentation operation, encrypt and encapsulate each resulting fragment to be sent to the first communication device.

[0071] In an embodiment, the notification may include an IKEv2 message indicating the MTU.

[0072] In an embodiment, the IKEv2 message may be an IKEv2 information message.

[0073] The present disclosure also provides at least one computer program product in the form of a non-volatile or volatile memory, such as a non-transitory computer-readable storage medium, an electrically erasable programmable read-only memory (EEPROM), a flash memory, and a hard disk drive. The computer program product includes a computer program. The computer program includes: when executed by the processor 620, the first communication device 600 performs, for example, the above combined Figure 2 or when executed by the processor 720, the second communication device 700 performs, for example, the above-mentioned combination Figure 5 Code / computer readable instructions describing the actions of a process.

[0074] The computer program product may be configured as a computer program code structured as computer program modules. The computer program modules may basically execute Figure 2 or Figure 5 The actions of the process shown.

[0075] The processor may be a single CPU (central processing unit), but may also include two or more processing units. For example, the processor may include a general-purpose microprocessor; an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor, such as an application-specific integrated circuit (ASIC). The processor may also include on-board memory for cache purposes. The computer program may be carried by a computer program product connected to the processor. The computer program product may include a non-transitory computer-readable storage medium storing the computer program. For example, the computer program product may be a flash memory, a random access memory (RAM), a read-only memory (ROM) or an EEPROM, and the above-mentioned computer program modules may be distributed on different computer program products in the form of memory in alternative embodiments.

[0076] The present disclosure has been described above with reference to its embodiments. It should be understood that various modifications, substitutions and additions may be made by those skilled in the art without departing from the spirit and scope of the present disclosure. Therefore, the scope of the present disclosure is not limited to the above specific embodiments, but is only limited by the appended claims.

Claims

1. A method (200) performed by a first communication device, comprising: receiving (210) an Encapsulating Security Payload ESP packet as an initial fragment from a second communication device; calculating (220) a maximum transmission unit MTU in a path from the second communication device to the first communication device based on the ESP packet; as well as The calculated MTU is notified (230) to the second communication device.

2. The method (200) according to claim 1, wherein: The calculation (220) includes: The MTU is calculated as the payload length of the ESP packet.

3. The method (200) according to claim 1 or 2, wherein: The notification (230) includes: An Internet Key Exchange Version 2 (IKEv2) message indicating the MTU is sent to the second communications device.

4. The method (200) according to claim 3, wherein: The IKEv2 message is an IKEv2 information message.

5. A method (500) performed by a second communication device, comprising: receiving (510) from a first communication device a notification of a maximum transmission unit MTU in a path from the second communication device to the first communication device; receiving (520) an original Internet Protocol IP packet from a packet sender to be sent to a first communication device in the path; For the original IP packet, calculating (530) a packet size with an additional Encapsulating Security Payload ESP header and an additional tunnel header; as well as When the packet size exceeds the MTU: notifying (540) the packet sender that the original packet is too large; or The original IP packet is fragmented based on the MTU (540).

6. The method (500) according to claim 5, wherein: The notifying (540) includes sending an Internet Control Message Protocol (ICMP) message to the packet sender, the ICMP message indicating that the original packet is too large.

7. The method (500) according to claim 6, wherein: The ICMP message indicates "Destination Unreachable" using type 3 and code 4 for IP version 4 "IPv4" or "Too Big" for IP version 6 "IPv6".

8. The method (500) according to claim 5, wherein: The original IP packet is fragmented such that each resulting fragment with the additional ESP header and the additional tunnel header has a size less than or equal to the MTU.

9. The method (500) according to claim 8, further comprising: After said segmentation (540), Each resulting fragment is encrypted and encapsulated for transmission to the first communication device.

10. The method (500) according to any one of claims 5 to 9, wherein: The notification includes an Internet Key Exchange Version 2 (IKEv2) message indicating the MTU.

11. The method (500) according to claim 10, wherein: The IKEv2 message is an IKEv2 information message.

12. A first communication device (600) comprising a communication interface (610), a processor (620) and a memory (630), the memory (630) comprising instructions executable by the processor (620), whereby the first communication device (600) is operable to perform the method according to any one of claims 1 to 4.

13. A computer program comprising instructions which, when executed by a processor of a first communication device, configure the first communication device to perform the method according to any one of claims 1 to 4.

14. A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor of a first communication device, configure the first communication device to perform the method according to any one of claims 1 to 4.

15. A second communication device (700) comprising a communication interface (710), a processor (720) and a memory (730), the memory (730) comprising instructions executable by the processor (720), whereby the second communication device (700) is operable to perform the method according to any one of claims 5 to 11.

16. A computer program comprising instructions which, when executed by a processor of a second communication device, configure the second communication device to perform a method according to any one of claims 5 to 11.

17. A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor of a second communication device, configure the second communication device to perform the method according to any one of claims 5 to 11.