硬件加速IPsec ESP协议：SEC引擎描述符与PDB配置实战-编程阁

1. 项目概述：硬件加速下的IPsec ESP协议处理

在网络通信安全领域，尤其是在企业VPN网关、物联网设备安全传输以及5G核心网边缘计算节点中，IPsec协议是保障数据机密性、完整性和认证性的基石。然而，随着网络带宽的飙升和延迟要求的严苛，传统的纯软件IPsec处理方式逐渐力不从心。软件处理每个数据包都需要CPU执行复杂的加密、认证算法，并维护庞大的安全关联状态表，这在高并发场景下极易成为性能瓶颈，导致吞吐量下降和延迟抖动。

为了解决这一痛点，硬件协议加速技术应运而生。其核心思想是将网络协议栈中计算最密集、最标准化的部分，特别是加密、解密、消息认证码（MAC）计算等操作，卸载到专用的硬件安全引擎中执行。SEC（Security Engine）就是这样一种典型的硬件加速模块，常见于NXP QorIQ系列等高性能网络处理器中。它并非简单地提供一个AES或SHA的硬件计算单元，而是将整个协议处理流程，如IPsec ESP的封装与解封装，抽象成一系列由硬件直接执行的“描述符命令”。开发者通过编排这些命令，描述一个数据包需要经历的所有操作（如添加ESP头、加密载荷、计算ICV等），SEC硬件便能自动、流水线化地完成整个处理流程，从而将CPU彻底解放出来，专注于策略控制、路由转发等更高层的逻辑。

这种硬件加速带来的收益是巨大的。首先，它实现了确定性的高性能。无论CPU负载如何波动，SEC都能以接近线速处理加解密数据流，保证了VPN隧道的稳定吞吐。其次，它降低了系统功耗和CPU占用率，使得设备可以在处理海量安全流量的同时，仍有余力运行其他应用服务。最后，硬件实现的协议状态机（如序列号管理、反重放窗口检查）更为可靠和高效，减少了软件实现中可能出现的竞态条件和逻辑错误。

本文将深入解析SEC引擎如何加速IPsec ESP协议。我们将从核心的共享描述符与协议数据块（PDB）机制讲起，拆解封装与解封装的数据流与状态管理，并详细探讨隧道模式与传输模式下的不同PDB配置。最后，我会结合自己的工程实践，分享在利用SEC进行IPsec加速时遇到的典型“坑”及其规避技巧，例如共享描述符的类型选择、IV生成模式对性能的影响，以及如何正确配置反重放检测以避免丢包。无论你是正在评估硬件加速方案的网络工程师，还是需要为嵌入式设备实现高性能IPsec的开发者，相信这些从芯片手册和实际调试中总结出的细节，都能为你提供直接的参考。

2. SEC加速引擎的核心架构：描述符与协议数据块

要理解SEC如何加速IPsec，必须先搞懂它的工作模式。你可以把SEC想象成一个拥有多个“流水线车间”（DECO）的工厂。CPU（工厂经理）不亲自处理每个数据包（产品），而是为每一类产品（例如，同一条IPsec隧道上的所有数据包）编写一份“标准作业指导书”，然后交给车间去自动执行。这份“指导书”就是共享描述符（Shared Descriptor），而指导书中针对特定产品型号的个性化参数页，就是协议数据块（PDB, Protocol Data Block）。

2.1 共享描述符：可复用的处理模板

一个描述符本质上是一个指令序列，告诉SEC要对输入的数据帧做什么。对于IPsec ESP封装，这个指令序列大致是：“读取IP头，提取五元组信息，查找对应的安全关联（SA），添加ESP头，使用指定的密钥和算法加密载荷，计算并附加完整性校验值（ICV），更新输出长度，最后将处理完的帧写回内存”。

如果每个数据包都单独携带这么一长串指令，会造成巨大的内存带宽和初始化开销。因此，SEC引入了共享描述符。对于同一条IPsec隧道（即同一个安全关联）的所有数据包，它们所需的处理步骤、使用的加密算法、认证算法都是完全相同的，不同的仅仅是每包的状态信息，比如序列号（Sequence Number）。共享描述符机制允许我们将固定的指令部分（算法、密钥指针等）和可变的状态部分（序列号、IV等）分离。

