Inter-domain route traffic propagation protection method and device based on rpki cryptographic object

Abstract

The application discloses an inter-domain routing traffic propagation protection method and device based on an RPKI encryption object, and the method adds a new encryption object Binding Message (BM) in the RPKI, uses the encryption object to synchronize with the RPKI repository, checks and filters the traffic of the inter-domain router, and discards the problematic traffic, so that prefix hijacking protection of the autonomous inter-domain routing and protection of the AS_PATH path attribute in the BGP-UPDATE message are achieved, and the route leak attack is partially solved. Through the application, the path verification function which has not been realized by the current RPKI can be effectively realized, the problems existing in the BGP Sec are made up, and the BGP routing security is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer network information security, and in particular to an inter-domain route traffic propagation protection method and device based on an RPKI encryption object, an electronic device, and a storage medium. BACKGROUND

[0002] The BGP protocol, which stands for Border Gateway Protocol, is an inter-AS dynamic routing protocol currently used in the Internet, which is used to automatically exchange IP routing information and reachability information between different ASes, and the main function is to control inter-domain route propagation and select the optimal route.

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

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

[0005] To this end, a first object of the present application is to provide an inter-domain route traffic propagation protection method based on an RPKI encryption object, which aims to overcome the problems in the prior art by adding new certificates to the RPKI system to solve the security problems of inter-domain route prefix hijacking, route path tampering, and route leakage.

[0006] A second object of the present application is to provide an inter-domain route traffic propagation protection device based on an RPKI encryption object.

[0007] A third object of the present application is to provide an electronic device.

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

[0009] To achieve the above objects, an inter-domain route traffic propagation protection method based on an RPKI encryption object according to a first aspect of the present application comprises:

[0010] The first routing entity verifies whether the route announcement is authorized by querying the RPKI repository upon receiving the route announcement sent by other routing entities on the route path; after determining the authorization, the router of the first routing entity generates a first encryption object and signs a certificate;

[0011] After generating the first encryption object, the router of the first routing entity generates a second encryption object list generated in the route propagation process, which contains the second encryption object generated by each routing entity;

[0012] The second encryption object list is announced to all routing entities on the route path, including the routing entity sending the route announcement;

[0013] After receiving the second encryption object list, the router of all routing entities obtains the first encryption object to verify whether the received second encryption object list is authorized; after determining the authorization, the router of the first routing entity acknowledges the route traffic propagation.

[0014] The first routing entity verifies whether the route announcement is authorized by querying the RPKI repository upon receiving the route announcement sent by other routing entities on the route path; 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 route announcement BGP-UPDATE sent by a second routing entity which is a neighbor of the first routing entity, the first routing entity obtains the second encryption object generated by all routing entities on the route path involved in the BGP-UPDATE message from the RPKI repository;

[0016] All second encryption objects are verified to verify whether the current BGP-UPDATE message information is authorized;

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

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

[0019] After generating the first encryption object, the router of the first routing entity generates a second encryption object list generated in the route propagation process, which contains the second encryption object generated by each routing entity, including:

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

[0021] The router of the first routing entity packs the IDs of all second encryption objects generated by the routing entity related to the route announcement BGP-UPDATE message, and inserts an identifier uniquely identifying the first encryption object into the second encryption object list to obtain a second encryption object list.

[0022] The router of the first routing entity packs the IDs of all second encryption objects generated by the routing entity related to the route announcement BGP-UPDATE message, and inserts an identifier uniquely identifying the first encryption object into the second encryption object list to obtain a second encryption object list.

[0023] The router of the first routing entity packs the IDs of all second encryption objects generated by the routing entity related to the route announcement BGP-UPDATE message, and inserts an identifier uniquely identifying the first encryption object into the second encryption object list to obtain a second encryption object list.

[0024] The router of the first routing entity packs the IDs of all second encryption objects generated by the routing entity related to the route announcement BGP-UPDATE message, and inserts an identifier uniquely identifying the first encryption object into the second encryption object list to obtain a second encryption object list.

[0025] If the verification is passed, the router of the routing entity receiving the announcement message of the second encryption object list modifies the routing filtering information, approves the routing propagation traffic in the route announcement BGP-UPDATE message sent from the first routing entity, and performs traffic filtering.

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

