Source address verification method and device of data packet and computer equipment

Abstract

The invention relates to a source address verification method and device of a data packet and computer equipment. The method comprises the following steps: receiving a data packet from source equipment, extracting routing information carried by the data packet, and identifying a routing path of the data packet according to the routing information; if the routing path is a backup path, determining a previous hop node for sending the data packet according to the routing information; matching an actual input interface of the data packet from the previous hop node to the merging node with a predetermined input interface; if the actual ingress interface is matched with the predetermined ingress interface, starting a source address verification mechanism at the actual ingress interface, and performing source address legality verification on the data packet; and forwarding the data packet to the target device through the remaining path under the condition that the verification of the source address is passed. By adopting the method, the source address of the data packet can be effectively verified in a dynamic path scene.

Description

Technical Field

[0001] The present application relates to the technical field of computer network security, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for verifying the source address of a data packet. Background Art

[0002] As network topologies become increasingly complex, traditional Source Address Validation (SAV) mechanisms face multiple challenges. For example, in traditional verification schemes such as shortest path verification, static path verification, control plane-based verification, and edge verification, the shortest path verification scheme assumes that traffic will be routed along the shortest path, and therefore only verifies traffic that follows the shortest path. However, when a path fails or load balancing is required, traffic may take alternative routes, leading to the spread of forged traffic. Static path verification schemes typically configure verification rules based on a fixed topology or routing policy. When the network topology changes (such as path switching or traffic load balancing), the original verification rules may become invalid, causing non-compliant traffic to pass.

[0003] Therefore, traditional source address verification methods are difficult to achieve effective source address verification in dynamic path scenarios. Summary of the Invention

[0004] Based on this, it is necessary to provide a source address verification method, device, computer equipment, computer-readable storage medium and computer program product for data packets that can effectively verify the source address in a dynamic path scenario to address the above technical problems.

[0005] In a first aspect, the present application provides a method for verifying the source address of a data packet, comprising:

[0006] Receive a data packet from a source device, extract routing information carried in the data packet; and identify a routing path of the data packet based on the routing information;

[0007] If the routing path is a backup path, determining the previous hop node for sending the data packet according to the routing information;

[0008] Matching the actual inbound interface of the data packet arriving at the merging node from the previous hop node with the predetermined inbound interface;

[0009] If the actual inbound interface of the data packet matches the predetermined inbound interface, a source address verification mechanism is enabled on the actual inbound interface to verify the legitimacy of the source address of the data packet;

[0010] If the source address of the data packet passes the verification, the data packet is forwarded to the target device through the remaining path.

[0011] In one embodiment, the verifying the legitimacy of the source address of the data packet includes:

[0012] Extracting the source address prefix in the data packet and querying a pre-built mapping relationship table to obtain a source address prefix set configured for the previous hop node;

[0013] If the source address prefix matches the source address prefix set corresponding to the previous hop node, it is determined that the source address verification of the data packet is passed.

[0014] In one embodiment, after the source address verification mechanism is enabled on the actual inbound interface, the method further includes:

[0015] Starting a timer set for the actual input interface;

[0016] If a new data packet is received again within the timing of the timer, the timer is reset;

[0017] If no new data packet is received within the timing time of the timer, the actual input interface is closed.

[0018] In one embodiment, if the actual inbound interface of the data packet matches the predetermined inbound interface, enabling a source address verification mechanism on the actual inbound interface includes:

[0019] If the actual input interface matches the predetermined input interface, determining the number of interfaces currently enabled on the routing device of the merging node;

[0020] When the number of currently enabled interfaces is less than a predetermined interface number threshold, a source address verification mechanism is enabled on the actual inbound interface.

[0021] In one embodiment, the method further comprises:

[0022] Obtaining the segment type of the previous hop node; different segment types are used to indicate different processing behaviors of the data packet;

[0023] determining the normality of the current path of the data packet according to the behavior logic corresponding to the segment type;

[0024] If there is an abnormality, a path status alarm will be triggered.

[0025] In one embodiment, the method further comprises:

[0026] If the actual inbound interface does not match the predetermined inbound interface, or the source address verification fails, determining that the data packet is a forged data packet;

[0027] The data packet is discarded and recorded in a security log.

[0028] In a second aspect, the present application further provides a device for verifying the source address of a data packet, comprising:

[0029] an identification module, configured to receive a data packet from a source device, extract routing information carried in the data packet, and identify a routing path of the data packet based on the routing information;

[0030] a sending module, configured to determine, if the routing path is a backup path, a previous hop node to which the data packet is sent based on the routing information;

[0031] a matching module, configured to match an actual inbound interface of the data packet arriving at the merging node from the previous hop node with a predetermined inbound interface;

[0032] a verification module, configured to enable a source address verification mechanism on the actual inbound interface to verify the legitimacy of the source address of the data packet if the actual inbound interface of the data packet matches the predetermined inbound interface;

[0033] The routing module is used to forward the data packet to the target device through the remaining path when the source address of the data packet is verified.

[0034] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0035] Receive a data packet from a source device, extract routing information carried in the data packet; and identify a routing path of the data packet based on the routing information;

[0036] If the routing path is a backup path, determining the previous hop node for sending the data packet according to the routing information;

