CN116192633A

CN116192633A - Remote certification application method, device, equipment, system and storage medium

Info

Publication number: CN116192633A
Application number: CN202111436561.2A
Authority: CN
Inventors: 吴迪; 张轶炯; 曹斌
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-11-29
Filing date: 2021-11-29
Publication date: 2023-05-30
Also published as: WO2023092951A1

Abstract

The application discloses a remote certification application method, a device, equipment, a system and a storage medium, and belongs to the technical field of communication. The method comprises the following steps: the first network element equipment acquires a remote proving result corresponding to the second network element equipment. The remote proving result is used for indicating the trusted state of the second network element equipment, and the trusted state of the second network element equipment comprises trusted state, untrusted state or unknown state. And then, the first network element equipment carries out route management on the second network element equipment based on the trusted state of the second network element equipment indicated by the remote proving result. After the remote proving result is obtained, the remote proving result is applied to the management process of the second network element equipment, so that the remote proving result can be reflected on the routing function of the second network element equipment. Because the remote proving result is used for indicating the trusted state of the second network element equipment, the management of the second network element equipment by applying the remote proving result improves the reliability of the management.

Description

Remote certification application method, device, equipment, system and storage medium

Technical Field

The present disclosure relates to the field of communications technologies, and in particular, to an application method, apparatus, device, system, and storage medium for remote attestation.

Background

In the field of communication technology, the remote attestation (remote attestation, RA) procedure is a procedure for performing a trusted measurement on a network element device based on measurement information corresponding to the network element device. The RA result is used for indicating the trusted state of the network element equipment. Therefore, the RA result can be applied to management of the network element device, thereby improving the reliability of management.

Disclosure of Invention

The application method, device, equipment, system and storage medium for remote certification are provided to apply RA results to management of network element equipment, so that reliability of management is improved.

In a first aspect, there is provided a method of applying remote attestation, the method comprising:

the first network element equipment firstly acquires a remote proving result corresponding to the second network element equipment. The remote proving result is used for indicating the trusted state of the second network element equipment, and the trusted state of the second network element equipment comprises trusted state, untrusted state or unknown state. And then, the first network element equipment carries out route management on the second network element equipment based on the trusted state of the second network element equipment indicated by the remote proving result.

After the remote proving result is obtained, the remote proving result is applied to the management process of the second network element equipment, so that the remote proving result can be reflected on the routing function of the second network element equipment. Because the remote proving result is used for indicating the trusted state of the second network element equipment, the management of the second network element equipment by using the remote proving result improves the reliability of management, thereby ensuring the security of the network architecture containing the second network element equipment and the security of communication based on the second network element equipment.

In one possible implementation manner, the first network element device performs route management on the second network element device based on the trusted status of the second network element device indicated by the remote attestation result, including: the first network element equipment acquires the routing information corresponding to the second network element equipment; the first network element device manages routing information corresponding to the second network element device according to configured rules based on the trusted state of the second network element device.

The route information corresponding to the second network element equipment is managed according to the configured rule, so that the first network element equipment can automatically realize the route management of the second network element equipment, and the reliability is higher.

In one possible implementation manner, the configured rule includes a route management policy, and the first network element device manages route information corresponding to the second network element device according to the configured rule based on a trusted state of the second network element device, including: the first network element equipment determines a target strategy matched with the trusted state of the second network element equipment from the route management strategy; and the first network element equipment manages the route information corresponding to the second network element equipment according to the target strategy.

The route management strategy is configured as a rule, and the flexibility of management based on the rule is high.

In one possible implementation manner, the routing information corresponding to the second network element device includes at least one of first routing information, second routing information, third routing information and fourth routing information, where the first routing information is routing information that needs to be issued by the second network element device, the second routing information is routing information that has been issued by the second network element device, the third routing information is routing information that needs to be received by the second network element device, and the fourth routing information is routing information that has been received by the second network element device; the target policy includes at least one policy of a policy corresponding to the first routing information, a policy corresponding to the second routing information, a policy corresponding to the third routing information, and a policy corresponding to the fourth routing information.

Based on the route management strategy, various route information can be managed, and each route information corresponds to different strategies respectively, so that the method is fine and flexible.

In one possible implementation, the trusted state of the second network element device is that the second network element device is trusted; the strategy corresponding to the first route information is used for indicating to issue the first route information; the strategy corresponding to the second routing information is used for indicating to maintain the second routing information; the strategy corresponding to the third routing information is used for indicating to issue the third routing information to the second network element equipment; the policy corresponding to the fourth routing information is used to indicate that the fourth routing information is maintained.

And under the condition that the second network element equipment is credible, the second network element equipment can normally send and receive the route information, so that the probability of the traffic passing through the credible second network element equipment is highest.

In one possible implementation, the trusted state of the second network element device is that the second network element device is not trusted; the strategy corresponding to the first route information is used for indicating that the first route information is not issued; the strategy corresponding to the second routing information is used for indicating to cancel the second routing information; the strategy corresponding to the third routing information is used for indicating that the third routing information is not issued to the second network element equipment; the policy corresponding to the fourth routing information is used for indicating to withdraw the fourth routing information.

And under the condition that the second network element equipment is not trusted, the second network element equipment cannot normally send and receive the routing information, so that the probability that the traffic passes through the untrusted second network element equipment is minimized.

In one possible implementation, the trusted state of the second network element device is that the state of the second network element device is unknown; the strategy corresponding to the first routing information is used for indicating to release the first routing information and a first priority index, the first priority index is used for indicating the priority of the first routing information, and the priority of the first routing information is lower than the default priority; the strategy corresponding to the second routing information is used for indicating to release the second routing information and a second priority index, the second priority index is used for indicating the priority of the second routing information released at this time, and the priority of the second routing information released at this time is lower than the default priority and lower than the priority of the second routing information released last time; the strategy corresponding to the third routing information is used for indicating to issue the third routing information to the second network element equipment; the policy corresponding to the fourth routing information is used to indicate that the fourth routing information is maintained.

In the case that the state of the second network element device is unknown, the second network element device can send and receive the routing information, but needs to reduce the priority of the routing information, so that the probability that the traffic passes through the second network element device with unknown state is between the highest probability and the lowest probability. The reliability degree of the three trusted states of the second network element equipment, the state of the second network element equipment is unknown and the second network element equipment is not trusted is sequentially reduced, and based on the above description, it can be seen that the probability that the flow passes through the second network element equipment in the three trusted states is also sequentially reduced. Thus, the present application enables: the lower the degree of trust of the second network element device, the lower the probability that the traffic passes through the second network element device.

In one possible implementation, the configured rule includes executable code, where the executable code is configured to configure, for route information corresponding to the second network element device, a priority indicator that matches a trusted state of the second network element device, and the first network element device manages, based on the trusted state of the second network element device, the route information corresponding to the second network element device according to the configured rule, including: the first network element equipment configures a third priority index for the routing information corresponding to the second network element equipment by running an executable code, wherein the third priority index is a priority index matched with the trusted state of the second network element equipment and is used for indicating the priority of the routing information corresponding to the second network element equipment; the first network element device issues routing information and a third priority index corresponding to the second network element device.

Wherein the executable code is configured as a rule, and the configuration process requires less effort.

In one possible implementation manner, the routing information corresponding to the second network element device includes at least one of first routing information and second routing information, where the first routing information is routing information that needs to be issued by the second network element device, the second routing information is routing information that has been issued by the second network element device, the third priority index includes at least one index of a priority index corresponding to the first routing information and a priority index corresponding to the second routing information, the priority index corresponding to the first routing information is used to indicate a priority of the first routing information, and the priority index corresponding to the second routing information is used to indicate a priority of the second routing information.

Based on the executable code, a plurality of routing information can be managed, and each routing information corresponds to a different priority.

In one possible implementation, the trusted state of the second network element device is that the second network element device is trusted; the priority of the first routing information and the priority of the second routing information are not lower than the default priority.

In one possible implementation, the trusted state of the second network element device is that the second network element device is not trusted; the priority of the first routing information and the priority of the second routing information are both lower than the default priority.

In one possible implementation, the trusted state of the second network element device is that the state of the second network element device is unknown; the priority of the first routing information and the priority of the second routing information are both lower than the default priority and higher than the priority in case the second network element device is not trusted.

The reliability of the three trusted states of the second network element equipment, the state of the second network element equipment is unknown and the second network element equipment is not trusted is sequentially reduced. It can be seen that, for the case that the second network element device with the highest reliability is trusted, the priority of the routing information corresponding to the second network element device is highest. And for the condition that the state of the second network element equipment with the second highest reliability is unknown, the priority of the routing information corresponding to the second network element equipment is high. And for the case that the second network element equipment with the lowest credibility is not credible, the priority of the routing information corresponding to the second network element equipment is lowest. Therefore, in the routing process, the trusted second network element equipment is preferentially selected, the second network element equipment with unknown state is selected, the untrusted second network element equipment is selected again, the selection probability is sequentially reduced, and the probability of selecting the second network element equipment influences the probability of the flow passing through the second network element equipment. Thereby, the lower the degree of reliability of the second network element device is, the lower the probability that the flow passes through the second network element device is.

In one possible implementation, the priority indicator is a BGP attribute, and the priority indicator includes a local priority or a multi-exit discriminator, where the greater the value of the local priority, the higher the priority indicated by the local priority, and the smaller the value of the multi-exit discriminator, the higher the priority indicated by the multi-exit discriminator.

In one possible implementation manner, the obtaining, by the first network element device, a remote attestation result corresponding to the second network element device includes: the method comprises the steps that a first network element device reads a remote proof result acquisition command, wherein the remote proof result acquisition command is used for indicating an acquisition path of a remote proof result; the first network element device acquires the remote certification result according to the acquisition path indicated by the remote certification result acquisition command.

In one possible implementation manner, the first network element device has a route reflection function, and BGP connection for performing route reflection is established between the first network element device and the second network element device.

Multiplexing the first network element equipment with the route reflection function to execute the method, and directly using BGP connection without additionally arranging other network element equipment between the first network element equipment and the second network element equipment and additionally establishing connection between the first network element equipment and the second network element equipment. Therefore, the cost of the application process of remote certification is saved, and the efficiency of the application process of remote certification is improved.

In a second aspect, there is provided an application apparatus for remote attestation, the apparatus comprising:

the acquisition module is used for acquiring a remote proving result corresponding to the second network element equipment, wherein the remote proving result is used for indicating the trusted state of the second network element equipment, and the trusted state of the second network element equipment comprises trusted state, untrusted state or unknown state;

and the management module is used for carrying out route management on the second network element equipment based on the trusted state of the second network element equipment indicated by the remote proving result.

In one possible implementation manner, the management module is configured to obtain routing information corresponding to the second network element device; and managing the routing information corresponding to the second network element equipment according to the configured rule based on the trusted state of the second network element equipment.

In one possible implementation, the configured rule includes a route management policy, and the management module is configured to determine a target policy matching the trusted state of the second network element device from the route management policy; and managing the route information corresponding to the second network element equipment according to the target strategy.

In one possible implementation manner, the configured rule includes executable code, the executable code is used for configuring a priority index matched with a trusted state of the second network element device for the routing information corresponding to the second network element device, and the management module is used for configuring a third priority index for the routing information corresponding to the second network element device by running the executable code, wherein the third priority index is a priority index matched with the trusted state of the second network element device, and the third priority index is used for indicating the priority of the routing information corresponding to the second network element device; the first network element device issues routing information and a third priority index corresponding to the second network element device.

In one possible implementation, the priority indicator is a border gateway protocol BGP attribute, and the priority indicator includes a local priority or a multi-exit discriminator, where the greater the value of the local priority, the higher the priority indicated by the local priority, and the smaller the value of the multi-exit discriminator, the higher the priority indicated by the multi-exit discriminator.

In one possible implementation, the obtaining module is configured to read a remote proof result obtaining command, where the remote proof result obtaining command is configured to indicate an obtaining path of the remote proof result; and acquiring the remote proving result according to the acquisition path indicated by the remote proving result acquisition command.

In one possible implementation manner, the application device of remote attestation is applied to a first network element device, the first network element device has a route reflection function, and BGP connection for performing route reflection is established between the first network element device and a second network element device.

In a third aspect, an application device for remote attestation is provided, the device comprising a memory and a processor; at least one instruction stored in the memory is loaded and executed by the processor to cause the remotely certified application device to implement the method of the first aspect or any of the possible implementations of the first aspect.

In a fourth aspect, there is provided an application device for remote attestation, the device comprising: network interface, memory, and processor. Wherein the network interface, the memory and the processor communicate with each other through an internal connection path. The network interface is used for sending or receiving messages according to the control of the processor. The memory is for storing instructions that, when executed by the processor, cause the apparatus to perform the method of the first aspect or any one of the possible implementations of the first aspect.

Optionally, the processor is one or more and the memory is one or more.

Alternatively, the memory may be integrated with the processor or the memory may be separate from the processor.

In a specific implementation process, the memory may be a non-transient (non-transitory) memory, for example, a Read Only Memory (ROM), which may be integrated on the same chip as the processor, or may be separately disposed on different chips, where the type of the memory and the manner of disposing the memory and the processor are not limited in this application.

In a fifth aspect, there is provided an application system for remote attestation, the system comprising a first network element device and at least one second network element device, the first network element device being communicatively connected to the at least one second network element device, the first network element device being adapted to perform the method of the first aspect or any of the possible implementations of the first aspect.

In a sixth aspect, there is provided a computer program (product) comprising: computer program code which, when run by a computer, causes the computer to perform the methods of the above aspects.

In a seventh aspect, there is provided a computer readable storage medium storing a program or instructions which, when run on a computer, perform the method of the above aspects.

In an eighth aspect, there is provided a chip comprising a processor for calling from a memory and executing instructions stored in the memory, to cause a chip-mounted communication device to perform the method of the above aspects.

In a ninth aspect, there is provided another chip comprising: the input interface, the output interface, the processor and the memory are connected through an internal connection path, the processor is used for executing codes in the memory, and when the codes are executed, the processor is used for executing the method in each aspect.

Drawings

FIG. 1 is a schematic diagram of an implementation environment provided by an embodiment of the present application;

fig. 2 is a schematic structural diagram of a second network element device provided in an embodiment of the present application;

FIG. 3 is a flowchart of an application method of remote attestation provided in an embodiment of the present application;

fig. 4 is a schematic flow chart of an RA result applied in the related art according to an embodiment of the present application;

fig. 5 is a schematic flow chart of managing routing information according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a BGP message for route publishing according to an embodiment of the present application;

Fig. 7 is a schematic structural diagram of a BGP message for performing route withdrawal according to an embodiment of the present application;

