A network node state data trust algorithm determination method and system

Abstract

This application provides a method and system for determining trusted algorithms for network node state data. The method includes: each network node's security state agent obtains available security algorithm information for the local XFRM framework through the Netlink interface, generating local state data with a unique node identifier and version number; synchronizing state data with neighboring nodes using the Gossip protocol, performing version number, integrity, and multi-source consistency checks on the received data, and marking algorithms corresponding to the same state data originating from at least two non-directly connected neighboring nodes as cluster trusted algorithms; generating a list of trusted algorithms for querying by the local IPsec process for security association negotiation. This application achieves dynamic discovery and trusted synchronization of cluster security algorithms, adapts to edge node and multi-region cluster scenarios, ensures synchronization reliability and security, and does not affect cluster operating performance.

Description

Technical Field

[0001] This application belongs to the field of network cluster security technology, specifically relating to a method and system for determining the trustworthy algorithm of network node status data. Background Technology

[0002] In Linux-based heterogeneous edge gateway clusters, gateway devices often establish secure tunnels via IPsec (Internet Protocol Security) to protect data. Since gateways may come from different vendors, their kernel versions and dynamically loadable XFRM (Transform Framework) security algorithm modules vary, and some edge gateways cannot run a centralized management agent due to resource limitations. In actual deployments, operations personnel need to manually configure IPsec security associations for each pair of gateways, which requires prior knowledge of the encryption or authentication algorithms actually supported by the peer kernel. Existing technologies typically rely on administrators manually logging into each gateway and trial-and-error through executing configuration commands one by one to confirm available security algorithms, resulting in extremely low configuration efficiency. When the number of gateways reaches thousands, it becomes almost impossible to complete a full network traversal. Other solutions attempt to exchange local algorithm information between network nodes via full broadcast, but lack the ability to distinguish the source of the information. False algorithm information reported by a single abnormal or malicious node can directly pollute the entire network configuration, posing security risks. Summary of the Invention

[0003] This application provides a method for determining the trustworthy algorithm for network node state data, enabling dynamic discovery and trusted synchronization of cluster security algorithms. It adapts to edge nodes and multi-region cluster scenarios, ensuring synchronization reliability and security without affecting cluster performance. This application also provides a system for determining the trustworthy algorithm for network node state data.

[0004] The first aspect of this application proposes a reliable algorithm method for determining network node state data, including: The security state agent running in user space on each network node obtains the available security algorithm information of the local XFRM framework through the Netlink interface in the Linux operating system kernel space, and generates local state data with a globally unique node identifier and a monotonically increasing version number. The security state agent uses the Gossip protocol to randomly select a preset number of neighbor nodes according to the synchronization period, sends the local state data to the selected neighbor nodes, and receives node state data from the neighbor nodes. The received node status data is subjected to version number verification and integrity verification. If the verification passes, the security algorithms in the node status data originating from at least two non-directly connected neighbor nodes are marked as cluster trusted algorithms, and a list of cluster trusted algorithms is generated for the local IPsec process to query during security association negotiation.

[0005] Optionally, the security state agent obtains available security algorithm information of the local XFRM framework through the Netlink interface in the Linux operating system kernel space, including: The security status agent sends a security algorithm query request to the kernel. After receiving the security algorithm query request through the Netlink interface, the kernel enters the RCU read critical section to obtain the algorithm registration list of the XFRM framework, traverses each node of the algorithm registration list to verify the registration status and lifecycle validity of the corresponding security algorithm, and exits the RCU read critical section after obtaining the available security algorithm. The available security algorithms are classified and counted by category to generate statistical quantity information. The common attribute information of each category of available security algorithms is extracted and stored in a continuous array structure in category order to obtain the common attribute array of the algorithms. Response data containing the statistical quantity information and the common attribute array of the algorithm is generated and returned to the security state agent through the Netlink interface.

[0006] Optionally, version number verification and integrity verification are performed on the received node status data, including: Compare the version number carried in the received node status data with the local version number of the corresponding node status data stored locally, and retain the node status data with a version number higher than the local version number. The integrity check value is recalculated for the retained node status data and compared with the integrity check value carried in the node status data. Node status data with inconsistent integrity check values ​​are filtered out, and node status data that passes the integrity check is taken as node status data that has passed the check.

[0007] Optionally, marking the security algorithm in node state data originating from at least two non-directly connected neighbor nodes as a cluster trusted algorithm includes: The verified node status data will be grouped according to the node identifier and status data content; For each group, if the node state data source node set within the group contains at least two non-directly connected neighbor nodes, then the security algorithm corresponding to the group is marked as a cluster trusted algorithm.

[0008] Optionally, a list of trusted cluster algorithms is generated for the local IPsec process to query during security association negotiation, including: Read all trusted algorithms in the cluster, classify and sort them according to algorithm type, and generate a list of trusted algorithms in the cluster; The list of trusted algorithms for the cluster is stored in the local storage area maintained by the security state agent and can be queried by the local IPsec process through a local interface.

[0009] Optional, also includes: Edge nodes send a secure algorithm state retrieval request to their directly connected neighbor nodes, carrying filtering rules that are used to filter target algorithm state data. The directly connected neighbor node receives the security algorithm status retrieval request, reads the filtering rules and the locally stored cluster status view, extracts the node status data of the security algorithm that matches the filtering rules, and returns it to the edge node. The edge node generates an event subscription rule and registers the event subscription rule with the directly connected neighbor node. The event subscription rule is a constraint condition used to filter events to be pushed. The directly connected neighbor node monitors change events in the local cluster status view, and pushes the corresponding event data to the edge node when the change event matches the event subscription rule.

[0010] Optional, also includes: The cluster where the network node is located is divided into multiple regional clusters according to the region. The regional cluster is an autonomous cluster unit composed of network nodes within the same region. Network nodes within each regional cluster synchronize node status data through the Gossip protocol. Version number verification and integrity verification are performed on the received node status data. The security algorithms in the node status data originating from at least two non-directly connected neighbor nodes in the verified node status data are marked as cluster trusted algorithms. Each regional cluster is configured with a preset number of gateway nodes. Gateway nodes in different regional clusters synchronize the node status data corresponding to the security algorithms that have been marked as trusted algorithms in their respective regions. The gateway node in the receiving region distributes the synchronized node status data as incremental node status data to all nodes in its regional cluster.

[0011] Optional, also includes: When a network node loses connection, it persists an incremental node status change log with a version number locally. After the network node reconnects, it sends the latest version number baseline to neighboring nodes. The version number baseline is the version number corresponding to the latest node status data stored by this node. The neighboring node compares the version number baseline with the locally stored node status data version number, and returns incremental node status data with a version number higher than the version number baseline to the reconnected network node; The network node sends its local version number baseline to its neighboring nodes at fixed intervals, and the neighboring node pushes the corresponding incremental node status data to the network node when it holds a higher version of node status data.