[0037] Matching the actual inbound interface of the data packet arriving at the merging node from the previous hop node with the predetermined inbound interface;

[0038] If the actual inbound interface of the data packet matches the predetermined inbound interface, a source address verification mechanism is enabled on the actual inbound interface to verify the legitimacy of the source address of the data packet;

[0039] If the source address of the data packet passes the verification, the data packet is forwarded to the target device through the remaining path.

[0040] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

[0041] Receive a data packet from a source device, extract routing information carried in the data packet; and identify a routing path of the data packet based on the routing information;

[0042] If the routing path is a backup path, determining the previous hop node for sending the data packet according to the routing information;

[0043] Matching the actual inbound interface of the data packet arriving at the merging node from the previous hop node with the predetermined inbound interface;

[0044] If the actual inbound interface of the data packet matches the predetermined inbound interface, a source address verification mechanism is enabled on the actual inbound interface to verify the legitimacy of the source address of the data packet;

[0045] If the source address of the data packet passes the verification, the data packet is forwarded to the target device through the remaining path.

[0046] In a fifth aspect, the present application further provides a computer program product, comprising a computer program, which, when executed by a processor, implements the following steps:

[0047] Receive a data packet from a source device, extract routing information carried in the data packet; and identify a routing path of the data packet based on the routing information;

[0048] If the routing path is a backup path, determining the previous hop node for sending the data packet according to the routing information;

[0049] Matching the actual inbound interface of the data packet arriving at the merging node from the previous hop node with the predetermined inbound interface;

[0050] If the actual inbound interface of the data packet matches the predetermined inbound interface, a source address verification mechanism is enabled on the actual inbound interface to verify the legitimacy of the source address of the data packet;

[0051] If the source address of the data packet passes the verification, the data packet is forwarded to the target device through the remaining path.

[0052] The source address verification method, apparatus, computer equipment, computer-readable storage medium and computer program product of the above-mentioned data packet, the routing device of the merging node receives the data packet routed by the source device, determines the routing path of the data packet by extracting the routing information carried by the data packet, and if it is a backup path, determines the previous hop node that sent the data packet; further determines the actual input interface of the data packet arriving at the merging node from the previous hop node, matches the actual input interface with the predetermined input interface, and if the two match, enables the source address verification mechanism on the actual input interface to verify the legitimacy of the source address of the data packet; if the source address verification passes, routes the data packet to the target device through the remaining path. The method implements source address verification of data packets routed along the backup path in a routing device at a merging node of the primary and backup paths, without being restricted to the shortest path or static path, and can effectively verify the source addresses of data packets in dynamic path scenarios. Furthermore, the routing device dynamically enables the source address verification mechanism of the relevant input interface only when the data packet passes through the backup path, based on the matching result between the actual input interface and the predetermined input interface. This on-demand method of enabling the routing device port for source address verification can achieve flexible and effective traffic verification. Furthermore, after the primary path is switched, the fast path recovery based on the TI-FRR mechanism allows traffic to be verified immediately after the path is switched, thereby preventing illegal traffic from entering the network. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0054] Figure 1 FIG. 1 is an application environment diagram of a method for verifying the source address of a data packet in one embodiment;

[0055] Figure 2 1 is a flow chart of a method for verifying the source address of a data packet in one embodiment;

[0056] Figure 3 A schematic diagram of a network topology in an application example;

[0057] Figure 4 Schematic diagram of a flow chart of a method for verifying the source address of a data packet in another embodiment;

[0058] Figure 5 is a structural block diagram of a device for verifying the source address of a data packet in one embodiment;

[0059] Figure 6FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0060] In order to make the purpose, technical solutions and advantages of this application clearer, the application is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application. The terms "including" and "having" and any variations thereof used in this application are intended to cover non-exclusive inclusions. The term "plurality" used in this application refers to two or more.

[0061] To facilitate understanding of this application, the terms involved in this application are briefly explained below.

[0062] The data plane and control plane are the two core logical layers that separate the functions of routing devices. They work together to achieve efficient and scalable network communication. The data plane (also known as the forwarding plane) is responsible for real-time data packet processing, including receiving, parsing, matching rules, and executing actions (such as forwarding, discarding, and modifying). The control plane is responsible for generating and managing network rules, calculating paths through protocols, maintaining topology information, and distributing decisions to the data plane.

[0063] SAV (Source Address Validation) is a source address verification mechanism that prevents source address forgery attacks and ensures network security by verifying the legitimacy of the source IP address of a data packet.

[0064] TI-FRR (Topology Independent Fast Reroute) is a topology-independent fast alternative path rerouting mechanism that ensures that traffic can be quickly switched to a pre-defined alternative path when a network path fails, minimizing service interruption.

[0065] Inbound interface, a port on a routing device, specifically a physical or logical interface on a routing device, used to receive and send data packets.

[0066] Segment Routing Header (SRH) is a type of IPv6 extension header that explicitly specifies an SRv6 (Segment Routing over IPv6) path by carrying information such as the Segment List.

[0067] A segment list defines an explicit forwarding path for a packet. Essentially, it's an ordered sequence of instructions that guides how a packet traverses the network, hop by hop, from the source device to the destination device. For example, the segment list for the path A→B→C→D is [D, C, B].

