False source address traffic verification method in intra-domain policy routing scene

Abstract

The invention provides a forged source address traffic verification method in an intra-domain policy routing scene, and the method comprises the steps: generating an initial SPD message according to a policy routing rule and a forwarding table of an intra-domain initial router; according to the priority sequence of each policy routing rule of the initial router, generating a corresponding SPD message sent to a next-hop routing node according to each policy routing rule and the initial SPD message of the round in sequence, and updating the initial SPD message of the round; constructing a flow verification table according to a filtering rule in the received SPD message, and continuing to propagate the newly generated SPD message to the next-hop routing node based on the propagation range of the SPD message until the propagation range becomes null; and verifying the ingress flow in each routing node according to the source prefix and the destination prefix in the flow verification table. According to the method, the forged source address traffic can be filtered more effectively and comprehensively under the scene that policy routing is deployed in the intra-domain router.

Description

Technical Field

[0001] The present application relates to the field of network communication security technologies, and particularly relates to a method for verifying forged source address traffic in an intra-domain policy routing scenario. Background Art

[0002] In recent years, distributed denial of service attacks (DDoS) mainly characterized by forging the source address of Internet Protocol (IP) addresses have caused serious damage to Internet network security. Such attacks control multiple machines located at different positions and use these machines to send a large amount of false traffic with randomly forged IP source addresses to attack the attacked party, consuming a large amount of network bandwidth or system resources of the attacked party's server, thus paralyzing and stopping providing normal services, and greatly affecting the availability of the Internet.

[0003] To avoid such attacks, source address verification technologies are usually adopted to check the authenticity of the IP source addresses of Internet traffic and prevent forged source address traffic from passing through the network. In related technologies, current intra-domain source address verification technology solutions usually perform source address verification based on manually configured rules or forwarding information bases (FIBs).

[0004] However, in the above verification methods in related technologies, the considered factors are relatively single, and the impacts of various factors in actual operation on the packet forwarding path are not fully considered. Therefore, some forged packets will be missed in filtering, and the verification accuracy does not meet the actual application requirements. Summary of the Invention

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

[0006] To this end, the first object of the present application is to propose a method for verifying forged source address traffic in an intra-domain policy routing scenario, which can more effectively and comprehensively filter forged source address traffic in a scenario where policy routing is deployed in an intra-domain router.

[0007] The second object of the present application is to propose a system for verifying forged source address traffic in an intra-domain policy routing scenario; The third object of the present application is to propose a non-transitory computer-readable storage medium.

[0008] To achieve the above object, an embodiment of the first aspect of the present application lies in proposing a method for verifying forged source address traffic in an intra-domain policy routing scenario, the method including the following steps: Generate an initial Security Policy Database (SPD) message for discovering the true forwarding path according to the policy routing rules and forwarding information base of the intra-domain initial router, where the SPD message includes a propagation range and a filtering rule, and the filtering rule includes a source prefix and a destination prefix; According to the priority order of each policy routing rule of the initial router, generate the corresponding SPD message sent to the next-hop routing node based on each policy routing rule and the initial SPD message of this round in sequence, and update the initial SPD message of this round; Control each next-hop routing node to construct a traffic verification table according to the filtering rules in the received SPD message, and based on the propagation range of the received SPD message, continue to propagate the newly generated SPD message to the subsequent next-hop routing nodes in the same way as the initial router generates the SPD message until the propagation range becomes empty; Verify the incoming traffic in each routing node according to the source prefix and destination prefix in the locally constructed traffic verification table.

[0009] Optionally, in an embodiment of the present application, before generating the initial SPD message for discovering the true forwarding path, it further includes: taking the forwarding table in each routing node as the policy routing rule with the lowest priority and arranging it after the preset policy routing rules; the generating of the initial SPD message for discovering the true forwarding path includes: taking all the destination prefixes in the policy routing rules and the forwarding table of the initial router as the propagation range of the initial SPD message; setting the filtering rule of the initial SPD message to allow all packets from all source prefixes to all destination prefixes of the initial router to pass the verification.

[0010] Optionally, in an embodiment of the present application, the generating of the corresponding SPD message sent to the next-hop routing node based on each policy routing rule and the initial SPD message of this round in sequence includes: determining the type of each policy routing rule according to whether each policy routing rule limits the source prefix, destination prefix and other elements; and determining the generating methods of the filtering rule and the propagation range in the SPD message sent to the next-hop routing node according to the type of each policy routing rule.

[0011] Optionally, in an embodiment of the present application, the generating method of the filtering rule of the SPD message sent to the next-hop routing node includes: calculating the intersection of the current policy routing rule and the filtering rule of the initial SPD message of this round, and being consistent with the filtering rule of the initial SPD message of this round; the generating method of the propagation range of the SPD message sent to the next-hop routing node includes: taking the destination prefix of the current policy routing rule as the propagation range of the SPD message sent to the next-hop routing node, and being consistent with the propagation range of the initial SPD message of this round.

[0012] Optionally, in an embodiment of the present application, updating the initial SPD message of this round includes: deleting the filtering rule of the current policy routing rule from the filtering rules of the initial SPD message of this round; or, deleting the destination prefix of the current policy routing rule from the propagation scope of the initial SPD message of this round.

