A method of distributing encrypted information and related apparatus

Abstract

A method for distributing encrypted information, which can realize encrypted data transmission between two parties and effectively reduce the complexity of network deployment. The method comprises: carrying encryption extension information in a route advertisement packet to indicate a route prefix and encryption extension information related to the route prefix. When receiving the route advertisement packet, a network device generates a key based on the encryption extension information in the route advertisement packet and generates a route entry with an encryption attribute, which can indicate that the network device encrypts data with the key and then sends the encrypted data to a network indicated by the route prefix. In the method, the encrypted information is transmitted between multiple network devices based on the route advertisement packet, and the network device is guided to generate the route entry with the encryption attribute, so that the network device can realize encrypted transmission of data packets based on the route entry, without the need to establish a dedicated encryption tunnel between the network devices, thereby effectively reducing the complexity of network deployment.

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method and apparatus for distributing encrypted information. Background Technology

[0002] IPSec (IP Services for Traffic at the IP Layer) is a set of protocols used to provide high-quality, encryption-based security services. IPSec provides security services at the IP layer, protecting the IP layer and all protocols carried on top of it. Therefore, IPSec can protect any path between a pair of hosts, a pair of security gateways, or a security gateway and a host.

[0003] Currently, encrypting traffic using IPSec requires first establishing a dedicated encrypted tunnel between the two parties. Then, the two parties exchange the necessary information through the encrypted tunnel to generate keys for encrypting or decrypting data. Finally, when either party receives traffic that needs to be encrypted and sent to the other, it routes the traffic to the encrypted tunnel for encryption and forwarding to the other party.

[0004] However, since transmitting encrypted traffic between any two network devices based on IPSec requires establishing a dedicated encrypted tunnel between them, the network deployment is complex and difficult to promote and apply in real-world large-scale network environments. Summary of the Invention

[0005] This application provides a method for distributing encrypted information, which enables encrypted data transmission between the two parties without the need to establish a dedicated encrypted tunnel, effectively reducing the complexity of network deployment.

[0006] This application provides a method for distributing encrypted information, comprising: a first network device receiving a first routing advertisement message, the first routing advertisement message including a routing prefix and first encrypted extension information associated with the routing prefix, the first encrypted extension information including a first parameter for generating a key. Then, the first network device generates at least one key based on the first encrypted extension information, wherein the at least one key is used to encrypt data packets destined for the network indicated by the routing prefix from the first network device and / or decrypt data packets destined for the first network device from the network indicated by the routing prefix. The first network device generates routing table entries according to the first routing advertisement message, the routing table entries including the routing prefix, and the routing table entries indicating the outgoing interface on the first network device destined for the network indicated by the routing prefix and indicating that data packets are encrypted using at least one key before forwarding data packets whose destination address belongs to the network indicated by the routing prefix. That is, the first network device generates routing table entries with encryption attributes based on the first routing advertisement message.

[0007] In this scheme, encryption extension information is included in the routing advertisement message to indicate the routing prefix and related encryption extension information. When a network device receives the routing advertisement message, it can generate a key based on the encryption extension information in the message and create a routing table entry with encryption attributes. This entry instructs the network device to encrypt data packets using the key before sending them to the network indicated by the routing prefix. This method uses routing advertisement messages to transmit encryption information between multiple network devices and guides them to generate routing table entries with encryption attributes. This ensures that network devices can achieve encrypted data packet transmission based on the routing table entries, eliminating the need to establish dedicated encryption tunnels between network devices and effectively reducing network deployment complexity.

[0008] Optionally, the first encrypted extension information is carried in the first typelength value (TLV) field of the first route advertisement message, and the first TLV field includes a first parameter for generating the key.

[0009] Optionally, the first encrypted extension information also includes information for indicating a first encrypted network topology, the information of which indicates multiple network devices constituting the first encrypted network topology and indicates that encrypted connections are permitted between the multiple network devices.

[0010] Optionally, the first encrypted extension information is also carried in the second TLV field of the first routing advertisement message, the second TLV field being used to indicate information about the first encrypted network topology.

[0011] In this solution, by adding a TLV field to the route advertisement message, it is possible to carry encrypted extended information while minimizing changes to the existing routing protocol and reducing the difficulty of actual deployment.

[0012] Optionally, the first route advertisement message can be a Border Gateway Protocol (BGP) message or an Interior Gateway Protocol (IGP) message.

[0013] Optionally, the first route advertisement message is a BGP update message; the first TLV field and the second TLV field are carried in the extended path attribute field of the BGP update message.

[0014] Optionally, the first route advertisement message is an Open Shortest Path First (OSPF) message; the first TLV field and the second TLV field are carried in the Link State Advertisement (LSA) sub-TLV field of the OSPF message.

[0015] Optionally, when the first network device obtains the target packet, if the destination address of the target packet matches the routing prefix in the routing table entry, the first network device encrypts the target packet using at least one key based on the indication of the routing table entry.

[0016] Optionally, if there is an existing tunnel between the first network device and the second network device, the first network device sends the encrypted target message based on the existing tunnel, and the second network device is the boundary device in the network indicated by the routing prefix; if there is no existing tunnel between the first network device and the second network device, the first network device creates a new tunnel with the second network device and sends the encrypted target message based on the newly created tunnel.

[0017] Optionally, the first encrypted extension information may also include the Internet Protocol (IP) address of the second network device; the first network device creates an IP-in-IP tunnel with the second network device based on the IP address of the second network device and the IP address of the first network device.

[0018] Optionally, the first TLV field includes the identifiers of one or more network devices, which are devices in the encrypted network topology that need to establish an encrypted connection with the second network device, and the second network device is a boundary device in the network indicated by the routing prefix.

[0019] Optionally, the second TLV field is used to indicate the first encrypted network topology to which one or more network devices belong, and the identifier of one or more network devices within the first encrypted network topology. The one or more network devices are devices in the first encrypted network topology that need to establish an encrypted connection with the second network device, and the second network device is a boundary device in the network indicated by the routing prefix.

[0020] Optionally, the second TLV field includes multiple bits, one of which is used to refer to at least one network device within the first encrypted network topology, and the one or more network devices correspond to one or more bits with a preset bit state among the multiple bits.

[0021] Optionally, the first TLV field includes the router identifier of the second network device, which is a border device in the network indicated by the routing prefix; the first network device generates at least one key based on the router identifier of the second network device and the router identifier of the first network device; wherein, the router identifier of the second network device and the router identifier of the first network device are both unique identifiers.

[0022] In this scheme, the key is generated based on the router identifier of the network device, which can ensure the uniqueness of the key and improve the security of data transmission.

[0023] Optionally, the first network device generates a first security parameter index based on a first TLV field and local parameters. The first security parameter index is used to indicate the encrypted connection between the first network device and the second network device. The local parameters include a random number and / or the identifier of the first network device. The second network device is a border device in the network indicated by the routing prefix. If the first security parameter index is the same as other security parameter indices already generated in the first network device, the first network device updates the local parameters and generates a second security parameter index based on the first TLV field and the updated local parameters. The first network device sends the updated local parameters to the second network device.

[0024] Optionally, the first TLV field may also include quantum key parameters.

[0025] Optionally, the first network device generates second encrypted extension information, which includes second parameters for generating a key and information about a second encrypted network topology. The information about the second encrypted network topology is used to indicate the multiple network devices constituting the second encrypted network topology and to indicate that encrypted connections are allowed between the multiple network devices in the second encrypted network topology. The first network device replaces the first encrypted extension information in the first routing advertisement message with the second encrypted extension information to obtain a second routing advertisement message. The first network device sends the second routing advertisement message to neighboring devices.

[0026] In this solution, after receiving a routing advertisement message, the network device can establish an encrypted connection with other network devices by modifying the encryption extension information in the routing advertisement message, thereby enabling flexible management of the encrypted network topology.

[0027] A second aspect of this application provides a method for distributing encrypted information, comprising: a second network device acquiring encrypted information related to a service, the encrypted information being used to indicate the object of the service encryption application; the second network device generating a routing advertisement message based on the encrypted information, the routing advertisement message including a routing prefix and encrypted extension information related to the routing prefix, the encrypted extension information including parameters for generating a key; and the second network device sending the routing advertisement message to neighboring devices.

[0028] Optionally, the object of the business encryption application is used to indicate the address family or virtual private network (VPN) instance that needs to establish an encrypted connection; based on the network prefix that the routing prefix belongs to in the address family or VPN instance, the second network device generates a routing advertisement message, and the second network device is a border device in the network indicated by the routing prefix.

[0029] Optionally, the objects of the business encryption application include routing policies, which are used to indicate network devices that need to establish encrypted connections; based on the fact that the second network device belongs to the network device indicated in the routing policy, the second network device generates a routing advertisement message.

[0030] A third aspect of this application provides a network device, comprising: a receiving unit, configured to receive a first routing advertisement message, the first routing advertisement message including a routing prefix and first encryption extension information associated with the routing prefix, the first encryption extension information including a first parameter for generating a key; a generating unit, configured to generate at least one key based on the first encryption extension information, wherein the at least one key is used to encrypt data packets from the network device to a network indicated by the routing prefix and / or decrypt data packets from the network indicated by the routing prefix to the network device; the generating unit is further configured to generate routing table entries according to the first routing advertisement message, the routing table entries including a routing prefix, and the routing table entries are used to indicate an outgoing interface on the network device leading to the network indicated by the routing prefix and to indicate that data packets are encrypted with at least one key before forwarding data packets whose destination address belongs to the network indicated by the routing prefix.

[0031] Optionally, the first encrypted extension information is carried in the first TLV field of the first route advertisement message, and the first TLV field includes a first parameter for generating the key.

[0032] Optionally, the first encrypted extension information also includes information for indicating a first encrypted network topology, the information of which indicates multiple network devices constituting the first encrypted network topology and indicates that encrypted connections are permitted between the multiple network devices.

[0033] Optionally, the first encrypted extension information is also carried in the second TLV field of the first routing advertisement message, the second TLV field being used to indicate information about the first encrypted network topology.

[0034] Optionally, the first route advertisement message can be a BGP message or an IGP message.

[0035] Optionally, the first route advertisement message is a BGP update message; the first TLV field and the second TLV field are carried in the extended path attribute field of the BGP update message.

[0036] Optionally, the first route advertisement message is an Open Shortest Path First (OSPF) message; the first TLV field and the second TLV field are carried in the link-state advertisement sub-TLV field of the OSPF message.

[0037] Optionally, the generation unit is also configured to: when a target packet is obtained, if the destination address of the target packet matches the routing prefix in the routing table entry, encrypt the target packet using at least one key based on the indication of the routing table entry.

[0038] Optionally, the network device may also include a transmitting unit;

[0039] If there is an established tunnel between the network device and the second network device, the sending unit is used to send the encrypted target message based on the established tunnel, where the second network device is the boundary device in the network indicated by the routing prefix;

[0040] If there is no existing tunnel between the network device and the second network device, the generation unit is used to create a new tunnel between the network device and the second network device, and the sending unit is used to send the encrypted target message based on the newly created tunnel.

[0041] Optionally, the first encrypted extension information may also include the IP address of the second network device; the generation unit is used to create an IPinIP tunnel between the second network device and the first network device based on the IP address of the second network device and the IP address of the first network device.

[0042] Optionally, the first TLV field includes the identifiers of one or more network devices, which are devices in the encrypted network topology that need to establish an encrypted connection with the second network device, and the second network device is a boundary device in the network indicated by the routing prefix.