fig. 8 is a schematic flow chart of a selection sequence of routing information according to an embodiment of the present application;

FIG. 9 is a flow chart of a method for remote attestation provided in an embodiment of the present application;

fig. 10 is a schematic structural diagram of a BGP header according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of an update type BGP message according to an embodiment of the present application;

FIG. 12 is a flow chart of a method for remote attestation provided in an embodiment of the present application;

fig. 13 is a schematic structural diagram of an open BGP message according to an embodiment of the present application;

FIG. 14 is a flow chart of a method for remote attestation provided in an embodiment of the present application;

FIG. 15 is a schematic structural diagram of a remote proven application device according to an embodiment of the present application;

fig. 16 is a schematic structural diagram of an application device for remote certification according to an embodiment of the present application.

Detailed Description

The terminology used in the description section of the present application is for the purpose of describing particular embodiments of the present application only and is not intended to be limiting of the present application.

In the communication process between different network element devices, the communication safety problem is particularly important, and the use of the network element devices in a trusted state in the communication process is a key for solving the communication safety problem. In this regard, a trusted computing group (trusted computing group, TCG) has motivated and developed a technique known as trusted computing, one of which includes an RA procedure for verifying the trusted status of network element devices. In the RA procedure, the two network element devices are respectively an RA client (client) and an RA server (server), the network element device serving as the RA client is a network element device that needs to be verified whether to be in a trusted state, and the network element device serving as the RA server is a trusted network element device (also referred to as a trusted root) for performing verification. The network element device acting as RA client generates and sends the metric information to the network element device acting as RA server. The network element device serving as the RA server verifies whether the network element device serving as the RA client is in a trusted state according to the received measurement information, so that an RA result is obtained, and the RA result is used for indicating the trusted state of the network element device serving as the RA client.

It is because the RA result is used to indicate the trusted status of the network element device as the RA client, the RA result may be applied to the management of the network element device as the RA client to improve the reliability of the management. Therefore, the embodiment of the application provides a remote proving application method. The method can be applied in the implementation environment shown in fig. 1.

In fig. 1, a first network element device 11 and at least one second network element device 12 are included (fig. 1 only illustrates 3 second network element devices 12 as an example), and the first network element device 11 and the second network element device 12 are communicatively connected. The first network element device 11 is configured to obtain an RA result corresponding to the second network element device, where the RA result is used to indicate a trusted state of the second network element device. The first network element device 11 is then configured to perform route management on the second network element device 12 based on the trusted status indicated by the RA result corresponding to the second network element device. Illustratively, the number of second network element devices 12 is at least one.

Illustratively, the first network element device 11 obtains the RA result corresponding to the second network element device from a local or other network element device except the local. In response to the first network element device 11 serving as an RA server, the manner in which the first network element device 11 obtains the RA result corresponding to the second network element device includes, but is not limited to: the first network element device 11 obtains the RA result locally or from a network element device in which the RA result is stored. Alternatively, in response to the first network element device 11 not being used as an RA server, the manner in which the first network element device 11 obtains the RA result corresponding to the second network element device includes, but is not limited to: the first network element device 11 acquires the RA result from the network element device for serving as the RA server or from the network element device storing the RA result. In some embodiments, the network element device storing RA results includes a device that provides a database service or shares a storage service, and so on.

In some embodiments, the first network element device 11 has a Route Reflection (RR) function, and a border gateway protocol (border gateway protocol, BGP) connection for performing route reflection is respectively established between the first network element device 11 and other network element devices including the second network element device 12. The manner in which the first network element device 11 performs route management on the second network element device 12 includes, but is not limited to: the first network element device 11 transmits BGP messages. The first network element device 11 with RR functionality is illustratively a route reflector. In the route reflection process, the second network element device 12 sends the route to be issued to the first network element device 11 with RR function through BGP connection, and other network element devices send the route to be issued to the first network element device 11 through BGP connection. The first network element device 11 selects a proper route through route learning and processing, and reflects the proper route to all network element devices which are connected with the first network element device 11 by BGP, so that route transfer is realized without forming full connection, network overhead is reduced, and network expandability is improved. The first network element device 11, the second network element device 12, and other network element devices are located in the same autonomous system (autonomous system, AS) domain or security domain, and the full connection refers to that any two network element devices in the second network element device 12 and other network element devices in the AS domain or security domain need to establish BGP connection, and the BGP connection is also called Internal BGP (IBGP) connection.

In other embodiments, the first network element device 11 does not have an RR function, and the manner in which the first network element device 11 performs route management on the second network element device 12 includes, but is not limited to: the first network element device 11 sends an instruction to the network element device with RR function, so that the network element device with RR function sends BGP message.

In the embodiment of the present application, the trusted state of the second network element device indicated by the RA result corresponding to the second network element device includes, but is not limited to: the second network element device is trusted, the second network element device is untrusted, or the second network element device state is unknown. Where the second network element device 12 is capable of supporting the RA procedure, the second network element device 12 is configured to act as an RA client, the RA result possibly indicating any of the three trusted states described above. In case the second network element device 12 is not able to support the RA procedure, the RA result indicates a trusted state in which the state of the second network element device 12 is unknown.

For the case where the second network element device 12 is capable of supporting the RA procedure, the structure of the second network element device 12 may be seen in fig. 2. In fig. 2, comprising a processor 21, a memory 22, a network interface 23, security hardware 24 and a bus 25, the processor 21, the memory 22, the network interface 23 and the security hardware 24 are respectively connected to the bus 25, and an operating system, service software and RA client are stored in the memory 22 in the form of program codes. Wherein the processor 21 reads the program code from the memory 22 to enable the operating system to run and to enable the business software and RA client to run in the operating system. The security hardware 24 obtains and stores, via the bus 25, from the processor 21, the metric information of the second network element device, which metric information comprises information generated by components of the second network element device 12, such as a board, during operation of the service software. In the RA procedure, the RA client reads the metric information from the security hardware 24 via the bus 25, sends the metric information to the network interface 23 via the bus 25, and the network interface 23 sends the metric information to the network element device for acting as RA server via BGP connection. The network element equipment serving as the RA server compares the measurement information with the remote proving baseline file to obtain a remote proving result.

In some embodiments, the security hardware includes a security chip, such as a trusted platform module (trusted platform module, TPM) chip, which is security hardware that meets the requirements of a TPM. The TPM is an international standard for secure cryptographic processors (secure crypto processor), and TPM requirements include, but are not limited to: the key-dependent functions are performed using secure hardware, including RA described above. Further, the functions associated with the key may include generating the key, generating a random number, storing the key, etc., without limitation. Illustratively, the TPM chip includes (platformconfiguration register, PCR) and stores the metric information of the second network element device in the PCR, which is also referred to as a PCR value.

In addition, in the case where the second network element device 12 cannot support the RA procedure, the RA client and the security hardware shown in fig. 2 are not included in the second network element device 12, and will not be described herein.

Based on the implementation environment shown in fig. 1, the embodiment of the application provides a remote attestation application method, which is applied to the first network element device in the description. As shown in fig. 3, the method includes the following steps 301 and 302.

301, the first network element device obtains a remote proof result corresponding to the second network element device, where the remote proof result is used to indicate a trusted state of the second network element device, and the trusted state of the second network element device includes trusted, untrusted or unknown state.

The remote proving result corresponding to the second network element equipment, which is acquired by the first network element equipment, is obtained by the second network element equipment participating in the remote proving process. The trusted state of the second network element device indicated by the remote attestation result includes: the second network element device may be trusted (also known as a remote attestation result is correct), the second network element device may be untrusted (also known as a remote attestation result is incorrect), or the second network element device status may be unknown (also known as a remote attestation result is null). The reliability of the three trusted states is sequentially from high to low: the second network element device is trusted, the state of the second network element device is unknown, and the second network element device is not trusted.

In an exemplary embodiment, the first network element device obtains a remote attestation result corresponding to the second network element device, including: the first network element device reads a remote attestation result acquisition command, where the remote attestation result acquisition command is used to indicate an acquisition path of a remote attestation result. The first network element device acquires the remote certification result according to the acquisition path indicated by the remote certification result acquisition command. It should be noted that, whether the first network element device obtains the remote proof result from the local or the network element device other than the local, the first network element device needs to read the remote proof result obtaining command. Illustratively, the remote attestation result acquisition path indicated by the remote attestation result acquisition command includes, but is not limited to: files, configuration items, etc. in local or other network element devices, the embodiments of the present application do not define a path for obtaining a remote attestation result.

And 302, the first network element equipment performs route management on the second network element equipment based on the trusted state of the second network element equipment indicated by the remote proving result.

After the remote proving result is obtained, the remote proving result is applied to the management process of the second network element equipment, so that the remote proving result can be reflected on the network function (such as a routing function) of the second network element equipment. And because the remote proving result is used for indicating the trusted state of the second network element equipment, the second network element equipment is managed by applying the remote proving result, and the reliability of management is improved, so that the security of the network architecture containing the second network element equipment and the security of communication based on the second network element equipment are ensured.

Referring to fig. 4, fig. 4 is a schematic diagram showing a result of remote attestation applied in the related art. After the RA server obtains the RA result, the RA result is sent to the network management device (abbreviated as network management), and then the user at the network management device can browse the RA result. And then, the user at the network manager performs artificial interference on the RA client according to the browsed RA result. Because the related art needs human intervention, the trusted state indicated by the remote proof result is not fully utilized, and the reliability is not high. And, the related art process of applying the remote certification result cannot be reflected on the network function of the second network element device in time. Based on the above description of the embodiments of the present application, the embodiments of the present application can improve the problems of the related art. Next, an example of a process of route management for the second network element device provided in the embodiment of the present application is continued.

In an exemplary embodiment, the first network element device performs route management on the second network element device based on the trusted status of the second network element device indicated by the remote attestation result, including: the first network element equipment acquires the routing information corresponding to the second network element equipment. The first network element device manages routing information corresponding to the second network element device according to configured rules based on the trusted state of the second network element device.

The first network element equipment manages the route information corresponding to the second network element equipment according to the configured rule, so that the route management of the second network element equipment is realized. Illustratively, the configured rule is a rule under BGP global or a rule under BGP address family. The rule under BGP global takes effect on all BGP address families, and the rule under BGP address family takes effect on only partially specified BGP address families, and the embodiment of the present application does not limit the effective range of the configured rule.

In an exemplary embodiment, the configured rules include a routing management policy or executable code, such as a script, and embodiments of the present application do not limit the executable code. The process of managing according to the route management policy is flexible, but the workload of configuring the route management policy is large. The process of managing in terms of executable code is not flexible enough, but the effort to configure executable code is small. In the case where the configured rules are different, the manner of managing the route information corresponding to the second network element device is also different, and the following description will be made.

In a first management mode, the configured rules include a route management policy. The first network element device manages routing information corresponding to the second network element device according to configured rules based on the trusted state of the second network element device, and the method comprises the following steps: the first network element device determines a target policy from the route management policies that matches the trusted status of the second network element device. And the first network element equipment manages the route information corresponding to the second network element equipment according to the target strategy.

In the first network element device, the routing management policy includes policies corresponding to respective trusted states of the second network element device. Because the trusted state of the second network element device includes trusted, untrusted, or unknown state, the routing management policy includes a policy corresponding to the second network element device that is trusted, a policy corresponding to the second network element device that is not trusted, and a policy corresponding to the second network element device that is unknown state. The first network element device can determine a target policy matched with the trusted state of the second network element device from the routing management policies based on the trusted state of the second network element device, so as to manage routing information corresponding to the second network element device according to the target policy.

In an exemplary embodiment, the routing information corresponding to the second network element device includes at least one of first routing information, second routing information, third routing information, and fourth routing information. The first routing information is routing information that needs to be issued by the second network element device, that is, the second network element device has not issued the first routing information to other network element devices, and the first routing information needs to be issued to other network element devices currently or later. The second routing information is the routing information issued by the second network element device, and the second network element device has issued the second routing information to other network element devices before. The third routing information is routing information which needs to be received by the second network element equipment, and the third routing information is the routing information which is not issued to the second network element equipment by other network element equipment, is currently or later needs to be issued to the second network element equipment. The fourth routing information is the routing information that the second network element device has received, that is, the fourth routing information has been previously issued to the second network element device by the other network element devices.

In some embodiments, if the first network element device has an RR function, the first network element device obtains routing information corresponding to the second network element device, including: the first network element equipment receives the route information sent by the second network element equipment and other network element equipment, and obtains the route information corresponding to the second network element equipment from the received route information. In other embodiments, if the second network element device does not have the RR function, the first network element device obtains routing information corresponding to the second network element device, including: the first network element equipment acquires the route information corresponding to the second network element equipment from the network element equipment with the RR function, or the first network element equipment acquires the route information from the second network element equipment and other network element equipment respectively, and acquires the route information corresponding to the second network element equipment from the acquired route information. The embodiment of the application does not limit the obtaining mode of the route information corresponding to the second network element device.

Based on the routing information corresponding to the second network element device, the target policy includes at least one policy of a policy corresponding to the first routing information, a policy corresponding to the second routing information, a policy corresponding to the third routing information, and a policy corresponding to the fourth routing information. In case the trusted status of the second network element device is different, the target policy is also different. The target strategies corresponding to the three trusted states are respectively illustrated by the cases A1-A3.

In case A1, the trusted state of the second network element device is that the second network element device is trusted.

Referring to fig. 5, in case A1, the second network element device may send and receive routing information corresponding to the second network element device normally because the second network element device is trusted. In case A1, the individual policies included in the target policy are referred to as cases a11-a14 below.

In case a11, the policy corresponding to the first routing information is used to indicate that the first routing information is issued.

Since the second network element device is trusted, the first routing information that the second network element device needs to issue can be issued to other network element devices. In some embodiments, the first network element device has RR function, and the second network element device sends the first routing information to the first network element device. Illustratively, the first network element device manages the routing information corresponding to the second network element device according to the target policy, including: the first network element equipment receives the first routing information, and sends BGP messages carrying the first routing information to other network element equipment according to a strategy corresponding to the first routing information so as to release the first routing information. In other embodiments, if the first network element device does not have the RR function, the first network element device sends an instruction to the network element device having the RR function, so that the network element device having the RR function sends the BGP message carrying the first routing information to other network element devices.

