Inter-domain routing flow propagation protection method and device based on RPKI encryption object

Abstract

The invention discloses an inter-domain routing traffic propagation protection method and device based on an RPKI encryption object, and the method comprises the steps: adding a new encryption object Binding Message (BM) in an RPKI, carrying out the checking and filtering of the traffic of an inter-domain router through the synchronization of the encryption object with an RPKI storage library, discarding the problematic traffic, and carrying out the protection of the traffic propagation of the inter-domain router. Prefix hijacking protection of routing between autonomous domains and protection of ASPATH path attributes in a BGP-UPDATE message are realized, and routing leakage attacks are partially solved; according to the method and the device, the path verification function which is not realized by the current RPKI can be effectively realized, the problems existing in BGPSec are solved, and the BGP routing security is ensured.

Description

Technical Field

[0001] The present application relates to the field of computer network information security technology, and in particular to a method, device, electronic device and storage medium for protecting inter-domain routing traffic propagation based on RPKI encryption objects. Background Art

[0002] BGP, the full name of which is Border Gateway Protocol, is a dynamic routing protocol between autonomous systems (AS) currently used in the Internet. It is used to automatically exchange IP routing information and reachability information between different ASs. Its main function is to control inter-domain routing propagation and select the optimal route.

[0003] Although the BGP protocol plays a vital role in the Internet, its own security is difficult to guarantee. General BGP-related problems can be divided into two categories: route leakage and route hijacking. Route leakage is the propagation of one or more route announcements beyond their intended scope. This is when the BGP route learned from an AS to another AS violates the predetermined policy of the receiver, sender and / or an AS along the previous AS path. Route hijacking is usually an unauthorized route source that announces routes. Route hijacking can be divided into route prefix hijacking and route path tampering. The cause of route leakage or route hijacking may be unintentional administrator misconfiguration or malicious attackers launching network attacks. The results of these two routing problems may be path loops, route redirection or denial of service attacks. Summary of the invention

[0004] The present application aims to solve one of the technical problems in the related art at least to some extent.

[0005] To this end, the first purpose of this application is to propose a method for protecting inter-domain routing traffic propagation based on RPKI encryption objects, aiming to overcome the problems existing in the prior art, by adding new certificates to the RPKI system to solve the security issues of inter-domain routing prefix hijacking, routing path tampering, and routing leakage.

[0006] The second objective of the present application is to propose an inter-domain routing traffic propagation protection device based on RPKI encryption objects.

[0007] The third objective of the present application is to provide an electronic device.

[0008] A fourth objective of the present application is to provide a computer-readable storage medium.

[0009] To achieve the above-mentioned purpose, the first embodiment of the present application proposes a method for protecting inter-domain routing traffic propagation based on RPKI encryption objects, including:

[0010] When the first routing entity receives a routing announcement sent by other routing entities on the routing path, it queries the RPKI repository to verify whether the routing announcement is authorized; after confirming the authorization, the router of the first routing entity generates a first encrypted object and signs the certificate;

[0011] After generating the first encrypted object, the router of the first routing entity generates a second encrypted object generated during the routing propagation process and includes a second encrypted object generated by each routing entity and a second encrypted object list;

[0012] Notifying the second encrypted object list to all routing entities on the routing path, including the routing entity that sends the routing announcement;

[0013] After receiving the second encrypted object list, the routers of all routing entities obtain the first encrypted object to verify whether the received second encrypted object list is authorized; after confirming the authorization, the routing traffic propagation of the first routing entity is approved.

[0014] When the first routing entity receives a routing announcement sent by other routing entities on the routing path, it queries the RPKI repository to verify whether the routing announcement is authorized; after determining the authorization, the router of the first routing entity generates a first encryption object and signs a certificate, including:

[0015] When the first routing entity receives a routing advertisement BGP-UPDATE sent by a second routing entity from its neighbor, the first routing entity obtains from the RPKI repository the second encrypted object generated by all routing entities on the routing path involved in the BGP-UPDATE message;

[0016] Verify all second encryption objects to verify whether the current BGP-UPDATE message information is authorized;

