Method for verifying security of autonomous domain and related device

Abstract

The application discloses a security verification method of an autonomous domain and related devices, and belongs to the field of communication technologies. The method comprises the following steps: a first device acquires first trusted routing information from a second device, the first device belongs to a first autonomous domain, the second device belongs to a second autonomous domain, and the first trusted routing information is used for proving the security of the second autonomous domain; and the first device confirms the security of the second autonomous domain based on the first trusted routing information. That is, the trusted routing information which can be transmitted between autonomous domains is used to guarantee the communication security between the autonomous domains and guarantee the security of data packets transmitted between the autonomous domains.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method and apparatus for verifying the security of an autonomous system. Background Technology

[0002] With the development of network technology, more and more offline businesses are moving online, requiring massive amounts of data to be transmitted via the internet, making network security crucial. Currently, the internet contains many Autonomous Systems (AS), also known as Autonomous Domains, and data packets may pass through multiple ASs before reaching their destination. If data packets flow through an insecure AS, data leakage is highly likely. Ensuring the security of data packets transmitted between ASs is a hot research topic in the industry. Summary of the Invention

[0003] This application provides a method and related apparatus for verifying the security of autonomous systems (AS), which can confirm the security of ASs, thereby ensuring the security of data packets transmitted between ASs. The technical solution is as follows:

[0004] In a first aspect, a method for verifying the security of an autonomous system is provided. The method is applied to a first device, which belongs to a first autonomous system. The method includes: obtaining first trusted routing information from a second device, which belongs to a second autonomous system, and the first trusted routing information is used to prove the security of the second autonomous system; and confirming the security of the second autonomous system based on the first trusted routing information.

[0005] In other words, by using trusted routing information that can be transmitted between autonomous systems, the security of communication between autonomous systems is guaranteed, ensuring the security of data packets transmitted between autonomous systems.

[0006] In one possible implementation, the first trusted routing information includes an identifier of a first evaluation rule, the first evaluation rule being a security evaluation rule supported by the second autonomous domain, and the first trusted routing information being determined according to the first evaluation rule; confirming the security of the second autonomous domain based on the first trusted routing information includes: confirming the security of the second autonomous domain based on the first trusted routing information if the first autonomous domain supports the first evaluation rule.

[0007] In this application, security assessment rules can be used to evaluate the security of autonomous systems (AS). Different ASs can support different security assessment rules; in other words, different ASs can support different security assessment rules. When different ASs can support different security assessment rules, the security assessment becomes more flexible and usable.

[0008] In one possible implementation, the first trusted routing information includes an identifier or download address of a verification report, which is used to prove the security of the second autonomous domain. Confirming the security of the second autonomous domain based on the first trusted routing information includes confirming the security of the second autonomous domain based on the identifier or download address of the verification report. In this way, the second autonomous domain does not need to disclose its configuration information to the first autonomous domain, thus ensuring the privacy of the autonomous domain.

[0009] In one possible implementation, the first trusted routing information further includes a timestamp indicating the validity period of the verification report; the step of confirming the security of the second autonomous domain based on the identifier or download address of the verification report includes: if it is determined based on the timestamp that the verification report has not expired, then confirming the security of the second autonomous domain based on the identifier or download address of the verification report.

[0010] In one possible implementation, confirming the security of the second autonomous domain based on the identifier or download address of the verification report includes: sending a verification request to a trusted verification party, the verification request carrying the identifier or download address of the verification report; and receiving a verification result returned by the trusted verification party, the verification result indicating whether the second autonomous domain is secure. That is, by utilizing a trusted verification party to assist in verifying the security of the second autonomous domain, the functional complexity of the first device is reduced.

[0011] In one possible implementation, the verification result includes first indication information indicating whether the second autonomous domain is secure; or, the verification result includes the verification report; or, the verification result includes the trust level of the second autonomous domain.

[0012] In one possible implementation, the first trusted routing information further includes the identifier of the trusted authenticator; before sending the verification request to the trusted authenticator, the method further includes: locating the trusted authenticator based on the identifier of the trusted authenticator.

[0013] In one possible implementation, verifying the security of the second autonomous domain includes: verifying whether the verification report is trustworthy; and / or,

[0014] The verification report records the trust level of the second autonomous domain, and / or the first trusted routing information also includes the trust level of the second autonomous domain. Confirming the security of the second autonomous domain includes: confirming whether the trust level of the second autonomous domain exceeds the trust level threshold.

[0015] In another possible implementation, the first trusted routing information includes the configuration information of the second autonomous domain; the step of confirming the security of the second autonomous domain based on the first trusted routing information includes: performing security verification on the configuration information of the second autonomous domain to confirm the security of the second autonomous domain.

[0016] In one possible implementation, the security verification of the configuration information of the second autonomous domain includes: performing security verification on the configuration information according to a second evaluation rule, wherein the second evaluation rule is a security evaluation rule supported by the first autonomous domain.

[0017] In one possible implementation, the first device is a trusted controller within the first autonomous system (AS). After confirming the security of the second AS based on the first trusted routing information, the method further includes sending confirmation results regarding the security of the second AS to some or all routing devices within the first AS. Thus, by notifying some or all routing devices within the first AS of the security confirmation results of the second AS, a secure communication path is established between the routing devices within the first AS and the second AS.

[0018] In one possible implementation, the confirmation result includes second indication information indicating whether the second autonomous domain is secure; or, the confirmation result includes the trust level of the second autonomous domain.

[0019] In this process, if the confirmation result includes the trust level of the second autonomous domain, the routing devices within the first autonomous domain can select an autonomous domain with an appropriate trust level to establish a reliable communication path for communication services of different importance based on the trust level of the autonomous domain.

[0020] In one possible implementation, the first device is a trusted controller within the first autonomous system (AS), and the second device is a trusted controller within the second AS. Obtaining the first trusted routing information from the second device includes: sending a request to the second device to obtain trusted routing information about the second AS; and receiving the first trusted routing information sent by the second device. That is, this application supports transmitting trusted routing information of an AS through trusted controllers of each AS.

[0021] In one possible implementation, the acquisition request carries an identifier of a second evaluation rule, which is a security evaluation rule supported by the first autonomous system, and the first trusted routing information is obtained when the second autonomous system supports the second evaluation rule.

[0022] In one possible implementation, after confirming the security of the second autonomous system based on the first trusted routing information, the method further includes: if the security of the second autonomous system is confirmed, sending a path establishment request to the second device, the path establishment request carrying first path parameters; receiving second path parameters returned by the second device in response to the path establishment request; and sending a third path parameter to a first routing device to instruct the first routing device to establish a communication path with the second autonomous system using the third path parameter, wherein the third path parameter is determined based on the second path parameter, and the first routing device is a routing device within the first autonomous system. That is, this application can achieve secure communication path establishment by transmitting path establishment parameters between autonomous systems through a trusted orchestrator within the autonomous system.

[0023] In another possible implementation, the first device is a trusted controller within the first autonomous system (AS), and the second device is a routing device within the second AS. Obtaining the first trusted routing information from the second device includes: receiving trusted routing information for one or more ASs reported by the second routing device, wherein the trusted routing information for the one or more ASs includes the first trusted routing information. The second routing device is a routing device within the first AS, and the trusted routing information for the one or more ASs is obtained from routing messages. The first trusted routing information is added to the routing messages by the second device. That is, this application supports the transmission of trusted routing information for an AS by a routing device within an AS via routing messages.

[0024] The second autonomous domain is any autonomous domain on the transmission path of the routing message.

[0025] Wherein, the trusted routing information of the one or more autonomous systems refers to the trusted routing information of some or all autonomous systems covered by the transmission path of the routing message.

[0026] In one possible implementation, the routing message is a Border Gateway Protocol (BGP) update message.

[0027] In one possible implementation, the routing message carries trusted routing information path attributes, which include an attribute type code field, an attribute length field, and an attribute value field; the attribute type code field indicates the type of information in the attribute value field; the attribute length field indicates the length of the attribute value field; and the attribute value field carries trusted routing information for the one or more autonomous systems.

[0028] In one possible implementation, the attribute value field includes one or more attribute value subfields, which carry trusted routing information for the one or more autonomous systems. Each attribute value subfield carries trusted routing information for one autonomous system, and different attribute value subfields carry trusted routing information for different autonomous systems.

[0029] In one possible implementation, the trusted routing information includes the identifier of the corresponding autonomous system.

[0030] In one possible implementation, the trusted routing information includes a signature of the trusted routing information by the corresponding autonomous system.

[0031] In another possible implementation, the routing message carries BGP secure path attributes, which include a secure path field and a signature field. The secure path field carries trusted routing information for the one or more autonomous systems, and the signature field carries a signature of the secure path field.

[0032] In one possible implementation, the secure path field includes one or more secure path segments, wherein one secure path segment corresponds to an autonomous system on the transmission path of the routing message, different secure path segments correspond to different autonomous systems, and some or all of the one or more secure path segments carry trusted routing information of the one or more autonomous systems.

[0033] In one possible implementation, each secure path segment includes an autonomous system identifier field that carries the identifier of the corresponding autonomous system.

[0034] In one possible implementation, each secure path segment includes a flag field, which includes a trusted routing enable bit. The trusted routing enable bit indicates that the corresponding secure path segment also includes a trusted routing information field, which carries trusted routing information of the corresponding autonomous system, or indicates that the corresponding secure path segment does not carry trusted routing information.

[0035] In one possible implementation, the trusted routing information of the one or more autonomous systems is received after the second routing device has verified the signature; and / or,

[0036] The operation of confirming the security of the second autonomous domain based on the first trusted routing information is performed after the first device has verified the signature.

[0037] Secondly, a method for verifying the security of an autonomous system (AS) is provided. The method is applied to a second routing device belonging to a first AS. The method includes: receiving a first routing message sent by a third routing device, the first routing message carrying trusted routing information of one or more ASs, the trusted routing information of the one or more ASs including first trusted routing information, the first trusted routing information being trusted routing information of a second AS, the first trusted routing information being used to prove the security of the second AS, and the third routing device being a peer of the second routing device; reporting the trusted routing information of the one or more ASs to a first trusted controller, the first trusted controller being a trusted controller within the first AS; and receiving an acknowledgment result sent by the first trusted controller, the acknowledgment result including an acknowledgment of the security of the second AS.

[0038] In other words, after receiving trusted routing information of the second autonomous region from other routing devices through routing messages, the routing devices in the first autonomous region can verify the trusted routing information of the second autonomous region through the trusted controller in the first autonomous region, thereby obtaining a confirmation result on the security of the second autonomous region and ensuring subsequent secure inter-domain communication.

[0039] In one possible implementation, the second autonomous region is any autonomous region on the transmission path of the first routing message.

[0040] In one possible implementation, the trusted routing information of the one or more autonomous systems is the trusted routing information of some or all of the autonomous systems covered by the transmission path of the first routing message.

[0041] In one possible implementation, the first routing message is a BGP update message.

[0042] In one possible implementation, the first routing message carries a trusted routing information path attribute, which includes an attribute type code field, an attribute length field, and an attribute value field.

[0043] The attribute type code field indicates the type of information in the attribute value field;

[0044] The attribute length field indicates the length of the attribute value field;

[0045] The attribute value field carries trusted routing information for the one or more autonomous systems.

[0046] In one possible implementation, the attribute value field includes one or more attribute value subfields, which carry trusted routing information for the one or more autonomous systems. Each attribute value subfield carries trusted routing information for one autonomous system, and different attribute value subfields carry trusted routing information for different autonomous systems.

[0047] In one possible implementation, the trusted routing information includes the identifier of the corresponding autonomous system.

[0048] In one possible implementation, the trusted routing information includes a signature of the trusted routing information by the corresponding autonomous system.

[0049] In one possible implementation, the first routing message carries BGP security path attributes, which include a security path field and a signature field. The security path field carries the routing information, and the signature field carries a signature of the security path field.

[0050] In one possible implementation, the secure path field includes one or more secure path segments, wherein one secure path segment corresponds to an autonomous system on the transmission path of the first routing message, different secure path segments correspond to different autonomous systems, and some or all of the one or more secure path segments carry trusted routing information of the one or more autonomous systems.

[0051] In one possible implementation, each secure path segment includes an autonomous system identifier field that carries the identifier of the corresponding autonomous system.

[0052] In one possible implementation, each secure path segment further includes a flag field, which includes a trusted routing enable bit. The trusted routing enable bit indicates that the corresponding secure path segment also includes a trusted routing information field, which carries trusted routing information of the corresponding autonomous system, or indicates that the corresponding secure path segment does not carry trusted routing information.

[0053] In one possible implementation, the trusted routing information of the one or more autonomous systems is reported after the second routing device verifies the signature.

[0054] In one possible implementation, after receiving the first routing message sent by the third routing device, the method further includes: updating the first routing message, adding second trusted routing information to the updated first routing message, the second trusted routing information being trusted routing information of the first autonomous system; and sending the updated first routing message to a fourth routing device, the fourth routing device being another peer of the second routing device.

[0055] In one possible implementation, the transmission path of the first routing message covers multiple autonomous systems, including the second autonomous system. The first routing message does not carry trusted routing information for some or all of the autonomous systems other than the second autonomous system. Updating the first routing message includes adding the second trusted routing information to the first routing message and adding trusted routing information for some or all of the autonomous systems, wherein the trusted routing information for some or all of the autonomous systems is a default value.

[0056] In one possible implementation, the first routing message carries trusted routing information path attributes, which carry an attribute flag field and an attribute value field. The attribute flag field includes partial bits, and the partial bits indicate that the trusted routing information path attributes have not been recognized by the third routing device. The attribute value field carries trusted routing information of the one or more autonomous systems. Updating the first routing message further includes modifying the partial bits, wherein the modified partial bits indicate that the trusted routing information routing attributes have been recognized by the second routing device and the content has been confirmed to be complete.

[0057] In one possible implementation, the method further includes: generating a second routing message, the second routing message carrying second trusted routing information, the second trusted routing information being trusted routing information of the first autonomous system; and transmitting the second routing message to a fifth routing device, the fifth routing device being a peer of the second routing device.

[0058] In one possible implementation, the method further includes: receiving a third routing message sent by a sixth routing device, the sixth routing device being a peer of the second routing device, the third routing message not carrying trusted routing information; updating the third routing message, the updated third routing message carrying second trusted routing information, the second trusted routing information being trusted routing information of the first autonomous system; and sending the updated third routing message to a seventh routing device, the seventh routing device being another peer of the second routing device.

[0059] In one possible implementation, updating the third routing message includes: adding the second trusted routing information to the third routing message, and adding trusted routing information of autonomous systems other than the first autonomous system whose transmission path of the third routing message has been covered, wherein the trusted routing information of the autonomous systems other than the first autonomous system is a default value.

[0060] In one possible implementation, the first trusted routing information includes an identifier of a first evaluation rule, the first evaluation rule being a security evaluation rule supported by the second autonomous system, the first trusted routing information being determined according to the first evaluation rule, the second autonomous system supporting a second evaluation rule, and the second evaluation rule being the same as or different from the first evaluation rule.

[0061] In this application, security assessment rules can be used to evaluate the security of autonomous systems (AS). Different ASs can support different security assessment rules; in other words, different ASs can support different security assessment rules. When different ASs can support different security assessment rules, the security assessment becomes more flexible and usable.

[0062] In one possible implementation, the first trusted routing information includes an identifier or download address of a verification report, which is used to prove the security of the second autonomous domain. In this way, the second autonomous domain does not need to disclose its configuration information to the first autonomous domain, thus ensuring the privacy of the autonomous domain.