Referring to fig. 6, fig. 6 illustrates a BGP message for route distribution, where the BGP message has an update (update) type, and includes a BGP header and a message content. The BGP message header includes a marker field, a length field, and a type value field, where the marker field is used to perform BGP authentication, the length field is used to indicate the total length of the BGP message, that is, the sum of the length of the BGP message header and the length of the message content, and the type value field is used to distinguish different message types. The value of the type value field is 2, which is used for indicating that the message type is an update type. The message content includes a total path attribute length (total path attribute length) field, a path attributes (path attributes) field, and a network layer reachability information (network layer reachability information, NLRI) field. The total path attribute length field is used for indicating the sum of the length of the path attribute field and the length of the NLRI, the NLRI field is used for carrying routing information to be issued, the path attribute field is used for carrying BGP attribute of the routing information carried by the NLRI field, and the BGP attribute can be set according to actual conditions.

Based on the message structure shown in fig. 6, the BGP message carrying the first routing information can be obtained by carrying the first routing information in the NLRI field.

In case a12, the policy corresponding to the second routing information is used to indicate that the second routing information is maintained.

Since the second network element device is trusted, other network element devices may continue to use the second routing information that the second network element device has published. Illustratively, the first network element device maintains the second routing information without performing operations because the second routing information is published.

In case a13, the policy corresponding to the third routing information is used to instruct to issue the third routing information to the second network element device.

Since the second network element device is trusted, the third routing information that needs to be issued by other network element devices may be issued to the second network element device. In some embodiments, the first network element device has RR function, and then the other network element devices send the third routing information to the first network element device. Illustratively, the first network element device manages the routing information corresponding to the second network element device according to the target policy, including: the first network element equipment receives the third routing information, and sends the BGP message carrying the third routing information to the second network element equipment according to the strategy corresponding to the third routing information so as to release the third routing information. In other embodiments, if the first network element device does not have the RR function, the first network element device sends an instruction to the network element device having the RR function, so that the network element device having the RR function sends the BGP message carrying the third routing information to the second network element device.

As shown in fig. 6, the third routing information is carried by the NLRI field shown in fig. 6, so that a BGP message carrying the third routing information can be obtained.

In case a14, the policy corresponding to the fourth routing information is used to indicate that the fourth routing information is maintained.

Since the second network element device is trusted, the second network element device may continue to use the fourth routing information that has been published by the other network element devices. Illustratively, the fourth routing information is maintained by the first network element device without operation, as the fourth routing information is published.

And in case A2, the trusted state of the second network element equipment is that the second network element equipment is not trusted.

Referring to fig. 5, since the second network element device is not trusted in the case A2, the second network element device does not receive and transmit the routing information corresponding to the second network element device. In case A2, the individual policies included in the target policy are referred to as cases a21-a24 below.

In case a21, the policy corresponding to the first routing information is used to indicate that the first routing information is not issued.

Since the second network element device is not trusted, the first routing information that the second network element device needs to issue may not be issued to other network element devices. In some embodiments, the first network element device has RR function, and the second network element device sends the first routing information to the first network element device. Illustratively, the first network element device manages the routing information corresponding to the second network element device according to the target policy, including: the first network element device does not receive the first routing information, or the first network element device receives the first routing information and discards the first routing information, or the first network element device receives and stores the first routing information, but does not issue the first routing information. In summary, the first network element device does not issue the first routing information to other network element devices. In other embodiments, the first network element device does not have an RR function, and the first network element device sends an instruction to the network element device having an RR function, so that the network element device having an RR function does not issue the first routing information to other network element devices.

In case a22, the policy corresponding to the second routing information is used to indicate that the second routing information is revoked.

Because the second network element device is not trusted, other network element devices may not continue to use the second routing information that the second network element device has published. In some embodiments, the first network element device has RR functionality, and thus the second routing information is received by the first network element device from the second network element device and issued to other network element devices. Illustratively, the first network element device manages the routing information corresponding to the second network element device according to the target policy, including: and the first network element equipment sends BGP messages carrying the second routing information to other network element equipment according to the strategy corresponding to the second routing information so as to cancel the second routing information. In other embodiments, if the first network element device does not have the RR function, the first network element device sends an instruction to the network element device having the RR function, so that the network element device having the RR function sends BGP messages carrying the second routing information to other network element devices.

Referring to fig. 7, fig. 7 shows a BGP message for performing route withdrawal, where a message type of the BGP message is an update type, and the BGP message includes a BGP header and a message content, and the BGP header is referred to in the description corresponding to fig. 6 in the case a11 and is not described herein again. In the message content, a revocation route length (withdrawn routes length) field and a revocation route (withdraw routes) field are included, the revocation route length field is used for indicating the length of the revocation route field, and the revocation route field is used for carrying route information to be revoked.

Based on the message structure shown in fig. 7, the BGP message carrying the second routing information can be obtained by withdrawing the second routing information carried by the routing field.

In case a23, the policy corresponding to the third routing information is used to indicate that the third routing information is not issued to the second network element device.

Since the second network element device is not trusted, the third routing information that other network element devices need to issue cannot be issued to the second network element device. In some embodiments, the first network element device has RR function, and then the other network element devices send the third routing information to the first network element device. Illustratively, the first network element device manages the routing information corresponding to the second network element device according to the target policy, including: the first network element device does not receive the third routing information, or the first network element device receives the third routing information and discards the third routing information, or the first network element device receives the third routing information, and the first network element device issues the third routing information to network element devices except the second network element device. In summary, the first network element device does not issue the third routing information to the second network element device. In other embodiments, the first network element device does not have an RR function, and the first network element device sends an instruction to the network element device having an RR function, so that the network element device having an RR function does not issue the third routing information to the second network element device.

In case a24, the policy corresponding to the fourth routing information is used to indicate that the fourth routing information is revoked.

Because the second network element device is not trusted, the second network element device may not continue to use the fourth routing information that has been published by the other network element devices. In some embodiments, the first network element device has RR functionality, and thus the fourth routing information is received by the first network element device from other network element devices and issued to the second network element device. Illustratively, the first network element device manages the routing information corresponding to the second network element device according to the target policy, including: and the first network element equipment sends the BGP message carrying the fourth routing information to the second network element equipment according to the strategy corresponding to the fourth routing information so as to cancel the fourth routing information. In other embodiments, if the first network element device does not have an RR function, the first network element device sends an instruction to the network element device having the RR function, so that the network element device having the RR function sends a BGP packet carrying fourth routing information to the second network element device.

As shown in fig. 7, the fourth routing information is carried by the withdrawal routing field in fig. 7, so that a BGP message carrying the fourth routing information may be obtained.

And in case A3, the trusted state of the second network element equipment is unknown to the state of the second network element equipment.

Referring to fig. 5, since the state of the second network element device is unknown in the case A3, the second network element device may send and receive the routing information corresponding to the second network element device, but needs to reduce the priority of the routing information corresponding to the second network element device. In case A3, the individual policies included in the target policy are referred to as cases a31-a34 below.

In case a31, the policy corresponding to the first routing information is used to indicate that the first routing information and the first priority index are issued, where the first priority index is used to indicate the priority of the first routing information, and the priority of the first routing information is lower than the default priority.

Because the state of the second network element device is unknown, the first routing information that needs to be published by the second network element device may be published to other network element devices, but the priority of the first routing information needs to be lower than the default priority, so as to avoid that other network element devices preferentially select the first routing information. Therefore, the first priority index indicating the priority of the first routing information needs to be issued together with the first routing information. Under the condition that priority indexes are not set for the routing information, the routing information corresponds to default priority indexes, and the priority indicated by the default priority indexes is the default priority.

In some embodiments, the first network element device has RR function, and the second network element device sends the first routing information to the first network element device. Illustratively, the first network element device manages the routing information corresponding to the second network element device according to the target policy, including: the first network element equipment receives the first routing information and sends BGP messages carrying the first routing information and the first priority index to other network element equipment according to a strategy corresponding to the first routing information. In other embodiments, if the first network element device does not have the RR function, the first network element device sends an instruction to the network element device having the RR function, so that the network element device having the RR function sends the BGP packet carrying the first routing information and the first priority indicator to other network element devices.

In an exemplary embodiment, the first priority indicator is a BGP attribute. As can be seen from the description corresponding to fig. 6 in the above case a11, the NLRI field in fig. 6 is used to carry the routing information to be published, and the path attribute field is used to carry the BGP attribute of the routing information carried by the NLRI field. Therefore, in the embodiment of the present application, the first priority index is carried by the path attribute field, and the first routing information is carried by the NLRI field, so as to obtain the BGP message carrying the first routing information and the first priority index. Wherein the number of BGP attributes is plural, and the attribute identifier, attribute name, attribute meaning and attribute type of each BGP attribute are as shown in table 1 below.

TABLE 1

In table 1, BGP attributes related to priority include local_pref and MED, and thus local_pref or MED is used as the first priority index in the embodiment of the present application. Therefore, the local_pref or MED needs to be carried by the path attribute field shown in fig. 6 described above. The path attribute field includes an attribute type (attribute type) field, an attribute length (attribute type) field, and an attribute value (attribute value) field in a type length value (type length value, TLV) format. The attribute type field includes an attribute flag (attribute flags) field and an attribute type number (attribute type code) field, where the attribute flag field is used to indicate whether the BGP attribute has to be extended or not, the attribute flag field may be set based on the attribute type in table 1, and the attribute type number field is used to carry the attribute identifier in table 1. The attribute length field is used to indicate the length of the attribute value field. The attribute value field is used for carrying content corresponding to the attribute identifier carried by the attribute type number field. For example, if the attribute identifier carried by the attribute type code field is 4, the first priority index is local_pref, and thus the attribute value field carries the value of local_pref. For another example, if the attribute identifier carried by the attribute type code field is 5, the first priority index is MED, and thus the attribute value field carries the value of MED.

The larger the value of the local_pref, the higher the priority indicated by the local_pref. In the case where the first priority index is local_pref, since the priority of the first routing information indicated by the first priority index needs to be lower than the default priority, the value of the first priority index needs to be smaller than the default value of local_pref, which is used to indicate the default priority. For example, if the default value of local_pref is 100, the value of the first priority index is 30, 50, 70, etc. less than 100, and the embodiment of the present application does not limit the value of the first priority index. Further, the smaller the value of the MED, the higher the priority indicated by the MED. In the case where the first priority index is an MED, since the priority of the first routing information indicated by the first priority index needs to be lower than the default priority, the value of the first priority index needs to be greater than the default value of the MED, which is used to indicate the default priority. For example, the default value of MED is 0, and the values of the first priority index are 20, 50, 100, etc. greater than 0, and the values of MED are not limited in the embodiment of the present application. The above local_pref and MED are also examples, and do not limit the first priority index, and other first priority indexes may be adopted according to actual needs in the embodiment of the present application.

Referring to fig. 8, fig. 8 shows a flow diagram of a selection sequence of routing information. If there are multiple routing information to the same destination address and the next hop is reachable, routing according to the various routing criteria shown in fig. 8 is started. In the routing process, routing information with a large value of the protocol preference value is preferentially selected from the plurality of routing information. If the values of the protocol preference values of the plurality of routing information are the same, among the plurality of routing information, the routing information having the large value of local_pref, that is, the routing information having the small value of local_pref, is preferentially selected. If the values of the local_pref of the plurality of routing information are also the same and the respective route bases (omitted in fig. 8) between the local_pref and the MED of the plurality of routing information are the same, among the plurality of routing information, the routing information having the small value of the MED, that is, the routing information having the large value of the MED, is not preferentially selected. If the values of the MED of the plurality of routing information are also the same, the routing is continued using the respective routing bases after MED (omitted in fig. 8) until the routing base to the peer address is used, ending the routing process.

Therefore, in the embodiment of the present application, local_pref or MED is adopted as the first priority index, and in the case that the state of the second network element device is unknown, by setting the value of the first priority index so that the priority of the first routing information is lower than the default priority, the first routing information can be prevented from being preferentially selected, thereby avoiding that the traffic preferentially passes through the second network element device with unknown state.

In case a32, the policy corresponding to the second routing information is used to indicate to issue the second routing information and a second priority index, where the second priority index is used to indicate the priority of the second routing information issued this time, and the priority of the second routing information issued this time is lower than the default priority and lower than the priority of the second routing information issued last time.

Since the state of the second network element device is unknown, other network element devices may continue to use the second routing information that the second network element device has published. However, this time, the priority of the second routing information needs to be reduced, so as to avoid that other network element devices preferentially select the second routing information. Therefore, the embodiment of the application issues the second routing information and the second priority index, that is, reissues the second routing information, so that the priority of the second routing information issued last time is reduced to the priority indicated by the second priority index. In addition, the priority of the second routing information released this time is lower than the default priority, and the application embodiment does not limit the default priority.

It should be noted that, as is known from the description in the above case a22, the first network element device needs to revoke the second routing information when the second network element device is not trusted, and does not issue the second routing information. Therefore, the trusted status of the second network element device when the second routing information is published last time may not include that the second network element device is not trusted, but may only include that the second network element device is trusted or that the second network element device status is unknown. If the second network element equipment is trusted when the second routing information is released last time, the reliability degree of the second network element equipment is reduced compared with that of the second network element equipment when the second routing information is released last time, so that the priority of the second routing information needs to be reduced this time. If the state of the second network element device is unknown when the second routing information is released last time, although the credibility of the second network element device is the same as that of the second network element device when the second routing information is released last time, the condition that the state of the second network element device is unknown already occurs at least twice, so that the priority of the second network element device also needs to be reduced this time.

In some embodiments, the first network element device has RR functionality, and thus the second routing information is received by the first network element device from the second network element device and issued to other network element devices. Illustratively, the first network element device manages the routing information corresponding to the second network element device according to the target policy, including: and the first network element equipment receives the second routing information and sends BGP messages carrying the second routing information and the second priority index to other network element equipment according to the strategy corresponding to the second routing information. In other embodiments, if the first network element device does not have the RR function, the first network element device sends an instruction to the network element device having the RR function, so that the network element device having the RR function sends the BGP message carrying the second routing information and the second priority indicator to other network element devices.

In an exemplary embodiment, the second priority indicator is a BGP attribute and the second priority indicator includes local_pref or MED. The larger the value of local_pref, the higher the priority indicated by local_pref. The smaller the value of the MED, the higher the priority indicated by the MED. Illustratively, the priority indicated by the second priority index is the lowest priority, and the value of the second priority index is the minimum value of local_pref in the case where the second priority index includes local_pref, and the value of the second priority index is the maximum value of MED in the case where the second priority index includes MED. The embodiments of the present application do not limit the minimum value of local_pref and the maximum value of MED. In addition, in the embodiment of the present application, the path attribute field shown in fig. 6 carries the second priority index, and the NLRI field carries the second routing information, so as to obtain the BGP message carrying the second routing information and the second priority index. The BGP message carrying the second routing information and the second priority index is referred to the description of the BGP message carrying the first routing information and the first priority index in the case a31, which is not described herein.