[0043] Optionally, the second TLV field is used to indicate the first encrypted network topology to which one or more network devices belong, and the identifier of one or more network devices within the first encrypted network topology. The one or more network devices are devices in the first encrypted network topology that need to establish an encrypted connection with the second network device, and the second network device is a boundary device in the network indicated by the routing prefix.

[0044] Optionally, the second TLV field includes multiple bits, one of which is used to refer to at least one network device within the first encrypted network topology, and the one or more network devices correspond to one or more bits with a preset bit state among the multiple bits.

[0045] Optionally, the first TLV field includes the router identifier of the second network device, which is a border device in the network indicated by the routing prefix; the generation unit is further configured to generate at least one key based on the router identifier of the second network device and the router identifier of the first network device; wherein the router identifier of the second network device and the router identifier of the first network device are both unique identifiers.

[0046] Optionally, the generation unit is further configured to: generate a first security parameter index based on a first TLV field and local parameters, the first security parameter index being used to indicate an encrypted connection between a network device and a second network device, the local parameters including a random number and / or the identifier of the first network device, the second network device being a border device in the network indicated by the routing prefix; if the first security parameter index is the same as other security parameter indices already generated in the network device, then update the local parameters and generate a second security parameter index based on the first TLV field and the updated local parameters; the sending unit is further configured to send the updated local parameters to the second network device.

[0047] Optionally, the first TLV field may also include quantum key parameters.

[0048] Optionally, the generating unit is further configured to generate second encrypted extension information, which includes second parameters for generating a key and information about a second encrypted network topology. The information about the second encrypted network topology is used to indicate the multiple network devices constituting the second encrypted network topology and to indicate that encrypted connections are allowed between the multiple network devices in the second encrypted network topology. The first network device replaces the first encrypted extension information in the first routing advertisement message with the second encrypted extension information to obtain a second routing advertisement message. The sending unit is further configured to send the second routing advertisement message to neighboring devices.

[0049] A fourth aspect of this application provides a network device, comprising: an acquisition unit for acquiring service-related encrypted information, the encrypted information being used to indicate the object of the service encryption application; a generation unit for generating a routing advertisement message based on the encrypted information, the routing advertisement message including a routing prefix and encrypted extension information related to the routing prefix, the encrypted extension information including parameters for generating a key; and a sending unit for sending the routing advertisement message to neighboring devices.

[0050] Optionally, the object of the business encryption application is used to indicate the address family or VPN instance that needs to establish an encrypted connection; the generation unit is also used to generate a route advertisement message based on the network prefix that the route prefix belongs to in the address family or VPN instance, wherein the network device is the border device in the network indicated by the route prefix.

[0051] Optionally, the objects of the business encryption application include routing policies, which are used to indicate network devices that need to establish encrypted connections; the generation unit is also used to generate routing announcement messages based on the fact that the network device belongs to the network device indicated in the routing policy.

[0052] A fifth aspect of this application provides a network device including a processor and a memory; wherein the memory is used to store program code, and the processor is used to call the program code in the memory to cause the network device to perform a method as described in any of the embodiments of the first or second aspect.

[0053] The sixth aspect of this application provides a network system, including a network device according to any embodiment of the third aspect and a network device according to any embodiment of the fourth aspect.

[0054] The seventh aspect of this application provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform a method as described in any of the embodiments of the first aspect.

[0055] The eighth aspect of this application provides a computer program product that, when run on a computer, causes the computer to perform a method as described in any of the embodiments of the first aspect.

[0056] A ninth aspect of this application provides a chip including one or more processors. Part or all of the processors are used to read and execute computer instructions stored in a memory to perform the methods in any possible implementation of any of the above aspects. Optionally, the chip also includes a memory. Optionally, the chip also includes a communication interface, with the processor connected to the communication interface. The communication interface is used to receive data and / or information to be processed, the processor obtains the data and / or information from the communication interface, processes the data and / or information, and outputs the processing results through the communication interface. Optionally, the communication interface is an input / output interface or a bus interface. The methods provided in this application are implemented by a single chip or by multiple chips working together.

[0057] The solutions provided in the second to ninth aspects above are used to implement or cooperate with the method provided in the first aspect above, and therefore can achieve the same or corresponding beneficial effects as the first aspect, which will not be elaborated here. Attached Figure Description

[0058] Figure 1 This application provides a schematic diagram of a network scenario for encrypted services within the same autonomous system.

[0059] Figure 2 This application provides a schematic diagram of a network scenario for cross-autonomous system encryption services.

[0060] Figure 3 A flowchart illustrating a method for distributing encrypted information provided in an embodiment of this application;

[0061] Figure 4 A schematic diagram illustrating the format of a BGP update message provided in an embodiment of this application;

[0062] Figure 5 A schematic diagram illustrating the format of an OSPF Internal Area Prefix Link State Advertisement (E-Inter-Area-Prefix-LSA) message provided for embodiments of this application;

[0063] Figure 6 A schematic diagram illustrating the format of the TLV field in an OSPF E-Inter-Area-Prefix-LSA message, provided for an embodiment of this application;

[0064] Figure 7 A schematic diagram illustrating the format of a first TLV field and a second TLV field provided for embodiments of this application;

[0065] Figure 8 A schematic diagram illustrating the format of a second TLV field provided in an embodiment of this application;

[0066] Figure 9Schematic diagrams of various encrypted network topologies provided in the embodiments of this application;

[0067] Figure 10 This is another flowchart illustrating a method for distributing encrypted information provided in an embodiment of this application;

[0068] Figure 11 This is a schematic diagram illustrating the distribution of encrypted information within the same autonomous system, as provided in an embodiment of this application.

[0069] Figure 12 This is a schematic diagram illustrating the distribution of encrypted information between different autonomous systems, provided as an embodiment of this application.

[0070] Figure 13 A schematic diagram illustrating a process for a sending-side device to publish a routing announcement message carrying encrypted extended information, as provided in an embodiment of this application;

[0071] Figure 14 A schematic diagram illustrating the process by which a receiving device receives and processes a routing announcement message carrying encrypted extended information, as provided in an embodiment of this application.

[0072] Figure 15 A schematic diagram illustrating a process for generating a security parameter index between network devices, provided as an embodiment of this application;

[0073] Figure 16 This application provides a schematic diagram of a renegotiation process when an SPI conflict occurs.

[0074] Figure 17 This is a schematic diagram of the structure of a network device 1700 provided in an embodiment of this application;

[0075] Figure 18 A schematic diagram of the structure of a network device 1800 provided in an embodiment of this application;

[0076] Figure 19 A schematic diagram of the structure of a network device 1900 provided in an embodiment of this application;

[0077] Figure 20 This is a schematic diagram of the structure of a network device 2000 provided in an embodiment of this application. Detailed Implementation

[0078] The embodiments of this application are described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. As those skilled in the art will understand, with the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0079] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0080] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0081] The following is an explanation of some terms and concepts involved in the embodiments of this application.

[0082] (1) Routing announcement message

[0083] A route advertisement message is a message used to advertise routes. Specifically, to enable message transmission between network devices, these devices need to send route advertisement messages to each other. For example, network device A sends a route advertisement message carrying its routing information to network device B. After receiving the route advertisement message from network device A, network device B can generate a corresponding route based on the routing information in the message and then transmit the message to network device A according to that route.

[0084] (2) Routing prefix

[0085] A routing prefix is ​​a network number used to uniquely identify a network connected to the Internet.

[0086] (3) Border Gateway Protocol (BGP)

[0087] BGP is a routing protocol for autonomous systems (AS) that runs on the Transmission Control Protocol (TCP). BGP is used to exchange routing information between different ASes. When two ASes need to exchange routing information, each AS must designate a node running BGP to represent it in exchanging routing information with other ASes. The nodes in two ASs that use BGP to exchange information are also called border gateways or border routers.

[0088] (4) Interior Gateway Protocol (IGP)

[0089] An Intermediate Gateway Protocol (IGP) is a protocol used within an Autonomous System (AS) to exchange routing information between network devices (such as gateways and routers). IGP protocols include Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS) routing protocol, Interior Gateway Routing Protocol (IGRP), and Enhanced Interior Gateway Routing Protocol (EIGRP).

[0090] (5) Virtual Private Network instance (VPN instance)

[0091] A VPN instance, also known as a Virtual Routing Forwarding (VRF) instance, is used to achieve routing isolation between different VPNs. A VPN instance is a dedicated entity established and maintained by the provider edge (PE) device for directly connected sites. Each site has its own independent VPN instance on the PE device. Each VPN instance on the PE device has a relatively independent routing table and Label Forwarding Information Base (LFIB) to ensure the independence and security of VPN data.

[0092] The above describes the terminology and concepts involved in the embodiments of this application. The following will describe the application scenarios of the encrypted information distribution method provided in the embodiments of this application.

[0093] Please see Figure 1 , Figure 1 This is a schematic diagram of a network scenario for encrypted services within the same autonomous system, provided as an embodiment of this application.

[0094] like Figure 1As shown, the network scenario includes multiple network devices located within the same autonomous system (i.e., autonomous system 001). These network devices specifically include network device a, network device b, network device c, and network device A. Network devices a and b establish neighbor relationships with network device c through network device A; alternatively, network device a directly establishes a neighbor relationship with network device c, and network device b directly establishes a neighbor relationship with network device c. For example, network devices a, b, and c are PE devices, and network device A is a route reflector (RR).

[0095] exist Figure 1 In the scenario of data transmission within the same autonomous system, data packets from network device a and network device b to network device c need to be encrypted to ensure data transmission security. That is, in... Figure 1 In the scenario shown, business data transmitted between network devices within the same autonomous system needs to be encrypted.

[0096] Please see Figure 2 , Figure 2 This is a schematic diagram of a network scenario for cross-autonomous system encryption services provided in an embodiment of this application.

[0097] like Figure 2 As shown, the network scenario includes multiple network devices located in different autonomous systems, specifically network devices 1 through 5. Network device 1 and network device 2 are connected via network devices 3, 4, and 5; that is, data packets sent from network device 1 to network device 2 must pass through network devices 3, 4, and 5. Furthermore, data packets between network devices 3 and 4 are transmitted across autonomous system 001, and data packets between network devices 4 and 5 are transmitted across autonomous system 002. For example, network devices 1 and 2 are, for instance, Customer Edge (CE) devices, and network devices 3, 4, and 5 are PE devices.

[0098] exist Figure 2 In the scenario of data transmission across autonomous systems, as shown, data packets from network device 3 to network device 4 and from network device 4 to network device 5 both need to be encrypted during transmission to ensure data security. That is, in... Figure 2 In the scenario shown, the business data transmitted between network devices across autonomous systems needs to be encrypted.

[0099] above Figure 1 and Figure 2This example illustrates encrypted data transmission between network devices in different scenarios, using data transmission within the same autonomous system and data transmission across autonomous systems as examples. In practical applications, encrypted data transmission between network devices may also be required in other scenarios, and this embodiment does not limit the specific scenarios.

[0100] The above describes the application scenarios of the methods provided in the embodiments of this application. The following will describe in detail the method for distributing encrypted information provided in the embodiments of this application.

[0101] Please see Figure 3 , Figure 3 This is a flowchart illustrating a method for distributing encrypted information according to an embodiment of this application. Figure 3 The method shown can be applied to any two path-reachable network devices in a data communication network to achieve encrypted information distribution between network devices, thereby ensuring that encrypted transmission of business data can be achieved between network devices.

