Data forwarding method and device, network equipment and SRv6 data forwarding system

Abstract

The embodiment of the invention provides a data forwarding method and device, network equipment and an SRv6 data forwarding system, and relates to the technical field of IPv6 forwarding. The method comprises the following steps: a network device receives a shared key generated and issued by a controller based on network topology information of the SRv6 data forwarding system, encrypts a preset header field of an original message based on the shared key when the shared key is used as a source node of data forwarding, and forwards the encrypted message; when serving as an intermediate node for data forwarding, verifying and re-encrypting a preset header field of the received message based on the shared key, and forwarding; and when the received message is used as a destination node for data forwarding, the preset header field of the received message is verified and decrypted based on the shared key to obtain the original message, so that an attacker is prevented from obtaining path information through a plaintext, and network topology exposure is avoided.

Description

Technical Field

[0001] This invention relates to the field of IPv6 forwarding technology, and more specifically, to a data forwarding method, apparatus, network device, and SRv6 data forwarding system. Background Technology

[0003] SRv6 (Segment Routing IPv6) defines packet forwarding paths through the segment list field in the IPv6 extension header. However, it carries the risk of segment list tampering, meaning an attacker could maliciously modify the segment list field in the extension header, leading to path hijacking or traffic sniffing. During packet transmission, the segment list field is transmitted in plaintext, exposing the network topology, which attackers can exploit to launch targeted attacks.

[0004] The aforementioned problems are particularly serious in scenarios with high security requirements such as finance, government affairs, and 5G core networks. How to make SRv6 data packets more secure and resistant to attacks is an urgent problem to be solved. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a data forwarding method, apparatus, network device and SRv6 data forwarding system.

[0006] To achieve the above objectives, the technical solutions adopted in the embodiments of the present invention are as follows:

[0007] In a first aspect, the present invention provides a data forwarding method applied to a network device in an SRv6 data forwarding system, wherein the SRv6 data forwarding system further includes a controller communicatively connected to the network device, and the method includes:

[0008] Receive a shared key issued by the controller, the shared key being generated by the controller based on the network topology information of the SRv6 data forwarding system;

[0009] When acting as a source node for data forwarding, the node encrypts the preset header field of the original message based on the shared key and then forwards it.

[0010] When acting as an intermediate node for data forwarding, the received message's preset header field is verified and re-encrypted based on the shared key before being forwarded.

[0011] When acting as the destination node for data forwarding, the received message's preset header field is verified and decrypted based on the shared key to obtain the original message.

[0012] Optionally, the step of encrypting the preset header field of the original message based on the shared key includes:

[0013] Generate a bit string based on the shared key;

[0014] The encrypted field is obtained by performing a byte-by-byte XOR operation on the preset header field of the original message using the bit string;

[0015] A baseline message fingerprint is generated using the shared key and the encryption field, and the baseline message fingerprint is written into the header of the original message to obtain an encrypted message.

[0016] Optionally, the step of verifying and re-encrypting the preset header field of the received message based on the shared key includes:

[0017] The integrity of the received message is verified using the shared key, the preset header field of the received message, and the base message fingerprint obtained from the header of the received message.

[0018] If the received message passes the integrity verification, the preset header field of the received message is re-encrypted using the shared key.

[0019] Optionally, the preset header fields include a remaining segment count field, a sequence number field, and a segment list field, and the step of re-encrypting the preset header fields of the received message using the shared key includes:

[0020] The remaining segment count field, sequence number field, and segment list field of the received message are decrypted using the shared key to obtain the decrypted remaining segment count field, sequence number field, and segment list field.

[0021] The decrypted sequence number field is checked based on the sequence number information recorded when the last message was received to determine whether there is duplication or out-of-order data forwarding.

[0022] If it is confirmed that there is no duplication or out-of-order data forwarding process, subtract 1 from the remaining segment count field after decryption to obtain the updated remaining segment count field.

[0023] The updated remaining segment count field, the decrypted sequence number field, and the decrypted segment list field are encrypted using the shared key to obtain the encrypted remaining segment count field, sequence number field, and segment list field.