[0063] In one possible implementation, the first trusted routing information further includes a timestamp indicating the validity period of the verification report.

[0064] In one possible implementation, the verification report records the trust level of the second autonomous domain, and / or the first trusted routing information also includes the trust level of the second autonomous domain.

[0065] Based on this, if the confirmation result regarding the security of the second autonomous domain includes the trust level of the second autonomous domain, the routing device in the first autonomous domain can select an autonomous domain with an appropriate trust level to establish a reliable communication path for communication services of different importance based on the trust level of the autonomous domain.

[0066] In one possible implementation, the first trusted routing information further includes the identifier of a trusted verifier, which is used by the first trusted controller to verify the trusted routing information of the one or more autonomous systems through the trusted verifier to obtain the confirmation result.

[0067] Thirdly, a security verification device for an autonomous system (AS / RS) is provided, which has the function of implementing the AS / RS security verification method described in the first aspect. In one implementation, the AS / RS security verification device includes one or more modules for implementing the AS / RS security verification method provided in the first aspect.

[0068] Fourthly, a security verification device for an autonomous system (AS / RS) is provided, which has the function of implementing the AS / RS security verification method behavior described in the second aspect above. In one implementation, the AS / RS security verification device includes one or more modules for implementing the AS / RS security verification method provided in the second aspect above.

[0069] Fifthly, a communication device is provided, comprising a processor and a memory, the memory storing a program for executing the autonomous system security verification method provided in the first aspect, and storing data related to implementing the autonomous system security verification method provided in the first aspect. The processor is configured to execute the program stored in the memory.

[0070] In one possible implementation, the communication device may further include a communication bus for establishing a connection between the processor and the memory.

[0071] In a sixth aspect, a communication device is provided, comprising a processor and a memory, the memory being used to store a program for executing the autonomous system security verification method provided in the second aspect, and to store data related to implementing the autonomous system security verification method provided in the second aspect. The processor is configured to execute the program stored in the memory.

[0072] In one possible implementation, the communication device may further include a communication bus for establishing a connection between the processor and the memory.

[0073] In a seventh aspect, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to perform the autonomous system security verification method described in the first or second aspect above.

[0074] Eighthly, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to perform the autonomous system security verification method described in the first or second aspect above.

[0075] The technical effects achieved by the third to eighth aspects mentioned above are similar to those achieved by the corresponding technical means in the first and second aspects, and will not be repeated here. Attached Figure Description

[0076] Figure 1 This is a schematic diagram illustrating the format of a customizable AS_PATH path attribute provided in an embodiment of this application;

[0077] Figure 2This is a schematic diagram illustrating the format of an extensible BGPsec_Path attribute provided in an embodiment of this application;

[0078] Figure 3 This is a schematic diagram of an implementation environment provided in an embodiment of this application;

[0079] Figure 4 This is a schematic diagram of another implementation environment provided in the embodiments of this application;

[0080] Figure 5 This is a schematic diagram of another implementation environment provided in the embodiments of this application;

[0081] Figure 6 This is a schematic diagram of another implementation environment provided in the embodiments of this application;

[0082] Figure 7 This is a schematic diagram of another implementation environment provided in the embodiments of this application;

[0083] Figure 8 This is a flowchart of a security verification method for an autonomous system provided in an embodiment of this application;

[0084] Figure 9 This is a schematic diagram of the format of a custom trusted routing information path attribute provided in an embodiment of this application;

[0085] Figure 10 This is a schematic diagram illustrating the format of an extended BGPsec_Path attribute provided in an embodiment of this application;

[0086] Figure 11 This is a flowchart of another autonomous domain security verification method provided in the embodiments of this application;

[0087] Figure 12 This is a flowchart of another autonomous system security verification method provided in the embodiments of this application;

[0088] Figure 13 This is a flowchart of another autonomous system security verification method provided in the embodiments of this application;

[0089] Figure 14 This is a schematic diagram of the structure of a security verification device for an autonomous region provided in an embodiment of this application;

[0090] Figure 15 This is a schematic diagram of the structure of another autonomous domain security verification device provided in the embodiments of this application;

[0091] Figure 16 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0092] Figure 17This is a schematic diagram of the structure of another communication device provided in the embodiments of this application;

[0093] Figure 18 This is a schematic diagram of the structure of another communication device provided in the embodiments of this application;

[0094] Figure 19 This is a schematic diagram of the structure of an interface board in a communication device provided in an embodiment of this application. Detailed Implementation

[0095] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0096] First, some of the terms used in the embodiments of this application will be explained.

[0097] 1. Trustworthy routing

[0098] Trusted routing is a mechanism that ensures the reliability of data transmission paths (also known as communication paths) in a network.

[0099] 2. Remote attestation

[0100] Remote attestation is a security protocol used to verify the authenticity and status of remote systems or devices. It primarily involves three key roles: the attester, the verifier, and the relying party. In the remote attestation process, the attester provides credible information (i.e., evidence) about its own state or attributes. The relying party needs to verify the evidence provided by the attester to confirm its authenticity and thus determine the attester's trustworthiness. This process is assisted by a third party (i.e., the verifier), who is responsible for checking the evidence provided by the attester to confirm its authenticity.

[0101] In other words, the proving party is the device that needs to prove its state or attributes, typically by generating evidence containing information about its current state. The verifying party is responsible for verifying the evidence provided by the proving party to confirm whether the proving party's state or attributes meet expectations. The dependent party is the party that ultimately relies on the proving party's state or attribute information to make decisions, such as an application or service provider.

[0102] There are two common models for remote authentication technology: the passport model and the background-check model.

[0103] In the passport model, the prover first sends a request to the verifier to generate evidence containing information about its state or attributes. Upon receiving the request, the verifier generates and signs a proof (called a verification report or "passport") and returns it to the prover. The prover then sends this "passport" to the dependent party, which verifies its validity by checking the signature and decides whether to trust the prover. The advantage of this model is that the dependent party does not need to communicate directly with the verifier, simplifying the management of the trust chain.

[0104] In contrast, the background checking model is more direct. In this model, the proving party directly sends its state or attribute information (i.e., evidence) to the dependent party. The dependent party then forwards this information to the validator for verification. After verification, the validator directly returns the result to the dependent party. The dependent party then decides whether to trust the proving party based on the verification result. The advantage of the background checking model is that it can provide more real-time verification of state and attribute information, but it also requires a direct communication channel between the dependent party and the validator.

[0105] 3. BGP peer

[0106] BGP peers are two routing devices in a network that directly exchange routing information using the BGP protocol. There are two types of BGP peers: internal BGP peers and external BGP peers. Internal BGP peers consist of two routing devices belonging to the same autonomous system (AS), while external BGP peers consist of two routing devices belonging to different ASs.

[0107] 4. Trust Orchestrator (TO)

[0108] A TO, also known as a trust controller, is an entity within an autonomous system that performs functions such as evaluating, transmitting, and acquiring trusted routing information. A TO can provide trusted routing-related services to devices within the autonomous system and communicate with TOs in other autonomous systems.

[0109] In the embodiments of this application, each autonomous domain in the autonomous system can be a large heterogeneous network, and the embodiments of this application do not limit the system architecture within each autonomous domain.

[0110] The relevant technologies of the embodiments of this application will be described below.

[0111] With the development of cloud computing and other network technologies, more and more offline businesses are moving online. Massive amounts of sensitive data need to be transmitted over the network and stored on servers, which brings additional security risks. Currently, AI-enabled big data analytics can extract vast amounts of sensitive information from limited data sets. Meanwhile, the threat of quantum computing is increasingly looming, and some organizations are beginning to store encrypted data for future analysis after decryption. Much of this data has a confidentiality period of decades, and once compromised, it can easily cause serious security incidents. Therefore, existing internet forwarding mechanisms are no longer effective in preventing these threats, necessitating further enhancements to the security and trustworthiness of network data forwarding processes to ensure that data transmission does not pass through untrusted devices, organizations, or regions.

[0112] Trusted routing technology is one of the core technologies of future networks such as 5G and 6G. It emphasizes that the authenticity of Internet Protocol (IP) addresses is the foundation for building a trusted network, and uses a series of technologies to ensure the uniqueness of network address identities and the authenticity of routing locations. However, most existing research on trusted routing focuses on architectural design, neglecting its integration with existing network environments and protocols. Therefore, researching trusted routing schemes that adapt to current network architectures and are compatible with existing network protocols is of great significance.

[0113] Against this backdrop, embodiments of this application can establish BPG-related standards and address routing security issues through remote verification. Embodiments of this application aim to provide trust level assessments and evidence for routing paths between autonomous systems, the integrity of routing paths, and proof that data packets have traversed such paths. This includes: allowing clients to select the desired security attributes of the network services they receive; achieving reliable forwarding by routing only on devices that meet specific trust requirements; and proving to clients that certain data packets or flows have traversed network paths with specific trust or security attributes. Furthermore, high-trust-level logical paths can be established between autonomous systems using low-trust-level physical paths.

[0114] BGP (the protocol defined by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 4271) is a standardized exterior gateway protocol used for routing between autonomous systems on the Internet. BGP's main function is to exchange routing information between different ASes to achieve efficient data packet transmission on the Internet. BGP is one of the most important routing protocols on the current Internet; it supports classless inter-domain routing (CIDR), can handle large-scale routing tables, and has high flexibility and scalability.

[0115] BGP communicates via Transmission Control Protocol (TCP) connections, ensuring the reliability and security of data transmission. Each BGP router maintains a routing table, recording the optimal path to each network. BGP's routing process is based on a series of complex attributes and policies, including path length, network policies, and route priorities. These characteristics enable BGP to adapt to complex network environments and meet the needs of different network operators.

[0116] BGP update messages are one of the core message types in the BGP protocol, used to exchange routing information between BGP peers. A BGP update message contains the following main parts:

[0117] 1. Withdrawn routes: Contains a list of route prefixes that are no longer valid.

[0118] 2. Path attributes: Contains various attributes related to new or updated routes, such as next-hop address, AS path, local priority, etc. Each attribute has a type code, length, and value.

[0119] 3. Network layer reachability information (NLRI): Lists reachable network prefixes (a range of IP addresses).

[0120] The path attributes include the AS_PATH attribute. The AS_PATH attribute gives the AS number of the autonomous systems traversed by the path. When a BGP router propagates a BGP update message to the next external peer, it adds the AS number of its own autonomous system to the beginning of the AS_PATH attribute.

[0121] The processing procedure for BGP update messages includes:

[0122] 1. Reception and parsing: After receiving a BGP update message, the BGP router first parses the various fields in the message.

[0123] 2. Route Update: Update the routing table based on the resolution results, remove invalid routes, and add new routes.

[0124] 3. Policy Application: Apply local routing policies to determine whether to add the new route to the routing table.

[0125] 4. Propagation: If the new route meets the propagation conditions, the BGP router will forward it to other BGP peers.

[0126] The BGP protocol is extensible, primarily in that BGP update messages support custom path attributes, with the format shown below. Figure 1 As shown. See also Figure 1 The path attribute includes four fields: attribute flags (Attr.Flags), attribute type code (Attr.Type Code), attribute length (Attr.Length), and attribute value (Attr.Value). The attribute flags field is 1 8-bit byte long, the attribute type code field is 1 8-bit byte long, the attribute length field is 1 or 2 8-bit bytes long, and the length of the attribute value field is determined by the attribute length field.

[0127] The attribute flags include the following:

[0128] 1. The highest bit is the optional bit, which defines whether the attribute is optional (set to 1) or well-known (set to 0).

[0129] Any BGP implementation must support all well-known properties, but optional properties may not be supported by some implementations.

[0130] 2. The second bit is the transitive bit, which defines whether the attribute is transitive (set to 1) or non-transitive (set to 0).

[0131] If a BGP router (which may be simply called a router) receives an unrecognized optional attribute with a pass bit of 1, then the router should accept the attribute and propagate it to other peers.

[0132] If a router receives an unrecognized optional attribute and the pass bit is 0, the router should ignore the attribute and not propagate it to other peers.

[0133] For well-known properties, the pass bit must be set to 1.

[0134] 3. The third bit is the partial bit, which defines whether the attribute content is complete (set to 0) or incomplete (set to 1).

[0135] If the router propagates received unrecognized optional transit attributes to other peers, some bits need to be set to 1.

[0136] If a router propagates a received, identifiable, optional transit attribute to other peers, and some of its bits are 1, then those bits need to be set to 0.

[0137] If an optional transitive attribute is added to the path attribute in the path (rather than being added by the originating router), then some bits must be set to 1.

[0138] For well-known properties and optional non-transitive properties, some bits need to be set to 0.

[0139] 4. The fourth bit is the extended length bit, which defines whether the attribute length field occupies 1 8-bit byte (set to 0) or 2 bytes (set to 1).

[0140] 5. The others are currently undefined.

[0141] As the foundation of internet routing, BGP also faces several security challenges, such as route hijacking, path tampering, and denial-of-service attacks. To address these risks, Resource Public Key Infrastructure (RPKI) was proposed to verify ownership of IP addresses, Autonomous System Numbers (AS numbers), and other information. RPKI uses public key technology to authorize source routes for IP addresses (clarifying which IP addresses can be published by which autonomous systems). RPKI provides source route verification methods for the BGP protocol.

[0142] On top of the RPKI system, BGPsec (RFC8205) was proposed and used for path verification in the BGP protocol. BGPsec requires RPKI to issue BGPsec router certificates to BGP routers, and simultaneously updates the AS_PATH attribute to the BGP secure path (sec_Path) attribute. The BGPsec_Path attribute adds a signature of the routing information calculated using the router certificate's private key to the original AS_PATH attribute, thereby ensuring that each autonomous system on the path recognizes the path from the source router to its predecessor.

[0143] The format of the BGPsec_Path attribute is as follows: Figure 2 As shown. See also Figure 2 The BGPsec_Path attribute includes a Secure_Path field and one or two Sequence of Signature_Blocks fields. These one or more Sequence of Signature_Blocks fields can be called signature fields, and they carry a signature of the Secure_Path field.

[0144] The Secure_Path field includes a Secure_Path Length field and one or more Secure_Path Segments. The number of Secure_Path Segments is N, where N is a positive integer. Each Secure_Path Segment includes a pCount field, a Flags field, and an Autonomous System ID field. The Flags field includes a 1-bit Confed_Segment Flag and a 7-bit Unassigned flag. The Signature Block Sequence field includes a Signature Block Length field, an Algorithm Suite Identifier field, and a Sequence of Signature Segments field. The Sequence of Signature Segments field includes N signature segments corresponding one-to-one with the N Secure_Path Segments. Each signature segment includes a subject key identifier (SKI), a signature length field, and a signature.

[0145] For a detailed introduction to BGP path attributes, please refer to the relevant standard technologies. This application will not provide further explanation in this regard.

[0146] The autonomous system security verification method provided in this application can carry trusted routing information of the autonomous system by customizing the BGP path attribute, or by extending the BGPsec_Path attribute, thereby transmitting trusted routing information between autonomous systems through BGP update messages.

[0147] Because the BGP protocol defines many optional and extended capabilities, RFC 5492 defines a capabilities parameter for mutually announcing supported protocol capabilities in the BGP open message used to establish peer relationships. Building upon this, RFC 8205 further defines BGPsec Capability for announcing the BGPsec capabilities supported by routers. Embodiments of this application can extend BGPsec Capability to announce between BGP peers whether they support the aforementioned custom BGP path attribute or the extended BGPsec_Path attribute.

[0148] The implementation environment of the embodiments of this application will be described next.

