A hardware acceleration method and system for routing path verification based on a programmable chip

Abstract

This invention discloses a hardware acceleration method and system for route path verification based on a programmable chip. The system includes a control plane and a data plane. The control plane maintains a global routing view, executes security verification algorithms based on RPKI and ASPA, and converts the verification results into forwarding behavior instructions. The control plane includes a security offload engine responsible for handling ECDSA signature verification for BGPsec and topology analysis for ASPA, interacting with the protocol daemon through an asynchronous queue; an adaptation and synchronization layer to resolve data structure differences between the control plane and the data plane and ensure eventual consistency between their states; and a data plane that performs line-fast lookup, packet filtering, and metadata tagging based on a "match-action" table issued by the adaptation and synchronization layer. The data plane includes a programmable parser for identifying BGP packet characteristics and extracting key fields for verification; and an FSM-based ASPA verification module and a cache-based BGPsec verification module.

Description

Technical Field

[0001] This invention belongs to the field of routing security protection technology, and specifically relates to a hardware acceleration method and system for routing path verification based on a programmable chip. Background Technology

[0002] Border Gateway Protocol (BGP) is the foundation for interconnectivity between Autonomous Systems (AS). As network security requirements evolve from single-source verification to end-path verification, the secure verification of BGP routing path topology and integrity faces unprecedented computational complexity challenges. Path verification (such as BGPsec and ASPA) has transformed into a high-computation-density, high-memory-access problem involving cryptographic operations and graph-based state machine traversal, posing significant performance challenges in traditional general-purpose CPU-based software routing architectures.

[0003] Autonomous System Provider Authorization (ASPA) is used to verify the rationality of path topology (i.e., compliance with the "valley-free" routing principle). Although ASPA does not involve real-time cryptographic computation, its verification requires multiple non-contiguous memory accesses within a massive graph data structure containing a huge number of nodes and edges. Due to the extremely discrete distribution of AS numbers, the CPU's L1 / L2 cache hit rate is extremely low. In high-throughput scenarios with massive route updates, main memory access latency becomes a serious efficiency bottleneck.

[0004] BGPsec (RFC 8205) protects path integrity through a hop-by-hop digital signature mechanism, but its ECDSA signature verification based on the P-256 curve involves complex cryptographic operations. On a general-purpose CPU, a single core can only process a few thousand verifications per second, and the verification overhead increases exponentially with the route path length (number of hops). Tests show that when the path length reaches 4-5 hops, BGPsec verification time accounts for more than 50% of the total processing time, severely slowing down route convergence. Furthermore, hop-by-hop signing also causes memory overhead to increase linearly with the number of routing entries.

[0005] Traditional fixed-function network devices (such as traditional hard routers) have long feature iteration cycles, making it difficult to cope with rapidly evolving security standards; while all-software routers face enormous control plane computational overload under large-scale throughput. Therefore, how to offload path verification logic to the data plane using a dedicated hardware architecture, and how to achieve line-speed verification and rapid feature expansion using pipelined parallelism and dedicated acceleration units, are urgent engineering and theoretical challenges to be solved in the field of routing security. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the prior art, focusing on the hardware expansion and acceleration of security verification functions. By decoupling the security verification process into high-speed data plane extraction and filtering and parallel computing of the control plane / heterogeneous engine, high-performance path verification and flexible function expansion can be achieved.

[0007] To achieve the above objectives, on the one hand, the present invention provides a hardware acceleration method for routing path verification based on a programmable chip, the method comprising the following steps:

[0008] A hardware cache table is set up in the data plane. When an Update message with BGPsec attributes is received, the fingerprint of the path and associated fields is calculated using the fast mapping matching method of the programmable chip, and the hardware cache table is queried: if the cache hits and the status is a valid VALID, the hardware directly allows the message at line speed; if the cache hits and the status is an invalid INVALID, the hardware directly executes a drop or degradation policy; if the cache misses, the message is copied and sent to the control plane, and the original message is marked as "unverified" to allow it to be temporarily forwarded but not to participate in the optimization, thus not blocking route propagation; after the control plane calls the security offload engine to perform batch ECDSA signature verification, the verification results are written back to the hardware cache table through an asynchronous channel; and