具体做法是：创建一个共享描述符，其中包含固定的协议命令（如“执行IPsec封装”）和一块预留的存储区域——PDB。这个共享描述符被预先加载到SEC能够访问的系统内存中。当需要处理一个数据包时，我们只需要提交一个非常轻量级的“任务描述符（Job Descriptor）”。这个任务描述符主要包含两个关键信息：1）输入/输出数据帧在内存中的地址；2）指向那个共享描述符的指针。SEC的DECO单元会找到共享描述符，读取其中的指令和PDB的初始状态，然后开始处理数据包。处理过程中，如果需要更新状态（比如序列号加1），DECO会将新状态写回内存中的那个PDB里。

2.2 协议数据块：安全关联的状态容器

PDB是嵌入在共享描述符内部的一个数据结构，它是SEC协议加速的灵魂。对于IPsec ESP，PDB里存放了该安全关联的所有必要信息，主要包括：

静态参数：安全参数索引（SPI）、使用的加密/认证算法标识（通过PROTINFO字段定义）、是否是隧道模式、是否使用扩展序列号（ESN）等。这些在隧道建立后通常不变。
动态状态：序列号（Sequence Number）、扩展序列号（高32位）、以及用于CBC模式的链式IV（Chained IV）。这些信息每处理一个包就需要更新。
可选配置：外部IP头的内容（用于隧道模式）、IP头长度、Next Header偏移量等。
反重放信息：在解封装侧，PDB中还包含一个“反重放计分卡”，用于实现滑动窗口，检测重复或乱序到达的包。

PDB的格式并非一成不变，它根据所选用的加密套件（Cipher Suite）而有所不同。例如，使用AES-CBC算法时，PDB中需要预留空间来存储或传递IV；而使用AES-GCM时，则需要存储Salt（盐值）和IV。芯片手册中会为每种加密套件定义其特定的PDB字段布局。

2.3 共享类型的选择：性能与正确性的权衡

多个DECO可以并行处理任务。共享描述符的“共享”方式，直接影响了并行处理的正确性和效率。SEC主要支持几种共享类型，在描述符头部通过SHARE字段指定：

WAIT共享：这是最常用且最安全的方式。当一个DECO正在使用某个共享描述符（及其PDB）处理任务时，它会设置一个“锁”（OK to Share信号）。其他DECO如果想处理同一隧道的数据包，看到锁被占用，就会等待，直到前一个DECO更新完PDB（如序列号）并释放锁后，才获取最新的PDB副本进行处理。这完美保证了同一隧道数据包的序列号严格递增，避免了重复。在IPsec中，只要使用了链式IV（Chained IV），就必须使用WAIT共享，因为下一个包的IV依赖于上一个包的密文。
SERIAL共享：强制所有使用该共享描述符的任务在同一个DECO上串行执行。这完全避免了并发冲突，是最安全的，但可能造成DECO利用率不均，如果某个隧道流量很大，绑定的DECO就会成为瓶颈，而其他DECO空闲。
ALWAYS共享：多个DECO可以同时读取同一份共享描述符和PDB的副本进行处理，完全不考虑状态更新冲突。这在使用随机IV（Random IV）且不关心严格序列号递增的某些特殊场景下可能可用，但对于IPsec ESP，绝对不要使用！因为它会导致多个包拥有相同的序列号，严重违反协议，接收端会因反重放检测而丢弃这些包。
NEVER共享：每个任务都从系统内存中获取一份全新的共享描述符和PDB副本。这同样会导致状态不同步，例如，DECO A和B都读取了序列号为N的PDB，处理后都将其更新为N+1写回，但后写回的操作会覆盖前一个，导致序列号丢失。这也可能产生重复序列号。

实操心得：共享描述符配置的坑在我早期的一个VPN网关项目中，曾遇到一个诡异的间歇性丢包问题。隧道建立正常，大流量测试时吞吐量也达标，但总会随机丢失一些包。抓包分析发现，接收端提示“重复的序列号”。排查良久才发现，问题出在共享描述符的配置上。我们为每条隧道创建了一个共享描述符，但错误地将其设置为NEVER共享。我们的本意是让每个包独立，但忽略了SEC硬件在写回更新后的PDB时存在延迟。两个核心几乎同时处理同一隧道的包，都读到了旧的序列号，处理完后写回，后一个写操作覆盖了前一个，导致序列号没有递增，从而产生重复。将共享类型改为WAIT后，问题彻底消失。这个教训告诉我，对于有状态协议加速，共享语义的理解至关重要，WAIT共享在绝大多数情况下都是唯一正确的选择。

