Summary

  • The SCHC Working Group's 29 September draft-ietf-schc-schclet-01 fills a Security Considerations section that said only TBD in January's -00: a SCHClet inherits RFC 8724's security guidance, while inputs matching no supported Rule need safe handling according to its configuration.
  • This does not introduce SCHClets or grant a universal right to pass traffic through. The draft was already about a declared subset and conditional interoperability; revision 01 makes the consequence of that subset's edge explicit. It is still an Internet-Draft at I-D Exists, not an approved RFC or deployment record.

The engineering appeal of a SCHClet is easy to see. A constrained device may need one compression or fragmentation function without carrying every function in a full Static Context Header Compression implementation. The WG draft describes such a module operating within one Stratum and one SCHC Instance, with its supported configuration defined in the document specifying it. Those constraints were present in revision 00. A reader who treats the September text as the birth of modular SCHC misses the actual change.

The change lies in section 6. The earlier version left security to be written later. Revision 01 says a SCHClet inherits the Security Considerations of RFC 8724 and other SCHC specifications it uses. It then asks implementers to ensure that inputs matching no supported Rule are handled safely, offering rejection or pass-through as examples depending on what the SCHClet Configuration defines. The draft does not choose a single fallback for every implementation, publish a test suite, or show how deployed peers behave.

That choice matters precisely because a subset is a boundary. A full peer and a narrow module can interoperate only under compatible configuration and interpretations; the draft's conditional claim is not a certificate for any pair of devices. Operators need to know which Rules the small implementation recognises, what sort of input reaches the unmatched path, what its configured action is, and whether the peer expects that action. Saying both endpoints are “SCHC-compatible” erases the decision that determines the failure mode.

There is also a limit to the word “pass-through.” RFC 8724 already discusses a forged SCHC packet with an unallocated RuleID at a decompressor and says it should be silently dropped. The SCHClet revision's example of a configured pass-through for an input that matches no supported Rule cannot simply be read as permission to forward that forged packet. These may be different input classes at different processing stages. The draft does not furnish the implementation detail needed to collapse them into one case, so neither a claimed conflict nor a blanket exception is justified.

For governance, the important move is from an empty security placeholder to a reviewable configuration decision. A standards document can describe a modular boundary, but a deployment's authority over unmatched input lives in the actual rule inventory and fallback setting. A review record should distinguish the supported Rules, input class, reject-or-pass-through action, peer configuration, software version, and test evidence. That is this article's proposed operating discipline, not a new IETF requirement. The -01 revision also adds normative-keyword boilerplate and reference housekeeping; it requests no immediate IANA action. None of those edits establishes WG last-call completion, approval, exploitation, or an installed safety default.

Sources