Path verification method and system based on bloom filter storage link proof

Abstract

The invention belongs to the technical field of network communication, and discloses a path verification method and system based on Bloom filter storage link proof, and the method comprises the steps: 1, calculating an optimal Bloom filter parameter based on a source node; step 2, based on the optimal Bloom filter parameter, establishing a session between a source node and a destination node; 3, based on the established session between the source node and the destination node, designing a path verification header of an initialized data packet of the source node and forwarding the data packet from an output interface; step 4, the intermediate node performs data packet verification and path verification; and step 5, based on the forwarded data packet, the destination node performs path verification. According to the method, the detour attack is defended through storage link type proof instead of node type proof, proof storage is carried out by using the Bloom filter, so that the size of a data packet header is remarkably reduced, and the expandability of a protocol is enhanced. And meanwhile, different transmission modes such as unicast, multicast, multipath and the like can be adapted.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of network communication, and relates to a path verification method in an open Internet scene, in particular to a path verification method and system based on Bloom filter storage link proof. BACKGROUND

[0002] The current Internet is built based on TCP / IP architecture, which only provides simple transmission services based on IP addresses. The end host specifies the destination IP address in the IP packet to start data transmission. However, the end host and even the network operator cannot control the forwarding path of the packet, which provides the possibility for many malicious behaviors, such as distributed denial of service attacks.

[0003] Path verification technology ensures the security of packet forwarding through two core functions: path enforcement and path verification. Path enforcement uses the packet header to specify the path that the source hopes its packet to follow. Path verification gives the destination node and intermediate nodes the ability to verify whether the packet strictly follows the path specified by the source. However, in the actual Internet environment, the existence of malicious nodes may cause the packet to deviate from the predetermined path, thereby causing security problems. To address this challenge, path verification needs the source node and intermediate nodes to embed cryptographic proofs and let the intermediate nodes perform verification to ensure security.

[0004] Current research on path verification mainly focuses on how to reduce the overhead while not losing the ability of path verification of the destination node and intermediate nodes. There are three types of overhead: computation overhead, forwarding overhead, and header overhead. Computation overhead comes from the proof generation process of the source node, and the cryptographic operations (such as message authentication code or signature) required in the verification process of the intermediate nodes and the destination node. Forwarding overhead comes from the additional state that the intermediate node may need to maintain and the complex header processing. Header overhead comes from the packet verification header that stores a large number of proofs.

[0005] As of now, there have been many well-known path verification proposals, which have their own unique design focus in different performance dimensions. However, most of them follow a common design guideline "generate node proofs and store them using in-order lists in the packet". However, we found that this guideline is the root of some bottlenecks, such as not being able to solve the detour attack, having a large path verification header, and having high complexity in adapting to multi-path and multicast. SUMMARY

[0006] To solve the problems in the prior art, the application provides a path verification method and system based on a Bloom filter storage link proof, which first stores link proof instead of node proof to prevent a bypass attack, and secondly uses a Bloom filter to store the proof, thereby significantly reducing the size of a data packet header and enhancing the scalability of a protocol.

[0007] To achieve the above object, the application provides the following scheme.

[0008] A path verification method based on a Bloom filter storage link proof, which comprises the following steps:

[0009] Step 1: calculating optimal Bloom filter parameters based on a source node;

[0010] Step 2: establishing a session of the source node and a destination node based on the optimal Bloom filter parameters;

[0011] Step 3: designing a path verification header of a data packet of the source node and forwarding the data packet from an outgoing interface based on the established session of the source node and the destination node;

[0012] Step 4: performing data packet verification and path verification by an intermediate node;

[0013] Step 5: performing path verification by the destination node based on the forwarded data packet.

[0014] Preferably, the method for calculating optimal Bloom filter parameters based on the source node comprises the following steps:

[0015]

[0016]

[0017] wherein M is the Bloom filter size, K is the number of hash functions, p is the false positive probability of the Bloom filter, and N is the total number of hops from the source node to the destination node.

[0018] Preferably, the method for establishing the session of the source node and the destination node based on the optimal Bloom filter parameters comprises the following steps:

[0019] The session establishment is performed based on an improved DRKey protocol, which comprises three stages: the source node initializes a session establishment data packet, the intermediate node generates a key and forwards it to a downstream node, and the destination node verifies and returns the key sequence.

