2026-10-24 11:28:54 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

论文介绍｜BitSlice-X: 高效可扩展的数据平面路径验证机制

原创

NASPLab
NASPLab

NASP网络实验室

2026年10月19日 16:19
北京

去阅读

论文题目：BitSlice-X: Efficient and Resilient Proof-of-Transit at Scale

作者信息：Yingying Su, Li Chen, Dan Li

完成单位：中关村实验室、清华大学

学术会议：IEEE S&P 2027

论文摘要

路径感知转发与路径验证技术能够帮助网络有效执行服务功能链（service-function chains，SFCs）、流量工程和安全路由策略。现有数据平面路径验证机制通常在报文中携带密码学证明，但逐包携带完整证明会增加带宽与逐跳计算开销；分组或概率式方案虽然降低了开销，却可能限制验证节点的覆盖范围，或需要缓存、重组报文，对丢包和乱序较为敏感。

为此，我们提出可配置的数据平面路径验证机制 BitSlice-X。BitSlice-X将每一跳的证明分摊到一组报文中，通过证明切片与可异或抵消的编码，使每个参与节点仅凭当前报文就能独立完成验证和更新，无需等待其他报文或重组整组证明。证明长度与分组大小可以按应用安全需要灵活配置，以平衡安全强度和处理开销。论文分析了证明伪造、路径偏离、报文篡改与注入的错误接受概率，并基于Intel DPDK在包含18个节点的测试床上进行了原型实现。实验表明，在多数测试参数下，BitSlice-X均能够降低报文头部开销和中间节点处理成本，同时避免以往分组方案的重组等待与丢包放大。

主要贡献

提出BitSlice-X，一种支持逐包独立处理、可配置的数据平面路径验证机制。BitSlice-X将每一跳的路径证明分摊到一组报文中，同时支持各参与节点对到达的报文独立完成逐跳验证与更新。通过配置证明长度和分组大小，不同应用可以在安全强度与通信、计算开销之间选择适合的工作参数，兼顾严格路径合规验证与低开销流量清洗、监测等需求。
设计可异或抵消的路径证明编码结构，消除分组验证对报文缓存与整组重组的依赖。BitSlice-X将基于消息认证码生成的证明材料划分为用于本跳验证和下游更新的切片，并通过异或组合与抵消维护各跳的证明状态。每个节点仅处理当前报文携带的片段，无需等待同组其他报文，从而在保留分组摊销收益的同时，降低报文头部与逐跳处理开销，避免丢包或乱序阻塞同组其他报文的验证。
建立区分单包片段检查与整组证明的安全分析。针对证明伪造、路径偏离、报文篡改和注入等攻击，分别在论文威胁模型下推导了明确的错误接受概率界，刻画证明长度、分组大小与验证强度之间的关系。同时，分析节点失陷、串谋与重放等情况下的能力边界，为实际部署中的参数选择提供依据。
实现基于DPDK的协议原型，并通过多跳测试验证其开销与性能优势。在包含18个节点的测试床上，将BitSlice-X与ICING、OPT、EPIC和Symphony进行比较，系统评估报文头部开销、初始化与验证时间，以及有效载荷吞吐量。

研究背景

在现有互联网中，端系统通常难以掌握和约束报文实际经过的路径。然而，越来越多的应用与网络策略对转发路径提出了明确要求：实时业务需要满足时延、抖动和带宽等服务质量目标，服务功能链要求流量依次经过指定的检测、监测或清洗节点，敏感业务还可能受到地理位置、运营商选择和合规策略的约束。路径感知与路径验证因此成为保障数据交付的重要研究方向。其中，控制平面负责选择可信且经过授权的路径，数据平面则需要验证报文是否确实按规定顺序经过指定节点。因此，如何高效提供这种实际经过路径的证据，即数据平面路径验证（Proof-of-Transit，POT），成为了实现可信网络转发的关键问题。

