A method and apparatus for emergency synchronization of RPKI dependency cache based on online cooperation

Abstract

This invention relates to an emergency synchronization method and apparatus for RPKI dependent party cache based on online cooperation, belonging to the field of router research. The method establishes an online cooperation mechanism among dependent parties within the same autonomous system (AS), electing a primary dependent party that maintains good ROA information synchronization with the resource repository. The primary dependent party saves the ROA information obtained from the resource repository into a localized ROA information file. A problematic dependent party can request its localized ROA information file from the primary dependent party, update its ROA information cache, and publish it to its affiliated routers. Ultimately, this enables the local cache to be updated with the latest ROA information even when disconnected from the resource repository. This invention avoids the network unreachability problem caused by the router's inability to obtain ROA information for routing information authenticity verification.

Description

Technical Field

[0001] This invention relates to an emergency synchronization method and apparatus for RPKI dependent party cache based on online cooperation, belonging to the field of router research. Background Technology

[0002] BGP (Border Gateway Protocol) is a standard protocol that supports connectivity between Autonomous Systems (AS) on the Internet. However, because BGP itself does not provide any security guarantees, each AS can announce arbitrary routes to other ASs without verifying their correctness. This mechanism makes BGP highly vulnerable to various malicious attacks, such as prefix hijacking. To address the network security risks posed by route hijacking, the IETF (Internet Engineering Task Force) developed and standardized RPKI (Resource Public Key Infrastructure), aiming to provide a secure and reliable authentication system for route exchange between ASs.

[0003] RPKI is a hierarchical authentication system designed to combat route prefix hijacking. By allocating and verifying ownership of INRs (Internet Number Resources), it has become a technical consensus for solving current Internet domain routing security problems. Currently, RPKI is not only the only standardized solution for route prefix hijacking to date, but also a prerequisite for important routing security mechanisms such as BGPsec. The RPKI architecture can be mainly divided into a certificate issuance system, an RPKI resource repository, and dependencies. The certificate issuance system is responsible for issuing certificates to identify the hierarchical allocation relationship of INRs and issuing ROAs (Route Origin Authorizations) to authorize an AS to initiate route origin advertisements for its own IP prefix. The RPKI repository stores various authorization certificates and ROAs issued by the certificate issuance system. The dependent party is responsible for synchronizing ROAs from the RPKI repository, verifying the validity of ROAs based on the certificates, and extracting the IP address prefixes and their corresponding ASNs (ASNs are Autonomous System Numbers, unique identifiers of Autonomous Systems, assigned by Internet Assigned Numbers Authority (IANA) and regional Internet Registries. In the Internet routing system, the exchange of routing information between Autonomous Systems is mainly achieved through the Border Gateway Protocol (BGP), which uses ASNs to identify each Autonomous System) from all valid ROAs to generate a route filtering table. This route filtering table is then distributed to the BGP router via the RTR protocol [rtr] to guide BGP in performing route source verification. It is evident that the dependent party plays a crucial role in the data transmission process of the RPKI system, acting as a bridge between upstream and downstream processes. Once the dependent party loses connection with the resource repository, the BGP routers connected to that RP will be unable to obtain the route filtering table for source verification. As RPKI is gradually deployed globally, the corresponding data transmission scale is rapidly increasing, making the stable operation of RPKI data transmission of paramount importance.

[0004] The dependent party periodically synchronizes and verifies relevant certificates and ROA information from the RPKI database. Verified ROA information is stored in a local cache, and the verification data is then distributed to routers to guide BGP in route source verification. Multiple dependent parties are often deployed within the same autonomous system to achieve load balancing. Before this, the RPKI database first synchronizes data to the dependent party, mostly using the mainstream rsync (Remote Synchronize) protocol for data transmission. The rsync protocol has advantages such as fast synchronization speed and support for both full and incremental synchronization, making it very suitable for data synchronization between the database and the dependent party. However, this protocol is vulnerable to malicious attacks such as denial-of-service attacks, which can prevent the dependent party from obtaining data from the database or even disconnect it. Furthermore, factors such as certificate expiration can also cause the dependent party to lose connection with the database. Once the dependent party disconnects from the database, all BGP routers connected to that dependent party will be unable to verify the authenticity of the routing information, causing the network passing through that router to become unreachable.