[0013] Optionally, in an embodiment of the present application, based on the propagation scope of the received SPD message, continuing to propagate the newly generated SPD message to the subsequent next-hop routing node in the same manner as the initial router generates the SPD message includes: deleting the local prefix of the current routing node from the propagation scope of the received SPD message, and determining whether the propagation scope of the deleted SPD message is empty; when the propagation scope is not empty, according to the priority order of each policy routing rule of the current routing node, generating an SPD message sent to the subsequent next-hop routing node based on each policy routing rule and the received SPD message in turn, and updating the received SPD message.

[0014] Optionally, in an embodiment of the present application, constructing a traffic verification table according to the filtering rules in the received SPD message includes: when each SPD message is received on the access interface of any router, constructing a corresponding verification item according to the access interface and the source prefix and destination prefix in the filtering rules; after the message propagation is completed, summarizing all the verification items to generate the complete traffic verification table of the router.

[0015] To achieve the above object, a second aspect of the present application further provides a spoofed source address traffic verification system in an intra-domain policy routing scenario, including the following modules: A first generation module, configured to generate an initial SPD message for discovering the real forwarding path according to the policy routing rules and the forwarding table of the intra-domain initial router, where the SPD message includes a propagation scope and a filtering rule, and the filtering rule includes a source prefix and a destination prefix; A second generation module, configured to generate a corresponding SPD message sent to the next-hop routing node according to each policy routing rule and the initial SPD message of this round in turn according to the priority order of each policy routing rule of the initial router, and update the initial SPD message of this round; A construction module, configured to control each next-hop routing node to construct a traffic verification table according to the filtering rules in the received SPD message, and based on the propagation scope of the received SPD message, continue to propagate the newly generated SPD message to the subsequent next-hop routing node in the same manner as the initial router generates the SPD message until the propagation scope becomes empty; A verification module, configured to verify the incoming traffic at each routing node according to the source prefix and the destination prefix in the traffic verification table locally constructed.

[0016] To implement the above embodiments, an embodiment of the third aspect of the present application further provides a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the method for verifying forged source address traffic in the intra-domain policy routing scenario in the above embodiment of the first aspect is implemented.

[0017] The technical solutions provided by the embodiments of the present application at least bring the following beneficial effects: The present application generates a filtering rule field through the local policy routing rules and forwarding table of the router, and adds a filtering rule field to the SPD message, so that the SPD message contains specific policy routing rule information. Furthermore, each router within the domain can construct a more refined traffic verification table according to the filtering rule field, and verify the incoming traffic from both the source prefix and the destination prefix. Moreover, each router within the domain generates corresponding SPD messages in sequence according to the priority order of the local policy routing rules, and can comprehensively identify all possible forwarding paths from each source prefix to each destination prefix to transmit messages, further improving the comprehensiveness of the constructed traffic verification table. Thus, verifying the packets based on the traffic verification table constructed according to the present application can significantly enhance the filtering and interception ability for forged source address packets, expand the forged source address packets that can be intercepted, and improve the accuracy and comprehensiveness of the verification of forged source address traffic.

[0018] Additional aspects and advantages of the present invention will be given in part in the following description, become apparent in part from the following description, or be learned through the practice of the present invention. Description of the Drawings

[0019] The above and / or additional aspects and advantages of the present application will become apparent and be readily understood from the following description of the embodiments in conjunction with the drawings, where: Figure 1 It is a schematic diagram of a forged packet filtering process in related embodiments; Figure 2 It is a flowchart of a method for verifying forged source address traffic in an intra-domain policy routing scenario proposed by an embodiment of the present application; Figure 3 It is a schematic diagram of an SPD message format proposed by an embodiment of the present application; Figure 4 It is a schematic diagram of the network topology structure of an intra-domain router node proposed by an embodiment of the present application; Figure 5 It is a schematic diagram of the process of generating and sending an SPD message by router A proposed by an embodiment of the present application; Figure 6Schematic diagram of a traffic verification table proposed in an embodiment of this application; Figure 7 Schematic diagram of a router B propagating an SPD message proposed in an embodiment of this application; Figure 8 Schematic diagram of a process of a router C propagating an SPD message proposed in an embodiment of this application; Figure 9 Schematic diagram of a forged packet filtering process proposed in an embodiment of this application; Figure 10 Schematic diagram of the structure of a forged source address traffic verification system in an intra-domain policy routing scenario proposed in an embodiment of this application. Detailed implementation manners

[0020] The embodiments of the present invention will be described in detail below. Examples of the embodiments are shown in the accompanying drawings, where the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to explain the present invention and should not be construed as limiting the present invention.

[0021] To more clearly illustrate the implementation process of the forged source address traffic verification method in the intra-domain policy routing scenario of this application, some terms and related concepts involved in this application will be explained first below.

[0022] Distributed Denial of Service (DDoS for short): It refers to multiple attackers in different locations launching attacks on one or several targets simultaneously, or one attacker controlling multiple machines in different locations and using these machines to simultaneously attack the victim. The main goal of such attacks is to send a large number of malicious packets to consume the performance or network bandwidth of the target server, making the server unable to provide services normally. Since the attack origin points are distributed in different places, it is called a distributed denial of service attack.

[0023] Forwarding Information Base (FIB for short): The forwarding table is stored in the data plane of the router and usually consists of a prefix and a next hop. It is the main basis for route lookup. When a data packet enters the router, the router extracts the destination IP address in the packet header, then uses the forwarding table to find the longest prefix entry that matches this IP address, and then determines the corresponding next hop. According to the found next hop, the data packet is forwarded from the corresponding router interface.