近年来，学术界与工业界围绕路径验证的安全性和效率持续开展研究，其基本思路是由沿途节点检查、更新报文携带的密码学证明，使下游节点能够验证流量是否遵循预定路径。以ICING、OPT为代表的逐包方案提供了较强的验证能力，但每个报文携带的证明和逐跳密码学计算会增加带宽与处理开销。为降低这些成本，后续研究探索了紧凑证明、概率验证、流级统计检测以及分组摊销等方向，但也引入了不同取舍：部分方案限制了验证覆盖范围或检测的即时性；以Symphony为代表的分组方案虽然能够将证明成本分摊到多个报文，却要求节点缓存报文并重组整组证明，导致一个报文的丢失或延迟到达就可能影响同组其他报文的验证。因此，如何在明确安全保证的同时降低通信与计算开销，并适应实际网络中的丢包和乱序，仍然是路径验证面临的重要挑战。

针对上述问题，我们提出BitSlice-X，通过证明切片与可异或抵消的编码结构，将分组证明的开销优势与逐包独立处理能力结合起来。BitSlice-X将每跳证明分摊到一组报文中，同时使沿途节点仅凭当前报文携带的片段，就能独立完成本跳验证和下游证明更新。这一设计在降低报文头部与中间节点处理开销的同时，消除了跨报文处理依赖，避免丢失或迟到的报文阻塞同组其他报文的验证。此外，BitSlice-X将证明长度和分组大小作为可配置参数，使不同应用能够根据安全需求选择合适的验证强度与开销。

BitSlice-X工作流程

BitSlice-X将每跳证明分摊到一组报文中，同时让各节点能够独立处理每个到达的报文。其中BitSlice是由密钥派生的证明材料切片；POT是通过BitSlice切片按位异或组合得到的组级证明字段；pot则是POT切片得到、由单个报文携带的片段。通过可异或抵消的编码结构，节点仅凭当前报文携带的pot，就能完成验证和更新，无需重组完整的POT。如图1所示，源节点S与各POT节点共享相应的对称密钥，并沿授权路径经中间节点N₁，N₂向目的节点N₃发送报文。记每组包含k个报文，每个BitSlice和组级逐跳证明POT的长度均为t比特，每个报文携带的单跳证明片段pot长度为s = t/k比特。整体流程如下：

源节点初始化包头。源节点使用各跳共享密钥和报文组元信息，通过消息认证码生成证明材料，并将其划分为定长的BitSlice。每个节点对应的第一段BitSlice用于本跳验证，其余切片通过与下游节点的BitSlice进行按位异或组成下游证明，即分别构造供N₁，N₂和N₃验证的POT₁、POT₂、POT₃。随后，将每个POT均分为k个pot，组内第j个报文从每一跳的POT中各取第j个片段，组成自身的完整证明字段。
中间节点验证本跳片段并更新下游片段。当N₁收到第j个报文时，根据自身密钥和报文组信息重新生成对应的证明材料，检查报文中的pot是否与BitSlice片段一致。验证通过后，N₁将自身的更新片段异或到供N₂、N₃使用的片段中，抵消其中来自N₁的贡献，再转发报文。N₂采用相同方式验证本跳片段，并更新供N₃使用的片段。每个节点仅处理当前报文，无需等待同组其他报文。
目的节点完成最终验证。报文经过前两跳的验证与更新后，N₃对其携带的最终路径证明片段进行检查。此外，N₃使用与源节点共享的密钥，校验源端为该报文生成的完整性标识PktID，检查受保护的报文内容是否被修改。只有通过所需检查的报文才被接受。

在这一流程中，报文组用于分摊证明开销，单个报文则是独立验证和转发的处理单位。即使组内报文乱序到达，节点也能根据报文序号选择对应片段；某个报文丢失时，其他报文仍可继续验证。证明长度t和分组大小k还允许应用调整开销与验证强度：增大k可以缩短单包携带的片段，但单包实际检查的长度s也会随之减小，需要依据应用的安全要求选择。