[0102] like Figure 3 As shown, the method for distributing encrypted information is applied to a first network device and a second network device. The second network device generates a routing advertisement message carrying encrypted extension information and sends this message to the first network device. The first network device receives the routing advertisement message from the second network device and generates a routing table entry based on the routing prefix and encrypted extension information in the message. This allows the first network device to encrypt data packets before sending them to the second network device, based on the instructions in the routing table entry, and then send the encrypted data packets to the second network device.

[0103] Optionally, the first network device and the second network device may be physical devices such as routers, switches or gateways, or virtual devices that support packet forwarding. This embodiment does not limit the specific implementation of the first network device and the second network device.

[0104] Specifically, Figure 3 The method for distributing encrypted information shown includes the following steps 301-305.

[0105] Step 301: The second network device obtains service-related encryption information, which is used to indicate the object of the service encryption application.

[0106] In this embodiment, the encryption information obtained by the second network device is used to indicate the objects to which service encryption is applied, that is, to indicate which objects need to be encrypted. Based on the obtained encryption information, the second network device can determine whether the currently executed service needs to be encrypted.

[0107] For example, the objects to which service encryption is applied include address families or VPN instances that require the establishment of encrypted connections. Before publishing a routing advertisement message, the second network device requests confirmation as to whether the routing prefix in the routing advertisement message to be published belongs to a network prefix in an address family or VPN instance, in order to determine whether the service related to the routing prefix needs encryption. As another example, the objects to which service encryption is applied include routing policies, which are used to indicate network devices that need to establish encrypted connections. For instance, the routing policy indicates the identifier or address of the network device that needs to establish an encrypted connection. In this way, by confirming whether its own identifier or address belongs to the identifier or address of the network device indicated in the routing policy, the second network device can determine whether the service it is currently performing needs encryption.

[0108] Optionally, the encryption information in the second network device is pre-configured by the controller; or it is transmitted to the second network device by other network devices in the network system; or the encryption information in the second network device is manually configured by the administrator on the second network device. This embodiment does not limit the specific method by which the second network device obtains the encryption information.

[0109] Step 302: The second network device generates a first route advertisement message based on the encrypted information. The first route advertisement message includes a route prefix and first encrypted extension information related to the route prefix, and the first encrypted extension information includes a first parameter for generating a key.

[0110] When the second network device determines, based on encrypted information, that the service it performs requires encryption, it generates a first route advertisement message carrying first encryption extension information. The first encryption extension information carried in the first route advertisement message is related to the route prefix in the first route advertisement message; that is, packets destined for that route prefix need to be encrypted and transmitted based on the content indicated by the first encryption extension information. Furthermore, the second network device is a boundary device in the network indicated by the route prefix in the first route advertisement message, responsible for packet forwarding between the network indicated by the route prefix and other networks.

[0111] Optionally, if the object to which the service encryption is applied includes an address family or VPN instance that needs to establish an encrypted connection, the second network device generates the aforementioned first route advertisement message based on the network prefix belonging to the address family or VPN instance. Alternatively, if the service encryption is applied to an object routing policy, and the routing policy is used to indicate the network device that needs to establish an encrypted connection, the second network device generates the aforementioned first route advertisement message based on the fact that it belongs to the network device indicated in the routing policy.

[0112] Step 303: The second network device sends a first routing advertisement message to the neighboring device.

[0113] After generating the first routing advertisement message, the second network device sends the first routing advertisement message to its connected neighboring devices. Furthermore, upon receiving the first routing advertisement message, the neighboring devices of the second network device may optionally forward it to other neighboring devices to facilitate the propagation of the first routing advertisement message throughout the data communication network.

[0114] Step 304: The first network device receives the first routing announcement message.

[0115] In this embodiment, optionally, the first network device is, for example, a neighboring device of the second network device, that is, the first network device receives the first routing advertisement message from the second network device. Alternatively, the first network device may not be a neighboring device of the second network device, that is, other network devices are connected between the first and second network devices, and the first network device receives the first routing advertisement message from the second network device from a neighboring device of the first network device.

[0116] Step 305: The first network device generates at least one key based on the first encryption extension information in the first routing announcement message.

[0117] Because the first encryption extension information in the first routing advertisement message includes a first parameter for generating a key, the first network device can generate at least one key based on the first parameter in the first encryption extension information. The at least one key generated by the first network device is used to encrypt data packets from the first network device to the network indicated by the routing prefix in the first routing advertisement message; or, the at least one key is used to decrypt data packets from the network indicated by the routing prefix to the first network device. Alternatively, the at least one key generated by the first network device can be used to both encrypt and decrypt data packets from the network indicated by the routing prefix to the first network device.

[0118] For example, in the first encryption extension information, the first parameter for generating the key includes one or more of the following parameters: a random number for calculating the key, an identifier of the second network device, a security protocol type, a message encapsulation mode, a verification algorithm, and an encryption algorithm. Based on the first parameter in the first encryption extension information, the first network device can use the encryption algorithm and encryption parameters specified in the first parameter to generate at least one of the aforementioned keys.

[0119] Step 306: The first network device generates a routing table entry based on the first routing advertisement message. The routing table entry includes the routing prefix in the first routing advertisement message, and the routing table entry is used to indicate the outgoing interface on the first network device that leads to the network indicated by the routing prefix and to indicate that at least one key is used to encrypt data packets before forwarding data packets whose destination address belongs to the network indicated by the routing prefix.

[0120] Since the first route advertisement message includes both the route prefix and the first encryption extension information associated with the route prefix, the first network device generates a routing table entry with encryption attributes based on the first route advertisement message. The routing table entry with encryption attributes indicates both how the first network device should forward data packets destined for the network indicated by the route prefix, and that the first network device needs to use at least one of the aforementioned keys to encrypt data packets destined for the network indicated by the route prefix.

[0121] It should be noted that steps 301-306 above describe the second network device sending a routing advertisement message to the first network device, enabling the first network device to generate routing table entries with encryption attributes, thereby ensuring that the first network device can send encrypted data packets to the second network device. In practical applications, the first network device can also send a routing advertisement message carrying encryption extension information to the second network device, so that the second network device can also send encrypted data packets to the first network device. The specific process of the first network device sending the routing advertisement message carrying encryption extension information to the second network device, and the second network device generating routing table entries with encryption attributes based on the received routing advertisement message, is similar to steps 301-306 above, and will not be repeated in this embodiment.

[0122] In this embodiment, by simultaneously carrying the routing prefix and related encryption extension information in the routing advertisement message, the network device receiving the routing advertisement message can generate a key based on the encryption extension information in the routing advertisement message and generate a routing table entry with encryption attributes. This routing table entry can instruct the network device to encrypt data using the key before sending the encrypted data to the network indicated by the routing prefix, thereby achieving encrypted data transmission between network devices.

[0123] In summary, this embodiment uses routing announcement messages to transmit encrypted information between multiple network devices and guides network devices to generate routing table entries with encryption attributes. This ensures that network devices can transmit data packets encrypted based on routing table entries, eliminating the need to establish dedicated encrypted tunnels between network devices and effectively reducing network deployment complexity.

[0124] The above describes the process by which the second network device carries first encrypted extension information in the first routing advertisement message, enabling the first network device to generate routing table entries with encrypted attributes based on the first encrypted extension information after receiving the first routing advertisement message. For ease of understanding, the following will detail how to implement carrying the first encrypted extension information in the first routing advertisement message.

[0125] Optionally, in addition to the first parameters used to generate the key, the first encrypted extension information also includes information about a first encrypted network topology. The information about the first encrypted network topology is used to indicate the multiple network devices constituting the first encrypted network topology and to indicate that encrypted connections are permitted between the multiple network devices.

[0126] It should be understood that the data communication network in which the first and second network devices reside may include a large number of network devices. However, in some practical business scenarios, it is often only necessary to establish encrypted connections between a portion of the network devices in the data communication network. In this case, for ease of management, the network devices that are expected to establish encrypted connections with each other are divided into an encrypted network topology, and encrypted connections are allowed between multiple network devices within the same encrypted network topology.

[0127] In other words, by indicating the first encrypted network topology in the first encrypted extension information, it is possible to indicate the first encrypted network topology in which the second network device is located, and other network devices within the first encrypted network topology are allowed to establish encrypted connections with the second network device.

[0128] The following describes the specific implementation of carrying the first parameter for generating the key and the information indicating the topology of the first encrypted network in the first encrypted extension information.

[0129] In implementation method 1, the first encrypted extension information is carried in the first type length value (TLV) field of the first route advertisement message.

[0130] The first TLV field includes a first parameter for generating the key and information about the first encrypted network topology. For example, the first TLV field includes the identifiers of one or more network devices, which are devices in the first encrypted network topology that need to establish an encrypted connection with the second network device. In other words, implementation 1 specifies the devices that need to establish an encrypted connection with the second network device by carrying the identifiers of the network devices in the first TLV field. Thus, when any network device receives a first routing advertisement message from the second network device, the network device only needs to determine whether its own identifier is among the one or more identifiers indicated by the first TLV field to determine whether it needs to establish an encrypted connection with the second network device.

[0131] For example, when the second network device is in a BGP network, the identifiers of one or more network devices included in the first TLV field may be, for example, the BGP router identifiers of the network devices. Furthermore, the identifiers of one or more network devices included in the first TLV field may also be other types of identifiers, without specific limitations here.

[0132] In implementation method 2, the first encrypted extension information is carried in the first TLV field and the second TLV field of the first routing advertisement message.

[0133] The first TLV field includes a first parameter for generating the key, while the second TLV field indicates information about the first encrypted network topology. In other words, the first TLV field in the first routing advertisement message is used to transmit parameters for generating the key, and the second TLV field is used to manage the encrypted network topology.

[0134] For example, the second TLV field is used to indicate the first encrypted network topology to which one or more network devices belong, and the identifier of one or more network devices within the first encrypted network topology. That is, the second TLV field simultaneously indicates that the one or more network devices belong to the first encrypted network topology, and the identifier of the one or more network devices within the first encrypted network topology. The one or more network devices indicated by the second TLV field are devices in the first encrypted network topology that need to establish an encrypted connection with the second network device.

[0135] Optionally, the second TLV field includes multiple bits, and one of these bits refers to at least one network device within the first encrypted network topology. The one or more network devices in the first encrypted network topology indicated by the second TLV field correspond to one or more bits with a preset bit state. The preset bit state can mean that the bit is set (i.e., the bit value is 1), meaning the network device corresponding to the set bit in the multiple bits is a network device in the first encrypted network topology that needs to establish an encrypted connection with the second network device. Alternatively, the preset bit state can mean that the bit is not set (i.e., the bit value is 0), meaning the network device corresponding to the unset bit in the multiple bits is a network device in the first encrypted network topology that needs to establish an encrypted connection with the second network device. This embodiment does not specifically limit the preset bit state.

[0136] In addition, the bits in the second TLV field can be used to refer to at least one network device; if there are enough bits in the second TLV field, some bits in the second TLV field may not refer to a network device.

[0137] For example, suppose the second TLV field includes 6 bits. If the first encrypted network topology includes 6 network devices, and all 6 network devices need to establish an encrypted connection with the second network device, then each bit in the second TLV refers to a network device, and all 6 bits are set to 1.

[0138] For example, assuming the second TLV field includes 6 bits, if the first encrypted network topology includes 12 network devices, and all 12 network devices need to establish encrypted connections with the second network device, then each bit in the second TLV field represents two network devices, and all 6 bits are set to 1. As another example, assuming the second TLV field includes 6 bits, if the first encrypted network topology includes 3 network devices that need to establish encrypted connections with the second network device, then the first three bits in the second TLV field can each represent one network device, and all three bits in the second TLV field are set to 1.

