摘要

  • 9月29日的 draft-ietf-schc-schclet-01 将第00版安全章节的“待定”替换为具体文字：SCHClet 继承 RFC 8724 等已采用规范的安全考虑，未匹配任何受支持 Rule 的输入应依照 SCHClet Configuration 得到安全处置。
  • 模块化、必须说明受支持配置，以及与完整实现的有条件互通，并非这次新增。文件仍处于 I-D Exists，没有成为 RFC，也没有给出真实设备的互通测试结果。

在资源受限的网络里，只装所需的压缩或分片功能有实际吸引力。SCHClet 的初版已将它定义为 SCHC 框架的功能子集，限定在单一 Stratum 和单一 SCHC Instance 内。规定某个 SCHClet 的文件必须写明它支持的配置；完整实现与其互通，也要以相容的配置和双方一致的理解为前提。这些基础条件不能被包装成9月的新突破。

真正的版本差异集中在第6节。旧稿只有一个留待补写的占位词；新稿说明适用 RFC 8724 以及其他所用 SCHC 规范的安全考虑，并要求实现者安全处理没有匹配受支持规则的输入。拒绝和放行是文中列出的例子，实际选择依配置而定。它没有规定所有产品必须采用同一默认动作，也没有交付测试向量、部署调查或已验证的安全结论。

这使“支持 SCHC”成为一个需要拆开的说法。两个端点可能都声称遵循框架，却在某个窄模块没有实现的规则上出现不同路径。评估者至少要知道模块支持哪些 Rule、未匹配的究竟是原始输入还是已编码报文、决策发生在哪个处理环节、配置选择什么动作、对端按什么规则解释。草案的互通表述带着前提，不等于给任何一对实现盖章。

尤其不能把“可按配置放行”读成普遍的转发许可。RFC 8724 第12.1.1节谈的是到达解压端、RuleID 未获分配的伪造 SCHC 报文，并要求静默丢弃。一个窄 SCHClet 所支持的规则集合之外的输入，未必就是同一种报文，也未必位于同一处理阶段。现有文件不足以断言新稿推翻了 RFC 的处理方式，也不足以仅凭这两个句子宣布标准冲突。要判断，先得交代输入类别和具体路径。

治理意义不在于风险已被解决，而在于空白处终于出现了可审查的责任。Daniel Kade 的编辑判断是把受支持规则、输入类别、拒绝或放行动作、对端配置、软件版本与测试证据放在同一份审查记录中。这是本文提出的操作检查表，并不是 IETF 已采纳的新强制条款。第01版另增规范用语说明和参考文献整理，但未要求立即调整 IANA 登记；文中没有事故、漏洞利用、工作组最后征求意见完成或批准发布的证据。

资料来源