[0017] If the verification is successful, the router of the first routing entity generates a first encrypted object and places it in the repository of the RPKI;

[0018] If the verification fails, the route filtering operation is not performed and the received second encrypted object list is discarded.

[0019] After the first encrypted object is generated, the router of the first routing entity generates a second encrypted object list generated during the routing propagation process and including the second encrypted object generated by each routing entity, including:

[0020] The router of the first routing entity generates a first cryptographic object and stores it in the RPKI repository;

[0021] The router of the first routing entity packages the IDs of all second encrypted objects generated by the routing entity related to this routing announcement BGP-UPDATE message, and attaches an identifier that uniquely identifies the first encrypted object to obtain a second encrypted object list.

[0022] After receiving the second encrypted object list, the routers of all routing entities obtain the first encrypted object to verify whether the received second encrypted object list is authorized; after determining the authorization, the routing traffic propagation of the first routing entity is approved, including:

[0023] After receiving the notification message of the second encryption object list, any routing entity obtains the first encryption object;

[0024] Use the public key to perform signature verification on the first encrypted object to verify whether the notification message of the second encrypted object list is authorized;

[0025] If the verification is successful, the router of the routing entity that receives the notification message of the second encrypted object list modifies the routing filtering information, recognizes the routing propagation traffic in the routing announcement BGP-UPDATE message sent from the first routing entity, and performs traffic filtering;

[0026] If the verification fails, the routing entity discards the received second encryption object list message without additional processing.

[0027] Among them, the remaining routing entities on the non-routing path periodically obtain the first encrypted object from the RPKI repository and use the public key to verify the signature of the first encrypted object. If the verification passes, add or modify the traffic filtering policy to collaboratively filter the traffic forwarded from the router of the first routing entity that should not pass through this routing entity.

[0028] The router of each routing entity on the routing path will generate its own first encrypted object and verify the existing first encrypted objects generated by the routers of other routing entities to avoid routing path tampering hijacking attacks.

[0029] The notification message of the second encryption object list is only sent to the routing entity on the routing announcement BGP-UPDATE path to avoid routing leakage.

[0030] To achieve the above-mentioned purpose, the second embodiment of the present application proposes an inter-domain routing traffic propagation protection device based on RPKI encryption objects, including:

[0031] A first encrypted object signing module, configured to query the RPKI repository when the first routing entity receives a routing announcement sent by other routing entities on the routing path to verify whether the routing announcement is authorized; after determining the authorization, the router of the first routing entity generates a first encrypted object and signs the certificate;

[0032] A second encryption object list generating module, configured to generate, after generating the first encryption object, a second encryption object list generated by a router of the first routing entity in a routing propagation process and including the second encryption object generated by each routing entity;

[0033] A second encryption object list notification module, used to notify the second encryption object list to all routing entities on the routing path including the routing entity that sends the routing announcement;

[0034] The filtering protection module is used to obtain the first encrypted object certificate after the routers of all routing entities receive the second encrypted object list to verify whether the received second encrypted object list is authorized; after confirming the authorization, the routing traffic propagation of the first routing entity is approved.

[0035] To achieve the above-mentioned purpose, the third aspect of the present application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0036] Memory stores computer-executable instructions;

[0037] The processor executes the computer-executable instructions stored in the memory to implement the method of the aforementioned technical solution.

[0038] To achieve the above-mentioned purpose, the fourth aspect embodiment of the present application proposes a computer-readable storage medium, in which computer execution instructions are stored. When the computer execution instructions are executed by a processor, they are used to implement the method as the aforementioned technical solution.

[0039] Different from the prior art, the present invention provides a method, device, electronic device and storage medium for protecting inter-domain routing traffic propagation based on RPKI encryption objects. The method adds a new encryption object BindingMessage (BM) to RPKI, uses the encryption object to synchronize with the RPKI repository, checks and filters the traffic of inter-domain routers, discards problematic traffic, and implements prefix hijacking protection for autonomous inter-domain routing and protection of the AS_PATH path attribute in the BGP-UPDATE message, and partially solves the routing leakage attack. Through the present invention, the path verification function that has not yet been implemented in the current RPKI can be effectively realized, which makes up for the problems existing in BGPSec and ensures the security of BGP routing.