[0139] Optionally, in implementation method 1 and implementation method 2 above, the first TLV field includes a first parameter for generating the key, and the first parameter specifically includes the router identifier of the second network device.

[0140] In the process of the first network device generating at least one key based on the first encryption extension information, the first network device generates at least one key according to the router identifier of the second network device and the router identifier of the first network device; wherein, the router identifier of the second network device and the router identifier of the first network device are both unique identifiers.

[0141] Since the router identifiers of the first and second network devices are both unique identifiers in the data communication network, generating a key based on the router identifiers of the two network devices can guarantee the uniqueness of the generated key, thereby ensuring the security of encrypted transmission.

[0142] It should be noted that, in the process of the first network device generating at least one key, in addition to the router identifiers of the second network device and the first network device mentioned above, the first network device can also generate at least one key based on other parameters. For example, the first network device can generate at least one key based on the random number in the first TLV field, the random number generated by the first network device, the router identifier of the first network device, and the router identifiers of the second network device. This embodiment does not specifically limit the method by which the first network device generates the key.

[0143] Optionally, the first TLV field may also include quantum key parameters, such as a key identifier for quantum key distribution (QKD). Thus, after the first network device obtains the first TLV field from the first routing advertisement message, it sends the QKD key identifier from the first TLV field to the quantum key transmission network to request a quantum key. After the quantum key transmission network returns the quantum key to the first network device, the first network device uses the quantum key to encrypt data destined for the second network device.

[0144] In some optional embodiments, after establishing an encrypted connection, the first network device and the second network device often need to generate a secure parameter index (SPI) to indicate the encrypted connection between the first network device and the second network device. For example, for the first network device, the secure parameter index generated by the first network device is based on the content of the first TLV field and the local parameters of the first network device.

[0145] However, when the first network device needs to establish encrypted connections with multiple other network devices, the security parameter indices generated by the first network device for different encrypted connections may be the same. Therefore, this embodiment provides a method to resolve SPI conflicts.

[0146] For example, after receiving the first routing advertisement message, the first network device generates a first security parameter index based on the first TLV field and the local parameters of the first network device. The first security parameter index is used to indicate the encrypted connection between the first network device and the second network device, and the local parameters include a random number and / or the identifier of the first network device.

[0147] If the first security parameter index is the same as other security parameter indices already generated in the first network device, the first network device updates its local parameters and generates a second security parameter index based on the first TLV field and the updated local parameters. The second security parameter index indicates the encrypted connection between the first and second network devices, and it is different from other security parameter indices already generated in the first network device.

[0148] Then, the first network device sends the updated local parameters to the second network device so that the second network device can also regenerate the corresponding security parameter index.

[0149] The above describes how to carry the first encrypted extension information based on the first TLV field and the second TLV field in the first route advertisement message. The following will introduce the first route advertisement message in detail with specific application scenarios.

[0150] Optionally, if the data communication network in which the second network device is located is a BGP network or an IGP network, the first route advertisement message sent by the second network device may be, for example, a BGP message or an IGP message.

[0151] Taking the first route advertisement message as a BGP update message as an example, the first TLV field and the second TLV field are carried in the extended path attribute field of the BGP update message. Please refer to [link / reference]. Figure 4 , Figure 4 This is a schematic diagram illustrating the format of a BGP update message provided in an embodiment of this application. The BGP update message includes multiple fields: unfeasible routes length, withdrawn routes, total pathattribute length, path attributes, and network layer reachability information (NLRI). The unfeasible routes length field indicates the length of the unfeasible routes field; the withdrawn routes field indicates unreachable routes, including network prefixes of unfeasible routes to be withdrawn; the path attribute length field indicates the length of the path attribute field; the path attribute field represents a list of attributes of the path associated with the NLRI field. Typically, the path attribute field is filled with all attributes of the path associated with the NLRI field in order of their type numbers. The NLRI field represents network layer reachability information, including route prefixes that need to be advertised.

[0152] In this embodiment, the path attribute fields are extended to include the first TLV field and the second TLV field in the extended path attribute field of the BGP update message. The extended path attribute fields include a flags field, a type field, a length field, and a value field. Both the first TLV field and the second TLV field include a type field, a length field, and a value field.

[0153] Taking the first route advertisement message as an OSPF message as an example, the first TLV field and the second TLV field are carried in the Link State Advertisement (LSA) sub-TLV field of the OSPF message. Please refer to [link to relevant documentation]. Figure 5 , Figure 5This is a schematic diagram illustrating the format of an OSPF E-Inter-Area-Prefix-LSA message provided in an embodiment of this application. The OSPF message includes multiple fields, namely, LSA Age, Link State ID, Advertising Router, Sequence Number, LSA Checksum, Length, and TLV.

[0154] Please see Figure 6 , Figure 6 This is a schematic diagram illustrating the format of the TLV field in an OSPF E-Inter-Area-Prefix-LSA message, provided as an embodiment of this application. For example... Figure 6 As shown, the TLV field in the OSPF E-Inter-Area-Prefix-LSA message specifically includes the following fields: inter-area prefix field, TLV length field, metric field, prefix length field, prefix options field, address prefix field, and sub-TLVs field.

[0155] In this embodiment, the first TLV field and the second TLV field are carried in the sub-TLVs field of the TLV field in the OSPF E-Inter-Area-Prefix-LSA message, thereby realizing the extension of the OSPF message to carry the first TLV field and the second TLV field.

[0156] Furthermore, the encrypted extension information carried by the first TLV field and the second TLV field has an optional attribute and a transparent attribute, that is, the second network device can choose whether to add encrypted extension information to the routing advertisement message, and the first network device can choose to transparently transmit the routing advertisement message carrying encrypted extension information.

[0157] For example, please refer to Figure 7 , Figure 7 This is a schematic diagram illustrating the format of a first TLV field and a second TLV field provided for embodiments of this application. Figure 7As shown, in the aforementioned BGP update message or OSPF message, the first TLV field is used to transmit encryption-related parameters. The first TLV field includes the basic sub-TLV, the Diffie-Hellman Key exchange sub-TLV (DH_KE sub-TLV), and the secure proposal sub-TLV. The second TLV field is used for managing the encrypted network topology to adapt to any encrypted topology in the data communication network, increasing network deployment flexibility.

[0158] The basic sub-TLV includes, for example, a random number for calculating the key and identification information related to the network device. Specifically, the identification information related to the network device includes, but is not limited to, the following identifiers: the IP address of the second network device, the router identifier of the second network device, the QKD key identifier for quantum encryption, and a count for identifying key updates (rekeys).

[0159] The DH_KE sub-TLV includes: key exchange algorithm group identifier and key exchange algorithm swap data.

[0160] Security recommendations sub-TLV include: security protocol type, message encapsulation mode, authentication algorithm, and encryption algorithm.

[0161] The second TLV field includes: topology group identifier (i.e., the identifier of the first encrypted network topology mentioned above), topology group type, and topology group attribute value. Based on these multiple fields in the second TLV field, flexible management of the encrypted network topology is possible. For an example, please refer to... Figure 8 , Figure 8 This is a schematic diagram illustrating the format of a second TLV field provided in an embodiment of this application.

[0162] The topology group identifier is used to indicate the encrypted network topology in which the network device that needs to establish an encrypted connection with the second network device is located.

[0163] Figure 8 The "Type" shown refers to the topology group type, which indicates the type of encrypted network topology. For example, a topology group type of 0 indicates that the encrypted network topology is without sub-attributes; a topology group type of 1 indicates that the encrypted network topology is hub-spoke sub-attributes; and a topology group type of 2 indicates that the encrypted network topology is bitmap sub-attributes.

[0164] Figure 8 The "Group type" shown refers to the topology group type. Topology group attribute values ​​are used to indicate specific attribute information within the encrypted network topology. For example, a topology group attribute value indicates the affinity group attribute (i.e., ...) within the encrypted network topology. Figure 8 The AFFINITY-GROUP value shown in the image indicates the network devices within the same encrypted network topology that require encrypted connections. Furthermore, the affinity-group attribute can also have corresponding sub-attributes (i.e., ...). Figure 8 The SUB-ATTRIBUTION value shown in the figure, and the sub-attributes of the affinity-group attribute are used to indicate the specific network devices that require encrypted connections.

[0165] For example, please refer to Figure 9 , Figure 9 These are schematic diagrams illustrating various encrypted network topologies provided in embodiments of this application. For example... Figure 9 As shown, in a real network topology, PE1, PE2, PE3, and PE4 are interconnected. However, in practical applications, PE1, PE2, PE3, and PE4 can form different encrypted network topologies according to different business needs. Among them, Figure 9 Types 1 through 6 are used to represent different encrypted network topologies.

[0166] In Type 1, PE1, PE2, PE3, and PE4 constitute an encrypted network topology, and all PE1, PE2, PE3, and PE4 are fully encrypted, meaning that any PE is encryptedly connected to all other PEs.

[0167] In Type 2, PE2, PE3, and PE4 constitute an encrypted network topology, and all connections between PE2, PE3, and PE4 are fully encrypted, meaning that any one of PEs (PE2, PE3, and PE4) is encryptedly connected to every other PE. For the encrypted network topology shown in Type 2, the topology group attribute value in the second TLV field indicates the affinity-group attribute, and PE2, PE3, and PE4 carry the same affinity-group value.

[0168] In type 3, PE1, PE2, PE3, and PE4 constitute an encrypted network topology, and PE1, PE2, and PE4 are each encryptedly connected to PE3. For the encrypted network topology shown in type 3, the topology group attribute value in the second TLV field indicates the affinity-group attribute, and the affinity-group attribute also has sub-attributes.

[0169] Specifically, PE1, PE2, PE3, and PE4 carry the same affinity-group value. Furthermore, in the route advertisement message generated by PE3, the sub-attribute of the affinity-group attribute in the second TLV field is 111, indicating that PE3 needs to establish an encrypted connection with PE1, PE2, and PE4. In the route advertisement message generated by PE1, the sub-attribute of the affinity-group attribute in the second TLV field is 001, indicating that PE1 needs to establish an encrypted connection with PE3. In the route advertisement message generated by PE2, the sub-attribute of the affinity-group attribute in the second TLV field is 010, indicating that PE2 needs to establish an encrypted connection with PE3. In the route advertisement message generated by PE4, the sub-attribute of the affinity-group attribute in the second TLV field is 100, indicating that PE4 needs to establish an encrypted connection with PE3.

[0170] Alternatively, PE1, PE2, PE3, and PE4 may carry the same affinity-group value. Furthermore, in the route advertisement message generated by PE3, the affinity-group attribute in the second TLV field has a sub-attribute of "hub," indicating that PE3 is a backbone node. In the route advertisement messages generated by PE1, PE2, and PE4, the affinity-group attribute in the second TLV field has a sub-attribute of "spoke," indicating that PE1, PE2, and PE4 are branch nodes.

[0171] In Type 4, PE1, PE2, and PE4 constitute encrypted network topology A, and all connections between PE1, PE2, and PE4 are fully encrypted. PE2, PE3, and PE4 constitute encrypted network topology B, and all connections between PE2, PE3, and PE4 are fully encrypted. For the encrypted network topologies shown in Type 4, the topology group attribute value in the second TLV field indicates the affinity-group attribute. In route advertisement messages sent by PE1, PE2, and PE4 to other PEs in encrypted network topology A, the affinity-group value is A; in route advertisement messages sent by PE2, PE3, and PE4 to other PEs in encrypted network topology B, the affinity-group value is B.