[0068] FIB (Forwarding Information Base) is the core data structure of routing devices. It stores instructions for fast forwarding on the data plane and maps the destination address to the outgoing interface / next hop.

[0069] The source address verification method of the data packet provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown in FIG. 1 , the source device 101 sends a data packet to the target device 102 via the primary path or the backup path. After the primary and backup paths are switched, the traffic is merged back to the original path, and the first common node after the convergence is recorded as the merge node. For example, Figure 1 Node 103 in. In the application scenario of the present application, the source device 101 and the target device 102 can both be user-side routers, or one can be a user-side router and the other can be an operator's router. When the primary path is normal, the source device 101 sends the data packet to the target device 102 through the primary path. When the primary path fails, the TI-FRR mechanism is triggered to reroute the action, automatically enabling the backup path, switching to the backup path, and sending the data packet to the target device 102 through the backup path. When the source device 101 sends the data packet to the target device 102 through the backup path, it is necessary to verify the source address of the data packet at the merging node 103 to prevent forged traffic from entering the network through the backup path.

[0070] Specifically, the merging node 103 receives a data packet routed by the source device 101 and determines whether it belongs to the primary path or the backup path based on the routing information carried in the data packet. If it belongs to the backup path, the previous hop node from which the data packet was sent is determined. The actual inbound interface of the data packet from the previous hop node to the merging node is determined, and a pre-built node-inbound interface mapping table in the merging node's routing device is queried to determine the predetermined inbound interface from the previous hop node to the merging node. If the actual inbound interface matches the predetermined inbound interface, the source address verification mechanism is enabled at the actual inbound interface to verify the legitimacy of the data packet's source address. If the source address verification passes, the data packet is routed to the target device 102 via the remaining path. This ensures that even if attack traffic takes the backup path, it cannot bypass the verification point and directly enter the target device. Therefore, source address legitimacy verification only needs to be performed at the first hop node (merging node) shared by the primary and backup paths. The merging node is generally an edge node or security boundary node close to the receiving service.

[0071] In an exemplary embodiment, Figure 2 As shown, a method for verifying the source address of a data packet is provided, and the method is applied to Figure 1 Taking the routing device of the merging node 103 in FIG. 1 as an example, the method includes the following steps:

[0072] Step S210: receiving a data packet from a source device, extracting routing information carried in the data packet, and identifying a routing path of the data packet based on the routing information.

[0073] In this step, the routing information is specifically the Segment Routing Header (SRH), which contains the currently active node (Active Segment) and the packet's forwarding path table (i.e., Segment List). It should be noted that the currently active node is the node that sent the packet to the merging node. Therefore, from the perspective of the merging node, this application defines it as the previous hop node that sent the packet.

[0074] Specifically, the forwarding path table of the data packet and the previous hop node of the data packet can be parsed from the routing information of the data packet. Further combined with the local policy or path mapping table of the routing device of the merging node, it can be determined whether the routing path of the current data packet is the main path or the backup path.

[0075] Step S220: If the routing path is a backup path, determine the previous hop node for sending the data packet according to the routing information.

[0076] Specifically, if the actual forwarding path of the data packet is matched with the current policy or path mapping table and it is determined that the data packet is routed via the backup path, the currently active node in the routing information may be used as the previous hop node for sending the data packet.

[0077] For example, an operator deploys an SRv6-based primary and backup path network to carry core business traffic. The network topology is as follows: Figure 3 As shown in the figure, the primary and backup paths from the source device (CE-A) to the destination device (CE-B) are:

[0078] The main path is: R1 → R2 → R4 → R5;

[0079] The backup path is: R1 → R3 → R4 → R5;

[0080] When the primary path is functioning properly, data packets travel from R1 through R2, R4, and R5 to the destination device. If a failure occurs between R2 and R4, the TI-FRR mechanism automatically activates the backup path, routing traffic through R3 to R4. R4, the merging node, receives the data packet and extracts the routing information carried in the packet. If the parsed routing information identifies R3 as the currently active node, the packet is determined to have been routed via the backup path, and R3 is identified as the previous hop for the packet.

[0081] Step S230 : Match the actual inbound interface of the data packet arriving at the merging node from the previous hop node with the predetermined inbound interface.

[0082] Specifically, after determining the previous hop node from which the data packet was sent, the actual inbound interface of the data packet arriving at the merging node from the previous hop node is further determined. Furthermore, a pre-built mapping table of nodes and inbound interfaces is queried from the routing device of the merging node to determine the predetermined inbound interface from the previous hop node to the merging node. The actual inbound interface is then matched with the predetermined inbound interface. Based on the matching result, the merging node determines whether to perform source address verification, i.e., whether to allow the data packet to enter through the actual inbound interface. The mapping table stores the associations between different nodes and their inbound interfaces arriving at the merging node, and the mapping table can be stored in the local FIB.

[0083] In this application, when the TI-FRR mechanism is deployed on the control plane of the routing device, a corresponding Segment List will be pre-generated for each primary and backup path to implement source address verification control on the backup path. Figure 3 For the primary and backup paths shown, the control plane of the routing device at the merging node can preset the segment list as follows:

[0084] Main path: Segment List = [End (R5)];

[0085] Backup path: Segment List = [End.X (R3→R4), End (R5)];