[0149] Figure 3 This is a schematic diagram of an implementation environment provided in an embodiment of this application. See also... Figure 3 The implementation environment includes a first device 301 and a second device 302. The first device 301 belongs to a first autonomous domain, and the second device 302 belongs to a second autonomous domain. The first device 301 and the second device 302 can communicate with each other.

[0150] The second device 302 is used to provide trusted routing information of the second autonomous system to the first device 301. The first device 301 is used to obtain the trusted routing information from the second device 302 according to the technical solution provided in the embodiments of this application, and to confirm the security of the second autonomous system based on the trusted routing information. For details of the specific implementation, please refer to the method embodiments below.

[0151] In one possible implementation, the security of the second autonomous domain is autonomously verified by the first device 301.

[0152] In another possible implementation, see Figure 4 The implementation environment also includes a trusted verification party 303. The first device 301 can establish a communication connection with the trusted verification party 303. The first device 301 can request the trusted verification party 303 to assist in verifying the security of the second autonomous domain and receive the verification result returned by the trusted verification party 303. The trusted verification party 303 is used to help the first device 301 verify the security of the second autonomous domain. That is, the first device 301 acts as the dependent party of remote proof, the second device 302 acts as the proving party of remote proof, and the trusted verification party 303 acts as the verifying party of remote proof. The trusted verification party 303 assists in verifying the security of the second autonomous domain, thereby reducing the functional complexity of the local system of the autonomous domain. The following embodiments will be described using the implementation environment including the trusted verification party 303 as an example.

[0153] In this context, the trusted verification party can be a party independent of any autonomous domain (e.g., Figure 4 (As shown), the trusted authenticator can be a third authenticator, or it can be a trusted authenticator within a certain autonomous system (AS). Although the trusted authenticator within an AS is a device within that AS, its functionality is equivalent to that of a third authenticator. As an example, the trusted authenticator is a trusted authenticator within a first AS, such as a trusted orchestrator within the first AS, or it could be another device within the first AS. This application does not limit this. In the following embodiments, the trusted authenticator will be described using a third authenticator as an example.

[0154] In this embodiment, the first device can be a trusted orchestrator (denoted as the first TO, or the first trusted controller) within the first autonomous system (AS), or a routing device within the first AS. When the first device is the first TO, the first TO performs the function of verifying the trusted routing information of the second AS, thereby achieving separation of the data plane and control plane, reducing the functional complexity of the routing device. This solution can be implemented by adding trusted routing information-related functions to an existing network controller. The following embodiments will all use the first TO as an example for description.

[0155] The second device in this embodiment can be a trusted orchestrator (denoted as the second TO, or the second trusted controller) within the second autonomous system, or a routing device (such as a border routing device) within the second autonomous system. Based on this, the following will describe different scenarios.

[0156] For the first scenario, see [link / reference] Figure 5 The first device 301 is the first TO, and the second device 302 is the second TO.

[0157] The first TO is used to send a request to the second TO to obtain trusted routing information about the second autonomous system, and to receive trusted routing information about the second autonomous system returned by the second TO.

[0158] For the second scenario, see [link / reference]. Figure 6 The first device 301 is the first TO, and the second device 302 is a routing device within the second autonomous system, such as routing device 1.

[0159] Taking routing device 1 in the second autonomous system as an example, routing device 1 is used to transmit trusted routing information of the second autonomous system to the second routing device in the first autonomous system through routing messages. The routing message may carry trusted routing information of one or more autonomous systems. The second routing device is used to report the trusted routing information of the one or more autonomous systems to the first TO. The trusted routing information of the one or more autonomous systems includes the trusted routing information of the second autonomous system.

[0160] In this embodiment, the second device 302 and the second routing device can be a pair of peers (such as BGP peers), or they can be separate entities; this embodiment does not impose any limitations on this. Based on this, the transmission path of the trusted routing information of the second autonomous system before reaching the second routing device may only cover the second device 302, or it may also cover other routing devices. That is, the trusted routing information of the second autonomous system is transmitted to the second routing device via the second device 302 and other routing devices.

[0161] Furthermore, it should be understood that the trusted routing information of one or more autonomous systems can be carried in the routing message to transmit the trusted routing information of the autonomous system. The transmission path of the routing message before reaching the first autonomous system can cover only the second autonomous system or cover multiple autonomous systems, where the second autonomous system is any one of the multiple autonomous systems.

[0162] Since the purpose of this application's embodiments is to achieve secure communication between autonomous systems (AS), and the bridge for communication between ASs is the routing device within the AS. Therefore, see further... Figure 5 and Figure 6 The implementation environment may further include one or more routing devices within a first autonomous system (SAS) and one or more routing devices within a second SAS. A first TO can establish a communication connection with one or more routing devices within the first SAS, and a second TO can establish a communication connection with one or more routing devices within the second SAS. Any routing device within the first SAS can be used to establish a trusted communication path with a routing device within the second SAS, provided that the first TO has successfully verified the security of the second SAS, thereby achieving a secure communication connection.

[0163] In the case where the first device 301 is the first TO, see Figure 7 The implementation environment may also include a TO (Telematics Registry) whereby a TO within any Autonomous System (AS) can send a registration request to the TO Registry, which may carry the TO's address (e.g., an IP address). The TO Registry receives and responds to registration requests from TOs within each AS. A TO within any AS can also request the addresses of TOs in other ASs from the TO Registry, thereby enabling communication with TOs in other ASs based on their addresses.

[0164] It should be understood that the TO registry can be regarded as a centralized service provider, and the process by which a TO requests the addresses of other TOs from the TO registry can be called the TO service discovery process.

[0165] The aforementioned TO can be any type of control device or controller, and the embodiments of this application do not limit the structure and form of the TO. Any of the aforementioned routing devices can be a conventional router, a switch, or other routing switching devices, and the embodiments of this application also do not limit the structure and form of the routing device.

[0166] It should be understood that the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0167] The following section describes the autonomous system security verification method provided in the embodiments of this application.

[0168] Figure 8 This is a flowchart illustrating a security verification method for an autonomous system (AS / RS) provided in an embodiment of this application. This method can be applied to any of the implementation environments described above. The steps of this method can be executed by a first device, which belongs to a first AS / RS. Please refer to... Figure 8 The method includes the following steps.

[0169] Step 801: The first device obtains the first trusted routing information from the second device. The first device belongs to the first autonomous system, and the second device belongs to the second autonomous system. The first trusted routing information is used to prove the security of the second autonomous system.

[0170] Based on the previous introduction to the implementation environment, there are multiple ways to implement step 801. Two of these methods will be introduced below.

[0171] The first implementation involves a first device being a trusted controller (denoted as the first TO) within a first autonomous system (AS), and a second device being a trusted controller (denoted as the second TO) within a second AS. The first device obtains first trusted routing information from the second device, including: the first device sending a request to the second device to obtain trusted routing information about the second AS, and receiving the first trusted routing information sent by the second device. Upon receiving the request, the second device can send the first trusted routing information back to the first device.

[0172] In one possible implementation, before the first device sends a request to the second device for trusted routing information about the second autonomous system, it may send a request to the TO registry for the address of the second device and receive the address of the second device returned by the TO registry. The address of the second device is an address that can locate the second device, such as an IP address or other possible address.

[0173] It should be understood that the TO registry keeps a record of the addresses of TOs that have registered with it, including the addresses of the first TO and the second TO. Upon receiving a request to obtain the address of the second device, the TO registry can look up the address of the second TO in its records and send that address to the first TO.

[0174] In this embodiment, security assessment rules can be used to evaluate the security of autonomous systems (AS). Different ASs can support different security assessment rules; in other words, different ASs can support different security assessment rules, or they can support the same security assessment rules. When different ASs can support different security assessment rules, the security assessment becomes more flexible and usable.

[0175] As an example, if Autonomous System 1 has higher security requirements than Autonomous System 2, then Autonomous System 1 can assess the security of Autonomous System 3 using the higher security assessment rules, while Autonomous System 2 can assess it using the lower security assessment rules. The assessment results from Autonomous System 1 and Autonomous System 2 may be completely different. For example, Autonomous System 1 might assess Autonomous System 3 as insecure, while Autonomous System 2 might assess it as secure. Another example is that Autonomous System 1's assessment gives Autonomous System 3 a trust level of five, while Autonomous System 2's assessment gives it a trust level of two. Level five security is lower than level two security.

[0176] Based on this, the request sent by the first device to the second device for obtaining trusted routing information about the second autonomous system (AS) can carry the identifier of the second evaluation rule. The second evaluation rule is a security evaluation rule supported by the first AS, and the first trusted routing information is obtained when the second AS supports the second evaluation rule. That is, if the first AS and the second AS support the same security evaluation rule (including the case where they are the same), the first AS and the second AS can further perform a process to verify the security of the second AS.

[0177] If the second autonomous system does not support the second evaluation rule, the second device can return a rejection message to the first device, indicating that the second device refuses to send trusted routing information of the second autonomous system to the first device. After receiving the rejection message, the first device can determine that the security verification of the second autonomous system has failed.

[0178] In this embodiment of the application, the security verification method for the autonomous system can adopt remote proof technology. Based on the above introduction to remote proof, there are two types of remote proof models: one is the passport model and the other is the background check model. Based on this, the contents of the first trusted routing information are different, which will be introduced separately below.

[0179] In relevant implementations of the passport model, the first trusted routing information includes the identifier (ID) or download address (e.g., a Uniform Resource Locator (URL)) of the verification report, which is used to prove the security of the second autonomous domain. It should be understood that this verification report is obtained by a trusted verifier (hereinafter referred to as the verifier) ​​evaluating and signing the configuration information of the second autonomous domain. The configuration information of the second autonomous domain may include one or more of the physical configuration information, status information, and attribute information of routing devices within the second autonomous domain. In some embodiments, it may also include information such as the type and bandwidth of transmission media such as network cables and optical fibers within the second autonomous domain.

[0180] The verification report may record the trust level of the second autonomous domain. This trust level is obtained by the trusted verification party by evaluating the configuration information of the second autonomous domain according to the security assessment rules (also known as trust level assessment rules) supported by the second autonomous domain.

[0181] In cases where different autonomous systems can support different security assessment rules, the first trusted routing information may also include the identifier of the first assessment rule, which is the assessment rule supported by the second autonomous system.

[0182] In one possible implementation, the first trusted routing information may also include a trust level. In this way, the receiver can directly see the trust level given by the second autonomous system from the first trusted routing information. If the trust level given by the second autonomous system is lower than the trust level threshold, the first device can directly determine that the second autonomous system is insecure without further verification. Of course, it can also continue to perform subsequent verification operations.

[0183] In one possible implementation, the first trusted routing information may further include a timestamp indicating the validity period of the aforementioned verification report. If the timestamp indicates that the verification report has expired, the first device can directly determine that the second autonomous system is insecure without further verification; alternatively, it can continue with subsequent verification operations. Alternatively, if the timestamp indicates that the verification report has expired, the first device can resend a request to the second device for new trusted routing information.

[0184] In one possible implementation, the first trusted routing information may further include the identifier of the trusted authenticator (such as name, ID, or URL), which is the party that provided the aforementioned verification report. It should be understood that the implementation environment may include one or more trusted authenticators; whether there are one or more trusted authenticators, the first trusted routing information may include the identifier of the trusted authenticator that provided the aforementioned verification report.

[0185] In the implementation of the background inspection model, the first trusted routing information may include the configuration information of the second autonomous system.

[0186] In one possible implementation, the first trusted routing information may further include a first evaluation rule and / or a timestamp, where the first evaluation rule is the security evaluation rule supported by the second autonomous system, and the timestamp indicates the time when the configuration information in the first trusted routing information was collected.

[0187] In addition, regardless of the remote authentication model, the first trusted routing information may also include the identifier of the second autonomous system, such as the second autonomous system number (AS number).

[0188] The second implementation: The first device is a trusted controller (denoted as the first TO) within the first autonomous system, and the second device is a routing device within the second autonomous system; the first device obtains the first trusted routing information from the second device, including: receiving trusted routing information of one or more autonomous systems reported by the second routing device, wherein the trusted routing information of one or more autonomous systems includes the first trusted routing information, the second routing device is a routing device within the first autonomous system, and the trusted routing information of one or more autonomous systems is obtained from a routing message, wherein the first trusted routing information is added to the routing message by the second device.

[0189] It should be understood that, in addition to including trusted routing information for one or more autonomous systems, the routing message may also include other information. For example, the routing message may be a single packet containing a header and a payload, with the payload including trusted routing information for one or more autonomous systems. The second routing device can receive the complete routing message and, upon receipt, directly report it to the first TO, or it can extract the trusted routing information for one or more autonomous systems from the routing message and report it to the first TO.

[0190] In this scenario, the second routing device and the second device are a peer (e.g., a BGP peer), and the routing message is sent directly from the second device to the second routing device. Alternatively, the second routing device and the second device are not a peer, and the routing message is passed from the second device to other routing devices, and then from other routing devices to the second routing device.

[0191] In one possible implementation, the second autonomous domain is any autonomous domain on the transmission path of the routing message, such as the first autonomous domain on the transmission path, or a non-first autonomous domain on the transmission path.

[0192] The trusted routing information of the aforementioned one or more autonomous systems refers to the trusted routing information of some or all autonomous systems covered by the transmission path of the routing message. For example, the transmission path of the routing message may cover one or more autonomous systems, and the routing message carries trusted routing information of all autonomous systems covered by the transmission path, or carries trusted routing information of autonomous systems within the autonomous systems covered by the transmission path that support trusted routing information-related functions. It should be understood that the second autonomous system is any one of the one or more autonomous systems, and the first device can perform security verification according to the technical solution provided in the embodiments of this application for any trusted routing information of any autonomous system carried by the routing message.

[0193] As described above, embodiments of this application can extend BGP update messages to achieve the transmission of trusted routing information. Therefore, in some embodiments, the aforementioned routing message can be a BGP update message. As also described above, embodiments of this application can carry trusted routing information of an autonomous system by customizing the BGP path attribute, or by extending the BGPsec_Path attribute. These will be described in detail below.

[0194] The first implementation method is to carry trusted routing information of the autonomous system by customizing the path attributes of BGP.

[0195] In other words, the above routing message carries trusted routing information path attributes, which are custom BGP routing attributes.

[0196] Figure 9 This is a schematic diagram illustrating the format of a trusted routing information path attribute provided in an embodiment of this application. See also... Figure 9 The trusted routing information path attributes include an attribute type code field, an attribute length field, and an attribute value field (also called a trusted routing information segment); the attribute type code field indicates the type of information in the attribute value field; the attribute length field indicates the length of the attribute value field; the attribute value field carries trusted routing information for one or more autonomous systems. The lengths of these three fields can be set according to relevant technologies, which will not be described in detail in this embodiment.

[0197] Combination Figure 1 And refer to Figure 9It is understood that the custom trusted routing information path attribute may also include an attribute flag field. In some embodiments, the 2-byte field formed by the attribute flag field and the attribute type code field can be called the attribute type field.

[0198] In this embodiment, the attribute flag field includes an optional bit and a transmission bit. The optional bit indicates that the trusted routing information path attribute is an optional attribute, and the optional attribute indicates that the corresponding path attribute is allowed to be unsupported; the transmission bit indicates that the trusted routing information path attribute needs to be continued to be transmitted by the second routing device (i.e., the recipient of the path attribute) to other peers of the second routing device.

[0199] In simple terms, the path attributes of trusted routing information are optional and transitive attributes. For example... Figure 9 As shown, the optional and transit bits in the trusted routing information path attribute can be set to 1 according to the relevant BGP standards.