[0040] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 It is a flow chart of an inter-domain routing traffic propagation protection method based on RPKI encryption objects provided by the present invention.

[0042] Figure 2 It is a schematic diagram of BGP routing prefix hijacking in an inter-domain routing traffic propagation protection method based on RPKI encryption objects provided by the present invention.

[0043] Figure 3 It is a schematic diagram of BGP routing path tampering in an inter-domain routing traffic propagation protection method based on RPKI encryption objects provided by the present invention.

[0044] Figure 4 It is a schematic diagram of a BGP route leakage attack in an inter-domain route traffic propagation protection method based on an RPKI encryption object provided by the present invention.

[0045] Figure 5 It is a schematic diagram of the eContent content of the BM encryption object in the inter-domain routing traffic propagation protection method based on the RPKI encryption object provided by the present invention.

[0046] Figure 6 It is a schematic diagram of the contents of FCList in an inter-domain routing traffic propagation protection method based on RPKI encryption objects provided by the present invention.

[0047] Figure 7 The present invention provides a schematic diagram of a route UPDATE announcement processing flow of a single BGP router in a method for protecting inter-domain route traffic propagation based on an RPKI encryption object.

[0048] Figure 8 It is a schematic diagram of an actual case of an inter-domain routing traffic propagation protection method based on RPKI encryption objects provided by the present invention.

[0049] Fig. 9 It is a structural schematic diagram of an inter-domain routing traffic propagation protection device based on RPKI encryption objects provided by the present invention. DETAILED DESCRIPTION

[0050] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0051] The following describes a method and device for protecting inter-domain routing traffic propagation based on RPKI encryption objects in an embodiment of the present application with reference to the accompanying drawings.

[0052] Figure 1 A flowchart of a method for protecting inter-domain routing traffic propagation based on RPKI encryption objects provided in an embodiment of the present application. The method comprises the following steps:

[0053] S101: When a first routing entity receives a routing announcement sent by other routing entities on a routing path, it queries the RPKI repository to verify whether the routing announcement is authorized; after confirming the authorization, the router of the first routing entity generates a first encryption object and signs a certificate.

[0054] When the first routing entity receives a routing advertisement BGP-UPDATE sent by a second routing entity from its neighbor, the first routing entity obtains the second encrypted object generated by all routing entities involved in the BGP-UPDATE message from the RPKI repository;

[0055] Verify all second encryption objects to verify whether the current BGP-UPDATE message information is authorized;

[0056] If the verification is successful, the router of the first routing entity applies for the first encryption object and places it in the repository of the RPKI;

[0057] If the verification fails, the route filtering operation is not performed and the received second encrypted object list is discarded.

[0058] Specifically, in the present invention, AS represents an autonomous system, RP represents a relying party, FC represents a Forwarding Commitment, which is an RPKI encryption object that needs to be used together, that is, the second encryption object involved in the present invention, and BM represents a Binding Message, which is an encryption object to be newly added to RPKI, that is, the first encryption object involved in the present invention.

[0059] When AS1, the first routing entity, receives a BGP-UPDATE from its neighbor, the second routing entity AS2, it queries the RPKI repository for all encryption objects generated by the AS on this AS-PATH, namely the FC encryption object, and uses the public key therein to verify the signature of the certificate of the FC encryption object to verify whether the current BGP-UPDATE message information is authorized; if the verification is successful, AS1's router R1 generates a BM encryption object, the certificate of the BM encryption object is self-signed by R1, and the BM encryption object is placed in the RPKI repository for synchronization and downloading by other RPs. The BM certificate is verified by the RP to prove its correctness. This BM is recorded as BM1; otherwise, no operation is performed and the BGP-UPDATE message is discarded.

[0060] In practical applications, routing prefix hijacking attacks such as Figure 2 As shown, AS3's router R3 received two announcements for the same routing prefix. Since the routing prefix announced by AS4 is longer, according to the BGP routing rules, AS4 is selected as the best route, and the hijacking is successful.

