Summary

  • Petros Gigis 在 RIPE 92 的原始发言指出：计数器能看到流量从哪一处进入，BGP 能显示公告，却不能仅凭这些证明包上的源地址是真的。
  • openPenny 从选定的 TCP 流里故意丢掉少量包，等待重传。按Gigis 本人的技术说明，其测试在多条流中共丢 12 个包，得到低至百万分之一的误报率；那是测试配置下的结果。

一个前缀突然从东京的入口出现，值班工程师可能先去查路由泄漏。Petros Gigis提醒他们，另一种情况便宜得多，也更烦人：有人把那个前缀写进了伪造数据包的源地址。监控计数准确无误，讲出的故事却错了。

转接网络夹在通信两端。NetFlow、sFlow 记录入口和流量，BGP 记录已知的路由公告；它自己并不终止连接。RIPE 92 问答中，Jen Linkova 提出查看 TCP 握手的办法。Gigis 回答，终端服务商能看到的连接状态，过境的 ISP 未必拿得到。让这个 ISP 根据入口统计直接判定路径变化，等于跳过了源地址真实性这一关。

openPenny 把检验分成两步。被动模式观察镜像流，不碰在线数据包；有可疑特征时，主动模式只把选中的一小段流量送到本地分析设备。设备故意丢掉几个 TCP 包，观察对方是否重传。真实的双向连接会对缺包作出反馈；单向伪造流量无法以同样方式回答。官方演讲简介列出了 x86 设备和相应的高速包处理框架。

Gigis 报告的 12 次丢包分散在多条流里，测试条件下误报率低至百万分之一。外部丢包、负载均衡、TCP 行为差异和攻击者模仿重传都会改变判断难度。阳性信号说明所观察的流量集合里存在真实来源的流；它本身不画出完整路径，也不宣判某次劫持发生了。

这道小关卡替运营商守住昂贵的东西：人的时间。伪造噪声能把一班工程师引去追不存在的事故；真正的数据路径绕行也可能躲在 BGP 监测点之外。先让流量证明自己，再决定是否联络邻居、改路由策略或调整购买的转接服务。Gigis 把调查顺序倒回了证据出现的地方。

来源：RIPE 92 原始速记 · 官方演讲页 · RACI 人物页 · Gigis 本人的技术文章。