[0024] Policy-Based Routing (PBR): Policy-based routing is a mechanism for routing selection based on policies formulated by users, enabling users to forward packets according to customized policies on the basis of traditional routing forwarding. Policy-based routing usually consists of multiple rules, and each rule contains two parts: a matching policy and a policy action. Compared with the "ordinary routing" based on FIB, the matching policies of policy-based routing are more diverse. In addition to the destination address of the packet, matching policies can also be implemented based on attributes such as the source address of the packet, packet size, protocol type, and link quality. In specific implementations and applications, the priority of policy-based routing is usually higher than that of "ordinary routing". When policy-based routing is not configured, the device forwards packets to the specified next hop according to the FIB table; when policy-based routing is configured, the next-hop interface of the packet is determined according to policy-based routing first; when policy-based routing is configured but none of the rules are matched, the FIB still determines the next-hop interface of the packet. In practical applications, there are various implementation methods for policy-based routing, such as Route Maps, ACL, and IPFilter. The main differences between different implementation methods lie in the syntax and richness of the matching policies. The general configuration steps of policy-based routing usually include the following steps: 1) Configure traffic classification; 2) Configure traffic behavior; 3) Configure traffic policy, that is, configure the required traffic behavior for the specified traffic classification; 4) Apply the traffic policy on the router device interface. Packets arriving at the device interface will be redirected to the specified next-hop address if they meet the traffic classification rules.

[0025] Source address spoofing: In order to communicate normally on the Internet, the sender of a data packet must fill in the real IP address assigned to the sender in the source address field of the packet so that the recipient of the packet can determine to which address the reply packet should be sent. Source address spoofing means that the sender of the packet, for some special purpose, modifies the source address carried in the packet to any IP address that is not its own real IP address. Generally, a router forwards packets only based on the destination IP address of the packet and does not check the legitimacy of the source IP address of the packet. Therefore, packets with spoofed source addresses can also reach the recipient normally. Since it is difficult to trace the real source of packets with spoofed source addresses, source address spoofing has become a common means for attackers to launch network attacks such as DDoS.

[0026] Source address verification: Source address verification technology is an important technical means to solve the problem of source address spoofing. Its basic idea is to build a source address verification table on the router, bind each forwarding interface to a list of legal source address prefixes allowed to enter from that interface. When a data packet enters from a certain router forwarding interface, the source address of the current incoming packet is checked based on the verification table of that router interface, and only packets with legal source addresses are allowed to pass, while the remaining illegal packets are judged as false and filtered out.

[0027] It should be noted that in the relevant embodiments, to construct the source address verification table, a distributed source address verification table generation scheme within the Internet domain can be adopted. This scheme discovers the real data plane forwarding path through hop-by-hop message propagation and helps the routers within the domain generate the source address verification table based on the real forwarding path of the data.

[0028] Among them, the message used to discover the real forwarding path is simply referred to as the SPD message. The SPD message consists of two main fields: the first field is the source router ID, that is, the ID of the router that initially generates this message, and this ID remains unchanged during the message propagation process. The second field is the propagation range. This field contains a series of destination prefixes, indicating that the message needs to be propagated hop by hop to the routers where these destination prefixes are located. The prefixes in the propagation range field usually come from the forwarding table, and this part of the content will be changed hop by hop during the message propagation process.

[0029] Specifically, the basic process of constructing the source address verification table based on the SPD message includes the following steps: First, the router within the domain generates an SPD message packet according to the local forwarding table, and then sends the SPD message to the neighbor router; then the neighbor router generates the source address verification table based on the received SPD message and relays the SPD message to other neighbor routers of its own.

[0030] For example, assume that router interface i receives an SPD message. This router first extracts the source router ID field in the message, and then according to the corresponding relationship between the source prefix and the source router ID saved locally, adds the source prefix corresponding to this ID to the source address verification table as the legal source prefix allowed to enter from interface i.

[0031] It can be understood that in the policy routing scenario in actual applications, the configuration of the policy routing rules enables the data packet to be redirected and forwarded to the next hop specified by the rules, resulting in the actual forwarding path of the packet may be inconsistent with the definition of the forwarding table FIB. In this case, when the router generates and propagates the SPD message, it must synchronously consider the configuration information of the policy routing and propagate the SPD message to the next-hop neighbor router specified in the policy routing rules to ensure that the message can reach the neighbor along the actual forwarding path and guarantee the integrity of the source address verification table.

[0032] However, the method of constructing the source address verification table in the above-mentioned relevant embodiments can achieve that the legal data packets will not be misfiltered in the policy routing scenario, but may cause illegal data packets to be missed filtered. Especially in the scenario where this verification technology is only deployed on some routers within the domain, it will cause data packets with forged source addresses from the undeployed area to illegally enter the router interfaces where this verification technology is deployed and be forwarded, resulting in network attacks.

[0033] For example, such as Figure 1As shown in the figure, assume that the network directly connected to the intra-domain router node (Node) 1 has two network segments, P1 and P2, and the network segment directly connected to the router node 8 is P8. Without configuring policy-based routing, the packets sent from P1 and P2 to P8 are forwarded according to the next hop specified by the FIB of each node, and the complete forwarding path is: Node 1 -> Node 2 -> Node 3 -> Node 4 -> Node 8.

