Chip-based IPSEC encryption and decryption method and device
By coordinating IPSEC encryption and decryption with the CPU and hardware, the problems of high CPU burden and hardware complexity are solved, and efficient and flexible IPSEC encryption and decryption processing is achieved to adapt to various scenarios.
Patent Information
- Application Number
- CN202211714636.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-12-29
- Publication Date
- 2025-09-23
- Estimated Expiration
- 2042-12-29
AI Technical Summary
In the existing technology, IPSEC encryption and decryption processing consumes a lot of CPU resources when performed on the CPU, increasing delay and jitter. At the same time, the hardware implementation is complex and costly, and cannot support multiple scenarios.
The IPSEC encryption and decryption method combines CPU and hardware division of labor. It determines whether encryption and decryption are required by looking up the IPSEC table, uses the encryption and decryption engine on the chip to process, and distributes tasks between the CPU and hardware, including AH/ESP encryption and decryption pre-processing, post-processing and secondary encryption and decryption processing.
The IPSEC encryption and decryption scheme has been optimized, simplifying the complexity and cost of hardware design. It supports the processing of multiple IP option headers, flexibly controls the encryption and fragmentation order, and adapts to more scenarios.
Smart Images

Figure CN116015919B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of network communication technology, and in particular to a chip-based IPSEC encryption and decryption method and device. Background Art
[0002] With the rapid development of Internet technology, the security requirements for network data transmission are becoming increasingly stringent. This has led to the emergence of IPSEC (Internet Protocol Security). IPSEC is a three-layer tunnel encryption protocol developed by the IETF. The IPSEC protocol operates at the IP layer and provides transparent security services for IP networks. IPSEC protects user data transmitted between specific communicating parties (for example, between two security gateways) by establishing a tunnel, commonly referred to as an IPSEC tunnel. IPSEC offers the advantages of data confidentiality, integrity, and data origin authentication.
[0003] Data confidentiality is achieved by IPSEC encrypting the message before the sender transmits it over the network. However, the complete IPSEC encryption and decryption processing of the message on the CPU consumes a lot of CPU computing resources. If all messages are encrypted and decrypted on the CPU, it will greatly increase the CPU burden and increase the delay and jitter of message forwarding.
[0004] Another example is that the CPU will offload the messages that need to be encrypted and decrypted by IPSEC and the related encryption and decryption parameter information to the IPSEC hardware, and the hardware will perform the complete encryption and decryption processing. After completion, the message will be passed back to the CPU, and the CPU will perform subsequent forwarding processing. Due to the large number of types and complex situations of IPSEC encapsulation header processing, having hardware handle such complex operations will greatly increase the hardware's circuit design, area, power consumption and other costs; at the same time, the entire solution will also be limited by the hardware implementation. For scenarios that the hardware cannot support, the entire solution will not be able to support them.
[0005] The information disclosed in this background technology section is only intended to enhance understanding of the overall background of the invention and should not be regarded as an admission or any form of suggestion that the information constitutes the prior art already known to a person skilled in the art. Summary of the Invention
[0006] The object of the present invention is to provide a chip-based IPSEC encryption and decryption method and device for overcoming one or more technical problems raised in the prior art.
[0007] To achieve the above object, the present invention proposes a chip-based IPSEC encryption and decryption method, comprising the following steps:
[0008] The CPU receives the message and determines whether IPSEC encryption and decryption needs to be enabled before forwarding it;
[0009] For messages that require IPSEC encryption and decryption, AH / ESP encryption and decryption pre-processing is performed on the messages that require encryption and decryption by looking up the IPSEC table.
[0010] Send the message after AH / ESP encryption and decryption pre-processing to the encryption and decryption engine on the chip for encryption and decryption processing;
[0011] The CPU reads the encrypted and decrypted message, performs AH / ESP encryption and decryption processing, and then sends the message back to the CPU to check the IPSEC table again;
[0012] The second IPSEC table query information is used to determine whether the message needs to be encrypted and decrypted twice. The second encryption and decryption process is performed on the message that needs to be encrypted and decrypted twice, and the message that has been encrypted and decrypted is forwarded.
[0013] Preferably, the messages that need to be encrypted and decrypted include AH messages, ESP messages, and AH-ESP messages.
[0014] Preferably, the AH / ESP encryption and decryption preprocessing includes selecting one or more of the following AH / ESP encryption preprocessing for messages of different encryption and decryption protocols:
[0015] Buffer additional application;
[0016] Add packaging processing;
[0017] IP header variable field processing;
[0018] IP options header processing;
[0019] ESN processing;
[0020] ICV splicing.
[0021] Preferably, when the buffer additional application is used for encapsulating a long ESP message, the CPU applies for a buffer and appends it to the buffer linked list to prevent the tail of the message from exceeding the original buffer during message editing.
[0022] Preferably, the ICV splicing includes, when encapsulating the ESP message, deleting the ICV data at the end of the previous buffer from the ICV field spanning two buffers after the ESP tail, and adding this data to the next buffer to make the ICV data continuous.
[0023] Preferably, the AH / ESP encryption / decryption preprocessing includes selecting one or more of the following AH / ESP decryption preprocessing for messages of different encryption / decryption protocols:
[0024] Anti-retransmission protection;
[0025] IP header variable field processing;
[0026] IP options header processing;
[0027] ESN processing;
[0028] ICV splicing.
[0029] Preferably, the AH / ESP encryption / decryption post-processing includes selecting one or more of the following AH / ESP encryption / decryption post-processing for messages of different encryption / decryption protocol types:
[0030] IP header variable field recovery processing;
[0031] IP options header recovery processing;
[0032] ESN recovery processing.
[0033] Preferably, the AH / ESP encryption / decryption post-processing includes selecting one or more of the following AH / ESP decryption post-processing for messages of different encryption / decryption protocol types:
[0034] Anti-retransmission protection;
[0035] IP header variable field recovery processing;
[0036] IP options header recovery processing;
[0037] Decapsulation processing;
[0038] ESN recovery processing.
[0039] Preferably, the encryption and decryption processing in the encryption and decryption engine includes selecting authentication, encryption, decryption, verification, encryption first and then authentication, authentication first and then encryption, decryption first and then verification, verification first and then decryption, or bypassing encryption and decryption processing for messages of different encryption and decryption protocol types.
[0040] Preferably, for AH messages and ESP messages, after encryption and decryption are completed, they are forwarded according to the lookup information in the IPSEC table;
[0041] For AH-ESP messages, after completing ESP encryption, a second AH encryption process is performed based on the lookup information in the IPSEC table, or after completing AH decryption, a second ESP decryption process is performed based on the lookup information in the IPSEC table, and then the message is forwarded based on the lookup information in the IPSEC table.
[0042] Preferably, when editing a message before forwarding, it is determined whether the message length requires fragmentation. For messages that require fragmentation, the order of fragmentation and IPSEC enabling is set to perform fragmentation first and then encryption and decryption or encryption and decryption first and then fragmentation.
[0043] The present invention also proposes a chip-based IPSEC encryption and decryption device, comprising:
[0044] The CPU packet receiving module is used to receive messages sent from the chip and determine whether IPSEC encryption and decryption needs to be enabled before forwarding;
[0045] The IPSEC table lookup module is used to obtain the table lookup information for message encryption and decryption processing by looking up the IPSEC table for messages that need to be encrypted and decrypted, and send the messages that need to be encrypted and decrypted to the AH / ESP encryption and decryption preprocessing module, and forward the messages that have completed the encryption and decryption processing;
[0046] An AH / ESP encryption / decryption preprocessing module is used to perform different AH / ESP encryption / decryption preprocessing on messages of different encryption / decryption protocols according to the table lookup information;
[0047] The encryption and decryption engine is used to encrypt and decrypt the messages after AH / ESP encryption and decryption preprocessing;
[0048] The AH / ESP encryption and decryption post-processing module is used to perform different AH / ESP encryption and decryption post-processing on messages of different encryption and decryption protocols, and send the messages to the CPU packet receiving module again to determine whether the messages need secondary encryption and decryption processing by checking the IPSEC table module again.
[0049] Preferably, the AH / ESP encryption and decryption preprocessing module includes an AH / ESP encryption preprocessing module, which includes one or more modules selected from the group consisting of a buffer appending application module, an encapsulation processing module, an IP header variable field processing module, an IP option header processing module, an ESN processing module, and an ICV splicing module; wherein
[0050] The buffer appending module is used to apply for a buffer through the CPU and append it to the buffer list when performing ESP encapsulation on long packets to prevent the tail of the packet from exceeding the original buffer during editing.
[0051] The encapsulation processing module is used to perform different encapsulation processing on messages of different encryption and decryption protocols in different encapsulation modes;
[0052] The IP header variable field processing module is used to clear some fields in the IP header of the ESP message;
[0053] The IP option header processing module is used to clear or replace some fields in the IP option header or extension header in the message.
[0054] An ESN processing module is used to add an ESN field to ESN-enabled messages and delete the ESN field after encryption is completed;
[0055] The ICV splicing module, used in ESP message encapsulation, removes the ICV data at the end of the previous buffer and adds this data to the next buffer to ensure continuous processing of the ICV data.
[0056] Preferably, the AH / ESP encryption / decryption preprocessing module includes an AH / ESP decryption preprocessing module, and the AH / ESP decryption preprocessing module includes one or more modules of an anti-retransmission protection module, an IP header variable field processing module, an IP option header processing module, an ESN processing module, and an ICV splicing module, wherein
[0057] Anti-retransmission protection module, used for anti-retransmission protection check of messages;
[0058] The IP header variable field processing module is used to clear some fields in the IP header of the ESP message;
[0059] The IP option header processing module is used to clear or replace some fields in the IP option header or extension header in the message.
[0060] An ESN processing module is used to add an ESN field to ESN-enabled messages and delete the ESN field after decryption is completed;
[0061] The ICV splicing module, used in ESP message encapsulation, removes the ICV data at the end of the previous buffer and adds this data to the next buffer to ensure continuous processing of the ICV data.
[0062] Preferably, the AH / ESP encryption and decryption post-processing module includes an AH / ESP encryption post-processing module, and the AH / ESP encryption post-processing module includes one or more modules of an IP header variable field recovery processing module, an IP option header recovery processing module, and an ESN recovery processing module, wherein
[0063] The IP header variable field recovery processing module is used to recover the variable field according to the information saved during the message encryption preprocessing;
[0064] An IP option header recovery processing module is used to recover some of the cleared or replaced fields in the IP option header or extension header based on the information saved during message encryption preprocessing;
[0065] The ESN recovery processing module is used to delete the ESN field from the message that has been added during encryption preprocessing.
[0066] Preferably, the AH / ESP encryption / decryption post-processing module includes an AH / ESP decryption post-processing module, and the AH / ESP decryption post-processing module includes one or more modules of an anti-retransmission protection module, an IP header variable field recovery processing module, an IP option header recovery processing module, a decapsulation processing module, and an ESN recovery processing module, wherein
[0067] Anti-retransmission protection module, used for anti-retransmission protection check of messages;
[0068] The IP header variable field recovery processing module is used to recover the variable field according to the information saved during the message decryption preprocessing;
[0069] An IP option header recovery processing module is used to restore some of the cleared or replaced fields in the IP option header or extension header based on the information saved during the message decryption preprocessing; a decapsulation module is used to perform different decapsulation processing on messages in different encapsulation modes;
[0070] The ESN recovery processing module is used to delete the ESN field from the message that has been added during decryption preprocessing.
[0071] Compared with the prior art, the present invention optimizes the IPSEC encryption and decryption scheme by adopting an IPSEC encryption and decryption method combining CPU and hardware division of labor. At the same time, it also has the following advantages:
[0072] 1. Since ASIC only needs to perform encryption and decryption operations, the encryption and decryption processes are normalized and isomorphized during design, which greatly simplifies the design complexity and cost of the IPSEC engine in ASIC.
[0073] 2. By cyclically encrypting or decrypting twice, the secondary encryption of the AH-ESP protocol can be achieved without increasing hardware costs.
[0074] 3.Support AH authentication processing of various IP option headers.
[0075] 4. During the encryption process, if the tail edit is too long, you can freely request additional buffers, without being limited by the buffer's tailroom reserved size.
[0076] 5. You can flexibly control whether to use the encryption first and then fragmentation or fragmentation first and then encryption scheme. BRIEF DESCRIPTION OF THE DRAWINGS
[0077] Figure 1 This is a schematic diagram of the architecture of a chip-based IPSEC data encryption and decryption method according to an embodiment of the present invention;
[0078] Figure 2 This is a flowchart of a chip-based IPSEC data encryption method according to an embodiment of the present invention;
[0079] Figure 3 This is a flow chart of a chip-based IPSEC data encryption method according to an embodiment of the present invention;
[0080] Figure 4 The Buffer data structure disclosed in the embodiment of the present invention;
[0081] Figure 5 This is a flowchart of a chip-based IPSEC data decryption method according to an embodiment of the present invention;
[0082] Figure 6 The figure is a flow chart of a chip-based IPSEC data decryption method according to an embodiment of the present invention. DETAILED DESCRIPTION
[0083] The specific embodiments of the present invention are described in detail below with reference to the accompanying drawings, but it should be understood that the protection scope of the present invention is not limited by the specific embodiments.
[0084] Unless otherwise expressly stated, throughout the specification and claims, the term "comprise" or its variations such as "include" or "comprising", etc. will be understood to include the stated modules, elements or components but not to exclude other modules, elements or other components.
[0085] The present invention discloses a chip-based IPSEC encryption and decryption method, such as Figure 1 As shown in the figure, it optimizes the IPSEC encryption and decryption process based on the characteristics of CPU and hardware. Figure 2 、 3 As shown, the chip-based IPSEC encryption method of this embodiment includes the following processing steps:
[0086] S11. The CPU receives the message and determines whether IPSEC encryption needs to be enabled before forwarding it.
[0087] Specifically, for plaintext messages that need to be encrypted, after the ASIC's port inbound direction receives them, it performs the normal packet reception and sends them to the CPU for processing. This includes applying for a buffer for the message to cache the message data, applying for a normal Normal DMA (Direct Memory Access) receive direction RX descriptor, filling in the storage address of the message in the buffer in the RX descriptor, and writing the descriptor to the RX Ring (DMA receive direction ring queue) corresponding to the Normal DMA, and then waiting for CPU processing.
[0088] The CPU reads the RX descriptor from the RX Ring queue in the receive direction of the Normal DMA, and reads the Buffer information according to the RX descriptor. The RX scheduling module then performs RX scheduling processing. The message parsing module performs message parsing processing to parse out the second, third, and fourth layer header information of the message. The Ethernet layer packet receiving processing module performs conventional Ethernet layer processing. The IP packet receiving processing module performs IP layer packet receiving processing. During the packet receiving processing, it is determined whether the message needs to be reassembled. If so, it is sent to the IP message reassembly module for reassembly; if not, it is sent to the forwarding table lookup module for table lookup and forwarding.
[0089] For packets that need to be reassembled, after entering the IP packet reassembly module, they will be reassembled and collected. After the IP packets are reassembled into a complete IP packet, they are sent back to the IP layer packet receiving and processing module for subsequent forwarding processing.
[0090] Packets that don't require reassembly are sent to the forwarding table lookup module for regular forwarding table lookup. The forwarding table here refers to all table entries searched during Layer 3 forwarding, including the NAT table, routing table, neighbor table, ECMP table, and so on. After all entries are searched, the egress and editing information is obtained and sent to the message editing module.
[0091] Before the message enters the message editing module for editing and forwarding, it is necessary to determine whether the message length exceeds the IP MTU size and whether IPSEC encryption is required. Whether the message needs to be fragmented is determined based on whether the message length exceeds the IP MTU size. If fragmentation is required, it is sent to the IP message fragmentation module. On the other hand, it is checked whether the IPSEC encryption function is enabled. If enabled, it is sent to the IPSEC table search module. For messages that do not require fragmentation and do not have IPSEC encryption enabled, regular message editing operations are performed based on the previously obtained editing information. For messages that require fragmentation and have IPSEC encryption enabled, the order of determining whether to fragment first or to determine whether IPSEC is enabled first can be controlled through configuration, so that the operation scheme of fragmentation first and then encryption or encryption first and then fragmentation can be adopted.
[0092] For messages that need to be fragmented, they are fragmented according to the IP MTU size. The fragmented multi-piece IP messages are sent back to the message editing module for subsequent forwarding processing.
[0093] S12. For messages that require IPSEC encryption, different AH / ESP encryption pre-processing is performed on messages of different encryption protocols that require encryption by looking up the IPSEC table.
[0094] Specifically, for messages that need to enable IPSEC encryption, the IPSEC table search module is entered. The IPSEC table module includes the SPD (Security Policy Database, which determines the forwarding policy of the message) table and the SAD (Security Association Database, which determines the encryption parameters of the encrypted message) table. The SPD table is used to determine the forwarding policy of the message, and the encryption parameters of the message can be obtained through the SAD table.
[0095] After searching the SPD table, you will get the following three operation methods:
[0096] (1) Protect operation, that is, encryption protection processing, indicates that the message traffic needs to be encrypted. At the same time, the SAD table will be obtained. According to the encryption parameters obtained from the table, the message is sent to the AH / ESP encryption preprocessing module for AH / ESP encryption preprocessing.
[0097] (2) Bypass operation, i.e. bypass processing, means that the message traffic does not need to be encrypted and is sent to the message sending processing module for normal forwarding processing.
[0098] (3) The discard operation, i.e., discard processing, indicates that the message traffic needs to be discarded and is discarded directly.
[0099] For messages that require encryption protection and are sent to the AH / ESP encryption preprocessing module, different preprocessing is performed based on the different message requirements of different IPSEC protocols, namely AH messages, ESP messages, and AH-ESP messages. Among them, AH messages are messages that only need to be authenticated according to the AH protocol, ESP messages are messages that need to be encrypted and authenticated according to the ESP protocol, and AH-ESP messages are messages that need to first undergo ESP encryption and authentication processing, and then AH authentication for dual protection. The preprocessing in the AH / ESP encryption preprocessing module includes:
[0100] Buffer additional application;
[0101] Add packaging processing;
[0102] IP header variable field processing;
[0103] IP options header processing;
[0104] ESN processing;
[0105] ICV splicing. The CPU and ASIC transmit message data and related information through the agreed Buffer data structure. Buffer addition is applied when the long ESP message is encapsulated. Figure 4 The following table shows the Buffer structure involved in this embodiment:
[0106]
[0107] The maximum number of bytes added to the ESP tail is 255 (esp-t) + 4 (esn) + 16 (icv) = 275. If the tail space is insufficient, the tail editing may exceed the original buffer size. Therefore, during AH / ESP encryption preprocessing, for long ESP-encapsulated packets (when the packet length exceeds the pktData size), the CPU applies for a buffer appended to the buffer list through buffer appending. Multiple buffers can be organized like a linked list to store the entire packet information, solving the problem of insufficient tail space when encapsulating long ESP packets.
[0108] The encapsulation process in AH / ESP encryption preprocessing is due to the different encapsulation modes of AH and ESP, namely transport and tunnel, and the need to perform different encapsulation operations when different ESN and ESP-NAT options are superimposed. The details are shown in the following table:
[0109]
[0110]
[0111] The processing of variable fields in the IP header only involves ESP packets, including clearing some fields in the IPv4 and IPv6 headers. Specifically, the DSCP, ECN, flags, fragment offset, TTL, and checksum fields in the IPv4 header are cleared and saved, and the DSCP, ECN, flow label, and hop limit fields in the IPv6 header are cleared and saved.
[0112] When processing IP option headers, some IP option headers require special processing before participating in AH authentication. There are many types of IP option headers, and their location and processing methods are not fixed. Using hardware to process them would be very expensive. The specific processing is as follows:
[0113] IPv4 options header:
[0114]
[0115] IPv6 extension header:
[0116]
[0117]
[0118] ESN processing applies to both AH and ESP packets. For AH packets, when the ESN function is enabled, a 4-byte ESN field is added after the payload for authentication, but the final packet does not carry this field. For ESP encapsulation, when the ESN function is enabled and the CBC-HMAC mode is used, a 4-byte ESN field is added after the ESP trailer for authentication, but the final packet does not carry this field. When using GCM mode for ESP packets, the ESN is carried in the AAD field, eliminating the need for separate ESN processing. When editing software, add the ESN field first and then delete it after encryption and authentication are complete.
[0119] During ICV splicing, for AH packets, since the ICV field is located in the AH header and is always in the first buffer, the ICV data is always continuous, thus eliminating the need for ICV splicing. However, for ESP encapsulation, the ICV field is located after the ESP tail and may span two buffers, resulting in discontinuous ICV data. To address this issue, an ICV splicing operation is designed during preprocessing to facilitate the IPSEC engine's reading of continuous ICV data. This splicing operation removes the ICV data at the end of the previous buffer and appends it to the next buffer.
[0120] For AH, ESP, and AH-ESP packets using different encryption and decryption protocols, you can select one or more of the above preprocessing methods for preprocessing before encryption based on the applicability of each AH / ESP preprocessing method.
[0121] S13, sending the message after AH / ESP encryption pre-processing to the encryption and decryption engine on the chip via SEC DMA for encryption processing;
[0122] Specifically, for messages that have completed AH / ESP encryption pre-processing, the plaintext is sent to the security device module, which applies for a TX descriptor for the SEC DMA (encryption and decryption DMA) in the sending direction for the message. The buffer address and relevant parameters in the SAD table entry are filled in the descriptor, and the descriptor is written to the TX Ring of the outgoing direction circular queue corresponding to the SEC DMA, and then waits for ASIC processing. If the TX Ring of the outgoing direction circular queue is full at this time, it means that the IPSEC encryption and decryption engine has exceeded the bandwidth, then the message will be discarded and IPSEC statistics will be counted, including encryption statistics and over-bandwidth discard statistics.
[0123] The IPSEC encryption and decryption engine reads the TX descriptor from the SEC DMA's transmit direction circular queue, the TX Ring, and reads the Buffer information and encryption parameter information in the SAD table based on the TX descriptor. The Buffer information and SAD information are then sent to the IPSEC encryption and decryption engine for encryption. If the Buffer information and SAD information cannot be sent, it means that the IPSEC encryption and decryption engine has exceeded the bandwidth. In this case, a stop reading signal is sent to stop it from reading the descriptors in the TX Ring.
[0124] For messages normally sent to the IPSEC encryption and decryption engine, the encryption and decryption engine encrypts the messages. The specific encryption processing includes the following five methods:
[0125] 1) Encryption first, then authentication: first convert the plaintext data into ciphertext data, and then calculate the ICV value of the ciphertext data.
[0126] 2) Authentication before encryption: First calculate the ICV value for the plaintext data, and then convert the plaintext data and ICV value into ciphertext data.
[0127] 3) Encryption only: only convert plaintext data into ciphertext data.
[0128] 4) Authentication only: The ICV value is calculated based only on the data (plaintext or ciphertext).
[0129] 5) Bypass: Do not convert data and do not calculate ICV value.
[0130] The engine selects the corresponding operation based on the descriptor configuration parameters. After encryption is completed, the ciphertext data and ICV value are backfilled into the corresponding position of the buffer. At this time, the buffer contains the encrypted message data.
[0131] Next, apply for the RX descriptor of SEC DMA, fill in the buffer address and processing result related parameters in the descriptor, and write the descriptor into the receiving direction ring queue RX Ring corresponding to SEC DMA, and then wait for CPU processing.
[0132] S14, the CPU reads the encrypted message, performs different AH / ESP encryption post-processing on the messages of different encryption and decryption protocols, and sends the encrypted message to the CPU again for packet reception and IPSEC table re-checking;
[0133] The CPU reads the RX descriptor from the SEC DMA's receive direction circular queue RX Ring, reads the buffer information and processing results based on the RX descriptor, enters the security device to read the ciphertext module, and makes a judgment based on the returned result: if the return is successful, the encrypted message is sent to the AH / ESP encryption post-processing module; if the return fails, the message is discarded and IPSEC statistics are performed, including encryption statistics and error statistics.
[0134] The AH / ESP post-encryption processing module processes encrypted packets after encryption. Similar to the AH / ESP pre-encryption processing, it primarily processes the encapsulation header, including the following:
[0135] IP header variable field recovery processing
[0136] IP options header recovery processing
[0137] ESN recovery processing
[0138] Corresponding to encryption preprocessing, IP header variable field recovery requires restoring variable fields based on information saved during preprocessing. IP options header recovery also requires restoring some cleared or replaced fields in the IP options header or extension header based on information saved during preprocessing. ESN recovery involves deleting the ESN field if it was added during encryption preprocessing.
[0139] S15. Determine whether the message needs to be encrypted twice based on the information in the IPSEC table, perform secondary encryption on the message that needs secondary encryption, and forward the message that has completed encryption.
[0140] After the encryption is completed, the message is sent to the IP packet receiving and processing module again, and then enters the forwarding table search module again. For the tunnel mode, the forwarding table is rechecked in the tunnel mode. At this time, the message is encapsulated with an IP header, and the new IP header information is used to perform a forwarding table search operation to obtain new exit and editing information.
[0141] After checking the forwarding table, the message enters the message editing module again and is sent to the IPSEC table search module according to the IPSEC enabled. Since the AH-ESP message needs to be encrypted twice, the message will be encrypted by ESP first. After the encryption is completed, the message will be encrypted by AH again, that is, it needs to go through the encryption process twice. At this time, the corresponding SPD table entry needs to be issued, the protect operation is performed, and the message is sent to the AH / ESP encryption preprocessing module. Then, the encryption unloading process is carried out again, that is, the encryption preprocessing, encryption processing and encryption post-processing are performed again, and then the CPU packet receiving and table lookup processing flow is entered.
[0142] For AH messages, ESP messages, and AH-ESP messages that have completed secondary encryption, since the encryption process has been completed, the SPD table entry cannot be found at this time. Therefore, the bypass operation is performed and the message is sent to the message sending processing module. According to the export information, the message is prepared to be sent, and enters the priority mapping module for conventional priority mapping processing. The corresponding QoS queue is mapped and enters the message queue module. The message is sent to the mapped QoS queue for conventional scheduling and traffic shaping processing, enters the TX scheduling module for conventional TX scheduling processing, enters the CPU packet sending module, applies for the TX descriptor of Normal DMA, fills in the Buffer address in the descriptor, and writes the descriptor to the outgoing ring queue TX Ring corresponding to Normal DMA, and then waits for ASIC processing.
[0143] The ASIC reads the descriptor from the outgoing circular queue TX Ring of the Normal DMA and reads the buffer information based on the TX descriptor. The ASIC releases the buffer resources and performs regular packet processing, thus completing the entire encryption process. The encryption process is handled by the CPU and ASIC hardware in a division of labor. The CPU is responsible for table lookup and encapsulation header processing, while the ASIC is responsible for encryption and authentication processing. This maximizes the balance between CPU burden and hardware cost, making the entire IPSEC solution more flexible and adaptable to more scenarios.
[0144] For ciphertext messages that need to be decrypted, the decryption process is similar to the encryption process, such as Figure 4 、 5 As shown, the specific steps include:
[0145] S21. The CPU receives the message and determines whether IPSEC decryption needs to be enabled before forwarding it.
[0146] Specifically, for ciphertext messages that need to be decrypted, after the ASIC's port inbound direction receives them, it performs the normal packet reception and uploading process to the CPU, including applying for a buffer for the message to cache the message data, applying for the RX descriptor of Normal DMA, filling in the storage address of the message in the buffer in the RX descriptor, and writing the descriptor to the RX Ring of the receiving direction corresponding to Normal DMA, and then waiting for CPU processing.
[0147] The CPU reads the RX descriptor from the RX Ring queue in the receive direction of the Normal DMA and reads the buffer information based on the RX descriptor. The RX scheduling module then performs RX scheduling processing. The message parsing module then performs message parsing processing to parse out the second and third layer header information of the message. Since the fourth layer information is encrypted, no parsing is required here. After parsing, the message enters the Ethernet layer packet receiving processing module. After the Ethernet layer packet receiving processing module performs conventional Ethernet layer processing, the message is sent to the IP packet receiving processing module for IP layer packet processing. During the packet receiving processing, it determines whether the message needs to be reassembled. If so, it is sent to the IP message reassembly module for reassembly. At the same time, it determines whether the IPSEC function is enabled and whether it is an IPSEC message. If so, it is sent to the IPSEC table search module.
[0148] For packets that require reassembly, they enter the IP packet reassembly module for collection and reassembly. Once the IP packets are reassembled into a complete IP packet, they are sent back to the IP layer packet receiving module for subsequent forwarding. For packets that do not require reassembly and do not have PSEC enabled, regular IP layer packet receiving is performed.
[0149] For messages that require reassembly and IPSEC function enablement, the order of determining reassembly or IPSEC enablement first can be controlled through configuration, thereby controlling whether decryption is performed first and then reassembly or first and then decryption.
[0150] S22. For messages that require IPSEC decryption, different AH-ESP decryption preprocessing is performed on messages of different decryption protocols that require decryption by looking up the IPSEC table.
[0151] Specifically, for messages that need to enable IPSEC decryption, enter the IPSEC table search module. The IPSEC table module includes the SPD table and the SAD table. First, search the SPD table entry and you will get the following three operation methods:
[0152] (1) The protect operation, i.e., decryption protection processing, indicates that the message traffic needs to be decrypted. At the same time, the SAD table will be obtained and the message will be sent to the AH / ESP decryption pre-processing module based on the decryption parameters obtained from the table.
[0153] (2) Bypass operation, i.e. bypass processing, means that the message traffic does not need to be decrypted and is sent to the message sending processing module for normal forwarding processing.
[0154] (3) The discard operation, i.e., discard processing, indicates that the message traffic needs to be discarded and is discarded directly.
[0155] For messages sent to the AH / ESP encryption preprocessing module that need to be decrypted, different preprocessing is performed based on the different message requirements of different IPSEC protocols, namely AH messages, ESP messages, and AH-ESP messages. Among them, AH messages are messages that only need to be verified according to the AH protocol, ESP messages are messages that need to be decrypted and verified according to the ESP protocol, and AH-ESP messages are messages that need to first undergo AH verification and then undergo ESP decryption and verification processing for dual protection. The AH / ESP decryption preprocessing in the AH / ESP encryption preprocessing module includes:
[0156] Anti-retransmission protection;
[0157] IP header variable field processing;
[0158] IP options header processing;
[0159] ESN processing;
[0160] ICV splicing.
[0161] Among them, the anti-retransmission protection processing is to perform an anti-retransmission protection check on the message. If the check fails, the message will be discarded.
[0162] The processing of variable fields in the IP header only involves ESP packets, including clearing some fields in the IPv4 and IPv6 headers. Specifically, the DSCP, ECN, flags, fragment offset, TTL, and checksum fields in the IPv4 header are cleared and saved, and the DSCP, ECN, flow label, and hop limit fields in the IPv6 header are cleared and saved.
[0163] When processing IP option headers, some IP option headers require special processing before participating in AH authentication. There are many types of IP option headers, and their location and processing methods are not fixed. Using hardware to process them would be very expensive. The specific processing is as follows:
[0164] IPv4 options header:
[0165]
[0166] IPv6 extension header:
[0167]
[0168]
[0169] ESN processing applies to both AH and ESP packets. For AH packets, when the ESN function is enabled, a 4-byte ESN field must be added after the payload for authentication, but the final packet does not carry this field. For ESP packets, when the ESN function is enabled and the CBC-HMAC mode is used, a 4-byte ESN field must be added after the ESP trailer for authentication, but the final packet does not carry this field. When ESP packets are in GCM mode, the ESN is carried in the AAD field, eliminating the need for separate ESN processing. When editing software, add the ESN field first and then delete it after decryption and verification are complete.
[0170] During ICV splicing, for AH packets, the ICV field is located in the AH header, meaning it is always in the first buffer. Therefore, ICV data is always continuous and therefore does not require ICV splicing. However, for ESP packets, the ICV field is located after the ESP tail and may span two buffers, resulting in discontinuous ICV data. To address this, an ICV splicing operation is designed during preprocessing to facilitate the IPSEC engine's reading of continuous ICV data. This splicing operation removes the ICV data at the end of the previous buffer and appends it to the next buffer.
[0171] For different types of AH, ESP, and AH-ESP packets, one or more of the above preprocessing methods can be selected based on the applicability of each AH / ESP preprocessing method to perform preprocessing before decryption in the AH / ESP encryption preprocessing module.
[0172] S23, sending the message after AH-ESP decryption pre-processing to the encryption and decryption engine on the chip via SEC DMA for decryption processing;
[0173] For messages that have completed AH / ESP decryption preprocessing, the ciphertext is sent to the security device module, which applies for a SECDMA (encryption and decryption DMA) sending direction TX descriptor for the message, fills in the buffer address and related parameters in the SAD table entry in the descriptor, and writes the descriptor into the sending direction circular queue TX Ring corresponding to the SEC DMA, and then waits for ASIC processing. If the sending direction circular queue TX Ring is full at this time, it means that the IPSEC encryption and decryption engine has exceeded the bandwidth, then the message will be discarded and IPSEC statistics will be counted, including encryption statistics and excessive bandwidth discard statistics.
[0174] The IPSEC encryption and decryption engine reads the TX descriptor from the SEC DMA's transmit direction circular queue, the TX Ring, and reads the buffer information and decryption parameter information in the SAD table based on the TX descriptor. The buffer information and SAD information are then sent to the IPSEC encryption engine for encryption. If the buffer information and SAD information cannot be sent, it means that the IPSEC encryption and decryption engine has exceeded the bandwidth. At this time, a stop reading signal is sent to stop it from reading the descriptors in the TX Ring.
[0175] For messages normally sent to the IPSEC encryption and decryption engine, the encryption and decryption engine performs decryption processing on the messages. The specific decryption processing includes the following five methods:
[0176] 1) Decrypt first and then verify: first convert the ciphertext data into plaintext data and ICV value, then calculate the ICV value of the plaintext data, and compare whether the two ICV values match.
[0177] 2) Verify first and then decrypt: First calculate the ICV value of the ciphertext data, and compare the ICV value with the ICV value at the end of the message to see if they match, and then convert the ciphertext data into plaintext data.
[0178] 3) Decryption only: only convert the ciphertext data into plaintext data.
[0179] 4) Verification only: Calculate and compare the ICV value based only on the data (plaintext or ciphertext).
[0180] 5) Bypass: Do not convert data, nor calculate or compare ICV values.
[0181] The engine selects the corresponding operation based on the descriptor configuration parameters. After decryption is completed, the plaintext data and ICV value are backfilled into the corresponding position of the buffer. At this time, the buffer contains the decrypted message data.
[0182] Next, apply for the RX descriptor of SEC DMA, fill in the buffer address, ICV comparison result and processing result related parameters in the descriptor, and write the descriptor into the receiving direction ring queue RX Ring corresponding to SEC DMA, and then wait for CPU processing.
[0183] S24, the CPU reads the decrypted message, performs different AH / ESP decryption post-processing on the messages of different decryption protocols, and sends the decrypted message to the CPU again for packet reception and IPSEC table re-checking;
[0184] The CPU reads the RX descriptor from the SEC DMA's receive direction circular queue RX Ring, reads the buffer information and processing results based on the RX descriptor, enters the security device's plaintext reading module, and makes a judgment based on the returned result: if the return is successful, the decrypted message is sent to the AH / ESP decryption post-processing module; if the return fails, the message is discarded and IPSEC statistics are performed, including decryption statistics and error statistics.
[0185] The post-decryption processing of the decrypted message in the AH / ESP post-decryption processing module corresponds to the AH / ESP decryption pre-processing, mainly including
[0186] Anti-retransmission protection;
[0187] IP header variable field recovery processing;
[0188] IP options header recovery processing;
[0189] Decapsulation processing;
[0190] ESN recovery processing.
[0191] Corresponding to the decryption preprocessing, the anti-retransmission protection process is to perform an anti-retransmission protection check on the message again. If the check passes, the anti-retransmission protection window is updated; if the check fails, the message is discarded.
[0192] For IP header variable field recovery, the variable field needs to be restored based on the information saved during decryption preprocessing. For IP option header recovery, some fields that were cleared or replaced in the IP option header or extension header need to be restored based on the information saved during decryption preprocessing.
[0193] For decapsulation, AH and ESP packets can be encapsulated in different modes, transport and tunnel, and different decapsulation operations are performed when the ESN and ESP-NAT options are enabled. The following table lists the specific decapsulation operations:
[0194]
[0195]
[0196] For ESN recovery, if the ESN field was added during encryption preprocessing, it needs to be deleted.
[0197] S25. Determine whether the message needs to be decrypted twice based on the information in the IPSEC table, perform secondary decryption on the message that needs secondary decryption, and forward the message after the decryption is completed.
[0198] After the decryption is completed, the message is sent to the IP packet processing module again. After the IP packet processing, it enters the forwarding table lookup module again. For the tunnel mode, the outer IP header of the message is decapsulated. At this time, the inner IP header information is used to perform a forwarding table lookup operation to obtain new exit and editing information.
[0199] Next, the message enters the message editing module and is sent to the IPSEC table lookup module to look up the IPSEC table again before editing and forwarding. Since the AH-ESP message needs to be decrypted twice, that is, the message will first be AH decrypted, and then the ESP decryption will be performed on the message after decryption, which means that two decryption processes are required. At this time, for the message that has completed one AH decryption, the corresponding SPD table entry needs to be issued, the protect operation is performed, and the message is sent to the AH / ESP decryption preprocessing module, and then the decryption unloading process is performed again, that is, AH / ESP decryption preprocessing, decryption processing and AH / ESP decryption post-processing are performed again, and then it is sent to the CPU to look up the packet table again.
[0200] For AH messages and ESP messages that have completed decryption, as well as AH-ESP messages that have completed secondary decryption, no SPD table entry can be found at this time. The bypass operation is performed and the message is sent to the message sending processing module for subsequent forwarding processing. That is, the message is sent to the message sending processing module. According to the export information, the message is prepared to be sent, and enters the priority mapping module for conventional priority mapping processing. The corresponding QoS queue is mapped and enters the message queue module. The message is sent to the mapped QoS queue for conventional scheduling and traffic shaping processing, enters the TX scheduling module for conventional TX scheduling processing, enters the CPU packet sending module, applies for the TX descriptor of Normal DMA, fills in the Buffer address in the descriptor, and writes the descriptor to the sending direction ring queue TX Ring corresponding to Normal DMA, and then waits for ASIC processing.
[0201] The ASIC reads the descriptor from the Normal DMA's transmit direction circular queue, the TX Ring, and reads the buffer information based on the TX descriptor. The ASIC releases the buffer resources and performs regular packet processing, thus completing the entire decryption process. This process is a combination of the CPU and ASIC hardware division of labor. The CPU is responsible for table lookup and decapsulation header processing, while the ASIC is responsible for decryption and verification processing. This maximizes the balance between CPU burden and hardware cost, making the entire IPSEC solution more flexible and adaptable to more scenarios.
[0202] The embodiment of the present invention further discloses a chip-based IPSEC encryption device, which includes:
[0203] The CPU packet receiving module is used to receive messages sent from the chip and determine whether IPSEC encryption and decryption needs to be enabled before forwarding;
[0204] The IPSEC table lookup module is used to obtain the table lookup information for message encryption and decryption processing by looking up the IPSEC table for messages that need to be encrypted and decrypted, and send the messages that need to be encrypted and decrypted to the AH / ESP encryption and decryption preprocessing module, and forward the messages that have completed the encryption and decryption processing;
[0205] An AH / ESP encryption / decryption preprocessing module is used to perform different AH / ESP encryption / decryption preprocessing on messages of different encryption / decryption protocols according to the table lookup information;
[0206] The encryption and decryption engine is used to encrypt and decrypt the messages after AH / ESP encryption and decryption preprocessing;
[0207] The AH / ESP encryption and decryption post-processing module is used to perform different AH / ESP encryption and decryption post-processing on messages of different encryption and decryption protocols, and send the messages to the CPU packet receiving module again to determine whether the messages need secondary encryption and decryption processing by checking the IPSEC table module again.
[0208] The CPU packet sending module is used to forward the encrypted and decrypted messages, including a message sending processing module, a priority mapping module, a message queuing module, a TX scheduling module and a CPU packet sending module.
[0209] The CPU packet receiving module further includes an RX scheduling module, a message parsing module, an ETH packet receiving processing module, an IP packet receiving processing module, a forwarding table search module, and a message editing module.
[0210] The AH / ESP encryption / decryption preprocessing module includes an AH / ESP encryption preprocessing module and an AH / ESP decryption preprocessing module. The AH / ESP encryption preprocessing module includes one or more modules of a buffer appending application module, an encapsulation processing module, an IP header variable field processing module, an IP option header processing module, an ESN processing module, and an ICV splicing module.
[0211] The AH / ESP decryption pre-processing module includes one or more modules of an anti-retransmission protection module, an IP header variable field processing module, an IP option header processing module, an ESN processing module, and an ICV splicing module, wherein:
[0212] The buffer appending module is used to apply for a buffer through the CPU and append it to the buffer list when performing ESP encapsulation on long packets to prevent the tail of the packet from exceeding the original buffer during editing.
[0213] The encapsulation processing module is used to perform different encapsulation processing on messages of different encryption and decryption protocols in different encapsulation modes;
[0214] The IP header variable field processing module is used to clear some fields in the IP header of the ESP message;
[0215] The IP option header processing module is used to clear or replace some fields in the IP option header or extension header in the message.
[0216] The ESN processing module is used to add the ESN field to the ESN-enabled message and delete the ESN field after encryption and decryption are completed;
[0217] The ICV splicing module, used in ESP message encapsulation, removes the ICV data at the end of the previous buffer and adds this data to the next buffer to ensure continuous processing of the ICV data.
[0218] The AH / ESP encryption / decryption post-processing module includes an AH / ESP encryption post-processing module and an AH / ESP decryption post-processing module. The AH / ESP encryption post-processing module includes one or more modules of an IP header variable field recovery processing module, an IP option header recovery processing module, and an ESN recovery processing module.
[0219] The AH / ESP post-decryption processing module includes one or more modules of an anti-retransmission protection module, an IP header variable field recovery processing module, an IP option header recovery processing module, a decapsulation processing module, and an ESN recovery processing module, wherein:
[0220] The IP header variable field recovery processing module is used to recover the variable field according to the information saved during the message encryption preprocessing;
[0221] An IP option header recovery processing module is used to recover some of the cleared or replaced fields in the IP option header or extension header based on the information saved during message encryption preprocessing;
[0222] An ESN recovery processing module is used to delete the ESN field of the message that was added during encryption preprocessing;
[0223] The anti-retransmission protection module is used for anti-retransmission protection checking of messages.
[0224] The IPSEC encryption device also includes a message sending module for receiving the message pre-processed by the AH / ESP encryption and decryption pre-processing module and a security device reading module before the encrypted and decrypted message is sent to the AH / ESP encryption and decryption post-processing module.
[0225] The IPSEC encryption device also includes an ASIC packet receiving and processing module for receiving messages on the ASIC input direction and a Normal DMA RX module when sending messages to the CPU, a Normal DMA TX module and an ASIC packet sending processing module for receiving messages processed by the CPU on the ASIC output direction, and an SEC DMA TX module when the encryption and decryption engine receives encrypted and decrypted messages sent by the CPU, and an SEC DMA RX module that sends the encrypted and decrypted messages to the CPU.
[0226] The functions of the above modules have been described in conjunction with the steps of the chip-based IPSEC encryption and decryption method, and will not be repeated here.
[0227] The foregoing descriptions of specific exemplary embodiments of the present invention are for purposes of illustration and description. These descriptions are not intended to limit the invention to the precise forms disclosed, and it is apparent that many variations and modifications are possible in light of the foregoing teachings. The exemplary embodiments have been selected and described for the purpose of explaining the specific principles of the invention and their practical application, thereby enabling those skilled in the art to realize and utilize a variety of exemplary embodiments of the invention and various options and modifications. The scope of the invention is intended to be defined by the claims and their equivalents.
Claims
1. A chip-based IPSEC encryption and decryption method, characterized in that: include: The CPU receives the message and determines whether IPSEC encryption and decryption needs to be enabled before forwarding it; For messages that require IPSEC encryption and decryption, AH / ESP encryption and decryption pre-processing is performed on the messages that require encryption and decryption by looking up the IPSEC table. Send the message after AH / ESP encryption and decryption pre-processing to the encryption and decryption engine on the chip for encryption and decryption processing; The CPU reads the encrypted and decrypted message, performs AH / ESP encryption and decryption processing, and then sends the message back to the CPU to check the IPSEC table again; The second IPSEC table query information is used to determine whether the message needs to be encrypted and decrypted twice. The second encryption and decryption process is performed on the message that needs to be encrypted and decrypted twice, and the message that has been encrypted and decrypted is forwarded.
2. The chip-based IPSEC encryption and decryption method according to claim 1, characterized in that: The messages that need to be encrypted and decrypted include AH messages, ESP messages, and AH-ESP messages.
3. The chip-based IPSEC encryption and decryption method according to claim 1 or 2, characterized in that: The AH / ESP encryption and decryption preprocessing includes selecting one or more of the following AH / ESP encryption preprocessing for messages of different encryption and decryption protocols: Buffer additional application; Add packaging processing; IP header variable field processing; IP options header processing; ESN processing; ICV splicing.
4. The chip-based IPSEC encryption and decryption method according to claim 3, characterized in that: The buffer append application is used for encapsulating a long ESP message. The CPU applies for a buffer and appends it to the buffer list to prevent the tail of the message from exceeding the original buffer during message editing.
5. The chip-based IPSEC encryption and decryption method according to claim 3, characterized in that: The ICV splicing includes deleting the ICV data at the end of the previous buffer and adding this data to the next buffer when encapsulating the ESP message.
6. The chip-based IPSEC encryption and decryption method according to claim 1 or 2, characterized in that: The AH / ESP encryption / decryption preprocessing includes selecting one or more of the following AH / ESP decryption preprocessing for messages of different encryption / decryption protocols: Anti-retransmission protection; IP header variable field processing; IP options header processing; ESN processing; ICV splicing.
7. The chip-based IPSEC encryption and decryption method according to claim 1 or 2, characterized in that: The AH / ESP post-encryption and decryption processing includes selecting one or more of the following AH / ESP post-encryption processing for messages of different encryption and decryption protocol types: IP header variable field recovery processing; IP options header recovery processing; ESN recovery processing.
8. The chip-based IPSEC encryption and decryption method according to claim 1 or 2, characterized in that: The AH / ESP post-encryption and decryption processing includes selecting one or more of the following AH / ESP post-encryption processing for messages of different encryption and decryption protocol types: Anti-retransmission protection; IP header variable field recovery processing; IP options header recovery processing; Decapsulation processing; ESN recovery processing.
9. The chip-based IPSEC encryption and decryption method according to claim 1 or 2, characterized in that: The encryption and decryption processing in the encryption and decryption engine includes selecting authentication, encryption, decryption, verification, encryption first and then authentication, authentication first and then encryption, decryption first and then verification, verification first and then decryption, or bypassing the encryption and decryption processing for messages of different encryption and decryption protocol types.
10. The chip-based IPSEC encryption and decryption method according to claim 2, characterized in that: For AH and ESP packets, after encryption and decryption, they are forwarded based on the IPSEC table lookup information. For AH-ESP messages, after completing ESP encryption, a second AH encryption process is performed based on the lookup information in the IPSEC table, or after completing AH decryption, a second ESP decryption process is performed based on the lookup information in the IPSEC table, and then the message is forwarded based on the lookup information in the IPSEC table.
11. The chip-based IPSEC encryption and decryption method according to claim 1, characterized in that: When editing a message before forwarding, determine whether the message length requires fragmentation. For messages that require fragmentation, set the order of fragmentation and IPSEC enabling to perform fragmentation first and then encryption and decryption or encryption and decryption first and then fragmentation.
12. A chip-based IPSEC encryption and decryption device, characterized in that: include: The CPU packet receiving module is used to receive messages sent from the chip and determine whether IPSEC encryption and decryption needs to be enabled before forwarding; The IPSEC table lookup module is used to obtain the table lookup information for message encryption and decryption processing by looking up the IPSEC table for messages that need to be encrypted and decrypted, and send the messages that need to be encrypted and decrypted to the AH / ESP encryption and decryption preprocessing module, and forward the messages that have completed the encryption and decryption processing; An AH / ESP encryption / decryption preprocessing module is used to perform different AH / ESP encryption / decryption preprocessing on messages of different encryption / decryption protocols according to the table lookup information; The encryption and decryption engine is used to encrypt and decrypt the messages after AH / ESP encryption and decryption preprocessing; The AH / ESP encryption and decryption post-processing module is used to perform different AH / ESP encryption and decryption post-processing on messages of different encryption and decryption protocols, and send the messages to the CPU packet receiving module again to determine whether the messages need secondary encryption and decryption processing by checking the IPSEC table module again.
13. The chip-based IPSEC encryption and decryption device according to claim 12, characterized in that: The AH / ESP encryption and decryption preprocessing module includes an AH / ESP encryption preprocessing module, which includes one or more modules selected from the group consisting of a buffer appending application module, an encapsulation processing module, an IP header variable field processing module, an IP option header processing module, an ESN processing module, and an ICV splicing module; wherein The buffer appending module is used to apply for a buffer through the CPU and append it to the buffer list when performing ESP encapsulation on long packets to prevent the tail of the packet from exceeding the original buffer during editing. The encapsulation processing module is used to perform different encapsulation processing on messages of different encryption and decryption protocols in different encapsulation modes; The IP header variable field processing module is used to clear some fields in the IP header of the ESP message; The IP option header processing module is used to clear or replace some fields in the IP option header or extension header in the message; An ESN processing module is used to add an ESN field to ESN-enabled messages and delete the ESN field after encryption is completed; The ICV splicing module, used in ESP message encapsulation, removes the ICV data at the end of the previous buffer and adds this data to the next buffer to ensure continuous processing of the ICV data.
14. The chip-based IPSEC encryption and decryption device according to claim 12, characterized in that: The AH / ESP encryption / decryption preprocessing module includes an AH / ESP decryption preprocessing module, which includes one or more modules in the group consisting of an anti-retransmission protection module, an IP header variable field processing module, an IP option header processing module, an ESN processing module, and an ICV splicing module. Anti-retransmission protection module, used for anti-retransmission protection check of messages; The IP header variable field processing module is used to clear some fields in the IP header of the ESP message; The IP option header processing module is used to clear or replace some fields in the IP option header or extension header in the message; An ESN processing module is used to add an ESN field to ESN-enabled messages and delete the ESN field after decryption is completed; The ICV splicing module, used in ESP message encapsulation, removes the ICV data at the end of the previous buffer and adds this data to the next buffer to ensure continuous processing of the ICV data.
15. The chip-based IPSEC encryption and decryption device according to claim 12, characterized in that: The AH / ESP encryption and decryption post-processing module includes an AH / ESP encryption post-processing module, and the AH / ESP encryption post-processing module includes one or more modules of an IP header variable field recovery processing module, an IP option header recovery processing module, and an ESN recovery processing module, wherein The IP header variable field recovery processing module is used to recover the variable field according to the information saved during the message encryption preprocessing; An IP option header recovery processing module is used to recover some of the cleared or replaced fields in the IP option header or extension header based on the information saved during message encryption preprocessing; The ESN recovery processing module is used to delete the ESN field from the message that has been added during encryption preprocessing.
16. The chip-based IPSEC encryption and decryption device according to claim 12, characterized in that: The AH / ESP encryption and decryption post-processing module includes an AH / ESP decryption post-processing module, which includes one or more modules of an anti-retransmission protection module, an IP header variable field recovery processing module, an IP option header recovery processing module, a decapsulation processing module, and an ESN recovery processing module, wherein Anti-retransmission protection module, used for anti-retransmission protection check of messages; The IP header variable field recovery processing module is used to recover the variable field according to the information saved during the message decryption preprocessing; An IP option header recovery processing module is used to restore some of the cleared or replaced fields in the IP option header or extension header based on the information saved during the message decryption preprocessing; a decapsulation module is used to perform different decapsulation processing on messages in different encapsulation modes; The ESN recovery processing module is used to delete the ESN field from the message that has been added during decryption preprocessing.
Citation Information
Patent Citations
System and method of fast message decryption
CN103200187A
IPsec protocol message encryption and decryption method based on chip scheme
CN115333859A