3. IPsec ESP封装与解封装流程深度解析

理解了SEC的基础架构后，我们深入到IPsec ESP协议本身，看SEC如何具体实现封装与解封装。ESP协议的目标是为IP数据包提供机密性、数据源认证、抗重放保护和有限的数据流机密性。

3.1 封装流程：从明文到受保护的ESP包

封装过程，即发送端对原始IP包（明文）进行处理，输出一个包含ESP头、加密载荷、ESP尾部和ICV的完整数据包。SEC的封装线程（Protocol = IPsec encrypt）自动完成以下步骤：

读取与解析：SEC根据任务描述符找到输入数据帧。根据PDB中的Tun/Trsp（隧道/传输模式）和IP Header Length等字段，确定需要处理的数据范围。在传输模式下，它只对IP载荷进行加密和认证；在隧道模式下，它将整个原始IP包视为载荷。
构建ESP头部：生成ESP头部，包含SPI（从PDB中读取）和序列号（从PDB中读取并递增，然后写回PDB）。如果启用ESN，高32位也会参与ICV计算和状态更新，但不放入报文。
加密与填充：
- IV生成：根据PDB中IVsrc位的配置，决定IV来源。若为0（链式IV），则使用上一个包加密后的最后一个密文块作为本次IV（首次包需在PDB中预置初始IV）。若为1（随机IV），则从SEC内部的真随机数生成器获取。链式IV能提供更好的数据流连续性，但强制要求WAIT共享；随机IV则允许更灵活的调度，但需要高质量的随机源。
- 加密：根据PROTINFO指定的算法（如AES-CBC, AES-GCM），使用加载的密钥对载荷进行加密。对于CBC模式，会在加密前对载荷进行填充以满足分组长度要求，并生成Pad Length和Next Header字段。
计算ICV：对ESP头部、载荷（加密后）和ESP尾部（不包括ICV本身）计算完整性校验值，使用的算法由PROTINFO指定（如HMAC-SHA256, AES-GMAC）。
构建输出帧：
- 在隧道模式下，可能需要前置一个新的外部IP头。这个IP头可以来自PDB中预置的模板（OIHI=11b），也可以从输入帧中复制（OIHI=01b）。SEC会根据PDB中的DSC（DiffServ复制）、DFC（DF位复制）、DTTL（TTL递减）等选项修改这个外部IP头。
- 将外部IP头（如果有）、ESP头部、加密后的载荷、ESP尾部（填充、Pad Length、Next Header）和ICV依次组装成最终的输出帧。
- 更新输出帧的IP头总长度字段和校验和（如果启用Cksm选项）。

整个过程中，SEC硬件自动处理了所有的字节序转换、长度计算和字段拼接，软件只需要提供正确的PDB和输入数据指针。

3.2 解封装流程：验证与还原原始数据包

解封装是封装的逆过程，但增加了验证步骤。SEC的解封装线程（Protocol = IPsec decrypt）流程如下：

定位与解析：SEC根据任务描述符找到输入的ESP包。它首先解析ESP头部，获取SPI和序列号。这里有一个关键点：SEC会使用收到的SPI和序列号与PDB中预期的值进行比对吗？不完全是。SPI用于在软件层面查找对应的SA和PDB，这个查找工作是由驱动软件在提交任务前完成的。提交给SEC的任务已经关联了正确的PDB。序列号则主要用于反重放检测。
反重放检测：这是解封装的第一道安全关卡。SEC硬件内置反重放引擎，支持32、64、128位等多种大小的滑动窗口（通过PDB中ARS位配置）。它会检查接收到的序列号是否在窗口内且未被接收过。如果序列号太旧（在窗口左侧之外），则产生LATE错误；如果是重复的（在窗口内但标记已接收），则产生REPLAY错误。只有通过检测的包才会继续处理。硬件实现的检测速度极快，且避免了软件实现中的锁竞争问题。
验证ICV：使用PDB中指定的认证算法和密钥，对ESP头部、加密载荷和ESP尾部重新计算ICV，并与包尾附带的ICV进行比较。如果不匹配，SEC会返回认证失败错误。这一步确保了数据的完整性和来源真实性。
解密：只有ICV验证通过后，SEC才会进行解密操作。它使用PDB中指定的解密算法和密钥，以及ESP头部之后的IV字段（对于CBC/GCM等模式），对加密载荷进行解密，并移除填充数据。
重构原始IP包：
- 根据解密后得到的Next Header字段和PDB中的TUN/TRSP模式，确定如何处理解密后的数据。
- 在传输模式下，解密后的数据就是原始IP包的载荷，SEC会将其与未加密的IP头（来自输入帧）组合，并根据DTTL、DSC等选项更新IP头（如递减TTL）。
- 在隧道模式下，解密后的数据就是一个完整的IP包。SEC将其作为输出帧。如果启用了AOFL（调整输出帧长度）选项，SEC上报的输出帧长度会自动减去ESP尾部的填充等字段，方便上层软件直接处理。
- 同样，如果需要，会更新IP头的校验和。