[0020] Preferably, the path verification header comprises two parts: packet metadata and packet security information, wherein the packet metadata is composed of three fields of HASH, SessionID and TS, and the packet security information is composed of three fields of PVF, PPF and DestPVF;

[0021] The method for designing the path verification header of the data packet by the source node and forwarding the data packet from the out interface comprises the steps of:

[0022] Step 301, initializing the packet metadata:

[0023] The source node sets the SessionID field by using the Session ID determined in the session establishment stage, sets the TS field by obtaining the current timestamp, and then calculates the static field hash value:

[0024] HASH = H (Payload||SessionID||TS) ;

[0025] Wherein, H represents a hash function, Payload represents the payload of the packet, and after the calculation is completed, the obtained hash value is filled into the HASH field of the data packet;

[0026] Step 302, initializing the packet security information:

[0027] The source node first obtains the end-to-end path established in the session establishment stage, which is represented by a series of link labels {L1, L2,..., Ln}, and then constructs a Bloom filter according to the predetermined Bloom filter parameters. The bit array is initialized to all 0, and then all the links except the last link in the path, i.e. {L1, L2,..., Ln-1}, are traversed. The path verification field PVF of each link is calculated: N N-1 i

[0028]

[0029] Wherein, K i is the session key of the i-th intermediate node R i , || represents string splicing, and MAC Key (·) represents the message authentication code calculated by using the key Key;

[0030] Each calculated PVF i is inserted into the Bloom filter, and the bit array in the final Bloom filter is stored in the PPF field of the data packet. The initial value of the PVF field is set to 0. For the DestPVF field, the calculation follows the formula:

[0031] ​​​

[0032] wherein, K D represents the session key of the destination node;

[0033] Step 303, forwarding of the data packet:

[0034] After the initialization of the data packet is completed, the source node immediately forwards the data packet out through the out interface corresponding to the first link L1.

[0035] Preferably, the method for the intermediate node to verify the data packet comprises integrity verification, timestamp verification, and PPF field legality verification.

[0036] The method for the intermediate node to verify the path comprises:

[0037] obtaining the link identifier LiD in corresponding to the in interface, and extracting the PVF and HASH fields from the data packet;

[0038] calculating the expected PVF value PVF Expected , and the calculation formula is:

[0039]

[0040] finding the K hash functions corresponding to the SessionID in the packet, and taking the PPF field in the packet as a bit array, thereby constructing a Bloom filter;

[0041] judging whether the PVF Expected is a member of the Bloom filter: if the PVF Expected is judged to be a member in the Bloom filter, the path verification is passed;

[0042] After the path verification is passed, the node will find the correct out interface by using the SessionID in the packet to look up the SessionID-to-out interface mapping recorded during session establishment, and the data packet will be forwarded through the out interface.

[0043] Preferably, the method for the destination node to verify the path comprises:

[0044] obtaining the link identifier LiD in corresponding to the in interface, and extracting the PVF and HASH fields from the data packet;

[0045] calculating the expected DestPVF value DestPVF Expected , and the calculation formula is:

[0046]

[0047] extracting the DestPVF field stored in the data packet and comparing with the calculated DestPVF Expected An equality comparison is made, and if equal, the path verification is passed, and the data packet is submitted to the upper layer, i.e., the transport layer, for processing.

[0048] The application also provides a path verification system based on Bloom filter storage of link proof, which is used to implement the foregoing method, and comprises a calculation module, an establishment module, a design module, an intermediate node verification module and a destination node verification module.

[0049] The calculation module is used to calculate optimal Bloom filter parameters based on a source node.

[0050] The establishment module is used to establish a session of the source node and the destination node based on the optimal Bloom filter parameters.

[0051] The design module is used to design a path verification header of a source node initialization data packet and forward the data packet from an outgoing interface based on the established session of the source node and the destination node.

[0052] The intermediate node verification module is used to perform data packet verification and path verification by an intermediate node.

[0053] The destination node verification module is used to perform path verification by a destination node based on the forwarded data packet.

[0054] Compared with the prior art, the application has the following beneficial effects:

[0055] (1) The path verification based on link proof designed in the application can effectively resist the detour attack initiated by a malicious node.

[0056] (2) The proof storage based on Bloom filter designed in the application significantly reduces the size of the path verification data packet header, thereby improving the scalability of the mechanism. In addition, the one-way property of the Bloom filter makes it difficult for an attacker to restore the original link proof from the Bloom filter, thereby increasing the difficulty of brute force cracking of the session key and enhancing the security of the mechanism.