[0200] In addition to the optional bits and the transmission bits, the attribute flag field also includes a part bit. The part bit indicates that the trusted routing information path attribute has not been recognized by the third routing device, or indicates that the trusted routing information routing attribute has been recognized by the third routing device and the content has been confirmed to be complete. The third routing device is the upstream routing device of the second routing device on the transmission path of the above-mentioned routing message.

[0201] In the trusted routing information path attribute, some bits can be set to 1 or 0 according to the relevant BGP standards. 1 indicates that the trusted routing information path attribute has not been recognized by the third routing device, and 0 indicates that the trusted routing information routing attribute has been recognized by the third routing device and its content has been confirmed to be complete.

[0202] In addition, the attribute flag field also includes an extended length bit, which indicates the number of bytes occupied by the attribute length field.

[0203] The extended length bit can be set to 0 or 1 according to the relevant BGP standards. 0 indicates that the attribute length field occupies 1 8-bit byte (i.e., 1 byte), and 0 indicates that the attribute length field occupies 2 8-bit bytes (i.e., 2 bytes).

[0204] See Figure 9 The remaining 4 bits of the attribute flag field can be set to 0 according to the relevant BGP standards.

[0205] As discussed above, routing messages can carry trusted routing information for one or more autonomous systems (AS). Therefore, the aforementioned attribute value fields can include one or more attribute value subfields (which can be called trusted routing information subfields). These one or more attribute value subfields carry trusted routing information for one or more ASs along the transmission path of the routing message. Specifically, one attribute value subfield carries trusted routing information for one AS, and different attribute value subfields carry trusted routing information for different ASs. For example... Figure 9 As shown, the trusted routing information segment includes N trusted routing information subfields, where N is a positive integer.

[0206] To distinguish the N trusted routing information subfields, the trusted routing information can include the identifier of the corresponding autonomous system, such as... Figure 9 As shown, trusted routing information may include the corresponding Autonomous System number (AS number).

[0207] In addition to including the identifier of the corresponding autonomous system, the trusted routing information may, in one possible implementation, also include the signature of the corresponding autonomous system on the trusted routing information. Based on this, the trusted routing information of one or more autonomous systems may be received by the second routing device after the signature in the routing message has been verified, and / or, the first device may subsequently verify the signature, and after successful verification, execute step 802.

[0208] Based on the preceding description of the contents that the first trusted routing information may include, see [link to previous text]. Figure 9 The trusted routing information in the path message may also include the identifier (name or ID) of the authenticator, the identifier (ID) or download address of the authentication report, the identifier (ID) of the trust level assessment rule, the trust level, and a timestamp. The identifier (name or ID) of the authenticator, the identifier (ID) of the trust level assessment rule, the trust level, and the timestamp are all optional.

[0209] The second implementation method is to carry trusted routing information of the autonomous system by extending the BGPsec_Path attribute.

[0210] That is, the routing message carries BGP security path attributes, which include a security path field and a signature field. The security path field carries trusted routing information for one or more autonomous systems, and the signature field carries a signature on the security path field. Based on this, the trusted routing information for one or more autonomous systems can be received by the second routing device after the signature in the signature field has been verified; and / or, the first device can subsequently verify the signature, and after successful verification, execute step 802.

[0211] It should be understood that this implementation method can reuse the original signature of the BGPsec_Path attribute. In the relevant implementation, the trusted routing information can be added to the secure path field.

[0212] Combination Figure 2 It is known that the security path field of the BGPsec_Path attribute includes one or more security path segments. One security path segment corresponds to an autonomous system on the transmission path, and different security path segments correspond to different autonomous systems. Based on this, in the embodiments of this application, the security path field in the above-mentioned routing message includes one or more security path segments, and some or all of the security path segments in the above-mentioned one or more security path segments carry trusted routing information of the above-mentioned one or more autonomous systems.

[0213] Each secure path segment includes an autonomous system identifier field, which carries the identifier of the corresponding autonomous system.

[0214] In one implementation, the extended BGPsec_Path attribute in this embodiment can serve as a new version of the BGPsec_Path attribute, which can replace the existing (i.e., older) BGPsec_Path attribute that does not contain trusted routing information. Based on this, routing devices compatible with the new version of the BGPsec_Path attribute can add corresponding secure path segments to routing messages and write trusted routing information for their own autonomous system into the added secure path segments.

[0215] Depend on Figure 2 It is also known that each secure path segment includes a flag field. Based on this, in another implementation, a trusted routing enable bit can be defined in the flag field; that is, the flag field can include a trusted routing enable bit. The trusted routing enable bit indicates that the corresponding secure path segment also includes a trusted routing information field, which carries trusted routing information for the corresponding autonomous system, or indicates that the corresponding secure path segment does not carry trusted routing information. It should be understood that this implementation can be achieved through negotiation among multiple parties (including multiple autonomous systems). After successful negotiation, routing devices within each autonomous system can be upgraded to recognize the newly defined trusted routing enable bit. Correspondingly, BGPsecCapability can be updated to define whether the trusted routing enable bit is supported.

[0216] As an example, see Figure 10 The second bit in this flag field can be set as the trusted routing enable bit (denoted as E_T_RFlag). The trusted routing enable bit is 0 or 1. 0 indicates that the corresponding secure path segment does not carry trusted routing information, and 1 indicates that the corresponding secure path segment also includes a trusted routing information field. The trusted routing information field carries the trusted routing information of the corresponding autonomous system.