[0024] A new message fingerprint is generated using the shared key, the encrypted remaining segment count field, the sequence number field, and the segment list field. The new message fingerprint is then written into the header of the received message to obtain a new encrypted message.

[0025] Optionally, the preset header fields include a remaining segment count field, a sequence number field, and a segment list field. The step of verifying and decrypting the preset header fields of the received message based on the shared key to obtain the original message includes:

[0026] The integrity of the received message is verified using the shared key, the preset header field of the received message, and the base message fingerprint obtained from the header of the received message.

[0027] If the received message passes the integrity verification, the remaining segment count field, sequence number field, and segment list field of the received message are decrypted using the shared key to obtain the decrypted remaining segment count field, sequence number field, and segment list field.

[0028] The decrypted sequence number field is checked based on the sequence number information recorded when the last message was received to determine whether there is duplication or out-of-order data forwarding.

[0029] If it is determined that there is no duplication or out-of-order delivery during the data forwarding process, the header encapsulation of the received message is removed to obtain the original message.

[0030] Optionally, the step of performing integrity verification on the received message using the shared key, the preset header field of the received message, and the reference message fingerprint obtained from the header of the received message includes:

[0031] Based on the shared key and the preset header fields of the received message, a fingerprint of the message to be compared is generated;

[0032] If the fingerprint of the message to be compared is consistent with the fingerprint of the reference message, then it is determined that the received message has passed the integrity check.

[0033] If the fingerprint of the message to be compared is inconsistent with the fingerprint of the reference message, it is determined that the received message has failed the integrity check.

[0034] Optionally, after the step of performing integrity verification on the received message using the shared key, the preset header field of the received message, and the reference message fingerprint obtained from the header of the received message, the method further includes:

[0035] If a received message fails the integrity check, the received message is discarded, and the abnormal event is forwarded to the controller so that the controller generates an alarm message to notify the operation and maintenance personnel to perform network checks.

[0036] In a second aspect, the present invention provides a data forwarding apparatus for use in a network device within an SRv6 data forwarding system, wherein the SRv6 data forwarding system further includes a controller communicatively connected to the network device, and the apparatus comprises:

[0037] The acquisition module is used to receive a shared key issued by the controller, wherein the shared key is generated by the controller based on the network topology information of the SRv6 data forwarding system;

[0038] The processing module is configured to, when acting as a source node for data forwarding, encrypt the preset header fields of the original message based on the shared key and forward it; when acting as an intermediate node for data forwarding, verify and re-encrypt the preset header fields of the received message based on the shared key and forward it; and when acting as a destination node for data forwarding, verify and decrypt the preset header fields of the received message based on the shared key to obtain the original message.

[0039] Thirdly, the present invention provides a network device including a memory and a processor, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor can execute the machine-executable instructions to implement the data forwarding method described in the first aspect above.

[0040] Fourthly, the present invention provides an SRv6 data forwarding system, including a controller and a plurality of network devices as described in the third aspect above. The controller is communicatively connected to each of the network devices. The controller is used to collect network topology information of the SRv6 data forwarding system, and generate a pre-shared key based on the network topology information and distribute it to each of the network devices.

[0041] The data forwarding method, apparatus, network device, and SRv6 data forwarding system provided in this invention utilize a shared key generated and distributed by the network device's receiver controller based on the network topology information of the SRv6 data forwarding system. When acting as a source node for data forwarding, the system encrypts a preset header field of the original packet based on the shared key and forwards it. When acting as an intermediate node for data forwarding, the system verifies and re-encrypts the preset header field of the received packet based on the shared key and forwards it. When acting as a destination node for data forwarding, the system verifies and decrypts the preset header field of the received packet based on the shared key to obtain the original packet. Because this invention encrypts the preset header fields of the packet at the source, intermediate, and destination nodes, it prevents attackers from obtaining path information through plaintext and avoids exposing the network topology.

