RFCLLM：评估LLMs在网络协议状态机中的推理能力

# RFCLLM：评估LLM对网络协议状态机的推理能力  
来源：https://arxiv.org/html/2609.13389  

###### 摘要  
将文本规范映射到形式化表示对于确保协议设计和实现的正确性至关重要。在网络安全或测试中使用的LLM生成映射通常被认为完美理解了规范，但实际情况可能并非如此。本文旨在评估LLM正确解读规范的程度。我们研究了LLM通过自然语言描述隐含表示的有限状态转换系统与人工生成的基准模型之间的契合度。我们针对16个协议设计了4类任务和1482个查询，评估了不同评判器的偏差、任务间的固有难度差异、4种上下文类型的影响，以及协议特征的作用。本研究为验证LLM是否能真正可信地进行协议规范的FSM（有限状态机）推理迈出了关键一步。  

## 1 引言  
自然语言是描述网络协议规范最常见的方式，因其易于被不同领域专家理解。这些规范包括散文文档以及伪代码、头部描述或状态机。然而，文本规范无法直接用于验证协议正确性或判断实现是否符合规范。此类分析需要基于精确形式语言和语法的正式验证工具。因此，将文本规范映射到形式化表示对于确保协议设计和实现的正确性至关重要。过去，协议规范到形式模型的映射主要通过人工完成Jero等人（2015）(https://arxiv.org/html/2609.13389#bib.bib36)或Jero等人（2018）(https://arxiv.org/html/2609.13389#bib.bib3)，或借助NLP技术Pacheco等人（2022）(https://arxiv.org/html/2609.13389#bib.bib22)实现。近年来，LLM越来越多地被用于生成支持形式化验证、测试和安全的映射，或直接集成到这些工作流中Meng等人（2024）(https://arxiv.org/html/2609.13389#bib.bib1)；Zheng等人（2025）(https://arxiv.org/html/2609.13389#bib.bib16)；Hahn等人（2022）(https://arxiv.org/html/2609.13389#bib.bib18)；Mao等人（2025）(https://arxiv.org/html/2609.13389#bib.bib19)。与早期经过严格评估以解读协议规范的NLP方法不同，现有将LLM输出用于网络安全或测试的工作通常假设LLM完美理解规范并能正确将高层技术描述映射为形式模型：这在实践中可能并不成立。  

本文评估LLM正确解读规范的程度。我们专注于互联网协议最知名的规范——请求评论（RFC）。  
**动机示例**：为阐明文本规范的固有模糊性以及领域知识如何帮助澄清作者意图，考虑以下来自Ginesin等人（2024）(https://arxiv.org/html/2609.13389#bib.bib24)的示例，该示例揭示了RFC 9260（SCTP）中描述对等方收到意外INIT消息应如何反应的歧义：  
*在Cookie_Echoed状态下收到INIT块时，端点必须使用其原始INIT块中发送的相同参数响应INIT_ACK块*。  
提供相关背景：SCTP使用两个安全标识符i-tag（发起标签）和v-tag（验证标签）来建立和验证两个端点之间的活动连接，方法是将一端发送的i-tag作为另一端的v-tag，反之亦然。图1 (https://arxiv.org/html/2609.13389#S1.F1)显示了两个对等方A和B最初均处于Closed状态，以及一个可以伪造B端口和IP的攻击者。序列结束时，v-tag V应取何值？短语“相同参数”存在歧义：合理的读者可能设置V = i1；正确答案是V = i2，但只有当读者理解i-tag和v-tag在连接两个方向上扮演相反角色时，这点才清晰。遵循错误解释的实现者会允许攻击者注入伪造数据包并劫持连接。  

我们提出的评估直接针对此类场景，系统性地评估LLM文本解释所允许的转换的合法性与完整性。  
**问题定义**：我们将此挑战构建为对世界模型理解的评估Vafa等人（2024）(https://arxiv.org/html/2609.13389#bib.bib32)。每个RFC用自然语言定义一个世界模型，可形式化表示为有限状态转换系统，包括状态、变量和转换逻辑。我们提出四种关于状态转换及其条件的QA任务（例如，给定两个状态，导致从一个状态到另一个状态的事件序列是什么？）。这些任务是评估LLM理解网络协议语义的起点，并直接适用于网络安全任务，如协议模糊测试探索Meng等人（2024）(https://arxiv.org/html/2609.13389#bib.bib1)；Ma等人（2024）(https://arxiv.org/html/2609.13389#bib.bib23)；Zhang等人（2025）(https://arxiv.org/html/2609.13389#bib.bib21)；Huang等人（2025）(https://arxiv.org/html/2609.13389#bib.bib20)、跟踪分析Arkko等人（2024）(https://arxiv.org/html/2609.13389#bib.bib2)或形式化分析Mao等人（2025）(https://arxiv.org/html/2609.13389#bib.bib19)；Cosler等人（2023）(https://arxiv.org/html/2609.13389#bib.bib17)。为创建QA数据，我们收集了覆盖开放系统互连网络栈不同层的16个协议，总计包含118个状态、334个状态转换、5381条有效路径和1482个任务查询。我们为每个协议标注了基准FSM以推导标准答案。比较生成的响应与标准答案时，我们采用两种自动评判器：衡量两者余弦相似度Shen等人（2025）(https://arxiv.org/html/2609.13389#bib.bib31)，以及将其构建为标准答案与模型生成答案对之间的释义检测任务。  

**建模方法**：我们的分析旨在评估阅读RFC描述后，LLM隐含的世界模型表示与人工生成的基准之间的契合度。与先前通过标记训练数据诱导世界模型Vafa等人（2024）(https://arxiv.org/html/2609.13389#bib.bib32)或基于简洁图定义推理Wang等人（2023）(https://arxiv.org/html/2609.13389#bib.bib34)；Zhang等人（2024）(https://arxiv.org/html/2609.13389#bib.bib33)；Yuan等人（2025）(https://arxiv.org/html/2609.13389#bib.bib35)的研究不同，我们的工作聚焦于反映技术文档模糊性和不充分性的现实场景。由于RFC定义高层行为并依赖人类领域知识解决不一致性，我们研究LLM能否弥合这些解释差距。为此，我们评估了多种引出这些隐含协议模型的策略：依赖模型参数且无额外信息的基线（No-context），以及使用理想化、无歧义转换表的理想基准（Easy）。我们将这些与两种基于文档的表示进行比较：一种是由专家手动策划的RFC相关部分（Manual-extracted-RFC），另一种是由LLM自动检索的（LLM-extracted-RFC）。我们的实验设置旨在区分记忆、检索和推理。No-context设置捕捉记忆（因为未在提示中添加文本规范，模型必须依赖通过其参数捕获的协议知识）。比较Manual-extracted-RFC和LLM-extracted-RFC检验了完美（专家策划）与现实（自动检索）检索之间的差异。最后，通过观察Easy与Manual-extracted-RFC之间的差异评估推理，这捕捉了基于标准RFC模型（即逻辑推理）与基于完美检索的模型文本描述（即文本推理）推理的差异。比较这些设置使我们能够区分记忆与基于规范的推理，并评估失败是源于结构推理不足还是无法导航技术标准密集的文本。  

**图1**：SCTP歧义Ginesin等人（2024）(https://arxiv.org/html/2609.13389#bib.bib24)。  

**实验研究**：我们评估了8个LLM，包括两个开源和六个商业模型，覆盖不同供应商和参数规模。实验分析围绕五个问题展开：(1)不同评判方法表现如何？(2)不同任务的难度如何变化？(3)不同上下文类型如何影响性能？(4)不同协议特征如何影响性能？(5)不同LLM回答任务的表现如何？我们的评估比较了不同评判器的偏差和任务间的固有难度差异，主要发现包括：(1)文档理解是主要瓶颈，因为模型在结构化FSM（*Easy*上下文）下比原始RFC文本表现显著更好；(2)手动策划的RFC摘录始终优于自动检索的上下文，表明信息检索仍然具有挑战性；(3)即使提供了正确的FSM（*Easy*上下文），多跳推理仍然困难。在所有协议中，特定的协议特征在性能中起重要作用，我们识别了一些关键因素。  

**主要贡献**：我们提出一个评估LLM在网络协议FSM理解中推理能力的框架，包含四个不同难度的任务。我们提出四种上下文设置，旨在突出模型推理挑战的不同方面。研究产生了一个全面的数据集，包含源自16个协议的1482个任务查询。分析揭示了8个模型在FSM理解方面不同能力的见解。我们认为这些见解可转移到许多需要模型遵循严格文本规范的语言理解场景，例如遵循游戏指令和受限解码应用。我们发布了代码：https://anonymous.4open.science/r/rfcllm。  

## 2 相关工作  
我们明确区分两条研究路线：(1)从规范文本提取或构建协议FSM的工作；(2)直接分析或推理协议规范以用于安全应用的工作。我们将本文定位为首个评估协议推理能力而非FSM构建的基准。  

对于第一类，近期工作探索使用大型语言模型（LLM）进行规范理解和模型提取。例如，PROSPERSharma和Yegneswaran（2023）(https://arxiv.org/html/2609.13389#bib.bib25)展示了LLM如何帮助从RFC中提取结构化协议规范，尽管存在歧义和协议行为在文档中分散描述。PSMBenchShen等人（2025）(https://arxiv.org/html/2609.13389#bib.bib31)提供了一个将标注的RFC文本与手动提取的基准协议状态机配对的数据集，用于评估LLM在自动FSM提取上的性能。  

对于第二类，NLP技术（包括LLM）被用于分析规范以应用于安全。RFCNLPPacheco等人（2022）(https://arxiv.org/html/2609.13389#bib.bib22)是一种混合方法，使用词表示、零样本学习和从提取信息到协议FSM的基于规则映射的组合从RFC文档中提取FSM。他们的系统表明从RFC提取的FSM可用于自动合成针对TCP和DCCP等协议的攻击。RFCAUDITZheng等人（2025）(https://arxiv.org/html/2609.13389#bib.bib16)以自动代理方式检查实现代码是否符合RFC定义，以识别与规范的不一致及可能导致的错误。  

先前工作评估LLM能否从RFC文本构建协议FSM。我们的基准解决一个根本不同的问题：一旦协议规范（甚至正确的FSM本身）可用，LLM能否正确推理其中编码的协议语义？此区分源于LLM在网络实践中的常见使用方式。许多近期系统直接向LLM提供RFC文本或协议规范，并隐含假设模型能正确理解协议语义。我们的结果表明，即使在明确提供正确FSM的Easy设置下，模型仍难以进行多跳路径推理，揭示了构建协议表示与推理协议语义之间的差距。  

## 3 方法  
为衡量LLM对网络协议FSM逻辑的理解，我们定义了若干任务，并比较不同的上下文信息选项。最后，我们将LLM查询结果与基准进行比较并分析统计数据。  

**图2** (https://arxiv.org/html/2609.13389#S3.F2)显示了我们方法的工作流程。  

**图2**：RFCLLM工作流程  

#### 基准FSM：  
我们定义FSM为一组转换元组：即  
FSM = {⟨s, γ, s', A'⟩ | s, s' ∈ S, γ ∈ C, A' ⊆ A}  
其中：  
- S 是状态集合；  
- C 是转换条件集合；  
- A 是动作集合（例如更新变量值、发送数据包）；  
- A' ⊆ A 是由转换触发的动作集合；  
- ⟨s, γ, s', A'⟩ 是转换元组：从当前状态 s，在条件 γ 下，FSM 转移到下一个状态 s' 并执行 A' 中的动作。  

例如，TCP拥塞控制协议的FSM中，一个转换元组⟨s, γ, s', A'⟩可以是：s:指数退避；γ:ACK；s':慢启动；A'：[重置rto定时器，按允许发送新数据包]。  

我们的基准FSM由一位拥有四年网络安全领域博士研究经验及计算机科学正式本科教育背景的作者构建。构建过程取决于每个协议的规范方式：当RFC包含显式ASCII FSM时，我们直接提取其状态和转换；当FSM表示为转换表或其他结构化描述时，我们将这些表示手动转换为我们的转换元组格式；对于TCP拥塞控制协议，我们从先前发表的协议分析论文中提取转换规则。对于状态逻辑分散在RFC文本中的协议，我们使用PSMBenchShen等人（2025）(https://arxiv.org/html/2609.13389#bib.bib31)的FSM作为初始参考，仔细对照相应RFC验证，并修正错误和遗漏。