[0217] In addition, the aforementioned signature field includes one or more signature subfields (e.g., Figure 2 The sequence of N signature segments (the one or more signature subfields in the sequence) can be in one or two groups. Each group contains one or more signature subfields that correspond one-to-one with the one or more secure path segments mentioned above. Each signature subfield carries the signature of the corresponding autonomous system for the corresponding secure path segment. If there are two groups, the signature algorithms used in the two groups may be different.

[0218] contrast Figure 9 and Figure 10 It can be seen that in the custom BGP path attributes, trusted routing information can carry the autonomous system number and signature, while in the extended BGP secure path attributes, trusted routing information can not carry the autonomous system number and signature, but instead reuse the autonomous system number and signature in the defined BGP secure path attributes.

[0219] In addition to customizing or extending existing attributes of BGP update messages in the above embodiments, the embodiments of this application may also carry trusted routing information through newly defined messages, or by extending other existing defined messages to carry trusted routing information, without limitation.

[0220] Step 802: The first device confirms the security of the second autonomous domain based on the first trusted routing information.

[0221] After obtaining the first trusted routing information, the first device can confirm the security of the second autonomous domain based on the first trusted routing information.

[0222] If the first trusted routing information includes the identifier of the first evaluation rule, then, if the first autonomous system supports the first evaluation rule, the first device confirms the security of the second autonomous system based on the first trusted routing information. The first evaluation rule is a security evaluation rule supported by the second autonomous system, and the first trusted routing information is determined according to the first evaluation rule.

[0223] The embodiments of this application do not limit the specific content of the security assessment rules. The security assessment rules can be flexibly set and selectively supported according to needs.

[0224] If the first trusted routing information includes an identifier or download address for a verification report, the first device verifies the security of the second autonomous system based on that identifier or download address. The verification report is used to prove the security of the second autonomous system.

[0225] If the first trusted routing information also includes a timestamp (indicating the validity period of the verification report), and if it is determined based on the timestamp that the verification report has not expired, the first device confirms the security of the second autonomous system based on the identifier or download address of the verification report.

[0226] In one possible implementation, the first device sends a verification request to the trusted authenticator and receives the verification result returned by the trusted authenticator.

[0227] The verification request carries the identifier or download address of the verification report, and the verification result indicates whether the second autonomous domain is secure.

[0228] In some embodiments, the verification request also carries an identifier of a second autonomous system (DAS) to identify the object being verified. In other embodiments, the verification request may not carry the identifier of the second DAS; the trusted verification party can assist in verification based on the identifier or download address of the received verification report.

[0229] In one possible implementation, the trusted verifier stores verification reports for one or more autonomous systems, including verification reports for a second autonomous system. Based on this, the trusted verifier can read the verification report based on its identifier or download address.

[0230] If the first trusted routing information also includes the identifier of the trusted authenticator, then before the first device sends the aforementioned authentication request to the trusted authenticator, it can first locate the trusted authenticator based on the identifier of the trusted authenticator.

[0231] As an example, the first device stores a mapping between the identifiers and addresses of one or more trusted authenticators. The first device can obtain the address of the trusted authenticator from the mapping based on the identifier of the trusted authenticator included in the first trusted routing information, and locate the trusted authenticator based on the obtained address.

[0232] In one possible implementation, the verification report includes the signature of the trusted verifier who issued the verification report, and the trusted verifier who assists the first device in verifying that the trusted verifier who issued the verification report is the same as the trusted verifier who issued the verification report.

[0233] After reading the verification report, the trusted authenticator can verify the signature to ensure the report's authenticity or trustworthiness, such as confirming whether the report has been tampered with. Alternatively, after reading the verification report, the trusted authenticator can directly return a verification result to the first device based on the report. This verification result may include first indication information indicating whether the second autonomous system (AAS) is secure; or the verification result may include the verification report itself, meaning the complete report is sent directly to the first device—this process can be understood as the first device downloading the report from the trusted authenticator; or the verification result may include the trust level of the second AAS, meaning the complete verification report is not sent to the first device.

[0234] As an example, the first indication message can carry "yes" or "no", where "yes" indicates that the second autonomous region is secure, and "no" indicates that the second autonomous region is insecure.

[0235] If the verification result includes the first indication information, the first device determines whether the second autonomous region is secure or insecure based on the first indication information.

[0236] If the verification result includes the verification report, the first device obtains the security assessment result of the second autonomous domain from the verification report and confirms whether the second autonomous domain is secure based on the security assessment result. The security assessment result may include the trust level of the second autonomous domain, and the first device can confirm the security of the second autonomous domain based on the trust level. Alternatively, the security assessment result may directly state whether the second autonomous domain is secure or insecure.

[0237] As described above, in one implementation, the verification report may record the trust level of the second autonomous system (SAS), and / or the first trusted routing information may include the trust level of the second SAS. Based on this, the first device can ultimately obtain the trust level of the second SAS. After obtaining the trust level of the second SAS, the first device can determine whether the second SAS is secure based on the trust level. Specifically, if the trust level of the second SAS exceeds the trust level threshold, the second SAS is secure; if the trust level of the second SAS does not exceed the trust level threshold, the second SAS is insecure.

[0238] In one possible implementation, the verification request may also carry the trust level expected by the first autonomous domain. The expected trust level is the trust level that satisfies the requirements of the first autonomous domain for secure communication. After receiving the verification request and obtaining the trust level of the second autonomous domain, the trusted verification party can determine whether the trust level of the second autonomous domain is a trust level expected by the first autonomous domain. If so, it returns the trust level of the second autonomous domain to the first device; otherwise, it returns an indication message to the first autonomous domain indicating that the second autonomous domain is insecure. Alternatively, it may return the trust level of the second autonomous domain to the first device.

[0239] If the first trusted routing information includes the configuration information of the second autonomous domain, the first device can perform security verification on the configuration information of the second autonomous domain to confirm the security of the second autonomous domain.

[0240] In one possible implementation, the first device can perform security verification on the aforementioned configuration information according to a second evaluation rule, where the second evaluation rule is a security evaluation rule supported by the first autonomous system. That is, the first device performs security verification on the aforementioned configuration information itself.

[0241] In another possible implementation, the first device can send the aforementioned configuration information and the security assessment rules supported by the first autonomous system (AS) to any trusted authenticator, requesting the trusted authenticator to perform security verification on the configuration information according to the security assessment rules supported by the first AS, and return the verification result to the first device. Alternatively, the first device may not send the security assessment rules supported by the first AS to the trusted authenticator, and the trusted authenticator may perform security verification on the configuration information according to security assessment rules supported by all ASs.

[0242] The verification result obtained by performing security verification on the configuration information may include the security level of the second autonomous domain, and / or may indicate whether the second autonomous domain is secure.

[0243] When the trust level of the second autonomous domain is obtained by performing security verification on the configuration information, the first device can determine whether the second autonomous domain is secure based on the trust level of the second autonomous domain.

[0244] It should be understood that the first device can also verify the security of the second autonomous domain on its own based on the first trusted routing information, without relying on any verification party.

[0245] In summary, confirming the security of the second autonomous domain in this embodiment may include: confirming whether the verification report is trustworthy. And / or, the verification report records the trust level of the second autonomous domain, and / or, the first trusted routing information also includes the trust level of the second autonomous domain. Confirming the security of the second autonomous domain may include: confirming whether the trust level of the second autonomous domain exceeds the trust level threshold.

[0246] When the first device is a trusted controller within the first autonomous system, after confirming the security of the second autonomous system based on the first trusted routing information, the first device may send the confirmation result regarding the security of the second autonomous system to some or all of the routing devices in the first autonomous system.

[0247] Specifically, after determining the trust level of the second autonomous domain through security verification, the first device can send the trust level of the second autonomous domain to some or all of the routing devices in the first autonomous domain, that is, announce the trust level of the second autonomous domain to these routing devices. Alternatively, the first device can announce to these routing devices whether the second autonomous domain is secure. In other words, the above confirmation result may include the trust level of the second autonomous domain, or it may include second indication information indicating whether the second autonomous domain is secure.

[0248] Based on this, when a routing device that receives the aforementioned confirmation result needs to communicate with the second autonomous region, it can determine whether it can establish a communication connection with the second autonomous region based on the confirmation result. Specifically, if the confirmation result includes the trust level of the second autonomous region, and the trust level of the second autonomous region exceeds the trust level threshold, then the aforementioned routing device can establish a communication path with routing devices within the second autonomous region.

[0249] It is worth noting that, since the first autonomous domain in this embodiment can verify the security of other autonomous domains, in one implementation, the routing device in the first autonomous domain can obtain the trust levels of the other autonomous domains. Based on this, the trust levels of each autonomous domain can serve as the basis for routing by the routing device in the first autonomous domain. For example, the routing device can select a target autonomous domain to establish a communication path based on the importance or priority of the communication service and the trust levels of each autonomous domain. For instance, for communication services with high importance, an autonomous domain with a higher trust level can be selected as the target autonomous domain; for communication services with low importance, an autonomous domain with a lower trust level can be selected as the target autonomous domain.

[0250] This application does not limit the total number of trust levels. In one implementation, the total number of trust levels is at least 2. When the total number of trust levels is greater than 2, the granularity of distinguishing the security of autonomous systems according to trust levels is finer, and the routing device can select routes more flexibly and reliably.

[0251] Taking the establishment of a communication path between a first autonomous system (AS) and a second AS as an example, the first implementation of establishing this communication path is as follows: After confirming the security of the second AS, a first device (which may be the first TO) sends a path establishment request to a second device (which may be the second TO). This path establishment request carries first path parameters. The first device receives second path parameters returned by the second device in response to the path establishment request and sends third path parameters to the first routing device, instructing the first routing device to use the third path parameters to establish a communication path with the second AS. Here, the first routing device is a routing device within the first AS, and the communication path is established based on the first and second path parameters.

[0252] The third path parameter is determined based on the second path parameter. In one implementation, the third path parameter is the same as the second path parameter; in another, the first device processes the second path parameter to obtain the third path parameter. For example, if some parameters in the second path parameter need to be confirmed by the first device, the first device, after confirming some parameters in the second path parameter, uses the remaining parameters as the third path parameter. Or, if the second path parameter includes some parameters already present in the first routing device, the first device can delete those parameters from the second path parameter and use the remaining parameters as the third path parameter. The methods for processing the second path parameter include, but are not limited to, the two examples above.

[0253] The process of the first routing device establishing a communication path with the second autonomous system using the second path parameters can be as follows: the first routing device sends a path establishment request to a peer in the second autonomous system using the second path parameters. The peer responds to the path establishment request by obtaining the first path parameters from the second TO and establishing a communication path with the first routing device using the first path parameters.

[0254] In the above implementation, the first path parameter can be determined by the first device, such as the first TO. The first TO can generate the first path parameter based on the relevant configuration information of the first routing device. Alternatively, the first path parameter can be generated by the first routing device and then sent to the first TO.

[0255] Taking the establishment of a communication path between the first autonomous domain and the second autonomous domain as an example, the second implementation of establishing the communication path is as follows: The first device configures the first routing device to receive the target type connection, and sends the parameters of the target type connection to the second TO. After verifying the parameters of the target type connection, the second TO instructs a routing device (a peer of the first routing device) in the second autonomous domain to initiate a path establishment request to the first routing device. The first routing device responds to the path establishment request and establishes a communication path with the routing device in the second autonomous domain.

[0256] The two methods for establishing communication paths described above are only used to exemplify the technical solutions of the embodiments of this application and are not intended to limit the embodiments of this application. That is, the specific connection process of the communication path can be flexibly configured according to the selected path type (such as tunnel type) and actual needs.

[0257] In this application embodiment, the aforementioned communication path can be a tunnel, such as an Internet Protocol Security (IPSec) tunnel or other types of tunnels, such as IPIP, SIT, GRE, GRE over IPsec, etc., and this application embodiment does not limit this. Wherein, IPIP stands for IPv4 in IPv4, IPv4 stands for Internet protocol version 4, SIT stands for Simple Internet Transition, and GRE stands for Generic Routing Encapsulation.

[0258] Next, please combine... Figure 11 and Figure 12 The technical solutions of the embodiments of this application will be described again by way of example.

[0259] Figure 11 This is a flowchart of another autonomous system security verification method provided in this application embodiment. See also... Figure 11 The method includes the following steps.

[0260] 0. TO registration agencies should pre-register TO addresses for each autonomous region for subsequent TO service discovery.

[0261] 1. The TO1 of Autonomous Domain A (hereinafter referred to as Domain A) requests the TO address of Autonomous Domain B (hereinafter referred to as Domain B) from the TO registry.

[0262] 2. The TO registry returns the address of TO2 of autonomous domain B to TO1.

[0263] 3. TO1 requests trusted routing information for autonomous system B from TO2. The request message may carry one or more trust level assessment rule IDs supported by TO1.

[0264] 4. TO2 returns trusted routing information for autonomous system B that meets the requirements of TO1 to TO1. The content of the trusted routing information can be found in the example above.

[0265] 5. TO1 determines the timeliness of the verification report based on the timestamp contained in the trusted routing information (if it has expired, the trusted routing information is discarded).

[0266] 6. TO1 locates the trusted verifier requesting verification based on information such as verifier name, ID, or URI (if not supported, the trusted routing information is discarded).

[0267] 7. TO1 sends a verification request to the located trusted verification party. The verification request may include the autonomous system number to be verified, the verification report ID, etc. It is understandable that if the trusted routing information contains the address of the verification report, then in this step, TO1 can also send that address or download and send the corresponding verification report.

[0268] 8. The trusted verification party obtains the verification report and verifies its contents.

[0269] 9. The trusted verification direction TO1 returns the verification result, which may include the verified trust level.

[0270] 10. TO1 sends a trust level update message to one or more BGP routers in the autonomous system (BGP router 1 is used as an example in the figure). The message includes the trust level of autonomous system B.

[0271] 11. After receiving the trust level update message, BGP router 1 updates the trust level of the target autonomous system (autonomous system B) recorded locally.

[0272] 12. TO1 sends a trusted tunnel establishment request to TO2. The trusted tunnel can be an IPsec tunnel. The request can include the identifier of Autonomous System A, trusted tunnel establishment parameter 1, etc.

[0273] 13. TO2 verifies the trusted tunnel establishment request of TO1.

[0274] 14. After the trusted tunnel establishment request is verified, TO2 sends trusted tunnel establishment parameter 1 to BGP router 2 in autonomous system B.

[0275] 15. TO2 sends Trusted Tunnel Establishment Parameter 2 to TO1.

[0276] 16. TO1 sends Trusted Tunnel Establishment Parameter 2 to BGP Router 1 (or possibly another BGP router within Autonomous System A).

[0277] 17. BGP Router 1 and BGP Router 2 establish a trusted tunnel that provides bidirectional communication capabilities using their respective trusted routing establishment parameters.

[0278] 18. BGP Router 1 and BGP Router 2 announce the successful establishment of the trusted tunnel, and establish a BGP connection on the tunnel and forward data.

[0279] Combination Figure 11It can be seen that, Figure 11 In the illustrated embodiment, after the TOs of two autonomous systems discover each other, they can send trusted routing information to each other through network connections, and then negotiate to establish an encrypted tunnel (i.e., a trusted tunnel) between BGP routers as a logical link with a high level of trust connecting the two BGP routers, thereby achieving secure communication between the domains.

[0280] Figure 12 This is a flowchart of another autonomous system security verification method provided in this application embodiment. See also... Figure 12 The method includes the following steps.

[0281] 1. BGP router 2 in autonomous system B sends a BGP update message to BGP router in autonomous system A. This message carries trusted routing information for autonomous system B.

[0282] 2. Based on the BGP update message, BGP router 1 identifies autonomous systems along the route that do not support trusted routing and sets the trust level of these autonomous systems to the default value of 0. The specific implementation process will be described in detail in the following embodiments.

[0283] 3. BGP router 1 verifies the signature in the message.

[0284] 4. After the signature verification is successful, BGP router 1 reports trusted routing information to TO1 in autonomous system A.

[0285] 5. TO1 verifies the timeliness of the verification report based on the timestamp contained in the trusted routing information (if it has expired, the trusted routing information is discarded).

[0286] 6. TO1 confirms whether this autonomous system supports the corresponding security assessment rule (i.e., the trust level assessment rule carried in the BGP update message) based on the identifier of the trust level assessment rule.

[0287] 7. After the verification in steps 5 and 6 is successful, TO1 locates the trusted verifier requesting verification based on information such as verifier name, ID or URI (if not supported, the trusted routing information is discarded).

[0288] 8. TO1 sends a verification request to the located trusted verification party. The verification request may include the autonomous system number to be verified, the verification report ID, etc. It is understandable that if the trusted routing information contains the address of the verification report, then in this step, TO1 can also send that address or download and send the corresponding verification report.

[0289] 9. The trusted verification party obtains the verification report and verifies its contents.

[0290] 10. Trusted verification direction TO1 returns the verification result, which may include the verified trust level.

[0291] 11. TO1 sends a trust level update message to one or more BGP routers in the autonomous system (BGP router 1 is used as an example in the figure). The message includes the trust level of autonomous system B.

[0292] 12. After receiving the trust level update message, BGP router 1 updates the trust level of the target autonomous system (autonomous system B) recorded locally.

[0293] Combination Figure 12 It can be seen that, Figure 12 In the illustrated embodiment, BGP router 2 of autonomous system B can add trusted routing information of autonomous system B to the BGP update message sent to BGP router 1 of autonomous system A. After receiving the message, BGP router 1 can request TO within the domain to verify the trusted routing information of autonomous system B with the help of a trusted authenticator, and then write the verified trust level of autonomous system B into the local record of BGP router 1.

[0294] It should be understood that, Figure 12 In subsequent embodiments, a trusted communication path can also be established between BGP router 1 and BGP router 2. For specific implementation methods, please refer to the relevant descriptions in the embodiments above, or refer to related technologies.

[0295] In summary, in the embodiments of this application, the second autonomous domain can provide the first autonomous domain with its trusted routing information. The first autonomous domain can verify the security of the second autonomous domain based on the trusted routing information, thereby ensuring the establishment of a trusted communication path between the first and second autonomous domains and realizing secure communication between autonomous domains.

[0296] Depend on Figure 8 As can be seen from the embodiments, the embodiments of this application can carry trusted routing information in the routing messages transmitted by routing devices within an autonomous system. The following will be conducted through... Figure 13 The embodiments hereby provide an exemplary description of the routing device's processing of routing messages in the embodiments of this application.

[0297] Figure 13 The flowchart illustrates another autonomous system security verification method provided in this application embodiment. This method can be applied to... Figure 6 In the implementation environment shown, the steps of this method can be executed by a second routing device, which belongs to the first autonomous system. The second routing device can be... Figure 8 The second routing device in the embodiment. See also Figure 13 The method may include the following steps.

[0298] Step 1301: The second routing device receives a first routing message sent by the third routing device. The first routing message carries trusted routing information of one or more autonomous systems, including first trusted routing information. The first trusted routing information is trusted routing information of the second autonomous system. The first trusted routing information is used to prove the security of the second autonomous system. The second routing device belongs to the first autonomous system, and the third routing device is a peer of the second routing device.

[0299] In this embodiment, the third routing device can be a routing device within the second autonomous system (AS), in which case the third routing device directly sends the aforementioned routing message to the second routing device. Alternatively, the third routing device can be another routing device within the first AS, in which case the aforementioned routing message is passed from a routing device within the second AS to the third routing device and then to the second routing device. This process can involve multiple routing devices, and this embodiment does not limit the scope of the application.

[0300] In this embodiment, the second autonomous system (AS) can be any AS on the transmission path of the first routing message. Furthermore, the trusted routing information of the aforementioned one or more ASs can be trusted routing information of some or all ASs covered by the transmission path of the first routing message; that is, it is permissible to refer to cases where the first routing message does not carry trusted routing information of some ASs along the transmission path.

[0301] In one implementation, the first routing message can be a BGP update message, or it can be a message under other protocols; this application does not limit this. For related implementations of BGP update messages, please refer to... Figures 8 to 10 The descriptions of the embodiments are provided in this document and are merely illustrative.

[0302] Taking BGP update messages as an example, in one implementation, the first routing message carries trusted routing information path attributes, which include an attribute type code field, an attribute length field, and an attribute value field. The attribute type code field indicates the type of information in the attribute value field; the attribute length field indicates the length of the attribute value field; and the attribute value field carries trusted routing information for one or more autonomous systems.

[0303] The trusted routing information path attribute also includes an attribute flag field, which includes optional bits and transitive bits. The optional bits indicate that the trusted routing information path attribute is optional, meaning that the corresponding path attribute is allowed to be unsupported; the transitive bits indicate that the trusted routing information path attribute needs to be passed by the second routing device to another peer of the second routing device.

[0304] The attribute flag field also includes a partial bit, which indicates that the trusted routing information path attribute has not been recognized by the third routing device, or that the trusted routing information routing attribute has been recognized by the third routing device and its content has been confirmed to be complete.

[0305] The attribute flag field also includes an extended length bit, which indicates the number of bytes occupied by the attribute length field, which can be 1 byte or 2 bytes.

[0306] The attribute value field includes one or more attribute value subfields, which carry trusted routing information for the one or more autonomous systems. Each attribute value subfield carries trusted routing information for one autonomous system, and different attribute value subfields carry trusted routing information for different autonomous systems.

[0307] Therefore, trusted routing information may include the identifier of the corresponding autonomous system. Furthermore, in one implementation, trusted routing information may include a signature of the trusted routing information from the corresponding autonomous system.

[0308] In another implementation, the first routing message carries BGP security path attributes, which include a security path field and a signature field. The security path field carries trusted routing information for one or more autonomous systems, and the signature field carries a signature of the security path field.

[0309] The secure path field includes one or more secure path segments. Each secure path segment corresponds to an autonomous system on the transmission path of the first routing message. Different secure path segments correspond to different autonomous systems. Some or all of the secure path segments carry trusted routing information of the aforementioned one or more autonomous systems.

[0310] Each secure path segment includes an autonomous system identifier field, which carries the identifier of the corresponding autonomous system.

[0311] In addition, each secure path segment includes a flag field, which in one implementation includes a trusted routing enable bit. The trusted routing enable bit indicates that the corresponding secure path segment also includes a trusted routing information field, which carries trusted routing information for the corresponding autonomous system, or indicates that the corresponding secure path segment does not carry trusted routing information.

[0312] Accordingly, the signature field includes one or more signature subfields, which may be in one or two groups. Each group of one or more signature subfields corresponds one-to-one with the one or more secure path segments mentioned above. The signature subfields carry the signature of the corresponding autonomous system for the corresponding secure path segment.

[0313] Figure 13The content of the trusted routing information in the embodiment is the same as... Figure 8 The content of trusted routing information is the same in similar implementations in the embodiments, and is only described as an example here.

[0314] Taking the first trusted routing information as an example, the first trusted routing information may include the identifier of the first evaluation rule. The first evaluation rule is a security evaluation rule supported by the second autonomous system. The first trusted routing information is determined according to the first evaluation rule. The second autonomous system supports the second evaluation rule. The second evaluation rule may be the same as or different from the first evaluation rule.

[0315] In one possible implementation, the first trusted routing information includes the identifier or download address of a verification report used to prove the security of the second autonomous domain.

[0316] In one possible implementation, the first trusted routing information also includes a timestamp indicating the validity period of the verification report.

[0317] The verification report records the trust level of the second autonomous domain, and / or the first trusted routing information also includes the trust level of the second autonomous domain.

[0318] In one possible implementation, the first trusted routing information also includes the identifier of a trusted verifier. The identifier of the trusted verifier is used by the first trusted controller to verify the trusted routing information through the trusted verifier in order to obtain the verification result.

[0319] Step 1302: The second routing device reports the trusted routing information of the one or more autonomous systems to the first trusted controller, where the first trusted controller is a trusted controller within the first autonomous system.

[0320] In one implementation, the trusted routing information may include a signature of the trusted routing information by the corresponding autonomous system. If the second routing device verifies the signature in the routing information, it reports the routing information to the first trusted controller. Alternatively, the second routing device may not verify the signature but directly report the trusted routing information.

[0321] In another implementation, the first routing message carries BGP security path attributes, which include a security path field and a signature field. The security path field carries trusted routing information for one or more autonomous systems, and the signature field carries a signature on the security path field. Based on this, if the signature verification in the signature field passes, the second routing device reports the trusted routing information for the one or more autonomous systems to the first trusted controller. Alternatively, the second routing device may not verify the signature and directly report the trusted routing information.

[0322] Step 1303: The second routing device receives the confirmation result sent by the first trusted controller, which includes confirmation of the security of the second autonomous system.

[0323] The implementation process of the first trusted controller confirming the trusted routing information of the second autonomous region can be referred to... Figure 8 The specific implementation details will not be repeated here. This confirmation result can also be compared with... Figure 8 The confirmation results in the embodiments are similar. For example, the confirmation result may indicate whether the second autonomous domain is secure, and / or the confirmation result may include the trust level of the second autonomous domain.

[0324] It should be understood that the second autonomous domain is one of the autonomous domains reported by the second routing device. Based on this, if the second routing device reports multiple autonomous domains, the confirmation result can include the security confirmation results of multiple autonomous domains, such as the trust level of the multiple autonomous domains.

[0325] After receiving the first routing message sent by the third routing device, the second routing device can, in addition to requesting the first trusted controller to verify the trusted routing information in the first routing message, also confirm, based on the first routing message, the autonomous systems that do not support trusted routing information on the transmission path of the first routing message, and record the trust level of these autonomous systems as a default value (e.g., 0).

[0326] When the first routing message carries a custom trusted routing information path attribute, the implementation method for confirming that the autonomous system that does not support trusted routing information on the transmission path of the first routing message can be: confirming the autonomous system number in the attribute value subfield of the trusted routing information path attribute where the trusted routing information is the default value, and determining the autonomous system identified by these autonomous system numbers as the autonomous system that does not support trusted routing information.

[0327] When the first routing message carries the BGPsec_Path attribute, the implementation of confirming that the autonomous system that does not support trusted routing information on the transmission path of the first routing message can be as follows: confirm the autonomous system number carried by the security path segment that does not carry trusted routing information, and determine the autonomous system identified by these autonomous system numbers as the autonomous system that does not support trusted routing information.

[0328] In one possible implementation, after receiving the first routing message from the third routing device, the second routing device can update the first routing message and send the updated first routing message to a fourth routing device, which is another peer of the second routing device. The updated first routing message includes second trusted routing information, which is trusted routing information from the first autonomous system.

[0329] In the case where the first routing message carries a custom trusted routing information path attribute, the second routing device can add an attribute value subfield to the trusted routing information path attribute and write the trusted routing information of the first autonomous region into the attribute value subfield.

[0330] When the first routing message carries the BGPsec_Path attribute, the second routing device can add a secure path segment and one or two signature subfields (corresponding to one or two sets of cases) to the BGPsec_Path attribute, write the trusted routing information of the first autonomous system to the added secure path segment, and write the signature corresponding to the first autonomous system to the added signature subfield.

[0331] As discussed above, the transmission path of the first routing message can cover multiple autonomous systems (AS), including the second AS. Therefore, if the first routing message does not carry trusted routing information for some or all of the ASs other than the second AS (hereinafter referred to as the missing ASs), the second routing device updating the first routing message can include: adding second trusted routing information to the first routing message, and adding trusted routing information for the missing ASs, where the trusted routing information for the missing ASs is a default value. In other words, the second routing device completes the trusted routing information for the missing ASs in the first routing message. In relevant implementations, the missing trusted routing information can be completed by adding fields to the first routing message.

[0332] Based on this, if the first routing message carries trusted routing information path attributes, and the trusted routing information path attributes carry an attribute flag field and an attribute value field, and the attribute flag field includes partial bits, and the partial bits indicate that the trusted routing information path attributes have not been recognized by the third routing device, then the second routing device updating the first routing message may also include: modifying the partial bits, and the modified partial bits indicate that the trusted routing information routing attributes have been recognized by the second routing device and the content has been confirmed to be complete.

[0333] As an example, some bits were 1 before the modification and some bits were 0 after the modification.

[0334] In addition to receiving and processing the first routing messages transmitted by other routing devices, the second routing device can also generate a routing message.

[0335] As an example, a second routing device can generate a second routing message carrying second trusted routing information, which is trusted routing information of the first autonomous system, and pass the second routing message to a fifth routing device, which is a peer of the second routing device.

[0336] This application does not limit which or which routing devices the fifth routing device can be. For example, it can be the third or fourth routing device mentioned above, or other routing devices.

[0337] In one implementation, the second routing message can be a BGP update message. When the second routing message carries a trusted routing information path attribute, this attribute carries a unique attribute value subfield that carries the second trusted routing information. When the second routing message carries a BGPsec_Path attribute, this attribute carries a unique secure path segment and a unique signature subfield (including one or both sets of signatures). The secure path segment carries the second trusted routing information, and the signature subfield carries a signature for the secure path segment.

[0338] The second routing device may also receive a third routing message sent by the sixth routing device, which is a peer of the second routing device. If the third routing message does not carry trusted routing information, the second routing device can update the third routing message after receiving it. The updated third routing message carries second trusted routing information, which is trusted routing information of the first autonomous system. The updated third routing message is then sent to the seventh routing device, which is another peer of the second routing device.

[0339] In other words, although the third routing message is not generated by the second routing device, as long as the second routing device supports the relevant functions of trusted routing information, trusted routing information of the first autonomous system can be added to the third routing message. In relevant implementations, the second trusted routing information can be added by adding fields to the third routing message. For specific implementation methods, please refer to the relevant implementation methods for adding second trusted routing information to the second routing message described above.

[0340] This application does not limit which routing device the sixth and seventh routing devices can be.

[0341] If the transmission path of the third routing message already covers one or more autonomous systems (AS), the process of the second routing device updating the third routing message may include: adding second trusted routing information to the third routing message, and adding trusted routing information for the ASs already covered by the transmission path of the third routing message, where the trusted routing information for the ASs already covered by the transmission path of the third routing message is a default value. That is, the second routing device completes the third routing message with the trusted routing information for any missing ASs. In relevant implementations, this can be achieved by adding fields to the third routing message to complete the missing trusted routing information.

[0342] In the embodiments of this application, the second routing device can obtain trusted routing information of the first autonomous system in various ways, and this application does not limit this method. For example, after each evaluation of the configuration information of the first autonomous system and obtaining the trusted routing information of the first autonomous system, the trusted routing information of the first autonomous system can be manually or automatically configured on the second routing device. Alternatively, the second routing device can request the trusted routing information of the first autonomous system from the first trusted controller, for example, by periodically or periodically requesting the latest trusted routing information of the first autonomous system.

[0343] The second routing device in the above embodiments is a routing device that supports trusted routing information related functions, meaning that the second routing device can identify and process trusted routing information in routing messages. For routing devices that do not support trusted routing information related functions, taking the eighth routing device as an example, if the eighth routing device receives a routing message and the routing message carries fields related to trusted routing information, the eighth routing device cannot identify the fields related to trusted routing information and may not process the fields.

[0344] In summary, in the embodiments of this application, after a routing device in the first autonomous domain receives trusted routing information of the second autonomous domain transmitted by other routing devices, it can verify the trusted routing information of the second autonomous domain through the trusted controller in the first autonomous domain, thereby obtaining a confirmation result regarding the security of the second autonomous domain, and ensuring subsequent secure inter-domain communication.

[0345] It should be understood that, Figures 8 to 12 Examples and Figure 13 The embodiments belong to the same technical concept. Figures 8 to 12 The relevant implementation methods of the embodiments can be adapted in part or in whole to [the specific implementation methods]. Figure 13 Example.

[0346] Figure 14 This is a schematic diagram of the structure of a security verification device 1400 for an autonomous system provided in an embodiment of this application. The device 1400 can be implemented as part or all of a communication device by software, hardware, or a combination of both. This communication device can be the first device in the above method embodiments. In this embodiment, the device 1400 is included within the first device, and the first device belongs to the first autonomous system. See also... Figure 14 The device 1400 includes a trusted route acquisition module 1401 and a security verification module 1402.

[0347] The trusted route acquisition module 1401 is used to acquire first trusted route information from the second device, the second device belongs to the second autonomous system, and the first trusted route information is used to prove the security of the second autonomous system;

[0348] The security verification module 1402 is used to verify the security of the second autonomous domain based on the first trusted routing information.

[0349] In one possible implementation, the first trusted routing information includes the identifier of a first evaluation rule, which is a security evaluation rule supported by the second autonomous region, and the first trusted routing information is determined according to the first evaluation rule;

[0350] Security verification module 1402 is specifically used for:

[0351] If the first autonomous domain supports the first evaluation rule, the security of the second autonomous domain is confirmed based on the first trusted routing information.

[0352] In one possible implementation, the first trusted routing information includes the identifier or download address of a verification report used to prove the security of the second autonomous domain;

[0353] Security verification module 1402 is specifically used for:

[0354] The security of the second autonomous domain can be confirmed based on the identifier or download address of the verification report.

[0355] In one possible implementation, the first trusted routing information also includes a timestamp indicating the validity period of the verification report;

[0356] Security verification module 1402 is specifically used for:

[0357] If the timestamp determines that the verification report has not expired, then the security of the second autonomous domain is confirmed based on the verification report's identifier or download address.

[0358] In one possible implementation, the security verification module 1402 is specifically used for:

[0359] Send a verification request to a trusted verification party, which includes the identifier or download address of the verification report;

[0360] Receive the verification result returned by the trusted verifier, which indicates whether the second autonomous domain is secure.

[0361] In one possible implementation, the verification result includes first indication information indicating whether the second autonomous domain is secure; or, the verification result includes a verification report; or, the verification result includes the trust level of the second autonomous domain.

[0362] In one possible implementation, the first trusted routing information also includes the identifier of the trusted authenticator;

[0363] The device 1400 also includes:

[0364] The location module is used to locate trusted verifiers based on their identifiers.

[0365] In one possible implementation, verifying the security of the second autonomous domain includes: verifying the credibility of the verification report; and / or,

[0366] The verification report records the trust level of the second autonomous domain, and / or the first trusted routing information also includes the trust level of the second autonomous domain, confirming the security of the second autonomous domain, including: confirming whether the trust level of the second autonomous domain exceeds the trust level threshold.

[0367] In one possible implementation, the first trusted routing information includes the configuration information of the second autonomous system;

[0368] Security verification module 1402 is specifically used for:

[0369] The configuration information of the second autonomous domain is verified for security purposes to confirm its security.

[0370] In one possible implementation, the security verification module 1402 is specifically used for:

[0371] The configuration information is verified for security according to the second assessment rule, which is a security assessment rule supported by the first autonomous domain.

[0372] In one possible implementation, the first device is a trusted controller within a first autonomous domain;

[0373] The device 1400 also includes:

[0374] The notification module is used to send confirmation results regarding the security of the second autonomous domain to some or all of the routing devices in the first autonomous domain.

[0375] In one possible implementation, the confirmation result includes second indication information indicating whether the second autonomous domain is secure; or, the confirmation result includes the trust level of the second autonomous domain.

[0376] In one possible implementation, the first device is a trusted controller within a first autonomous system, and the second device is a trusted controller within a second autonomous system.

[0377] Trusted route acquisition module 1401 is specifically used for:

[0378] Send a request to the second device to obtain trusted routing information about the second autonomous region;

[0379] Receive the first trusted routing information sent by the second device.

[0380] In one possible implementation, the acquisition request carries an identifier of a second evaluation rule, which is a security evaluation rule supported by the first autonomous system, and the first trusted routing information is obtained if the second autonomous system supports the second evaluation rule.

[0381] In one possible implementation, the device 1400 further includes:

[0382] The path establishment module is used to send a path establishment request to the second device after confirming the security of the second autonomous region. The path establishment request carries the first path parameters.

[0383] The receiving module is used to receive the second path parameters returned by the second device in response to the path establishment request;

[0384] The parameter synchronization module is used to send third path parameters to the first routing device to instruct the first routing device to use the third path parameters to establish a communication path with the second autonomous system. The third path parameters are determined based on the second path parameters. The first routing device is a routing device within the first autonomous system.

[0385] In one possible implementation, the first device is a trusted controller within a first autonomous system, and the second device is a routing device within a second autonomous system.

[0386] Trusted route acquisition module 1401 is specifically used for:

[0387] The system receives trusted routing information for one or more autonomous systems reported by a second routing device. The trusted routing information for one or more autonomous systems includes first trusted routing information. The second routing device is a routing device within the first autonomous system. The trusted routing information for one or more autonomous systems is obtained from routing messages. The first trusted routing information is added to the routing message by the second device.

[0388] In one possible implementation, the second autonomous region is any autonomous region along the transmission path of the routed message.

[0389] In one possible implementation, the trusted routing information for one or more autonomous systems is the trusted routing information for some or all of the autonomous systems covered by the transmission path of the routing message.

[0390] In one possible implementation, the routing message is a BGP update message.

[0391] In one possible implementation, the routing message carries trusted routing information path attributes, which include an attribute type code field, an attribute length field, and an attribute value field.

[0392] The attribute type code field indicates the type of information in the attribute value field;

[0393] The attribute length field indicates the length of the attribute value field;

[0394] The attribute value field carries trusted routing information for one or more autonomous systems.

[0395] In one possible implementation, the attribute value field includes one or more attribute value subfields, which carry trusted routing information for one or more autonomous systems. Specifically, one attribute value subfield carries trusted routing information for one autonomous system, and different attribute value subfields carry trusted routing information for different autonomous systems.

[0396] In one possible implementation, the trusted routing information includes the identifier of the corresponding autonomous system.

[0397] In one possible implementation, the trusted routing information includes a signature of the trusted routing information by the corresponding autonomous system.

[0398] In one possible implementation, the routing message carries BGP secure path attributes, which include a secure path field and a signature field. The secure path field carries trusted routing information for one or more autonomous systems, and the signature field carries a signature of the secure path field.

[0399] In one possible implementation, the secure path field includes one or more secure path segments, wherein a secure path segment corresponds to an autonomous system on the transmission path of the routing message, different secure path segments correspond to different autonomous systems, and some or all of the secure path segments carry trusted routing information of one or more autonomous systems.

[0400] In one possible implementation, each secure path segment includes an autonomous system identifier field, which carries the identifier of the corresponding autonomous system.

[0401] In one possible implementation, each secure path segment includes a flag field, which includes a trusted routing enable bit. The trusted routing enable bit indicates that the corresponding secure path segment also includes a trusted routing information field, which carries trusted routing information for the corresponding autonomous system, or indicates that the corresponding secure path segment does not carry trusted routing information.

[0402] In one possible implementation, trusted routing information for one or more autonomous systems is received after the signature verification is successful by the second routing device; and / or,

[0403] The operation to verify the security of the second autonomous domain based on the first trusted routing information is performed after the first device has verified the signature.

[0404] In this embodiment of the application, the second autonomous domain can provide the first autonomous domain with trusted routing information of the second autonomous domain. The first autonomous domain can confirm the security of the second autonomous domain based on the trusted routing information of the second autonomous domain, thereby ensuring the establishment of a trusted communication path between the first autonomous domain and the second autonomous domain and realizing secure communication between autonomous domains.

[0405] It should be noted that the autonomous system security verification device 1400 provided in the above embodiments is only illustrated by the division of the above functional modules when verifying the security of the autonomous system. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the autonomous system security verification device and the autonomous system security verification method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0406] Figure 15 This is a schematic diagram of the structure of an autonomous system security verification device 1500 provided in an embodiment of this application. The device 1500 can be implemented as part or all of a communication device by software, hardware, or a combination of both. This communication device can be the second routing device in the above method embodiments. In this embodiment, the device 1500 is included in the second routing device, and the second routing device belongs to the first autonomous system. See also... Figure 15 The device 1500 includes: a first receiving module 1501, a reporting module 1502, and a second receiving module 1503.