[0005] How to ensure that the dependent party can still obtain complete ROA information in real time and effectively when it is under malicious attack or disconnected from the RPKI database is a key issue to prevent network unreachability failures caused by the BGP router's inability to obtain ROA information for route information authenticity verification. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides an emergency synchronization method and apparatus for RPKI dependency cache based on online cooperation. The online cooperation mechanism offers an economical and efficient way for dependencies that have lost contact with the RPKI repository for various reasons to obtain ROA information in real time. This method establishes an online cooperation mechanism among dependencies within the same autonomous system (AS). It elects primary and secondary dependencies that are well-synchronized with the RPKI repository regarding ROA information. These primary and secondary dependencies store the ROA information obtained from the RPKI repository as localized ROA information files. When a dependency within the AS cannot obtain information from the RPKI repository and becomes a problematic dependency, it requests its localized ROA information file from the primary dependency. The problematic dependency then updates its ROA information cache with the localized ROA information file and publishes it to its affiliated routers. Ultimately, this achieves the function of updating the local cache with the latest ROA information even when disconnected from the RPKI repository. This invention enables dependent parties disconnected from the RPKI resource library to obtain the latest ROA information in real time through emergency synchronization with dependent parties within the domain, thereby avoiding the network unreachability problem caused by the BGP router's inability to obtain ROA information for route information authenticity verification.

[0007] The present invention adopts the following technical solution: An emergency synchronization method for RPKI dependency cache based on online cooperation includes the following steps: S100: After each dependent program starts, it creates a dependent information table within the autonomous system and configures initial values; S200: The dependent program creates an RPKI repository monitoring table in each dependent and configures initial values; S300: Scan the dependency information table within the autonomous system, retrieve the IP addresses of the dependencies, and send a primary dependency election message to all dependencies except itself. S400: Create a network socket, listen for network data, and prepare to receive packets; Network sockets play a crucial role in computer networks, serving as endpoint communication components. They act as endpoints for bidirectional communication between application processes on different hosts within a network, providing a mechanism for application-layer processes to exchange data using network protocols. This allows programmers to implement network communication within applications, enabling two computers to connect and exchange data. A network socket is one end of a network communication process, providing a mechanism for application-layer processes to exchange data using network protocols. It connects to the application process upstream and the network protocol stack downstream, serving as the interface for applications to communicate via network protocols and for applications to interact with the network protocol stack. In socket programming, a socket typically acts as an endpoint for both communicating parties, allowing them to transmit data. In the TCP protocol, the server needs to actively listen for connection requests from clients. Therefore, network sockets can listen for network data to enable the server to receive and process client connection requests.