[0061] Routing path tampering attack Figure 3 As shown, AS3's router R3 received two announcements for the same routing prefix. Since the AS_PATH path announced by AS4 is shorter, according to the BGP routing rules, AS4 is selected as the best route, and the hijacking is successful.

[0062] Route leakage attacks such as Figure 4 As shown in the figure, this is an example of route leakage. The relationships between ASs are Provider-Customer (P2C), Peer-Peer (P2P), and Sibling-Sibling (S2S). The principles to be followed when configuring route announcement rules are:

[0063] Announce to a Provider: When a Customer announces routing information to its Provider, the AS serving as the Customer can output its own routes and the routes of its Customers, but cannot output routes obtained from other Providers or Peers.

[0064] Announce to a Customer: When a Provider announces routing information to its Customer, the AS acting as a Provider can announce its own routes and its Customer's routes, or it can output routes obtained from other Providers or Peers.

[0065] Announce to a Peer: When exchanging routing information with a Peer, you can announce your own routes and Customer's routes, but you cannot output routes obtained from other Providers or Peers.

[0066] The routing strategy between ASs needs to be based on the No-Valley criterion, which estimates the direction of routing information exchange in Provider-Customer and Peer-Peer relationships:

[0067] Principle 1: There is at most one P2P connection in an AS path;

[0068] Rule 2: If there is a P2C connection in an AS path, it cannot be followed by a C2P connection, but only by a P2C or S2S connection.

[0069] Principle 3: A P2C connection cannot be a P2P connection;

[0070] Principle 4: A P2P connection cannot be a C2P connection, it can only be a P2C or S2S connection.

[0071] According to the No-Valley standard, RFC7908 classifies BGP route leaks as follows:

[0072] The AS announces the routes received from the provider to other providers (P2C followed by C2P);

[0073] The AS announces the routes received from the peer to other peers; (P2P followed by P2P);

[0074] The AS advertises the routes received from the provider to its peers; (P2C followed by P2P);

[0075] The AS advertises the routes received from its peers to its providers (P2P followed by C2P).

[0076] RPKI is short for Resource Public Key Infrastructure. RPKI is a resource public key infrastructure built around the right to use Internet digital resources, including IP and ASN. The purpose of RPKI is to make Internet routing more secure. RPKI mainly consists of three parts: public key infrastructure, cryptographic signature objects, and distributed repositories. RPKI allows holders of Internet digital resources to make verifiable statements about how their resources are used. To achieve this, it uses a public key infrastructure that creates a resource certificate chain with the same structure as the way IP addresses and numbers are passed. Currently, RPKI is used by the legitimate owner of an IP address block to make a certification statement, which is used to indicate which AS the IP prefix in BGP belongs to. This certification statement is called Route Origin Authorization (ROA), which contains a prefix, a maximum prefix length, and the source AS number, which is used to authorize the source AS to announce the IP address prefix. Afterwards, other network operators can download and verify these statements from the distributed repository of RPKI and make routing decisions based on them. This process is called Route Origin Validation (ROV).

[0077] BGPSec is used to solve the security problem of BGP. However, BGPSec requires all AS routers on the path to sign and verify the prefix to ensure the correctness and integrity of the path. Therefore, its incremental deployment is difficult and the computational burden on routers is too heavy.

[0078] The BM encryption object designed by the present invention follows the encryption object template designed by RFC 6488, wherein the content of the eContent of the BM encryption object is as follows: Figure 5 As shown. Among them, asidS is the number of the AS that generates the BM; prefixS is a set of address prefixes that this AS can reach according to its local routing policy; prefixD is a prefix in BGP-UPDATE; BMID is the unique identifier of BM, which is used to uniquely locate a BM encryption object in RPKI. It is a HASH result, and the HASH content is the AS-PATH in BGP-UPDATE, the number of this AS, and the prefixD field.

[0079] The content of FCList of the present invention is as follows Figure 6 The fields are explained as follows:

[0080] BMID: It is the unique identifier of the BM encryption object, used to uniquely identify the BM encryption object in RPKI.

[0081] FCIDs: The IDs of all packaged FC encryption objects. FCID is the unique identifier of FC and is used to uniquely locate a FC encryption object in RPKI.

[0082] The processing flow of the present invention on a single BGP router is as follows: Figure 7 If the router is a router of the AS to which the source prefix belongs, that is, it belongs to the starting AS of the routing prefix, then the router does not need to perform the operations in the figure, that is, it does not need to wait for receiving BGP-UPDATE message information, does not need to obtain BM encryption objects from the RPKI repository, does not need to verify BM encryption objects, and does not need to generate BM encryption objects and FCList.

[0083] In this step, upon receiving the BGP-UPDATE route announcement, the BGP router R1 of the first routing entity AS1 obtains the FC encryption object related to each IP address prefix in the BGP-UPDATE message from the RPKI repository and verifies all related FC encryption objects. The signature information in the FC encryption object is verified using the carried public key information. If the verification is successful, it means that the route announcement has not been hijacked and the next step can be continued; otherwise, it means that there is a problem with the route announcement and the message needs to be discarded.

[0084] S102: After generating the first encrypted object, the router of the first routing entity generates a second encrypted object list generated in the routing propagation process and including the second encrypted object generated by each routing entity.

[0085] In an embodiment of the present invention, a router of the first routing entity signs the first encryption object certificate and stores it in the RPKI repository;

[0086] The router of the first routing entity packages the IDs of all second encrypted objects generated by the routing entity related to this routing announcement BGP-UPDATE message, and attaches an identifier that uniquely identifies the first encrypted object to obtain a second encrypted object list.

[0087] S103: Notify the second encryption object list to all routing entities on the routing path, including the routing entity that sends the routing announcement.

[0088] Specifically, after the router R1 of AS1 generates the BM encryption object and places it in the RPKI repository, R1 packages the IDs of all FC encryption objects related to this BGP-UPDATE message, and attaches an identifier BMID that can uniquely identify the above BM encryption object. The packaged content is called FCList; then, R1 will notify this FCList to all ASs on the AS-PATH path including its neighbor AS2.

[0089] S104: After receiving the second encrypted object list, the routers of all routing entities obtain the first encrypted object to verify whether the received second encrypted object list is authorized; after confirming the authorization, the routing traffic propagation of the first routing entity is approved.

[0090] After receiving the notification message of the second encryption object list, any routing entity obtains the first encryption object;

[0091] Use the public key to perform signature verification on the first encrypted object to verify whether the notification message of the second encrypted object list is authorized;

[0092] If the verification is successful, the router of the routing entity that receives the notification message of the second encrypted object list modifies the routing filtering information, recognizes the routing propagation traffic in the routing announcement BGP-UPDATE message sent from the second routing entity, and performs traffic filtering;

[0093] If the verification fails, the routing entity discards the received second encryption object list message without additional processing.

[0094] Specifically, after receiving the FCList announcement message, router R2 of AS2 first obtains the BM encryption object BM1 from RP, and uses the public key therein to verify the signature of the certificate therein to verify whether the current FCList announcement message is authorized; if the verification passes, R2 modifies the route filtering information and approves the traffic from R1 to the prefix announced by this BGP-UPDATE; otherwise, the message is discarded, and the above traffic forwarded from R1 is filtered.

[0095] In other embodiments of the present invention, for the remaining routing entities on the non-routing path, the first encrypted object is periodically obtained from the RPKI repository, and the signature of the first encrypted object is verified using the public key. If the verification passes, the traffic filtering policy is added or modified to collaboratively filter the traffic forwarded from the router of the first routing entity that should not pass through this routing entity.

[0096] The routers on the subsequent BGP-UPDATE forwarding path need to operate the BGP-UPDATE message according to the above steps and generate the BM encryption object and FCList. Each AS on the BGP-UPDATE path needs to receive the FCList sent by all ASs behind it, that is, the ASs on the subsequent routing path where the current AS makes route announcements.