[0034] Assume that a policy-based routing rule is configured on the router node 2, and this rule redirects the packets sent from P1 to P8 to the node 5. Then the forwarding path from P1 to P8 becomes: Node 1 -> Node 2 -> Node 5 -> Node 6 -> Node 7 -> Node 8. Assume that the source address verification mechanism is not deployed on the node 5. To ensure that the packets with the source address belonging to P1 can pass legally through this path, the node 2 needs to send an SPD message to its logical neighbor node 6, and the node 6 will pass the message to the node 7 until it reaches the node 8. In this way, on the source address verification table constructed by the nodes 6, 7, and 8, the packets with any source prefix (P1 or P2) whose source address matches the node 1 are allowed to enter from the interfaces 6.1, 7.1, and 8.2. As a result, the forged packets of P1 and P2 from the node 5 and its upstream undeployed area can also enter through these interfaces after passing through the node 5 without being intercepted. Therefore, there is an obvious false negative (i.e., some forged packets are missed in filtering) in the source address verification method in the related embodiments.

[0035] To solve the problem of missed filtering of illegal data packets in the above-mentioned related embodiments, the present application proposes a method for verifying forged source address traffic in the intra-domain policy-based routing scenario, which is applicable to more effectively and comprehensively filtering the forged source address traffic in the scenario where the intra-domain router deploys the policy-based routing.

[0036] Next, a method and system for verifying forged source address traffic in the intra-domain policy-based routing scenario proposed by the embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0037] Figure 2 It is a flowchart of a method for verifying forged source address traffic in the intra-domain policy-based routing scenario proposed by the embodiments of the present application. As Figure 2 shown, the method includes the following steps: Step S101, generate an initial message for discovering the real forwarding path according to the policy-based routing rule and the forwarding table of the intra-domain initial router, where the message includes the propagation range and the filtering rule, and the filtering rule includes the source prefix and the destination prefix.

[0038] Among them, the initial router is a router node that initially generates a message for discovering the true forwarding path (which can be simply referred to as an SPD message or a message in the embodiments of this application) in a network topology composed of multiple router nodes within a domain. That is, the SPD message is propagated backward from the initial router node to build a verification table at each routing node.

[0039] Specifically, the SPD message generated and propagated in this application carries specific policy routing rule information, so as to build a more refined traffic verification table on each router within the domain subsequently. As an example, the SPD message generated in this application is as Figure 3 shown. Compared with the SPD message generated in the above related embodiments, the embodiment of this application adds a filtering rule field. The filtering rule field consists of factors such as the source prefix and the destination prefix. This field is generated based on the local policy routing rules and FIB table information of the router. The router that receives this SPD message can build a verification table based on the filtering rule field in the message.

[0040] Therefore, this application first generates an initial SPD message according to the policy routing rules and the forwarding table of the initial router, so as to generate an SPD message sent to the next-hop routing node based on this initial SPD message subsequently. Among them, in order to facilitate unified description that each routing node builds a verification table according to the received SPD message, the initial SPD message generated by the initial router can be regarded as the SPD message it receives.

[0041] In an embodiment of this application, generating an initial SPD message for discovering the true forwarding path includes: using all the destination prefixes in the policy routing rules and the forwarding table of the initial router as the propagation range of the initial SPD message; setting the filtering rule of the initial SPD message to allow all packets from all source prefixes to all destination prefixes of the initial router to pass the verification.

[0042] Specifically, in this embodiment, for the convenience of unified processing, the following assumptions are made in advance: for the router node that initially generates the message, it is considered that the propagation range of the SPD message it receives is all the destination prefixes in the policy routing and the FIB table, and the filtering rule is to allow packets from all source prefixes of this node to all possible destination prefixes to pass.

[0043] Step S102, in the order of the priorities of each policy routing rule of the initial router, successively generate a corresponding message sent to the next-hop routing node according to each policy routing rule and the initial message for discovering the true forwarding path in this round, and update the initial message in this round.

[0044] It should be noted that this application accurately identifies the possible forwarding paths from each source prefix to each destination prefix based on both policy routing information and forwarding table information, and transmits messages along these paths. The policy routing rules take effect in sequence. When a rule takes effect, it means that the packets matching this rule cannot be forwarded along the paths specified by subsequent rules. Therefore, when constructing the SPD message in this application, the impact of the rules with higher priorities on the rules with lower priorities should be taken into account, and the SPD messages are generated one by one based on the rule priorities.

[0045] In an embodiment of this application, in order to balance the policy routing rules and the forwarding table and improve the comprehensiveness of the SPD message, the following assumptions are made in this embodiment: The forwarding table in each routing node is regarded as the policy routing rule with the lowest priority and is arranged after the preset policy routing rules.

[0046] Specifically, the FIB entries are regarded as a kind of policy routing rules, which are policy routing rules that only specify the destination prefix and have the lowest priority. If there are preset policy routing rules in the current routing node, the priority of the FIB table is lower than that of the actual policy routing rule PBR.

[0047] When generating the SPD message sent to the next-hop routing node, for each router node where the traffic verification method of this application is deployed, the SPD message can be generated in the same way. In this application, in the order of message propagation, the initial router node is first described in detail.

