Cloudflare测试IPsec防降级扩展：两端都需支持，相关标准仍在发布流程中

10-01 4阅读

2026 年 9 月 29 日，Cloudflare 介绍了 IPsec 防降级保护的进展。公告讨论的是协议协商时如何避免能力被削弱，以及一项已经开始测试的扩展。它不是“所有 IPsec 流量已经遭到量子破解”的通报，也不是全网设备已经完成升级的声明。

配图为 AI 生成的概念示意图，非真实产品界面、设备照片或测试现场。

测试状态和生效条件要一起看

Cloudflare 表示，Cloudflare WAN 与 Magic Transit 已提供 beta 支持，客户可联系客户经理申请开启。防护有效需要通信双方支持该扩展。公告讨论的量子攻击要求在握手期间完成实时量子计算，厂商也说明目前还不知道何时可行。

IETF 的对应文档在本文核验时仍标为活动 Internet-Draft，状态为 RFC Ed Queue。文档描述让双方认证完整的初始握手记录，在双方实现扩展且至少一项相关认证凭据未被攻破等条件下提供防降级保护。不能把“进入发布队列”写成已经发布了最终 RFC。

可以用双方核对会议纪要来理解这类问题：只证明自己说过什么，还需要确认对方看到的是同一段对话。协议协商中，支持一种算法与最终确实协商使用它也不是同一回事。这只是帮助理解目标的类比，具体安全性质仍应以协议文档为准。

对运维人员而言，一份设备清单至少应区分产品支持、软件版本支持、配置启用和连接实际协商结果。四项都写成“支持后量子”会掩盖实施差异。尤其在设备逐步更新时，旧端点仍可能影响一条链路的最终行为。

以下是本文的部署评估建议。先整理每条隧道两端的型号、版本和维护方，向厂商确认扩展兼容情况，再在允许的测试窗口核对成功连接、重连和异常行为。测试记录中保留当时的配置与实际结果，避免把计划启用当成验证完成。

如果两端由不同团队维护，先约定谁确认版本、谁观察连接状态，以及出现兼容问题时怎样恢复服务。单边打开一个选项并不能证明整条链路得到预期保护；是否进入生产，应取决于双方验证结果。

这是一项面向迁移过程的协议改进。读者可以持续关注标准状态和设备实现进展，但不应仅因新闻标题就立即更改生产网络参数。本文只报道公开进展，没有进行隧道测试或替任何组织修改网络设置。

Cloudflare：IPsec降级攻击防护（2026-09-29）；IETF：IKEv2防降级扩展草案状态（2026-10-01核验）。本文于北京时间 2026 年 10 月 1 日核验，后续状态以官方更新为准。