[0012] Optional, also includes: Network nodes monitor network packet loss rate in real time; When the network packet loss rate exceeds the preset network packet loss rate threshold, the fixed period is extended and the data window for a single synchronization is increased.

[0013] The second aspect of this application proposes a reliable algorithm system for determining network node state data, which includes multiple network nodes; The data acquisition module is used to obtain available security algorithm information of the local XFRM framework through the Netlink interface in the kernel space of the Linux operating system on each network node, and generate local state data with a globally unique node identifier and a monotonically increasing version number. The security status agent module is used to randomly select a preset number of neighbor nodes according to the synchronization period using the Gossip protocol, send the local status data to the selected neighbor nodes, and receive node status data from the neighbor nodes. The verification module is used to perform version number verification and integrity verification on the received node status data. If the verification passes, the security algorithm in the node status data originating from at least two non-directly connected neighbor nodes is marked as a cluster trusted algorithm, and a list of cluster trusted algorithms is generated for the local IPsec process to query during security association negotiation.

[0014] As can be seen from the above technical solution, the security state proxy of this application obtains the available XFRM algorithm information of the local machine through the Netlink interface, enabling the algorithm to be synchronized from the kernel space to the user space in real time, thus overcoming the problem that traditional methods cannot know the dynamically loaded kernel algorithm. This invention assigns a globally unique original node identifier and a monotonically increasing version number to each state data, providing a foundation for subsequent network-wide tracking of data sources and differentiation between old and new data. Proxy exchanges of state data use the Gossip protocol to randomly select neighbors, avoiding single points of failure in centralized synchronization and bandwidth storms from full broadcasts. The receiver performs version number verification, accepting only versions higher than the local record to prevent old data from overwriting new data, and performs integrity verification to filter out corrupted data, ensuring information integrity. Data that passes the preceding verification enters multi-source consistency verification. Only when the same state data arrives via at least two different non-directly connected neighbors is it considered trustworthy. This mechanism does not require any centralized voting; it relies solely on the multi-path forwarding characteristics of the Gossip protocol itself to exclude false algorithm information injected by a single malicious or faulty node. After being compiled into a list of trusted algorithms for the cluster, the local IPsec process can quickly select an algorithm supported by both ends for secure association negotiation based on this list, avoiding repeated trial and error and negotiation failures caused by algorithm inconsistencies. In summary, this application provides original data with source identification and version for synchronization through local probing, ensures that data from each node can reach the same receiver along multiple paths through Gossip random diffusion, and filters out untrusted and erroneous data through multi-layer verification, ensuring the real-time performance and reliability of the final cluster trusted algorithm list in dynamic heterogeneous clusters, thereby improving the success rate and automation level of IPsec configuration in large-scale edge gateway scenarios. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a method for determining the reliability of network node state data according to an embodiment of this application. Figure 2 This is a schematic diagram of the process by which the security state agent obtains available security algorithm information of the local XFRM framework through the Netlink interface in the Linux operating system kernel mode in this embodiment of the application. Figure 3 This is a flowchart illustrating the process of performing version number verification and integrity verification on the received node status data in this embodiment of the application; Figure 4This is a schematic diagram of the process described in this application embodiment for marking a security algorithm in node state data originating from at least two non-directly connected neighbor nodes as a cluster trusted algorithm; Figure 5 This is a flowchart illustrating the process of generating a list of trusted cluster algorithms for querying by the local IPsec process during security association negotiation, as described in this application embodiment. Figure 6 This is a flowchart illustrating another possible implementation of an embodiment of this application; Figure 7 This is a flowchart illustrating another possible implementation of the embodiments of this application; Figure 8 This is a flowchart illustrating another possible implementation of an embodiment of this application; Figure 9 This is a flowchart illustrating the real-time detection of network packet loss rate by network nodes in an embodiment of this application. Figure 10 This is a schematic diagram of the system structure of a network node state data reliability algorithm determination method according to an embodiment of this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0018] In this embodiment, existing technologies for implementing IPsec secure communication in heterogeneous edge gateway clusters typically rely on manual configuration of each gateway or centralized database synchronization of algorithm information. Taking an industrial IoT gateway cluster as an example, the cluster contains hundreds of gateway devices from different batches. These devices run different operating system kernel versions and support different XFRM security algorithm modules, some of which support dynamic loading and unloading. Maintenance personnel need to configure the same encryption or authentication algorithm for each pair of gateways requiring a secure tunnel. This can only be done by logging into each gateway and executing configuration commands to test and confirm available algorithms. The configuration process requires repeatedly trying different algorithm names until the command executes successfully. When the number of gateways reaches a certain scale, the workload of manual configuration increases dramatically, and it becomes impossible to detect dynamic changes in algorithm modules in a timely manner. The recorded algorithm list may deviate from the actual available state, leading to frequent IPsec negotiation failures. Some clusters use a centralized server to collect and synchronize algorithm information from all gateways, posing a single point of failure risk. If the server fails, the algorithm synchronization function of the entire cluster will be paralyzed. Another approach uses simple broadcasting to exchange algorithm lists between gateways, which cannot distinguish between data sent by normal nodes and abnormal nodes. Errors generated by a single node can spread to the entire cluster, affecting the accuracy of the algorithm information.

[0019] In some embodiments, such as Figure 1 As shown, this application provides a method for determining the reliability of network node state data using a reliable algorithm, including: S101, a security state agent running in user space on each network node, obtains available security algorithm information of the local XFRM framework through the Netlink interface in the Linux operating system kernel space, and generates local state data with a globally unique node identifier and a monotonically increasing version number.

[0020] S102, the security status agent uses the Gossip protocol to randomly select a preset number of neighboring nodes according to the synchronization period, sends the local status data to the selected neighboring nodes, and receives node status data from the neighboring nodes.

[0021] S103, perform version number verification and integrity verification on the received node status data. If the verification passes, mark the security algorithm in the node status data from at least two non-directly connected neighbor nodes as a cluster trusted algorithm, and generate a list of cluster trusted algorithms for the local IPsec process to query during security association negotiation.

[0022] Specifically, the security state agent is an independent process running in the user space of the network node. It does not rely on special kernel privileges, and its crash will not affect the normal operation of the operating system kernel. The security state agent is automatically initialized when the node starts, creating a Netlink socket for communication with the kernel, and a network socket for communication with other nodes. The Netlink interface is a native user-space and kernel-space communication mechanism provided by the Linux operating system. It supports asynchronous packet-oriented communication, enabling efficient transmission of structured data. Compared to other communication methods, it does not require frequent system calls, making it suitable for transmitting batch data such as algorithm information. The security state agent sends query requests to the kernel through the Netlink interface to obtain information on all available security algorithms currently supported by the local XFRM framework, avoiding the instability of obtaining algorithm information by parsing system files or executing system commands.

