Résumé

  • Sur UDP, le Message ID sert à reconnaître les doublons et à rattacher ACK ou Reset au message correspondant ; le Token rattache une réponse à la requête en attente, avec le contexte du point terminal.
  • L’égalité d’un Token ne prouve ni la personne, ni le propriétaire du terminal, ni l’autorisation, ni l’état actuel de la ressource, ni l’exécution effective de l’action demandée.

Imaginons deux alarmes dans un même tableau de bord. La première annonce que le même message a été reçu deux fois. La seconde annonce qu’une réponse a retrouvé la requête qui l’attendait. Si les deux alarmes sont rangées sous une seule colonne « identifiant de transaction », l’écran paraît plus simple. L’enquête, elle, vient de perdre sa grammaire.

CoAP a précisément prévu deux grammaires. La RFC 7252 place un Message ID de 16 bits dans la couche de messages utilisée sur UDP. Elle place le Token dans la couche requête-réponse. Carsten Bormann figure parmi les trois auteurs du texte. Quatre ans plus tard, la RFC 8323, dont il est le premier auteur cité, transporte CoAP sur TCP, TLS et WebSockets. Le transport fiable reprend la retransmission et la déduplication : le Message ID disparaît du format, mais le Token reste.

Cette soustraction vaut mieux qu’une définition abstraite. Elle montre la fonction irremplaçable de chaque champ.

Le Message ID décrit un échange limité

Sur UDP, une requête Confirmable peut être renvoyée si l’ACK se perd. Le destinataire revoit alors le même Message ID depuis le même point terminal. Il doit normalement acquitter chaque copie, tout en ne traitant qu’une fois la requête ou la réponse transportée. Le couple Message ID-point terminal aide aussi à rattacher un ACK ou un Reset au message qui l’a provoqué.

La portée est volontairement courte. Un émetteur ne doit pas réutiliser le même Message ID avec le même point terminal pendant EXCHANGE_LIFETIME. Le cache de doublons, la minuterie de retransmission et l’état de l’ACK appartiennent à cette fenêtre. Ils ne décrivent pas l’identité durable d’un appareil et encore moins celle d’un utilisateur.

Deux messages peuvent porter le même Token tout en utilisant des Message ID différents. C’est normal lorsqu’une réponse séparée arrive dans son propre échange. Inversement, un ACK vide peut reprendre le Message ID de la requête sans être encore la réponse applicative. Le premier rapproche des messages ; le second rapproche une réponse de son intention initiale.

Une télémétrie fidèle conserve donc Type, Message ID, point terminal, nombre de retransmissions, verdict de doublon et expiration du cache. Elle ne remplace pas ces champs par un état générique reçu.

Le Token appartient au client

Le client choisit le Token et le serveur le renvoie sans modification dans toute réponse produite. La RFC 7252 le présente comme un identifiant local au client pour distinguer ses requêtes simultanées ; « request ID » aurait aussi convenu. La recommandation d’unicité porte sur les Tokens actuellement utilisés pour une paire de points terminaux source-destination.

Cette phrase interdit plusieurs extrapolations. Il n’existe pas d’espace mondial des Tokens. La même valeur peut être réutilisée avec un autre point terminal. Un Token vide est même acceptable lorsque les requêtes sont strictement sérielles ou qu’aucun autre Token n’est actif vers la destination. Le serveur qui n’a pas généré la valeur doit la traiter comme opaque, sans supposer son contenu ni sa structure.

Le Token ne peut donc pas être lu comme un nom de compte. Il n’est pas un certificat de l’entreprise qui exploite le capteur. Il n’emporte aucun droit d’écriture sur la ressource. Il dit seulement au client : cette réponse est candidate pour telle attente locale, sous réserve que le point terminal et les autres règles concordent.

Dans une réponse intégrée à l’ACK, Message ID et Token concordent. Dans une réponse séparée, le Token assure le lien requête-réponse tandis que le nouveau message possède sa propre mécanique. Ce détail suffit à invalider les schémas de logs qui promettent une correspondance univoque entre Message ID et opération métier.

Le transport fiable révèle la frontière

TCP fournit retransmission, ordre et déduplication des octets. CoAP n’a donc plus besoin de ses types CON, NON, ACK et RST pour la même fonction. La RFC 8323 remplace cette couche par un cadrage sur le flux et retire Type ainsi que Message ID.

Le Token demeure dans la trame. Le transport peut livrer correctement plusieurs requêtes simultanées ; il ignore quelle réponse CoAP satisfait quelle requête CoAP. C’est au Token et à l’état local du client de résoudre ce problème.

Pour l’exploitation, la comparaison produit un arbre de diagnostic. Une anomalie propre à UDP oriente vers la réutilisation des Message ID, le cache de doublons, les temporisations, les ACK ou les retransmissions. Une anomalie commune à UDP et TCP oriente plutôt vers la génération des Tokens, la table des requêtes en attente, le contexte du point terminal ou de la connexion, l’intermédiaire et le traitement de la réponse.

Une connexion TLS peut, selon sa configuration, fournir une preuve de pair que le simple tuple UDP n’offre pas. Cette preuve appartient à la session de sécurité. La recopier dans la colonne Token rendrait les deux éléments impossibles à renouveler et à contester séparément.

Le hasard ne fabrique pas un titulaire

Sans sécurité de transport, la RFC 7252 recommande un Token non trivial et aléatoire. Sur l’Internet général, elle recommande au moins 32 bits de hasard. Un attaquant hors chemin qui ne voit pas la requête doit alors deviner la valeur pour injecter une fausse réponse acceptée.