[0407] The first receiving module 1501 is used to receive a first routing message sent by the third routing device. The first routing message carries trusted routing information of one or more autonomous systems. The trusted routing information of one or more autonomous systems includes the first trusted routing information. The first trusted routing information is the trusted routing information of the second autonomous system. The first trusted routing information is used to prove the security of the second autonomous system. The third routing device is a peer of the second routing device.

[0408] The reporting module 1502 is used to report trusted routing information of one or more autonomous systems to the first trusted controller, where the first trusted controller is a trusted controller within the first autonomous system.

[0409] The second receiving module 1503 is used to receive the confirmation result sent by the first trusted controller, the confirmation result including the confirmation result of the security of the second autonomous domain.

[0410] In one possible implementation, the second autonomous region is any autonomous region on the transmission path of the first routing message.

[0411] In one possible implementation, the trusted routing information for one or more autonomous systems is the trusted routing information for some or all of the autonomous systems covered by the transmission path of the first routing message.

[0412] In one possible implementation, the first routing message is a BGP update message.

[0413] In one possible implementation, the first routing message carries trusted routing information path attributes, which include an attribute type code field, an attribute length field, and an attribute value field.

[0414] The attribute type code field indicates the type of information in the attribute value field;

[0415] The attribute length field indicates the length of the attribute value field;