[0097] After BGP routing converges, all ASs filter traffic according to the established routing filter table, thereby protecting the propagation of BGP inter-domain routing traffic and detecting routing leaks.

[0098] In addition, the router of each routing entity on the routing path will generate its own first encrypted object and verify the first encrypted objects generated by the routers of other routing entities to avoid routing path tampering hijacking attacks.

[0099] For the legacy routers that have not been upgraded, it is sufficient to not verify the existing BM and not generate a new BM.

[0100] The public and private keys of the BGPSec router may be used to generate the public and private keys of the BM encryption object of the present invention. For details, please refer to RFC 8209, which will not be described in detail here.

[0101] The notification message of the second encrypted object list is only sent to the routing entity on the routing announcement BGP-UPDATE path to avoid routing leakage.

[0102] Specifically, the example topology of the BGP-UPDATE announcement used in the present invention is as follows: Figure 8 As shown, the subsequent implementation methods and their explanations are all referred to Figure 8 This example simplifies the operations within the AS. This is because although there may be multiple BGP routers within an AS, they actually play the same role and do not require more operations, so they can be simplified. BGP router R1 of AS1 has announced the route to its neighbor BGP router R2 of AS2, and BGP router R2 of AS2 has propagated this route announcement to AS3. Assume that the route prefix announced by R1 is 192.0.2.0 / 24 and the ASID is 1. Among them, AS2 obtains and verifies FC{1,2} from the RPKI repository, and AS3 obtains and verifies FC{1,2}, FC{2,3} from the RPKI repository.

[0103] AS2 and AS3 both need to generate BM encryption objects, BM2, BM3, and put the encryption objects into the RPKI repository. Taking BM3 as an example, the routing prefix is ​​192.0.2.0 / 24, the ASID is the AS number 3 of the currently generated BM, the BMID is HASH (192.0.2.0 / 24, {1, 2}, 3), and the Signature is filled in as needed. At the same time, AS2 and AS3 both need to generate FCList, AS2 needs to send it to AS1, and AS3 needs to send it to AS2 and AS1.

[0104] The present invention requires RP to obtain the BM encryption object list from the RPKI repository. This can be divided into online processing and offline processing. Online processing requires the BGP router to obtain the relevant BM encryption object list from the RPKI repository immediately after receiving the FCList message and verify it. This processing method has high requirements for latency and is difficult to implement in the current RPKI validator implementation; offline processing is that the BGP router first processes the FCList message and updates the routing table items. When the RP synchronizes to the relevant BM encryption objects from the Trust Anchor repository of RPKI, it will audit and eliminate illegal routing table items. This method has relatively low requirements for latency and basically does not affect the routing convergence speed of the BGP router. Regardless of the method, the BGP router is required to obtain all corresponding FCs from the FCList message and verify them to infer the current AS_PATH information. If the verification is passed, the routing filter table items are modified or added; otherwise, the FCList message is discarded.

[0105] All autonomous systems deploying the present invention need to periodically synchronize BM encrypted objects from the RPKI repository and update the routing filter table items according to the content of the BM encrypted objects to perform off-path collaborative filtering.

[0106] AS2's BGP router R2 receives inter-domain routing traffic from R3 for prefix 192.0.2.0 / 24. R2 allows this traffic to pass and forwards it to R1. If R4 (a router that is not a node on this AS-PATH) receives inter-domain routing traffic from R3 for prefix 192.0.2.0 / 24, it will discard it.

[0107] Through the above steps, if the AS node on the path deploys the present invention, the BGP traffic path cannot be modified by malicious nodes, and the routing traffic is protected.

[0108] Fig. 9 A schematic diagram of the structure of an inter-domain routing traffic propagation protection device based on RPKI encryption objects provided in an embodiment of the present application.

[0109] like Fig. 9 As shown, the device 300 includes:

[0110] The first encrypted object signing module 310 is used for, when the first routing entity receives a routing announcement sent by other routing entities on the routing path, to query the RPKI repository to verify whether the routing announcement is authorized; after determining the authorization, the router of the first routing entity generates a first encrypted object and signs the certificate;