In case a33, the policy corresponding to the third routing information is used to instruct to issue the third routing information to the second network element device.

Case a33 is referred to the description in case a13 above, and will not be described here again.

In case a34, the policy corresponding to the fourth routing information is used to indicate that the fourth routing information is maintained.

Case a34 is referred to the description in case a14 above, and will not be described here again.

It should be noted that, the first management manner may enable the lower the reliability of the second network element device, the lower the probability that the traffic passes through the second network element device. As can be seen from the description in step 301, the degree of reliability of the third case, i.e. the case A1, the state of the second network element is unknown (i.e. the case A3), and the second network element is not trusted (i.e. the case A2), decreases in sequence. In the embodiment of the application, the case A1 with the highest reliability can normally transmit and receive the routing information, the case A3 with the second highest reliability transmits and receives the routing information, the priority of the routing information is reduced, and the case A2 with the lowest reliability does not transmit and receive the routing information. Therefore, the probability of selecting the trusted second network element equipment is maximum in the routing process, the probability of selecting the second network element equipment with unknown state is secondary, and the probability of selecting the untrusted second network element equipment is minimum. Thereby, the lower the degree of reliability of the second network element device is, the lower the probability that the flow passes through the second network element device is.

The first management method is described above, and corresponds to a case where the configured rule includes a route management policy. In the following, a second kind of management is described, which corresponds to a case where the configured rule includes executable code.

In a second management mode, the configured rules include executable code. The executable code is configured for configuring, for the routing information corresponding to the second network element device, a priority indicator that matches the trusted status of the second network element device. The first network element device manages routing information corresponding to the second network element device according to configured rules based on the trusted state of the second network element device, and the method comprises the following steps: the first network element equipment configures a third priority index for the routing information corresponding to the second network element equipment by running the executable code, wherein the third priority index is a priority index matched with the trusted state of the second network element equipment, and the third priority index is used for indicating the priority of the routing information corresponding to the second network element equipment. The first network element device issues routing information and a third priority index corresponding to the second network element device.

The first network element device determines, by running the executable code, that a priority index matched with a trusted state of the second network element device needs to be configured for routing information corresponding to the second network element device, that is, a third priority index, where the third priority index is used to indicate a priority of the routing information corresponding to the second network element device. In some embodiments, the first network element device has an RR function, so the second network element device sends the routing information corresponding to the second network element device to the first network element device. The first network element device issues routing information and a third priority index corresponding to the second network element device, which includes: the first network element equipment receives the routing information corresponding to the second network element equipment and sends BGP messages carrying the routing information corresponding to the second network element equipment and the third priority index to other network element equipment. In other embodiments, if the first network element device does not have the RR function, the first network element device sends an instruction to the network element device having the RR function, so that the network element device having the RR function sends BGP messages carrying the routing information and the third priority index corresponding to the second network element device to other network element devices.

Illustratively, the third priority indicator is a BGP attribute, and the third priority indicator includes local_pref or MED. The larger the value of local_pref, the higher the priority indicated by local_pref. The smaller the value of the MED, the higher the priority indicated by the MED. In the embodiment of the present application, the path attribute field shown in fig. 6 carries the third priority index, and the NLRI field carries the routing information corresponding to the second network element device, so as to obtain the BGP message carrying the routing information corresponding to the second network element device and the third priority index. The BGP message carrying the routing information and the third priority index corresponding to the second network element device is referred to the description of the BGP message carrying the first routing information and the first priority index in the case a31, which is not described herein.

In an exemplary embodiment, the routing information corresponding to the second network element device includes at least one of first routing information and second routing information, where the first routing information is routing information that needs to be published by the second network element device, and the second routing information is routing information that has been published by the second network element device. The first routing information and the second routing information are described in the first management manner, and are not described herein. On the basis, the third priority index comprises at least one index of priority indexes corresponding to the first routing information and priority indexes corresponding to the second routing information, the priority indexes corresponding to the first routing information are used for indicating the priority of the first routing information, and the priority indexes corresponding to the second routing information are used for indicating the priority of the second routing information. In an exemplary embodiment, when the routing information corresponding to the second network element device includes the first routing information and the second routing information, the BGP packet carrying the routing information corresponding to the second network element device and the third priority indicator includes: the BGP message carrying the first routing information and the priority index corresponding to the first routing information, and the BGP message carrying the second routing information and the priority index corresponding to the second routing information.

It should be noted that, in the case that the trusted status of the second network element device is different, the priority of the first routing information and the priority of the second routing information are also different. The priorities of the first routing information and the priorities of the second routing information corresponding to the three trusted states are respectively illustrated by the cases B1-B3.

And in the case B1, the trusted state of the second network element equipment is the trusted state of the second network element equipment. The priority of the first routing information and the priority of the second routing information are not lower than the default priority.

Illustratively, the priority index of the first routing information and the priority index of the second routing information are both local_pref. Since the larger the value of the local_pref is, the higher the priority indicated by the local_pref is, and thus the value of the local_pref of the first routing information and the value of the local_pref of the second routing information are not smaller than the default value of the local_pref for indicating the default priority, it is possible to make the priority of the first routing information and the priority of the second routing information not lower than the default priority. For example, the default value of local_pref is 100, and the value of local_pref of the first routing information and the value of local_pref of the second routing information are both 200.

Alternatively, the priority index of the first routing information and the priority index of the second routing information are both MED. Since the smaller the value of the MED is, the higher the priority indicated by the MED is, the value of the MED of the first routing information and the value of the MED of the second routing information are not greater than the default value of the MED, which is used to indicate the default priority, so that the priority of the first routing information and the priority of the second routing information can be made not lower than the default priority. For example, the default value of MED is 0, and the value of MED of the first routing information and the value of MED of the second routing information are both 0.

And in the case B2, the trusted state of the second network element equipment is that the second network element equipment is not trusted. The priority of the first routing information and the priority of the second routing information are both lower than the default priority.

Illustratively, the value of the local_pref of the first routing information and the value of the local_pref of the second routing information are both less than the default value of the local_pref, such that the priority of the first routing information and the priority of the second routing information are both lower than the default priority. For example, if the default value of the local_pref is 100, the value of the local_pref of the first routing information and the value of the local_pref of the second routing information are both 0.

Alternatively, illustratively, the value of the MED of the first routing information and the value of the MED of the second routing information are both greater than the default value of the MED such that the priority of the first routing information and the priority of the second routing information are both lower than the default priority. For example, if the default value of MED is 0, the value of MED of the first routing information and the value of MED of the second routing information are both 100.

And B3, the trusted state of the second network element equipment is unknown. The priority of the first routing information and the priority of the second routing information are both lower than the default priority and higher than the priority in case the second network element device is not trusted.

The priority of the second network element device under the un-trusted condition is the priority of the first routing information and the priority of the second routing information in the above case B2.

Illustratively, the value of the local_pref of the first routing information and the value of the local_pref of the second routing information in case B3 are both smaller than the default value of the local_pref and larger than the value of the local_pref of the first routing information and the value of the local_pref of the second routing information in case B2. For example, if the default value of the local_pref is 100 and the values of the local_pref and the local_pref of the first routing information and the second routing information in the case B2 are both 0, the values of the local_pref and the local_pref of the first routing information in the case B3 are both 50.

Alternatively, illustratively, the value of the MED of the first routing information and the value of the MED of the second routing information in case B3 are both greater than the default value of the MED and less than the value of the MED of the first routing information and the value of the MED of the second routing information in case B2. For example, if the default value of MED is 0 and the values of MED of the first routing information and MED of the second routing information in case B2 are both 100, the values of MED of the first routing information and MED of the second routing information are both 50.

It should be noted that, the second management manner may also enable the lower the reliability of the second network element device, the lower the probability that the traffic passes through the second network element device. As can be seen from the description in step 301, the degree of reliability in the three cases of the second network element device being trusted (i.e. case B1), the state of the second network element device being unknown (i.e. case B3), and the second network element device being untrusted (i.e. case B2) decreases in sequence. In the embodiment of the present application, the priority of the routing information corresponding to the second network element device in the case B1 with the highest reliability is the highest, the priority of the routing information corresponding to the second network element device in the case B3 with the second highest reliability is the next highest, and the priority of the routing information corresponding to the second network element device in the case B2 with the lowest reliability is the lowest. Therefore, in the routing process, the trusted second network element equipment is preferentially selected, the second network element equipment with unknown state is selected, the untrusted second network element equipment is selected again, the selection probability is sequentially reduced, and the probability of selecting the second network element equipment influences the probability of the flow passing through the second network element equipment. Thereby, the lower the degree of reliability of the second network element device is, the lower the probability that the flow passes through the second network element device is.

In the embodiment of the present application, steps 301 and 302 are periodically executed during the working process of the first network element device, or in the use process of the second network element device. Therefore, the second network element equipment can be regularly subjected to route management, and the reliability of management is ensured.

In summary, after the remote attestation result is obtained, the embodiment of the application applies the remote attestation result to the management process of the second network element device, so that the remote attestation result can be reflected on the routing function of the second network element device. Because the remote proving result is used for indicating the trusted state of the second network element equipment, the management of the second network element equipment by using the remote proving result improves the reliability of management, thereby ensuring the security of the network architecture containing the second network element equipment and the security of communication based on the second network element equipment. Moreover, by applying the embodiment of the application, the lower the credibility of the second network element equipment is, the lower the probability that the flow passes through the second network element equipment is.

And under the condition that the first network element equipment has an RR function, BGP connection for carrying out route reflection is established between the first network element equipment and the second network element equipment. Under the condition, the first network element equipment is used as an RA server, and the second network element equipment is remotely proved through the connection of the first network element equipment and the BGP, so that other extra equipment is not required to be deployed outside the first network element equipment and the second network element equipment for realizing remote verification, and special connection is not required to be manually established, thereby saving the cost and improving the efficiency of remote verification. Referring to fig. 9, in this case, the specific process of the first network element device obtaining the remote attestation result corresponding to the second network element device in step 301 in the embodiment shown in fig. 3 includes the following steps 901-905.

901, the first network element device sends a first BGP message to the second network element device based on BGP connection, where the first BGP message is used to query metric information of the second network element device.

The first network element device is a device having a route reflection function (e.g., the first network element device 11 in fig. 1 or fig. 2), and BGP connection for performing route reflection is established between the first network element device and the second network element device, and the BGP connection is also called BGP session. Illustratively, a transmission control protocol (transmission control protocol, TCP) connection is first established between the first network element device and the second network element device, and a BGP connection is then established based on the TCP connection. In some embodiments, a BGP session list is stored in the first network element device, where the BGP session list includes at least one network element device, and any network element device in the at least one network element device establishes a BGP connection with the first network element device, so that any network element device in the BGP session list may be used as the second network element device. The first network element device traverses the BGP session list and selects a second network element device from the BGP session list, so that the first network element device can automatically discover the second network element device that needs remote attestation.

In an exemplary embodiment, the metric information of the second network element device includes: and the service software is the software installed on the second network element equipment. Illustratively, the running process includes a start-up process, and the metric information of the second network element device includes: and the service software generates information by the components of the second network element equipment in the starting process. In some embodiments, the components of the second network element device include, but are not limited to, individual boards in the second network element device, and the number of components of the second network element device may be one or more. In addition to the above manner of determining the metric information of the second network element device, other manners may be used to determine the metric information of the second network element device, which in the embodiment of the present application is not limited to the manner of determining the metric information, and the metric information may be determined according to actual needs.

In an exemplary embodiment, the first BGP message includes a first-type-length-value (type length value, TLV) field, which is used to indicate query metric information. The process of querying the metric information is also called a challenge process, and the first BGP message Wen Youchen is a challenge message. Illustratively, the first TLV field includes a first type field carrying a first type (type) value for indicating query metric information or carrying metric information, a first length field for indicating a length of the first value field, and a first value field for indicating that the first type value indicates query metric information. In some implementations, the first value field indicates that the first type value indicates query metric information in the manner of: the first value field carries a first reference value or alternatively, the first value field is empty. In the case that the first value field carries a first reference value, the first reference value comprises a value that is different from and not confused with the metric information. The first reference value may be obtained through configuration, or may be obtained through negotiation between the first network element device and the second network element device, which is not limited in the embodiment of the present application. In the case where the first value field is empty, the first length field is zeroed out because the first length field is used to indicate the length of the first value field.

Since the first BGP message belongs to one of BGP messages, a message structure of the BGP message is described next, so as to facilitate understanding a message structure of the first BGP message and other BGP messages of the subsequent BGP message.

The BGP message comprises a BGP message header and message content. Referring to fig. 10, fig. 10 shows the structure of BGP header. The BGP header includes a marker field, a length field, and a type value field, where the marker field is used to perform BGP authentication, the length field is used to indicate the total length of the BGP packet, that is, the sum of the lengths of the BGP header and the packet content, and the type value field is used to distinguish different packet types. For example, if the value of the type value field is 1, the message type is an open (open) type. And if the value of the type value field is 2, the message type is an update type. And, different message types correspond to different message contents.

As shown in fig. 11, fig. 11 shows a message structure of a BGP message of an update type, where the BGP message of the update type includes a BGP header and a message content corresponding to the update type. The message content corresponding to the update type includes a total path attribute length (total path attribute length) field and a path attribute (path attributes) field, where the total path attribute length field is used to indicate the length of the path attribute field, and the length of the path attribute field is variable. In some embodiments, the path attribute field is in TLV format, and the path attribute field includes an attribute type (attribute type) field, an attribute length (attribute length) field, and an attribute value (attribute value) field, the length of which is variable.

In an exemplary embodiment, the first BGP message is a first update message, that is, a BGP message with a message type that is an update type. The first update message includes a first path attribute field, and the first TLV field is located in the first path attribute field. The first path attribute field is a path attribute field shown in fig. 11, the first type field included in the first TLV field is an attribute type field shown in fig. 11, the first length field included in the first TLV field is an attribute length field shown in fig. 11, and the first value field included in the first TLV field is an attribute value field shown in fig. 11. In this case, the first TLV field includes a first type value carried by a first type field that is: any one of unregistered (unassigned) type values corresponding to the path attribute field. The unregistered type value corresponding to the path attribute field includes, but is not limited to: 39. 41-127, 130-240, 244-254, the first type value in this embodiment of the application is, for example, 201.