[0042] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0043] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This diagram illustrates the structure of a network device according to an embodiment of the present invention.

[0045] Figure 2 This diagram illustrates an example of a networking environment provided by an embodiment of the present invention.

[0046] Figure 3 A flowchart illustrating a data forwarding method provided by an embodiment of the present invention is shown;

[0047] Figure 4 This diagram illustrates a flowchart of a source node processing message according to an embodiment of the present invention.

[0048] Figure 5 This diagram illustrates a flowchart of an intermediate node processing message according to an embodiment of the present invention.

[0049] Figure 6 This diagram illustrates a flowchart of a destination node processing a message according to an embodiment of the present invention.

[0050] Figure 7 A functional block diagram of a data forwarding device provided in an embodiment of the present invention is shown.

[0051] Icons: 100 - Network device; 110 - Memory; 120 - Processor; 130 - Communication module; 200 - Data forwarding device; 201 - Acquisition module; 202 - Processing module. Detailed Implementation

[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0053] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

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

[0055] Please refer to Figure 1 This is a block diagram of network device 100. Network device 100 includes a memory 110, a processor 120, and a communication module 130. The memory 110, processor 120, and communication module 130 are electrically connected to each other directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0056] The memory 110 is used to store programs or data. The memory 110 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.

[0057] The processor 120 is used to read / write data or programs stored in the memory 110 and to perform corresponding functions.

[0058] The communication module 130 is used to establish a communication connection between the network device 100 and other communication terminals through the network, and to send and receive data through the network.

[0059] It should be understood that, Figure 1 The structure shown is only a schematic diagram of network device 100. The network device may also include components that are larger than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown. Figure 1 The components shown can be implemented using hardware, software, or a combination thereof.

[0060] Furthermore, the SRv6 data forwarding system provided in this embodiment of the invention includes a controller and multiple network devices, such as... Figure 2 As shown, the controller can be an SDN (Software Defined Network) controller, and the multiple network devices 100 can be operator edge devices (denoted as PE devices) and operator core devices (denoted as P devices), and the underground networks of the controller, PE devices and P devices are interconnected.

[0061] To overcome the shortcomings of the prior art, this invention provides a data forwarding method for network devices, which will be described in detail below.

[0062] Please refer to Figure 3 The data forwarding method includes steps S101 to S105.

[0063] S101, Receive the shared key issued by the controller.

[0064] The shared key is generated by the controller based on the network topology information of the SRv6 data forwarding system.

[0065] Before forwarding data, network devices (such as PE devices and P devices) receive a shared key from the controller.

[0066] The controller collects network topology information in real time or periodically through mechanisms such as SNMP, BGP-LS, PCEP, or Ethernet discovery protocols. This information includes, but is not limited to: the roles of network devices (PE / P devices), link relationships between devices, performance metrics such as link bandwidth, latency, and packet loss rate, SRv6 path planning information in the network (such as tunnel paths), and the management status and security level of network devices. This information constitutes a complete topology view of the SRv6 data forwarding system, providing the basic data for shared key generation.

[0067] The controller uses the aforementioned network topology information and encryption algorithms (such as AES, HMAC, etc.) to generate a shared key. The generation method is as follows: For each SRv6 path, the controller generates a shared key related to the path topology, for example, using the identifiers of nodes in the path and the current timestamp to generate a unique key according to a preset hash algorithm; the controller periodically (e.g., hourly, daily) or triggers key updates based on security events to prevent security risks caused by long-term use of the same key; the controller assigns different key permissions based on the network device's role (PE device or P device) and its location in the network.

[0068] The controller distributes the shared key to the corresponding network device through a secure channel (such as a communication mechanism built with protocols like NETCONF over TLS or BGPsec) to ensure that the shared key is not stolen or tampered with during transmission.

[0069] S102, when acting as the source node for data forwarding, encrypts the preset header field of the original message based on the shared key and forwards it.

[0070] In this embodiment of the invention, the source node (usually a PE device) is the starting point of the SRv6 path in the SRv6 forwarding model. It is responsible for encapsulating the original packet with an SRv6 header (including an SRH (Segment Routing Header)) and forwarding it according to the path information in the Segment List.