[0111] A second encryption object list generating module 320, configured to generate, after generating the first encryption object, a second encryption object list generated by the router of the first routing entity during the routing propagation process and including the second encryption object generated by each routing entity;

[0112] A second encryption object list notification module 330, configured to notify the second encryption object list to all routing entities on the routing path, including the routing entity that sends the routing announcement;

[0113] The filtering protection module 340 is used to obtain the first encrypted object certificate after the routers of all routing entities receive the second encrypted object list to verify whether the received second encrypted object list is authorized; after confirming the authorization, the routing traffic propagation of the first routing entity is approved.

[0114] In order to implement the above embodiments, the present application also proposes an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method provided by the above embodiments.

[0115] In order to implement the above embodiments, the present application also proposes a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the methods provided by the above embodiments.

[0116] In order to implement the above embodiments, the present application also proposes a computer program product, including a computer program, which implements the methods provided by the above embodiments when executed by a processor.

[0117] The collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in this application are in compliance with relevant laws and regulations and do not violate public order and good morals.

[0118] It should be noted that personal information from users should be collected for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. In addition, such collection / sharing should be carried out after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign the agreement / authorization including authorization of relevant user information before the user uses the function. In addition, any necessary steps should be taken to protect and safeguard access to such personal information data and ensure that others who have access to personal information data comply with its privacy policy and procedures.

[0119] The present application is expected to provide an implementation scheme for users to selectively block the use or access of personal information data. That is, the present disclosure is expected to provide hardware and / or software to prevent or block access to such personal information data. Once the personal information data is no longer needed, the risk can be minimized by limiting data collection and deleting the data. In addition, when applicable, such personal information is de-identified to protect the privacy of the user.

[0120] In the description of the aforementioned embodiments, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, without contradiction.

[0121] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In the description of this application, the meaning of "plurality" is at least two, such as two, three, etc., unless otherwise clearly and specifically defined.

[0122] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0123] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, device or apparatus (such as a computer-based system, a system including a processor, or other system that can fetch instructions from an instruction execution system, device or apparatus and execute the instructions), or in combination with these instruction execution systems, devices or apparatuses. For the purpose of this specification, "computer-readable medium" can be any device that can contain, store, communicate, propagate or transmit a program for use by an instruction execution system, device or apparatus, or in combination with these instruction execution systems, devices or apparatuses. More specific examples of computer-readable media (a non-exhaustive list) include the following: an electrical connection with one or more wires (electronic device), a portable computer disk box (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disk read-only memory (CDROM). In addition, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing in other suitable ways if necessary, and then stored in a computer memory.

[0124] It should be understood that the various parts of the present application can be implemented by hardware, software, firmware or a combination thereof. In the above-mentioned embodiments, multiple steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, it can be implemented by any one of the following technologies known in the art or their combination: a discrete logic circuit having a logic gate circuit for implementing a logic function for a data signal, a dedicated integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0125] A person skilled in the art may understand that all or part of the steps in the method for implementing the above-mentioned embodiment may be completed by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiment.

[0126] In addition, each functional unit in each embodiment of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into one module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0127] The storage medium mentioned above may be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application. A person of ordinary skill in the art may change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A method for protecting inter-domain routing traffic propagation based on RPKI encryption objects, characterized in that: include: When receiving a routing announcement sent by other routing entities on the routing path, the first routing entity queries the RPKI repository to verify whether the routing announcement is authorized; After confirming the authorization, the router of the first routing entity generates a first encrypted object and signs a certificate; After generating the first encrypted object, the router of the first routing entity generates a second encrypted object generated in the routing propagation process and includes a second encrypted object generated by each routing entity and a second encrypted object list; Notifying the second encrypted object list to all routing entities on the routing path, including the routing entity that sends the routing announcement; After receiving the second encrypted object list, the routers of all routing entities obtain the first encrypted object to verify whether the received second encrypted object list is authorized; After the authorization is determined, the routing traffic propagation of the first routing entity is approved.