[0086] At the merge node (R4), the control plane establishes a mapping between its incoming interfaces and other nodes that may reach the merge node. For example, if End.X represents interface eth2, which points from R3 to R4, the mapping table established on R4 is shown in Table 1.

[0087] Table 1

[0088]

[0089] This mapping table is stored in an attached structure of the routing device's local FIB. This allows the data plane of the routing device to subsequently determine whether a packet arrives via a legitimate path, thereby guiding whether the inbound interface should temporarily enable source address verification. In some embodiments, this mapping table can be hot-updated without restarting the service.

[0090] Step S240: If the actual inbound interface matches the predetermined inbound interface, a source address verification mechanism is enabled on the actual inbound interface to verify the legitimacy of the source address of the data packet.

[0091] In the specific implementation, if the actual inbound interface matches the predetermined inbound interface, it means that the merging node allows the packet to enter the routing device through the actual inbound interface. In other words, the received data packet belongs to legitimate fast reroute traffic and can be released with restrictions, and the source address verification mechanism of the inbound interface is activated.

[0092] For example, in Figure 3 In the example, if it is determined that the actual inbound interface of the data packet from R3 to R4 is eth2, and the predetermined inbound interface from R3 to R4 determined by querying the mapping table is eth2, the actual inbound interface matches the predetermined inbound interface, indicating that the data packet belongs to a legal detour path, then the eth2 interface is immediately opened and the source address verification function is enabled for the eth2 interface.

[0093] Step S250: If the source address of the data packet is verified, the data packet is forwarded to the target device through the remaining path.

[0094] The remaining path refers to the path formed by each node from the merge node to the target device.

[0095] In a specific implementation, if the source address of a data packet is verified to be legitimate and can be forwarded, the data packet can be forwarded to the next hop node, which in turn forwards it to the next hop node, and so on, until it is forwarded to the target device, thereby allowing the target device to receive the data packet sent by the source device. Figure 3 In the example, after the merging node R4 verifies the source address of the data packet sent by R3, it forwards the data packet to the node R5, and the node R5 sends the data packet to the target device CE-B.

[0096] In the above-mentioned method for verifying the source address of the data packet, the routing device of the merging node receives the data packet routed by the source device, determines the routing path of the data packet by extracting the routing information carried by the data packet, and determines the previous hop node that sent the data packet if it is a backup path; further determines the actual input interface of the data packet arriving at the merging node from the previous hop node, matches the actual input interface with the predetermined input interface, and if the two match, enables the source address verification mechanism on the actual input interface to verify the legitimacy of the source address of the data packet; if the source address verification passes, the data packet is routed to the target device through the remaining path. The method implements source address verification of data packets routed along the backup path in a routing device at a merging node of the primary and backup paths, without being restricted to the shortest path or static path, and can effectively verify the source addresses of data packets in dynamic path scenarios. Furthermore, the routing device dynamically enables the source address verification mechanism of the relevant input interface only when the data packet passes through the backup path, based on the matching result between the actual input interface and the predetermined input interface. This on-demand method of enabling the routing device port for source address verification can achieve flexible and effective traffic verification. Furthermore, after the primary path is switched, the fast path recovery based on the TI-FRR mechanism allows traffic to be verified immediately after the path is switched, thereby preventing illegal traffic from entering the network.

[0097] In an exemplary embodiment, step S240 verifies the legitimacy of the source address of the data packet, including: extracting the source address prefix in the data packet, and querying the mapping relationship table to obtain the source address prefix set configured for the previous hop node; if the source address prefix matches the source address prefix set corresponding to the previous hop node, it is determined that the source address verification of the data packet is passed.

[0098] In the specific implementation, the source address verification rule includes two key fields: the source address prefix and the source address prefix set corresponding to the previous hop node. The source address verification is specifically to verify whether the previous hop node that sends the data packet matches the "legal path source" corresponding to the source address of the data packet, that is, to determine whether the data packet sent from a certain source address (such as 2001:db8:aa::1) should enter through the path segment of the previous hop node. If the source address prefix matches the source address prefix set corresponding to the previous hop node, that is, within the range of the source address prefix set, the path of the data packet is considered to be consistent with the source, and the source address verification of the data packet is determined to be passed. If the source address prefix is ​​not in the source address prefix set corresponding to the previous hop node, its path is considered to be inconsistent with the source, and there may be a risk of path forgery or source address spoofing, thereby realizing the coupling judgment of the path and source. If multiple Segment sources are enabled (such as End.X@R3 and End.X@R6), multiple source node prefix sets can be configured. For example, with Figure 3 For example:

[0099] The current traffic node sequence is: [End.X@R3, End.DX6@R4], the currently active node is End.X@R3, the packet source address is 2001:db8:aa::1, and R4 is the final source address verification point.

[0100] The mapping relationship is preconfigured as:

[0101] End.X@R3 →Legal source address prefix set: (1) 2001:db8:aa:: / 48; (2) 2001:db8:ab:: / 48.

[0102] End.X@R6 →Legal source address prefix set: 2001:db8:cc:: / 48.

[0103] Verification process (occurs on the data plane of R4):

[0104] R4 parses the routing information and locates the currently active node = End.X@R3.

[0105] Query the local mapping table to obtain the "legal source address prefix set" corresponding to End.X@R3.

[0106] Match the source address 2001:db8:aa::1 in the packet with the source address prefix set.