[0071] Before forwarding SRv6 messages, the key header fields in the SRv6 messages are encrypted based on the shared key issued by the controller to prevent attackers from tampering with the SRH field, path hijacking, topology probing, and replay attacks.

[0072] The SRH format used in this embodiment of the invention is shown in the table below. Compared to the existing SRH format, the Flag field is modified to 2 bytes, which can be used to carry the encryption algorithm identifier. An Integrity Tag field is added, the content of which is used to perform integrity verification on the received SRv6 message to prevent the message from being tampered with during transmission. A Sequence Number field is added, which increments after each data packet is sent to prevent the message from being replayed. The original SegmentList field length is modified to a variable length, and this field stores the SID list data after being processed by the encryption algorithm.

[0073]

[0074]

[0075] In possible implementations, the process of "encrypting the preset header fields of the original message based on the shared key" may include, for example: Figure 4 The steps S201 to S203 are shown.

[0076] S201 generates a bit string based on the shared key.

[0077] The bit string refers to a pseudo-random bit sequence generated by the controller based on a shared key issued periodically and in combination with an encryption algorithm (such as AES, ChaCha20, CTR mode, etc.), and its length matches the data length of the field to be encrypted.

[0078] S202, perform a byte-by-byte XOR operation on the preset header field of the original message using a bit string to obtain the encrypted field.

[0079] The preset header fields include the number of remaining segments (Segments Left), the sequence number, and the segment list.

[0080] The length of the bit string matches the lengths of the fields to be encrypted: Segments Left, Sequence Number, and SegmentList.

[0081] By sequentially XORing each byte of the plaintext data in the three fields Segments Left, Sequence Number, and Segment List with the corresponding byte in the bit string, encrypted ciphertext bytes are generated. The encrypted ciphertext replaces the original field content, and the plaintext field is overwritten, resulting in the encrypted field.

[0082] This invention encrypts the Segment List, preventing attackers from directly obtaining forwarding path information even if they intercept packets, thus avoiding exposure of the topology and preventing targeted attacks. Furthermore, the controller periodically updates the key, resulting in different encryption results each time. Even if the path remains the same, the encrypted value of the Segment List will be different, preventing attackers from predicting paths or identifying traffic patterns by observing packets. Additionally, encryption is achieved using an XOR operation, resulting in low computational complexity, suitable for high-speed forwarding scenarios, and without significantly impacting forwarding performance.

[0083] S203, use the shared key and encryption field to generate a base message fingerprint, and write the base message fingerprint into the header of the original message to obtain an encrypted message.

[0084] A baseline message fingerprint is an integrity verification tag generated by combining encrypted fields with a shared key and performing HMAC (Hash-based Message Authentication Code) operations. It is a fixed-length digest value (e.g., 4 bytes) used to verify whether a message has been tampered with during transmission.

[0085] The baseline message fingerprint is written into the newly added Integrity Tag field in the SRH header. The Integrity Tag is located in the SRH header and is transmitted along with the encryption field.

[0086] After completing the above operations, the source node encapsulates the message into an encrypted SRv6 message and forwards it to the next node on the forwarding path.

[0087] The following section will continue to describe steps S103 to S104 of this data forwarding method.

[0088] S103, when acting as an intermediate node for data forwarding, verifies and re-encrypts the preset header fields of the received message based on the shared key, and then forwards it.

[0089] In a possible implementation, the process of "verifying and re-encrypting the preset header fields of the received message based on the shared key" may include, for example: Figure 5 The steps S301 to S302 are shown.

[0090] S301 uses the shared key, the preset header fields of the received message, and the base message fingerprint obtained from the header of the received message to perform integrity verification on the received message.

[0091] The implementation process of step S301 can be as follows:

[0092] S301-1, Generate the fingerprint of the message to be compared based on the shared key and the preset header fields of the received message.