[0057] (3) The application uses in-packet Bloom filter to store the link proof, so that the method can be flexibly adapted to various network transmission modes such as unicast, multicast and multi-path. BRIEF DESCRIPTION OF DRAWINGS

[0058] In order to more clearly illustrate the technical solutions of the application, the following briefly introduces the drawings needed in the embodiments. Obviously, the drawings described in the following embodiments are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0059] Figure 1 is a flow chart of a path verification method based on link proof in a Bloom filter in an embodiment of the present application;

[0060] Figure 2 is a schematic diagram of a session establishment process under a node sequence path representation and a link sequence path representation in an embodiment of the present application;

[0061] Figure 3 is a schematic diagram of a data packet format in an embodiment of the present application;

[0062] Figure 4 is a graph of experimental results of data packet processing efficiency by a container-based simulation platform in an embodiment of the present application;

[0063] Figure 5 is a graph of experimental results of data transmission efficiency by a container-based simulation platform in an embodiment of the present application. DETAILED DESCRIPTION

[0064] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.

[0065] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application will be further described in detail below with reference to the drawings and specific embodiments.

[0066] Embodiment One

[0067] The present application discloses a path verification method based on Bloom filter storage link proof. The path verification is achieved by embedding encrypted proof in source and intermediate nodes, so that downstream nodes can verify whether upstream nodes correctly forward data packets according to the path specified by the source. Most existing path verification methods follow a common design philosophy, that is, the source stores node proofs in the form of an ordered list in the data packet. However, the path verification protocol under this design philosophy has problems such as difficulty in preventing detour attacks, significant header overhead, difficulty in adapting to multicast / multi-path scenarios, etc. In the open Internet scenario, when some network nodes are malicious nodes, how to design a secure, efficient and scalable path verification protocol to ensure secure, reliable and efficient forwarding becomes a technical problem to be solved by the present application.

[0068] The application aims to provide a path verification method using a Bloom filter to store link proofs. The method effectively resists the detour attack initiated by a malicious node in the network by introducing a link identifier into the proof calculation. Meanwhile, the Bloom filter is used to store the link proof, which significantly reduces the size of the packet header and enhances the scalability of the protocol. In addition, due to the one-way property of the Bloom filter, it is difficult for an attacker to restore the original link proof from the Bloom filter, thereby increasing the difficulty of brute force cracking of the session key and improving the security of the mechanism. The combination of the link proof and the Bloom filter enables the method to flexibly support various network transmission modes such as unicast, multicast and multi-path.

[0069] In the application, there are N hops from the source node to the destination node, the size of the Bloom filter in the data packet is M bits, the number of hash functions is K, and the source node or the network specifies the false positive probability P of the Bloom filter.

[0070] Referring to Figure 1 As shown in the figure, the path verification method based on the Bloom filter to store the link proof comprises the following steps:

[0071] Step 1: The source node calculates the optimal Bloom filter parameters;

[0072] The source can determine the false positive rate of a Bloom filter. According to the false positive rate, we can calculate the size M (bit) of a Bloom filter and the number K of hash functions according to the following formula.

[0073]

[0074] This parameter optimization method can effectively reduce the storage overhead while ensuring the security of path verification: on the one hand, by reasonably setting the Bloom filter parameters, the probability of a malicious node forging a Bloom filter to store the link proof and bypassing the path verification can be significantly reduced; on the other hand, the Bloom filter storage space is minimized through parameter optimization, thereby improving the transmission efficiency of the path verification method.

[0075] Step 2: The source node and the destination node establish a session;

[0076] In the application, the establishment of a session is required before the actual data transmission stage. The application establishes a session based on an improved DRKey protocol. The improved DRKey protocol mainly includes three stages: the source node initializes the session establishment packet, the intermediate node generates a key and forwards it to the downstream node, and the destination node verifies and returns the key sequence.

[0077] In the packet initialization phase of session establishment, the standard DRKey protocol stores in the packet the session ID (used to uniquely identify a session σ), the end-to-end path PATH represented by a node sequence σ , the timestamp T σ , the public key PublicKey of the session σ , and the encrypted session private key (used to ensure security) Auth σ . The calculation formula of the encrypted session private key is as follows:

[0078]

[0079] wherein SymmEnc represents a symmetric encryption operation K SD , the symmetric key of the source end and the destination end. PrivateKey represents the private key of the session. σ

[0080] Unlike the standard DRKey protocol, the present application makes two key improvements:

[0081] 1. In the session establishment packet, the related parameters of the Bloom filter (the Bloom filter size M and the number of hash functions K determined in step one) are additionally stored.

[0082] 2. The path representation method is changed from a node sequence to a link sequence, which significantly improves the efficiency of multicast and multipath session establishment. As shown in Figure 2 , in the traditional node sequence representation, R1 needs to plan two different paths and send two packets (path {R1, R2, R3, R4}, path {R1, R2, R5}) to establish sessions with R4 and R5, so that R2 needs to perform repeated key generation and key signature encryption operations. Under the link sequence representation, we can use {L1, L2, L3, L4} to represent a multicast tree, and the intermediate nodes only need to check whether their four interfaces are in the link sequence and forward them. In this way, not only the communication overhead is reduced, but also the intermediate routers (such as R2) do not need to do any additional operations.

[0083] After the source node transmits the session establishment packet, the intermediate nodes generate their own session keys according to the session ID and their own private secret values, and the calculation formula is as follows:

[0084]

[0085] wherein F represents a pseudo-random function, R represents R i ​The private value is only known by the router itself, while the SessionID represents the unique identification of the session. Thus, for each session, the router will generate a unique session key K for this session i . Then, the key will be encrypted and signed to ensure its confidentiality and authenticity during transmission. The calculation formula is as follows:

[0086]

[0087] where Enc represents the encryption operation, Sign represents the signature operation, and || represents the string concatenation operation. PubclicKey σ represents the public key of the session, and PrivateKey represents the private key of the node. The intermediate node further traverses all the links corresponding to its own out interfaces to determine whether the links exist in the path represented by the link in the session establishment packet. If they exist, the session establishment packet will be forwarded from the interface, and the encrypted key and the signature of the key generated by the node itself need to be carried in the session establishment packet during forwarding. In addition, in order to not carry the complete path in the subsequent data packet transmission, but directly know how to forward according to the SessionID, after knowing which out interfaces should be forwarded, the intermediate node can store the mapping from the SessionID to the correct out interface sequence, as follows:

[0088] SessionID→{Intf1,Intf2,...,Intf n};

[0089] With this mapping relationship, in the data forwarding stage, as long as the data packet path verification is successful, the node can find the corresponding correct out interface sequence according to the SessionID in the data packet, and then forward the data packet from these interfaces. Thus, the data packet does not need to carry the complete end-to-end path information but only needs to carry the SessionID.

[0090] The destination node first decrypts the private key of the session after receiving the session from the upstream node. The decryption process is as follows:

[0091]

[0092] where SymmDec is the operation of decrypting using the symmetric key, and K SD is the symmetric key shared by the source and destination nodes. After decrypting the session key PrivateKey σ , the key is used to decrypt the router key encrypted by the session public key of the upstream router. The signature of each router is verified using the public key of the router. The calculation process is as follows:

[0093]

[0094] Dec is used to decrypt the session key generated by the upstream router, and CheckSig is used to verify the signature generated by each upstream router.

[0095] After verification, the destination node obtains the keys of the nodes along the way and verifies their authenticity. Then, like the intermediate nodes, the destination node generates, signs, and encrypts its own session key, which is calculated according to the following formula:

[0096]

[0097] The first formula generates a key, the second formula encrypts the key using the session public key, and the third formula signs the generated key using the destination node's private key.

[0098] The destination node then returns all key-related information to the source node. The source node then decrypts and verifies the key. This completes the session establishment process. As a result, the source node possesses the keys of all downstream nodes, the destination node possesses the keys of the intermediate nodes, and the intermediate nodes only possess their own keys.

[0099] Step 3: The source node initializes the path verification header of the data packet and forwards the data packet from the outbound interface;

[0100] See also Figure 3 As shown, in networks using path verification, the classic IP packet header and the path verification header jointly determine the packet forwarding process. Therefore, the path verification header is often placed between the network layer header and the transport layer header. The present invention follows this design principle. Specifically, the path verification header of the present invention consists of two parts: packet metadata and packet security information.