[0023] In this embodiment, a globally unique node identifier is used to uniquely identify each network node across the entire cluster. The identifier uses a 64-bit unsigned integer format, with the first 32 bits identifying the cluster and the last 32 bits identifying the node within the cluster. A unique node identifier is assigned to each node during cluster initialization to ensure that there are no duplicate node identifiers within the cluster. A monotonically increasing version number is used to identify the update sequence of local state data. The version number is initially set to 1. Whenever the available security algorithm state of the local machine changes, including loading or unloading algorithm modules, changes in dependency chain state, etc., the version number is atomically incremented by 1. This atomic operation ensures that version number updates do not conflict in a multi-threaded environment, ensuring that the version number always remains monotonically increasing and does not roll back. The local state data includes information such as node identifier, version number, algorithm type, algorithm name, algorithm availability state, and dependency chain integrity. All information is stored in fixed-length fields for easy transmission and parsing over the network.

[0024] It's important to note that the Gossip protocol is a decentralized distributed communication protocol. It achieves information dissemination throughout the cluster by randomly exchanging data between nodes, eliminating the need for a centralized control node and offering good fault tolerance and scalability. The synchronization period refers to the time interval between two data transmissions from the security state agent to neighboring nodes. The synchronization period needs to strike a balance between real-time data synchronization and system resource consumption. A synchronization period that is too short will lead to excessively frequent communication between nodes, increasing network bandwidth and processor usage; a synchronization period that is too long will increase data synchronization latency, failing to reflect changes in the algorithm state within the cluster in a timely manner. The preset number of neighboring nodes refers to the number of nodes the security state agent selects to send data to in each synchronization period. Neighboring nodes are randomly selected from online nodes within the same cluster. This random selection mechanism ensures that data can be disseminated to all nodes in the cluster through different paths, avoiding data propagation interruptions caused by fixed neighboring nodes going offline.

[0025] Specifically, at the start of each synchronization cycle, the security state agent first obtains a list of currently online nodes in the cluster via a heartbeat mechanism. This heartbeat mechanism is implemented by nodes periodically sending heartbeat packets. Upon receiving a heartbeat packet from another node, the node updates its local list of online nodes. If a node does not receive a heartbeat packet from a node within a preset time, it marks that node as offline. After excluding itself from the list of online nodes, the security state agent randomly selects a preset number of nodes as neighbor nodes for this synchronization, packages all locally stored state data, and sends it to the selected neighbor nodes. Simultaneously, the security state agent also acts as a neighbor node for other nodes, receiving node state data from them. Each received node state data may contain multiple algorithm state entries with different version numbers generated by different nodes.

[0026] In this embodiment, version number verification is used to determine the age of received node status data, preventing older data from overwriting newer data. Integrity verification is used to determine whether node status data has been corrupted during transmission, ensuring data accuracy. The security state agent sequentially performs version number verification and integrity verification on all received node status data. Only data that passes both verifications will proceed to the next processing step; data that fails verification will be discarded directly and will not affect local status data. Multi-source consistency verification is used to determine the trustworthiness of node status data, preventing erroneous or malicious data generated by a single node from being adopted. Non-directly connected neighbor nodes refer to nodes that have not established a direct Gossip communication connection with the current node and need to be forwarded through other intermediate nodes to reach it. When the same status data comes from at least two different non-directly connected neighbor nodes, it indicates that the data has been propagated through multiple independent paths and has a high degree of trustworthiness.

[0027] It's important to note that the cluster trusted algorithm list is a structured list generated by the security state agent based on state data that has passed multi-source consistency verification. This list contains information on trusted security algorithms supported by all nodes within the cluster. The IPsec process is the process within the network node responsible for establishing and managing IPsec security associations. During security association negotiation, the IPsec process needs to know the security algorithms supported by the peer node to select an algorithm supported by both parties for negotiation. After generating the local cluster trusted algorithm list, the security state agent stores the list in a local shared memory area or provides it to the local IPsec process for querying via a local inter-process communication interface. The IPsec process can directly obtain the trusted algorithms supported by the peer node from the list, eliminating the need for trial and error confirmation, thus improving the success rate and efficiency of security association negotiation.

[0028] In some embodiments, such as Figure 2 As shown, the security state agent obtains available security algorithm information for the local XFRM framework through the Netlink interface in the Linux operating system kernel space, including: S201, the security state agent sends a security algorithm query request to the kernel. After receiving the security algorithm query request through the Netlink interface, the kernel enters the RCU (Read-Copy-Update) critical section to obtain the algorithm registration list of the XFRM framework. It traverses each node of the algorithm registration list to verify the registration status and lifecycle validity of the corresponding security algorithm. After obtaining the available security algorithm, it exits the RCU critical section.

[0029] S202, the available security algorithms are classified and counted by category to generate statistical quantity information, and the common attribute information of each category of available security algorithms is extracted and stored in a continuous array structure in order of category to obtain the common attribute array of the algorithms.

[0030] S203, generate response data containing the statistical quantity information and the common attribute array of the algorithm, and return it to the security state agent through the Netlink interface.

[0031] Specifically, the security algorithm query request sent by the security state agent to the kernel uses the standard Netlink message format. The message header includes fields such as message type, message length, and message sequence number, while the message payload contains the specific parameters of the query request. In this application, the query request does not need to carry additional parameters. After receiving the request, the kernel will return all available security algorithm information. The XFRM subsystem in the kernel is responsible for processing the security algorithm query requests received by the Netlink interface. The XFRM subsystem is a core module in the Linux kernel used to implement IPsec security functions and manages all registered security algorithms. After receiving the query request, the kernel first enters the RCU read critical section. The RCU read critical section is an execution area built by the Linux kernel based on the read replication update synchronization mechanism. Within the RCU read critical section, read operations are not blocked by write operations, multiple read operations can be executed simultaneously, and write operations will update data only after all read operations are completed, ensuring that the data obtained by the read operations is consistent and that partial updates do not occur.