3.3 隧道模式与传输模式的PDB差异

虽然核心流程相似，但隧道模式和传输模式在PDB配置上有关键区别，主要体现在对IP头的处理上：

传输模式：用于端到端的安全通信。原始IP头得以保留，仅对上层协议（如TCP/UDP）载荷进行保护。在PDB中，TUN/TRSP位设为0。NH Offset字段至关重要，它指明了原始IP头中“协议类型”字段的字节偏移量，以便SEC在封装时将其复制到ESP尾部的Next Header字段，并在解封装时还原回去。
隧道模式：常用于网关之间或主机到网关。整个原始IP包被封装和保护。在PDB中，TUN/TRSP位设为1。NH Offset字段被AOIPHO（实际外部IP头偏移量）取代。因为隧道模式需要构造或修改一个全新的外部IP头，AOIPHO告诉SEC，在输入/输出帧的哪个位置开始才是真正的外部IP头，这允许外部IP头之前可以存在其他二层头部（如以太网头），SEC在修改IP头时会跳过这些部分。

一个容易混淆的点是“Legacy Tunnel”。在SEC的早期版本中，隧道模式也是通过“ESP Transport (and legacy tunnel)”这个协议命令来实现的，它使用传输模式的PDB格式，通过Inc IPHdr等选项来控制外部IP头的添加。而新的“ESP Tunnel”协议命令则使用了更清晰、功能更专一的PDB格式（如前文Table 9-15所示），直接支持NAT穿越（UDP封装）等新特性。在较新的芯��和驱动中，建议使用新的“ESP Tunnel”命令来实现隧道模式。

4. 协议数据块配置详解与实战避坑指南

PDB的配置是驱动开发者和网络工程师与SEC硬件交互的核心。一个错误配置的PDB轻则导致性能下降，重则导致通信完全失败。下面我们结合手册中的表格，深入几个关键字段的配置逻辑。

4.1 封装PDB关键字段解析

以IPsec ESP Tunnel封装PDB（Table 9-15）为例，我们看几个容易出错的字段：

IVsrc(位5)：IV来源选择。
- 0: 链式IV。IV存储在PDB中，并在每次加密后更新为最后一个密文块。这是最常用的模式，但要求对同一SA的数据包必须严格按序处理（WAIT共享），否则链式IV会断裂，导致对端无法解密。
- 1: 随机IV。每次封装从硬件随机数生成器获取新IV。这放松了处理顺序的要求，但需要确保RNG有足够的熵，且通信双方需要某种方式同步IV（通常IV会放在ESP头后面一起传输）。AES-GCM模式通常使用随机IV。
ESN(位4)：扩展序列号使能。
- 0: 禁用。序列号仅为32位。对于高速长期隧道，32位序列号可能回绕过快。
- 1: 启用。使用64位序列号，高32位（ESN）存储在PDB Word 1中，参与ICV计算和反重放检查，但不包含在发出的ESP包中。接收端必须通过带外方式或在IKEv2交换中协商获得初始ESN值。启用ESN能极大延长抗重放窗口的生命周期，是现代高速VPN的推荐配置。
OIHI(位3-2)：外部IP头来源。这个字段决定了隧道模式下的外部IP头如何获取。
- 00: 不提供外部IP头。这通常用于传输模式，或由其他网络模块添加IP头。
- 01: 外部IP头来自输入帧。输入帧需要包含两个IP头。这适用于“先路由后加密”的架构，SEC只负责加密和封装。
- 10:慎用！外部IP头由PDB中的指针引用。这会导致SEC产生额外的内存读取，且无法预取，会造成显著的性能损失。
- 11: 外部IP头直接存储在PDB中（Word 9开始）。这是最高效的方式，IP头模板在建立SA时写入PDB，后续每个包直接使用。
NAT与NUC(位1和位0)：用于支持NAT穿越（RFC 3948）。当IPsec ESP包需要穿越NAT设备时，需要在ESP头外再封装一层UDP头。NAT=1启用此功能。NUC=1则要求SEC计算UDP校验和；NUC=0则UDP校验和置零。在公网部署中，如果客户端可能位于NAT后，必须启用此选项。