[0027] The remaining routing entities on the non-routing path periodically obtain the first encryption object from the RPKE repository, and perform signature verification on the first encryption object using the public key, and if the verification is passed, add or modify the traffic filtering strategy, and cooperatively filter the traffic forwarded from the router of the first routing entity, which should not pass through the routing entity.

[0028] Each router of the routing entity on the routing path generates its own first encryption object, and verifies the existing first encryption object generated by the router of the other routing entity, to avoid routing path tampering and hijacking attacks.

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

[0030] To achieve the above purpose, a second aspect of the embodiment of the application provides a domain inter-routing traffic propagation protection device based on an RPKE encryption object, which comprises:

[0031] The first encryption object signing module is configured to, when the first routing entity receives a route announcement sent by another routing entity on a routing path, verify whether the route announcement is authorized by querying an RPKI repository; and after determining that the route announcement is authorized, a router of the first routing entity generates a first encryption object and signs a certificate;

[0032] The second encryption object list generating module is configured to, after the first encryption object is generated, a router of the first routing entity generates a second encryption object list containing a second encryption object generated by each routing entity in a route propagation process;

[0033] The second encryption object list announcing module is configured to announce the second encryption object list to all routing entities on the routing path, including the routing entity sending the route announcement;

[0034] The filtering protection module is configured to, after the router of each routing entity receives the second encryption object list, acquire the first encryption object certificate to verify whether the received second encryption object list is authorized; and after determining that the second encryption object list is authorized, the router of the first routing entity is approved to propagate the routing traffic.

[0035] To achieve the above object, the third aspect of the embodiment of the application provides an electronic device, comprising: a processor, and a memory connected with the processor in communication;

[0036] The memory stores computer execution instructions;

[0037] The processor executes the computer execution instructions stored in the memory to implement the method of the foregoing technical solution.

[0038] To achieve the above object, the fourth aspect of the embodiment of the application provides a computer readable storage medium, the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method of the foregoing technical solution.

[0039] Different from the prior art, the method, the device, the electronic device and the storage medium provided by the application add a new encryption object BindingMessage (BM) in the RPKI, synchronize the encryption object with the RPKI repository, check and filter the traffic of the inter-domain router, discard the problematic traffic, realize the prefix hijacking protection of the inter-autonomous domain routing and the protection of the AS_PATH path attribute in the BGP-UPDATE message, and partially solve the routing exposure attack; through the application, the path verification function not yet realized by the current RPKI can be effectively realized, the problems existing in the BGPSec are compensated, and the BGP routing security is ensured.

[0040] Additional aspects and advantages of the application will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following and the attached drawings. BRIEF DESCRIPTION OF DRAWINGS

[0041] Figure 1 is a flowchart of a method for inter-domain route traffic propagation protection based on RPKI encrypted objects provided by the present application.

[0042] Figure 2 is a schematic diagram of BGP route prefix hijacking in a method for inter-domain route traffic propagation protection based on RPKI encrypted objects provided by the present application.

[0043] Figure 3 is a schematic diagram of BGP route path tampering in a method for inter-domain route traffic propagation protection based on RPKI encrypted objects provided by the present application.

[0044] Figure 4 is a schematic diagram of BGP route exposure attack in a method for inter-domain route traffic propagation protection based on RPKI encrypted objects provided by the present application.

[0045] Figure 5 is a schematic diagram of eContent content of BM encrypted object in a method for inter-domain route traffic propagation protection based on RPKI encrypted objects provided by the present application.

[0046] Figure 6 is a schematic diagram of content of FCList in a method for inter-domain route traffic propagation protection based on RPKI encrypted objects provided by the present application.

[0047] Figure 7 is a schematic diagram of route UPDATE announcement processing flow of a single BGP router in a method for inter-domain route traffic propagation protection based on RPKI encrypted objects provided by the present application.

[0048] Figure 8 is a schematic diagram of a practical case of a method for inter-domain route traffic propagation protection based on RPKI encrypted objects provided by the present application.

[0049] Figure 9 is a schematic diagram of a structure of a device for inter-domain route traffic propagation protection based on RPKI encrypted objects provided by the present application. DETAILED DESCRIPTION