[0032] In this embodiment, the algorithm registration list is a doubly linked circular list in the XFRM framework used to store the structures of registered secure algorithms. Each node in the list corresponds to a registered secure algorithm, and the node contains information such as the algorithm's type, name, function pointer, and dependent modules. After the kernel enters the RCU read critical section, it obtains the head pointer of the algorithm registration list and then traverses each node in the list from the head. For each node, the kernel first verifies the registration status of the algorithm, checking whether the registration flag in the algorithm structure is in a registered state, excluding algorithms that have not completed the registration process; then it verifies the validity of the algorithm's lifecycle, checking whether the kernel module corresponding to the algorithm is in a loaded state and has not entered the unregistration process, excluding algorithms that are being unloaded or have been marked for deletion. Only algorithms that pass both the registration status verification and the lifecycle validity verification are marked as available secure algorithms. After the kernel completes the traversal and verification of all nodes, it exits the RCU read critical section. The list of available secure algorithms obtained at this time can accurately reflect the actual algorithm support status of the kernel at the current moment.

[0033] It should be noted that the kernel categorizes available security algorithms according to their functional type, including at least four categories: AEAD (Authenticated Encryption with Associated Data), authentication, encryption, and compression. AEAD algorithms provide both encryption and authentication, authentication algorithms provide data integrity verification, encryption algorithms provide data encryption, and compression algorithms provide data compression. The kernel counts the number of available security algorithms in each category, generating statistical information in 32-bit unsigned integer format, corresponding to the number of algorithms in each of the four categories. Then, the kernel extracts common attribute information from the structure of each available security algorithm. This common attribute information includes the algorithm name, algorithm identifier, parameter format, and dependent module identifier. The algorithm name uses ASCII (American Standard Code for Information Interchange) encoding, the algorithm identifier is a unique integer used within the XFRM framework to identify the algorithm, the parameter format describes the required parameters such as key length and initialization vector length, and the dependent module identifier identifies other kernel modules that the algorithm depends on.

[0034] Specifically, the kernel stores the common attribute information of each type of available security algorithm in a contiguous memory array structure, ordered by algorithm identifier from smallest to largest, resulting in an array of common algorithm attributes. Each algorithm's common attribute information occupies a fixed length of bytes for easy subsequent storage and transmission. The kernel-generated response data uses a fixed structure layout. The first 16 bytes of the response data store statistical quantity information, in the following order: number of AEAD-type algorithms, number of authentication algorithms, number of encryption algorithms, and number of compression algorithms, each occupying 4 bytes. The subsequent part of the response data stores the common attribute arrays of the four types of algorithms in sequence, with each array immediately following the corresponding category's statistical quantity. The kernel encapsulates the response data into a standard Netlink message format, adds message header information, and sends it to the security state broker that initiated the query request via the Netlink interface. Upon receiving the response data, the security state broker parses the data according to the preset structure layout to obtain the statistical quantity information and common attribute information of the available security algorithms on the local machine, which is used to generate local state data.

[0035] In some embodiments, such as Figure 3 As shown, version number verification and integrity verification are performed on the received node status data, including: S301, compare the version number carried by the received node status data with the local version number of the node status data of the corresponding node identifier stored locally, and retain the node status data with a version number higher than the local version number.

[0036] S302, recalculate the integrity check value for the retained node status data, compare it with the integrity check value carried in the node status data, filter out node status data with inconsistent integrity check values, and take the node status data that passes the integrity check as the node status data that has passed the check.

[0037] In this embodiment, the security state agent maintains a version number baseline table locally. This table uses a key-value pair structure, where the key is the node identifier and the value is the latest version number corresponding to that node. Each time the security state agent updates the status data of a node stored locally, it synchronously updates the version number of the corresponding node identifier in the version number baseline table. When the security state agent receives a node status data entry, it first extracts the node identifier and version number of the sending node from the data, and then searches the version number baseline table for the local version number corresponding to that node identifier. If the received version number is significantly higher than the local version number, it indicates that the data is newer than the locally stored data, and the data is retained for subsequent integrity verification. If the received version number is lower than or equal to the local version number, it indicates that the data is old status information, or that the same version of data is already stored locally, and the data is discarded without further processing.

[0038] It's important to note that version number verification uses a strict higher-than rule, rather than a greater-than-equal-than rule. This avoids processing the same version of data repeatedly, reducing unnecessary computational overhead. Furthermore, the strict higher-than rule prevents older data from overwriting newer data, ensuring that the locally stored state data is always up-to-date. For example, if a node's version number is 5 in local storage, receiving data from the same node with version number 5 will discard that data directly, as that version's information is already stored locally. Similarly, receiving data with version number 4 will also discard it, as it's older than the locally stored data. Only data with version number 6 or higher will be retained and processed further.

[0039] Specifically, the integrity check value is a fixed-length checksum generated based on the content of the node state data. This application uses the CRC32 (Cyclic Redundancy Check 32) algorithm to generate the integrity check value. The CRC32 algorithm is fast, resource-efficient, and suitable for use on edge nodes. When a node sends node state data, it calculates the CRC32 checksum based on the data content and appends it to the end of the data packet. After receiving the retained node state data, the security state agent recalculates the CRC32 checksum based on the data content and compares the calculated checksum with the checksum carried in the data packet. If the two checksums match, it means the data has not been corrupted during transmission and is complete; this data is then accepted as valid node state data. If the two checksums do not match, it means errors such as bit flipping or data packet truncation occurred during transmission, and the data is incomplete; this data is then discarded.

[0040] In this embodiment, the CRC32 checksum calculation scope includes all valid fields of the node status data, excluding control fields in the header and trailer of the data packet, ensuring that the checksum accurately reflects the integrity of the data content. When calculating the checksum, the security state agent reads each byte sequentially according to the storage order of the data in the data packet, substitutes them into the CRC32 algorithm for calculation, and obtains the final checksum. Through integrity verification, most invalid data caused by network transmission errors can be filtered out, preventing erroneous data from entering the subsequent multi-source consistency verification process and ensuring the accuracy of local status data.

[0041] In some embodiments, such as Figure 4 As shown, the step of marking the security algorithm in node state data originating from at least two non-directly connected neighbor nodes as a cluster trusted algorithm includes: S401, group the verified node status data according to node identifier and status data content.

[0042] S402, for each group, if the node state data source node set within the group contains at least two non-directly connected neighbor nodes, then the security algorithm corresponding to the group is marked as a cluster trusted algorithm.

[0043] Specifically, the security state agent groups all node status data collected during the current synchronization cycle that has passed version number and integrity checks. The grouping is based on node identifiers and status data content. First, the data is divided into different groups according to node identifiers, with each group corresponding to an original node. Then, within each group corresponding to an original node, the data is further subdivided based on its specific content, with status data containing identical content grouped into the same subgroup. This grouping method aggregates information from different nodes describing the same state of the same original node, facilitating subsequent multi-source consistency checks.