[0093] S301-2, If the fingerprint of the message to be compared is consistent with the fingerprint of the reference message, then it is determined that the received message has passed the integrity check.

[0094] S301-3 If the fingerprint of the message to be compared is inconsistent with the fingerprint of the reference message, it is determined that the received message has failed the integrity check.

[0095] In this embodiment of the invention, an intermediate node (such as a P device) receives an SRv6 message from the previous hop node (PE device or P device), extracts the encrypted fields Segments Left (ciphertext), Sequence Number (ciphertext), and Segment List (ciphertext) from the message, and extracts the Integrity Tag field to obtain the base message fingerprint.

[0096] The HMAC algorithm is used to perform a hash operation on the extracted encrypted field and the shared key. To adapt to the SRH header length limit, the HMAC result can be truncated to a fixed length (such as 4 bytes) as the final fingerprint to be compared.

[0097] The calculated fingerprint to be compared is compared with the baseline message fingerprint obtained from the Integrity Tag field. If the two are consistent, it means that the message has not been tampered with since it was sent from the source node, and the integrity verification is passed.

[0098] If the two are inconsistent, it indicates that the message has been tampered with during transmission, and the integrity verification has failed. In this case, the intermediate node discards the received message and forwards the abnormal event to the controller, so that the controller generates an alarm message and notifies the maintenance personnel to perform a network check.

[0099] S302, if the received message passes the integrity check, the preset header field of the received message is re-encrypted using the shared key.

[0100] The implementation process of step S302 can be as follows:

[0101] S302-1, use the shared key to decrypt the remaining segment count field, sequence number field, and segment list field of the received message to obtain the decrypted remaining segment count field, sequence number field, and segment list field.

[0102] S302-2, based on the sequence number information recorded when the last message was received, checks the decrypted sequence number field to determine whether there is duplication or out-of-order data forwarding.

[0103] S302-3, if it is determined that there is no duplication or out-of-order data forwarding, subtract 1 from the remaining segment count field after decryption to obtain the updated remaining segment count field.

[0104] S302-4, use the shared key to encrypt the updated remaining segment quantity field, the decrypted sequence number field, and the decrypted segment list field to obtain the encrypted remaining segment quantity field, sequence number field, and segment list field.

[0105] S302-5, using the shared key and the encrypted remaining segment quantity field, sequence number field and segment list field, a new message fingerprint is generated, and the new message fingerprint is written into the header of the received message to obtain a new encrypted message.

[0106] In this embodiment of the invention, the intermediate node uses the shared key issued by the controller to generate a bit string, and performs a byte-by-byte XOR operation on the contents of the encrypted Segments Left, encrypted Sequence Number, and encrypted SegmentList fields in the SRH header to obtain the plaintext field.

[0107] Extract the decrypted Sequence Number, extract the packet's triple information (including source IP address, destination IP address, and protocol type), and look up the previously received Sequence Number recorded in the local cache based on the triple.

[0108] If the current Sequence Number is not greater than the cached Sequence Number, it means that the packet was duplicated or out of order during forwarding. In this case, the received packet should be discarded, and the packet forwarding anomaly event should be reported to the controller so that the controller generates an alarm message and notifies the operations and maintenance personnel to perform network checks.

[0109] If the current Sequence Number field content is greater than the cached Sequence Number value, it means that the packet did not experience duplication or out-of-order delivery during forwarding. In this case, the cached Sequence Number value needs to be updated to the current Sequence Number field content, the decrypted Segments Left field value needs to be decremented by 1, and the SegmentList needs to be updated, moving the pointer to the next SID. After updating the key fields, the contents of these key fields are re-encrypted. This involves generating a new bit string using the shared key and performing a byte-by-byte XOR operation on the updated Segments Left, decrypted SequenceNumber, and updated Segment List fields.

[0110] Using the HMAC algorithm, the encrypted field is combined with the shared key to generate a fixed-length hash value (e.g., 4 bytes), which is written into the Integrity Tag field of the SRH header. The message is then encapsulated to obtain a new SRv6 message, which is then forwarded to the next node on the forwarding path.