[0172] In type 5, PE1, PE2, and PE4 constitute encrypted network topology A, with PE1 encryptedly connected to both PE2 and PE4. PE2, PE3, and PE4 constitute encrypted network topology B, with PE3 encryptedly connected to both PE2 and PE4.

[0173] For the encrypted network topology shown in Type 5, in the route advertisement message sent by PE1 to the network devices in encrypted network topology A, the affinity-group value in the second TLV field is A, and the sub-attribute of the affinity-group attribute is 11, indicating that PE1 needs to establish an encrypted connection with PE2 and PE4. In the route advertisement message sent by PE2 to the network devices in encrypted network topology A, the affinity-group value in the second TLV field is A, and the sub-attribute of the affinity-group attribute is 01, indicating that PE2 needs to establish an encrypted connection with PE1. In the route advertisement message sent by PE4 to the network devices in encrypted network topology A, the affinity-group value in the second TLV field is A, and the sub-attribute of the affinity-group attribute is 10, indicating that PE4 needs to establish an encrypted connection with PE1.

[0174] Furthermore, in the routing advertisement message sent by PE3 to network devices in encrypted network topology B, the affinity-group value in the second TLV field is B, and the sub-attribute of the affinity-group attribute is 11, indicating that PE3 needs to establish an encrypted connection with PE2 and PE4. In the routing advertisement message sent by PE2 to network devices in encrypted network topology B, the affinity-group value in the second TLV field is B, and the sub-attribute of the affinity-group attribute is 01, indicating that PE2 needs to establish an encrypted connection with PE3. In the routing advertisement message sent by PE4 to network devices in encrypted network topology B, the affinity-group value in the second TLV field is B, and the sub-attribute of the affinity-group attribute is 10, indicating that PE4 needs to establish an encrypted connection with PE3.

[0175] In type 6, PE2, PE3, and PE4 form an encrypted network topology A on service A, and all connections between PE2, PE3, and PE4 are fully encrypted. PE2, PE3, and PE4 form an encrypted network topology B on service B, and PE3 is encryptedly connected to both PE2 and PE4.

[0176] For example, in Type 6, for VPN service A, in the route advertisement messages sent by PE2, PE3, and PE4 to network devices in encrypted network topology A, the affinity-group value in the second TLV field is A. For VPN service B, in the route advertisement message sent by PE3 to network devices in encrypted network topology B, the affinity-group value in the second TLV field is B, and the sub-attribute of the affinity-group attribute is 11, indicating that PE3 needs to establish an encrypted connection with PE2 and PE4. In the route advertisement message sent by PE2 to network devices in encrypted network topology B, the affinity-group value in the second TLV field is B, and the sub-attribute of the affinity-group attribute is 01, indicating that PE2 needs to establish an encrypted connection with PE3. In the route advertisement message sent by PE4 to network devices in encrypted network topology B, the affinity-group value in the second TLV field is B, and the sub-attribute of the affinity-group attribute is 10, indicating that PE4 needs to establish an encrypted connection with PE3.

[0177] The above describes how to carry the first encrypted extension information in the first routing advertisement message. The following will describe in detail how the first network device sends the encrypted message to the second network device when it obtains a message destined for the second network device.

[0178] Optional, please refer to Figure 10 , Figure 10 This is another flowchart illustrating a method for distributing encrypted information provided in an embodiment of this application. Figure 10 As shown above, in the above Figure 3 In the embodiment shown, after the first network device generates a routing table entry based on the first routing advertisement message, the first network device also performs the following steps 307-3011.

[0179] Step 307: When the first network device obtains the target packet, if the destination address of the target packet matches the routing prefix in the routing table entry, the first network device encrypts the target packet using at least one key based on the indication of the routing table entry.

[0180] The target message is the message to be forwarded received by the first network device.

[0181] In this step, if the destination address of the target packet matches the routing prefix in the routing table entry, it means that the target packet is destined for the second network device. Therefore, the first network device encrypts the target packet using at least one pre-generated key based on the indication of the routing table entry.

[0182] Step 308: Determine whether there is an existing tunnel between the first network device and the second network device.

[0183] In this step, after encrypting the target packet, the first network device needs to determine whether it already has a tunnel with the second network device, such as a VPN tunnel.

[0184] Step 309: If there is an established tunnel between the first network device and the second network device, the first network device sends the encrypted target message based on the established tunnel.

[0185] Since the messages transmitted from the first network device to the second network device are encrypted using a pre-generated key, the data transmission security between the first and second network devices is guaranteed. If a tunnel has already been established between the first and second network devices, the first network device sends the encrypted target message to the second network device through the established tunnel, without needing to create a dedicated encryption tunnel.

[0186] Step 3010: If there is no existing tunnel between the first network device and the second network device, then the first network device creates a new tunnel between itself and the second network device.

[0187] Step 3011: The first network device sends the encrypted target message based on the newly created tunnel.

[0188] For example, the first encrypted extension information also includes the Internet Protocol (IP) address of the second network device. The first network device creates an IP-in-IP tunnel with the second network device based on both the first and second network device IP addresses; that is, the newly created tunnel is an IP-in-IP tunnel. An IP-in-IP tunnel is a Layer 3 tunnel, where the original IP packet is encapsulated within a new IP packet to create the tunnel transmission.

[0189] Optionally, after receiving the first routing announcement message, the first network device continues to forward the first routing announcement message to other network devices so that the first routing announcement message can be continuously transmitted in the data communication network.

[0190] For example, upon receiving a first routing advertisement message, the first network device determines whether it needs to modify the first routing advertisement message. If the first network device needs to establish a new encrypted connection with another network device, the first network device needs to modify the first encryption extension information in the first routing advertisement message so that other network devices can establish encrypted connections with the first network device. If the first network device does not need to establish a new encrypted connection with another network device, the first network device does not need to modify the first encryption extension information in the first routing advertisement message, but instead forwards the first routing advertisement message to other network devices so that other network devices can establish encrypted connections with the second network device.

[0191] If the first network device needs to modify the first encryption extension information in the first routing advertisement message, the first network device generates second encryption extension information. The second encryption extension information includes a second parameter for generating the key and information about the second encrypted network topology. The information about the second encrypted network topology is used to indicate the network devices constituting the second encrypted network topology and to indicate that encrypted connections are allowed between the network devices in the second encrypted network topology. The first network device then replaces the first encryption extension information in the first routing advertisement message with the second encryption extension information to obtain a second routing advertisement message, which it then sends to its neighboring devices.

[0192] If the first network device does not need to change the first encryption extension information in the first routing advertisement message, the first network device will forward the received first routing advertisement message to its neighboring devices without changing the first encryption extension information in the first routing advertisement message.

[0193] The above describes a method for distributing encrypted information provided by embodiments of this application. For ease of understanding, the execution process of the method for distributing encrypted information provided by embodiments of this application will be described in detail below with specific examples.

[0194] Please see Figure 11 , Figure 11 This is a schematic diagram illustrating the distribution of encrypted information within the same autonomous system, as provided in an embodiment of this application. Figure 11 In this context, data packets from network device a and network device b to network device c need to be transmitted in encrypted form to ensure data transmission security.

[0195] First, configure the encrypted network topology attributes on network devices a, b, and c. The encrypted network topology attribute for network devices a and b is the "spoke" attribute, meaning that network devices a and b are branch nodes; the encrypted network topology attribute for network device c is the "hub" attribute, meaning that network device c is the backbone node.

[0196] Then, network device c sends a route advertisement message 1 carrying encrypted extension information to network device A. The route advertisement message 1 also carries a route prefix related to the encrypted extension information, and network device c is the boundary device of the network indicated by the route prefix 1.

[0197] After receiving the routing advertisement message 1 sent by network device c, network device A recognizes that the routing advertisement message 1 has a transparent transmission attribute. Therefore, network device A forwards the routing advertisement message 1 to network device a and network device b.

[0198] After receiving Route Advertisement Message 1, network device A generates a key and a routing table entry based on the routing prefix and encryption extension information in Route Advertisement Message 1. The routing table entry generated by network device A indicates the outgoing interface to network device C and specifies that packets destined for network device C must be encrypted with the key before forwarding them.

[0199] Similarly, after receiving Route Advertisement Message 1, network device b generates a key and a routing table entry based on the routing prefix and encryption extension information in Route Advertisement Message 1. The routing table entry generated by network device b indicates the outgoing interface to network device c and specifies that packets destined for network device c must be encrypted with the key before forwarding them.

[0200] Please see Figure 12 , Figure 12 This is a schematic diagram illustrating the distribution of encrypted information between different autonomous systems, as provided in an embodiment of this application. Figure 12 In this process, network device 1 and network device 2 communicate with each other, and data packets from network device 3 to network device 5 need to be transmitted in encrypted form.

[0201] First, network device 2 sends a route advertisement message 2 to network device 5. The route advertisement message 2 carries a route prefix, and network device 2 is the boundary device of the route prefix.

[0202] Then, network device 5 generates a route advertisement message 3 carrying encrypted extension information based on the route advertisement message 2 received from network device 2, and sends route advertisement message 3 to network device 4. The route prefix carried in route advertisement message 3 is the same as the route prefix in route advertisement message 2. The encrypted extension information in route advertisement message 3 indicates that the network device that needs to establish an encrypted connection with network device 5 is network device 3.

[0203] After receiving the routing advertisement message 3 sent by network device 5, network device 4 recognizes that the routing advertisement message 3 has a transparent transmission attribute, so network device 4 forwards the routing advertisement message 3 to network device 3.

[0204] After receiving the routing advertisement message 3, network device 3 generates a key and a routing table entry 3 based on the routing prefix and encryption extension information in the routing advertisement message 3. The routing table entry 3 indicates the outgoing interface to network device 2 and specifies that the message needs to be encrypted with the key before forwarding the message destined for network device 2.

[0205] Thus, when network device 3 receives a data packet destined for network device 2 from network device 1, network device 3 encrypts the data packet according to the instructions of routing table entry 3 before sending it to network device 4. After receiving the encrypted data packet from network device 4, network device 5 decrypts the encrypted data packet and then sends the decrypted data packet to network device 2.

[0206] The following will describe in detail the distribution process of encrypted information from the perspectives of the network device that publishes routing advertisement messages carrying encrypted extended information (hereinafter referred to as the sending device) and the network device that receives routing advertisement messages carrying encrypted extended information (hereinafter referred to as the receiving device). The sending device is, for example, the second network device in the above embodiments, and the receiving device is, for example, the first network device in the above embodiments.

[0207] Please see Figure 13 , Figure 13 This is a schematic diagram illustrating a process by which a sending-side device publishes a routing announcement message carrying encrypted extended information, as provided in an embodiment of this application. Figure 13 As shown, the process of the sending device publishing a routing advertisement message carrying encrypted extended information includes the following steps 1301-1304.

[0208] Step 1301: Configure the relevant parameters of the encryption extension attribute on the sending side device.

[0209] In this embodiment, the way the transmitting device configures the relevant parameters of the encryption extension attribute is, for example, by the controller sending the relevant parameters of the encryption extension attribute to the transmitting device, or by the administrator manually configuring the relevant parameters of the encryption extension attribute on the transmitting device.

