把拓扑发现的信任边界前移：SDN 拓扑投毒防御札记
拓扑发现不是普通后台监控项，而是路由、故障切换和安全策略共同依赖的状态入口。一旦发现路径被普通规则影响，控制器随后看到的拓扑就可能已经失真。
为什么拓扑发现值得单独讨论
在 SDN 或更广义的控制/转发分离网络中，控制器并不是凭空知道网络长什么样。它通常需要周期性发送链路发现报文，例如 LLDP，观察报文从哪个交换机、哪个端口进入，再把这些观察结果拼成一张拓扑图。
这张拓扑图看起来只是“网络管理信息”，但实际地位更高。路由计算、故障切换、负载均衡、流量监控和安全策略部署，都依赖它。如果拓扑是错的，上层决策就会在错误地图上行走；如果拓扑发布太慢，上层决策就会基于过期地图行动。
因此，拓扑发现同时有两个要求：
| 要求 | 含义 | 风险 |
|---|---|---|
| 正确性 | 发布的链路关系必须反映真实网络连接 | 错误链路、隐藏节点、绕路、黑洞 |
| 新鲜度 | 拓扑必须在规定时间内完成更新 | 故障恢复慢、路径重算滞后、安全策略失效 |
| 可信性 | 进入拓扑服务的证据必须可验证 | 控制器或应用被利用后污染全局状态 |
这里的关键切入点是：拓扑安全不只是“发现攻击”，而是“在时限内发布可信拓扑”。
控制器侧投毒为什么难防
传统 LLDP 拓扑发现的直觉很简单：控制器让交换机从某个端口发出 LLDP，另一台交换机收到后上报，控制器据此认为两端之间存在链路。
问题在于，近期的拓扑投毒思路并不一定需要伪造 LLDP 内容。攻击者如果控制了某个控制器应用，或者在多控制器环境中控制了一个恶意控制器，它可能只安装看似普通的转发规则，让合法 LLDP 走一条不该走的路径。这样，控制器收到的仍然是格式正常的 LLDP 回报，但这份回报已经不再代表真实链路。
这类攻击的麻烦之处在于：控制器看到的是端点，真正有害的动作发生在转发路径中。控制器如果事后再做一致性检查、关联分析或主动探测，确实可以降低风险，但这些检查会占用同一条控制平面的处理时间。拓扑发现越频繁，网络规模越大，控制器越忙，这个矛盾就越明显。
可以把问题抽象成下面这张表：
| 防御位置 | 优点 | 主要问题 |
|---|---|---|
| 控制器事后检测 | 容易集成，能复用已有拓扑视图 | 攻击已经影响发现路径，检测还会消耗拓扑更新时间 |
| 交换机侧提前隔离 | 在 LLDP 进入普通转发前阻断改道 | 需要证明运行中的管线就是被审查过的管线 |
| 独立可信准入 | 避免普通控制器应用直接决定可信拓扑 | 需要额外的证据、权限边界和 fail-closed 设计 |
如果攻击发生在转发路径，第一道防线就不应只放在控制器的事后分析上。
三层防线：隔离、绑定、准入
防御思路可以概括为三层。
第一层是交换机侧隔离。发现流量在进入普通转发逻辑前被识别，并进入专门的发现处理路径。普通业务转发规则仍然可以安装和更新，但不能再决定 LLDP 这类发现报文的可信路径。
第二层是部署工件绑定。只在源代码里写了隔离逻辑还不够，运行时可能出现替换、回滚或配置漂移。因此，系统需要把已审查的程序、接口描述、编译产物、队列配置等工件绑定到签名清单中，并在运行时验证当前设备是否仍然匹配这些工件。
第三层是可信拓扑准入。控制器当前看到的拓扑不能直接等同于可信拓扑。独立的验证与收集路径需要检查每台交换机的可信证据，只接收来自可信运行状态的拓扑观察。没有证明、证明过期、哈希不匹配或来源不可信的观察，都应 fail-closed。
| 机制 | 解决的问题 | 工程含义 |
|---|---|---|
| 交换机侧发现流量隔离 | 普通转发规则不再影响 LLDP 可信路径 | 防御位置从控制器后验检测前移到转发入口 |
| 静态检查与签名工件 | 防止错误或被替换的管线被当作可信管线 | 让“审查过的逻辑”和“正在运行的逻辑”可绑定 |
| 运行时证明 | 防止回滚、替换、重放和工件漂移 | 运行状态需要被证明，而不是被假定 |
| 独立 collector | 防止普通控制器应用直接污染可信拓扑 | 拓扑发布路径应和普通控制器权限分离 |
这套结构的关键不是某一个工具，而是边界设计：普通控制器应用可以继续做业务控制，但不能直接控制发现流量的可信路径，也不能绕过证据准入直接发布可信拓扑。
实时性不是附加指标
在拓扑安全场景里，很多人容易先关注“攻击是否被挡住”。但对于控制/转发分离网络，仅挡住攻击还不够。拓扑状态如果不能及时发布，路由、故障切换和安全策略同样会受到影响。
因此，可以把一轮拓扑发现拆成几个阶段：交换机侧处理、准入验证、拓扑重建和发布通知。整体目标是这些阶段的总耗时不能超过系统给定的拓扑新鲜度 deadline。
这个视角会改变防御设计的优先级。控制器侧每包检测如果很复杂，单次看起来不贵，但乘以一轮中的大量 LLDP 报告，再叠加攻击者制造的规则写入压力，就可能把安全检查变成实时性瓶颈。
把第一道过滤放到交换机侧，并不意味着拓扑发布没有成本。运行时证明、collector 判断和拓扑重建仍然需要资源。但它减少了“每一轮、每一个发现报文都在普通控制器路径里反复诊断”的压力，把主要风险从静默污染转化为可观察、可拒绝、可 fail-closed 的准入问题。
验证思路
验证不能只看单个脚本是否跑通，而要沿着证据链分层回答几个问题：攻击是否真实、隔离是否改变发现路径、可信证据是否约束运行状态，以及拓扑发布是否仍满足时间预算。
| 实验问题 | 需要证明什么 | 观察结果 |
|---|---|---|
| 攻击基线是否成立 | 控制器侧规则是否能稳定污染拓扑发现 | 无防御条件下，攻击在原型环境中表现稳定 |
| 交换机侧隔离是否有效 | 普通规则是否还能影响发现路径 | 隔离后未观察到成功的拓扑投毒 |
| 部署工件是否可信 | 被替换、回滚、篡改的工件是否会被接受 | 异常工件和不匹配证据会被拒绝 |
| collector 是否独立准入 | 伪造或无证明的观察是否进入可信拓扑 | 未经证明的观察不会进入可信发布路径 |
| 实时性是否可维持 | 攻击压力和背景负载下是否仍满足 freshness 目标 | 在软件原型中保持了 deadline 内发布趋势 |
| 结论边界是否清楚 | 哪些结论适用于软件原型，哪些需要硬件验证 | 软件时延不等同于硬件最坏情况 |
这里尤其要强调结果边界。软件交换机、虚拟机、原型 collector 和真实硬件交换机之间有差距；单控制器 live 闭环和真正大规模多控制器部署之间也有差距。设计逻辑和证据链可以支持机制判断，但不能把原型结果包装成生产硬件的最坏情况保证。
对工程实践有什么启发
这些设计取舍对工程系统也有直接启发。
第一，拓扑发现不应被视为普通监控功能。它是很多控制决策的输入，应该具备比普通状态采集更明确的信任边界。
第二，控制器插件和普通控制应用的权限需要收敛。一个应用如果既能读拓扑、写普通规则，又能影响拓扑发布路径，那么攻击面会被显著放大。更合理的做法是区分普通转发编程权限和可信拓扑发布权限。
第三，网络安全机制要考虑实时性成本。把所有验证都放到控制器后处理路径中，可能在小规模环境里看不出问题，但在大规模 LLDP 轮询、攻击写入压力和多应用并发下，会和拓扑新鲜度发生冲突。
第四，可信运行状态需要证据链。静态代码审查、签名清单、运行时测量、collector 准入和差异报告应当互相衔接，而不是各做各的检查。
可以把这些启发落成一个简单检查清单：
- 权限边界：普通应用能否影响可信拓扑发布？
- 发现路径：LLDP 是否会进入普通转发规则范围？
- 工件绑定：运行中管线是否对应已审查版本？
- 准入策略：无可信证明时是否 fail-closed？
- 时间预算：是否定义 freshness deadline？
- 证据留存：结论能否追溯到运行、指标和日志？
仍然需要谨慎的地方
系统结论不能只展示最强结果，也要说明适用边界。
| 边界 | 含义 |
|---|---|
| 威胁模型边界 | 如果攻击者能替换可信管线、绕过设备测量或直接写可信拓扑发布服务，那已经超出普通控制器侧投毒模型 |
| 部署覆盖边界 | 只有被保护管线覆盖的交换机和链路才能享受完整保证，部分部署只能得到局部保护 |
| 原型边界 | 软件交换机和 VM 时延结果不能直接等同于硬件 ASIC 最坏情况时延 |
| 控制器边界 | 单控制器闭环、replay harness 和多控制器生产部署不是同一类证据 |
| 可用性边界 | fail-closed 能避免静默污染，但在高压下可能表现为延迟或可用性压力 |
这些边界不会削弱机制本身，反而能让结论更可信。对拓扑安全这类系统问题来说，最危险的不是承认边界，而是把原型证据写成无条件保证。
小结
SDN 拓扑发现的安全问题，本质上不是“LLDP 报文能不能被识别”这么简单。真正的问题是：谁有权影响发现路径，谁有权把观察结果变成可信拓扑，以及这件事能否在拓扑新鲜度 deadline 内完成。
更合理的方向是把信任边界前移：在交换机侧隔离发现流量，用签名工件和运行时证据绑定部署状态，再通过独立 collector 决定拓扑准入。这样做不是为了替代控制器，而是为了让控制器继续承担业务控制的同时，不再把拓扑发现这条可信路径暴露给普通规则和普通应用。