[0009] In the secure execution pipeline of the data plane, a parallel finite state machine (FSM) is constructed using a multi-level table application strategy. The state transition rules follow the state transition table: in the UP or START state, if a C2P match is found, the state remains or transitions to UP; if a C2P / P2P match is found in the reverse direction in the APEX or DOWN state, the state machine directly jumps to FAIL; once the state machine triggers FAIL at any stage, the hardware immediately performs a discard or marking action at line speed.

[0010] On the other hand, the present invention provides a hardware acceleration system for routing path verification based on a programmable chip, the system comprising: a control plane and a data plane, wherein,

[0011] Control plane: Used to maintain a global routing view, execute security authentication algorithms based on RPKI and ASPA, and convert authentication results into forwarding behavior instructions; the control plane includes:

[0012] Security offload engine: Responsible for handling BGPsec ECDSA signature verification and complex topology analysis of ASPA, interacting with the protocol daemon process through asynchronous queues to avoid blocking the main router thread;

[0013] Adaptation and synchronization layer: used to resolve data structure differences between the control plane and the data plane, and to ensure eventual consistency of their states;

[0014] Data plane: performs quick lookup, message filtering, and metadata tagging based on the "match-action" table issued by the adaptation and synchronization layer; the data plane includes:

[0015] A programmable parser is used to identify BGP message characteristics and extract key fields for verification.

[0016] The module includes an FSM-based ASPA verification module and a cache-based BGPsec verification module, which contain a series of lookup-matching tables to implement ASPA checks based on finite state machine (FSM) and BGPsec verification based on cache.

[0017] This invention, through hardware-software collaboration, multi-stage pipeline parallelism, and cache redirection mechanisms, greatly reduces the CPU computation and memory access load on the control plane, providing a path verification technology solution for global Internet routing systems that combines high throughput acceleration performance with rapid software-level scalability. Attached Figure Description

[0018] Figure 1 A schematic diagram of a hardware acceleration system for routing path verification based on a programmable chip, provided for an embodiment of the present invention;

[0019] Figure 2 A diagram of a BGPsec hardware offloading architecture based on caching and redirection provided in an embodiment of the present invention;

[0020] Figure 3 A diagram illustrating the state transition to verify the valley-free principle;

[0021] Figure 4 This is a schematic diagram of an ASPA hardware pipeline design based on multi-level table applications. Detailed Implementation

[0022] To enable those skilled in the art to more fully understand and implement the present invention, the technical solution of the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.

[0023] Figure 1 This is a schematic diagram of a hardware acceleration system architecture for routing path verification based on a programmable chip, provided as an embodiment of the present invention. Figure 1As shown, this invention proposes a "hardware-software hybrid" system architecture for data packet verification and processing. This system mainly comprises a control plane and a data plane. The control plane (CPU) handles the complex "matching" logic involving cryptographic operations (BGPsec signature verification) and graph theory computations (ASPA topology construction). The data plane (programmable chip) is responsible for line-speed data packet extraction and verification. The data plane performs line-speed extraction and preliminary filtering through a hardware pipeline and a pre-computed hardware cache table (BGPsec_Cache). The control plane and the Security Offload Engine are responsible for asynchronously maintaining the global security state and performing high-density computations. Since the hardware pipeline only needs to match the "match-action" entries issued by the synchronization layer, when security standards or verification algorithms evolve, only the policy computation logic of the control plane needs to be updated, or different state transition and filtering rules need to be dynamically issued through the southbound interface (P4Runtime). This allows for rapid expansion and elastic upgrades of the security verification function without replacing or modifying the underlying fixed hardware.