[0107] If the match is successful → it is determined that the path-source coupling relationship is established;

[0108] Otherwise → trigger anomaly detection (such as source address spoofing, path forgery, etc.).

[0109] In some embodiments, the matching policy of the source address prefix can be full match ( / 32), aggregate match ( / 24), or BGP (Border Gateway Protocol) import filtering.

[0110] In this embodiment, on the basis of enabling and disabling the inbound interface on demand, the source address of the data packet is verified to further enhance the accuracy of determining the legitimacy of the source address, thereby enhancing the ability to identify forged traffic.

[0111] To avoid security risks or resource waste caused by maintaining an inbound interface in an open state for a long period of time, this application also introduces an "on-demand dynamic SAV activation and deactivation mechanism" to enable on-demand activation and deactivation of inbound interfaces, dynamically adjusting interface dynamics. In an exemplary embodiment, after enabling the source address verification mechanism on the actual inbound interface, the following steps are further included: starting a timer set for the actual inbound interface; if a new data packet is received within the timer's timer, resetting the timer; and if no new data packet is received within the timer's timer, deactivating the actual inbound interface.

[0112] In a specific implementation, when a certain inbound interface receives a matching legal data packet for the first time, the source address verification policy of the inbound interface is immediately enabled, and a timer is started to control the life cycle of the inbound interface.

[0113] Specifically, after the actual inbound interface is enabled, the data plane of the routing device at the merge node starts a timer. If the actual inbound interface continues to receive valid packets within the timer's duration, the timer will be reset continuously, extending the duration of the source address verification state and ensuring uninterrupted high-availability services. If no new valid packets are received within the timer's duration, the actual inbound interface will automatically close the source address verification state.

[0114] For example, Figure 3 For example, let's assume the timer is set to 30 seconds. When R4's data plane starts source address verification on inbound interface eth2, the timer starts simultaneously. If a new valid packet is received within 30 seconds, the timer is reset, keeping the inbound interface active. The timer is reset each time a new valid packet is received. If no new valid packet is received for more than 30 seconds, the source address verification status for that inbound interface is automatically cleared.

[0115] The source address verification and timing processing processes of this embodiment are all completed autonomously on the data plane, without the participation of the control plane (such as issuing policies or remote synchronization). Compared with traditional control-plane-based verification solutions that require the control plane to update the verification policy and send it to the data plane when a link or node failure occurs, which is difficult to match the fast path convergence capability of the data plane, this solution can significantly reduce convergence delays and synchronization risks.

[0116] In an exemplary embodiment, if the actual input interface matches the predetermined input interface, the source address verification mechanism is enabled on the actual input interface, including: if the actual input interface matches the predetermined input interface, determining the number of interfaces currently opened by the routing device of the merging node; when the number of interfaces currently opened is less than the predetermined interface number threshold, enabling the source address verification mechanism on the actual input interface.

[0117] In a specific implementation, a threshold value for the maximum number of dynamically enabled input interfaces can be pre-configured for each routing device, and the interface number threshold value corresponding to each routing device can be the same or different. After determining that the actual input interface of the data packet arriving at the merge node matches the predetermined input interface, before enabling the source address verification mechanism of the actual input interface, the number of interfaces currently enabled on the routing device of the merge node can be determined. If the number of currently enabled interfaces is less than the predetermined interface number threshold, the source address verification mechanism of the actual input interface is enabled. If the number of currently enabled interfaces is equal to the predetermined interface number threshold, it means that after the actual input interface is enabled, the interface number threshold will be exceeded. Therefore, the addition of the actual input interface can be rejected, and the actual input interface can be enabled after other input interfaces are closed, so as to maintain the number of input interfaces enabled by the routing device of the merge node within the predetermined range.

[0118] In some embodiments, the opening and closing process of each inbound interface is determined by the local FIB, without adding other modules (such as a forwarding module), thereby achieving lightweight deployment.

[0119] In this embodiment, a predetermined interface number threshold is used to maintain the number of input interfaces opened by the routing device of the merged node within a predetermined range. This resource control and anti-spam mechanism can avoid system burdens caused by frequent opening and closing of interfaces or potential attackers exploiting the mechanism to speculate on the interface status, thereby ensuring stable system operation.

[0120] In an exemplary embodiment, the method further includes: obtaining the segment type of the previous hop node; different segment types are used to indicate different processing behaviors of the data packet; determining the normality of the current path of the data packet based on the behavioral logic corresponding to the segment type; if there is an abnormality, triggering a path status alarm.

[0121] The segment type refers to the segment type. A segment is the smallest programmable unit in the segment routing architecture. It represents a logical or physical instruction in the network forwarding path, precisely controlling packet transmission behavior. Each segment is bound to a specific forwarding action or network function through a unique identifier (such as an MPLS label or SRv6 SID).

[0122] Different segment types (such as End.DX6 and End.B6) actually represent different behaviors (behavior types), such as "forward to local interface," "cross-domain forwarding," or "sending the packet to a specific policy." The FIB configures different processing logic for each segment type. Therefore, if a segment type is End.DX6 (forward to local interface), it can be determined that the current segment is the end point and the packet should terminate there. If it is End.B6 (cross-domain forwarding), the path is still in the intermediate state and the next-hop path must be verified for validity. Therefore, based on the current segment type, it is necessary to quickly determine whether the packet is in the valid path stage or has entered the invalid path termination state.