图1：BitSlice-X数据包逐跳处理过程示意图

源节点初始化

Step 1：获取工作密钥与组级元数据

源节点首先获得授权路径，以及与各POT节点共享的工作密钥。假设路径包含n个POT节点，其中Nₙ为目的节点，源节点与Nᵢ共享的密钥记为Kᵢ。BitSlice-X采用分层动态密钥派生机制，将工作密钥绑定到会话、授权路径和密钥周期，沿途节点能够基于本地秘密派生相同密钥。

每开始一组报文，源节点确定组标识GroupID、组大小GroupSize和时间戳TimeStamp，并与源、目的IP地址及头部长度共同组成组级元数据GroupData。此外，每个节点的节点标识及授权入、出端口组成节点信息NodeDataᵢ，两者共同参与该节点的证明生成。

Step 2：生成并编码各跳证明

源节点使用Kᵢ，基于GroupData和NodeDataᵢ，通过消息认证码生成证明材料proofᵢ，再依次截取长度为t 比特的切片，生成BitSlice，即BitSliceᵢr = proofᵢ[(r - 1) × t : r × t].其中，下标i表示对应节点，上标r表示第r段切片。

随后，源节点从前i个节点的证明材料中各取一段切片，通过异或组合，构造供Nᵢ验证的组级证明字段POTᵢ = BitSlice₁ⁱ ⊕ BitSlice₂i − 1 ⊕ … ⊕ BitSliceᵢ¹：最后一项为Nᵢ自身的验证切片，其余项来自上游节点，用于沿途更新。该结构将POTᵢ的预期状态与上游节点的处理过程关联起来：上游节点依次抵消自身贡献后，保留供Nᵢ检查的验证材料。

Step 3：封装BitSlice-X包头

源节点将每个t比特的POTᵢ均分为k份，每份长度为s = t/k比特。组内第j个报文从各跳POT中分别取出第j个片段：potᵢj = POTᵢ[(j - 1) × s : j × s]. 源节点将这些片段按路径顺序拼接，组成该报文的POT字段，并通过PktSeq标明组内序号。因此，每个报文均携带各跳证明的相应片段，供对应节点独立验证和更新。此外，源节点使用与目的节点共享的密钥Kₙ，为每个报文生成完整性标PktID：PktIDj = MAC(Kₙ, GroupData||PktSeqj||Payloadj). PktID将报文内容与组级元数据及组内序号绑定，用于目的节点的报文完整性验证。

最后，源节点将组级元数据、报文序号、PktID和各跳证明片段封装为图2所示的BitSlice-X头部，并发送报文。

图2：BitSlice-X包头结构示意图

POT节点验证与更新

Step1：检查新鲜度并获取证明材料

当下游POT节点收到报文时，首先检查时间戳TimeStamp是否处于允许的新鲜度窗口内，超出窗口的报文将被丢弃。随后，节点获取当前报文组对应的证明材料。对于节点Nᵢ，使用工作密钥Kᵢ，结合报文中的GroupData和本地授权路径信息NodeDataᵢ，按照与源节点相同的方法生成proofᵢ，并划分为定长BitSlice。其中，第一段用于本跳验证，其余切片用于更新下游证明。

Step2：验证本跳片段并更新下游证明

节点Nᵢ从第一段BitSlice中提取第j个片段，检查报文携带的本跳证明是否满足：potᵢj = BitSliceᵢ¹[(j - 1) × s : j × s], 由于上游节点已依次抵消自身对该字段的贡献，合法报文到达Nᵢ时，其本跳pot应与上述预期片段一致。若不匹配，节点丢弃报文；若匹配，则继续更新当前报文中供下游节点使用的证明片段。

