摘要
- 主机发出的 PIM Hello 可以形成邻接,选举报文也可能改变 DR、DF 或 Assert Forwarder;这些状态只证明设备接受了协议输入,并不证明发送者获得运营方授权。
- Passive mode、IPsec、协议过滤与源地址验证覆盖的入口不同。合格证据必须分别记录接口用途、允许的说话者、认证结果、选举状态、转发执行和接收端结果。
故障发生在第一份丢包报告之前
接入拓扑通常把“主机”和“路由器”画成两类设备,但实现只会执行配置。若面向主机的接口启用了完整 PIM,任何能够发送 Hello 的节点都可能尝试成为邻居。协议看到的是格式、地址和定时器;运营方心里的“这只是员工终端、服务器或租户端口”不会自动进入判断。
RFC 5294 因而揭示了一条权限链。报文被解析,不等于发送者身份可信;地址可信,不等于它有权成为 PIM 邻居;邻接成立,不等于它应参加选举;赢得选举,更不等于它按运营方意图转发。把这些步骤压成一个绿色状态,等于让协议结果反过来定义授权主体。
这是一份 2008 年的 Informational RFC,不是对今天任何厂商或网络的漏洞通报。它提供的是边界分析:只要端口角色没有被机器可执行地表达,正确运行的协议也可能替错误主体行使权力。
从 Hello 到转发责任
在 PIM-SM 中,局域网的指定路由器负责为新源封装 Register,并代表本地组成员发送 Join/Prune。能够成为邻居的节点也可能推动自己赢得 DR 选举。之后,它可以不发送 Join/Prune、不注册本地源,或只对部分组正常工作。其他组仍然畅通,并不能证明受影响的流量保持完整。
BIDIR-PIM 的 DF 同时承担向链路下游和从链路向上游的转发职责。RFC 5294 描述了伪造 DF Offer、DF Winner、宣告更优指标以及不断发 Offer 使选举无法收敛等路径。选举算法的结果,只能证明它在可见候选中作出了选择;它不能证明候选集合本身经过授权。
Assert 又提供了一条较窄但同样有力的入口。对某个 (S,G) 或 (*,G),Assert 胜者可以覆盖普通 DR 行为,成为向局域网转发的责任方。默认三分钟的 Assert Timer 会让未刷新状态过期,却不会阻止第一次扰动,也不会补回期间丢失或被篡改的数据。
Register 绕过了同一张边界图
单路由器 stub 链路适合使用 PIM passive mode:接口不发送也不处理 PIM 报文,但主机仍可发送和接收组播。这样既保留业务数据面,又撤销了不必要的 Hello、邻接和选举表面。
然而 Register 是单播,主机可以自行构造并发送到任意地址,包括本域之外的 RP。缺少源地址验证时,它还可以伪造来源。这条路径可能绕过只放在合法 DR 上的速率限制。因此 RFC 5294 的缓解表明确表示:passive mode 不解决主机自行发送 Register 的问题。
这也说明“已保护 PIM”不是一个足够精确的结论。本地多播控制报文、跨网的单播 Register、源地址真实性、路由器之间的认证与最终数据转发不在同一个闸门上。
缓解措施不是同义词
多台合法路由器共享链路时,IPsec 可以认证它们之间的 PIM。代价是安全关联、密钥和设备支持需要维护;自动协商也未必适合。更重要的是,本地路由器之间的 IPsec 不必然阻止一台主机把 Register 发往远端。审计必须说明认证覆盖了哪些报文、哪些对端和哪段路径。
在单路由器 stub 上,入口 ACL 阻止 IP protocol 103,既能阻止多播 PIM,也能阻止单播 Register,覆盖面比 passive mode 更完整。多路由器链路则可以在交换机的所有主机端口过滤 PIM,或只允许已知邻居地址并在端口侧防止源地址伪造。这样保留路由器互通,但正确性转移到端口清单、例外审批和过滤规则维护。一个遗漏的新端口就足以重新打开权限面。
BIDIR-PIM 还需要独立的入口过滤,因为共享树不会以同样方式提供 RPF 检查。源地址方向正确,只减少了一类伪装,并不授予路由器角色。
证据应当停在它真正到达的位置
一份可审计记录至少分六行:接口被定义为主机口;PIM 在该口被禁止、被动运行或按例外允许;发送源通过验证;控制报文通过认证;合法候选参与选举并产生角色;转发状态执行且接收者观察到预期流量。上游一行成功,不能替下游一行签字。
负面观察也要限定窗口。抓包期间没有非法 Hello,不等于所有接入口都过滤 PIM;DR 身份稳定,不等于某个组没有遭遇伪造 Assert;计时器到期,不会重建过去的交付。组播订阅成功同样不证明保密性,链路节点可能调整二层组播过滤,机密性仍需加密。
把收费或订阅授权只放在 IGMP 等成员管理层也不够。若主机能以路由器身份行动,它可能绕开订阅路径或影响同链路其他用户。业务资格与控制平面角色是两本账。
本文没有证明什么
本文不声称某个现有产品接受非邻居 PIM,不声称真实网络遭到攻击,也不从历史 RFC 推断当前普及率。RFC 7761 后来取代 RFC 4601 成为 PIM-SM 规范;实际行为需要版本、配置、抓包与部署证据。
任何单项控制也不能证明交付。Passive mode 不修复数据面错误,IPsec 不保证获授权路由器配置正确,ACL 不会替接收端创建成员状态。本文只作更窄的结论:在读取邻居表和选举状态之前,必须先证明接口有权接纳这一类控制主体。
资料来源
- RFC 5294:Host Threats to Protocol Independent Multicast
- RFC 5294 纯文本
- RFC Editor 的 RFC 5294 信息页
- IETF Datatracker 的 RFC 5294 记录
- IETF Datatracker 的 RFC 5294 历史
- RFC 5294 引用的文档
- 引用 RFC 5294 的文档
- RFC 5294 勘误
- RFC 4609:PIM-SM Multicast Routing Security
- RFC 4601:Protocol Independent Multicast — Sparse Mode
- RFC 5015:Bidirectional Protocol Independent Multicast
- RFC 3973:Protocol Independent Multicast — Dense Mode
- RFC 3704:多宿主网络入口过滤
- RFC 5796:PIM-SM 认证与保密
- RFC 7761:Protocol Independent Multicast — Sparse Mode
- RFC 3740:组播组安全架构
- IANA PIM 参数
- Heng Lu:On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
- Heng Lu:Running Code Primary
- Heng Lu:On the Agency Problem at the Core of Internet Governance
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