4.2 解封装PDB与反重放配置

解封装PDB（如Table 9-8）中有几个字段关乎安全性和正确性：

ARS(位7-6)：反重放窗口大小。这是硬件抗重放能力的核心配置。
- 00: 关闭反重放检测。绝对不建议在生产环境使用，除非你确信网络环境绝对安全或出于调试目的。
- 01/11/10: 分别对应32、64、128位的滑动窗口。窗口越大，能容忍的乱序包范围越大，但消耗的PDB存储空间也越多（需要额外的“计分卡”字段）。对于高延迟抖动的网络（如卫星链路、跨国互联网），建议使用128位窗口。
AOFL(位2)：调整输出帧长度。
- 0: 不调整。SEC报告的输出帧长度包含了解密后的原始IP包以及紧随其后的ESP尾部（填充、Pad Length、Next Header字节）。软件需要自己解析并剥离这些尾部字节。
- 1: 调整。SEC自动从输出帧长度中减去ESP尾部的长度，报告的长度就是纯原始IP包的长度。强烈建议启用此选项，这可以简化驱动和上层协议栈的处理逻辑，直接获得一个干净的IP包。
OUT_FMT(位3)：输出帧格式。
- 0: 将所有输入帧字段复制到输出帧。这通常用于调试或特殊转发路径。
- 1: 输出帧仅为解封装后的PDU（即原始IP包）。这是最常用的模式。

避坑指南：反重放窗口的初始化与同步硬件反重放窗口虽然高效，但初始化不当会导致连接初期大量丢包。窗口的“基点”是当前收到的最新序列号。在SA刚建立时，我们需要在PDB中初始化一个预期的起始序列号（通常为0或1），并将反重放计分卡（PDB Word 5-8）全部清零。这里有一个关键细节：计分卡清零意味着所有位都表示“未接收”。当第一个序列号为N的包到达时，硬件会将其标记为已接收，并将窗口右边界移动到N。那么，在N之前（窗口左侧）的序列号都会被标记为LATE（迟到包）。因此，如果链路上存在乱序，且第一个包不是最小序列号，那么比它先发出的、序列号更小的包就会被当作迟到包丢弃。在实际部署中，特别是无线或复杂网络环境中，我建议在SA建立后的前几个RTT内，在驱动层面暂时禁用或放宽反重放检查（例如，先记录序列号但不丢弃），待流量稳定后再完全启用硬件反重放，或者使用一个较大的初始窗口来容忍初始乱序。

4.3 使用DECO协议覆盖寄存器进行动态调整

共享描述符的PDB定义了SA的默认处理方式。但有时需要对特定数据包进行微调。例如，某条隧道上大部分包是IPv4，但偶尔需要处理IPv6的包（虽然不常见）；或者需要动态改变某个包的Next Header值。

SEC提供了DECO协议覆盖寄存器来实现这一目的。在提交任务描述符时，可以通过LOAD IMMEDIATE命令向DPOVRD寄存器写入特定值，并设置其OVRD位为1。这样，SEC在处理这个特定任务时，就会使用DPOVRD寄存器中的值来临时覆盖PDB中的对应字段，例如IP头长度、NH Offset、Next Header值等。

这个功能非常强大，但要谨慎使用。它主要用于处理一些异常或动态情况，而不是常规路径。常规路径应该通过创建不同的SA和PDB来处理。滥用覆盖寄存器会增加软件复杂度，并可能引入错误。

5. 典型问题排查与性能优化实践

在实际部署和调试基于SEC的IPsec加速系统时，会遇到各种各样的问题。下面记录几个我遇到过的典型场景及其解决方法。

5.1 问题一：加解密成功，但网络不通或丢包严重

现象：IPsec隧道可以建立，SA协商成功，驱动显示加解密操作正常完成（SEC返回成功状态），但ping不通对端或TCP连接建立失败，抓包发现大量ESP包被对端静默丢弃或回复认证失败。

排查思路：