[0050] Embodiments of the present application are described in detail below with reference to the attached drawings, which are incorporated in and constitute a part of this specification. The embodiments described below are illustrative of the present application and are not intended to be limiting. Throughout the drawings, the same or like reference numerals can refer to the same or like parts throughout the drawings.

[0051] A method and device for inter-domain route traffic propagation protection based on RPKI encryption objects are described below with reference to the accompanying drawings.

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

[0053] S101: When receiving a route announcement sent by other route entities on a route path, the first route entity verifies whether the route announcement is authorized by querying the RPKI repository; after determining the authorization, the router of the first route entity generates a first encryption object and signs a certificate.

[0054] When the first route entity receives a route announcement BGP-UPDATE sent by a second route entity which is a neighbor, the first route entity acquires second encryption objects generated by all route entities involved in the BGP-UPDATE message from the RPKI repository;

[0055] All second encryption objects are verified to verify whether the current BGP-UPDATE message information is authorized;

[0056] If the verification is passed, the router of the first route entity applies the first encryption object and places it into the repository of the RPKI;

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

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

[0059] When AS1 as the first routing entity receives BGP-UPDATE from its neighbor, the second routing entity AS2, it queries the encrypted object generated by all ASs on the AS-PATH from the RPKI repository, i.e. FC encrypted object, and verifies the signature of the certificate of the FC encrypted object using the public key therein to verify whether the current BGP-UPDATE message information is authorized; if the verification is passed, the router R1 of AS1 generates a BM encrypted object, the certificate of the BM encrypted object is self-signed by R1, the BM encrypted object is placed into the repository of RPKI for other RPs to synchronize and download, and the BM certificate is verified by the RP to prove its correctness, and this BM is recorded as BM1; otherwise, no operation is performed and the BGP-UPDATE message is discarded.

[0060] In actual application, the route prefix hijacking attack is as shown in Figure 2 Fig. 3, the router R3 of AS3 receives two announcements for the same route prefix, and AS4 is selected as the best route according to the BGP routing rule because the route prefix announced by AS4 is longer, and the hijacking is successful.

[0061] The route path tampering attack is as shown in Figure 3 Fig. 4, the router R3 of AS3 receives two announcements for the same route prefix, and AS4 is selected as the best route according to the BGP routing rule because the AS_PATH path announced by AS4 is shorter, and the hijacking is successful.

[0062] The route leakage attack is as shown in Figure 4 Fig. 5, which is an example of route leakage. The relationship between ASs is Provider-Customer (P2C), Peer-Peer (P2P), and Sibling-Sibling (S2S). The principle that needs to be followed in configuring the route announcement rule is:

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

[0064] Announce to a Customer: when a Provider announces route information to its Customer, the AS as the Provider can announce its own route and the route of its Customer, and can also output the route obtained from other Providers or Peers.

[0065] Announce to a Peer: When exchanging routing information with a Peer, one can announce its own routes and the routes of its Customers, but not the routes obtained from other Providers or Peers.

[0066] The routing policy between ASs needs to follow the No-Valley criteria, which can estimate the direction of routing information exchange between Provider-Customer and Peer-Peer relationships:

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

[0068] Criteria 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] Criteria 3: A P2C connection cannot be followed by a P2P connection.

[0070] Criteria 4: A P2P connection cannot be followed by a C2P connection, but only by a P2C or S2S connection.

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

[0072] AS announces to other Providers a route received from a Provider; (P2C followed by C2P).

[0073] AS announces to other Peers a route received from a Peer; (P2P followed by P2P).

[0074] AS announces to its Peers a route received from a Provider; (P2C followed by P2P).

[0075] AS announces to its Providers a route received from a Peer; (P2P followed by C2P).

[0076] RPKI is the abbreviation of Resource Public Key Infrastructure. RPKI is a resource public key infrastructure built around the rights to use Internet digital resources, including IP and ASN. The purpose of RPKI is to make Internet routing more secure, and RPKI mainly includes three parts: public key infrastructure, cryptographic signed object and distributed repository. RPKI allows the holder of Internet digital resources to make verifiable statements about how they use their resources. To achieve this, it uses a public key infrastructure that creates a resource certificate chain, which is structured in the same way as the delivery of IP addresses and numbers. The current RPKI is used for the legitimate owner of an IP address block to make an authentication statement that explains which AS the IP prefix in BGP belongs to. The authentication statement is called Route Origin Authorization (ROA), which contains a prefix, a maximum prefix length and a source AS number, which is used to authorize the source AS to announce the IP address prefix. Then, other network operators can download and verify these statements from the distributed repository of RPKI and make routing decisions based on this, which is called Route Origin Validation (ROV).

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