[0123] Specifically, the FIB defines native SRv6 segment types (such as End.DX6 and End.B6) to quickly determine the status of traffic paths. During forwarding, the data plane uses the behavioral logic defined by SRv6 segment types (such as End, End.DX6, and End.B6) combined with the current header and FIB status to determine whether the path is normal. If the segment type does not match or is undefined, a path status alarm or degradation action can be triggered.

[0124] For example, when the data plane resolves to the current segment End.X, it can immediately locate the valid inbound interface information in the FIB entry corresponding to that segment. If the actual inbound interface of the current packet matches the predetermined inbound interface in the FIB, source address verification for that interface can be immediately activated. Otherwise, the default shutdown state is maintained or the untrusted processing path is redirected.

[0125] This embodiment proposes implementing path awareness in the FIB and automatically completing interface determination in combination with the TI-FRR primitive. This mechanism allows the entire path legitimacy determination and interface policy adjustment to rely entirely on fast local FIB lookups, improving execution efficiency without introducing control plane bottlenecks.

[0126] In an exemplary embodiment, the method further includes: if the actual input interface does not match the predetermined input interface, or the source address verification fails, determining that the data packet is a forged data packet; discarding the data packet, and recording the data packet in a security log.

[0127] In the specific implementation, if the actual input interface does not match the predetermined input interface, it is preliminarily judged to be a forged path or an illegal source. Similarly, if the source address verification of the data packet fails, it means that the data packet is illegal. In both cases, the data packet can be regarded as forged traffic and discarded, and can be recorded or triggered by means of logs or other means.

[0128] In some embodiments, all dynamic status and log information involved in the data packet forwarding process can be uniformly and visually managed through a network management platform to facilitate problem tracking and source analysis.

[0129] In this embodiment, by intercepting and processing data packets when the actual input interface does not match the predetermined input interface or the source address verification fails, illegal data packets can be prevented from entering the network, thereby ensuring network security.

[0130] refer to Figure 4 , is a flow chart of a method for verifying the source address of a data packet provided in another embodiment. In this embodiment, the method includes the following steps:

[0131] (1) Receive the data packet routed by the source device, extract the routing information carried by the data packet, and identify the routing path of the data packet based on the routing information.

[0132] (2) When it is determined according to the routing information that the data packet is obtained through the backup path, the previous hop node for sending the data packet is determined according to the routing information.

[0133] (3) Determine the actual inbound interface of the data packet from the previous hop node to the merge node, and query the pre-built node-inbound interface mapping table in the routing device of the merge node to determine the predetermined inbound interface from the previous hop node to the merge node.

[0134] (4) If the actual inbound interface matches the predetermined inbound interface, the number of interfaces currently enabled on the routing device of the merged node is determined; if not, the data packet is discarded.

[0135] (5) When the number of currently enabled interfaces is less than the predetermined interface number threshold, the source address verification mechanism is enabled on the actual inbound interface;

[0136] (6) Verify the source address of the data packet at the actual inbound interface. Specifically, extract the source address prefix in the data packet and query the mapping table to obtain the source address prefix set configured for the previous hop node. Then compare the source address prefix with the source address prefix set corresponding to the previous hop node.

[0137] (7) If the source address verification passes, the data packet is forwarded to the target device through the remaining path; if the source address verification fails, the data packet is discarded.

[0138] This method implements source address verification of data packets routed along the backup path in the routing device of the merging node of the primary and backup paths, without being restricted to the shortest path or static path, and can implement effective verification of the source addresses of data packets in dynamic path scenarios; further, the routing device dynamically opens the relevant input interface for source address verification only when the data packet passes through the backup path, based on the matching result between the actual input interface and the predetermined input interface. This method of opening the routing device port on demand for source address verification can implement flexible and effective traffic verification; further, after the primary path is switched, the fast path recovery based on the TI-FRR mechanism allows the traffic to be verified immediately after the path is switched, which can prevent illegal traffic from entering the network.

[0139] Understandably, the TI-FRR mechanism in Segment Routing provides millisecond-level backup path switching, significantly improving network reliability in failure scenarios. However, TI-FRR focuses on rapid forwarding layer (data plane) recovery—that is, the ability to quickly restore the data plane to a valid path in the event of a path failure (such as a control plane failure, routing loops, or interface flaps)—and does not address the integration with security policies (such as SAV).

[0140] In the existing technology, when the primary path fails and TI-FRR switching is triggered, the data plane can quickly switch paths, but the SAV policy cannot be updated synchronously, which is likely to cause: (1) legitimate traffic is misidentified as forged traffic due to the non-pre-registered interface; (2) the SAV control plane responds laggingly and misses the critical recovery window; (3) attackers disguise themselves as rerouting legitimate traffic to bypass boundary detection.

[0141] Therefore, in order to solve the problems of the existing source address verification mechanism in the fast rerouting scenario, such as delayed policy updates, complex coordination between the data plane and the control plane, and high deployment costs, this application proposes an on-demand source address verification method based on the TI-FRR mechanism, which enables the source address verification function to dynamically and adaptively adjust along the traffic path, effectively improving network security and operational flexibility. The core idea of ​​this solution is to identify the current path status in the TI-FRR backup path through the segment information carried by the data packet, and drive the automatic opening and closing of the source address verification policy of the inbound interface, so as to achieve the interface-level source address verification capability of "on-demand activation and timely shutdown".