It should be noted that TCG proposes the concept of "trust chain" and "trust metric" for trusted computing. The method comprises the steps of firstly setting a trusted root, carrying out trusted measurement on other devices by the trusted root, and if the trusted root verifies that one device is in a trusted state, forming a trust chain by the device in the trusted state and the trusted root. In this embodiment, the first network element device verifies whether the second network element device is in a trusted state, that is, the first network element device performs a trusted measurement on the second network element device, so before executing step 901, the first network element device needs to be set as a trusted root. And responding to the first network element equipment to verify that the second network element equipment is in a trusted state in the subsequent process, and forming a trust chain by the first network element equipment and the second network element equipment. In addition, before step 901, the embodiment of the present application needs to set the first network element device as an RA server. Illustratively, the first network element device receives a command line configured by a user, or receives a configuration command sent by the network management device, so as to configure the first network element device as an RA server. In some implementations, the command line is, for example, an RA server enable (RA server enable) command line. In other embodiments, the first network element device receives the configuration command sent by the network management device via a simple network management protocol (simple network management protocol, SNMP) or a network configuration (network configuration, netcon) protocol.

The second network element device receives a first BGP message sent by the first network element device based on the BGP connection 902.

After the first network element device sends the first BGP message to the second network element device based on the BGP connection, the second network element device may receive the first BGP message. The second network element device analyzes the first BGP message, so as to determine that the first BGP message is used to query metric information of the second network element device.

903, the second network element device sends a second BGP message to the first network element device based on BGP connection, where the second BGP message carries metric information, so that the first network element device obtains a remote proof result corresponding to the second network element device.

After determining that the first BGP message is used to query the metric information of the second network element device, the second network element device obtains the metric information, and sends the second BGP message carrying the metric information to the first network element device. Illustratively, the second network element device obtains the metric information from security hardware (e.g., a TPM chip including PCRs) embedded in the second network element device.

In an exemplary embodiment, the second BGP message includes a second TLV field, where the second TLV field is used to carry metric information. The process of returning the measurement information is also called a response process, so that the second BGP message is also called a response message. Illustratively, the second TLV field includes a second type field, a second length field, and a second value field, where the second type field carries a first type value, and the first type value is used to indicate query metric information or carries metric information, and the first type value is referred to in step 901 and is not described herein. The second length field is used to indicate the length of the second value field, and the second value field is used to carry the metric information, so that the first type value can be indicated to carry the metric information.

As can be seen from the description in step 901, the metric information of the second network element device includes information generated by a component of the second network element device during the running process (e.g., the start-up process) of the service software. In some embodiments, the metric information carried in the second value field includes a hash value obtained by performing a hash (hash) calculation on the metric information of the second network element device. In some implementations, the metric information carried by the second value field includes metric information that has been encoded in accordance with yet another next generation (yet another next generation, YANG) model. The YANG model is, for example, a YANG model defined by draft-ietf-rates-YANG-tpm-charra-11.

In an exemplary embodiment, the second BGP message is a second update message, which is a BGP message with a message type that is an update type. The second update message includes a second path attribute field, the second TLV field being located in the second path attribute field. The second path attribute field is the path attribute field shown in fig. 11, the second type field included in the second TLV field is the attribute type field shown in fig. 11, the second length field included in the second TLV field is the attribute length field shown in fig. 11, and the second value field included in the second TLV field is the attribute value field shown in fig. 11.

904, the first network element device receives a second BGP message sent by the second network element device based on BGP connection, and parses the second BGP message to obtain metric information carried by the second BGP message.

Because the second network element device sends the second BGP message to the first network element device, the first network element device may receive the second BGP message. The first network element device analyzes the second BGP message, thereby obtaining the measurement information of the second network element device.

905, comparing the measurement information obtained by analysis with the remote proof baseline file by the first network element device to obtain a remote proof result.

The measurement information obtained by analysis is the measurement information of the second network element device carried in the second BGP message. The remote proof baseline file comprises a reference value of the measurement information, and is used as a reference of the measurement information, namely, a reference for comparison in the RA process. Illustratively, in the case where the metric information comprises information generated by a component of the second network element device during operation of the service software, the remote attestation baseline file comprises information generated by said component during operation of the untampered, authentic and complete service software. In case the second network element device comprises a plurality of components, the remote attestation baseline file also comprises information generated by the plurality of components during the running of the untampered, authentic and complete service software, in which case the remote attestation baseline file may be represented as a list. Illustratively, the untampered, authentic and complete business software includes business software at the time of release.

And the first network element equipment compares the analyzed measurement information with the remote proof baseline file to obtain a remote proof result for indicating whether the second network element equipment is in a trusted state. And responding to the consistency of the measurement information and the remote proving baseline file, and obtaining a remote proving result used for indicating that the second network element equipment is in a trusted state by the first network element equipment. In response to the metric information and the remote attestation baseline file not being consistent, the first network element device obtains a remote attestation result indicating that the second network element device is in an untrusted state.

In an exemplary embodiment, the metric information is consistent with a remote attestation baseline file, comprising: each piece of metric information is consistent with corresponding information in the remote attestation baseline file, the corresponding information being information generated by the same component. Taking the components in the second network element device including the single board 1 and the single board 2 as an example, the measurement information includes information generated by the single board 1 and information generated by the single board 2 in the operation process of the service software, and the remote proof baseline file includes information generated by the single board 1 and information generated by the single board 2 in the operation process of the untampered, real and complete service software. And responding to the fact that the information generated by the single board 1 in the measurement information is the same as the information generated by the single board 1 in the remote certification baseline file, and the information generated by the single board 2 in the measurement information is the same as the information generated by the single board 2 in the remote certification baseline file, the first network element equipment obtains a remote certification result for indicating that the second network element equipment is in a trusted state.

For example, after the first network element device obtains the remote attestation result, the first network element device sends the remote attestation result to the network management device to present the remote attestation result to a user of the network management device, and the second network element device is managed by the user of the network management device based on the remote attestation result. For example, in case the remote attestation result is used to indicate that the second network element device is in an untrusted state, the user of the network management device alerts the user of the second network element device or the user of the network management device drops the second network element device.

It can be appreciated that the first network element device needs to obtain the remote attestation baseline file before performing step 905. In some embodiments, the remote attestation baseline file is received by the first network element device. The first network element device receives the remote proof baseline file sent by other devices, for example, network management devices, and a user of the network management devices uploads the remote proof baseline file to the first network element device through the network management devices. In some embodiments, the first network element device receives the remote attestation baseline file in an environment that can be secured. For example, the first network element device receives the remote attestation baseline file via a secure file transfer protocol (secure file transfer protocol, SFTP). In other embodiments, the remote attestation baseline file is generated by the first network element device based on metric information of the first network element device. Illustratively, in response to the first network element device and the second network element device providing the same version of the device for the same vendor, the first network element device generates the remote attestation baseline file from the metric information of the first network element device. The reason why the first network element device can generate the remote proof baseline file by itself is that: the first network element device is a trusted root, and thus the service software in the first network element device is not tampered with, authentic and complete. On this basis, the first network element device and the second network element device comprise the same components, as the first network element device and the second network element device are devices of the same version provided by the same provider. Therefore, the first network element equipment can record information generated by each component in the running process of the service software to obtain the measurement information of the first network element equipment, so that the measurement information of the first network element equipment is used as a remote proof baseline file.

In addition, in the use process of the second network element device, the steps 901 to 905 may be periodically performed, so as to periodically verify whether the second network element device is in a trusted state, and ensure the security of the second network element device.

In an exemplary embodiment, in step 901, the first network element device sends a first BGP message to the second network element device based on the BGP connection, including: the first network element equipment establishes a secure connection with the second network element equipment based on the BGP connection, and sends a first BGP message to the second network element equipment through the secure connection. The safety of the first BGP message in the transmission process can be improved by transmitting the first BGP message through the safety connection, so that the accuracy of a subsequently obtained remote proof result is improved. In an exemplary embodiment, the second network element device receives, in step 902, a first BGP message sent by the first network element device based on the BGP connection, including: the second network element device establishes a secure connection with the first network element device based on the BGP connection, and receives a first BGP message sent by the first network element device through the secure connection. In step 903, the second network element device sends a second BGP message to the first network element device based on the BGP connection, including: and the second network element equipment sends a second BGP message to the first network element equipment through the secure connection. In step 904, the first network element device receives, based on BGP connection, a second BGP message sent by the second network element device, including: the first network element equipment receives a second BGP message sent by the second network element equipment through the secure connection.

In an exemplary embodiment, the secure connection comprises a transport layer security (transport layer security, TLS) connection or an internet protocol (internet protocol, IP) security (sec) tunnel. In the case that the secure connection is a TLS connection, the first network element device establishes a secure connection with the second network element device based on the BGP connection, including: the first network element device establishes a new TCP connection with the second network element device based on the BGP connection, establishes a TLS connection based on the new TCP connection, and establishes a new BGP connection based on the TLS connection, which is also called a BGP (BGP over TLS) connection based on the TLS. In the case that the secure connection is an IP Sec tunnel, the first network element device does not need to establish a new BGP connection again, but only needs to establish the IP Sec tunnel directly based on the BGP connection. The embodiment of the application does not limit the safety connection, and the safety connection is selected according to actual needs.

In an exemplary embodiment, the first network element device establishes a secure connection with the second network element device based on the BGP connection, including: in response to determining that the second network element device supports the remote attestation function, the first network element device sends a secure connection establishment request to the second network element device through the BGP connection, and establishes a secure connection with the second network element device according to the secure connection establishment request. For the second network element device, the second network element device establishes a secure connection with the first network element device based on the BGP connection, including: the second network element equipment receives a secure connection establishment request sent by the first network element equipment through BGP connection, and establishes secure connection with the first network element equipment according to the secure connection establishment request. In the embodiment of the application, under the condition that the second network element equipment supports the remote proof function, the first network element equipment establishes the secure connection with the second network element equipment, so that the RA process is realized by interacting the first BGP message and the second BGP message based on the secure connection. Therefore, the situation that the safety connection is established but the second network element equipment does not support the remote proving function can be avoided, and the waste of transmission bandwidth and processing resources is avoided.

In an exemplary embodiment, the second network element device supporting the remote attestation function includes: and the version information corresponding to the second network element equipment is matched with the version information corresponding to the remote proof baseline file, and/or the second network element equipment has address family expansion capability. Thus, the second network element device supports the remote attestation functionality including the following three cases.

In the first case, the second network element device supporting the remote proof function means that version information corresponding to the second network element device is matched with version information corresponding to the remote proof baseline file, and the second network element device has address family expansion capability. For the first case, before the first device sends the first BGP message to the second network element device based on the BGP connection, or before the second network element device receives the first BGP message sent by the first network element device based on the BGP connection, referring to fig. 12, the method further includes the following steps 906-914.

906, the first network element device sends a third BGP message to the second network element device through BGP connection, where the third BGP message is configured to instruct to query version information corresponding to the second network element device.

The purpose of the first network element device to query version information corresponding to the second network element device is that: the first network element device needs to determine whether the version information corresponding to the remote proof baseline file is the same as the version information corresponding to the second network element device. And under the condition that the version information corresponding to the remote proof baseline file is the same as the version information corresponding to the second network element equipment, the first network element equipment can use the remote proof baseline file to remotely prove the second network element equipment.

In an exemplary embodiment, the third BGP message includes a third TLV field, which is used to indicate query version information. Illustratively, the third TLV field includes a third type field, a third length field, and a third value field, the third type field carrying a second type value, the second type value being used to indicate query version information or carrying version information, the third length field being used to indicate a length of the third value field, the third value field being used to indicate that the second type value indicates query version information. The third value field illustratively carries a second reference value or alternatively, the third value field is blank to indicate that the second type value indicates query version information. The second reference value includes a value different from the version information and not confused with the version information, and is obtained through configuration or negotiation. In addition, in the case that the third value field is set to null, the third length field is set to zero.

In an exemplary embodiment, the third BGP message is a third update message, which is a BGP message with a message type that is an update type. The third update message includes a third path attribute field, and the third TLV field is located in the third path attribute field. The third path attribute field is the path attribute field shown in fig. 11, the third type field included in the third TLV field is the attribute type field shown in fig. 11, the third length field included in the third TLV field is the attribute length field shown in fig. 11, and the third value field included in the third TLV field is the attribute value field shown in fig. 11. In this case, the third TLV field includes a third type field carrying a second type value of: any one of unregistered type values corresponding to the path attribute field, and the second type value is different from the first type value in the above first BGP message and the second BGP message. Illustratively, the second type value in the present embodiment is 200.

907, the second network element device receives, through BGP connection, the third BGP message sent by the first network element device.

After the first network element device sends the third BGP message through the BGP connection, the second network element device also receives the third BGP message through the BGP connection. The second network element device analyzes the third BGP message, so as to determine that the third BGP message is used to instruct to query version information corresponding to the second network element device.

And 908, the second network element device sends a fourth BGP message to the first network element device through BGP connection, wherein the fourth BGP message carries version information corresponding to the second network element device.

After determining that the third BGP message is used to query version information corresponding to the second network element, the second network element device obtains the version information corresponding to the second network element device, and sends the third BGP message carrying the version information corresponding to the second network element device to the first network element device.

In an exemplary embodiment, the fourth BGP message includes a fourth TLV field, where the fourth TLV field is configured to carry version information corresponding to the second network element device. Illustratively, the version information corresponding to the second network element device includes sub-version information of at least one component in the second network element device, and the sub-version information of any one component in the at least one component includes at least one of a software version and a hardware version. The fourth TLV field is for carrying an information list, the information list comprising at least one information item, any of the at least one information item comprising a component name of any component and sub-version information of any component. For example, the components of the second network element device include a board 1-board N (N is not less than 2 and N is a positive integer), and the information list carried by the fourth TLV field includes N information items, where the N information items are in one-to-one correspondence with the N boards. The first information item comprises a single board 1, a hardware version of the single board 1 and a software version of the single board 1, the second information item comprises a single board 2, a hardware version of the single board 2 and a software version of the single board 2, and the nth information item comprises a single board N, a hardware version of the single board N and a software version of the single board N.

Illustratively, the fourth TLV field includes a fourth type field, a fourth length field, and a fourth value field, where the fourth type field carries a second type value, and the second type value is used to indicate query version information or carries version information, and the second type value is referred to in step 906 above, and is not described herein. The fourth length field is used for indicating the length of the fourth value field, and the fourth value field is used for carrying version information corresponding to the second network element equipment, so that the second type value can be indicated to carry the version information. In the case that the fourth TLV field carries the above-described information list, the information list is carried by a fourth value field included in the fourth TLV field.

In an exemplary embodiment, the fourth BGP message is a fourth update message, which is a BGP message with a message type that is an update type. The fourth update message includes a fourth path attribute field, and the fourth TLV field is located in the fourth path attribute field. The fourth path attribute field is the path attribute field shown in fig. 11, the fourth type field included in the fourth TLV field is the attribute type field shown in fig. 11, the fourth length field included in the fourth TLV field is the attribute length field shown in fig. 11, and the fourth value field included in the fourth TLV field is the attribute value field shown in fig. 11.