[0008] S500: The dependent party receives the main dependent party election message sent by S300 and compares the ROA information timestamp of the message with the ROA information timestamp of the RPKI monitoring table in the dependent party receiving the message. If the value of the ROA information timestamp of the RPKI monitoring table of the dependent party receiving the message is greater than the value of the message timestamp, then proceed to S501; otherwise, ignore the election message information and return to S400. S501: Scan the dependency information table within the autonomous system, find the entry record under the dependency IP address that is the same as the dependency IP address that received the election message in S500, then assign the timestamp in this entry record to the timestamp value of the last time the election message received by S500 retrieved ROA information from the RPKI resource library, and increment the counter of this entry record by 1; that is, using the dependency IP address field extracted from the message in step S500, scan the dependency information table within the autonomous system, find the entry record in the dependency information table that matches the dependency IP address, use the timestamp of the last ROA information update extracted from the message in step S500 to update the timestamp field in the entry record, and increment the counter field in the record by 1; S502: Scan the dependency information table within the autonomous system (each entry in the autonomous system dependency information table corresponds to a dependency information, that is, all dependency type flags in the dependency information table of the currently executing dependency program are set to 0), set the value of the type flag of all entries to 0, after the scan is completed, record the dependency record within the autonomous system whose timestamp is closest to the current time, set the value of the type flag of the record to 1, that is, determine it as the primary dependency, and return to S400; S600: All dependent programs send a message to the RPKI repository requesting ROA information, scan the RPKI repository monitoring table, obtain the RPKI repository monitoring table information, set a 5-second timer, if the ROA information sent by the RPKI repository is received before the timer expires, the ROA information in the message is extracted and step S601 is executed; if the message is not received before the timer expires, step S602 is executed. S601: Using the RPKI resource library monitoring table record obtained from step S600, extract the timestamp field, set the value of the timestamp field to the current system time, extract the disconnection alarm threshold field, increment its value by 1 (i.e., increment the disconnection alarm threshold by 1), update the dependent party's local cache with the ROA information extracted in step S600, and save the localized ROA information file. S602: Using the RPKI resource library monitoring table record obtained from step S600, extract the disconnection alarm threshold field and decrement its value by 1 (i.e., decrement the disconnection alarm threshold by 1). S700: Using the records in the RPKI resource library monitoring table recorded in step S600, retrieve the value of the disconnect alarm threshold field. If the disconnect alarm threshold is less than or equal to 0, it means that the dependent party corresponding to this record is a problematic dependent party. Then execute step S701. If it is greater than zero, execute step S702. S701: Scan the dependency information table within the autonomous system, extract the record with the type flag field being 1, i.e. the record of the main dependency, extract the IP address of the main dependency, send a request message to obtain the localized ROA information file saved in step S601 with the IP address as the destination address, and return to step S400 to continue execution. S702: Sets a 5-second timer; after the timer expires, the dependent program returns to S600. S800: If the dependent program receives a response message to obtain the localized ROA information saved in step S601, it extracts the main dependent IP address and localized ROA information from the message, and scans the dependent information table within the autonomous system using the main dependent IP address. If a record is found and the type flag field in the record is 1, then step S801 is executed; otherwise, step S802 is executed. S801: Update the local ROA cache of the dependent party using the localized ROA information obtained in step S800; S802: Ignore the response message received this time for obtaining localized ROA information; S900: Set a 5-second timer. After the timer expires, return to step S600 to continue execution.

[0009] In this invention, the purpose of steps S600 to S700 is to identify the problematic dependent party. Steps S700 to S800 are the process of emergency synchronization of the problematic dependent party. However, step S800 will run independently even if there is no problematic dependent party.

[0010] Preferably, in step S100, the dependency information table within the autonomous system includes the dependency IP address, timestamp, counter, and type tag. The dependency IP address is the IP address of the host running the dependency software within the autonomous system, the timestamp is the time of the last communication between the current dependency and the RPKI repository, the counter is the number of times it has communicated with the current dependency, and the type tag is the type to which the current dependency belongs. 1 indicates that the dependency is a primary dependency. The initial dependency program creates an autonomous system dependency information table for each dependency within the autonomous system. The dependency IP address is initialized to the IP address of the dependency within the autonomous system, the timestamp of the last updated ROA information is initialized to 0, the counter is initialized to 0, and the type flag is initialized to 1 for the first record and 0 for the other records.

[0011] Preferably, in step S200, the RPKI repository monitoring table includes a timestamp and a disconnection alarm threshold, wherein the timestamp is the time of the last communication between the current dependent party and the RPKI repository, and the disconnection alarm threshold is the maximum value of the current dependent party's failed attempts to connect to the RPKI repository; When configuring initial values, the timestamp is initialized to 0, the disconnection alarm threshold is initialized to 5, and the RPKI repository monitoring table is visible if the dependent program can maintain a connection with the RPKI repository; otherwise, all fields in the RPKI repository monitoring table are assigned initial values.

[0012] Preferably, in step S300, the primary dependent party election message includes the IP address of the dependent party that sent the election message and the timestamp information of the last time the dependent party that sent the election message obtained ROA information from the RPKI resource library.

[0013] An emergency synchronization device for RPKI dependency cache based on online cooperation includes an RPKI repository, a dependency, and a router. The dependency is used to execute the above-mentioned emergency synchronization method for RPKI dependency cache based on online cooperation. The primary dependency is used to save the ROA information obtained from the RPKI repository into a localized ROA information file. When a dependency in the same autonomous system cannot obtain information from the RPKI repository normally and becomes a problematic dependency, the problematic dependency can request the primary dependency to obtain its localized ROA information file, update its ROA information cache, and publish it to the routers under its jurisdiction.