[0210] The parameters related to the encryption extension attributes include, but are not limited to, the following: the IP address of the sending device, the router identifier of the sending device, the QKD key identifier for quantum encryption, the counter for identifying key updates, the key exchange algorithm group identifier, the exchange data of the key exchange algorithms, the security protocol type, the message encapsulation mode, the verification algorithm, the encryption algorithm, and the information of the network devices that need to establish an encrypted connection with the sending device.

[0211] Step 1302: The sending-side device determines the service for which the encryption extension attribute is applied.

[0212] For example, the sending-side device determines the services applied by the encryption extension attribute based on a pre-configured address family, VPN instance, or routing policy, that is, it determines which network prefixes on the sending-side device are related to the encryption extension attribute.

[0213] Step 1303: The sending device generates a routing announcement message carrying encrypted extension information based on the relevant parameters of the encryption extension attribute and the application's services.

[0214] After determining the service to which the encryption extension attribute applies, the sending device can generate encryption extension information based on the relevant parameters of the encryption extension attribute. Furthermore, it carries the routing prefix and the encryption extension information associated with the routing prefix in the routing advertisement message. The routing prefix is ​​related to the service to which the encryption extension attribute applies.

[0215] Step 1304: The sending device sends a routing advertisement message carrying encrypted extension information to the neighboring device.

[0216] Optionally, before the sending device sends a routing advertisement message with encrypted extended information to neighboring devices, the sending device and other network devices reachable by the routing advertisement message in the data communication network have been authenticated to ensure that the encryption and decryption parties establish a relationship under legitimate identities and to prevent malicious impersonators from establishing a relationship to obtain sensitive data information.

[0217] For example, the sending device establishes an authentication relationship with other network devices through a Transport Layer Security (TLS) authentication mechanism. Alternatively, the sending device establishes an authentication relationship with other network devices using a pre-defined identity key. Specifically, the sending device uses a specific bit flag in the routing advertisement message to indicate whether the encrypted extension information in the routing advertisement message is protected by encryption and integrity. Furthermore, the sending device encrypts the encrypted extension information in the routing advertisement message using the pre-defined identity key, and then performs an integrity calculation on the encrypted content using the pre-defined identity key; the calculation result is then filled into the routing advertisement message. Thus, after the receiving device receives the routing advertisement message, it uses the pre-defined identity key to verify the integrity of the corresponding content in the routing advertisement message, and after successful verification, it uses the pre-defined identity key to parse the content in the routing advertisement message to obtain the encrypted extension information.

[0218] Please see Figure 14 , Figure 14 This is a schematic diagram illustrating the process by which a receiving device receives and processes a routing announcement message carrying encrypted extended information, as provided in an embodiment of this application. Figure 14 As shown, the process by which the receiving device receives and carries a routing advertisement message with encrypted extended information includes the following steps 1401-1414. Figure 14In this context, the receiving device is, for example, the first network device in the above embodiments.

[0219] Step 1401: Receive a routing announcement message carrying encrypted extension information.

[0220] The receiving device can receive routing advertisement messages carrying encrypted extension information from neighboring devices or directly from the sending device.

[0221] Step 1402: Determine whether this device supports encryption extension capabilities.

[0222] Step 1403: If this device does not support encryption extension capabilities, then transmit the route advertisement message transparently.

[0223] If the receiving device does not support encryption extension capabilities, it will transparently transmit the route advertisement message without processing it. Alternatively, the receiving device may generate corresponding routing table entries based solely on the route prefix in the route advertisement message, and these generated routing table entries will not have encryption attributes.

[0224] Step 1404: If this device supports encryption extension capabilities, then parse the routing advertisement message to obtain the encryption extension information.

[0225] Step 1405: Determine whether the encrypted extension information is related to this device.

[0226] The receiving device can determine whether the encrypted extension information is related to its own device based on the encrypted network topology information indicated in the encrypted extension information.

[0227] Step 1406: If the encrypted extension information is not related to this device, then transmit the routing advertisement message.

[0228] Step 1407: If the encrypted extension information is related to this device, generate at least one key and a routing table entry with encrypted attributes.

[0229] Step 1408: Determine whether it is necessary to change the encrypted extension information in the route advertisement message.

[0230] If the receiving device needs to establish an encrypted connection with other network devices, it needs to modify the encryption extension information in the route advertisement message. If the receiving device does not need to establish an encrypted connection with other network devices, it does not need to modify the encryption extension information in the route advertisement message.

[0231] Step 1409: If it is necessary to change the encrypted extension information in the route advertisement message, regenerate the encrypted extension information based on the local parameters and forward the new route advertisement message.

[0232] The new routing announcement message carries regenerated encrypted extension information.

[0233] Step 1410: If no change is needed to the encrypted extension information in the route advertisement message, then forward the route advertisement message.

[0234] If the encrypted extension information in the route advertisement message does not need to be changed, the receiving device forwards the received route advertisement message to the neighboring device without changing the encrypted extension information in the route advertisement message.

[0235] Step 1411: Determine whether there is an available tunnel between the device and the transmitting side.

[0236] Step 1412: If a tunnel is available between the sending device and the sending device, then encrypt and forward packets destined for the sending device based on the available tunnel.

[0237] Step 1413: If no tunnel is available between the sending device and the receiving device, create an IPinIP tunnel based on the IP address of the sending device and the IP address of the receiving device.

[0238] Step 1414: Encrypt and forward packets destined for the sending device based on the newly created IPinIP tunnel.

[0239] In addition, after the receiving device receives the routing advertisement message sent by the sending device, the receiving device also generates a security parameter index based on the encryption extension information and local parameters in the routing advertisement message to identify the encrypted connection between the receiving device and the sending device.

[0240] Please see Figure 15 , Figure 15 This is a schematic diagram illustrating a process for generating a security parameter index between network devices, provided as an embodiment of this application. Figure 15 As shown, the process of generating a security parameter index between network devices includes the following steps 1501-1504.

[0241] Step 1501: Network device 1 sends router identifier 1, random number 1, and rekey 1 to network device 2.

[0242] In this configuration, router identifier 1, random number 1, and rekey1 are carried within the encrypted extension information. Network device 1 sends router identifier 1, random number 1, and rekey1 to network device 2 by sending a route advertisement message including the encrypted extension information. Router identifier 1 is the router identifier of network device 1, and both random number 1 and rekey1 are generated by network device 1.

[0243] Step 1502, Network device 2 generates SPI 1.

[0244] Network device 2 generates SPI 1 using the pseudo-random function pref+(). SPI 1 is pref+(router identifier 1|router identifier 2|random number 1|random number 2|rekey1|rekey2). Router identifier 2 is the identifier of network device 2, and random number 2 and rekey2 are both generated by network device 1.

[0245] SPI 1 is used to identify the encrypted connection from network device 1 to network device 2. Network device 2 can also generate SPI 3 to identify the encrypted connection from network device 2 to network device 1. The parameters used to generate SPI 3 are the same as those used to generate SPI 1. SPI 3 is prrf+(router identifier 2|router identifier 1|random number 2|random number 1|rekey2|rekey1).

[0246] Step 1503: Network device 2 sends router identifier 2, random number 2, and rekey 2 to network device 1.

[0247] Similarly, network device 2 sends router identifier 2, random number 2, and rekey 2 to network device 1 by sending a routing advertisement message that includes encrypted extended information.

[0248] Step 1504, Network device 1 generates SPI 2.

[0249] Network device 2 generates SPI 2 using the pseudo-random function pref+(). SPI 2 is pref+(router identifier 2|router identifier 1|random number 2|random number 1|rekey2|rekey1).

[0250] In this embodiment, the uniqueness of the SPI can be effectively guaranteed by generating the SPI based on the unique router identifier between the two parties involved in the encryption.

[0251] Please see Figure 16 , Figure 16 This is a schematic diagram illustrating a renegotiation process when an SPI conflict occurs, provided as an embodiment of this application. Figure 16 As shown, when a conflict occurs in the SPI generated by the network device, the network device executes the following negotiation process.

[0252] Step 1601: Network device 1 sends encrypted extension information 1 to network device 3.

[0253] The encrypted extension information 1 is carried in the routing announcement message sent by network device 1 to network device 3.

[0254] Step 1602: Network device 3 generates SPI-11 based on encrypted extension information 1 and local parameters 1.

[0255] For details on how network device 3 generates SPI-11 based on encryption extension information 1 and local parameter 1, please refer to the above. Figure 15 Step 1502 in the corresponding embodiment will not be repeated here.

[0256] Step 1603: Network device 2 sends encrypted extension information 2 to network device 3.

[0257] The encrypted extension information 2 is carried in the routing announcement message sent by network device 2 to network device 3.

[0258] Step 1604: Network device 3 generates SPI-21 based on encrypted extension information 2 and local parameter 1.

[0259] Step 1605: Based on the fact that SPI-11 and SPI-21 are the same, network device 3 updates local parameters to obtain local parameter 2.

[0260] After each new SPI is generated, network device 3 compares the new SPI with the previously generated SPI. If SPI-11 and SPI-21 are the same, network device 3 updates its local parameters to obtain local parameter 2.

[0261] Step 1606: Network device 3 generates SPI-12 based on encryption extension information 1 and local parameters 2, generates SPI-22 based on encryption extension information 2 and local parameters 2, and compares whether SPI-12 and SPI-22 are still the same.

[0262] After network device 3 updates its local parameters, network device 3 recalculates the conflicting SPI based on the updated local parameters 2, and compares whether the SPI still conflicts after updating the local parameters.

[0263] Step 1607: If SPI-12 and SPI-22 are different, network device 3 sends encrypted extension information 3 to network device 1 and network device 2. The encrypted extension information 3 carries local parameters 2.

[0264] Furthermore, if SPI-12 and SPI-22 remain the same, network device 3 continues to update local parameters until SPI conflicts no longer occur.

[0265] To implement the above embodiments, this application also provides a network device. Please refer to... Figure 17 , Figure 17 This is a schematic diagram of the structure of a network device 1700 provided in an embodiment of this application. Figure 17 The network device 1700 shown is, for example, the one described above. Figure 3 as well as Figure 10 The first network device in the corresponding embodiment, or the one described above Figure 14 The receiving device in the corresponding embodiment.

[0266] like Figure 17 As shown, network device 1700 includes: a receiving unit 1701, configured to receive a first routing advertisement message, the first routing advertisement message including a routing prefix and first encryption extension information associated with the routing prefix, the first encryption extension information including a first parameter for generating a key; a generating unit 1702, configured to generate at least one key based on the first encryption extension information, wherein the at least one key is used to encrypt data packets from the network device to the network indicated by the routing prefix and / or decrypt data packets from the network indicated by the routing prefix to the network device; the generating unit 1702 is further configured to generate a routing table entry according to the first routing advertisement message, the routing table entry including the routing prefix, and the routing table entry being used to indicate the outgoing interface on the network device to the network indicated by the routing prefix and to indicate that data packets are encrypted with at least one key before forwarding data packets whose destination address belongs to the network indicated by the routing prefix.

[0267] Optionally, the first encrypted extension information is carried in the first TLV field of the first route advertisement message, and the first TLV field includes a first parameter for generating the key.

[0268] Optionally, the first encrypted extension information also includes information for indicating a first encrypted network topology, the information of which indicates multiple network devices constituting the first encrypted network topology and indicates that encrypted connections are permitted between the multiple network devices.

[0269] Optionally, the first encrypted extension information is also carried in the second TLV field of the first routing advertisement message, the second TLV field being used to indicate information about the first encrypted network topology.