[0024] Specifically, the control plane runs on a general-purpose x86 server, equipped with a software routing suite. Its core responsibilities are maintaining the global routing view (RIB), executing complex security verification algorithms based on RPKI and ASPA, and translating the verification results into specific forwarding instructions. It mainly includes the following core modules: Routing Protocol Daemon: Responsible for maintaining BGP sessions, receiving routing updates, executing path selection algorithms, and acting as the kernel manager for routing information, summarizing and distributing routing information from various protocols. RPKI Client: Responsible for synchronizing with the global RPKI trust anchor, obtaining RPKI data objects, and generating rules for use by the data plane. Security Offload Engine: An independent multi-threaded service dedicated to handling BGPsec ECDSA signature verification and complex ASPA topology analysis. It interacts with the protocol daemon through an asynchronous queue to avoid blocking the main routing thread.

[0025] Adaptation and Synchronization Layer: Serving as the link between hardware and software, this layer primarily functions as the P4Runtime agent. Its main function is to resolve data structure differences between the control plane (software objects) and the data plane (hardware entries), and to ensure eventual consistency between their states. This embodiment of the invention uses gRPC as the transport protocol, responsible for pushing action parameters and security configurations to the hardware switch. Simultaneously, it is also responsible for transmitting data (such as drop counts and verification failure events) back from the switch to the control plane.

[0026] The data plane is based on a hardware pipeline defined using the P4 switch language. It lacks a complex protocol stack, performing only quick lookup, packet filtering, and metadata tagging based on the "match-action" table issued by the synchronization layer. It mainly consists of three parts: a programmable parser (custom parser) capable of recognizing BGP packet characteristics and extracting key fields for verification (NLRI, AS_PATH, etc.); an FSM-based ASPA verification module and a cache-based BGPsec verification module, containing a series of lookup-match tables to implement FSM-based ASPA checks and cache-based BGPsec verification.

[0027] To further elucidate the operational mechanism of the hardware-software integrated system, this embodiment of the invention outlines the core process as two closed loops: control plane state construction and distribution, and data plane verification and anomaly reporting. This design ensures that even when hardware resources are limited or complex security scenarios that cannot be handled are encountered, the system can still guarantee business continuity through a software fallback mechanism.

[0028] First, the control plane is responsible for transforming global internet routing security knowledge into hardware entries understandable to the data plane. This is the cornerstone of the system's security defense. The corresponding control plane RPKI client periodically synchronizes RPKI data from global RIRs (such as RIPE and ARIN) and simultaneously retrieves topology authorization information from the ASPA database, performing structured transformations. This primarily includes constructing a network-wide AS interconnection topology map based on ASPA records and converting it into a state transition table suitable for hardware FSMs. The completed entries are then distributed to the data plane via the P4Runtime interface of the adaptation layer. Furthermore, for incremental updates (such as newly issued data objects), the adaptation and synchronization layers only calculate the differences and perform atomic updates, minimizing control channel occupancy.

[0029] The data plane is responsible for line-rate verification and anomaly reporting. When a BGP Update message enters the programmable chip (P4 switch), the programmable parser extracts key fields such as NLRI (prefix), Origin AS, and AS_PATH. It then drives the hardware finite state machine (FSM) to verify whether AS_PATH conforms to the "valley-free routing" principle. Figure 3(Diagram illustrating state transition verification for the valleyless principle). When the above verification process is verifiable and valid, the hardware tags the packet with "Hardware-Verified" metadata and sends it to the control plane software router suite via the CPU port for regular route learning. At this point, time-consuming ROV / ASPA calculations are no longer required. When an invalid route is encountered, the hardware either discards the packet and counts it, or tags it "Invalid" and sends it to the control plane for further processing, depending on the configuration policy. Packets that the hardware cannot process, such as BGPsec packets or packets exceeding the hardware resolution depth (e.g., AS_PATH > 16 hops), are uniformly marked, directly encapsulated, and sent to the control plane for unified processing. Upon receiving the sent packet, the control plane checks the metadata tag. For packets marked "Pending," it schedules them to the security offloading engine for software-level BGPsec signature verification or complex logic verification. After verification, it merges the hardware and software verification results, updates the RIB (Routing Table), and decides whether to write the final route to the forwarding plane (FIB).