[0101] Packet metadata consists of three fields: HASH, SessionID, and TS. The HASH field stores the hash value of the packet's static fields, verifying packet integrity. The SessionID field uniquely identifies the session, and its value is determined when the session is established. The TS field records the packet's creation timestamp to protect against replay attacks.

[0102] The data packet security information is composed of three fields: PVF, PPF and DestPVF. PVF is the path verification field. When a data packet is received, the intermediate node uses the PVF and PPF fields to verify whether the upstream node correctly forwards the data packet. If the verification is successful, the normal intermediate node will update the PVF field to support the subsequent path verification. The PPF field is a Bloom filter, which is used to store the link-based proof generated by the source node to support the path verification of the intermediate node. The DestPVF field stores the encrypted expected final PVF value for the destination node to complete the path verification.

[0103] Step 301, data packet metadata initialization;

[0104] The source node sets the SessionID field using the session ID determined in the session establishment stage, obtains the current timestamp TS field, and then calculates the static field hash value using the following formula:

[0105] HASH = H (Payload || SessionId || TS) ;

[0106] Where H represents the hash function, Payload represents the payload of the packet, SessionID is the unique identifier of the session, and || represents the string concatenation operation. After the calculation is completed, the hash value obtained by the calculation is filled into the HASH field of the data packet.

[0107] Step 302, data packet security information initialization;

[0108] The source node first obtains the end-to-end path established in the session establishment stage, which is represented by a series of link identifiers {L1, L2,..., L N}. Then, a Bloom filter is constructed according to the predetermined Bloom filter parameters, and its bit array is initialized to all 0. Then, all links in the path except the last link, i.e. {L1, L2,..., L N-1}, are traversed, and the path verification field PVF i of each link is calculated according to the following formula:

[0109]

[0110] Where PVF0 = 0, K i represents the session key of the intermediate i-th node R i . MAC Key (·) represents the message authentication code calculated using the key Key. HASH is the hash value of the data packet, || represents the string concatenation operation, and L i is the link identifier.

[0111] For each calculated PVF i , its value will be inserted into the Bloom filter, and the final bit array in the Bloom filter will be stored in the PPF field of the packet. Meanwhile, the initial value of the PVF field is set to 0. In addition, for the DestPVF field, its value is calculated according to the following formula:

[0112]

[0113] where K D denotes the session key of the destination node, and MAC Key (·) denotes the message authentication code calculated using the key Key.

[0114] Step 303, forwarding of the packet;

[0115] After the initialization of the packet is completed, the source node immediately forwards the packet through the out interface corresponding to the first link L1.

[0116] Step four: packet verification and path verification by the intermediate node;

[0117] In the present application, when the intermediate node receives the packet, in order to ensure the integrity of the packet and the correctness of the path, it needs to perform packet verification and path verification. Only when both verifications are successfully passed, the node will continue to forward the packet.

[0118] Step 401, packet verification;

[0119] Packet verification needs to verify the integrity, timestamp, and legitimacy of the Bloom filter (PPF field) in each packet.

[0120] Integrity verification: the intermediate node recalculates the hash value of the static field of the packet, and the value is calculated according to the following formula:

[0121] HASH = H (Payload || SessionID || TS);

[0122] where H represents the hash function, Payload represents the payload of the packet, SessionID is the unique identifier of the session, and || represents the string concatenation operation. The calculated value is compared with the HASH field in the packet to verify whether the packet has been tampered with during transmission. If it is inconsistent with the HASH field in the packet, it means that the packet has been tampered with during transmission.

[0123] Timestamp verification: the intermediate node calculates the difference between the current time and the timestamp (TS field) in the packet to determine whether it exceeds the preset threshold. The value is calculated according to the following formula:

[0124] TimeElasped = |now - pkt's TS|;

[0125] If the difference exceeds the threshold, it is determined that the data packet is likely a replay attack data packet, thereby effectively defending against replay attacks.

[0126] Bloom filter (PPF field) validity verification: Since the Bloom filter has false positives, there is a certain probability of misjudging the non-existent elements as existing in the Bloom filter. Therefore, a malicious node may use this point to bypass the verification of downstream nodes by setting the bits in the PPF field from 0 to 1. Assuming that the Bloom filter contains K hash functions, and a total of N link proofs are inserted into the Bloom filter. Normally, there are at most KN bits in the Bloom filter that are set to 1. If the intermediate node detects that the number of bits set to 1 in the PPF field exceeds KN, it can be determined that the PPF field is a malicious node forgery, thereby identifying and discarding the data packet.