[0014] For any details not covered in this invention, please refer to the prior art.

[0015] The beneficial effects of this invention are as follows: This invention establishes an online cooperation mechanism among dependent parties within the same autonomous system (AS). A primary dependent party with good ROA information synchronization with the RPKI repository is elected from among the dependent parties in the AS. This primary dependent party saves the ROA information obtained from the RPKI repository as a localized ROA information file. When a dependent party in the AS cannot obtain information from the RPKI repository and becomes a problematic dependent party, it requests its localized ROA information file from the primary dependent party. The problematic dependent party obtains the localized ROA information file, updates its ROA information cache, and publishes it to its affiliated routers. Ultimately, this achieves the function of updating the local cache with the latest ROA information even when disconnected from the RPKI repository. This invention enables dependent parties disconnected from the RPKI repository to obtain the latest ROA information in real time through emergency synchronization with dependent parties in the AS, thus avoiding network unreachability failures caused by BGP routers being unable to obtain ROA information for route information authenticity verification. Attached Figure Description

[0016] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

[0017] Figure 1 A schematic diagram of the emergency synchronization method and device topology for RPKI dependency caching based on online cooperation; Figure 2 This is a schematic diagram of the dependent party information table within an autonomous domain; Figure 3 This is a schematic diagram of the RPKI resource database monitoring entries; Figure 4 This is a schematic diagram of the election message for the primary dependent party; Figure 5 A schematic diagram of a message used to retrieve ROA information from an RPKI repository; Figure 6 A diagram illustrating a request message for obtaining localized ROA information; Figure 7 This is a flowchart of the dependent program. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. However, this is not the only description; all aspects not described in detail herein are based on conventional techniques in the art.

[0019] A schematic diagram of the RPKI dependency cache emergency synchronization method and device topology based on online cooperation is shown below. Figure 1The application scenario diagram of the present invention is shown in the figure. The left side of the figure is the Internet number resource allocation architecture, which is used to mark the position of the present invention in the architecture. The right side of the figure shows the process of the present invention actually acting on each router in the autonomous system. Each dependent program in the autonomous system obtains authentication information data from the RPKI resource library and sends it to each router in the autonomous system.

[0020] The IANA on the left of the diagram stands for Internet Assigned Numbers Authority. It is responsible for the global allocation of IP addresses and ASNs, as well as the management and protocol allocation of DNS root zones.

[0021] RIPE NCC stands for Reseaux IP Europeens NetworkCoordination Centre.

[0022] AFRNIC stands for Africa Network Information Centre.

[0023] APNIC stands for Asia Pacific Network Information Centre.

[0024] LACNIC stands for the Latin American and Caribbean Network Information Centre in computer networks. LACNIC is an international non-governmental organization established in Uruguay in 2002. It is responsible for allocating and managing Internet resources (IPv4, IPv6), Autonomous System Numbers (ASNs), Reverse Resolution, and other resource identifiers for the Latin American and Caribbean region.

[0025] ARIN stands for the Internet Digital Registry, an agency responsible for managing the registration of IP addresses and Autonomous System Numbers (ASNs) in North America and the Caribbean.

[0026] LIR stands for Local Internet Registry. LIRs are responsible for managing and allocating IP addresses and AS numbers to local Internet Service Providers (ISPs). Under an RIR, the LIR typically handles the allocation of IP addresses and AS numbers to ISPs and assists ISPs with address registration and renewal.

[0027] NIR stands for Network Information Registry. An NIR is a non-governmental organization responsible for managing the allocation of IP addresses and AS numbers to Internet Service Providers in its region. NIRs typically work with RIRs to ensure the proper allocation and management of IP addresses and AS numbers.

[0028] Local Internet Registries (LIRs) designate ISPs as Internet Service Providers. ISPs provide services such as dial-up internet access, web browsing, file downloading, and email, serving as the gateway and bridge for end-users to access the Internet.

[0029] See the diagram of dependent items within the autonomous domain. Figure 2 The table entries are shown in the figure. Each dependency information occupies a separate entry. Each entry consists of a 32-bit dependency IP address, a 32-bit timestamp of the last time the dependency obtained ROA information from the RPKI repository, a 16-bit counter, and a 1-bit type flag.