2. The method for protecting inter-domain routing traffic propagation based on RPKI encryption objects according to claim 1, characterized in that: When receiving a routing announcement sent by other routing entities on the routing path, the first routing entity queries the RPKI repository to verify whether the routing announcement is authorized; After determining the authorization, the router of the first routing entity generates a first encrypted object and signs a certificate, including: When the first routing entity receives a routing advertisement BGP-UPDATE sent by a second routing entity from its neighbor, obtaining from the RPKI repository a second encrypted object generated by all routing entities on the routing path involved in the BGP-UPDATE message; Verify all second encryption objects to verify whether the current BGP-UPDATE message information is authorized; If the verification is successful, the router of the first routing entity generates a first encrypted object and places it in the repository of the RPKI; If the verification fails, the route filtering operation is not performed and the received second encrypted object list is discarded.

3. The method for protecting inter-domain routing traffic propagation based on RPKI encryption objects according to claim 2, characterized in that: After generating the first encrypted object, the router of the first routing entity generates a second encrypted object list generated during the routing propagation process and including the second encrypted object generated by each routing entity, including: The router of the first routing entity generates the first encrypted object and stores it in the RPKI repository; The router of the first routing entity packages the IDs of all second encrypted objects generated by the routing entity related to this routing announcement BGP-UPDATE message, and attaches an identifier that uniquely identifies the first encrypted object to obtain the second encrypted object list.

4. The method for protecting inter-domain routing traffic propagation based on RPKI encryption objects according to claim 1, characterized in that: After receiving the second encryption object list, the routers of all routing entities obtain the first encryption object certificate to verify whether the received second encryption object list is authorized; Determining that the routing traffic propagation of the first routing entity is approved after the authorization includes: After receiving the notification message of the second encryption object list, any routing entity obtains the first encryption object; Using a public key to perform signature verification on the first encrypted object to verify whether the notification message of the second encrypted object list is authorized; If the verification is successful, the router of the routing entity that receives the notification message of the second encrypted object list modifies the routing filtering information, recognizes the routing propagation traffic in the routing announcement BGP-UPDATE message sent from the first routing entity, and performs traffic filtering; If the verification fails, the routing entity discards the received second encryption object list message without additional processing.

5. The method for protecting inter-domain routing traffic propagation based on RPKI encryption objects according to claim 1, characterized in that: The remaining routing entities not on the routing path periodically obtain the first encrypted object from the RPKI repository and use the public key to verify the signature of the first encrypted object. If the verification passes, add or modify the traffic filtering policy to collaboratively filter the traffic forwarded from the router of the first routing entity that should not pass through this routing entity.

6. The method for protecting inter-domain routing traffic propagation based on RPKI encryption objects according to claim 1, characterized in that: The router of each routing entity on the routing path will generate its own first encrypted object and verify the existing first encrypted objects generated by the routers of other routing entities to avoid routing path tampering hijacking attacks.

7. The method for protecting inter-domain routing traffic propagation based on RPKI encryption objects according to claim 1, characterized in that: The notification message of the second encrypted object list is only sent to the routing entity on the routing announcement BGP-UPDATE path to avoid routing leakage.

8. An inter-domain routing traffic propagation protection device based on RPKI encryption objects, characterized in that: include: A first encrypted object signing module, configured to query the RPKI repository when the first routing entity receives a routing announcement sent by other routing entities on the routing path to verify whether the routing announcement is authorized; after determining the authorization, the router of the first routing entity generates a first encrypted object and signs a certificate; A second encryption object list generating module, configured to generate, after generating the first encryption object, a second encryption object list generated by a router of the first routing entity in a routing propagation process and including the second encryption object generated by each routing entity; A second encryption object list notification module, used for notifying the second encryption object list to all routing entities on the routing path including the routing entity that sends the routing announcement; A filtering protection module, configured to obtain the first encrypted object certificate after the routers of all routing entities receive the second encrypted object list, so as to verify whether the received second encrypted object list is authorized; After the authorization is determined, the routing traffic propagation of the first routing entity is approved.

9. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.

Images