[0048] Specifically, the local policy routing rule can be represented in the following form: <source prefix, destination prefix, other elements, next-hop np>. Assume that the SPD message received by the local router is M , and traverse each local policy routing rule in sequence according to the priority order, and perform the following steps: The first step is to generate the SPD message sent to np based on M and this policy routing rule.

[0049] The second step is to analyze the impact of this rule on the forwarding policies of subsequent rules and update the message M .

[0050] After the policy routing rule with the highest priority is processed, the remaining policy routing rules are sequentially repeated the above two steps in the priority order until all policy routing rules are processed.

[0051] It can be understood that since policy routing rules can be divided into different types, for each type of policy routing rule, the ways of performing the above two steps are also different. In an embodiment of the present application, corresponding SPD messages sent to the next-hop routing node are generated successively according to each policy routing rule and the initial SPD message of this round, including the following steps: determining the type of each policy routing rule according to whether each policy routing rule limits the source prefix, destination prefix and other elements; determining the generation methods of the filtering rules and propagation scopes in the SPD messages sent to the next-hop routing node according to the type of each policy routing rule.

[0052] For example, in this embodiment, the specific processing procedures of the above two steps for generating SPD messages can be referred to the manner shown in Table 1 below: Table 1 Generation Method Table of SPD Messages for Different Types of Policy Routing

[0053] As shown in Table 1, in this embodiment, the generation method of the filtering rules of the SPD messages sent to the next-hop routing node includes: calculating the intersection of the current policy routing rule and the filtering rules of the initial SPD message of this round, and being consistent with the filtering rules of the initial SPD message of this round; the generation method of the propagation scope of the SPD messages sent to the next-hop routing node includes: using the destination prefix of the current policy routing rule as the propagation scope of the SPD messages sent to the next-hop routing node, and being consistent with the propagation scope of the initial SPD message of this round.

[0054] And updating the initial SPD message of this round includes: deleting the filtering rules of the current policy routing rule from the filtering rules of the initial SPD message of this round; or deleting the destination prefix of the current policy routing rule from the propagation scope of the initial SPD message of this round.

[0055] To describe the above processing procedure more clearly, a specific example is given below. As Figure 4 shown, a network topology structure composed of four router nodes within the domain (i.e., Router A, Router B, Router C, and Router D) Figure 4 is shown, where Router A has prefixes P1 and P2, Router B has prefix P3, Router C has prefix P4, and Router D has prefix P5. Router B contains two incoming interfaces b1 and b2, Router C contains one incoming interface c1, and Router D contains two incoming interfaces d1 and d2. Router A is the initial router in this example, and it configures a policy routing rule <P1, *, C>, that is, redirects all packets with source address P1 to the next-hop C. Then the local policy routing rules in Router A are as shown in Table 2 below: Table 2 Local Forwarding Policy Table of Router A

[0056] For Router A, the process of generating and sending SPD messages is shown in Figure 5 as follows. Specifically, assume that the propagation ranges of the SPD messages M received by A are P3, P4, and P5, and the filtering rules are <P1, *> and <P2, *> (i.e., allowing all packets with source addresses P1 or P2 to pass). First, according to the policy routing rule <P1, *, C> with the highest priority, an SPD message sent to C is generated. Referring to the generation method shown in Table 1 above, the propagation range of the generated SPD message is M consistent, and the filtering rule is <P1, *> obtained by taking the intersection of <P1, *> and <P2, *>. Then, when updating, <P1, *> is deleted from the filtering rule of the message M .

[0057] Then, based on the next policy routing rule <*, P3, B>, an SPD message sent to B is generated. Continuing to refer to the generation method shown in Table 1 above, the propagation range of the SPD message corresponding to this rule should be P3, and the filtering rule is the intersection of <*, P3> and <P2, *>, that is, <P2, P3>. Then, P3 is deleted from the propagation range of the message M . Similarly, based on the subsequent policy routing rules <*, P4, C> and <*, P5, B> in turn, SPD messages sent to C and B are generated respectively until all the policy routing rules in Table 2 are processed.

[0058] Step S103: Control each next-hop routing node to construct a traffic verification table according to the filtering rules in the received message, and based on the propagation range of the received message, continue to propagate the newly generated message to the subsequent next-hop routing nodes in the same way as the initial router generates the message for discovering the true forwarding path until the propagation range becomes empty.

[0059] Specifically, among each next-hop routing node, the router that receives the SPD message sent by the above initial router constructs a traffic verification table in the format shown in Figure 6 based on the filtering rule field in the SPD message, so as to filter the incoming traffic based on the source prefix and destination prefix in the verification table later.

[0060] Among them, each routing node may receive multiple SPD messages. Therefore, the verification table is updated every time an SPD message is received during the message propagation process. Moreover, the SPD message received by this routing node may still need to be propagated to the subsequent next-hop routing node. Therefore, when it is determined according to the propagation range of the received message that it still needs to be propagated to the next-hop routing node, the newly generated message is continuously propagated to the subsequent next-hop routing node in the same manner as the initial router generates and sends the SPD in step S102 until the propagation range of the SPD message received by this routing node becomes empty.

[0061] In an embodiment of the present application, based on the propagation range of the received SPD message, the newly generated SPD message is continuously propagated to the subsequent next-hop routing node in the same manner as the initial router generates the SPD message, including: deleting the local prefix of the current routing node from the propagation range of the received SPD message, and determining whether the propagation range of the deleted SPD message is empty; when the propagation range is not empty, in the order of the priorities of each policy routing rule of the current routing node, an SPD message sent to the subsequent next-hop routing node is generated according to each policy routing rule and the received SPD message in turn, and the received SPD message is updated.