[0111] The following section will continue to describe step S104 of this data forwarding method.

[0112] S104, when acting as the destination node for data forwarding, verifies and decrypts the preset header fields of the received message based on the shared key to obtain the original message.

[0113] In a possible implementation, the process of implementing step S104 may include, for example: Figure 6 S401 to S404 are shown.

[0114] S401 uses the shared key, the preset header fields of the received message, and the base message fingerprint obtained from the header of the received message to perform integrity verification on the received message.

[0115] The implementation process of step S401 can be as follows:

[0116] S401-1, Generate the fingerprint of the message to be compared based on the shared key and the preset header fields of the received message.

[0117] S401-2, If the fingerprint of the message to be compared is consistent with the fingerprint of the reference message, then it is determined that the received message has passed the integrity check.

[0118] S401-3 If the fingerprint of the message to be compared is inconsistent with the fingerprint of the reference message, it is determined that the received message has failed the integrity check.

[0119] In this embodiment of the invention, when the destination node (such as a PE device) is the end point of the path or its next hop is a regular IP forwarding node, for the SRv6 message received from the previous hop node (PE device or P device), it is necessary to extract the encrypted fields Segments Left (ciphertext), Sequence Number (ciphertext), and Segment List (ciphertext) from the message, as well as extract the Integrity Tag field to obtain the base message fingerprint.

[0120] A fingerprint to be compared is generated using the shared key and the extracted encrypted text field, and then compared with the baseline message fingerprint obtained from the Integrity Tag field to verify whether the message has been tampered with. If they match, it means the message has not been tampered with since it was sent from the source node, and the integrity check passes. If they do not match, it means the message has been tampered with during transmission, and the integrity check fails. In this case, the destination node discards the received message and forwards the abnormal event to the controller, causing the controller to generate an alarm message and notify the operations and maintenance personnel to perform a network check.

[0121] S402, if the received message passes the integrity check, use the shared key to decrypt the remaining segment count field, sequence number field, and segment list field of the received message to obtain the decrypted remaining segment count field, sequence number field, and segment list field.

[0122] The destination node uses the shared key issued by the controller to generate a bit string, and performs a byte-by-byte XOR operation on the encrypted Segments Left, encrypted Sequence Number, and encrypted Segment List fields in the SRH header to obtain the plaintext field.

[0123] S403 checks the decrypted sequence number field based on the sequence number information recorded when the last message was received to determine whether there is duplication or out-of-order data forwarding.

[0124] S404: If it is determined that there is no duplication or out-of-order delivery during the data forwarding process, the header encapsulation of the received message is removed to obtain the original message.

[0125] The destination node extracts the decrypted Sequence Number and the packet's triple information (including source IP address, destination IP address, and protocol type), and then looks up the previously received Sequence Number recorded in its local cache based on the triple.

[0126] If the current Sequence Number is not greater than the cached Sequence Number, it means that the packet was duplicated or out of order during forwarding. In this case, the received packet should be discarded, and the packet forwarding anomaly event should be reported to the controller so that the controller generates an alarm message and notifies the operations and maintenance personnel to perform network checks.

[0127] If the current Sequence Number is greater than the cached Sequence Number, it means that the packet was not duplicated or out of order during forwarding. At this time, the destination node removes the SRv6 encapsulation of the packet, that is, removes the SRH header, restores the original IPv6 packet, and updates the Next Header field of the IPv6 basic header to the original payload type (such as TCP, UDP, ICMPv6).

[0128] When the next hop of the destination node is a regular IP forwarding node, the destination node performs IP forwarding based on the destination address of the original packet.

[0129] If the destination node is the end point of the forwarding path, the original packet is forwarded to the local access network or service gateway.

[0130] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0131] (1) The controller generates a shared key related to the path topology based on the network topology information of the SRv6 system (such as device role, link status, and path planning), thereby binding the key to the network topology and enhancing the security of the forwarding path. The controller supports updating the key on demand (such as timed or triggered), and assigns different key permissions according to the device role, and distributes the shared key through a secure channel, thereby avoiding the security risks caused by using the same key for a long time and realizing fine-grained access control and permission isolation.