[0416] The attribute value field carries trusted routing information for one or more autonomous systems.

[0417] In one possible implementation, the attribute value field includes one or more attribute value subfields, which carry trusted routing information for one or more autonomous systems. Specifically, one attribute value subfield carries trusted routing information for one autonomous system, and different attribute value subfields carry trusted routing information for different autonomous systems.

[0418] In one possible implementation, the trusted routing information includes the identifier of the corresponding autonomous system.

[0419] In one possible implementation, the trusted routing information includes a signature of the trusted routing information by the corresponding autonomous system.

[0420] In one possible implementation, the first routing message carries BGP security path attributes, which include a security path field and a signature field. The security path field carries routing information, and the signature field carries a signature of the security path field.

[0421] In one possible implementation, the secure path field includes one or more secure path segments, wherein a secure path segment corresponds to an autonomous system on the transmission path of the first routing message, different secure path segments correspond to different autonomous systems, and some or all of the secure path segments carry trusted routing information of one or more autonomous systems.

[0422] In one possible implementation, each secure path segment includes an autonomous system identifier field, which carries the identifier of the corresponding autonomous system.

[0423] In one possible implementation, each secure path segment also includes a flag field, which includes a trusted routing enable bit. The trusted routing enable bit indicates that the corresponding secure path segment also includes a trusted routing information field, which carries trusted routing information for the corresponding autonomous system, or indicates that the corresponding secure path segment does not carry trusted routing information.

[0424] In one possible implementation, trusted routing information for one or more autonomous systems is reported by a second routing device after the signature verification of the first routing message has been passed.

[0425] In one possible implementation, the device 1500 further includes:

[0426] The update module is used to update the first routing message. The updated first routing message contains second trusted routing information, which is the trusted routing information of the first autonomous system.

[0427] The sending module is used to send the updated first routing message to the fourth routing device, which is another peer of the second routing device.

[0428] In one possible implementation, the transmission path of the first routing message covers multiple autonomous systems, including a second autonomous system. The first routing message does not carry trusted routing information for some or all of the autonomous systems other than the second autonomous system.

[0429] The update module is specifically used for:

[0430] Add second trusted routing information to the first routing message, and add trusted routing information for some or all autonomous systems. The trusted routing information for some or all autonomous systems is the default value.

[0431] In one possible implementation, the first routing message carries trusted routing information path attributes, which carry an attribute flag field and an attribute value field. The attribute flag field includes partial bits, and the partial bits indicate that the trusted routing information path attributes are not recognized by the third routing device. The attribute value field carries trusted routing information for one or more autonomous systems.

[0432] The update module is also used for:

[0433] The modified bits indicate that the trusted routing information routing attributes have been recognized and confirmed to be complete by the second routing device.

[0434] In one possible implementation, the device 1500 further includes:

[0435] The generation module is used to generate a second routing message, which carries second trusted routing information, which is the trusted routing information of the first autonomous system.

[0436] The sending module is used to transmit the second routing message to the fifth routing device, which is a peer of the second routing device.

[0437] In one possible implementation, the device 1500 further includes:

[0438] The third receiving module is used to receive the third routing message sent by the sixth routing device, which is a peer of the second routing device. The third routing message does not carry trusted routing information.

[0439] The update module is used to update the third routing message. The updated third routing message carries the second trusted routing information, which is the trusted routing information of the first autonomous system.

[0440] The sending module is used to send the updated third routing message to the seventh routing device, which is another peer of the second routing device.

[0441] In one possible implementation, the update module is specifically used for:

[0442] Add second trusted routing information to the third routing message, and add trusted routing information for autonomous systems other than the first autonomous system that are covered by the transmission path of the third routing message. The trusted routing information for autonomous systems other than the first autonomous system is the default value.

[0443] In one possible implementation, the first trusted routing information includes the identifier of a first evaluation rule, which is a security evaluation rule supported by the second autonomous system. The first trusted routing information is determined according to the first evaluation rule, and the second autonomous system supports a second evaluation rule, which may be the same as or different from the first evaluation rule.

[0444] In one possible implementation, the first trusted routing information includes the identifier or download address of a verification report, which is used to prove the security of the second autonomous domain.

[0445] In one possible implementation, the first trusted routing information also includes a timestamp indicating the validity period of the verification report.

[0446] In one possible implementation, the verification report records the trust level of the second autonomous system, and / or the first trusted routing information also includes the trust level of the second autonomous system.

[0447] In one possible implementation, the first trusted routing information also includes the identifier of a trusted authenticator, which is used by the first trusted controller to verify the trusted routing information of one or more autonomous systems through the trusted authenticator to obtain a confirmation result.

[0448] In this embodiment of the application, after a routing device in the first autonomous domain receives trusted routing information of the second autonomous domain transmitted by other routing devices, it can verify the trusted routing information of the second autonomous domain through the trusted controller in the first autonomous domain, thereby obtaining a confirmation result on the security of the second autonomous domain and ensuring subsequent secure inter-domain communication.

[0449] It should be noted that the autonomous system security verification device 1500 provided in the above embodiments is only illustrated by the division of the above functional modules when verifying the security of an autonomous system. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the autonomous system security verification device and the autonomous system security verification method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0450] Figure 16 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. In some embodiments, the communication device is the first device in the method embodiment of this application. The communication device includes one or more processors 1601, a communication bus 1602, a memory 1603, and one or more communication interfaces 1604.

[0451] The processor 1601 is a general-purpose central processing unit (CPU), a network processor (NP), a microprocessor, or one or more integrated circuits for implementing the solutions of this application, such as an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. In some embodiments, the PLD is a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0452] The communication bus 1602 is used to transmit information between the aforementioned components. In some embodiments, the communication bus 1602 is divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 16 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0453] The memory 1603 may be a read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), optical disc (including compact disc read-only memory (CD-ROM), compressed optical disc, laser disc, digital versatile optical disc, Blu-ray disc, etc.), magnetic disk storage medium, or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 1603 exists independently and is connected to the processor 1601 via the communication bus 1602, or the memory 1603 is integrated with the processor 1601.

[0454] Communication interface 1604 uses any transceiver-like device for communicating with other devices or communication networks. Communication interface 1604 includes a wired communication interface and / or a wireless communication interface. The wired communication interface may be, for example, an Ethernet interface. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof.

[0455] In some embodiments, the communication device includes multiple processors, such as Figure 16 The processors 1601 and 1605 shown are examples of processors. Each of these processors may be a single-core processor or a multi-core processor. Here, a processor refers to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0456] As one embodiment, the communication device also includes an output device 1606 and an input device 1607. The output device 1606 communicates with the processor 1601 and can display information in various ways. For example, the output device 1606 can be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector. The input device 1607 communicates with the processor 1601 and can receive user input in various ways. For example, the input device 1607 can be a mouse, keyboard, touchscreen device, or sensing device.

[0457] In some embodiments, memory 1603 stores program code 1610 for executing the scheme of this application, and processor 1601 is capable of executing the program code 1610 stored in memory 1603. The program code includes one or more software modules, and the communication device can implement the above through processor 1601 and the program code 1610 in memory 1603. Figure 8 The implementation example provides a method for verifying the security of autonomous systems.

[0458] Figure 17 This is a schematic diagram of a communication device provided in an embodiment of this application. The communication device 1700 can be a routing device in any of the above embodiments, such as a second routing device. The communication device 1700 can be a switch, a router, or other communication device that forwards packets. In this embodiment, the communication device 1700 includes: a main control board 1710, an interface board 1730, and an interface board 1740. In the case of multiple interface boards, a switching network board (not shown in the figure) can be included, which is used to complete data exchange between the interface boards (interface boards are also called line cards or service boards).

[0459] The main control board 1710 performs functions such as system management, equipment maintenance, and protocol processing. Interface boards 1730 and 1740 provide various service interfaces (e.g., POS interface, GE interface, ATM interface, etc.) and forward data streams. The main control board 1710 primarily has three types of functional units: a system management control unit, a system clock unit, and a system maintenance unit. The main control board 1710, interface board 1730, and interface board 1740 communicate with each other via a system bus connected to the system backplane. Interface board 1730 includes one or more processors 1731. Processors 1731 control and manage the interface board, communicate with the central processing unit 1717 on the main control board, and handle data stream forwarding. The memory 1732 on interface board 1730 stores forwarding table entries; processors 1731 forward data streams by searching the forwarding table entries stored in memory 1732.

[0460] The interface board 1730 includes one or more network interfaces 1733 for receiving data streams or other information sent by terminals or other network devices, and processing these data streams or information according to the instructions of the processor 1731. The specific implementation process will not be described in detail here.

[0461] Understandable, such as Figure 17 As shown, this embodiment includes multiple interface boards and employs a distributed forwarding mechanism. Under this mechanism, the operations on interface board 1740 are basically similar to those on interface board 1730, and for simplicity, they will not be described in detail. Furthermore, it is understood that... Figure 17 The processor 1731 in interface board 1730 and / or the processor 1741 in interface board 1740 can be dedicated hardware or a chip, such as a network processor or an application-specific integrated circuit (ASIC), to implement the above functions. This implementation method is commonly referred to as using dedicated hardware or a chip for the forwarding plane. For a detailed implementation using a network processor or other dedicated hardware or chip, please refer to the following. Figure 18 The illustrated embodiment. In other embodiments, processors 1731 and / or 1741 may also employ general-purpose processors, such as general-purpose CPUs, to implement the functions described above.

[0462] Furthermore, it should be noted that there may be one or more main control boards, including a primary main control board and a backup main control board. There may also be one or more interface boards; the stronger the data processing capability of the device, the more interface boards it provides. With multiple interface boards, these boards can communicate through one or more switching network boards, enabling load sharing and redundancy backup. In a centralized forwarding architecture, the device may not require a switching network board; the interface boards handle the processing of the entire system's business data. In a distributed forwarding architecture, the device includes multiple interface boards, which can exchange data with each other through a switching network board, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of a distributed architecture communication device are greater than those of a centralized architecture device. The specific architecture adopted depends on the specific network deployment scenario, and no limitations are made here.

[0463] In some embodiments, memory 1732 and / or memory 1742 may be read-only memory (ROM), random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), optical discs (including compact disc read-only memory (CD-ROM), compressed optical discs, laser discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code having an instruction or data structure form and accessible by a computer, but not limited thereto. Memory 1732 may exist independently and be connected to processor 1731 via a communication bus. Memory 1732 may also be integrated with processor 1731. Similarly, memory 1742 may exist independently and be connected to processor 1741 via a communication bus, or memory 1742 may be integrated with processor 1741.

[0464] In some embodiments, network interface 1733 and / or network interface 1743 can be any transceiver-like device used to communicate with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), etc. Network interface 1733 and / or network interface 1743 includes a wired network interface and may also include a wireless network interface. The wired network interface can be, for example, an Ethernet interface. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. The wireless network interface can be a WLAN interface, a cellular network communication interface, or a combination thereof, etc. When the communication device is any communication device within the domain, network interface 1733 and / or network interface 1743 is used to forward data packets to other communication devices.

[0465] In some embodiments, the communication device may include a plurality of processors, each of which may be a single-core processor or a multi-core processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores for processing data (such as computer program instructions).

[0466] In some embodiments, the memory 1732 is used to store program code that executes the scheme of this application, and the processor 1731 can execute the program code stored in the memory 1732 to cause the communication device 1700 to perform... Figures 8 to 13 The processing steps of the routing device in the embodiment can be referred to for specific implementation. Figures 8 to 13 The detailed descriptions of the embodiments shown will not be repeated here.

[0467] Figure 18This is a schematic diagram of another communication device provided in this application embodiment. The communication device 1800 can be any of the communication devices in the above embodiments. In this embodiment, the communication device 1800 includes: a main control board 1810, an interface board 1830, a switching network board 1820, and an interface board 1840. The main control board 1810 is used to perform functions such as system management, equipment maintenance, and protocol processing. The switching network board 1820 is used to perform data exchange between the various interface boards (interface boards are also called line cards or service boards). The interface boards 1830 and 1840 are used to provide various service interfaces (e.g., POS interface, GE interface, ATM interface, etc.) and to realize the forwarding of data packets. The control plane consists of the various management and control units on the main control board 1810 and the management and control units on the interface boards 1830 and 1840. The main control board 1810 mainly has three types of functional units: system management and control unit, system clock unit, and system maintenance unit. The main control board 1810, interface boards 1830 and 1840, and switching network board 1820 communicate with each other via a system bus connected to the system backplane. The central processing unit 1831 on interface board 1830 and the central processing unit 1841 on interface board 1840 control and manage the corresponding interface boards and communicate with the central processing unit 1811 on the main control board. The forwarding table entry memory 1834 on interface board 1830 and the forwarding table entry memory 1844 on interface board 1840 store forwarding table entries. The network processors 1832 and 1842 forward data streams by searching the forwarding table entries stored in the forwarding table entry memory 1834.

[0468] The physical interface card 1833 on interface board 1830 and the physical interface card 1843 on interface board 1840 are used to receive data streams or other data sent by terminals or other devices. The specific implementation process will not be described in detail here.

[0469] The network processor 1832 is used to process received data streams, etc. The specific functions of the network processor 1832 will not be detailed here. For example, the network processor 1832 can execute program code, causing the communication device 1800 to perform... Figures 8 to 13 The processing steps of the routing device in the illustrated embodiment can be referred to for specific implementation. Figures 8 to 13 The detailed descriptions in the embodiments will not be repeated here.

[0470] Understandable, such as Figure 18 As shown, this embodiment includes multiple interface boards and employs a distributed forwarding mechanism. Under this mechanism, the operations on interface board 1840 are basically similar to those on interface board 1830, and for simplicity, they will not be described in detail. Furthermore, as mentioned above, Figure 18The functions of network processors 1832 and 1842 can be implemented using application-specific integrated circuits (ASICs).

[0471] Furthermore, it should be noted that there may be one or more main control boards, including a primary and a backup main control board. There may also be one or more interface boards; the stronger the data processing capability of the device, the more interface boards it provides. Each interface board may also have one or more physical interface cards. There may be no switching network board, or one or more; multiple boards can share the load for redundancy and backup. In a centralized forwarding architecture, the device may not need a switching network board, as the interface boards handle the entire system's business data processing. In a distributed forwarding architecture, the device can have at least one switching network board, which enables data exchange between multiple interface boards, providing high-capacity data exchange and processing capabilities. Therefore, the data access and processing capabilities of distributed architecture communication devices are greater than those of centralized architecture devices. The specific architecture adopted depends on the specific network deployment scenario, and no limitations are made here.

[0472] Figure 19 This is one of the above-mentioned embodiments provided in this application. Figure 18 The diagram shows the structure of the interface board in the communication device. The communication device containing the interface board can be the routing device in any of the above embodiments. The interface board may include a physical interface card (PIC) 1930, a network processor (NP) 1919, and a traffic management module 1920.

[0473] Among them, PIC: physical interface card, is used to realize the physical layer docking function. The raw traffic enters the interface board of the communication device through this PIC card, and the processed messages are sent out from this PIC card.

[0474] The NP1919 network processor is used to implement packet forwarding processing. Specifically, uplink packet processing includes: packet ingress interface processing, timestamp acquisition, uplink flow classification, forwarding table lookup, measurement information encapsulation, and packet replication processing; downlink packet processing includes: forwarding table lookup, downlink flow classification, timestamp acquisition, measurement information encapsulation, and outgress interface processing, etc.

[0475] Traffic Management™ is used to implement functions such as QoS, line-rate forwarding, large-capacity caching, and queue management. Specifically, uplink traffic management includes uplink QoS processing (such as congestion management and queue scheduling) and slicing; downlink traffic management includes packet reassembly, multicast replication, and downlink QoS processing (such as congestion management and queue scheduling).