[0030] See the schematic diagram of the RPKI resource database monitoring items. Figure 3 The monitoring table entries are shown in the figure. This table consists of two fields: a 32-bit timestamp field for the last communication between the current dependent party and the RPKI resource library, and an 8-bit disconnection alarm threshold field.

[0031] See the diagram of the primary dependent party election message. Figure 4 The election message entry, as shown in the figure, consists of two fields: a 32-bit timestamp field and a 32-bit timestamp field indicating the last communication between the current dependent party and the RPKI repository.

[0032] See the diagram below for a message used to retrieve ROA information from the RPKI repository. Figure 5 It consists of two fields: a 32-bit primary dependent IP address field and a 32-bit localized ROA information field.

[0033] See the diagram of the request message for obtaining localized ROA information. Figure 6 The message consists of a header and a data portion. Taking the common 20-byte IPv4 header as an example, the request message type, which indicates that this message is a request for localized ROA information, occupies 2 bits. Example 1

[0034] An emergency synchronization method for RPKI dependency cache based on online cooperation, such as Figure 7 As shown, it includes the following steps: S100: After each dependent program starts, it creates a dependent information table within the autonomous system and configures initial values; S200: The dependent program creates an RPKI repository monitoring table in each dependent and configures initial values; S300: Scan the dependency information table within the autonomous system, retrieve the IP addresses of the dependencies, and send a primary dependency election message to all dependencies except itself. S400: Create a network socket, listen for network data, and prepare to receive packets; Network sockets play a crucial role in computer networks, serving as endpoint communication components. They act as endpoints for bidirectional communication between application processes on different hosts within a network, providing a mechanism for application-layer processes to exchange data using network protocols. This allows programmers to implement network communication within applications, enabling two computers to connect and exchange data. A network socket is one end of a network communication process, providing a mechanism for application-layer processes to exchange data using network protocols. It connects to the application process upstream and the network protocol stack downstream, serving as the interface for applications to communicate via network protocols and for applications to interact with the network protocol stack. In socket programming, a socket typically acts as an endpoint for both communicating parties, allowing them to transmit data. In the TCP protocol, the server needs to actively listen for connection requests from clients. Therefore, network sockets can listen for network data to enable the server to receive and process client connection requests.

[0035] S500: The dependent party receives the main dependent party election message sent by S300 and compares the ROA information timestamp of the message with the ROA information timestamp of the RPKI monitoring table in the dependent party receiving the message. If the value of the ROA information timestamp of the RPKI monitoring table of the dependent party receiving the message is greater than the value of the message timestamp, then proceed to S501; otherwise, ignore the election message information and return to S400. S501: Scan the dependency information table within the autonomous system, find the entry record under the dependency IP address that is the same as the dependency IP address that received the election message in S500, then assign the timestamp in this entry record to the timestamp value of the last time the election message received by S500 retrieved ROA information from the RPKI resource library, and increment the counter of this entry record by 1; that is, using the dependency IP address field extracted from the message in step S500, scan the dependency information table within the autonomous system, find the entry record in the dependency information table that matches the dependency IP address, use the timestamp of the last ROA information update extracted from the message in step S500 to update the timestamp field in the entry record, and increment the counter field in the record by 1; S502: Scan the dependency information table within the autonomous system (each entry in the autonomous system dependency information table corresponds to a dependency information, that is, all dependency type flags in the dependency information table of the currently executing dependency program are set to 0), set the value of the type flag of all entries to 0, after the scan is completed, record the dependency record within the autonomous system whose timestamp is closest to the current time, set the value of the type flag of the record to 1, that is, determine it as the primary dependency, and return to S400; The dependent program runs in each dependent program, and each dependent program executes steps S500~S502 and follows the steps outlined in the code. Figure 7 There is no fixed order in which the process executes, compares, and updates dependencies.