对于任一下游节点Nm(m > i)，Nᵢ从对应的更新切片中提取第j个片段，并执行异或更新：potmj← potmj⊕ BitSliceᵢm − i + 1[(j - 1) × s : j × s]，抵消下游pot中来自Nᵢ的贡献。随着各节点依次完成更新，下一跳对应的pot将保留该节点自身的验证片段，支持其继续执行相同的验证流程。中间节点完成本跳验证和全部下游片段更新后，转发报文。

Step3：目的节点完整性验证

目的节点Nₙ同样执行新鲜度检查和本跳pot验证，但无需再更新下游证明。此外，目的节点使用与源节点共享的密钥Kₙ重新计算PktID，并与报文携带的值比较，以验证报文完整性。只有通过全部检查的报文才被接受。

参数选择与应用场景

BitSlice-X通过证明长度t和分组大小k，在验证强度与处理开销之间提供可配置的选择。在t固定时，增大k能够减少每个报文携带的证明比特数，但也会缩短实际检查的片段。因此，单包每跳的盲猜强度取决于s = t/k. 对于严格的逐包路径合规场景，可采用k = 1，并配置足够长的证明。例如，t = 128、k = 1对应128比特的单包每跳盲猜强度；t = 128、k = 2则将每包的单跳证明开销减半，对应64比特的盲猜强度。对于允许一定残留伪造流量的流量清洗或批量监测场景，可以适当扩大分组，降低通信与计算开销，并结合可容忍的残留流量和验证尝试速率确定参数。不同参数配置均沿用相同的逐包独立验证与更新流程。

实验结果

我们基于Intel DPDK实现BitSlice-X，并在包含18台物理服务器的多跳测试床上，与ICING、OPT、EPIC（L3）及Symphony进行比较。各方案使用相同软硬件环境，处理时间和吞吐量实验均采用500字节有效载荷。

通信开销

BitSlice-X将每跳证明分摊到多个报文中，降低单包头部开销。在相同的128比特单包每跳盲猜强度下，其头部开销低于ICING和OPT；在t = 128、分组大小相同时，相比Symphony减少 16.8%—53.4%，体现了紧凑证明编码的通信效率。

图3：BitSlice-X与Symphony在不同路径长度和分组大小下POT头部大小对比

节点处理开销

处理时间实验分别测量源节点初始化、中间节点验证与更新，以及目的节点验证的平均单包耗时。相同安全强度下，BitSlice-X的中间节点处理时间相比ICING和OPT分别减少74.8%—88.1%和59.6%—66.8%，源端与目的端的处理时间也均有优势。与EPIC（L3）相比，BitSlice-X中间节点处理时间减少 54.7%—65.0%。与Symphony相比，BitSlice-X在t = 128的分组配置下，中间节点处理时间减少45.7%—57.5%。源端和目的端在k = 2时也更快；但随着分组增大，Symphony对报文认证成本的摊销更加充分，部分配置下其源端或目的端处理时间更低。

图4：EPIC、Symphony和BitSlice-X 源初始化和POT节点单包处理时间对比图

有效载荷吞吐量

吞吐量按单位时间处理的有效载荷比特数统计，分别反映源节点、中间节点和目的节点的本地处理能力。BitSlice-X POT节点的吞吐量均高于ICING和OPT。与Symphony相比，BitSlice-X的优势在中间节点最为显著：在比特时，BitSlice-X中间节点有效载荷吞吐量达到13.0—21.4 Gbps，Symphony为7.8—12.8 Gbps。源端和目的端在k=2时同样优于Symphony；较大分组下，两者的相对性能随路径长度和分组大小变化，体现了逐包完整性验证与组级认证摊销之间的性能取舍。

图5：EPIC、Symphony和BitSlice-X 源节点和POT节点有效载荷吞吐对比

IEEE S&P（IEEE Symposium on Security and Privacy）是网络空间安全领域入选计算机科学顶级学术会议列表 CSRankings（https://csrankings.org）的四大国际顶级学术会议之一（另外三个会议为 ACM CCS、USENIX Security 与 ISOC NDSS）。