[0078] The BM encryption object designed by the application follows the encryption object template designed by RFC 6488, wherein the content of eContent of the BM encryption object is as shown in the following formula I: Figure 5 Wherein, asidS is the number of the AS generating the BM; prefixS is a set of address prefixes that can be reached by the AS according to its local routing policy; prefixD is a certain prefix in BGP-UPDATE; BMID is the unique identifier of the BM, which is used to uniquely identify a BM encryption object in RPKI, and is a HASH result, and the HASH content is AS-PATH in BGP-UPDATE, the number of the AS, and the prefixD field.

[0079] The content of the FCList of the application is as shown in the following formula II: Figure 6 Wherein, the field explanations are as follows:

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

[0081] FCIDs: IDs of all FC encryption objects packed, FCID is the unique identification of FC, used to uniquely locate a FC encryption object in RPKI.

[0082] The processing flow of the present application on a single BGP router is shown in Figure 7 If the router is the router of the source prefix belonging AS, i.e. belongs to the starting AS of the route prefix, then the router does not need to perform the operations in the figure, i.e. does not need to wait to receive the BGP-UPDATE message information, does not need to obtain the BM encryption object from the RPKI repository, does not need to verify the BM encryption object, does not need to generate the BM encryption object and FCList.

[0083] In this step, 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 when receiving the BGP-UPDATE route announcement, and verifies all related FC encryption objects. The signature information in the FC encryption object is verified using the carried public key information, and if the verification is passed, it indicates that the route announcement is not hijacked, and the next step can be continued; otherwise, it indicates that the route announcement has a problem, and the message needs to be discarded.

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

[0085] In the embodiment of the present application, the 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 packs the IDs of all second encryption objects generated by the routing entities related to the current route announcement BGP-UPDATE message, and attaches an identifier uniquely identifying the first encryption object therein to obtain a second encryption object list.

[0087] S103: Announce the second encryption object list to all routing entities on the route path including the routing entity sending the route announcement.

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

[0089] S104: After the router of all routing entities receives the second encrypted object list, the first encrypted object is obtained 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 recognized.

[0090] Any routing entity obtains the first encrypted object after receiving the announcement message of the second encrypted object list;

[0091] The first encrypted object is verified by using the public key to verify whether the announcement message of the second encrypted object list is authorized;

[0092] If the verification is passed, the router of the routing entity receiving the announcement 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 is not passed, the routing entity discards the received second encrypted object list message without additional processing.

[0094] Specifically, after the router R2 of AS2 receives the FCList announcement message, the BM encrypted object BM1 is first obtained from the RP, and the certificate therein is verified by using the public key therein to verify whether the current FCList announcement message is authorized; if the verification is passed, the R2 modifies the routing filtering information, recognizes the traffic from R1 to the prefixes announced in the current BGP-UPDATE; otherwise, the message is discarded, and the above-mentioned traffic forwarded from R1 is filtered.

[0095] In other embodiments of the application, for the remaining routing entities on the non-routing path, the first encrypted object is periodically obtained from the RPKI repository, and the first encrypted object is verified by using the public key, if the verification is passed, the traffic filtering strategy is added or modified, and the traffic forwarded from the router of the first routing entity, which should not pass through the routing entity, is cooperatively filtered.

[0096] The router on the subsequent BGP-UPDATE forwarding path needs to operate the BGP-UPDATE message according to the foregoing steps and generate the BM encrypted object and the FCList, and each AS on the BGP-UPDATE path needs to receive the FCList sent by all the AS behind it, i.e., the AS on the subsequent routing path of the routing announcement of the current AS.

[0097] After the BGP routing converges, all ASs filter the traffic according to the established routing filtering table, so that the protection of the BGP inter-domain routing traffic propagation and the routing leak detection can be realized.