[0036] S600: All dependent programs send a message to the RPKI repository requesting ROA information, scan the RPKI repository monitoring table, obtain the RPKI repository monitoring table information, set a 5-second timer, if the ROA information sent by the RPKI repository is received before the timer expires, the ROA information in the message is extracted and step S601 is executed; if the message is not received before the timer expires, step S602 is executed. S601: Using the RPKI resource library monitoring table record obtained from step S600, extract the timestamp field, set the value of the timestamp field to the current system time, extract the disconnection alarm threshold field, increment its value by 1 (i.e., increment the disconnection alarm threshold by 1), update the dependent party's local cache with the ROA information extracted in step S600, and save the localized ROA information file. S602: Using the RPKI resource library monitoring table record obtained from step S600, extract the disconnection alarm threshold field and decrement its value by 1 (i.e., decrement the disconnection alarm threshold by 1). S700: Using the records in the RPKI resource library monitoring table recorded in step S600, retrieve the value of the disconnect alarm threshold field. If the disconnect alarm threshold is less than or equal to 0, it means that the dependent party corresponding to this record is a problematic dependent party. Then execute step S701. If it is greater than zero, execute step S702. S701: Scan the dependency information table within the autonomous system, extract the record with the type flag field being 1, i.e. the record of the main dependency, extract the IP address of the main dependency, send a request message to obtain the localized ROA information file saved in step S601 with the IP address as the destination address, and return to step S400 to continue execution. S702: Sets a 5-second timer; after the timer expires, the dependent program returns to S600. S800: If the dependent program receives a response message to obtain the localized ROA information saved in step S601, it extracts the main dependent IP address and localized ROA information from the message, and scans the dependent information table within the autonomous system using the main dependent IP address. If a record is found and the type flag field in the record is 1, then step S801 is executed; otherwise, step S802 is executed. S801: Update the local ROA cache of the dependent party using the localized ROA information obtained in step S800; S802: Ignore the response message received this time for obtaining localized ROA information; S900: Set a 5-second timer. After the timer expires, return to step S600 to continue execution.

[0037] according to Figure 7 As shown, once the dependent program starts, it will proceed step by step according to the execution order of the flowchart. S500, S600, and S800 are programs that execute in parallel after S400. As long as there are no unexpected interruptions (power outages, memory leaks, or program crashes due to programming flaws), the program will continue to advance as shown in the flowchart. Figure 7 It is evident that this program is a loop, and will eventually return to the S400 loop for execution, used for caching emergency synchronization. Example 2

[0038] An emergency synchronization device for RPKI dependency cache based on online cooperation includes an RPKI repository, a dependency, and a router. The dependency is used to execute the emergency synchronization method for RPKI dependency cache based on online cooperation of Embodiment 1. The primary dependency is used to save the ROA information obtained from the RPKI repository into a localized ROA information file. When a dependency in the same autonomous system cannot obtain information from the RPKI repository normally and becomes a problem dependency, the problem dependency can request the primary dependency to obtain its localized ROA information file, update its ROA information cache, and publish it to the router under its jurisdiction.