909, the first network element device receives the fourth BGP message sent by the second network element device through BGP connection, and parses the fourth BGP message to obtain version information corresponding to the second network element device carried in the fourth BGP message.

Because the second network element device sends the fourth BGP message to the first network element device, the first network element device may receive the fourth BGP message. The first network element device analyzes the fourth BGP message to obtain version information corresponding to the second network element device.

At 910, the first network element device determines that the second network element device supports the remote attestation function in response to the version information corresponding to the second network element device being the same as the version information corresponding to the remote attestation baseline file.

For example, in response to the version information corresponding to the second network element device being the same as the version information corresponding to the remote attestation baseline file, it may be determined that the version information corresponding to the second network element device matches the version information corresponding to the remote attestation baseline file, thereby determining that the second network element device supports the remote attestation function. In an exemplary embodiment, on the basis of determining that the version information corresponding to the second network element device matches the version information corresponding to the remote attestation baseline file, it is further determined that the second network element device has an address family expansion capability, so that it is determined that the second network element device supports the remote attestation function. The manner in which the second network element device is determined to have the address family extension capability is described in steps 911-914 below, and will not be described herein.

In an exemplary embodiment, the version information corresponding to the second network element device is the same as the version information corresponding to the remote attestation baseline file, including: each piece of metric information is consistent with corresponding information in the remote attestation baseline file, the corresponding information being information generated by the same component. Taking the example that the components in the second network element device include the single board 1 and the single board 2, and the version information includes the software version and the hardware version, then: and responding to the fact that the hardware version of the single board 1 in the measurement information is identical to the hardware version of the single board 1 in the remote proving baseline file, the software version of the single board 1 in the measurement information is identical to the software version of the single board 1 in the remote proving baseline file, the hardware version of the single board 2 in the measurement information is identical to the hardware version of the single board 2 in the remote proving baseline file, and the software version of the single board 2 in the measurement information is identical to the software version of the single board 2 in the remote proving baseline file, so that the first network element equipment can determine that the version information corresponding to the second network element equipment is identical to the version information corresponding to the remote proving baseline file.

911, the first network element device sends a fifth BGP message to the second network element device through BGP connection, where the fifth BGP message is used to negotiate address family extension capability with the second network element device.

The first network element device negotiates the address family expansion capability with the second network element device, that is, the first network element device determines whether the second network element device has the capability to support the expanded address family. The expanded address family can be obtained by expanding the address family, and the purpose of expanding the address family is to differentiate services, so that the RA process is realized based on the expanded address family, and other services are realized based on other address families. It should be noted that the command lines configured by the user include a global command line and command lines under the address groups, the global command line being effective for all address groups, and the command lines under the address groups being effective for only a part of the specified address groups. The procedure of the first network element device receiving the user configured command line for the first network element device to act as RA server is described in step 901 above. Illustratively, in the case of expanding an address family, the command line includes a command line under the address family.

In an exemplary embodiment, the fifth BGP message includes at least one first capability subfield, and any one of the at least one first capability subfield carries an address family identifier, where the address family identifier is used to indicate the extended address family. The first network element device informs the second network element device of the expanded address family through the fifth BGP message so that the second network element device can confirm whether the second network element device has the capability of supporting the expanded address family or not, and therefore negotiation of the expanded capability of the address family is achieved.

It can be understood that, the first capability subfield in the fifth BGP message corresponds to the extended address family one to one, and the greater the number of first capability subfields included in the fifth BGP message, the greater the number of extended address families negotiated by the fifth BGP message, which in the embodiment of the present application does not limit the number of first capability subfields. Illustratively, the fifth BGP message includes two first capability subfields, where one first capability subfield carries an internet protocol fourth version (internet protocol version, IPv 4) address family identifier, the IPv4 address family identifier is used to indicate the extended IPv4 address family af-IPv4-RA, and the other first capability subfield carries an internet protocol sixth version (internet protocol version, IPv 6) address family identifier, and the IPv6 address family identifier is used to indicate the extended IPv6 address family af-IPv6-RA. That is, the fifth BGP message is used to negotiate the extended IPv4 address family and the extended IPv6 address family. Wherein, the IPv4 address group af-IPv4-RA and the IPv6 address group af-IPv6-RA are used for realizing the RA procedure. The af-IPv4-RA is the name of the IPv4 address group, the af-IPv6-RA is the name of the IPv6 address group, these two names are merely examples, and the embodiments of the present application are not limited to the names of the IPv4 address group and the IPv6 address group.

In an exemplary embodiment, the fifth BGP message is a first open message. The first open message is a BGP message with an open message type. Referring to fig. 13, a description will be given of a message structure of an open type BGP message. The open type BGP message comprises a BGP message header and message contents corresponding to the open type. As can be seen from the above description in step 901, the BGP header includes a type value field with a value of 1, which is used to indicate that the message type is an open type. The message content corresponding to the open type includes an optional parameter length (optional parameter length) field and an optional parameter (optional parameter) field. The optional parameter length field is used to indicate the length of the optional parameter field. The optional parameter field includes a parameter type (parameter type) field, a parameter length (parameter length) field, and a parameter value (parameter value) field, the parameter type field having a value of 2 for indicating capability negotiation, the parameter length field for indicating the length of the parameter value field, and the parameter value field including at least one capability field. One capability field includes a capability number (capability code) field, a capability length (capability length) field, and a capability value (capability value) field. The capability number field has a value of 1 for indicating a negotiated address family capability, the capability length field for indicating the length of the capability value field, the capability value field including an address family identification (address family identifier, AFI) field, a reserved field for indicating an address family to be negotiated, and a sub-address family identification (sub-address family identifier, SAFI) field, the reserved field being zeroed, the SAFI field for distinguishing between different indicated communication modes including, but not limited to, unicast, multicast, and virtual private networks (virtual private network, VPN).

In an exemplary embodiment, the first open message includes a first optional parameter field in which the at least one first capability subfield is located. The first optional parameter field is an optional parameter field shown in fig. 13, the first capability subfield is a capability field shown in fig. 13, and the address family identifier to be carried by the first capability subfield is an AFI field shown in fig. 13. In the related art, the AFI fields have values of 1, 2 and 196, which are used to indicate the IPv4 address family, the IPv6 address family and the layer 2 (L2), respectively, so that values other than 1, 2 and 196 are used as the address family identifier in the embodiment of the present application to indicate the extended address family. For example, the AFI field has a value of 256 for indicating the extended IPv4 address family and the AFI field has a value of 257 for indicating the extended IPv6 address family. In addition, embodiments of the present application do not limit the communication mode indicated by the SAFI field.

912, the second network element device receives, through BGP connection, a fifth BGP message sent by the first network element device.

The second network element device receives and parses the fifth BGP message, thereby determining that the fifth BGP message is used to negotiate address family extension capability with the first network element device. As can be seen from the above description in step 911, the fifth BGP message includes at least one first capability subfield carrying an address group identifier, and the second network element device can obtain the address group identifier by parsing the fifth BGP message, so as to determine the extended address group indicated by the address group identifier.

913, the second network element device generates a sixth BGP message based on the address family expansion capability of the second network element device, and sends the sixth BGP message to the first network element device through BGP connection.

After the second network element device determines the extended address family, it can be determined by the address family extension capability of the second network element device that the second network element device supports the extended address family. Thus, the second network element device informs the first network element device of the address family that the second network element device is capable of supporting the extension through the sixth BGP message.

In an exemplary embodiment, the second network element device generates a sixth BGP message based on an address family extension capability of the second network element device, including: in response to determining that the second network element device has the address family extension capability, the second network element device sends a sixth BGP message including at least one second capability subfield carrying an address family identifier to the first network element device, that is, the sixth BGP message includes at least one second capability subfield carrying an address family identifier.

The second network element device has address family expansion capability, and includes: the second network element device is capable of supporting at least one address family of the extension indicated by the address family identification. And the second network element device can support the extended address group indicated by the address group identifier, and the second capability subfield included in the sixth BGP message sent by the second network element device to the first network element device includes the address group identifier, where the second capability subfield corresponds to the address group identifier one to one. For example, the fifth BGP message includes two first capability subfields, which respectively carry an IPv4 address family identifier and an IPv6 address family identifier. And in response to the second network element equipment being only capable of supporting the extended IPv4 address group indicated by the IPv4 address group identification, sending a sixth BGP message comprising a second capability subfield carrying the IPv4 address group identification to the first network element equipment. And responding to the expanded IPv4 address group indicated by the IPv4 address group identifier which can be supported by the second network element equipment, and the expanded IPv6 address group indicated by the IPv6 address group identifier can be supported by the second network element equipment, wherein the sixth BGP message sent by the second network element equipment to the first network element equipment comprises two second capability subfields which respectively carry the IPv4 address group identifier and the IPv6 address group identifier.

In an exemplary embodiment, the message type of the sixth BGP message is an open type, the sixth BGP message includes a second optional parameter field, and in response to the sixth BGP message including at least one second capability subfield carrying an address family identifier, the at least one second capability subfield carrying an address family identifier is located in the second optional parameter field. The second optional parameter field is an optional parameter field shown in fig. 13, the second capability subfield is a capability field shown in fig. 13, and the address family identifier to be carried by the second capability subfield is an AFI field shown in fig. 13. The AFI field is described in step 911 above, and will not be described in detail here.

914, the first network element device receives a sixth BGP message sent by the second network element device through BGP connection, and determines, based on the sixth BGP message, that the second network element device has an address family expansion capability, so that the second network element device supports a remote attestation function.

And in response to determining that the second network element equipment has the address family expansion capability based on the sixth BGP message, determining that the second network element equipment supports the remote proving function. On the basis of determining that the second network element device has the address family extension capability, it is further determined that the version information corresponding to the second network element device matches the version information corresponding to the remote attestation baseline file through steps 906-910 above, so as to determine that the second network element device supports the remote attestation function.

In an exemplary embodiment, the first network element device determines, based on the sixth BGP message, that the second network element device has an address family extension capability, including: the first network element device parses the sixth BGP message. And responding to the sixth BGP message to comprise at least one second capability subfield carrying the address family identifier, and determining that the second network element equipment has the address family expansion capability by the first network element equipment. In the case that the sixth BGP message includes the second capability subfield that carries the address group identifier, it is described that the second network element device can support the address group of the extension indicated by the address group identifier, so that it can be determined that the second network element device has an address group extension capability.

It will be appreciated that embodiments of the present application do not limit the order of execution of steps 906-910 and steps 911-914. For example, steps 906-910 are performed first and then steps 911-914 are performed. Alternatively, steps 906-910 may be performed after steps 911-914 are performed. Still alternatively, steps 906-910 and steps 911-914 are performed simultaneously. In summary, after steps 906-910 and steps 911-914 have been performed, it can be determined that the second network element device supports the remote attestation function, so that steps 901-905 above can be performed continuously.

The above step 910 is directed to the case where the version information corresponding to the second network element device is the same as the version information corresponding to the remote attestation baseline file. It should be understood that after steps 906-909 are performed, there may also be a case where the version information corresponding to the second network element device is different from the version information corresponding to the remote attestation baseline file, that is, a case where the version information corresponding to the second network element device does not match the version information corresponding to the remote attestation baseline file. In case of mismatch, the first network element device determines that the second network element device does not support the remote attestation function, and cannot remotely attest to the second network element device, so that the above steps 901-905 do not need to be performed. And, in response to the steps 911-914 being the later steps, the first network element device does not need to execute the steps 911-914 again under the condition of no match, thereby avoiding the waste of processing resources.

The above steps 913 and 914 are directed to the case where the second network element device has address family extension capabilities. It should be appreciated that there may also be situations where the second network element device does not have address family extension capabilities after performing step 911 and step 912. In the case that the second network element device does not have the address group extension capability, the second network element device does not send a sixth BGP message including at least one second capability subfield with the address group identifier to the first network element device as in step 913, but sends a sixth BGP message not including the second capability subfield with the address group identifier to the first network element device. In the case that the message type of the sixth BGP message is an open type, the sixth BGP message includes a second optional parameter field, where the second optional parameter field is null. After the first network element device parses the sixth BGP message, the sixth BGP message does not include at least a second capability subfield with an address group identifier, as in step 914, but does not include the second capability subfield with the address group identifier, so that the first network element device determines that the second network element device does not have an address group extension capability. In the case that the second network element device does not have the address family extension capability, the first network element device determines that the second network element device does not support the remote attestation function and cannot remotely attest to the second network element device, so that the above steps 901-905 do not need to be performed. And, in response to the steps 906-910 being the later-executed steps, the first network element device does not need to execute the steps 906-910 again even if the second network element device does not have the address family expansion capability, thereby avoiding the waste of processing resources.

In the second case, the second network element device supporting the remote attestation function means that version information corresponding to the second network element device is matched with version information corresponding to the remote attestation baseline file. In this case, before the first device sends the first BGP message to the second network element device based on the BGP connection, or before the second network element device receives the first BGP message sent by the first network element device based on the BGP connection, only the steps 906-910 need to be executed, and the steps 911-914 need not be executed. After performing the above steps 906-910, the above steps 901-905 can be continued. In addition, in response to determining that the version information corresponding to the second network element device is different from the version information corresponding to the remote attestation baseline file after performing steps 906-909, the first network element device determines that the second network element device does not support the remote attestation function, cannot perform remote attestation on the second network element device, and does not perform steps 901-905 above.

In the third case, the second network element device supporting the remote attestation function means that the second network element device has an address family expansion capability. In this case, before the first device sends the first BGP message to the second network element device based on the BGP connection, or before the second network element device receives the first BGP message sent by the first network element device based on the BGP connection, only the steps 911-914 need to be performed, and the steps 906-910 need not be performed. After performing steps 911-914 described above, steps 901-905 described above can continue. In addition, in response to determining that the second network element device does not have address family extension capabilities after performing steps 911 and 912, the first network element device determines that the second network element device does not support the remote attestation function, cannot remotely attest to the second network element device, and does not perform steps 901-905 above. In the case that the second network element device does not have the address family extension capability, the sixth BGP message is described in the first case, which is not described herein.

Referring to fig. 14, fig. 14 is a schematic flow chart of a remote attestation result obtained by a remote attestation process between a first network element device and a second network element device, and the remote attestation process is generally described with reference to fig. 14. As shown in fig. 14, the RA procedure includes steps 1401-1412 as follows.

1401, the first network element device is set as a trusted root.