[0030] Figure 2 This is a diagram illustrating a BGPsec hardware offloading architecture based on caching and redirection, provided as an embodiment of the present invention. Figure 2 As shown, due to the computationally intensive nature of BGPsec, signature verification cannot be completed within the P4 switch. Therefore, this embodiment of the invention designs an offloading architecture based on caching and redirection, maintaining a cache table in the data plane for quickly retrieving verification results of known paths. When the P4 switch receives an Update packet with BGPsec attributes, it executes the following logic: First, a hash calculation is performed, and the programmable parser extracts the relevant BGPsec fields and calculates its fingerprint. Then, a cache query is performed. If the fingerprint exists in the cache and its status is VALID, it is allowed directly; if it is INVALID, it is discarded or its priority is reduced. When a miss occurs, it indicates a new path, and the following two actions are performed: First, the packet is copied and sent to the control plane security offloading engine; then, the original packet is marked "unverified," allowing it to temporarily enter the routing table, but it does not participate in the optimization (or is given a very low priority). The entire process does not block route propagation, but limits its scope of influence. Once the control security offloading engine completes ECDSA verification, it writes the result (Valid / Invalid) to the control plane. The control plane then sends the (Fingerprint, Result) entry to the data plane's cache table via the P4Runtime interface. Furthermore, if the verification result is INVALID, the control plane sends a Withdraw command to the router, removing the previously temporarily allowed "unverified" route.

[0031] Through the above design, the programmable hardware device acts as an extremely efficient "filter" and "distributor," sending only new path fingerprints to the more expensive verification engine, while the vast majority of repetitive routing updates will hit the hardware cache, thereby enabling high-performance BGPsec deployment at the network scale.

[0032] Figure 4 This is a schematic diagram of an ASPA hardware pipeline design based on multi-level table applications. Figure 4 As shown, the core of ASPA is to verify whether the path conforms to the "valley-free" attribute. This embodiment of the invention designs a parallel finite state machine based on a lookup-match table in the Ingress Pipeline of the P4 programmable switch. The "lookup-match" behavior logic of the programmable switch chip follows a pipelined key-value processing paradigm. Its core process is as follows: First, after the ingress packet is parsed, the Match-Action Unit (MAU) extracts preset tuple fields (such as quintuples, metadata) to form a lookup key. Subsequently, this key value is distributed in parallel to the on-chip high-speed memory (SRAM / TCAM) for concurrent retrieval. The logical judgment depends on the hardware characteristics of the memory unit: if based on an exact match table (EM), an equality comparison is performed; if based on a prefix match (LPM) or access control table (ACL), the longest prefix or mask overlay determination is performed. Once a hit is achieved, the hardware immediately returns the corresponding Action Index and parameters, driving the pipeline to perform operations such as forwarding, rewriting, or discarding. The entire process is completed within a single clock cycle, realizing a low-latency mapping of control plane policies to data plane line-rate behavior.

[0033] Based on the IETF draft standard, the ASPA path should follow: Up-Ramp → Apex → Down-Ramp. Based on this principle, a finite state machine (FSM) with valley-free verification is proposed. The FSM state is defined as a P4 register or metadata value, as detailed below:

[0034] STATE_START (0): Initial state.

[0035] STATE_UP (1): In the uphill phase (continuous C2P).

[0036] STATE_APEX (2): At the peak (just passed P2P).

[0037] STATE_DOWN (3): In the downhill phase (continuous P2C).

[0038] STATE_FAIL (4): Verification failed (an illegal topology was detected, such as Down followed by Up).

[0039] Since the hardware cannot traverse the entire path within a single clock cycle, this embodiment of the invention decomposes the verification into steps targeting adjacent AS pairs. Given atomic operations, design the following state transition table.