C’est une protection concrète, mais étroite. Un observateur sur le chemin peut voir la valeur. Un proxy la connaît sur son propre tronçon. Un générateur défaillant peut répéter des Tokens. Un état local conservé trop longtemps peut accepter une réponse ancienne. Le Message ID n’ajoute que peu de protection, car il est souvent séquentiel et une réponse séparée peut contourner sa valeur.

L’événement « Token correct » signifie que la réponse a passé une épreuve de corrélation dans un modèle de menace donné. Il ne signifie pas « serveur authentifié ». Les modes de sécurité, les associations DTLS ou TLS, l’authentification et l’autorisation ont leurs propres preuves. Un système peut avoir un Token excellent sur un canal non authentifié, ou un canal authentifié avec une erreur de Token. Les deux axes doivent rester visibles.

Chaque intermédiaire ouvre un nouvel espace de corrélation

Les Tokens CoAP sont de proche en proche. Un proxy reçoit le Token du client et son adresse de transport, conserve l’association, puis envoie sa propre requête vers le serveur d’origine avec son propre Token. Au retour, il consulte sa table et reconstruit la réponse destinée au client.

La valeur observée côté serveur peut donc ne jamais avoir circulé côté client. Un incident qui ne conserve que le Token amont ne peut nommer la requête aval. Pour reconstruire le trajet, il faut une jonction locale produite par l’intermédiaire, datée, limitée et protégée. Cette jonction est une preuve de l’opérateur du proxy, non un attribut end-to-end du protocole.

Cela change aussi la responsabilité. Le client répond de sa table d’attente. Le proxy répond de sa correspondance entre deux tronçons. Le serveur répond du traitement de la ressource. La couche de sécurité répond de son identité de pair. Aucun acteur ne peut déduire les conclusions des autres à partir de son seul Token.

Déplacer l’état dans le Token ne le supprime pas

La RFC 8974 permet de sérialiser une partie de l’état d’une requête dans un Token plus long. Le serveur renvoie les octets, et le client reconstitue le contexte qu’il aurait autrement gardé en mémoire. Ce texte est signé par Klaus Hartke et Michael Richardson, pas par Bormann ; il sert ici à éprouver la limite du mécanisme défini auparavant.

Le mot « stateless » y est explicitement présenté comme simplificateur. Il reste un état par serveur, un état de génération des Tokens, un état de contrôle de congestion et, pour les messages Confirmable sur UDP, un état d’échange. Avant de dépendre des Tokens étendus, le client doit normalement découvrir leur prise en charge par un échange qui, lui, conserve un état.

L’octet transporté devient par ailleurs une surface d’attaque. L’intégrité empêche une modification silencieuse. Une fenêtre anti-rejeu et une information de fraîcheur distinguent un retour tardif. Le chiffrement protège les données privées. La taille doit être bornée pour ne pas épuiser la mémoire d’un nœud contraint. Une chaîne de proxies « sans état » peut grossir la valeur à chaque saut.

Le serveur n’a toujours pas certifié la structure interne. Il a renvoyé une suite opaque. Le client récupère son propre état, sous la protection qu’il a lui-même conçue. La garde de l’information a changé ; sa vérité et sa responsabilité n’ont pas été transférées au serveur.

Le reçu complet commence là où le Token s’arrête

Un reçu exploitable nomme d’abord le point d’observation, l’heure monotone et l’heure civile. Il précise UDP, TCP, TLS ou WebSocket, le tuple ou la connexion, puis la session de sécurité et le pair authentifié lorsqu’il existe.

Il conserve ensuite le Message ID et le type pour UDP, le Token sous une forme compatible avec la confidentialité, la méthode, la cible, la requête locale en attente, la forme de la réponse, son code et le verdict de corrélation. Chez un proxy, il ajoute la jonction entre les deux tronçons. Il garde les versions du logiciel, de la configuration et des politiques qui fixent la durée de validité de ces faits.

Enfin viennent les décisions que CoAP ne peut prendre à lui seul : autorisation de lire ou modifier, version de la ressource, validation métier, engagement en base, accusé d’un actionneur ou observation physique indépendante. Une réponse 2.xx est une déclaration du serveur dans un contexte ; elle n’est pas toujours une preuve durable du monde extérieur.

La force du protocole compact tient précisément à cette modestie. La spécification commune définit ce qu’il faut pour interopérer. Le client, l’opérateur, le propriétaire de l’application et le responsable de la sécurité gardent leurs décisions locales. Le standard fournit des objets vérifiables, pas un verdict universel.

Une attribution elle aussi limitée

Le profil IETF consulté le 30 août 2026 recense 65 RFC pour Carsten Bormann et le présente comme président de CoRE et du groupe de recherche Thing-to-Thing. Ces données situent une contribution importante, mais elles évolueront. Elles ne donnent pas à un auteur le pouvoir de certifier les mises en œuvre.

La preuve documentaire est plus sobre : Bormann a coécrit la RFC 7252 et figure en tête des auteurs de la RFC 8323. Les deux textes sont issus d’un processus collectif de l’IETF. Le code exécuté, la configuration active, la capture et le résultat applicatif indiquent ensuite ce qu’un opérateur a réellement adopté.

Ne pas transformer l’auteur en mandant suit la même règle que ne pas transformer le Token en identité. Dans les deux cas, on conserve la contribution réelle et on refuse l’autorité ajoutée par commodité.

Le Token a retrouvé sa réponse. Ce résultat mérite une ligne exacte, pas une légende.

Sources