The first network element equipment has a route reflection function. By setting the first network element equipment as a trusted root, the first network element equipment can perform trusted measurement on the second network element equipment, so that an RA process is realized. The second network element device is a device which needs to determine whether the second network element device is in a trusted state, and BGP connection for performing route reflection is established between the first network element device and the second network element device.

1402, the first network element device obtains a remote attestation baseline file.

Illustratively, the first network element device receives a remote attestation baseline file sent by the other device. Or under the condition that the first network element equipment and the second network element equipment are equipment with the same version provided by the same provider, the first network element equipment automatically generates a remote proof baseline file according to the measurement information of the first network element equipment.

The first network element device sends a fifth BGP message to the second network element device to negotiate address family extension capabilities with the second network element device 1403. Step 1403 is described in step 911 above, and will not be described here.

1404, the second network element device sends a sixth BGP message to the first network element device to negotiate address family extension capabilities with the first network element device. Step 1404 is described in step 913 above, and will not be described in detail here.

1405, the first network element device determines whether the second network element device is address family extension capable. The first network element equipment checks the address family expansion capability of the second network element equipment based on the analysis result of the sixth BGP message. If the second network element device has address family extension capabilities, then execution continues with step 1406. If the second network element equipment does not have the address family expansion capability, the first network element equipment determines that the second network element equipment cannot be remotely proved.

1406, the first network element device sends a third BGP message to the second network element device to query version information corresponding to the second network element device. Step 1406 is described in step 906 above and will not be described in detail herein.

1407, the second network element device sends a fourth BGP message to the first network element device, where the fourth BGP message carries version information corresponding to the second network element device. Step 1407 is described in step 908 above, and will not be described here again.

1408, the first network element device determines whether the version information corresponding to the second network element device matches the version information corresponding to the remote certificate. The first network element equipment checks version information corresponding to the second network element equipment based on an analysis result of the fourth BGP message. If the version information corresponding to the second network element device matches the version information corresponding to the remote attestation baseline file, then step 1409 is continuously executed, otherwise, the first network element device determines that remote attestation cannot be performed on the second network element device.

1409, the first network element device establishes a secure connection with the second network element device.

1410, the first network element device sends a first BGP message to the second network element device through the secure connection to query metric information of the second network element device. Step 1410 is described in step 901 above, and will not be described in detail here.

1411, the second network element device sends a second BGP message to the first network element device through the secure connection, where the second BGP message carries metric information of the second network element device. Step 1411 is described in step 903 above and will not be described in detail herein.

1412, the first network element device compares the metric information of the second network element device carried in the second BGP message with the locally stored remote attestation baseline file, to obtain a remote attestation result, where the remote attestation result is used to indicate whether the second network element device is in a trusted state. Step 1412 is described in step 905 above and will not be described in detail herein.

The application method of remote certification provided by the embodiment of the application is introduced, and the embodiment of the application also provides an application device of remote certification corresponding to the method. The device is applied to first network element equipment. The device is used for executing the application method of the remote attestation executed by the first network element equipment in the above-mentioned figure 3 through each module shown in figure 15. As shown in fig. 15, the application device for remote attestation provided in the embodiment of the present application includes the following several modules.

An obtaining module 1501, configured to obtain a remote attestation result corresponding to a second network element device, where the remote attestation result is used to indicate a trusted state of the second network element device, and the trusted state of the second network element device includes trusted, untrusted, or unknown state; for example, the manner in which the obtaining module 1501 obtains the remote attestation result corresponding to the second network element device may refer to the embodiment shown in fig. 9, which is not described herein. Alternatively, the manner in which the obtaining module 1501 obtains the remote attestation result corresponding to the second network element device may refer to the related content of step 301 in the embodiment shown in fig. 3, which is not described herein.

And the management module 1502 is configured to perform route management on the second network element device based on the trusted status of the second network element device indicated by the remote attestation result. The manner in which the management module 1502 performs route management on the second network element device based on the trusted status of the second network element device indicated by the remote attestation result may refer to the relevant content of step 302 in the embodiment shown in fig. 3, which is not described herein.

In an exemplary embodiment, the management module 1502 is configured to obtain routing information corresponding to the second network element device; and managing the routing information corresponding to the second network element equipment according to the configured rule based on the trusted state of the second network element equipment.

In an exemplary embodiment, the configured rules include a route management policy, a management module 1502 for determining a target policy from the route management policy that matches the trusted status of the second network element device; and managing the route information corresponding to the second network element equipment according to the target strategy.

In an exemplary embodiment, the routing information corresponding to the second network element device includes at least one of first routing information, second routing information, third routing information and fourth routing information, where the first routing information is routing information that needs to be published by the second network element device, the second routing information is routing information that has been published by the second network element device, the third routing information is routing information that needs to be received by the second network element device, and the fourth routing information is routing information that has been received by the second network element device; the target policy includes at least one policy of a policy corresponding to the first routing information, a policy corresponding to the second routing information, a policy corresponding to the third routing information, and a policy corresponding to the fourth routing information.

In an exemplary embodiment, the trusted state of the second network element device is that the second network element device is trusted; the strategy corresponding to the first route information is used for indicating to issue the first route information; the strategy corresponding to the second routing information is used for indicating to maintain the second routing information; the strategy corresponding to the third routing information is used for indicating to issue the third routing information to the second network element equipment; the policy corresponding to the fourth routing information is used to indicate that the fourth routing information is maintained.

In an exemplary embodiment, the trusted status of the second network element device is that the second network element device is not trusted; the strategy corresponding to the first route information is used for indicating that the first route information is not issued; the strategy corresponding to the second routing information is used for indicating to cancel the second routing information; the strategy corresponding to the third routing information is used for indicating that the third routing information is not issued to the second network element equipment; the policy corresponding to the fourth routing information is used for indicating to withdraw the fourth routing information.

In an exemplary embodiment, the trusted state of the second network element device is that the state of the second network element device is unknown; the strategy corresponding to the first routing information is used for indicating to release the first routing information and a first priority index, the first priority index is used for indicating the priority of the first routing information, and the priority of the first routing information is lower than the default priority; the strategy corresponding to the second routing information is used for indicating to release the second routing information and a second priority index, the second priority index is used for indicating the priority of the second routing information released at this time, and the priority of the second routing information released at this time is lower than the default priority and lower than the priority of the second routing information released last time; the strategy corresponding to the third routing information is used for indicating to issue the third routing information to the second network element equipment; the policy corresponding to the fourth routing information is used to indicate that the fourth routing information is maintained.

In an exemplary embodiment, the configured rule includes executable code, where the executable code is configured to configure, for routing information corresponding to the second network element device, a priority indicator that matches a trusted state of the second network element device, and the management module 1502 is configured to configure, by running the executable code, a third priority indicator for routing information corresponding to the second network element device, where the third priority indicator is a priority indicator that matches the trusted state of the second network element device, and the third priority indicator is configured to indicate a priority of routing information corresponding to the second network element device; and issuing the routing information and the third priority index corresponding to the second network element equipment.

In an exemplary embodiment, the routing information corresponding to the second network element device includes at least one of first routing information and second routing information, where the first routing information is routing information that needs to be issued by the second network element device, the second routing information is routing information that has been issued by the second network element device, and the third priority index includes at least one index of a priority index corresponding to the first routing information and a priority index corresponding to the second routing information, where the priority index corresponding to the first routing information is used to indicate a priority of the first routing information, and the priority index corresponding to the second routing information is used to indicate a priority of the second routing information.

In an exemplary embodiment, the trusted state of the second network element device is that the second network element device is trusted; the priority of the first routing information and the priority of the second routing information are not lower than the default priority.

In an exemplary embodiment, the trusted status of the second network element device is that the second network element device is not trusted; the priority of the first routing information and the priority of the second routing information are both lower than the default priority.

In an exemplary embodiment, the trusted state of the second network element device is that the state of the second network element device is unknown; the priority of the first routing information and the priority of the second routing information are both lower than the default priority and higher than the priority in case the second network element device is not trusted.

In an exemplary embodiment, the priority indicator is a BGP attribute, and the priority indicator includes a local priority or a multi-exit discriminator, where the greater the value of the local priority, the higher the priority indicated by the local priority, and the smaller the value of the multi-exit discriminator, the higher the priority indicated by the multi-exit discriminator.

In an exemplary embodiment, an acquisition module 1501 is configured to read a remote attestation result acquisition command, where the remote attestation result acquisition command is configured to indicate an acquisition path of a remote attestation result; and acquiring the remote proving result according to the acquisition path indicated by the remote proving result acquisition command.

The remote attestation application apparatus shown in fig. 15 is applied to the first network element device, the structure of the apparatus, the detailed process of interacting with the second network element device, and the detailed process of performing route management on the second network element device by using the remote attestation result, please refer to the descriptions of the embodiments related to fig. 1-3 and 5-8, and are not repeated here. In an exemplary embodiment, the first network element device has a route reflection function, and BGP connection for performing route reflection is established between the first network element device and the second network element device.

It should be understood that, in implementing the functions of the apparatus provided in fig. 15, only the division of the functional modules is illustrated, and in practical application, the functional modules may be allocated to different functional modules according to needs, that is, the internal structure of the apparatus is divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and the method embodiments provided in the foregoing embodiments belong to the same concept, and specific implementation processes of the apparatus and the method embodiments are detailed in the method embodiments and are not repeated herein.

Referring to fig. 16, fig. 16 illustrates a schematic structural diagram of an exemplary remote attestation application device 1600 of the present application, the remote attestation application device 1600 including at least one processor 1601, a memory 1603, and at least one network interface 1604.

The processor 1601 is, for example, a general purpose CPU, digital signal processor (digital signal processor, DSP), network processor (network processer, NP), GPU, neural network processor (neural-network processing units, NPU), data processing unit (Data Processing Unit, DPU), microprocessor, or one or more integrated circuits or application-specific integrated circuits (ASIC) for implementing the present aspects, a programmable logic device (programmable logic device, PLD) or other programmable logic device, transistor logic device, hardware component, or any combination thereof. PLDs are, for example, complex programmable logic devices (complex programmable logic device, CPLD), field-programmable gate arrays (field-programmable gate array, FPGA), general-purpose array logic (generic array logic, GAL), or any combination thereof. Which may implement or perform the various logical blocks, modules, and circuits described in connection with the present disclosure. A processor may also be a combination of computing functions, including for example, one or more microprocessor combinations, a combination of DSPs and microprocessors, and the like.

Optionally, the remotely proven application device 1600 also includes a bus 1602. Bus 1602 is used to transfer information between the components of remotely certified application device 1600. Bus 1602 may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus, or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The bus 1602 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in fig. 16, but not only one bus or one type of bus.

The Memory 1603 is, for example, but not limited to, a read-only Memory (ROM) or other type of storage device that can store static information and instructions, as well as a random access Memory (random access Memory, RAM) or other type of dynamic storage device that can store information and instructions, as well as an electrically erasable programmable read-only Memory (electrically erasable programmable read-only Memory, EEPROM), compact disc (compact disc read-only Memory) or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, blu-ray disc, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory 1603 is, for example, independent and is connected to the processor 1601 via the bus 1602. Memory 1603 may also be integrated with processor 1601.

The network interface 1604 uses any transceiver-like device for communicating with other devices or communication networks, which may be ethernet, radio access network (radio access network, RAN), or wireless local area network (wireless local area network, WLAN), etc. The network interface 1604 may include a wired network interface and may also include a wireless network interface. Specifically, the network interface 1604 may be an Ethernet (Ethernet) interface, such as: fast Ethernet (FE) interfaces, gigabit Ethernet (GE) interfaces, asynchronous transfer mode (Asynchronous Transfer Mode, ATM) interfaces, WLAN interfaces, cellular network interfaces, or combinations thereof. The ethernet interface may be an optical interface, an electrical interface, or a combination thereof. In some embodiments of the present application, the network interface 1604 may be used for the remote attestation of the application device 1600 to communicate with other devices.

In a particular implementation, as some embodiments, the processor 1601 may include one or more CPUs, such as CPU0 and CPU1 shown in fig. 16. Each of these processors may be a single-core processor or a multi-core processor. A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In particular implementations, as some implementations, the remotely certified application device 1600 may include multiple processors, such as processor 1601 and processor 1605 shown in fig. 16. Each of these processors may be a single-core processor or a multi-core processor. A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In some embodiments, memory 1603 is used to store program instructions 1610 that execute aspects of the present application, and processor 1601 may execute program instructions 1610 stored in memory 1603. That is, the remotely proven application device 1600 may implement the method provided by the method embodiment, i.e. the method performed by the first network element device or the second network element device in fig. 3, 9, 12, 14, by the processor 1601 and the program instructions 1610 in the memory 1603. One or more software modules may be included in the program instructions 1610. Alternatively, the processor 1601 may itself store program instructions for performing the present application.

In a specific implementation, the remotely proven application device 1600 of the present application may correspond to the first network element device for performing the method described above, where the processor 1601 in the remotely proven application device 1600 reads the instructions in the memory 1603, so that the remotely proven application device 1600 shown in fig. 16 can perform all or part of the steps in the method embodiment.

The remotely certified application device 1600 may also correspond to the apparatus shown in fig. 15 described above, and each functional module in the apparatus shown in fig. 15 is implemented in software of the remotely certified application device 1600. In other words, the apparatus shown in fig. 15 includes functional modules generated after the processor 1601 of the remotely proven application device 1600 reads the program instructions 1610 stored in the memory 1603.

Wherein the steps of the method shown in fig. 3, 9, 12, 14 are accomplished by instructions in the form of integrated logic circuits or software of hardware in a processor of the remotely proven application device 1600. The steps of an embodiment of a method disclosed in connection with the present application may be embodied directly in a hardware processor or in a combination of hardware and software modules in a processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in the memory, and the processor reads information in the memory, and in combination with the hardware, performs the steps of the above method embodiment, which will not be described in detail herein to avoid repetition.