[0127] If the data packet successfully passes the above data packet verification, it enters the next path verification. Otherwise, the data packet will be discarded directly. However, a malicious node can set a bit that is less than or exactly equal to KN. In this way, our scheme cannot detect this malicious behavior. However, the success rate of this attack is very small. Accordingly, after receiving multiple data packets that are not recorded in the BF valid link proofs, the downstream node can immediately identify malicious behavior (from the upstream node).

[0128] Step 402, path verification;

[0129] Path verification is used to confirm whether the upstream node correctly forwarded the data packet. Specifically, the intermediate node first obtains the link identifier LiD in corresponding to the incoming interface, and extracts the PVF and HASH fields from the data packet. Then, the expected PVF value PVF Expected is calculated, and the calculation formula is as follows:

[0130]

[0131] Next, we find the K hash functions corresponding to the SessionID in the packet, and take the PPF field in the packet as a bit array, thereby constructing a Bloom filter. Then, it is determined whether PVF Expected is a member of the Bloom filter. If PVF ExpectedIf a node is determined to be a member of the Bloom filter, path verification has passed. After path verification, the node uses the SessionID in the packet to look up the SessionID-to-outbound interface mapping recorded when the session was established, thereby obtaining the correct outbound interface. The packet is then forwarded through this outbound interface.

[0132] Step 5: The destination node verifies the data packet path;

[0133] The destination node also needs to verify whether the upstream node has correctly forwarded the data packet. Specifically, the destination node first obtains the link identifier LiD corresponding to the inbound interface. in , and extract the PVF and HASH fields from the data packet. Then, calculate the expected DestPVF value DestPVF Expected The calculation formula is as follows:

[0134]

[0135] Next, we extract the DestPVF field stored in the data packet and compare it with the calculated DestPVF Expected Perform an equality comparison. If they are equal, the path verification passes and the data packet will be submitted to the upper layer (transport layer) for processing.

[0136] Example 2

[0137] The method of the present invention implements the present invention and the currently most advanced methods ICING and OPT in the Linux kernel and simulates them on a container-based simulation platform.

[0138] Figure 4 The distribution of processing time consumption of this method and the most advanced methods ICING and OPT at different types of nodes (source node, intermediate node, destination node) under different end-to-end hop counts is shown. Specifically, Figure 4 Figure 1 shows ICING, OPT, and our method from left to right. We can see that, with the same end-to-end hop count, our method outperforms ICING and OPT in processing latency at the source, intermediate, and destination nodes, demonstrating its high efficiency.

[0139] Figure 5The data transmission efficiency of the method and the prior art ICING and OPT under different end-to-end hop numbers is shown. The first and second subgraphs respectively show the comparison results of the throughput (Throughput TP) and goodput (Goodput GP) generated by the method and the prior art ICING and OPT under different payloads (512 bytes, 1024 bytes) and hop numbers. The third and fourth subgraphs further show the comparison results of the goodput rate (i.e., the ratio of the goodput to the throughput) generated by the method and the prior art ICING and OPT under different payloads (512 bytes, 1024 bytes) and hop numbers. It is not difficult to find that, since the method is more efficient in single-node processing, the transmission performance indicators such as the throughput, goodput and goodput rate of the method are better than those of the ICING and OPT methods.

[0140] Embodiment three

[0141] The application further provides a path verification system for storing link proof based on a Bloom filter, which is used to implement the method of embodiment one, and comprises a calculation module, a session establishment module, a data packet initialization module, an intermediate node verification module and a destination node verification module.

[0142] The calculation module is used to calculate optimal Bloom filter parameters based on a source node.

[0143] The session establishment module is used to establish a session of the source node and the destination node based on the optimal Bloom filter parameters.

[0144] The data packet initialization module is used to design a path verification header of a source node initialization data packet and forward the data packet from an outgoing interface based on the established session of the source node and the destination node.

[0145] The intermediate node verification module is used for data packet verification and path verification by an intermediate node.

[0146] The destination node verification module is used for data packet verification and path verification by a destination node.

[0147] In this embodiment, the process of calculating optimal Bloom filter parameters based on a source node comprises:

[0148]

[0149] Wherein, M is the Bloom filter size, K is the number of hash functions, p is the false positive probability of the Bloom filter, and N is the total number of hops from the source node to the destination node.