[0132] (2) A bit string is generated using a shared key at the source node, intermediate node and destination node. The key fields in the SRv6 header are XORed byte by byte, so that attackers cannot directly obtain the forwarding path information, preventing the network topology from being exposed. Even if the path remains unchanged, the controller's periodic key update will result in different encryption results each time, effectively preventing traffic analysis and path prediction.

[0133] (3) By adding an Integrity Tag field to the SRv6 header to store the base message fingerprint generated based on the shared key and encryption field, integrity verification is performed at the source node, intermediate node and destination node, thereby ensuring that the message is not tampered with during transmission and effectively preventing man-in-the-middle attacks and path hijacking.

[0134] (4) A Sequence Number field is added to the SRv6 header, and the decrypted sequence number is checked at intermediate and destination nodes based on the sequence number information of the last received record, thereby preventing attackers from launching replay attacks by intercepting and replaying old messages, and improving the reliability and security of data transmission.

[0135] (5) When integrity verification fails or the sequence number is abnormal, the message is discarded and the abnormal event is forwarded to the controller, so that the controller can generate alarm information based on the reported information and notify the operation and maintenance personnel to conduct network inspection, thereby realizing real-time perception and response to potential attack behaviors and improving the overall network security situation.

[0136] To perform the corresponding steps in the above embodiments and various possible methods, an implementation of the data forwarding device 200 is given below. Further, please refer to... Figure 7 , Figure 7 This is a functional block diagram of a data forwarding device 200 provided in an embodiment of the present invention. It should be noted that the basic principle and technical effects of the data forwarding device 200 provided in this embodiment are the same as those in the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments. The data forwarding device 200 includes:

[0137] The acquisition module 201 is used to receive the shared key issued by the controller. The shared key is generated by the controller based on the network topology information of the SRv6 data forwarding system.

[0138] The processing module 202 is used to encrypt the preset header fields of the original message based on the shared key and forward it when acting as the source node for data forwarding; to verify and re-encrypt the preset header fields of the received message based on the shared key and forward it when acting as the intermediate node for data forwarding; and to verify and decrypt the preset header fields of the received message based on the shared key to obtain the original message when acting as the destination node for data forwarding.

[0139] Optionally, the above modules can be stored in the form of software or firmware. Figure 1 The memory shown is either stored in or embedded in the operating system (OS) of the network device, and can be used by... Figure 1 The processor executes the commands. Meanwhile, the data and program code required to execute these modules can be stored in memory.

[0140] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0141] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0142] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a network device, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0143] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A data forwarding method, characterized in that, A network device applied in an SRv6 data forwarding system, the SRv6 data forwarding system further comprising a controller communicatively connected to the network device, the method comprising: Receive a shared key issued by the controller, the shared key being generated by the controller based on the network topology information of the SRv6 data forwarding system; When acting as a source node for data forwarding, the node encrypts the preset header field of the original message based on the shared key and then forwards it. When acting as an intermediate node for data forwarding, the received message's preset header field is verified and re-encrypted based on the shared key before being forwarded. When acting as the destination node for data forwarding, the received message's preset header field is verified and decrypted based on the shared key to obtain the original message.

2. The data forwarding method according to claim 1, characterized in that, The step of encrypting the preset header field of the original message based on the shared key includes: Generate a bit string based on the shared key; The encrypted field is obtained by performing a byte-by-byte XOR operation on the preset header field of the original message using the bit string; A baseline message fingerprint is generated using the shared key and the encryption field, and the baseline message fingerprint is written into the header of the original message to obtain an encrypted message.

3. The data forwarding method according to claim 1, characterized in that, The step of verifying and re-encrypting the preset header field of the received message based on the shared key includes: The integrity of the received message is verified using the shared key, the preset header field of the received message, and the base message fingerprint obtained from the header of the received message. If the received message passes the integrity verification, the preset header field of the received message is re-encrypted using the shared key.

