Résumé

  • Daté du 29 septembre, draft-ietf-schc-schclet-01 remplace le simple « TBD » des considérations de sécurité de la version 00 : les prescriptions de la RFC 8724 restent pertinentes et une entrée sans règle prise en charge doit recevoir un traitement sûr défini par la configuration.
  • Le texte ne crée ni le principe du SCHClet ni une garantie générale de transmission. C’est encore un Internet-Draft du groupe SCHC, à l’état I-D Exists, et non une RFC approuvée ou un bilan de déploiement.

Dans un réseau contraint, installer toute la chaîne SCHC peut coûter plus que la fonction recherchée. Le projet de groupe décrit depuis sa première version un sous-ensemble modulaire, limité à une strate et à une instance SCHC. Le document définissant un SCHClet doit indiquer la configuration qu’il prend en charge. Son dialogue avec une implémentation complète suppose que les paramètres et leur interprétation correspondent. Ces conditions ne sont donc pas les nouveautés de septembre.

La nouveauté vérifiable est plus étroite : la section 6 n’est plus vide. Elle rattache expressément le module aux considérations de sécurité de la RFC 8724 et des autres textes SCHC employés. Elle attire ensuite l’attention sur les entrées qui ne correspondent à aucune règle prise en charge. Les rejeter ou les laisser passer sont des exemples de traitement, subordonnés à la configuration du SCHClet. Le projet ne décrète pas qu’une de ces actions convient partout ; il n’apporte pas de résultats d’essais ni de politique déjà installée sur les équipements.

Cette nuance change la manière de lire une promesse commerciale de compatibilité. Deux appareils peuvent partager l’étiquette SCHC tout en divergeant au premier paquet situé hors du sous-ensemble de l’un d’eux. Il faut connaître la liste des règles, la nature de l’entrée, le point du traitement où elle devient « non reconnue », l’action retenue et la configuration de l’autre extrémité. La phrase conditionnelle du projet sur l’interopérabilité avec une pile complète ne remplace pas ces vérifications.

Une lecture trop rapide du « laisser passer » serait aussi dangereuse. La RFC 8724 demande la suppression silencieuse d’un paquet SCHC forgé dont le RuleID n’est pas attribué lorsqu’il atteint un décompresseur. Une entrée qui ne correspond à aucune règle prise en charge par un module restreint n’est pas nécessairement ce même paquet, au même endroit du chemin. La révision 01 ne démontre ni une dérogation à la RFC ni un conflit irréconciliable. Sans typologie des entrées et sans trajet précis, les deux affirmations dépasseraient les sources.

Le progrès du texte est donc celui d’une responsabilité nommée, pas d’un risque résolu. Dans une revue de conception, Daniel Kade proposerait de conserver ensemble le jeu de règles, la classe d’entrée, le choix rejet ou passage, la configuration du pair, la version logicielle et les essais. Il s’agit d’un critère éditorial d’audit, non d’une exigence nouvelle déjà adoptée par l’IETF. La révision ajoute aussi les formules de mots normatifs et remanie des références ; elle ne réclame pas d’action IANA immédiate. Aucune preuve d’incident, d’exploitation ou d’homologation n’accompagne ces changements.

Sources