[0476] It is understandable that if a communication device has multiple interface boards, the multiple interface boards can communicate with each other through the switching network 1940.

[0477] It should be noted that, Figure 19 This illustration only shows a schematic processing flow or module within the NP. In a specific implementation, the processing order of each module is not limited to this, and in practical applications, other modules or processing flows can be deployed as needed. The comparison of embodiments in this application is not intended to limit the scope of the application.

[0478] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the autonomous system security verification method shown in the above method embodiments.

[0479] This application also provides a computer program product containing instructions that, when run on a computer, causes the computer to perform the steps of the autonomous system security verification method shown in the above-described method embodiments. This application also provides a computer program that, when run on a computer, causes the computer to perform the steps of the autonomous system security verification method shown in the above-described method embodiments.

[0480] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital versatile disc (DVD)), or a semiconductor medium (e.g., solid state disk (SSD)). It is worth noting that the computer-readable storage medium mentioned in the embodiments of this application can be a non-volatile storage medium; in other words, it can be a non-transient storage medium.

[0481] It should be understood that "at least one" as mentioned herein refers to one or more, and "multiple" refers to two or more. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In addition, in order to clearly describe the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and the terms "first," "second," etc., are not necessarily different.

[0482] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0483] The above descriptions are embodiments provided in this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A security verification method for autonomous systems, characterized in that, The method is applied to a first device, which belongs to a first autonomous region, and the method includes: Obtain first trusted routing information from a second device, which belongs to a second autonomous system, and use the first trusted routing information to prove the security of the second autonomous system; Based on the first trusted routing information, the security of the second autonomous domain is confirmed.

2. The method as described in claim 1, characterized in that, The first trusted routing information includes the identifier of the first evaluation rule, which is a security evaluation rule supported by the second autonomous system, and the first trusted routing information is determined according to the first evaluation rule; The step of confirming the security of the second autonomous system based on the first trusted routing information includes: If the first autonomous domain supports the first evaluation rule, the security of the second autonomous domain is confirmed based on the first trusted routing information.

3. The method as described in claim 1 or 2, characterized in that, The first trusted routing information includes the identifier or download address of the verification report, which is used to prove the security of the second autonomous domain; The step of confirming the security of the second autonomous system based on the first trusted routing information includes: The security of the second autonomous domain is confirmed based on the identifier or download address of the verification report.

4. The method as described in claim 3, characterized in that, The first trusted routing information also includes a timestamp, which indicates the validity period of the verification report; The process of confirming the security of the second autonomous domain based on the identifier or download address of the verification report includes: If the verification report is determined not to have expired based on the timestamp, the security of the second autonomous domain is confirmed based on the identifier or download address of the verification report.

5. The method as described in claim 3 or 4, characterized in that, The process of confirming the security of the second autonomous domain based on the identifier or download address of the verification report includes: Send a verification request to a trusted verification party, the verification request carrying the identifier or download address of the verification report; The system receives the verification result returned by the trusted verification party, which indicates whether the second autonomous domain is secure.

6. The method as described in claim 5, characterized in that, The verification result includes first indication information, which indicates whether the second autonomous domain is secure; or, the verification result includes the verification report; or, the verification result includes the trust level of the second autonomous domain.

7. The method as described in claim 5 or 6, characterized in that, The first trusted routing information also includes the identifier of the trusted verifier; Before sending the verification request to the trusted verification party, the method further includes: The trusted verifier is located based on its identifier.

8. The method according to any one of claims 3-7, characterized in that, The confirmation of the security of the second autonomous domain includes: confirming whether the verification report is credible; and / or, The verification report records the trust level of the second autonomous domain, and / or the first trusted routing information also includes the trust level of the second autonomous domain. Confirming the security of the second autonomous domain includes: confirming whether the trust level of the second autonomous domain exceeds the trust level threshold.

9. The method as described in claim 1 or 2, characterized in that, The first trusted routing information includes the configuration information of the second autonomous domain; The step of confirming the security of the second autonomous system based on the first trusted routing information includes: The configuration information of the second autonomous domain is verified for security purposes to confirm the security of the second autonomous domain.

10. The method as described in claim 9, characterized in that, The security verification of the configuration information of the second autonomous domain includes: The configuration information is verified for security according to the second evaluation rule, which is a security evaluation rule supported by the first autonomous domain.

11. The method according to any one of claims 1-10, characterized in that, The first device is a trusted controller within the first autonomous domain; After confirming the security of the second autonomous system based on the first trusted routing information, the method further includes: Send confirmation results regarding the security of the second autonomous domain to some or all of the routing devices in the first autonomous domain.

12. The method as described in claim 11, characterized in that, The confirmation result includes a second indication, which indicates whether the second autonomous domain is secure; or, the confirmation result includes the trust level of the second autonomous domain.

13. The method according to any one of claims 1-12, characterized in that, The first device is a trusted controller within the first autonomous system, and the second device is a trusted controller within the second autonomous system; The step of obtaining the first trusted routing information from the second device includes: Send a request to the second device to obtain trusted routing information about the second autonomous domain; Receive the first trusted routing information sent by the second device.

14. The method as described in claim 13, characterized in that, The acquisition request carries the identifier of the second evaluation rule, which is a security evaluation rule supported by the first autonomous system, and the first trusted routing information is obtained when the second autonomous system supports the second evaluation rule.

15. The method as described in claim 13 or 14, characterized in that, After confirming the security of the second autonomous system based on the first trusted routing information, the method further includes: If the security of the second autonomous domain is confirmed, a path establishment request is sent to the second device, the path establishment request carrying the first path parameters; Receive the second path parameters returned by the second device in response to the path establishment request; A third path parameter is sent to the first routing device to instruct the first routing device to establish a communication path with the second autonomous system using the third path parameter, wherein the third path parameter is determined based on the second path parameter, and the first routing device is a routing device within the first autonomous system.

16. The method according to any one of claims 1-12, characterized in that, The first device is a trusted controller within the first autonomous system, and the second device is a routing device within the second autonomous system; The step of obtaining the first trusted routing information from the second device includes: The system receives trusted routing information for one or more autonomous systems reported by a second routing device. The trusted routing information for one or more autonomous systems includes the first trusted routing information. The second routing device is a routing device within the first autonomous system. The trusted routing information for one or more autonomous systems is obtained from a routing message. The first trusted routing information is added to the routing message by the second device.

17. The method as described in claim 16, characterized in that, The second autonomous system is any autonomous system on the transmission path of the routing message.

18. The method as described in claim 16 or 17, characterized in that, The trusted routing information of the one or more autonomous systems refers to the trusted routing information of some or all of the autonomous systems covered by the transmission path of the routing message.

19. The method according to any one of claims 16-18, characterized in that, The routing message is a Border Gateway Protocol (BGP) update message.

20. The method as described in claim 19, characterized in that, The routing message carries trusted routing information path attributes, which include an attribute type code field, an attribute length field, and an attribute value field. The attribute type code field indicates the type of information in the attribute value field; The attribute length field indicates the length of the attribute value field; The attribute value field carries trusted routing information for the one or more autonomous systems.

21. The method as described in claim 20, characterized in that, The attribute value field includes one or more attribute value subfields, which carry trusted routing information for the one or more autonomous systems. Each attribute value subfield carries trusted routing information for one autonomous system, and different attribute value subfields carry trusted routing information for different autonomous systems.

22. The method as described in claim 21, characterized in that, The trusted routing information includes the identifier of the corresponding autonomous system.

23. The method as described in claim 21 or 22, characterized in that, The trusted routing information includes the signature of the trusted routing information by the corresponding autonomous system.

24. The method as described in claim 19, characterized in that, The routing message carries BGP security path attributes, which include a security path field and a signature field. The security path field carries trusted routing information for the one or more autonomous systems, and the signature field carries a signature of the security path field.

25. The method as described in claim 24, characterized in that, The secure path field includes one or more secure path segments, wherein a secure path segment corresponds to an autonomous system on the transmission path of the routing message, different secure path segments correspond to different autonomous systems, and some or all of the one or more secure path segments carry trusted routing information of the one or more autonomous systems.

26. The method as described in claim 25, characterized in that, Each secure path segment includes an autonomous system identifier field, which carries the identifier of the corresponding autonomous system.

27. The method as described in claim 25 or 26, characterized in that, Each secure path segment includes a flag field, which includes a trusted routing enable bit. The trusted routing enable bit indicates that the corresponding secure path segment also includes a trusted routing information field, which carries trusted routing information for the corresponding autonomous system, or indicates that the corresponding secure path segment does not carry trusted routing information.

28. The method according to any one of claims 23-27, characterized in that, The trusted routing information for the one or more autonomous systems is received after the second routing device has verified the signature; and / or, The operation of confirming the security of the second autonomous domain based on the first trusted routing information is performed after the first device has verified the signature.

29. A security verification method for an autonomous system, characterized in that, The method is applied to a second routing device, which belongs to a first autonomous system. The method includes: The system receives a first routing message sent by a third routing device. The first routing message carries trusted routing information for one or more autonomous systems. The trusted routing information for the one or more autonomous systems includes first trusted routing information, which is trusted routing information for a second autonomous system. The first trusted routing information is used to prove the security of the second autonomous system. The third routing device is a peer of the second routing device. The trusted routing information of the one or more autonomous systems is reported to the first trusted controller, which is a trusted controller within the first autonomous system. The system receives an acknowledgment from the first trusted controller, the acknowledgment including confirmation of the security of the second autonomous domain.

30. The method as described in claim 29, characterized in that, The second autonomous system is any autonomous system on the transmission path of the first routing message.

31. The method as described in claim 29 or 30, characterized in that, The trusted routing information of the one or more autonomous systems refers to the trusted routing information of some or all of the autonomous systems covered by the transmission path of the first routing message.

32. The method according to any one of claims 29-31, characterized in that, The first routing message is a Border Gateway Protocol (BGP) update message.

33. The method as described in claim 32, characterized in that, The first routing message carries trusted routing information path attributes, which include an attribute type code field, an attribute length field, and an attribute value field. The attribute type code field indicates the type of information in the attribute value field; The attribute length field indicates the length of the attribute value field; The attribute value field carries trusted routing information for the one or more autonomous systems.

34. The method as described in claim 33, characterized in that, The attribute value field includes one or more attribute value subfields, which carry trusted routing information for the one or more autonomous systems. Each attribute value subfield carries trusted routing information for one autonomous system, and different attribute value subfields carry trusted routing information for different autonomous systems.

35. The method as described in claim 34, characterized in that, The trusted routing information includes the identifier of the corresponding autonomous system.

36. The method as described in claim 34 or 35, characterized in that, The trusted routing information includes the signature of the trusted routing information by the corresponding autonomous system.

37. The method as described in claim 32, characterized in that, The first routing message carries BGP security path attributes, which include a security path field and a signature field. The security path field carries the routing information, and the signature field carries a signature of the security path field.

38. The method as described in claim 37, characterized in that, The secure path field includes one or more secure path segments, wherein one secure path segment corresponds to an autonomous system on the transmission path of the first routing message, different secure path segments correspond to different autonomous systems, and some or all of the one or more secure path segments carry trusted routing information of the one or more autonomous systems.

39. The method as described in claim 38, characterized in that, Each secure path segment includes an autonomous system identifier field, which carries the identifier of the corresponding autonomous system.

40. The method as described in claim 39, characterized in that, Each secure path segment also includes a flag field, which includes a trusted routing enable bit. The trusted routing enable bit indicates that the corresponding secure path segment also includes a trusted routing information field, which carries trusted routing information for the corresponding autonomous system, or indicates that the corresponding secure path segment does not carry trusted routing information.

41. The method according to any one of claims 36-40, characterized in that, The trusted routing information for the one or more autonomous systems is reported by the second routing device after the signature verification is successful.

42. The method according to any one of claims 29-41, characterized in that, After receiving the first routing message sent by the third routing device, the method further includes: The first routing message is updated, and the updated first routing message contains second trusted routing information, which is the trusted routing information of the first autonomous system. The updated first routing message is sent to a fourth routing device, which is another peer of the second routing device.

43. The method as described in claim 42, characterized in that, The transmission path of the first routing message covers multiple autonomous systems, including the second autonomous system. The first routing message does not carry trusted routing information for some or all of the autonomous systems other than the second autonomous system. The update of the first routing message includes: Add the second trusted routing information to the first routing message, and add trusted routing information for some or all autonomous systems, wherein the trusted routing information for some or all autonomous systems is a default value.

44. The method as described in claim 43, characterized in that, The first routing message carries trusted routing information path attributes, the trusted routing information path attributes carry an attribute flag field and an attribute value field, the attribute flag field includes partial bits, and the partial bits indicate that the trusted routing information path attributes are not recognized by the third routing device, and the attribute value field carries trusted routing information of the one or more autonomous systems; The update of the first routing message further includes: The modified bits indicate that the trusted routing information routing attributes have been recognized and confirmed to be complete by the second routing device.

45. The method according to any one of claims 29-44, characterized in that, The method further includes: A second routing message is generated, which carries second trusted routing information, and the second trusted routing information is the trusted routing information of the first autonomous system. The second routing message is transmitted to a fifth routing device, which is a peer of the second routing device.

46. ​​The method according to any one of claims 29-45, characterized in that, The method further includes: Receive a third routing message sent by a sixth routing device, wherein the sixth routing device is a peer of the second routing device, and the third routing message does not carry trusted routing information; The third routing message is updated, and the updated third routing message carries the second trusted routing information, which is the trusted routing information of the first autonomous system. The updated third routing message is sent to a seventh routing device, which is another peer of the second routing device.

47. The method as described in claim 46, characterized in that, The updated third-routing message includes: The second trusted routing information is added to the third routing message, as well as trusted routing information for autonomous systems other than the first autonomous system whose transmission path is already covered by the third routing message. The trusted routing information for autonomous systems other than the first autonomous system is a default value.

48. The method according to any one of claims 29-47, characterized in that, The first trusted routing information includes the identifier of a first evaluation rule, which is a security evaluation rule supported by the second autonomous system. The first trusted routing information is determined according to the first evaluation rule. The second autonomous system supports a second evaluation rule, which may be the same as or different from the first evaluation rule.

49. The method according to any one of claims 29-48, characterized in that, The first trusted routing information includes the identifier or download address of a verification report, which is used to prove the security of the second autonomous domain.

50. The method as described in claim 49, characterized in that, The first trusted routing information also includes a timestamp, which indicates the validity period of the verification report.

51. The method as described in claim 49 or 50, characterized in that, The verification report records the trust level of the second autonomous domain, and / or the first trusted routing information also includes the trust level of the second autonomous domain.

52. The method according to any one of claims 29-51, characterized in that, The first trusted routing information also includes the identifier of a trusted verifier. The identifier of the trusted verifier is used by the first trusted controller to verify the trusted routing information of the one or more autonomous systems through the trusted verifier in order to obtain the confirmation result.

53. A security verification device for an autonomous system, characterized in that, The apparatus is used to perform the method according to any one of claims 1-28, or to perform the method according to any one of claims 29-52.

54. A communication device, characterized in that, The communication device includes a processor and a memory; The memory is used to store computer programs; The processor is configured to run the computer program to perform the method according to any one of claims 1-28, or to perform the method according to any one of claims 29-52.

55. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-28, or the method described in any one of claims 29-52.

56. A computer program product, characterized in that, The computer program product stores computer instructions, which, when executed by a processor, implement the method described in any one of claims 1-28, or the method described in any one of claims 29-52.

Images