[0150] In this embodiment, the process of establishing a session of the source node and the destination node based on optimal Bloom filter parameters comprises:

[0151] The session is established based on the improved DRKey protocol, which is divided into three stages: the source node initializes the session establishment data packet, the intermediate node generates the key and forwards it to the downstream node, and the destination node verifies and returns the key sequence.

[0152] In this embodiment, the path verification header includes two parts: data packet metadata and data packet security information. The data packet metadata consists of three fields: HASH, SessionID, and TS, and the data packet security information consists of three fields: PVF, PPF, and DestPVF.

[0153] The process of designing the source node to initialize the path verification header of the data packet and forward the data packet out the outbound interface includes:

[0154] Step 301: Initialize data packet metadata:

[0155] The source node uses the session ID determined during the session establishment phase to set the SessionID field, obtains the current timestamp to set the TS field, and then calculates the hash value of the static field:

[0156] HASH=H(Payload||SessionID||TS);

[0157] Where H represents the hash function and Payload represents the payload of the packet. After the calculation is completed, the obtained hash value is filled into the HASH field of the data packet.

[0158] Step 302: Initialize data packet security information:

[0159] The source node first obtains the end-to-end path established in the session establishment phase. The path is represented by a series of link labels {L1, L2, ..., L N}, then build a Bloom filter according to the pre-determined Bloom filter parameters, the bit array is initialized to all 0, and then traverse all links in the path except the last link, that is, {L1, L2, ..., L N-1}, perform path verification field PVF on each link i Calculation:

[0160]

[0161] Among them, K i The i-th node R in the middle of the table i The session key, HASH is the hash of the data packet, || represents string concatenation, MAC Key (·) represents the message authentication code calculated using the key Key;

[0162] Each calculated PVF i is inserted into the Bloom filter, and the bit array in the final Bloom filter is stored in the PPF field of the packet, while the initial value of the PVF field is set to 0, and the DestPVF field is calculated using the key of the destination node, which follows the formula:

[0163]

[0164] where K D represents the session key of the destination node;

[0165] Step 303, forwarding of the packet:

[0166] After the initialization of the packet is completed, the source node immediately forwards the packet out through the out interface corresponding to the first link L1.

[0167] In this embodiment, the process of packet verification by the intermediate node includes integrity verification, timestamp verification, and Bloom filter PPF field legality verification.

[0168] The process of path verification by the intermediate node includes:

[0169] The link identifier LiD in corresponding to the in interface is obtained, and the PVF and HASH fields are extracted from the packet.

[0170] The expected PVF value PVF Expected is calculated, and the calculation formula is:

[0171]

[0172] The K hash functions corresponding to the SessionID in the packet are found, and the PPF field in the packet is taken as a bit array, thereby constructing a Bloom filter.

[0173] It is judged whether PVF Expected is a member of the Bloom filter: if PVF Expected is judged to be a member of the Bloom filter, the path verification passes.

[0174] After the path verification passes, the node finds the correct out interface using the SessionID in the packet to find the SessionID-to-out interface mapping recorded during session establishment, and the packet is forwarded through the out interface.

[0175] In this embodiment, the process of path verification by the destination node includes:

[0176] The link identifier LiDin and extract the PVF and HASH fields from the data packet;

[0177] calculate the expected DestPVF value DestPVF Expected , and the calculation formula is:

[0178]

[0179] extract the DestPVF field stored in the data packet, and compare it with the calculated DestPVF Expected If they are equal, the path verification is passed, and the data packet will be submitted to the upper layer, i.e. the transport layer, for processing.

[0180] The above-described embodiments are only descriptions of the preferred modes of the present application, and are not intended to limit the scope of the present application. Various modifications and improvements to the technical solutions of the present application made by those of ordinary skill in the art without departing from the design spirit of the present application shall fall within the protection scope of the present application as defined by the claims.

Claims

1. A path verification method based on Bloom filter storage link proof, characterized in that: The method comprises: Step 1: Calculate the optimal Bloom filter parameters based on the source node; Step 2: Based on the optimal Bloom filter parameters, establish a session between the source node and the destination node; Step 3: Based on the established session between the source node and the destination node, the source node is designed to initialize the path verification header of the data packet and forward the data packet through the outbound interface; Step 4: The intermediate node performs data packet verification and path verification; Step 5: Based on the forwarded data packets, the destination node performs path verification.