[0062] For example, continue to refer to the Figure 4 example in step S102 above. After the b1 interface of router B and the c1 interface of router C receive the SPD message sent by router A, they first need to construct a traffic verification table according to the filtering rules in the message. Then, the local prefix is removed from the propagation range of the message. If the propagation range is not empty, the message is continuously propagated backward.

[0063] Among them, the manner in which router B generates and propagates the SPD message is as Figure 7 shown. Since the propagation range of the first SPD message sent by router A to router B in Figure 5 becomes empty after removing the local prefix P3 from the propagation range of the received SPD message, and the propagation range of the second SPD message is P5, the second SPD message needs to be continuously propagated backward. Assume that the local policy routing rules in router B are as Figure 7 shown. After generating the SPD message sent to the next-hop router D in the manner of Table 1 above and updating the second SPD message, the propagation range of the second SPD message becomes empty, and thus the propagation ends.

[0064] For router C, the manner in which it generates and propagates the SPD message is as Figure 8 shown. Since the propagation range of the received SPD message becomes empty after removing the local prefix P4 from it, Figure 5The propagation range edge of the second SPD message sent by router A to router C is empty. The propagation range of the first SPD message is P3 and P5. Therefore, the first SPD message needs to be propagated further backward.

[0065] Assume that the local policy routing rules in router C are as Figure 8 shown. First, generate an SPD message to be sent to the next-hop router B in the manner of Table 1 above according to the priority order, and after updating the first SPD message, the propagation range of the first SPD message becomes P5. Then, generate an SPD message to be sent to the next-hop router D according to the next policy routing rule, and further update the first SPD message in this round. Its propagation range becomes empty, and thus the propagation ends.

[0066] Thus, after all SPD messages have completed propagation, each routing node constructs a complete traffic verification table according to the filtering rules in the continuously received SPD messages. In an embodiment of the present application, constructing a traffic verification table according to the filtering rules in the received SPD messages includes: when each SPD message is received at the access interface of any router, constructing a corresponding verification item according to the access interface and the source prefix and destination prefix in the filtering rules; after the message propagation is completed, summarizing all the verification items to generate a complete traffic verification table for any router.

[0067] Continuing to refer to the above example, after all SPD messages have completed propagation, the traffic verification tables constructed on routers B, C, and D are shown in Table 3, Table 4, and Table 5 below respectively: Table 3 Traffic Verification Table of Router B ; Table 4 Traffic Verification Table of Router C ; Table 5 Traffic Verification Table of Router D .

[0068] Based on the above constructed verification table, when router A enables the policy route <P1, *, C>, only packets with the source address of P2 are allowed to pass through the incoming interfaces b1 and d1 of the subsequent routers, and only packets with the source address of P1 are allowed to pass through the incoming interfaces b2 and d2.

[0069] Step S104, verify the incoming traffic in each routing node according to the source prefix and destination prefix in the locally constructed traffic verification table.

[0070] Specifically, after all SPD messages are propagated, each routing node locally constructs a complete traffic verification table. When actually verifying the incoming data packets, according to the source prefix and destination prefix in the traffic verification table, the incoming traffic is verified from two aspects, thereby improving the accuracy of filtering forged packets.

[0071] For example, also for the Figure 1 filtering forged packet verification process, after deploying the forged source address traffic verification method in the intra-domain policy routing scenario of this application on the router, the filtering process of forged packets becomes as Figure 9 shown. In the case of using the method described in this application to transmit SPD messages and construct a traffic verification table, nodes 6, 7, and 8 only allow packets with source address P1 and destination address P8 to enter from interfaces 6.1, 7.1, and 8.2. And attack packets with other forged source addresses P1 or P2 from node 5 and its upstream undeployed area will be intercepted. Compared with the Figure 1 verification technology in the related embodiments shown, this application significantly improves the accuracy of filtering packets.

[0072] In summary, for the forged source address traffic verification method in the intra-domain policy routing scenario of this application embodiment, by generating filter rule fields through the local policy routing rules and forwarding tables of the router, and adding filter rule fields to the SPD messages, the SPD messages contain specific policy routing rule information. Furthermore, each router within the domain can construct a more refined traffic verification table according to the filter rule fields and verify the incoming traffic from two aspects of the source prefix and destination prefix. And, each router within the domain generates corresponding SPD messages in sequence according to the priority order of the local policy routing rules, and can comprehensively identify all possible forwarding paths from each source prefix to each destination prefix to transmit messages, further improving the comprehensiveness of the constructed traffic verification table. Thus, verifying packets based on the traffic verification table constructed by this method can significantly improve the filtering and interception ability of forged source address packets, expand the forged source address packets that can be intercepted, and improve the accuracy and comprehensiveness of forged source address traffic verification.

[0073] To implement the above embodiments, this application also proposes a forged source address traffic verification system in the intra-domain policy routing scenario. Figure 10 As a structural schematic diagram of a forged source address traffic verification system in the intra-domain policy routing scenario proposed by this application embodiment, as Figure 10 shown, the system includes a first generation module 100, a second generation module 200, a construction module 300, and a verification module 400.

