01 · 防御纵深五层模型
2024年Cloudflare 1.1.1.1事件提供了五层模型的现实注脚：L2（Cloudflare自身ROV部署）保护了其内部服务；而外部未部署L2/L3的网络成为受损方——防御的价值与部署率成正比，监测与验证必须同时建设。
02 · 前缀过滤最佳实践
- 客户会话（eBGP downstream）：只接受客户注册授权范围内的前缀（以IRR as-set或客户书面清单为准），拒绝长度异常（如长于/24，除非业务确需）、拒绝RFC 1918等保留地址、拒绝包含自身或上游ASN的AS_PATH；
- 对等会话（peer）：只接受对方及其customer cone的前缀，拒绝从peer学到的"peer的客户之外"的路由——这是防泄露的第一道闸（MANRS行动1核心要求）；
- 上游会话：接受默认路由或全表，但应启用最大前缀数（max-prefix）保护，防止异常泛洪冲垮会话；
- 分级响应：过滤器违规的会话应触发告警并进入人工复核队列，而非静默丢弃——过滤器的存在本身也是数据源；
- 维护纪律：过滤清单与客户协议同步更新（客户新增前缀未同步=自造中断），建立过滤规则的版本管理与定期审计。
03 · RPKI ROV部署要点
3.1 部署组件
- 证书侧：在所属RIR的RPKI平台创建CA证书并签发ROA（RFC 6482），声明prefix、maxLength与起源AS——maxLength应贴合真实宣告粒度，过度宽松（如/16签maxLength=24）会放大sub-prefix劫持空间，过度严格会误伤合法deaggregation（最佳实践权衡详见课题03）；
- 验证侧：部署RPKI relying party软件（如RIPE NCC rpki-client、NLnet Labs Routinator等开源实现），通过RTR协议（RFC 8210）向路由器推送验证结果（Validated ROA Payload, VRP）；
- 路由器侧：启用ROV，对BGP宣告按Valid/Invalid/NotFound三态标记；处置策略可选"丢弃Invalid"或"降低优先级+告警"。
3.2 策略权衡
| 策略 | 优点 | 风险 |
|---|---|---|
| 丢弃Invalid | 最强防护，起源劫持直接失效（2024年Cloudflare实证） | ROA配置错误/证书过期时误伤合法路由，需配合通告与回退预案 |
| 仅降低优先级 | 几乎无中断风险 | 对抗优先级的劫持者（更短路径/更具体前缀）仍可能胜出，防护强度弱 |
| 仅监控 | 零风险起步 | 无主动防护，适合作为部署第一阶段 |
部署现状基线（公开口径）：截至2024年底，全球路由表约54%的前缀获ROA覆盖、ROA总数较2023年增长约49%（RIPE Labs年度回顾）；RIPE NCC辖区按地址空间计约68%的IPv4资源已签署ROA（RIPE NCC官方口径）——防御部署仍处在“起源验证快速普及、路径验证（ASPA/OTC）刚起步”的阶段，详见课题02部署测量。
3.3 运营配套
- ROA到期监控与续期流程（证书过期=自家路由被标记Invalid）；
- ROV执行率纳入变更审计：新增prefix宣告前检查ROA覆盖状态；
- 对NotFound路由保持传统过滤（IRR）作为补充——RPKI覆盖率尚不足以单独支撑全局防护（课题02提供覆盖率基线）。
04 · ASPA与角色机制（泄露治理的增量武器）
起源验证（ROV）对泄露无能为力，泄露治理依赖两个互补机制：
- BGP角色与OTC属性（RFC 9234）：会话建立时在OPEN消息中协商双方角色（customer/provider/peer/rs-server/rs-client等），路由携带Only-to-Customer（OTC）属性标记"此路由不可再提供给非客户"；接收方检测到OTC路由被继续外传即构成机器可判定的泄露证据。该机制增量部署——不支持OTC的旧设备直接忽略该属性，不影响兼容。
- ASPA（RFC 9015）：客户AS在RPKI体系中签发ASPA对象，声明其合法上游提供商集合；验证方据此检查AS_PATH中每一跳的"客户→提供商"授权关系，可检出"未经授权的transit"——即大部分泄露场景与部分路径操纵。ASPA与ROV共用RPKI基础设施，部署成本显著低于BGPsec。
演进判断（基于公开资料的综合）：业界主流观点将"ROV → OTC/角色 → ASPA → （远期）BGPsec"视为务实的演进序列。BGPsec（RFC 8205）因逐跳签名开销与全网部署依赖，规模化进展缓慢；ASPA被普遍视为当前阶段投入产出比最高的路径验证方案。具体部署进展以课题05与各RIR官方公告为准。
05 · 事件缓解标准流程
- 确认阶段：多源数据对齐确认异常宣告存在；判断事件类型（劫持/泄露/撤销）；评估是否为针对己方的攻击；
- 止血动作：联系源头AS的直接上游要求过滤/撤销（基于第5页§2.1识别的传播链逐点联系）；如有RPKI覆盖，确认己方宣告仍被正确标记为Valid；
- 对抗宣告（谨慎使用）：以子前缀宣告精确抢回关键地址段流量——合法但粗暴，需评估对自身路由策略与全球表大小的影响，事后及时撤销；
- 旁路恢复：关键服务启用Anycast多节点、备用IP段，DNS等基础设施预置应急切换方案；
- 复盘归档：事件时间线、影响面（第5页§04口径）、处置时长、改进项——纳入案例库（第6页）反哺检测规则。
06 · 国内实践参照
- CERNET：中国教育和科研计算机网作为MANRS发起成员之一，长期开展路由劫持监测与可视化分析，并部署RPKI实践路由起源认证，其公开报告中的IPv6 ROA签署率达84%（专题首页口径）——国内学术网络的标杆实践；
- CNNIC角色：作为APNIC框架下的国家互联网注册管理机构（NIR），在IP地址/AS号资源管理、注册数据准确性（MANRS行动4"全球验证"的国内支点）方面具有枢纽作用；注册数据质量直接决定过滤与归因的有效性；
- 对国内AS的建议路径：注册数据治理（行动4）→ 基础过滤（行动1）→ 反欺骗（行动2，uRPF等）→ RPKI ROA签署与ROV灰度（行动3协作机制下推进）→ 监测告警体系（本子课题）。
本节参考来源（第7页）
IETF RFC 6482 / 6484 / 6810 / 6811 / 8210（RPKI与ROV体系）：rfc-editor.org。
IETF RFC 9015（ASPA）：rfc-editor.org/rfc/rfc9015；RFC 9234（BGP角色与OTC）：rfc-editor.org/rfc/rfc9234；RFC 8205（BGPsec）：rfc-editor.org/rfc/rfc8205。
MANRS行动规范：manrs.org；RIPE NCC rpki-client：github.com/RIPE-NCC/rpki-client；Routinator：github.com/NLnetLabs/routinator。
Cloudflare 2024年6月1.1.1.1事件官方报告（ROV防御实证出处）：blog.cloudflare.com。
CERNET路由安全公开实践资料：cernet.edu.cn；CNNIC：cnnic.cn。