2. The method according to claim 1, characterized in that Methods for calculating optimal Bloom filter parameters based on source nodes include: Among them, M is the size of the Bloom filter, K is the number of hash functions, p is the false positive probability of the Bloom filter, and N is the total number of hops from the source node to the destination node.

3. The method according to claim 1, characterized in that The method for establishing a session between a source node and a destination node based on the optimal Bloom filter parameters includes: The session is established based on the improved DRKey protocol, which is divided into three stages: the source node initializes the session establishment data packet, the intermediate node generates the key and forwards it to the downstream node, and the destination node verifies and returns the key sequence.

4. The method according to claim 1, wherein The path verification header consists of two parts: packet metadata and packet security information. The packet metadata consists of three fields: HASH, SessionID, and TS, and the packet security information consists of three fields: PVF, PPF, and DestPVF. Methods for designing a source node to initialize the path verification header of a data packet and forward the data packet from the outbound interface include: Step 301: Initialize data packet metadata: The source node uses the session ID determined during the session establishment phase to set the SessionID field, obtains the current timestamp to set the TS field, and then calculates the hash value of the static field: HASH=H(Payload||SessionID||TS); Where H represents the hash function and Payload represents the payload of the packet. After the calculation is completed, the obtained hash value is filled into the HASH field of the data packet. Step 302: Initialize data packet security information: The source node first obtains the end-to-end path established in the session establishment phase. The path is represented by a series of link labels {L1, L2, ..., L N }, then build a Bloom filter according to the pre-determined Bloom filter parameters, the bit array is initialized to all 0, and then traverse all links in the path except the last link, that is, {L1, L2, ..., L N-1 }, perform path verification field PVF on each link i Calculation: Among them, K i Represents the middle i-th node R i The session key, || represents string concatenation, MAC Key (·) represents the message authentication code calculated using the key Key; Each calculated PVF i Inserted into the Bloom filter, the final bit array in the Bloom filter will be stored in the PPF field of the data packet, and the initial value of the PVF field is set to 0. For the DestPVF field, the calculation follows the formula: Among them, K D It represents the session key of the destination node; Step 303, forwarding of data packets: After completing the initialization of the data packet, the source node immediately forwards the data packet through the outbound interface corresponding to the first link L1.

5. The method according to claim 1, wherein The methods used by the intermediate nodes to verify data packets include: integrity verification, timestamp verification, and Bloom filter PPF field legitimacy verification; The methods for intermediate nodes to perform path verification include: Get the link identifier LiD corresponding to the inbound interface in , and extract the PVF and HASH fields from the data packet; Calculate the expected PVF value PVF Expected , the calculation formula is: Find the K hash functions corresponding to the SessionID in the packet and use the PPF field in the packet as a bit array to construct a Bloom filter; Determining PVF Expected Is it a member of the Bloom filter: If PVF Expected If it is determined to be a member of the Bloom filter, the path verification passes; After the path verification passes, the node will use the SessionID in the packet to find the mapping from the SessionID to the outbound interface recorded when the session was established, thereby obtaining the correct outbound interface, and the data packet will be forwarded through the outbound interface.

6. The method according to claim 1, characterized in that The destination node performs path verification in the following ways: Get the link identifier LiD corresponding to the inbound interface in , and extract the PVF and HASH fields from the data packet; Calculate the expected DestPVF value DestPVF Expected , the calculation formula is: Extract the DestPVF field stored in the data packet and compare it with the calculated DestPVF Expected An equality comparison is performed. If they are equal, the path verification passes and the data packet will be submitted to the upper layer, the transport layer, for processing.

7. A path verification system based on Bloom filter storage link proof, the system is used to implement the method according to any one of claims 1 to 6, characterized in that: The system includes: a calculation module, a building module, a design module, an intermediate node verification module, and a destination node verification module; The calculation module is used to calculate the optimal Bloom filter parameters based on the source node; The establishing module is used to establish a session between the source node and the destination node based on the optimal Bloom filter parameters; The design module is used to design a path verification header of a data packet initialized by the source node and forward the data packet from an outbound interface based on the established session between the source node and the destination node; The intermediate node verification module is used for performing data packet verification and path verification at the intermediate node; The destination node verification module is used to perform path verification on the destination node based on the forwarded data packet.

Images