[0098] In addition, the router of each routing entity on the routing path generates a first encryption object of itself, and verifies the first encryption object generated by the router of other routing entities, to avoid a routing path tampering hijacking attack.

[0099] For a legacy router that is not upgraded, only the existing BM needs to be verified and a new BM does not need to be generated.

[0100] The public and private keys for generating the BM encryption object can use the public and private keys of the BGPSec router, and details can be referred to RFC 8209, which will not be repeated here.

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

[0102] Specifically, the example topology of the BGP-UPDATE announcement adopted by the present application is as shown in Figure 8 The subsequent embodiments and their explanations are all made with reference to Figure 8 The present example simplifies the operation within the AS, because although there can be multiple BGP routers within an AS, they actually play the same role and do not need more operations, so they can be simplified. The BGP router R1 of AS1 has announced a route to its neighbor BGP router R2 of AS2, and the BGP router R2 of AS2 has propagated this route announcement to AS3. It is assumed 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 and BM3, and put the encryption objects into the RPKI repository. Taking BM3 as an example, the route 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 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 application needs the RP to obtain the BM encryption object list from the RPKI repository. This can be divided into online processing and offline processing. Online processing is that the BGP router receives the FCList message and immediately obtains the relevant BM encryption object list from the RPKI repository and verifies 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 item, and then audits when the RP synchronizes the relevant BM encryption object from the repository of the Trust Anchor of the RPKI, and eliminates the illegal routing table item. This method has relatively low delay requirements and basically does not affect the routing convergence speed of the BGP router. Regardless of the method, the BGP router needs to obtain all the FCs from the FCList message and verify them to infer the current AS_PATH information. If the verification is passed, the routing filter table item is modified or added; otherwise, the FCList message is discarded.

[0105] All autonomous systems deploying the application need to synchronize BM encryption objects from the RPKI repository regularly, and update the routing filter table item according to the content of the BM encryption object to perform path-outside collaborative filtering.

[0106] The BGP router R2 of AS2 receives the inter-domain routing traffic of the prefix 192.0.2.0 / 24 sent by R3, R2 allows the traffic to pass and forwards it to R1; if R4 (the router of the node not on the AS-PATH) receives the inter-domain routing traffic of the prefix 192.0.2.0 / 24 from R3, it will be discarded.

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

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

[0109] As shown in Figure 9 , the device 300 includes:

[0110] The first encryption object signing module 310 is configured to, when the first routing entity receives the routing announcement sent by the other routing entity on the routing path, verify whether the routing announcement is authorized by querying the RPKI repository; after authorization is determined, the router of the first routing entity generates a first encryption object and signs a certificate;

[0111] The second encryption object list generation module 320 is configured to generate a second encryption object list containing the second encryption object generated by each routing entity in the route propagation process generated by the router of the first routing entity after the first encryption object is generated.

[0112] The second encryption object list announcement module 330 is configured to announce the second encryption object list to all routing entities on the routing path including the routing entity sending the route announcement.

[0113] The filtering protection module 340 is configured to obtain the first encryption object certificate after the router of each routing entity receives the second encryption object list, to verify whether the received second encryption object list is authorized, and to authorize the routing traffic propagation of the first routing entity after the authorization is determined.

[0114] To achieve the above-mentioned embodiments, the present application further provides an electronic device, comprising a processor and a memory connected with the processor in communication; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to realize the method provided by the foregoing embodiments.

[0115] To achieve the above-mentioned embodiments, the present application further provides a computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to realize the method provided by the foregoing embodiments.

[0116] To achieve the above-mentioned embodiments, the present application further provides a computer program product, comprising a computer program, which is executed by the processor to realize the method provided by the foregoing embodiments.

[0117] The collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in the present application comply with relevant laws and regulations and do not violate public order and good customs.

[0118] It should be noted that the personal information from the user should be collected for legal and reasonable purposes, and should not be shared or sold outside these legal uses. In addition, such collection / sharing should be carried out after the user's informed consent is received, including but not limited to informing the user to read the user agreement / user notice before the user uses the function, and signing the agreement / authorization including authorization of relevant user information. In addition, any necessary steps should be taken to protect and ensure access to such personal information data, and to ensure that other people with access to personal information data comply with their privacy policy and processes.