[0044] In this embodiment, the source node refers to a neighboring node that directly sends the node status data to the current security state agent, rather than the original node that generated the status data. When receiving node status data, the security state agent records the source node information for each piece of data, associating the source node identifier with the data content. Non-directly connected neighbor nodes are relative to the current receiving node. The current node maintains a neighbor relationship table, recording nodes that have directly established Gossip communication connections with it (i.e., directly connected neighbor nodes); nodes not in the neighbor relationship table are non-directly connected neighbor nodes. When determining whether a source node is a non-directly connected neighbor node, the security state agent only needs to query its local neighbor relationship table.

[0045] It should be noted that for each subgroup, the security state agent collects the source nodes of all data within that subgroup, forming a source node set. Then, it checks the number of non-directly connected neighbor nodes in the source node set. If the number is greater than or equal to 2, it indicates that the state data corresponding to that subgroup has been propagated to the current node through at least two independent paths, and the data has high reliability. The security algorithm corresponding to this subgroup is then marked as a cluster trusted algorithm. If the number of non-directly connected neighbor nodes in the source node set is less than 2, it indicates that the data has only been propagated through one path, or only comes from directly connected neighbor nodes. The data's reliability is insufficient, and it is not marked as a cluster trusted algorithm for the time being, pending further data collection from more sources during subsequent synchronization cycles for a final determination.

[0046] Specifically, multi-source consensus verification leverages the multi-path propagation characteristic of the Gossip protocol. When data spreads within the cluster, it reaches the same node through different paths. Erroneous or malicious data generated by a single node is difficult to propagate to the same node simultaneously through two or more independent paths, as this would require controlling multiple intermediate nodes, which is quite challenging. Therefore, data propagated through at least two non-directly connected neighbor nodes can largely eliminate the impact of single-node errors or malicious behavior, ensuring the accuracy of the cluster's trusted algorithm. Compared to traditional distributed consensus mechanisms, multi-source consensus verification does not require full-node voting or complex state machine management, resulting in extremely low resource consumption, making it suitable for use in large-scale clusters composed of edge nodes.

[0047] In some embodiments, such as Figure 5 As shown, a list of trusted cluster algorithms is generated for the local IPsec process to query during security association negotiation, including: S501 reads all trusted algorithms in the cluster, sorts them according to algorithm type, and generates a list of trusted algorithms in the cluster.

[0048] S502, the list of trusted algorithms for the cluster is stored in the local storage area maintained by the security status agent, and is available for querying by the local IPsec process through the local interface.

[0049] In this embodiment, the security state agent reads all entries marked as cluster trusted algorithms and categorizes them according to their functional type. The categorization method is consistent with that in the kernel, dividing them into four categories: AEAD, authentication, encryption, and compression. Within each category, the algorithms are sorted in ascending order of their algorithm identifiers, or alternatively, based on usage frequency, stability, or other indicators. The sorting method can be configured according to actual needs. After sorting, a structured list of cluster trusted algorithms is generated. Each entry in the list contains information such as node identifier, algorithm type, algorithm name, algorithm identifier, parameter format, and version number. All information is stored in fixed-length fields for easy parsing by the IPsec process.

[0050] It's important to note that the cluster's trusted algorithm list is stored in a local storage area maintained by the security state agent. This local storage area can be a contiguous block of memory or a file on the local disk. Storing it in memory offers fast read speeds, making it suitable for scenarios with frequent queries; storing it on disk ensures data is not lost due to node restarts, making it suitable for scenarios requiring persistent storage. The security state agent periodically synchronizes the cluster's trusted algorithm list from memory to disk to prevent data loss due to abnormal node restarts.

[0051] Specifically, the security state agent provides a local interface for the local IPsec process to query the list of trusted algorithms in the cluster. This local interface can employ various inter-process communication methods, such as Unix domain sockets, shared memory, and pipes. Unix domain sockets are used for inter-process communication on the same host, offering high communication efficiency and supporting both connection-oriented and connectionless communication methods. Shared memory is the fastest inter-process communication method, allowing multiple processes to directly access the same memory area without data copying. Pipes are a half-duplex communication method suitable for unidirectional data transmission. In this application, a suitable local interface can be selected based on the actual situation. The IPsec process sends a query request to the security state agent through the local interface, and upon receiving the request, the security state agent returns the list of trusted algorithms in the cluster to the IPsec process.

[0052] In this embodiment, when performing security association negotiation, the IPsec process first queries the cluster trusted algorithm list from the security state proxy through a local interface. Then, it filters the algorithms supported by the peer node from the list and selects a suitable algorithm for negotiation. Since the algorithms in the cluster trusted algorithm list are all trusted algorithms that have undergone multi-source consistency verification, the IPsec process no longer needs to confirm whether the peer node supports the algorithm through trial and error, which improves the success rate of security association negotiation and reduces negotiation time. Simultaneously, the cluster trusted algorithm list is updated in real time as the algorithm status within the cluster changes, ensuring that the IPsec process obtains the latest algorithm information with each query, guaranteeing that the algorithm used for negotiation is currently available.

[0053] In some embodiments, such as Figure 6 As shown, it also includes: S601, the edge node sends a secure algorithm state retrieval request to its directly connected neighbor node, carrying filtering rules that are used to filter the target algorithm state data.

[0054] S602, the directly connected neighbor node receives the security algorithm status retrieval request, reads the filtering rules and the locally stored cluster status view, extracts the node status data of the security algorithm that matches the filtering rules, and returns it to the edge node.

[0055] S603, the edge node generates an event subscription rule and registers the event subscription rule with the directly connected neighbor node. The event subscription rule is a constraint condition used to filter events to be pushed.

[0056] S604, the directly connected neighbor node monitors the change events in the local cluster status view, and pushes the corresponding event data to the edge node when the change event matches the event subscription rule.

[0057] Specifically, edge nodes refer to terminal devices within a cluster with limited computing power and bandwidth resources. These devices typically use low-power processors, have limited memory and storage space, and limited network bandwidth, making them unable to run a complete security state proxy and Gossip protocol stack. Edge nodes do not participate in the Gossip synchronization process within the cluster, nor do they maintain a complete view of the cluster state. Instead, they obtain the necessary algorithm state data through directly connected neighbor nodes. Directly connected neighbor nodes are standard network nodes that have a direct physical or logical link connection with the edge nodes and run a complete security state proxy. Directly connected neighbor nodes maintain a complete view of the cluster state and can provide algorithm state query and event push services to edge nodes.