[0142] by Figure 3 Taking the network topology shown in FIG. 1 as an example, this method specifically includes the following steps:

[0143] (1) Pre-configuration phase: Constructing a legal Segment-Interface mapping relationship.

[0144] To implement source address verification control on the backup path, the control plane presets the SR Segment List as follows:

[0145] Main path: Segment List = [End (R5)];

[0146] Backup path: Segment List = [End.X (R3→R4), End (R5)].

[0147] At the merging node R4, create the Segment-Interface table entry as follows:

[0148] {Segment: End.X::R3;

[0149] Interface: eth2;

[0150] Source Router-ID: R3;

[0151] Valid prefix list: [10.1.0.0 / 24, 10.1.2.0 / 24];

[0152] Lifetime (TTL): 30s;

[0153] status: disabled;}

[0154] (2) Path switching and strategy activation process.

[0155] When R2 fails, the TI-FRR mechanism is immediately triggered on the data plane of R1. R1 changes the data packet to the path with segment End.X and forwards it to R4 through R3.

[0156] At this point, R4 performs the following operations after receiving the data packet:

[0157] Extract segment information: Parse the SRH and find that the current active segment is End.X, and the corresponding previous hop node is R3.

[0158] Search the mapping table to match the inbound interface: the default inbound interface is eth3, and check whether the packet enters through eth2.

[0159] If the match succeeds, the packet is determined to belong to a legal detour path, and the activation interface policy is executed, that is, the SAV check function is enabled for the eth2 interface and a timer (for example, 30 seconds) is started.

[0160] Subsequent traffic renewal: If the traffic continues, the timer is continuously refreshed to keep SAV enabled.

[0161] (3) Source address verification process.

[0162] After the SAV policy is enabled on interface eth2, the data plane verifies the source address based on the locally cached legal prefix of R3 (for example, 192.168.30.0 / 24).

[0163] If the source address of the data packet is 192.168.30.12, the match is successful and forwarding is allowed;

[0164] If the source address is 10.1.1.1 (not the R3 prefix), it is considered forged, the packet will be discarded, and the security log will be recorded.

[0165] (4) Path recovery and automatic interface shutdown.

[0166] When R2 recovers, the primary path becomes available again. The TI-FRR mechanism restores traffic to the R2→R4 path, and R4's eth2 interface no longer receives traffic from the End.X Segment.

[0167] At this time, the timer automatically times out after 30 seconds, the SAV policy of the eth3 interface is disabled by the system, the resources are released, and the default security state is restored.

[0168] (5) Deployment and expansion instructions.

[0169] This embodiment is implemented entirely based on data plane capabilities and does not require the intervention of an external controller.

[0170] The Segment-Interface mapping table is automatically delivered by the control plane during the path deployment phase. It can also be automatically generated through mechanisms such as BGP-LS (BGP Link-State).

[0171] All interface status and policy switching support logging, facilitating network auditing and security tracking;

[0172] If deployed on network devices with NetConf / YANG interfaces, unified management can also be achieved through the automated policy control platform.

[0173] This method has the following beneficial effects:

[0174] (1) Opening router ports for SAV verification on demand: Based on the TI-FRR mechanism, the router dynamically opens relevant ports for source address verification only when traffic passes through an alternative path. On the one hand, by dynamically opening ports for traffic verification, it effectively prevents forged traffic from entering the network through alternative paths, thereby improving network security. On the other hand, by opening ports for verification only when necessary, it avoids the waste of resources caused by continuously opening ports and reduces resource consumption.

[0175] (2) Fast fault recovery and dynamic path verification: Combined with TI-FRR's fast path recovery, traffic is verified immediately after path switching to prevent illegal traffic from entering the network.

[0176] (3) Flexible adaptation to network topology changes: Routers can automatically adjust SAV rules based on real-time topology changes, ensuring that traffic verification remains effective even in dynamic environments.

[0177] (4) Enhanced network adaptability: The combination of TI-FRR and SAV mechanisms enables the network to quickly adapt to topology changes and path recovery while maintaining traffic legitimacy verification.

[0178] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0179] Based on the same inventive concept, an embodiment of the present application further provides a device for verifying the source address of a data packet for implementing the aforementioned method for verifying the source address of a data packet. The solution provided by the device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of the embodiments of the device for verifying the source address of one or more data packets provided below can be found in the above-mentioned limitations of the method for verifying the source address of a data packet, and will not be repeated here.

[0180] In an exemplary embodiment, Figure 5 As shown, a source address verification device for a data packet is provided, comprising:

[0181] Identification module 510, configured to receive a data packet from a source device, extract routing information carried in the data packet, and identify a routing path of the data packet based on the routing information;

[0182] The sending module 520 is configured to determine the previous hop node to which the data packet is to be sent based on the routing information if the routing path is a backup path;

[0183] Matching module 530, configured to match the actual inbound interface of the data packet arriving at the merging node from the previous hop node with the predetermined inbound interface;