[0119] The present application contemplates an implementation that provides users with the ability to selectively opt in or opt out of permitting the collection and / or use of their personal information data. That is, the present disclosure contemplates providing users with the ability to prevent or limit the collection and / or use of their personal information data. For example, the present disclosure contemplates providing users with the ability to prevent or limit the collection and / or use of their personal information data by, for example, blocking or deleting cookies. In addition, the present disclosure contemplates providing users with the ability to determine whether and how to interact with the present disclosure by, for example, blocking web beacons. Further, the present disclosure contemplates providing users with the ability to access and / or edit their personal information data when such data is collected by the present disclosure. In addition, the present disclosure contemplates that the collection and / or use of personal information data can be limited to only those users who expressly consent or give permission to the collection and / or use of their personal information data.

[0120] In the foregoing detailed description, the description used with respect to the terms "one embodiment", "some embodiments”, "an example”, "a specific example” or "some examples” etc. means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. Illustrative appearances of the above terms are not necessarily referred to the same embodiment or example throughout the description. Moreover, the particular features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples. Furthermore, in non-contradictory cases, those skilled in the art can combine and combine the features described in different embodiments or examples and the features of different embodiments or examples in the present application.

[0121] In addition, the terms "first", "second", etc. are used only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the technical features indicated. Therefore, the features defined with "first", "second" can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "a plurality of" is at least two, for example, two, three, etc., unless otherwise explicitly specified.

[0122] Any process or method descriptions or descriptions of processes or methods described in flow diagrams or otherwise described herein can be understood as representing code modules, segments, or portions of code that include one or more executable instructions for implementing specific logic functions (or steps) in the process, and that the various embodiments of the present application can include additional or fewer steps, perform the functions in a different order, or omit functions, and that these descriptions are not limited to the precise processes described but include alternatives and modifications thereof as would be known to one of ordinary skill in the art.

[0123] The logic and / or steps represented in the flowcharts and / or described herein, for example, can be considered as a sequence of executable instructions stored in a computer readable medium, which can be executed by an instruction execution system, apparatus or device, such as a computer-based system, a processor-based system, or other system that can fetch the instructions from the instruction execution system, apparatus or device and execute the instructions, or a combination thereof. For the purposes of this specification, a "computer readable medium" can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus or device. The computer readable medium can specifically be, but is not limited to, the following: an electronic connection (electronic apparatus) having one or more wires, a portable computer diskette (magnetic apparatus), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, and a portable compact disk read-only memory (CDROM). In addition, the computer readable medium can even be paper or other suitable medium upon which the program can be printed, because the program can be electronically obtained, for example, by optically scanning the paper or other medium, then

[0124] It should be understood that portions of the application can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. As such, if implemented in hardware, and in another embodiment, any of the following technologies, known in the art, or a combination thereof, can be used: discrete logic circuitry having logic gates for implementing logic functions on data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), and the like.

[0125] Those of ordinary skill in the art can understand that all or part of the steps carried out by the above-mentioned embodiment methods can be completed by programs instructing relevant hardware, and the programs can be stored in a computer readable storage medium. When the programs are executed, they include one of the steps of the method embodiments or a combination thereof.

[0126] In addition, each of the functional units in the various embodiments of the present application can be integrated in one processing module, or each of the units can be physically present separately, or two or more units can be integrated in one module. The integrated module can be implemented in the form of hardware or in the form of a software functional module. When the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer readable storage medium.

[0127] The storage medium mentioned above can 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 should be understood that the above embodiments are exemplary and should not be construed as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above embodiments within the scope of the present application.

Claims

1. A method for inter-domain route traffic propagation protection based on RPKI cryptographic objects, characterized in that, The application comprises: When a first routing entity receives a routing announcement sent by other routing entities on a routing path, the first routing entity verifies whether the routing announcement is authorized by querying an RPKI repository; After authorization is determined, a router of the first routing entity generates a first encryption object and signs a certificate; After the first encryption object is generated, the router of the first routing entity generates a second encryption object list generated in a routing propagation process and containing a second encryption object generated by each routing entity; The second encryption object list is announced to all routing entities on the routing path, including routing entities sending the routing announcement; After the router of all routing entities receives the second encryption object list, the first encryption object is obtained to verify whether the received second encryption object list is authorized; After authorization is determined, the routing traffic propagation of the first routing entity is recognized.