[0040] START (0) C2P UP (1) Continue Normal uphill START (0) P2P APEX (2) Continue Reach the summit directly START (0) P2C DOWN (3) Continue direct downhill UP (1) C2P UP (1) Continue Continue uphill UP (1) P2P APEX (2) Continue Reaching the summit UP (1) P2C DOWN (3) Continue Start going downhill APEX (2) P2C DOWN (3) Continue Downhill after the summit APEX (2) C2P / P2P FAIL (4) Drop / Mark Illegal: No further uphill or equivalent climbs are allowed after reaching the summit. DOWN (3) P2C DOWN (3) Continue Continue downhill DOWN (3) C2P / P2P FAIL (4) Drop / Mark Illegal: It is not allowed to go against the flow of traffic after going downhill.

[0041] To resolve the conflict between the variable-length nature of the AS_PATH attribute and the fixed-length resolution of hardware, the programmable parser introduces finite loop unrolling in the Parser. The unrolled resolution states are defined from parse_asn_0 to parse_asn_N (N is set to 16 or 32), and the actual path length, path_len, is recorded in metadata. For extremely long paths exceeding the hardware resolution depth, the programmable parser marks meta.truncated = 1 and sends it to the control plane. Then, it marks the original packet as "unverified," allowing it to temporarily enter the routing table but not participate in route optimization (or setting it to a very low priority). This process does not block route propagation but limits its impact. Upon receiving the sent packet, the control plane parses the meta.truncated mark and sends the packet to the security offload engine. The security offload engine verifies the extreme-length path and writes the result (Valid / Invalid) to the control plane. If the verification result is INVALID, the control plane sends a Withdraw command to the router, removing the previously temporarily allowed "unverified" route.

[0042] In the secure execution pipeline of the programmable data plane, for regular non-extreme length paths, such as path length n, the programmable parser introduces finite loop unrolling in the Parser, using parse_asn_0 to parse_asn_n-1 to parse the n AS numbers corresponding to the AS_PATH attribute. After parsing, a parallel finite state machine (FSM) is constructed using a multi-level table application strategy: the system defines the legal ASPA path states as: START(0), UP(1) (continuous C2P), APEX(2) (passing through P2P), DOWN(3) (continuous P2C), and FAIL(4) (illegal topology). Since the hardware cannot traverse the entire path in one cycle, pipelined replication is performed during the processing stage of the programmable hardware chip. Stage 1 extracts and matches the adjacency relationships (C2P / P2P / P2C) of Hop 1-2, and combines the current state to transition to the next state; Stage 2 then matches Hop 2-3, and so on. The state transition rules strictly follow the state transition table: in the UP or START state, if a C2P match is found, the state remains or transitions to UP; if a C2P / P2P match is found in the APEX or DOWN state, the state machine directly jumps to FAIL. Once the state machine triggers FAIL at any stage, the hardware immediately performs a drop or mark action at line speed. The entire topology verification is completed within a few hundred nanoseconds of a single data packet passing through the pipeline.

[0043] The embodiments of the present invention, through the above-mentioned hardware and software collaboration, multi-stage pipeline parallelism and cache redirection mechanism, greatly release the CPU computing and memory access load of the control plane, and provide a path verification technology solution for the global Internet routing system that has both high throughput acceleration performance and software-level rapid expansion capability.

[0044] The specific embodiments described above further illustrate the purpose, technical solutions, and beneficial effects of the multiple embodiments disclosed in this specification. It should be understood that the above description is only within the scope of this specification. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solutions of the multiple embodiments disclosed in this specification should be included within the protection scope of the multiple embodiments disclosed in this specification.

Claims