4. The data forwarding method as described in claim 3, characterized in that, The preset header fields include a remaining segment count field, a sequence number field, and a segment list field. The step of re-encrypting the preset header fields of the received message using the shared key includes: The remaining segment count field, sequence number field, and segment list field of the received message are decrypted using the shared key to obtain the decrypted remaining segment count field, sequence number field, and segment list field. The decrypted sequence number field is checked based on the sequence number information recorded when the last message was received to determine whether there is duplication or out-of-order data forwarding. If it is confirmed that there is no duplication or out-of-order data forwarding process, subtract 1 from the remaining segment count field after decryption to obtain the updated remaining segment count field. The updated remaining segment count field, the decrypted sequence number field, and the decrypted segment list field are encrypted using the shared key to obtain the encrypted remaining segment count field, sequence number field, and segment list field. A new message fingerprint is generated using the shared key, the encrypted remaining segment count field, the sequence number field, and the segment list field. The new message fingerprint is then written into the header of the received message to obtain a new encrypted message.

5. The data forwarding method as described in claim 1, characterized in that, The preset header fields include a remaining segment count field, a sequence number field, and a segment list field. The step of verifying and decrypting the preset header fields of the received message based on the shared key to obtain the original message includes: The integrity of the received message is verified using the shared key, the preset header field of the received message, and the base message fingerprint obtained from the header of the received message. If the received message passes the integrity verification, the remaining segment count field, sequence number field, and segment list field of the received message are decrypted using the shared key to obtain the decrypted remaining segment count field, sequence number field, and segment list field. The decrypted sequence number field is checked based on the sequence number information recorded when the last message was received to determine whether there is duplication or out-of-order data forwarding. If it is determined that there is no duplication or out-of-order delivery during the data forwarding process, the header encapsulation of the received message is removed to obtain the original message.

6. The data forwarding method as described in claim 3 or 5, characterized in that, The step of performing integrity verification on the received message using the shared key, the preset header field of the received message, and the base message fingerprint obtained from the header of the received message includes: Based on the shared key and the preset header fields of the received message, a fingerprint of the message to be compared is generated; If the fingerprint of the message to be compared is consistent with the fingerprint of the reference message, then it is determined that the received message has passed the integrity check. If the fingerprint of the message to be compared is inconsistent with the fingerprint of the reference message, it is determined that the received message has failed the integrity check.

7. The data forwarding method as described in claim 3 or 5, characterized in that, After the step of performing integrity verification on the received message using the shared key, the preset header field of the received message, and the reference message fingerprint obtained from the header of the received message, the method further includes: If a received message fails the integrity check, the received message is discarded, and the abnormal event is forwarded to the controller so that the controller generates an alarm message to notify the operation and maintenance personnel to perform network checks.

8. A data forwarding device, characterized in that, A network device used in an SRv6 data forwarding system, the SRv6 data forwarding system further including a controller communicatively connected to the network device, the device comprising: The acquisition module is used to receive a shared key issued by the controller, wherein the shared key is generated by the controller based on the network topology information of the SRv6 data forwarding system; The processing module is configured to, when acting as a source node for data forwarding, encrypt the preset header fields of the original message based on the shared key and forward it; when acting as an intermediate node for data forwarding, verify and re-encrypt the preset header fields of the received message based on the shared key and forward it; and when acting as a destination node for data forwarding, verify and decrypt the preset header fields of the received message based on the shared key to obtain the original message.

9. A network device, characterized in that, The system includes a memory and a processor, the memory storing machine-executable instructions that can be executed by the processor to implement the data forwarding method according to any one of claims 1-7.

10. An SRv6 data forwarding system, characterized in that, The system includes a controller and multiple network devices as described in claim 9, wherein the controller is communicatively connected to each of the network devices, and the controller is used to collect network topology information of the SRv6 data forwarding system, and generate a pre-shared key based on the network topology information and distribute it to each of the network devices.

Images