It is to be appreciated that the processor described above can be a central processing unit (Central Processing Unit, CPU), but also other general purpose processors, digital signal processors (digital signal processing, DSP), application specific integrated circuits (application specific integrated circuit, ASIC), field-programmable gate arrays (field-programmable gate array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or any conventional processor or the like. It is noted that the processor may be a processor supporting an advanced reduced instruction set machine (advanced RISC machines, ARM) architecture.

Further, in an alternative embodiment, the memory may include read only memory and random access memory, and provide instructions and data to the processor. The memory may also include non-volatile random access memory. For example, the memory may also store information of the device type.

The memory may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an electrically Erasable EPROM (EEPROM), or a flash memory. The volatile memory may be random access memory (random access memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available. For example, static RAM (SRAM), dynamic RAM (dynamic random access memory, DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous DRAM (SLDRAM), and direct memory bus RAM (DR RAM).

In an exemplary embodiment, an application system for remote attestation is provided, the system comprising a first network element device and at least one second network element device, the first network element device being communicatively connected to the at least one second network element device, the first network element device being configured to perform the method performed by the first network element device in fig. 3, 9, 12, 14, and the second network element device being configured to perform the method performed by the second network element device in fig. 9, 12, 14.

In an exemplary embodiment, a computer program (product) is provided, the computer program (product) comprising: computer program code which, when run by a computer, causes the computer to perform the method of application of remote attestation performed by the first network element device of figures 3, 9, 12, 14. Or cause the computer to perform the method performed by the second network element device in fig. 9, 12, 14.

In an exemplary embodiment, a computer readable storage medium is provided, the computer readable storage medium storing a program or instructions which, when run on a computer, perform the method performed by the first network element device of fig. 3, 9, 12, 14 described above. Alternatively, the computer performs the method performed by the second network element device in fig. 9, 12 and 14.

In an exemplary embodiment, a chip is provided that includes a processor to invoke from a memory and execute instructions stored in the memory, such that a device on which the chip is installed performs a method performed by a first network element device of fig. 3, 9, 12, 14. Alternatively, the chip-mounted device is caused to perform the method performed by the second network element device of 9, 12, 14.

In an exemplary embodiment, another chip is provided, comprising: the input interface, the output interface, the processor and the memory are connected through an internal connection path, the processor is used for executing codes in the memory, and when the codes are executed, the processor is used for executing the method executed by the first network element device in fig. 3, 9, 12 and 14. Alternatively, the processor is configured to perform the method performed by the second network element device in fig. 9, 12, 14.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Disk), etc.

The terms "first," "second," and the like in this application are used to distinguish between identical or similar items that have substantially the same function and function, and it should be understood that there is no logical or chronological dependency between the "first," "second," and "nth" terms, nor is it limited to the number or order of execution. It will be further understood that, although the following description uses the terms first, second, etc. to describe various elements, these elements should not be limited by the terms. These terms are only used to distinguish one element from another element.

It should also be understood that, in the embodiments of the present application, the sequence number of each process does not mean that the execution sequence of each process should be determined by the function and the internal logic of each process, and should not constitute any limitation on the implementation process of the embodiments of the present application.

The term "at least one" in this application means one or more, the term "plurality" in this application means two or more, for example, a plurality of second devices means two or more second devices. The terms "system" and "network" are often used interchangeably herein.

It is to be understood that the terminology used in the description of the various examples described herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various described examples and in the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The term "and/or" is an association relationship describing an associated object, and means that there may be three relationships, for example, a and/or B, and may mean: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" in the present application generally indicates that the front-rear association object is an or relationship.

It should also be understood that the terms "if" and "if" may be interpreted to mean "when" ("white" or "upon") or "in response to a determination" or "in response to detection. Similarly, the phrase "if determined" or "if [ a stated condition or event ] is detected" may be interpreted to mean "upon determination" or "in response to determination" or "upon detection of [ a stated condition or event ] or" in response to detection of [ a stated condition or event ] "depending on the context.

The foregoing description of the embodiments is merely illustrative of the present application and is not intended to limit the invention to the particular embodiments disclosed, but on the contrary, the intention is to cover all modifications, equivalents, alternatives, and alternatives falling within the spirit and scope of the invention.

Claims

1. A method of remotely proving an application, the method comprising:

the method comprises the steps that a first network element device obtains a remote proving result corresponding to a second network element device, wherein the remote proving result is used for indicating the trusted state of the second network element device, and the trusted state of the second network element device comprises trusted state, untrusted state or unknown state;

and the first network element equipment carries out route management on the second network element equipment based on the trusted state of the second network element equipment indicated by the remote proving result.

2. The method of claim 1, wherein the first network element device performs route management on the second network element device based on the trusted status of the second network element device indicated by the remote attestation result, comprising:

the first network element equipment acquires the routing information corresponding to the second network element equipment;

and the first network element equipment manages the route information corresponding to the second network element equipment according to the configured rule based on the trusted state of the second network element equipment.

3. The method of claim 2, wherein the configured rule includes a route management policy, and wherein the first network element device manages route information corresponding to the second network element device according to the configured rule based on a trusted state of the second network element device, including:

The first network element equipment determines a target strategy matched with the trusted state of the second network element equipment from the route management strategy;

and the first network element equipment manages the route information corresponding to the second network element equipment according to the target strategy.

4. The method of claim 3, wherein the routing information corresponding to the second network element device includes at least one of first routing information, second routing information, third routing information, and fourth routing information, wherein,

the first routing information is routing information that the second network element device needs to issue,

the second routing information is routing information that has been published by the second network element device,

the third routing information is routing information that the second network element device needs to receive,

the fourth routing information is the routing information received by the second network element device;

the target policy includes at least one policy of a policy corresponding to the first routing information, a policy corresponding to the second routing information, a policy corresponding to the third routing information, and a policy corresponding to the fourth routing information.

5. The method of claim 4, wherein the trusted status of the second network element device is that the second network element device is trusted;

The strategy corresponding to the first routing information is used for indicating to issue the first routing information;

the strategy corresponding to the second routing information is used for indicating to maintain the second routing information;

the strategy corresponding to the third routing information is used for indicating to issue the third routing information to the second network element equipment;

and the strategy corresponding to the fourth routing information is used for indicating to maintain the fourth routing information.

6. The method of claim 4, wherein the trusted status of the second network element device is that the second network element device is not trusted;

the strategy corresponding to the first routing information is used for indicating that the first routing information is not issued;

the strategy corresponding to the second routing information is used for indicating to cancel the second routing information;

the policy corresponding to the third routing information is used for indicating that the third routing information is not issued to the second network element equipment;

and the strategy corresponding to the fourth routing information is used for indicating to cancel the fourth routing information.

7. The method of claim 4, wherein the trusted status of the second network element device is unknown to the second network element device status;

the strategy corresponding to the first routing information is used for indicating to release the first routing information and a first priority index, the first priority index is used for indicating the priority of the first routing information, and the priority of the first routing information is lower than a default priority;

The policy corresponding to the second routing information is used for indicating to issue the second routing information and a second priority index, the second priority index is used for indicating the priority of the second routing information issued this time, and the priority of the second routing information issued this time is lower than the default priority and lower than the priority of the second routing information issued last time;

8. The method of claim 2, wherein the configured rule includes executable code for configuring, for routing information corresponding to a second network element device, a priority indicator that matches a trusted state of the second network element device, the first network element device managing the routing information corresponding to the second network element device according to the configured rule based on the trusted state of the second network element device, comprising:

the first network element device configures a third priority index for the routing information corresponding to the second network element device by running the executable code, wherein the third priority index is a priority index matched with the trusted state of the second network element device, and the third priority index is used for indicating the priority of the routing information corresponding to the second network element device;

And the first network element equipment issues the routing information corresponding to the second network element equipment and the third priority index.

9. The method of claim 8, wherein the routing information corresponding to the second network element device includes at least one of first routing information and second routing information, wherein,

the third priority index comprises at least one index of a priority index corresponding to the first routing information and a priority index corresponding to the second routing information, the priority index corresponding to the first routing information is used for indicating the priority of the first routing information, and the priority index corresponding to the second routing information is used for indicating the priority of the second routing information.

10. The method of claim 9, wherein the trusted status of the second network element device is that the second network element device is trusted;

the priority of the first routing information and the priority of the second routing information are not lower than a default priority.

11. The method of claim 9, wherein the trusted status of the second network element device is that the second network element device is not trusted;

the priority of the first routing information and the priority of the second routing information are both lower than a default priority.

12. The method of claim 9, wherein the trusted status of the second network element device is unknown to the second network element device status;

the priority of the first routing information and the priority of the second routing information are both lower than a default priority and higher than the priority in case the second network element device is not trusted.

13. The method according to any of claims 7-12, wherein the priority indicator is a border gateway protocol BGP attribute, and wherein the priority indicator comprises a local priority or a multi-egress discriminator, and wherein the higher the value of the local priority, the higher the priority indicated by the local priority and the lower the value of the multi-egress discriminator, the higher the priority indicated by the multi-egress discriminator.

14. The method according to any one of claims 1-13, wherein the first network element device obtains a remote attestation result corresponding to the second network element device, including:

The first network element device reads a remote proof result acquisition command, wherein the remote proof result acquisition command is used for indicating an acquisition path of the remote proof result;

and the first network element equipment acquires the remote proving result according to the acquisition path indicated by the remote proving result acquisition command.

15. The method according to any of claims 1-14, wherein the first network element device is provided with a route reflection function, and a BGP connection for performing route reflection is established between the first network element device and the second network element device.

16. An application device for remote attestation, the device comprising:

the device comprises an acquisition module, a verification module and a verification module, wherein the acquisition module is used for acquiring a remote proving result corresponding to second network element equipment, the remote proving result is used for indicating the trusted state of the second network element equipment, and the trusted state of the second network element equipment comprises trusted, untrusted or unknown state;

17. The apparatus of claim 16, wherein the management module is configured to obtain routing information corresponding to the second network element device; and managing the routing information corresponding to the second network element equipment according to the configured rule based on the trusted state of the second network element equipment.

18. The apparatus of claim 17, wherein the configured rules comprise a route management policy, the management module configured to determine a target policy from the route management policy that matches the trusted status of the second network element device; and managing the routing information corresponding to the second network element equipment according to the target policy.

19. The apparatus of claim 18, wherein the routing information corresponding to the second network element device includes at least one of first routing information, second routing information, third routing information, and fourth routing information, wherein the first routing information is routing information that the second network element device needs to issue, the second routing information is routing information that the second network element device has issued, the third routing information is routing information that the second network element device needs to receive, and the fourth routing information is routing information that the second network element device has received; the target policy includes at least one policy of a policy corresponding to the first routing information, a policy corresponding to the second routing information, a policy corresponding to the third routing information, and a policy corresponding to the fourth routing information.

20. The apparatus of claim 19, wherein the trusted status of the second network element device is that the second network element device is trusted; the strategy corresponding to the first routing information is used for indicating to issue the first routing information; the strategy corresponding to the second routing information is used for indicating to maintain the second routing information; the strategy corresponding to the third routing information is used for indicating to issue the third routing information to the second network element equipment; and the strategy corresponding to the fourth routing information is used for indicating to maintain the fourth routing information.

21. The apparatus of claim 19, wherein the trusted status of the second network element device is that the second network element device is not trusted; the strategy corresponding to the first routing information is used for indicating that the first routing information is not issued; the strategy corresponding to the second routing information is used for indicating to cancel the second routing information; the policy corresponding to the third routing information is used for indicating that the third routing information is not issued to the second network element equipment; and the strategy corresponding to the fourth routing information is used for indicating to cancel the fourth routing information.

22. The apparatus of claim 19, wherein the trusted status of the second network element device is unknown to the second network element device status; the strategy corresponding to the first routing information is used for indicating to release the first routing information and a first priority index, the first priority index is used for indicating the priority of the first routing information, and the priority of the first routing information is lower than a default priority; the policy corresponding to the second routing information is used for indicating to issue the second routing information and a second priority index, the second priority index is used for indicating the priority of the second routing information issued this time, and the priority of the second routing information issued this time is lower than the default priority and lower than the priority of the second routing information issued last time; the strategy corresponding to the third routing information is used for indicating to issue the third routing information to the second network element equipment; and the strategy corresponding to the fourth routing information is used for indicating to maintain the fourth routing information.

23. The apparatus of claim 17, wherein the configured rule includes executable code for configuring, for routing information corresponding to a second network element device, a priority indicator that matches a trusted state of the second network element device, and wherein the management module is configured to configure, by running the executable code, a third priority indicator for routing information corresponding to the second network element device, wherein the third priority indicator is a priority indicator that matches a trusted state of the second network element device, and the third priority indicator is configured to indicate a priority of routing information corresponding to the second network element device; and releasing the routing information corresponding to the second network element equipment and the third priority index.

24. The apparatus of claim 23, wherein the routing information corresponding to the second network element device includes at least one of first routing information and second routing information, wherein the first routing information is routing information that the second network element device needs to issue, the second routing information is routing information that the second network element device has issued, and the third priority indicator includes at least one of a priority indicator corresponding to the first routing information and a priority indicator corresponding to the second routing information, and the priority indicator corresponding to the first routing information is used for indicating a priority of the first routing information, and the priority indicator corresponding to the second routing information is used for indicating a priority of the second routing information.

25. The apparatus of claim 24, wherein the trusted status of the second network element device is that the second network element device is trusted; the priority of the first routing information and the priority of the second routing information are not lower than a default priority.

26. The apparatus of claim 24, wherein the trusted status of the second network element device is that the second network element device is not trusted; the priority of the first routing information and the priority of the second routing information are both lower than a default priority.

27. The apparatus of claim 24, wherein the trusted status of the second network element device is unknown to the second network element device status; the priority of the first routing information and the priority of the second routing information are both lower than a default priority and higher than the priority in case the second network element device is not trusted.

28. The apparatus of any of claims 22-27, wherein the priority indicator is a border gateway protocol BGP attribute, and wherein the priority indicator comprises a local priority or a multi-exit discriminator, and wherein the greater the value of the local priority, the higher the priority indicated by the local priority and the lesser the value of the multi-exit discriminator, the higher the priority indicated by the multi-exit discriminator.

29. The apparatus of any one of claims 16-28, wherein the acquisition module is configured to read a remote attestation result acquisition command, the remote attestation result acquisition command being configured to indicate an acquisition path for the remote attestation result; and acquiring the remote proving result according to the acquisition path indicated by the remote proving result acquisition command.

30. The apparatus according to any of the claims 16-29, wherein the remote attestation application means is applied to a first network element device, the first network element device having a route reflection function, and a BGP connection for performing route reflection is established between the first network element device and the second network element device.

31. A remotely certified application device, the device comprising a memory and a processor; the memory has stored therein at least one instruction that is loaded and executed by the processor to cause the remotely certified application device to implement the remotely certified application method of any of claims 1-15.

32. A remote attestation application system, characterized in that the system comprises a first network element device and at least one second network element device, the first network element device being communicatively connected to the at least one second network element device, the first network element device being adapted to perform the remote attestation application method of any of the claims 1-15.

33. A computer readable storage medium having stored therein at least one instruction that is loaded and executed by a processor to implement the remote attestation application method of any of claims 1-15.

34. A computer program product, characterized in that it comprises a computer program or instructions that are executed by a processor to cause a computer to implement the method of application of remote attestation as claimed in any of the claims 1-15.