IPsec Packet Processing in SoC Data Paths
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing inline IPsec processing schemes are inadequate for routing platforms where IPsec is just one feature in the middle of the data path, as they fail to efficiently handle packet classification, SA lookups, and decryption due to resource limitations and complex packet processing paths.
Innovation Solution
The implementation of a hardware look-up table for packet classification using the IP 5-tuple and SPI as lookup keys, along with a software SA look-up table for scaling, and out-of-place decryption mechanisms to handle complex packet processing, allowing dynamic swapping of table entries and efficient distribution of decrypted packets.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If a simple inline IPsec scheme is used, then the implementation is straightforward and resources are minimal, but it cannot handle packet processing paths where IPsec is in the middle of multiple data path features
Solution Approach 1:
The packet processing path is segmented into multiple stages: packet classification stage (using hardware tables for IP 5-tuple and SPI lookup), IPsec processing stage (using hardware/crypto engine for decryption/encryption), and feature array stage (where processed packets are inserted at correct positions). This segmentation allows each stage to handle specific tasks independently, enabling IPsec to operate in the middle of multiple data path features without requiring a complete redesign of the processing architecture.
2Speed
If hardware look-up tables are used for packet classification and SA lookup, then processing speed is improved, but hardware resources are consumed and table capacity is limited
Solution Approach 1:
The system transitions from a single-level hardware lookup table to a hierarchical structure combining hardware tables (for fast IP 5-tuple and SPI classification) with software-based SA lookup tables. The hardware tables handle the first dimension of classification quickly, while the software tables provide unlimited capacity for SA storage. This dimensional transition allows the system to achieve both high processing speed through hardware acceleration and unlimited scalability through software supplementation.
3Productivity
If IPsec processing is performed inline in the data path, then processing efficiency is improved, but it becomes difficult to handle packets where IPsec features are in the middle of other data path features
Solution Approach 1:
The system dynamically adapts the packet processing path based on the position of IPsec features in the feature array. When IPsec is detected in the middle of other features, the system dynamically reorders processing operations: first processing non-IPsec features, then performing IPsec decryption/encryption, and finally inserting the processed packet at the correct position in the feature array. This dynamic adaptation maintains high processing efficiency while accommodating complex packet processing paths.
Data Source
AI summary
Techniques and mechanisms for IPsec processing of IPsec packets for routing platforms where IPsec is just one or more features in the middle of data path features on the packet processing path and hence, the typical, simple inline IPsec scheme does not work well for such platforms. The techniques include using a hardware look-up table for packet classification and inbound security association (SA) lookup in one pass with IP 5-tuple plus SPI as a lookup key at hardware table. The techniques provide an entry match action format and mechanism for deriving inbound SA dram addresses that may be used by a hardware (HW)/firmware (FW) crypto/IPsec engine to process inbound packet traffic. A software SA look-up table is also provided to overcome hardware look-up table resource limitations and support more IPsec session scaling than the physical hardware look-up table can handle. Additional techniques are described.