[0058] In this embodiment, when an edge node needs to obtain security algorithm status data, it generates a security algorithm status retrieval request, which carries filtering rules. Filtering rules are constraints used to filter target algorithm status data; these constraints may include algorithm type, algorithm identifier, node identifier, version number, etc. For example, the edge node can set the filtering rule to only retrieve algorithm status data of type AEAD, or only retrieve algorithm status data of a specific node. The edge node sends the retrieval request to its directly connected neighbor node. Upon receiving the request, the directly connected neighbor node parses the filtering rules, then reads the cluster status view stored locally, extracts all algorithm status data that matches the filtering rules, packages the data, and returns it to the edge node. After receiving the data, the edge node can directly use this data for IPsec security association negotiation without additional verification.

[0059] It's important to note that edge nodes can also register event subscription rules with their directly connected neighbors to receive real-time updates on algorithm state change events. Event subscription rules are constraints used to filter events to be pushed, and these constraints can include event type, algorithm type, and node identifier. Event types include algorithm registration events, algorithm deregistration events, and algorithm state change events. For example, edge nodes can subscribe to state change events for Chinese cryptographic algorithms. When the state of a Chinese cryptographic algorithm changes within the cluster, the directly connected neighbor will promptly push an event notification to the edge node. After generating the event subscription rules, the edge node sends the rules to its directly connected neighbor, which then stores the rules in its local subscription rule list.

[0060] Specifically, directly connected neighbor nodes continuously monitor change events in their local cluster state view. Whenever the cluster state view changes, a corresponding change event is generated. Then, the directly connected neighbor nodes match these change events with all locally stored event subscription rules. If a change event meets the constraints of a subscription rule, the event data is pushed to the edge nodes that have registered that rule. The event data includes information such as event type, algorithm identifier, node identifier, and change time. After receiving the event data, the edge nodes can adjust their IPsec configurations accordingly. By combining pull and subscription methods, edge nodes can obtain the necessary algorithm state data with extremely low resource overhead while ensuring data real-time performance.

[0061] In some embodiments, such as Figure 7 As shown, it also includes: S701, the cluster where the network node is located is divided into multiple regional clusters according to the region. The regional cluster is an autonomous cluster unit composed of network nodes within the same region.

[0062] S702, network nodes in each regional cluster synchronize node status data through the Gossip protocol, perform version number verification and integrity verification on the received node status data, and mark the security algorithms in the node status data originating from at least two non-directly connected neighbor nodes in the verified node status data as cluster trusted algorithms.

[0063] S703: Each regional cluster is configured with a preset number of gateway nodes. Gateway nodes in different regional clusters synchronize the node status data corresponding to the security algorithms marked as cluster trusted algorithms within their respective regions. The gateway node in the receiving region distributes the synchronized node status data as incremental node status data to all nodes within its regional cluster.

[0064] In this embodiment, when the cluster scale expands to cross-regional deployment, the entire cluster is divided into multiple regional clusters based on the network latency between nodes. Nodes with network latency below a preset threshold are typically grouped into the same regional cluster. Nodes within the same region have low network latency, sufficient bandwidth, and low communication costs; nodes in different regions have high network latency and high bandwidth costs. By dividing the cluster into regional clusters, data synchronization can be confined to the region, reducing cross-regional network traffic, lowering bandwidth costs, and improving data synchronization speed. Each regional cluster acts as an independent autonomous cluster unit, with nodes within it using the Gossip protocol to perform state synchronization and multi-source consistency verification, maintaining a cluster state view for their respective region.

[0065] It should be noted that each regional cluster has a preset number of gateway nodes. These gateway nodes are selected from nodes with strong computing power and high network stability within the region. Each regional cluster has 2 to 3 gateway nodes, employing a primary / backup mode. When the primary gateway node fails, the backup gateway node can automatically take over, ensuring the reliability of cross-region synchronization. In addition to possessing all the functions of ordinary nodes, gateway nodes are also responsible for cross-region state synchronization. Ordinary nodes do not participate in cross-region communication; all cross-region data transmission is conducted through the gateway nodes.

[0066] Specifically, dedicated cross-regional synchronization links are established between gateway nodes in different regional clusters. These links employ encrypted transmission to ensure data security. Gateway nodes periodically exchange status data within their respective regions. Synchronized data is limited to node status data corresponding to secure algorithms that have passed multi-source consistency verification and are marked as trusted cluster algorithms within that region. Temporary data that fails verification is not synchronized to other regions. This reduces the amount of data transmitted across regions while ensuring the reliability of the transmitted data. Upon receiving the cross-regional synchronized data, the gateway node in the receiving region first performs version number and integrity verification. After passing these verifications, the data is injected as incremental node status data into the Gossip synchronization stream within its region. The data is then distributed to all ordinary nodes within the region via the Gossip protocol within that region. When ordinary nodes receive the cross-regional data forwarded by the gateway node, they do not need to perform multi-source consistency verification again; they only need to perform version number verification. Once the version number is confirmed to be higher than the local version, the local cluster status view is updated.

[0067] In some embodiments, such as Figure 8 As shown, it also includes: S801, when a network node loses connection, it persists an incremental node status change log with a version number locally. After the network node reconnects, it sends the latest version number baseline to neighboring nodes. The version number baseline is the version number corresponding to the latest node status data stored by this node.

[0068] S802, the neighboring node compares the version number baseline with the locally stored node status data version number, and returns incremental node status data with a version number higher than the version number baseline to the reconnected network node.

[0069] S803, the network node sends a local version number baseline to neighboring nodes at a fixed period, and when a neighboring node holds a higher version of node status data, it pushes the corresponding incremental node status data to the network node.

[0070] In this embodiment, network nodes may experience network outages due to network failures, power interruptions, or other reasons. During these outages, nodes cannot receive state updates from other nodes, but their local algorithm state may still change, such as the loading or unloading of algorithm modules. To prevent the loss of local changes during outages, the security state agent records each change in local algorithm state as an incremental node state change log after detecting a network interruption. This log is persistently stored on a local non-volatile storage medium, such as flash memory or a hard disk. Each incremental state change log entry includes a timestamp of the change, node identifier, version number, change type, and algorithm identifier. The logs are managed using a circular overwrite method; when storage space is full, the oldest log entry is overwritten, while the latest change record is retained.

[0071] It's important to note that when a network node detects that network connectivity has been restored, it first reads the incremental state change log stored locally. It then applies the local changes made during the network outage to its local state data, updating its local version number baseline. The version number baseline is a collection of the latest version numbers of all known nodes stored on this node, with each node identifier corresponding to a specific latest version number. Next, the node sends its latest local version number baseline to multiple neighboring nodes. Upon receiving the baseline, each neighboring node compares it to its locally stored version number baseline, selecting all incremental node state data with version numbers higher than the reconnected node's baseline. This data is then packaged and returned to the reconnected node. Upon receiving the incremental data, the reconnected node performs version number and integrity checks. If the checks pass, it updates its local cluster state view, completing the state recovery after the network outage.