[0074] Among them, the first generation module 100 is used to generate an initial SPD message for discovering the real forwarding path according to the policy routing rules and forwarding tables of the intra-domain initial router. The SPD message includes a propagation range and filtering rules, and the filtering rules include a source prefix and a destination prefix.

[0075] The second generation module 200 is used to generate corresponding SPD messages sent to the next-hop routing node according to each policy routing rule and the initial SPD message of this round in turn according to the priority order of each policy routing rule of the initial router, and update the initial SPD message of this round.

[0076] The construction module 300 is used to control each next-hop routing node to construct a traffic verification table according to the filtering rules in the received SPD message, and based on the propagation range of the received SPD message, continue to propagate the newly generated SPD message to the subsequent next-hop routing nodes in the same way as the initial router generates the SPD message until the propagation range becomes empty.

[0077] The verification module 400 is used to verify the incoming traffic according to the source prefix and destination prefix in the locally constructed traffic verification table in each routing node.

[0078] Optionally, in an embodiment of the present application, the first generation module 100 is specifically used to: regard the forwarding table in each routing node as the policy routing rule with the lowest priority and arrange it after the preset policy routing rules; regard all the destination prefixes in the policy routing rules and forwarding tables of the initial router as the propagation range of the initial SPD message; set the filtering rule of the initial SPD message to allow all packets from all source prefixes to all destination prefixes of the initial router to pass the verification.

[0079] Optionally, in an embodiment of the present application, the second generation module 200 is specifically used to: determine the type of each policy routing rule according to whether each policy routing rule limits the source prefix, destination prefix and other elements; determine the generation method of the filtering rules and propagation range in the SPD message sent to the next-hop routing node according to the type of each policy routing rule.

[0080] Optionally, in an embodiment of the present application, the second generation module 200 is further used to: delete the filtering rule of the current policy routing rule from the filtering rules of the initial SPD message of this round; or delete the destination prefix of the current policy routing rule from the propagation range of the initial SPD message of this round.

[0081] Optionally, in an embodiment of the present application, the building module 300 is specifically configured to: delete the local prefix of the current routing node from the propagation scope of the received SPD message, and determine whether the propagation scope of the SPD message after deletion is empty; When the propagation scope is not empty, in the order of the priorities of each policy routing rule of the current routing node, successively generate an SPD message sent to the subsequent next-hop routing node according to each policy routing rule and the received SPD message, and update the received SPD message.

[0082] Optionally, in an embodiment of the present application, the building module 300 is specifically configured to: when each SPD message is received by the access interface of any router, construct a corresponding verification item according to the access interface and the source prefix and destination prefix in the filtering rule; after the message propagation is completed, summarize all the verification items to generate a complete traffic verification table of any router.

[0083] It should be noted that the foregoing explanation of the embodiments of the spoofed source address traffic verification method in the intra-domain policy routing scenario also applies to the system of this embodiment. The specific functions executed by each module can refer to the relevant descriptions in the foregoing method embodiments, and will not be elaborated here.

[0084] In summary, the spoofed source address traffic verification system in the intra-domain policy routing scenario of the embodiments of the present application generates a filtering rule field through the policy routing rule and the forwarding table of the router locally, and adds a filtering rule field to the SPD message, so that the SPD message contains specific policy routing rule information. Furthermore, each router in the domain can construct a more refined traffic verification table according to the filtering rule field, and verify the incoming traffic from both the source prefix and the destination prefix. This system can significantly improve the filtering and interception ability of spoofed source address packets, expand the spoofed source address packets that can be intercepted, and improve the accuracy and comprehensiveness of spoofed source address traffic verification.

[0085] To implement the above embodiments, the present application also proposes a non-transitory computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, it implements the spoofed source address traffic verification method in any of the above embodiments in the intra-domain policy routing scenario.

[0086] In the description of this specification, the descriptions referring to terms such as "one embodiment", "some embodiments", "examples", "specific examples", or "some examples", etc. mean that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this application. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0087] In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include at least one of such features. In the description of this application, "a plurality of" means at least two, such as two, three, etc., unless otherwise specifically defined.

[0088] Any process or method description shown in the flowchart or described in other ways herein can be understood as representing a module, segment, or portion of code including one or more executable instructions for implementing a customized logic function or process, and the scope of the preferred embodiments of this application includes additional implementations, where the functions can be executed in a manner that may not be in the order shown or discussed, including in a substantially simultaneous manner according to the involved functions or in a reverse order, which should be understood by those skilled in the art to which the embodiments of this application belong.

[0089] The logic and / or steps represented in the flowchart or otherwise described herein can, for example, be considered as a definable sequence list of executable instructions for implementing logical functions, which can be specifically implemented in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device), or in conjunction with these instruction execution systems, apparatuses, or devices. For the purposes of this specification, a "computer-readable medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (non-exhaustive list) of computer-readable media include the following: an electrical connection portion having one or more wirings (electronic device), a portable computer diskette (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium can even be paper or other suitable media on which the program can be printed, as the program can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpretation, or otherwise processing as appropriate, and then storing it in a computer memory.

[0090] It should be understood that various parts of the present application can be implemented by hardware, software, firmware, or a combination thereof. In the above-described 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 in hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application-specific integrated circuits having suitable combinational logic gate circuits, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0091] Those of ordinary skill in the art of this technology can understand that all or part of the steps carried by the methods of the above-described embodiments can be completed by instructing relevant hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiments.

