Résumé

  • RFC 9868 emploie l’espace du transport IP situé après UDP Length comme surplus area pour des options de transport ; cet espace est distinct des données utilisateur UDP.
  • DTLS protège les données utilisateur, non les options UDP. Une charge protégée, une OCS valable ou une option envoyée ne remplacent donc pas la preuve de protection, de traitement ou d’effet.

Une extension de paquet devient trompeuse lorsqu’on lui prête une assurance qui appartient à une couche voisine. RFC 9868 tire parti de l’écart possible entre UDP Length et l’espace de transport indiqué par IP. Les octets avant cette limite sont les données utilisateur ; ceux qui restent forment une zone d’options pour une mise en œuvre qui connaît cette extension. Le RFC définit une mécanique de transport, non une attestation sur l’autre extrémité, le réseau traversé ou l’action de l’application.

La mécanique reste volontairement étroite. UDP demeure sans état et unidirectionnel ; les options constituent un cadre, pas un protocole achevé. Hormis les options déclarées obligatoires pour une implémentation qui prend en charge UDP Options, l’émetteur ne peut imposer leur traitement. Le récepteur garde sa politique locale pour les options facultatives. « L’option a été envoyée » est donc un fait d’émission, non une preuve de compatibilité, de conservation par le chemin ou de réponse du pair.

La frontière de protection est explicite. RFC 9868 rappelle que TLS et DTLS ne protègent pas la couche de transport : DTLS opère sur les données utilisateur UDP. Le mécanisme d’options n’apporte pas non plus de protection spécifique contre la modification de l’en-tête, de la charge ou de la zone excédentaire, sauf celle d’OCS, AUTH, UENC ou d’une autre couche telle qu’IPsec. Sans chiffrement pertinent, les options restent visibles sur le chemin. Une session DTLS ne permet pas de conclure que l’option voisine est chiffrée, authentifiée ou intacte.

OCS doit conserver son sens limité. Il détecte des erreurs dans la zone excédentaire ; il ne désigne pas une autorité, ne garantit pas un itinéraire et n’approuve aucune décision. Pour préserver le comportement des équipements anciens, un récepteur peut encore livrer les données utilisateur tout en ignorant les options lorsqu’une OCS applicable échoue. Le journal utile décrit une évaluation locale sous une politique identifiée, et non une réussite de sécurité exprimée de façon générale.

RFC 9869 rend visible l’écart entre syntaxe et observation : son emploi de DPLPMTUD exige l’activation chez l’émetteur et le récepteur ainsi qu’un accusé explicite de la sonde. Une option définie ne mesure pas à elle seule un chemin. RFC 9868 note aussi que certains chemins peuvent retirer la zone excédentaire ou abandonner le datagramme. La capacité de former l’option, le constat de chemin, l’accusé du pair et le résultat applicatif doivent rester des enregistrements distincts.

Pour la gouvernance, cette séparation est une force. Conserver l’option produite, la protection demandée, la politique du récepteur, une observation corrélée et la conséquence applicative évite qu’un artefact commun se transforme en décision locale invisible. RFC 9868 rend le format testable ; l’activation, le seuil de protection et l’usage du résultat restent des responsabilités locales, conformément à la discipline de Heng Lu.

Sources