[0072] Specifically, during normal operation, network nodes send their local version number baselines to neighboring nodes at fixed intervals, consistent with the Gossip synchronization cycle. Upon receiving the version number baseline, a neighboring node compares it to its own. If it finds that it holds state data of a node with a higher version, it proactively pushes the corresponding incremental node state data to the node that sent the version number baseline. This mechanism can promptly detect version differences caused by network packet loss, synchronization omissions, etc., ensuring eventual consistency of state data between nodes. Compared to traditional acknowledgment retransmission mechanisms, this lazy retransmission mechanism based on version number baselines requires no waiting for acknowledgment messages or setting timeouts. It is simple in logic, consumes few resources, and is suitable for use in weak network environments.

[0073] In some embodiments, such as Figure 9 As shown, it also includes: S901 enables network nodes to monitor network packet loss rate in real time.

[0074] S902, when the network packet loss rate exceeds the preset network packet loss rate threshold, the fixed period is extended and the data window for a single synchronization is increased.

[0075] In this embodiment, network nodes monitor the packet loss rate of the current network link in real time. The packet loss rate is calculated by counting the number of data packets sent and the number of acknowledgment data packets received. After sending a data packet, the node records the sending time and the sequence number of the data packet. After receiving acknowledgment data packets from neighboring nodes, it determines which data packets have been successfully received and which data packets have been lost based on the sequence number. The node periodically counts the number of lost packets and the total number of packets sent over a period of time to calculate the current network packet loss rate. The pre-set network packet loss rate threshold is an empirical value, set according to the actual network environment and application requirements. When the packet loss rate exceeds the threshold, it indicates that the network is in a weak state, and the synchronization parameters need to be adjusted to adapt to the network environment.

[0076] It's important to note that when the network packet loss rate exceeds a critical threshold, the node automatically extends the fixed Gossip synchronization period and increases the data window for each synchronization. Extending the synchronization period reduces the number of data packets sent, lowering the probability of network congestion; increasing the data window for each synchronization increases the number of incremental data packets sent each time, reducing the number of small packet transmissions and improving data transmission efficiency. For example, the default synchronization period is 100 milliseconds, and the data window for each synchronization is 10 incremental data packets. When the packet loss rate exceeds the critical threshold, the synchronization period is extended to 200 milliseconds, and the data window for each synchronization increases to 20 incremental data packets. When the network packet loss rate falls back below the critical threshold, the node automatically restores the default synchronization parameters to ensure real-time data synchronization.

[0077] Specifically, the synchronization period and data window adjustment range can be dynamically adjusted based on the packet loss rate. The higher the packet loss rate, the greater the extension of the synchronization period and the larger the data window. This adaptive adjustment mechanism can dynamically optimize synchronization parameters according to changes in the network environment, ensuring real-time data synchronization when network conditions are good and ensuring data transmission reliability when network conditions are poor, thus improving the adaptability of the solution to different network environments.

[0078] For example, in an industrial IoT edge cluster consisting of 100 network nodes, the nodes are distributed across two different regions, with 50 nodes in each region. Network latency between nodes within a region is less than 50 milliseconds, while network latency between nodes across regions is approximately 200 milliseconds. Each node is equipped with a low-power processor, runs a Linux operating system, and supports the XFRM framework and IPsec security features. The cluster is divided into two regional clusters, each with two gateway nodes responsible for cross-regional state synchronization. A secure state broker runs on all standard nodes, and edge nodes obtain algorithm state data through direct connections to neighboring nodes.

[0079] After the cluster starts, the security state agent on each node initializes, creates Netlink sockets and network sockets, and sends a security algorithm query request to the kernel. Upon receiving the request, the kernel enters the RCU read critical section, traverses the algorithm registration list, verifies the registration status and lifecycle validity of each algorithm, and exits the RCU read critical section after obtaining available security algorithms. The kernel categorizes and counts available algorithms, extracts common attribute information to generate an array of common algorithm attributes, and encapsulates the statistical count information and the common attribute array into response data, which is returned to the security state agent via the Netlink interface. The security state agent parses the response data, generates local state data, and assigns a globally unique node identifier and an initial version number of 1 to the data.

[0080] Each node's security state agent randomly selects 3 to 5 online neighbor nodes in the same region and sends local state data every 100 milliseconds. Upon receiving the state data from its neighbors, the node first performs a version number check, comparing the received data's version number with its local version number baseline, retaining data with a version number higher than its local version. Then, it performs an integrity check on the retained data, recalculating the CRC32 checksum and comparing it with the checksum carried in the data packet, filtering out data that does not match. Data that passes the checksum check enters the multi-source consistency verification process. The node groups the data by node identifier and content, checks the source node set of each group, and if it contains at least two non-directly connected neighbor nodes, marks the corresponding algorithm as a cluster trusted algorithm. The node reads all cluster trusted algorithms, sorts them by type to generate a cluster trusted algorithm list, stores it locally, and makes it available for querying by the local IPsec process via Unix domain sockets.

[0081] Gateway nodes in each region establish cross-regional synchronization links to periodically exchange status data corresponding to trusted algorithms within their respective regions. Upon receiving data, the gateway node in the receiving region performs version number and integrity checks. If the checks pass, the data is injected into the region's Gossip synchronization stream and distributed to all nodes within the region. When an edge node needs to establish an IPsec tunnel, it sends a pull request with filtering rules to its directly connected neighbor nodes to obtain the required algorithm status data. Simultaneously, it registers event subscription rules with its directly connected neighbor nodes to receive relevant algorithm status change events.

[0082] When a node experiences a network outage, the security state agent records the local algorithm state changes during the outage as incremental logs and persists them locally. After the node reconnects, it sends a local version number baseline to neighboring nodes. Neighboring nodes return incremental data with version numbers higher than the baseline, and the node completes state recovery. The node monitors the network packet loss rate in real time. When the packet loss rate exceeds a critical value, it automatically extends the synchronization period and increases the data window to adapt to weak network environments.

[0083] During cluster operation, the IPsec process queries the cluster's trusted algorithm list through a local interface during security association negotiation, selecting algorithms supported by both parties for negotiation, thus improving the negotiation success rate. The entire cluster does not require a centralized management node; nodes achieve trusted synchronization of algorithm states through peer-to-peer interaction, adapting to the characteristics of limited resources and unstable network environments at edge nodes.

[0084] This application further provides a system for determining the reliability of network node state data using a reliable algorithm, such as... Figure 10 As shown, it includes multiple network nodes; The data acquisition module 1001 is used to obtain available security algorithm information of the local XFRM framework through the Netlink interface in the kernel space of the Linux operating system on each network node, and generate local state data with a globally unique node identifier and a monotonically increasing version number.