[0184] Verification module 540, configured to enable a source address verification mechanism on the actual inbound interface to verify the source address of the data packet when the actual inbound interface of the data packet matches the predetermined inbound interface;

[0185] The routing module 550 is configured to forward the data packet to the target device through the remaining path if the source address of the data packet is verified successfully.

[0186] In one embodiment, the verification module 540 is also used to extract the source address prefix in the data packet and query the mapping relationship table to obtain the source address prefix set configured for the previous hop node; if the source address prefix matches the source address prefix set corresponding to the previous hop node, it is determined that the source address verification of the data packet is passed.

[0187] In one embodiment, the verification module 540 is also used to start a timer set for the actual input interface; if a new data packet is received again within the timer's timing, the timer is reset; if no new data packet is received within the timer's timing, the actual input interface is closed.

[0188] In one embodiment, the verification module 540 is further used to determine the number of interfaces currently enabled on the routing device of the merging node if the actual input interface matches the predetermined input interface; when the number of interfaces currently enabled is less than the predetermined interface number threshold, enable the source address verification mechanism on the actual input interface.

[0189] In one embodiment, the device also includes an alarm module for obtaining the segment type of the previous hop node; different segment types are used to indicate different processing behaviors of the data packet; based on the behavioral logic corresponding to the segment type, the normality of the current path of the data packet is determined; if there is an abnormality, a path status alarm is triggered.

[0190] In one embodiment, the device further includes a discarding module for determining that a data packet is a forged data packet when the actual input interface does not match the predetermined input interface or the source address verification fails; discarding the data packet and recording the data packet in a security log.

[0191] Each module in the aforementioned data packet source address verification device may be implemented in whole or in part through software, hardware, or a combination thereof. Each module may be embedded in or independent of a processor in a computer device in the form of hardware, or may be stored in a memory in the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0192] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 6As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O) and a communication interface. The processor, memory and input / output interface are connected via a system bus, and the communication interface is connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store data required in the process of verifying the source address of a data packet. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a method for verifying the source address of a data packet is implemented.

[0193] Those skilled in the art will understand that Figure 6 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0194] In one embodiment, a computer device is further provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0195] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0196] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0197] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), quantum computing-based data processing logic devices, artificial intelligence (AI) processors, and the like.

[0198] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0199] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A method for verifying the source address of a data packet, characterized in that: A routing device applied to a merging node in a primary and backup path, wherein the merging node is a node where the backup path rejoins the primary path, and the method includes: receiving a data packet from a source device, extracting routing information carried in the data packet, and identifying a routing path of the data packet based on the routing information; If the routing path is a backup path, determining the previous hop node for sending the data packet according to the routing information; Matching the actual inbound interface of the data packet arriving at the merging node from the previous hop node with the predetermined inbound interface; If the actual inbound interface of the data packet matches the predetermined inbound interface, a source address verification mechanism is enabled on the actual inbound interface to verify the legitimacy of the source address of the data packet; If the source address of the data packet passes the verification, the data packet is forwarded to the target device through the remaining path.

2. The method according to claim 1, characterized in that The verifying the legitimacy of the source address of the data packet includes: Extracting the source address prefix in the data packet and querying a pre-built mapping relationship table to obtain a source address prefix set configured for the previous hop node; If the source address prefix matches the source address prefix set corresponding to the previous hop node, it is determined that the source address verification of the data packet is passed.

3. The method according to claim 1, characterized in that After the source address verification mechanism is enabled on the actual inbound interface, the method further includes: Starting a timer set for the actual input interface; If a new data packet is received again within the timing of the timer, the timer is reset; If no new data packet is received within the timing time of the timer, the actual input interface is closed.

4. The method according to claim 1, wherein If the actual inbound interface of the data packet matches the predetermined inbound interface, enabling a source address verification mechanism on the actual inbound interface includes: If the actual input interface matches the predetermined input interface, determining the number of interfaces currently enabled on the routing device of the merging node; When the number of currently enabled interfaces is less than a predetermined interface number threshold, a source address verification mechanism is enabled on the actual inbound interface.

5. The method according to claim 1, wherein The method further comprises: Obtaining the segment type of the previous hop node; different segment types are used to indicate different processing behaviors of the data packet; determining the normality of the current path of the data packet according to the behavior logic corresponding to the segment type; If there is an abnormality, a path status alarm will be triggered.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: If the actual inbound interface does not match the predetermined inbound interface, or the source address verification fails, determining that the data packet is a forged data packet; The data packet is discarded and recorded in a security log.

7. A device for verifying the source address of a data packet, characterized in that: A routing device is provided at a merging node in a primary and backup path, wherein the merging node is a node where the backup path rejoins the primary path. The device includes: an identification module, configured to receive a data packet from a source device, extract routing information carried in the data packet, and identify a routing path of the data packet based on the routing information; a sending module, configured to determine, when the routing path is a backup path, a previous hop node to which the data packet is sent according to the routing information; a matching module, configured to match an actual inbound interface of the data packet arriving at the merging node from the previous hop node with a predetermined inbound interface; a verification module, configured to enable a source address verification mechanism on the actual inbound interface to verify the legitimacy of the source address of the data packet if the actual inbound interface of the data packet matches the predetermined inbound interface; The routing module is used to forward the data packet to the target device through the remaining path when the source address of the data packet is verified.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images