[0270] Optionally, the first route advertisement message can be a BGP message or an IGP message.

[0271] Optionally, the first route advertisement message is a BGP update message; the first TLV field and the second TLV field are carried in the extended path attribute field of the BGP update message.

[0272] Optionally, the first route advertisement message is an Open Shortest Path First (OSPF) message; the first TLV field and the second TLV field are carried in the link-state advertisement sub-TLV field of the OSPF message.

[0273] Optionally, the generation unit 1702 is further configured to: when a target message is obtained, if the destination address of the target message matches the routing prefix in the routing table entry, encrypt the target message using at least one key based on the indication of the routing table entry.

[0274] Optionally, the network device may also include a transmitting unit 1703;

[0275] If there is an established tunnel between the network device and the second network device, the sending unit 1703 is used to send the encrypted target message based on the established tunnel, where the second network device is a boundary device in the network indicated by the routing prefix;

[0276] If there is no existing tunnel between the network device and the second network device, the generation unit 1702 is used to create a new tunnel between the network device and the second network device, and the sending unit 1703 is used to send the encrypted target message based on the newly created tunnel.

[0277] Optionally, the first encrypted extension information may also include the IP address of the second network device; the generation unit 1702 is used to create an IPinIP tunnel between the second network device and the first network device based on the IP address of the second network device and the IP address of the first network device.

[0278] Optionally, the first TLV field includes the identifiers of one or more network devices, which are devices in the encrypted network topology that need to establish an encrypted connection with the second network device, and the second network device is a boundary device in the network indicated by the routing prefix.

[0279] Optionally, the second TLV field is used to indicate the first encrypted network topology to which one or more network devices belong, and the identifier of one or more network devices within the first encrypted network topology. The one or more network devices are devices in the first encrypted network topology that need to establish an encrypted connection with the second network device, and the second network device is a boundary device in the network indicated by the routing prefix.

[0280] Optionally, the second TLV field includes multiple bits, one of which is used to refer to at least one network device within the first encrypted network topology, and the one or more network devices correspond to one or more bits with a preset bit state among the multiple bits.

[0281] Optionally, the first TLV field includes the router identifier of the second network device, which is a border device in the network indicated by the routing prefix; the generation unit 1702 is further configured to generate at least one key based on the router identifier of the second network device and the router identifier of the first network device; wherein the router identifier of the second network device and the router identifier of the first network device are both unique identifiers.

[0282] Optionally, the generation unit 1702 is further configured to: generate a first security parameter index based on a first TLV field and local parameters, the first security parameter index being used to indicate an encrypted connection between a network device and a second network device, the local parameters including a random number and / or the identifier of the first network device, the second network device being a border device in the network indicated by the routing prefix; if the first security parameter index is the same as other security parameter indices already generated in the network device, then update the local parameters and generate a second security parameter index based on the first TLV field and the updated local parameters; the sending unit 1703 is further configured to send the updated local parameters to the second network device.

[0283] Optionally, the first TLV field may also include quantum key parameters.

[0284] Optionally, the generation unit 1702 is further configured to generate second encrypted extension information, which includes second parameters for generating a key and information about a second encrypted network topology. The information about the second encrypted network topology is used to indicate the multiple network devices constituting the second encrypted network topology and to indicate that encrypted connections are allowed between the multiple network devices in the second encrypted network topology. The first network device replaces the first encrypted extension information in the first routing advertisement message with the second encrypted extension information to obtain a second routing advertisement message. The sending unit 1703 is further configured to send the second routing advertisement message to neighboring devices.

[0285] Please see Figure 18 , Figure 18 This is a schematic diagram of the structure of a network device 1800 provided in an embodiment of this application. Figure 18 The network device 1800 shown is, for example, the one described above. Figure 3 as well as Figure 10 The second network device in the corresponding embodiment, or the one described above Figure 13 The transmitting-side device in the corresponding embodiment.

[0286] like Figure 18 As shown, network device 1800 includes: an acquisition unit 1801, used to acquire service-related encrypted information, the encrypted information being used to indicate the object of the service encryption application; a generation unit 1802, used to generate a routing advertisement message based on the encrypted information, the routing advertisement message including a routing prefix and encrypted extension information related to the routing prefix, the encrypted extension information including parameters for generating a key; and a sending unit 1803, used to send the routing advertisement message to neighboring devices.

[0287] Optionally, the objects of the business encryption application include address families or VPN instances that need to establish encrypted connections; the generation unit 1802 is also used to generate a route advertisement message based on the network prefix that the route prefix belongs to in the address family or VPN instance, wherein the network device is a border device in the network indicated by the route prefix.

[0288] Optionally, the objects of the business encryption application include routing policies, which are used to indicate network devices that need to establish encrypted connections; the generation unit 1802 is also used to generate routing announcement messages based on the fact that the network device belongs to the network device indicated in the routing policy.

[0289] Please refer to Figure 19 , Figure 19 This is a schematic diagram of the structure of a network device 1900 provided in an embodiment of this application. Figure 19 The network device 1900 shown can be used to perform the steps performed by any one of the first network device, second network device, transmitting device or receiving device described in the above embodiments. Figure 19 Although the network device 1900 shown has certain specific features, those skilled in the art will realize from the embodiments of this application that, for the sake of brevity, Figure 19 Various other features are not shown to avoid obscuring more relevant aspects of the implementation methods disclosed in this application. Therefore, as an example, in some implementations, network device 1900 includes one or more processors (e.g., CPU) 1901, a network interface 1902, a programming interface 1903, a memory 1904, and one or more communication buses 1905 for interconnecting various components. In other implementations, network device 1900 may omit or add some functional components or units based on the above examples.

[0290] In some implementations, network interface 1902 is used to connect to one or more other network devices / servers in a network system. In some implementations, communication bus 1905 includes circuitry for interconnecting and controlling communication between system components. Memory 1904 may include non-volatile memory, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Memory 1904 may also include volatile memory, which may be random access memory (RAM) used as an external cache.

[0291] In some implementations, the non-transitory computer-readable storage medium of memory 1904 stores programs, modules, and data structures, or subsets thereof, including, for example, an acquisition unit (not shown), a transmission unit (not shown), and a processing unit 19041.

[0292] In one possible embodiment, the network device 1900 may have the above-described features. Figure 3 Any function in the network device in the corresponding method embodiment.

[0293] It should be understood that network device 1900 corresponds to the first network device in the above method embodiments. The modules in network device 1900 and the other operations and / or functions described above are various steps and methods implemented by the first network device in the above method embodiments. For specific details, please refer to the above... Figure 3 For the sake of brevity, the corresponding method implementations will not be described in detail here.

[0294] It should be understood that the data transmission and reception operations in this application can be performed by the network interface 1902 on the network device 1900, or the processor can call the program code in the memory and cooperate with the network interface 1902 to realize the function of the transceiver unit when needed.

[0295] In various implementations, the network device 1900 is used to execute the encrypted information distribution method provided in the embodiments of this application, such as executing the above-described method. Figure 3 The illustrated embodiment corresponds to the method for distributing encrypted information.

[0296] This application Figure 19 The specific structure of the network device can be as follows: Figure 20 As shown.

[0297] Figure 20 This is a schematic diagram of the structure of a network device 2000 provided in an embodiment of this application. Figure 20 The network device 2000 shown can be used to perform the steps executed by any one of the first network device, second network device, transmitting-side device, or receiving-side device described in the above embodiments. The network device 2000 includes a main control board 2020 and an interface board 2030.

[0298] The main control board 2020, also known as the main processing unit (MPU) or route processor, is used to control and manage the various components in the network device 2000, including route calculation, device management, device maintenance, and protocol processing functions. The main control board 2020 includes a central processing unit 2011 and a memory 2012.

[0299] The interface board 2030, also known as a line processing unit (LPU), linecard, or service board, provides various service interfaces and enables packet forwarding. Service interfaces include, but are not limited to, Ethernet interfaces and POS (Packet over SONET / SDH) interfaces. The interface board 2030 includes: a central processing unit 2031, a network processor 2032, a physical interface card (PIC) 2033, and a forwarding table entry memory 2034.

[0300] The central processing unit 2031 on the interface board 2030 is used to control and manage the interface board 2030 and communicate with the central processing unit 2011 on the main control board 2020.

[0301] The network processor 2032 is used to implement packet forwarding. The network processor 2032 can be in the form of a forwarding chip.

[0302] The physical interface card 2033 is used to implement physical layer interfacing functions. Raw traffic enters the interface board 2030 through this card, and processed packets are sent out from the physical interface card 2033. The physical interface card 2033 includes at least one physical interface, also called a physical port, which can be a Flexible Ethernet (FlexE) physical interface. In some embodiments, the central processing unit 2031 of the interface board 2030 can also perform the functions of the network processor 2032, such as implementing software forwarding based on a general-purpose CPU, thus eliminating the need for the network processor 2032 in the interface board 2030.

[0303] Optionally, the network device 2000 includes multiple interface boards. For example, the network device 2000 also includes an interface board 2040, which includes a central processing unit 2041, a network processor 2042, a physical interface card 2043, and a forwarding table entry memory 2044.

[0304] Optionally, network device 2000 also includes a switching fabric board 2020. The switching fabric board 2020 can also be called a switch fabric unit (SFU). In cases where the network device has multiple interface boards 2030, the switching fabric board 2020 is used for data exchange between the interface boards. For example, interface boards 2030 and 2040 can communicate via the switching fabric board 2020.

[0305] The main control board 2020 and the interface board are coupled. For example, the main control board 2020, interface boards 2030 and 2040, and the switching network board 2020 are interconnected via a system bus and / or a system backplane. In one possible implementation, an inter-process communication (IPC) channel is established between the main control board 2020 and the interface board 2030, and the main control board 2020 and the interface board 2030 communicate with each other through the IPC channel.

[0306] Logically, network device 2000 includes a control plane and a forwarding plane. The control plane includes a main control board 2020 and a central processing unit 2031, while the forwarding plane includes various components that perform forwarding, such as a forwarding table entry memory 2034, a physical interface card 2033, and a network processor 2032. The control plane performs functions such as publishing routes, generating forwarding tables, processing signaling and protocol messages, and configuring and maintaining the device's status. The control plane distributes the generated forwarding tables to the forwarding plane. In the forwarding plane, the network processor 2032 forwards messages received by the physical interface card 2033 based on the forwarding tables distributed by the control plane. The forwarding tables distributed by the control plane can be stored in the forwarding table entry memory 2034. In some embodiments, the control plane and the forwarding plane can be completely separated and not on the same device.

[0307] It should be understood that the operation on interface board 2040 in this embodiment is consistent with the operation on interface board 2030, and will not be described again for the sake of simplicity. It should be understood that the network device 2000 in this embodiment can correspond to the first network device in the above-described method embodiments. The main control board 2020, interface board 2030 and / or interface board 2040 in the network device 2000 can implement the functions and / or various steps implemented by the first network device in the above-described method embodiments, and will not be described again for the sake of simplicity.

[0308] It's worth noting that a network device may have one or more main control boards, including a primary and a backup main control board. It may also have one or more interface boards; the stronger the network device's data processing capabilities, the more interface boards it provides. Each interface board may also have one or more physical interface cards. A switching board may or may not exist; multiple switching boards can share load and provide redundancy. In a centralized forwarding architecture, the network device may not need a switching board, with the interface boards handling the entire system's business data processing. In a distributed forwarding architecture, the network device can have at least one switching board, enabling data exchange between multiple interface boards and providing high-capacity data exchange and processing capabilities. Optionally, the network device can also consist of only one board, without a switching board, integrating the functions of the interface boards and the main control board onto this single board. In this case, the central processing unit (CPU) on the interface board and the CPU on the main control board can be combined into a single CPU, executing the combined functions of both. The specific architecture adopted depends on the specific network deployment scenario and is not a single, definitive choice.