检查序列号：这是最常见的问题。确认两端序列号同步。检查发送端PDB中的序列号是否在递增，接收端的反重放窗口配置是否合理。使用调试工具或驱动日志，对比发送包和接收包的序列号是否连续。如果发送端使用了NEVER或ALWAYS共享，会导致序列号重复。
检查ICV：认证失败意味着密钥不一致、算法不匹配，或者数据在传输过程中被篡改。确认两端SA协商的加密算法、认证算法、密钥完全一致。特别注意HMAC算法的密钥格式：手册中明确提到，使用HMAC时，为了性能必须使用“Split Key”。这意味着需要调用SEC的派生密钥协议，将原始HMAC密钥转换成SEC内部MDHA模块所需的格式，并通过KDEST字段指定为MDHA Split Key。如果直接加载原始密钥，ICV计算一定会失败。
检查填充和对齐：对于CBC等分组加密模式，SEC会自动进行填充。但需要确认两端对填充内容的约定是否一致（通常是PKCS#7）。另外，确认网络设备（如路由器、防火墙）没有对ESP包进行MTU分片，因为分片可能会影响ICV的计算范围。
检查模式与IP头处理：确认两端配置的IPsec模式（隧道/传输）一致。在隧道模式下，检查外部IP头的源/目的地址是否正确，TTL/跳数限制是否合理（是否被中间路由器置零）。检查DSC、DFC等选项的配置是否符合网络策略。

5.2 问题二：性能未达到预期，CPU占用率依然很高

现象：启用了SEC加速，但吞吐量提升不明显，且top命令显示处理网络中断的CPU核心占用率依然很高。

排查思路：

描述符与内存布局：SEC通过DMA直接读写系统内存。确保输入输出数据帧、描述符、PDB所在的内存区域是缓存一致（Cache-coherent）的，并且已经正确刷新到内存中。如果CPU缓存中的数据没有及时写回，SEC读到的可能是旧数据；反之，SEC写回的数据如果还在缓存行中，CPU也可能读到旧状态。使用正确的内存屏障（Memory Barrier）和缓存维护操作（如dma_alloc_coherent）至关重要。
共享描述符竞争：如果大量流量集中在少数几条隧道上，且使用了WAIT共享，可能会在共享描述符上形成锁竞争，导致DECO空闲等待。可以通过流量分流来缓解：将不同客户或不同目的地的流量映射到不同的SA上，即使它们使用相同的加密策略，从而利用多个共享描述符并行处理。
任务提交开销：虽然SEC处理快，但如果驱动提交任务的效率低（例如，每个包都触发一次中断，或任务描述符构建太慢），整体性能也会受限。考虑使用批处理和轮询模式：一次提交多个包的任务描述符，并让CPU轮询完成队列，而不是依赖中断，可以显著降低开销。
硬件队列深度：检查SEC的Job Ring或Queue Manager接口的队列深度是否足够。如果任务提交速度持续超过SEC处理速度，队列会满，导致任务被阻塞或丢弃。适当增加队列深度，并监控队列水位线。

5.3 问题三：支持NAT穿越时，UDP封装异常

现象：在NAT设备后方的客户端无法建立或维持IPsec隧道，抓包发现ESP包被封装在UDP中，但对端网关不响应或响应错误。

排查思路：

确认两端支持NAT-T：首先确保两端IKEv2协商阶段成功交换了NAT-T载荷，并协商使用UDP封装ESP（端口4500）。
检查PDB配置：在发送端（通常是客户端）的封装PDB中，必须设置NAT=1。如果网络路径要求UDP校验和，还需设置NUC=1；否则设为NUC=0。接收端（网关）的解封装PDB同样需要配置NAT=1，以便它能识别并剥离UDP头。
检查UDP端口：SEC硬件通常固定使用4500端口进行UDP封装。确保防火墙规则允许4500端口的UDP流量通过。
NAT保活：NAT设备会清除不活跃的映射表项。需要IKE守护进程定期发送NAT-T保活包（空UDP包）来维持映射。这是软件层面的功能，SEC硬件不负责。

最后，性能调优是一个持续的过程。我的经验是，在功能正确实现后，通过perf等工具分析驱动代码的热点，重点关注内存分配、锁竞争和中断处理。同时，充分利用SEC芯片手册中的性能提示，例如避免使用“外部IP头指针引用”（OIHI=10b）这类高开销选项，尽可能将静态数据（如IP头模板）直接嵌入PDB。对于超高速场景，可以考虑将多个小包聚合成一个大的“超级帧”再提交给SEC处理，以减少任务提交的相对开销，但这需要驱动和上层协议栈的紧密配合。