[0085] The security state proxy module 1002 is used to randomly select a preset number of neighbor nodes according to the synchronization period using the Gossip protocol, send the local state data to the selected neighbor nodes, and receive node state data from the neighbor nodes.

[0086] The verification module 1003 is used to perform version number verification and integrity verification on the received node status data. If the verification passes, the security algorithm in the node status data originating from at least two non-directly connected neighbor nodes is marked as a cluster trusted algorithm, and a list of cluster trusted algorithms is generated for the local IPsec process to query during security association negotiation.

[0087] Based on the same principle, the implementation method of the network node state data reliable algorithm determination system of this application can refer to the implementation method of the above method, and will not be described in detail here.

[0088] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for determining the reliability of network node state data, characterized in that, include: The security state agent running in user space on each network node obtains the available security algorithm information of the local XFRM framework through the Netlink interface in the Linux operating system kernel space, and generates local state data with a globally unique node identifier and a monotonically increasing version number. The security state agent uses the Gossip protocol to randomly select a preset number of neighbor nodes according to the synchronization period, sends the local state data to the selected neighbor nodes, and receives node state data from the neighbor nodes. The received node status data is subjected to version number verification and integrity verification. If the verification passes, the security algorithms in the node status data originating from at least two non-directly connected neighbor nodes are marked as cluster trusted algorithms, and a list of cluster trusted algorithms is generated for the local IPsec process to query during security association negotiation.

2. The method according to claim 1, characterized in that, The security state agent obtains available security algorithm information for the local XFRM framework through the Netlink interface in the Linux operating system kernel mode, including: The security status agent sends a security algorithm query request to the kernel. After receiving the security algorithm query request through the Netlink interface, the kernel enters the RCU read critical section to obtain the algorithm registration list of the XFRM framework, traverses each node of the algorithm registration list to verify the registration status and lifecycle validity of the corresponding security algorithm, and exits the RCU read critical section after obtaining the available security algorithm. The available security algorithms are classified and counted by category to generate statistical quantity information. The common attribute information of each category of available security algorithms is extracted and stored in a continuous array structure in category order to obtain the common attribute array of the algorithms. Response data containing the statistical quantity information and the common attribute array of the algorithm is generated and returned to the security state agent through the Netlink interface.

3. The method according to claim 1, characterized in that, Perform version number verification and integrity verification on the received node status data, including: Compare the version number carried in the received node status data with the local version number of the corresponding node status data stored locally, and retain the node status data with a version number higher than the local version number. The integrity check value is recalculated for the retained node status data and compared with the integrity check value carried in the node status data. Node status data with inconsistent integrity check values ​​are filtered out, and node status data that passes the integrity check is taken as node status data that has passed the check.

4. The method according to claim 1 or 3, characterized in that, The step of marking the security algorithm in node state data originating from at least two non-directly connected neighbor nodes as a cluster trusted algorithm includes: The verified node status data will be grouped according to the node identifier and status data content; For each group, if the node state data source node set within the group contains at least two non-directly connected neighbor nodes, then the security algorithm corresponding to the group is marked as a cluster trusted algorithm.

5. The method according to claim 1, characterized in that, Generate a list of trusted cluster algorithms that can be queried by the local IPsec process during security association negotiation, including: Read all trusted algorithms in the cluster, classify and sort them according to algorithm type, and generate a list of trusted algorithms in the cluster; The list of trusted algorithms for the cluster is stored in the local storage area maintained by the security state agent and can be queried by the local IPsec process through a local interface.

6. The method according to claim 1, characterized in that, Also includes: Edge nodes send a secure algorithm state retrieval request to their directly connected neighbor nodes, carrying filtering rules that are used to filter target algorithm state data. The directly connected neighbor node receives the security algorithm status retrieval request, reads the filtering rules and the locally stored cluster status view, extracts the node status data of the security algorithm that matches the filtering rules, and returns it to the edge node. The edge node generates an event subscription rule and registers the event subscription rule with the directly connected neighbor node. The event subscription rule is a constraint used to filter events to be pushed. The directly connected neighbor node monitors change events in the local cluster status view, and pushes the corresponding event data to the edge node when the change event matches the event subscription rule.

7. The method according to claim 1, characterized in that, Also includes: The cluster where the network node is located is divided into multiple regional clusters according to the region. The regional cluster is an autonomous cluster unit composed of network nodes within the same region. Network nodes within each regional cluster synchronize node status data through the Gossip protocol. Version number verification and integrity verification are performed on the received node status data. The security algorithms in the node status data originating from at least two non-directly connected neighbor nodes in the verified node status data are marked as cluster trusted algorithms. Each regional cluster is configured with a preset number of gateway nodes. Gateway nodes in different regional clusters synchronize the node status data corresponding to the security algorithms that have been marked as trusted algorithms in their respective regions. The gateway node in the receiving region distributes the synchronized node status data as incremental node status data to all nodes in its regional cluster.

8. The method according to claim 1, characterized in that, Also includes: When a network node loses connection, it persists an incremental node status change log with a version number locally. After the network node reconnects, it sends the latest version number baseline to neighboring nodes. The version number baseline is the version number corresponding to the latest node status data stored by this node. The neighboring node compares the version number baseline with the locally stored node status data version number, and returns incremental node status data with a version number higher than the version number baseline to the reconnected network node; The network node sends its local version number baseline to its neighboring nodes at fixed intervals, and the neighboring node pushes the corresponding incremental node status data to the network node when it holds a higher version of node status data.

9. The method according to claim 8, characterized in that, Also includes: Network nodes monitor network packet loss rate in real time; When the network packet loss rate exceeds the preset network packet loss rate threshold, the fixed period is extended and the data window for a single synchronization is increased.

10. A system for determining the reliability of network node state data using a reliable algorithm, characterized in that, Includes multiple network nodes; The data acquisition module is used to obtain available security algorithm information of the local XFRM framework through the Netlink interface in the kernel space of the Linux operating system on each network node, and generate local state data with a globally unique node identifier and a monotonically increasing version number. The security status agent module is used to randomly select a preset number of neighbor nodes according to the synchronization period using the Gossip protocol, send the local status data to the selected neighbor nodes, and receive node status data from the neighbor nodes. The verification module is used to perform version number verification and integrity verification on the received node status data. If the verification passes, the security algorithm in the node status data originating from at least two non-directly connected neighbor nodes is marked as a cluster trusted algorithm, and a list of cluster trusted algorithms is generated for the local IPsec process to query during security association negotiation.

Images