[0309] It should be understood that the network devices of the various product forms described above have any of the functions of the first network device and the second network device in the above method embodiments, which will not be elaborated here.

[0310] Furthermore, embodiments of this application also provide a computer program product that, when run on a network device, causes the network device to perform the aforementioned... Figure 3 The method executed by any network device in the corresponding method embodiment.

[0311] This application also provides a chip system, including a processor and an interface circuit. The interface circuit is used to receive instructions and transmit them to the processor. The processor is used to implement the methods in any of the above method embodiments.

[0312] Optionally, the chip system also includes a memory, and the chip system can have one or more processors. The processor can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor that implements the methods in any of the above method embodiments by reading software code stored in the memory.

[0313] Optionally, the chip system may contain one or more memories. These memories may be integrated with the processor or separated from it; this application does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed on different chips. This application does not specifically limit the type of memory or the arrangement of the memory and processor.

[0314] The embodiments of this application have been described in detail above. The steps in the method of the embodiments of this application can be scheduled, merged or deleted in sequence according to actual needs; the modules in the device of the embodiments of this application can be divided, merged or deleted according to actual needs.

[0315] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0316] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0317] It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0318] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0319] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0320] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

Claims

1. A method for distributing encrypted information, characterized in that, include: A first network device receives a first routing advertisement message, the first routing advertisement message including a routing prefix and first encrypted extension information related to the routing prefix, the first encrypted extension information including a first parameter for generating a key; The first network device generates at least one key based on the first encryption extension information, wherein the at least one key is used to encrypt data packets from the first network device to the network indicated by the routing prefix and / or decrypt data packets from the network indicated by the routing prefix to the first network device; The first network device generates a routing table entry with encryption attributes based on the first routing advertisement message. The routing table entry includes the routing prefix and is used to indicate the outgoing interface on the first network device that leads to the network indicated by the routing prefix and to indicate that the data packet is encrypted with the at least one key before forwarding the data packet whose destination address belongs to the network indicated by the routing prefix.

2. The method according to claim 1, characterized in that, The first encrypted extension information is carried in the first type length value (TLV) field in the first routing advertisement message, and the first TLV field includes a first parameter for generating a key.

3. The method according to claim 2, characterized in that, The first encrypted extension information also includes information for indicating a first encrypted network topology, wherein the information of the first encrypted network topology is used to indicate a plurality of network devices constituting the first encrypted network topology, and to indicate that encrypted connections are permitted between the plurality of network devices.

4. The method according to claim 3, characterized in that, The first encrypted extension information is also carried in the second TLV field of the first routing advertisement message, and the second TLV field is used to indicate the information of the first encrypted network topology.

5. The method according to claim 4, characterized in that, The first route advertisement message is a Border Gateway Protocol (BGP) message or an Interior Gateway Protocol (IGP) message.

6. The method according to claim 5, characterized in that, The first route advertisement message is a BGP update message; The first TLV field and the second TLV field are carried in the extended path attribute field of the BGP update message.

7. The method according to claim 5, characterized in that, The first route advertisement message is an Open Shortest Path First (OSPF) message; The first TLV field and the second TLV field are carried in the Link State Advertisement sub-TLV field of the OSPF message.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: When the first network device obtains a target packet, if the destination address of the target packet matches the routing prefix in the routing table entry, the first network device encrypts the target packet using the at least one key based on the indication of the routing table entry.

9. The method according to claim 8, characterized in that, The method further includes: If there is an established tunnel between the first network device and the second network device, the first network device sends the encrypted target message based on the established tunnel, and the second network device is a border device in the network indicated by the routing prefix; If there is no existing tunnel between the first network device and the second network device, the first network device creates a new tunnel with the second network device and sends the encrypted target message based on the newly created tunnel.

10. The method according to claim 9, characterized in that, The first encrypted extension information also includes the Internet Protocol (IP) address of the second network device; The first network device creates a new tunnel with the second network device, including: The first network device creates an IP-in-IP tunnel with the second network device based on the IP address of the second network device and the IP address of the first network device.

11. The method according to any one of claims 3-7, characterized in that, The first TLV field includes the identifier of one or more network devices, which are devices in the first encrypted network topology that need to establish an encrypted connection with the second network device, and the second network device is a boundary device in the network indicated by the routing prefix.

12. The method according to any one of claims 4-7, characterized in that, The second TLV field is used to indicate the first encrypted network topology to which one or more network devices belong, and the identifier of the one or more network devices within the first encrypted network topology. The one or more network devices are devices in the first encrypted network topology that need to establish an encrypted connection with the second network device, and the second network device is a border device in the network indicated by the routing prefix.

13. The method according to claim 12, characterized in that, The second TLV field includes multiple bits, one of which is used to refer to at least one network device within the first encrypted network topology, and the one or more network devices correspond to one or more bits with a preset bit state among the multiple bits.

14. The method according to any one of claims 2-7, characterized in that, The first TLV field includes the router identifier of the second network device, which is a border device in the network indicated by the routing prefix; The first network device generates at least one key based on the first encryption extension information, including: The first network device generates the at least one key based on the router identifier of the second network device and the router identifier of the first network device; Both the router identifier of the second network device and the router identifier of the first network device are unique identifiers.

15. The method according to any one of claims 2-7, characterized in that, The method further includes: The first network device generates a first security parameter index based on the first TLV field and local parameters. The first security parameter index is used to indicate the encrypted connection between the first network device and the second network device. The local parameters include a random number and / or the identifier of the first network device. The second network device is a border device in the network indicated by the routing prefix. If the first security parameter index is the same as other security parameter indexes already generated in the first network device, the first network device updates the local parameter and generates a second security parameter index based on the first TLV field and the updated local parameter. The first network device sends the updated local parameters to the second network device.

16. The method according to any one of claims 2-7, characterized in that, The first TLV field also includes quantum key parameters.

17. The method according to any one of claims 1-7, characterized in that, The method further includes: The first network device generates second encryption extension information, which includes a second parameter for generating a key and information about a second encrypted network topology. The information about the second encrypted network topology is used to indicate the multiple network devices constituting the second encrypted network topology and to indicate that encrypted connections are allowed between the multiple network devices in the second encrypted network topology. The first network device replaces the first encryption extension information in the first routing advertisement message with the second encryption extension information to obtain a second routing advertisement message. The first network device sends the second routing advertisement message to its neighboring devices.

18. A method for distributing encrypted information, characterized in that, include: The second network device obtains encrypted information related to the service, and the encrypted information is used to indicate the object of the service encryption application. The second network device generates a route advertisement message based on the encrypted information. The route advertisement message includes a route prefix and encrypted extension information related to the route prefix. The encrypted extension information includes parameters for generating a key. The second network device sends the routing advertisement message to the neighboring device, so that the neighboring device generates a routing table entry with encryption attributes based on the routing advertisement message. The routing table entry includes the routing prefix and is used to indicate the outgoing interface on the neighboring device to the network indicated by the routing prefix and to indicate that the data packet is encrypted with at least one key before forwarding the data packet whose destination address belongs to the network indicated by the routing prefix.

19. The method according to claim 18, characterized in that, The objects of the business encryption application include address families or virtual private network (VPN) instances that require the establishment of encrypted connections. The second network device generates a routing announcement message based on the encrypted information, including: Based on the fact that the routing prefix belongs to the address family or the network prefix in the VPN instance, the second network device generates the routing advertisement message, and the second network device is a border device in the network indicated by the routing prefix.

20. The method according to claim 18, characterized in that, The objects of the business encryption application include routing policies, which are used to indicate network devices that need to establish encrypted connections. The second network device generates a routing announcement message based on the encrypted information, including: Based on the fact that the second network device belongs to the network device indicated in the routing policy, the second network device generates the routing announcement message.

21. A network device, characterized in that, include: A receiving unit is configured to receive a first route advertisement message, the first route advertisement message including a route prefix and first encrypted extension information related to the route prefix, the first encrypted extension information including a first parameter for generating a key; A generation unit is configured to generate at least one key based on the first encryption extension information, wherein the at least one key is used to encrypt data packets from the network device to the network indicated by the routing prefix and / or decrypt data packets from the network indicated by the routing prefix to the network device; The generating unit is further configured to generate a routing table entry with encryption attributes based on the first routing advertisement message. The routing table entry includes the routing prefix and is used to indicate the outgoing interface on the network device leading to the network indicated by the routing prefix and to indicate that the data packet is encrypted with the at least one key before forwarding the data packet whose destination address belongs to the network indicated by the routing prefix.

22. The network device according to claim 21, characterized in that, The first encrypted extension information is carried in the first type length value (TLV) field in the first routing advertisement message, and the first TLV field includes a first parameter for generating a key.

23. The network device according to claim 22, characterized in that, The first encrypted extension information further includes information for indicating a first encrypted network topology, wherein the information of the first encrypted network topology is used to indicate a plurality of network devices constituting the first encrypted network topology, and to indicate that encrypted connections are allowed to be established between the plurality of network devices. The first encrypted extension information is also carried in the second TLV field of the first routing advertisement message, and the second TLV field is used to indicate the information of the first encrypted network topology.

24. The network device according to claim 23, characterized in that, The first route advertisement message is a BGP message or an IGP message.

25. The network device according to claim 24, characterized in that, The first route advertisement message is a BGP update message; The first TLV field and the second TLV field are carried in the extended path attribute field of the BGP update message.

26. The network device according to claim 24, characterized in that, The first route advertisement message is an OSPF message; The first TLV field and the second TLV field are carried in the Link State Advertisement sub-TLV field of the OSPF message.

27. The network device according to any one of claims 21-26, characterized in that, When the network device obtains a target packet, if the destination address of the target packet matches the routing prefix in the routing table entry, the generating unit is further configured to encrypt the target packet using the at least one key based on the indication of the routing table entry.

28. A network device, characterized in that, include: An acquisition unit is used to acquire business-related encrypted information, wherein the encrypted information is used to indicate the object of the business encryption application; The generation unit generates a route advertisement message based on the encrypted information. The route advertisement message includes a route prefix and encrypted extension information related to the route prefix. The encrypted extension information includes parameters for generating a key. A sending unit is configured to send the routing advertisement message to a neighboring device, so that the neighboring device generates a routing table entry with encryption attributes based on the routing advertisement message. The routing table entry includes the routing prefix and is used to indicate the outgoing interface on the neighboring device that leads to the network indicated by the routing prefix and to indicate that the data packet is encrypted with at least one key before forwarding the data packet whose destination address belongs to the network indicated by the routing prefix.

29. The network device according to claim 28, characterized in that, The objects of the business encryption application include address families or VPN instances that require the establishment of encrypted connections; The network device generates a routing announcement message based on the encrypted information, including: Based on the fact that the routing prefix belongs to the address family or the network prefix in the VPN instance, the network device generates the routing advertisement message, and the network device is a border device in the network indicated by the routing prefix.

30. A network device comprising a processor and a memory, the memory for storing program code, the processor for calling the program code in the memory to cause the network device to perform the method as claimed in any one of claims 1-20.

31. A network system comprising the network device as described in any one of claims 21-27 and the network device as described in any one of claims 28-29.

32. A computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-20.

Images