[0039] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for emergency synchronization of RPKI dependency cache based on online cooperation, characterized in that, Includes the following steps: S100: After each dependent program starts, it creates a dependent information table within the autonomous system and configures initial values; S200: The dependent program creates an RPKI repository monitoring table in each dependent and configures initial values; S300: Scan the dependency information table within the autonomous system, retrieve the IP addresses of the dependencies, and send a primary dependency election message to all dependencies except itself. S400: Create a network socket, listen for network data, and prepare to receive packets; S500: The dependent party receives the main dependent party election message sent by S300 and compares the ROA information timestamp of the message with the ROA information timestamp of the RPKI monitoring table in the dependent party receiving the message. If the value of the ROA information timestamp of the RPKI monitoring table of the dependent party receiving the message is greater than the value of the message timestamp, then proceed to S501; otherwise, ignore the election message information and return to S400. S501: Scan the dependency information table within the autonomous system, find the table entry record under the dependency IP address that is the same as the dependency IP address that received the election message in S500, then assign the timestamp in this table entry record to the timestamp value of the last time the election message received by S500 obtained ROA information from the RPKI resource library, and increment the counter of this table entry record by 1. S502: Scan the dependency information table within the autonomous system, set the type flag value of all entries to 0, after the scan is complete, record the dependency record within the autonomous system whose timestamp is closest to the current time, set the type flag value of the record to 1, that is, determine it as the primary dependency, and return to S400; S600: All dependent programs send a message to the RPKI repository requesting ROA information, scan the RPKI repository monitoring table, obtain the RPKI repository monitoring table information, set a 5-second timer, if the ROA information sent by the RPKI repository is received before the timer expires, the ROA information in the message is extracted and step S601 is executed; if the message is not received before the timer expires, step S602 is executed. S601: Using the RPKI resource library monitoring table record obtained from step S600, extract the timestamp field, set the value of the timestamp field to the current system time, extract the disconnection alarm threshold field, increment its value by 1, update the dependent party's local cache with the ROA information extracted in step S600, and save the localized ROA information file. S602: Using the RPKI resource library monitoring table record obtained from step S600, extract the disconnection alarm threshold field and decrement its value by 1; S700: Using the records in the RPKI resource library monitoring table recorded in step S600, retrieve the value of the disconnect alarm threshold field. If the disconnect alarm threshold is less than or equal to 0, it means that the dependent party corresponding to this record is a problematic dependent party. Then execute step S701. If it is greater than zero, execute step S702. S701: Scan the dependency information table within the autonomous system, extract the record with the type flag field being 1, i.e. the record of the main dependency, extract the IP address of the main dependency, send a request message to obtain the localized ROA information file saved in step S601 with the IP address as the destination address, and return to step S400 to continue execution. S702: Sets a 5-second timer; after the timer expires, the dependent program returns to S600. S800: If the dependent program receives a response message to obtain the localized ROA information saved in step S601, it extracts the main dependent IP address and localized ROA information from the message, and scans the dependent information table within the autonomous system using the main dependent IP address. If a record is found and the type flag field in the record is 1, then step S801 is executed; otherwise, step S802 is executed. S801: Update the local ROA cache of the dependent party using the localized ROA information obtained in step S800; S802: Ignore the response message received this time for obtaining localized ROA information; S900: Set a 5-second timer. After the timer expires, return to step S600 to continue execution.

2. The emergency synchronization method for RPKI dependency cache based on online cooperation according to claim 1, characterized in that, In step S100, the dependency information table within the autonomous system includes the dependency IP address, timestamp, counter, and type tag. The dependency IP address is the IP address of the host running the dependency software within the autonomous system. The timestamp is the time of the last communication between the current dependency and the RPKI repository. The counter is the number of times the current dependency has communicated. The type tag is the type to which the current dependency belongs. 1 indicates that the dependency is a primary dependency. The initial dependency program creates an autonomous system dependency information table for each dependency within the autonomous system. The dependency IP address is initialized to the IP address of the dependency within the autonomous system, the timestamp of the last updated ROA information is initialized to 0, the counter is initialized to 0, and the type flag is initialized to 1 for the first record and 0 for the other records.

3. The emergency synchronization method for RPKI dependency cache based on online cooperation according to claim 2, characterized in that, In step S200, the RPKI repository monitoring table includes a timestamp and a disconnection alarm threshold, where the timestamp is the time of the last communication between the current dependent party and the RPKI repository, and the disconnection alarm threshold is the maximum number of times the current dependent party has failed to connect to the RPKI repository. When configuring initial values, the timestamp is initialized to 0, the disconnection alarm threshold is initialized to 5, and the RPKI repository monitoring table is visible if the dependent program can maintain a connection with the RPKI repository; otherwise, all fields in the RPKI repository monitoring table are assigned initial values.

4. The emergency synchronization method for RPKI dependency cache based on online cooperation according to claim 3, characterized in that, In step S300, the primary dependent party election message includes the IP address of the dependent party that sent the election message and the timestamp information of the last time the dependent party that sent the election message obtained ROA information from the RPKI resource repository.

5. An emergency synchronization device for RPKI dependency cache based on online cooperation, characterized in that, The system includes an RPKI repository, dependent parties, and routers. The dependent parties are used to execute the online cooperative RPKI dependent party cache emergency synchronization method described in claim 1. The primary dependent party is used to save the ROA information obtained from the RPKI repository into a localized ROA information file. When a dependent party within the same autonomous system cannot obtain information from the RPKI repository normally and becomes a problematic dependent party, the problematic dependent party can request the primary dependent party to obtain its localized ROA information file, update its ROA information cache, and publish it to the routers under its jurisdiction.

Images