1. A hardware acceleration method for routing path verification based on a programmable chip, applied to a hardware acceleration system consisting of a control plane and a data plane, characterized in that, The method steps include: A hardware cache table is set up in the data plane. When an Update message with BGPsec attributes is received, the fingerprint of the path and associated fields is calculated using the fast mapping matching method of the programmable chip, and the hardware cache table is queried: if the cache hits and the status is valid VALID, the hardware directly allows the message at line speed; if the cache hits and the status is invalid INVALID, the hardware directly executes the discard or degradation policy; if the cache misses, the message is copied and sent to the control plane, and the original message is marked "unverified" to allow it to be temporarily forwarded but not to participate in the optimization, thus not blocking route propagation; after the control plane calls the security offload engine to perform batch ECDSA signature verification, the verification results are written back to the hardware cache table through an asynchronous channel; and In the secure execution pipeline of the data plane, a parallel finite state machine (FSM) is constructed using a multi-level table application strategy. The state transition rules follow the state transition table: in the UP or START state, if a C2P match is found, the state remains or transitions to UP; if a C2P / P2P match is found in the reverse direction in the APEX or DOWN state, the state machine directly jumps to FAIL; once the state machine triggers FAIL at any stage, the hardware immediately performs a discard or marking action at line speed.

2. The method according to claim 1, characterized in that, FSM status is defined as a P4 register or metadata value, as detailed below: STATE_START(0): Initial state; STATE_UP(1): In the uphill phase, i.e., continuous C2P; STATE_APEX(2): At its peak, meaning it has just passed through P2P; STATE_DOWN(3): In the downhill phase, i.e., continuous P2C; STATE_FAIL(4): Verification failed, i.e. an illegal topology was detected, such as Down followed by Up.

3. The method according to claim 1, characterized in that, The process involves periodically synchronizing RPKI data from the global RIR database, retrieving topology authorization information from the ASPA database, and performing structured transformation. The main steps include: Based on ASPA records, a network-wide AS interconnection topology is constructed and transformed into a state transition table suitable for hardware FSM. The completed table entries are sent to the data plane through the P4Runtime interface of the adaptation and synchronization layer. Meanwhile, for incremental updates, the adaptation and synchronization layer calculates the differences and performs atomic updates.

4. A hardware acceleration system for route path verification based on a programmable chip, characterized in that, Includes: control plane and data plane, where, Control plane: Used to maintain a global routing view, execute security authentication algorithms based on RPKI and ASPA, and convert authentication results into forwarding behavior instructions; the control plane includes: Security offload engine: Responsible for handling ECDSA signature verification of BGPsec and topology analysis of ASPA. It interacts with the protocol daemon process through an asynchronous queue to avoid blocking the main router thread; Adaptation and synchronization layer: used to resolve data structure differences between the control plane and the data plane, and to ensure eventual consistency of their states; Data plane: performs quick lookup, message filtering, and metadata tagging based on the "match-action" table issued by the adaptation and synchronization layer; the data plane includes: A programmable parser is used to identify BGP message characteristics and extract key fields for verification. The module includes an FSM-based ASPA verification module and a cache-based BGPsec verification module, which contain lookup-matching tables to implement ASPA checks based on finite state machine (FSM) and BGPsec verification based on cache.

5. The system according to claim 4, characterized in that, The control plane also includes: Routing protocol daemons: responsible for maintaining BGP sessions, receiving route updates, executing path selection algorithms, and acting as the kernel manager for routing information, summarizing and distributing routing information from various protocols; and RPKI Client: Responsible for synchronizing with the global RPKI Trust anchor, obtaining RPKI data objects, and generating rules for use by the data plane.

6. The system according to claim 4, characterized in that, The adaptation and synchronization layer uses gRPC as the transmission protocol, which is responsible for pushing action parameters and security configurations to the programmable chip; at the same time, it is responsible for transmitting data back from the switch to the control plane.

7. The system according to claim 4, characterized in that, The adaptation and synchronization layer is a P4Runtime proxy.

8. The system according to claim 4, characterized in that, The control plane runs on a general-purpose x86 server and is equipped with a software routing suite; the data plane is a P4 programmable switching data plane.

Images