[0092] In addition, each functional unit in various embodiments of the present application may be integrated into a processing module, may exist physically alone for each unit, 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. When 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.

[0093] The above-mentioned storage medium may be a read-only memory, a magnetic disk, an optical disc, 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 should not be construed as limiting the present application. Those of ordinary skill in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present application.

Claims

1. A method for verifying forged source address traffic in a domain policy routing scenario, characterized in that: The following steps are involved: Generate an initial SPD message for discovering a real forwarding path according to the policy routing rules and forwarding table of the initial router in the domain, wherein the SPD message includes a propagation range and a filtering rule, and the filtering rule includes a source prefix and a destination prefix; According to the priority order of each policy routing rule of the initial router, according to each policy routing rule and the initial SPD message of this round, a corresponding SPD message sent to the next hop routing node is generated and the initial SPD message of this round is updated; Control each next-hop routing node to construct a traffic verification table according to the filtering rules in the received SPD message, and based on the propagation range of the received SPD message, continue to propagate the newly generated SPD message to subsequent next-hop routing nodes in the manner in which the initial router generates the SPD message until the propagation range becomes empty; In each routing node, the ingress traffic is verified based on the source prefix and destination prefix in the locally constructed traffic verification table.

2. The method according to claim 1, characterized in that Before generating the initial SPD message for discovering the real forwarding path, the method further includes: The forwarding table in each routing node is used as the policy routing rule with the lowest priority and arranged after the preset policy routing rule; The generating of the initial SPD message for discovering the real forwarding path includes: Using the policy routing rules of the initial router and all destination prefixes in the forwarding table as the propagation scope of the initial SPD message; The filtering rule of the initial SPD message is set to allow all messages from all source prefixes to all destination prefixes of the initial router to pass the verification.

3. The method according to claim 1, characterized in that: The method generates a corresponding SPD message sent to the next hop routing node according to each policy routing rule and the initial SPD message of this round, including: Determine the type of each of the policy routing rules according to whether each of the policy routing rules limits a source prefix, a destination prefix and other elements; According to the type of each of the policy routing rules, a generation method of the filtering rule and the propagation range in the SPD message sent to the next-hop routing node is determined.

4. The method according to claim 3, characterized in that The method for generating the filtering rule of the SPD message sent to the next-hop routing node includes: calculating the intersection of the current policy routing rule and the filtering rule of the initial SPD message of the current round, and the intersection of the current policy routing rule and the filtering rule of the initial SPD message of the current round is consistent; The method for generating the propagation range of the SPD message sent to the next-hop routing node includes: using the destination prefix of the current policy routing rule as the propagation range of the SPD message sent to the next-hop routing node, and making it consistent with the propagation range of the initial SPD message of this round.

5. The method according to claim 4, characterized in that The updating of the initial SPD message of this round includes: The filtering rule of the current policy routing rule is deleted from the filtering rule of the initial SPD message of this round; or the destination prefix of the current policy routing rule is deleted from the propagation range of the initial SPD message of this round.

6. The method according to claim 1, characterized in that The method of continuing to propagate the newly generated SPD message to the subsequent next-hop routing node in the manner in which the initial router generates the SPD message based on the propagation range of the received SPD message includes: Deleting the local prefix of the current routing node from the propagation range of the received SPD message, and determining whether the propagation range of the SPD message after the deletion is empty; When the propagation range is not empty, according to the priority order of each policy routing rule of the current routing node, according to each policy routing rule and the received SPD message, an SPD message to be sent to the subsequent next-hop routing node is generated and the received SPD message is updated.

7. The method according to claim 1, characterized in that The step of constructing a flow verification table according to the filtering rules in the received SPD message includes: When an access interface of any router receives an SPD message, a corresponding verification item is constructed according to the access interface and the source prefix and destination prefix in the filtering rule; After the message propagation is completed, all verification items are summarized to generate a complete flow verification table for any of the routers.

8. A forged source address traffic verification system in a domain policy routing scenario, characterized in that: Includes the following modules: A first generating module, configured to generate an initial SPD message for discovering a real forwarding path according to a policy routing rule and a forwarding table of an initial router in the domain, wherein the SPD message includes a propagation range and a filtering rule, and the filtering rule includes a source prefix and a destination prefix; A second generation module is used to generate a corresponding SPD message sent to the next hop routing node and update the initial SPD message of this round according to the priority order of each policy routing rule of the initial router and each policy routing rule and the initial SPD message of this round; A construction module, used to control each next-hop routing node to construct a traffic verification table according to the filtering rules in the received SPD message, and based on the propagation range of the received SPD message, continue to propagate the newly generated SPD message to subsequent next-hop routing nodes in the manner in which the initial router generates the SPD message until the propagation range becomes empty; The verification module is used to verify the ingress traffic in each routing node according to the source prefix and destination prefix in the locally constructed traffic verification table.

9. The system according to claim 8, characterized in that The first generating module is specifically used for: The forwarding table in each routing node is used as the policy routing rule with the lowest priority and arranged after the preset policy routing rule; Using the policy routing rules of the initial router and all destination prefixes in the forwarding table as the propagation scope of the initial SPD message; The filtering rule of the initial SPD message is set to allow all messages from all source prefixes to all destination prefixes of the initial router to pass the verification.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, a forged source address traffic verification method is implemented in an intra-domain policy routing scenario according to any one of claims 1 to 7.

Images