01 · 事件分级标准
协同处置的效率取决于分级是否清晰。本课题按"影响面×性质"二维分级，避免单一维度造成的处置资源错配：
| 级别 | 定义（满足其一即入级） | 响应要求 |
|---|---|---|
| G1 重大 | 关键基础设施前缀被劫持；或观测受影响AS超过50；或事件伴随明确的攻击意图证据（钓鱼重定向、流量窃听特征） | 30分钟内启动协同；24小时内输出中期通报；全程留痕 |
| G2 严重 | 观测受影响AS 10-50；或重要业务前缀受影响但未见攻击意图证据 | 2小时内启动协同；72小时内输出通报 |
| G3 一般 | 观测受影响AS 2-9的孤立事件；或高置信度但影响面有限 | 24小时内纳入研判队列；周度汇总通报 |
| G4 轻微/存疑 | 单观测点记录、低置信度；或确认为已知合法场景（迁移窗口、任播波动） | 批量处理；基线库更新；不单独通报 |
分级在事件生命周期内可动态调整：新观测源加入或发现攻击意图证据时升级；确认为误配置且无扩散时降级。每次调整记录理由，支撑MTTR度量与事后复盘。
02 · "发现—确认—通报—缓解—恢复—复盘"闭环流程
2.1 通报渠道矩阵
| 对象 | 渠道 | 内容要点 |
|---|---|---|
| 源头AS运营者 | WHOIS/RDAP注册联系人、PeeringDB联系人、直连上游（沿AS_PATH逐跳追溯） | 事件事实、证据（观测点+AS_PATH）、请求动作（撤销宣告/核查配置）、时限要求 |
| 上游提供商 | 该AS的上游运营者NOC（当源头不响应时，请求上游过滤） | 同上，附源头未响应的经过记录 |
| 受影响方 | 重点前缀清单持有人（若有合作渠道）；邮件列表/社区渠道（范围较大时） | 事件影响描述、本地缓解建议（改道/过滤/切换备用） |
| 行业/治理组织 | MANRS渠道、RIR安全联络机制、NANOG类社区列表、国内反钓鱼工作组/CNNIC协调渠道 | 结构化事件简报（对齐STIX映射，见第4页）；G1事件即时、其余汇总 |
2.2 缓解手段工具箱
- 源头侧（治本）：撤销异常宣告、修正过滤配置；上游实施入向过滤（基于IRR/RPKI/前缀列表）。
- 传播侧（控面）：中间AS对异常前缀做临时过滤；IXP路由服务器侧策略更新（适用于成员前缀事件）。
- 受害侧（自救）：更具体前缀宣告夺回流量（/24覆盖被劫/16的子前缀场景）；DNS层面切换（若DNS前缀同时受影响）；启用备用出口。
- 防御侧（长效）：推动受影响前缀补签ROA；确认涉事路径上ROV拦截有效性；将事件样本纳入基线库。
03 · 标杆案例复盘：Cloudflare 1.1.1.1事件（2024年6月）
2024年6月27日发生的事件是理解"劫持+泄露叠加"与"RPKI防御价值"双重主题的最佳公开案例，信息源为Cloudflare官方博客事件报告与BleepingComputer等媒体报道：
3.1 事件时间线
| 环节 | 事实 |
|---|---|
| 触发 | 2024年6月27日18:51 UTC，巴西Eletronet S.A.（AS267613）开始向其对等体与上游宣告1.1.1.1/32；凭借最长前缀匹配（LPM），该/32优先于Cloudflare自身的1.1.1.0/24，解析流量被黑洞化；某Tier-1运营商更将其按RTBH（远程触发黑洞）路由接受，显著放大影响 |
| 放大 | 1分钟后（18:52 UTC），Nova Rede de Telecomunicações Ltda（AS262504）将1.1.1.0/24向上游AS1031泄露并被进一步传播；泄露路径当晚多次复发（20:10、22:16 UTC两批次），形成"劫持+泄露"叠加结构 |
| 影响 | 70个国家/地区300多个网络的用户无法访问或访问质量下降；Cloudflare评估总体影响"相当低"，受影响流量占比不足1%，但部分地区用户完全不可达 |
| 缓解 | 20:03 UTC Cloudflare内部立案；20:08与21:56 UTC先后停用与AS267613的两处对等互联点并联络相关网络撤销宣告；劫持约2小时后缓解，泄露于次日02:28 UTC完全消除 |
| 防御验证 | 因内部部署RPKI自动拒绝Invalid路由，Cloudflare内部服务未受影响；Cloudflare同时指出当时全球RPKI部署刚达"50%前缀签署"里程碑，防御价值已被实证但覆盖仍需扩大 |
3.2 对本课题闭环设计的启示
- 劫持与泄露的叠加判定：本事件同时存在起源劫持与路由泄露两个独立违规动作，分级研判时须分别归因（响应KQ-1中的分类口径偏差问题）。
- RTBH滥用暴露的验证缺口：某Tier-1将第三方/32宣告按黑洞路由接受，反映RTBH过滤过度依赖IRR AS-SET的宽松实践；IETF曾提出DOA（Discard Origin Authorization）对象草案用于黑洞宣告的授权校验，事件后该方向重获关注——这是"起源验证之外"的第二层防御议题。
- RPKI价值实证：事件成为"部署RPKI的组织自身免疫"的公开证据——这一叙事对推动行业部署的动员价值，超过单纯的技术论证，值得在治理层指标（第2页）中体现。
- 通报时延教训：事件中异常宣告的全球传播以分钟计，而跨组织协同的人工联络仍是小时级——自动化情报通道（第4页TAXII设计）与预置联系人体系（PeeringDB维护质量）是缩短MTTR的关键杠杆。
04 · 闭环度量体系
度量数据的治理规则：①所有时延指标以观测点时间戳为准并保留原始证据；②G4事件不计入MTTM（无通报义务）；③度量结果本身纳入治理层指标（第2页）对外发布，以透明度换取协同信任。
05 · 国内协同机制试点设计
借鉴MANRS三要素（第5页§3.3）并依托既有组织基础（第6页§1.1），本课题提出国内路由安全协作组试点方案：
- 参与主体：骨干运营商、大型CDN/云、科研教育网（CERNET为代表）、CNNIC及反钓鱼工作组（协调秘书处）、安全厂商（能力支撑）。
- 承诺事项（差异化）：与MANRS四行动对标的国内版最低实践集——注册数据准确维护、关键前缀ROA签署、成员单位间事件双向通报、应急联络人制度。
- 测量与背书：依托本课题平台（第3页）对成员实践合规度进行季度测量并向成员反馈；测量结果作为行业评优、资质审查的参考输入，形成声誉激励。
- 与钓鱼治理的跨域闭环：对涉及钓鱼重定向的路由事件，按"路由处置（本组）+域名处置（反钓鱼工作组）+受害人预警（成员单位）"三方联动模板执行——这是本课题区别于纯路由安全研究的核心特色落地场景。
06 · 历史案例对照：2008年YouTube劫持事件
2008年2月的事件是理解"人工协同时代"处置瓶颈的经典案例（多家公开资料记载）：巴基斯坦电信（AS17557）因内部审查要求在本地宣告YouTube前缀（208.65.153.0/24），该宣告经其上游PCCW（AS3491）泄露至全球，导致YouTube服务中断约2小时，最终由PCCW介入撤销。
- 与2024年1.1.1.1事件的对照：两案均为"单点误宣告＋上游放行"结构；不同的是，2024年受害方具备RPKI自身免疫、分钟级发现与对等断连等工具，MTTR从"小时级人工协调"缩短至"分钟级技术动作＋小时级根治"。
- 对度量体系的意义：2008年事件无MTTD统计（依赖用户投诉发现）；本课题MTTD/MTTA/MTTM框架正是为了让"处置效率可被度量、可被改进"。
- 上游责任：两案中上游过滤（基于IRR/前缀列表）均是最后防线，验证"上游过滤义务"应写入协同机制的最低承诺（第5页三要素的本地化）。
本节参考来源（第7页）
Cloudflare官方博客1.1.1.1事件报告（2024年6月）：blog.cloudflare.com（事件时间线与RPKI防御效果描述的来源）。
BleepingComputer对2024年6月BGP劫持事件的报道：bleepingcomputer.com（影响范围"70个国家/地区300多个网络"的公开报道口径，含分钟级时间线）。
NIST SP 800-61 Rev.2《Computer Security Incident Handling Guide》（2012）：csrc.nist.gov（事件响应闭环框架来源）。
MANRS《Actions》文档：manrs.org/participants/actions（缓解最佳实践参考）。
PeeringDB：peeringdb.com（协作联系人数据基础设施）。
公共互联网反网络钓鱼工作组：fandiao.org.cn（跨域协同机制组织基础）。
2008年巴基斯坦电信劫持YouTube事件（RIPE NCC/学术文献广泛记录）：路由劫持事件协同处置的历史参照，如《Internet Intelligence Redux》等CTI分析文献。