2. The method for inter-domain route traffic propagation protection based on RPKI cryptographic object according to claim 1, characterized in that, When a first routing entity receives a routing announcement sent by other routing entities on a routing path, the first routing entity verifies whether the routing announcement is authorized by querying an RPKI repository; After authorization is determined, a router of the first routing entity generates a first encryption object and signs a certificate, comprising: When the first routing entity receives a routing announcement BGP-UPDATE sent by a second routing entity which is a neighbor of the first routing entity, second encryption objects generated by all routing entities on a routing path involved in the BGP-UPDATE message are obtained from an RPKI repository; All second encryption objects are verified to verify whether the current BGP-UPDATE message information is authorized; If the verification is passed, the router of the first routing entity generates a first encryption object and places the first encryption object in the RPKI repository; If the verification is not passed, no routing filtering operation is performed, and the received second encryption object list is discarded.

3. The method of claim 2, wherein the RPKI cryptographic object is a Route Origin Validation (ROV) object. After the first encryption object is generated, the router of the first routing entity generates a second encryption object list generated in a routing propagation process and containing a second encryption object generated by each routing entity, comprising: The router of the first routing entity generates the first encryption object and stores the first encryption object in the RPKI repository; The router of the first routing entity packs IDs of all second encryption objects generated by routing entities related to the routing announcement BGP-UPDATE message, and attaches an identifier uniquely identifying the first encryption object in the IDs to obtain the second encryption object list.

4. The method of claim 1, wherein the RPKI cryptographic object is a Route Origin Validation (ROV) object. After the router of all routing entities receives the second encryption object list, the first encryption object certificate is obtained to verify whether the received second encryption object list is authorized; After authorization is determined, the routing traffic propagation of the first routing entity is recognized, comprising: After any routing entity receives an announcement message of the second encryption object list, the first encryption object is obtained; The first encryption object is signed and verified using a public key to verify whether the announcement message of the second encryption object list is authorized; If the verification is passed, the router of the route entity receiving the announcement message of the second encryption object list modifies the route filtering information, acknowledges the route propagation traffic in the route announcement BGP-UPDATE message sent from the first route entity, and performs traffic filtering; If the verification is not passed, the route entity discards the received second encryption object list message without additional processing.

5. The method of claim 1, wherein the RPKI cryptographic object is a Route Origin Validation (ROV) object. The remaining route entities other than the route path periodically obtain the first encryption object from the RPKI repository, and perform signature verification on the first encryption object using the public key. If the verification is passed, the traffic filtering strategy is added or modified, and the traffic forwarded by the router of the first route entity and not supposed to pass through the route entity is cooperatively filtered.

6. The method of claim 1, wherein the RPKI cryptographic object is a Route Origin Validation (ROV) object. The router of each route entity on the route path generates its own first encryption object, and verifies the existing first encryption objects generated by the routers of other route entities, to avoid route path tampering and hijacking attacks.

7. The method of claim 1, wherein the RPKI cryptographic object is a Route Origin Validation (ROV) object. The announcement message of the second encryption object list is only sent to the route entities on the route announcement BGP-UPDATE path, to avoid route leakage.

8. An apparatus for inter-domain route traffic propagation protection based on RPKI cryptographic objects, characterized by, The method comprises the following steps: A first encryption object signing module is configured to, when the first route entity receives a route announcement sent by other route entities on the route path, verify whether the route announcement is authorized by querying the RPKI repository; after authorization is determined, the router of the first route entity generates a first encryption object and signs a certificate; A second encryption object list generating module is configured to, after the first encryption object is generated, the router of the first route entity generates a second encryption object list containing a second encryption object generated by each route entity in the route propagation process; A second encryption object list announcement module is configured to announce the second encryption object list to all route entities on the route path, including the route entities sending the route announcement; A filtering protection module is configured to, after the router of all route entities receives the second encryption object list, obtain the first encryption object certificate to verify whether the received second encryption object list is authorized; After authorization is determined, the route traffic of the first route entity is acknowledged.

9. An electronic device, comprising: The method comprises the following steps: A processor and a memory connected in communication with the processor; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory to implement the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method according to any one of claims 1-7.

Images