Résumé

  • Un Kiss-o’-Death place le paquet au stratum zéro : ses horodatages de réception et d’émission ne fournissent aucune heure exploitable, et son Reference Identifier devient un code d’état.
  • RATE, DENY ou RSTR n’agissent que si le client rattache la réponse à sa requête, applique le bon changement d’état et conserve des bornes contre une instruction erronée ou falsifiée.

Un paquet NTP peut avoir la bonne taille, arriver du bon port et répondre à une requête réelle, tout en ne disant absolument pas quelle heure il est. Cette propriété paraît paradoxale seulement si l’on suppose qu’une réponse doit continuer la fonction habituelle du protocole. Le Kiss-o’-Death, ou KoD, fait autre chose : il utilise l’enveloppe de la mesure pour parler de la relation entre le client et le serveur.

Quatre octets en attente d’une règle

Le format avait précédé l’usage. RFC 1305, spécification de NTPv3 publiée en 1992, qualifiait le stratum zéro d’« unspecified » et représentait le Reference Identifier des strata zéro et un par quatre caractères ASCII. RFC 2030 conserva cette disposition dans SNTPv4 en 1996. Aucune des deux normes ne donnait encore à ces quatre octets le pouvoir précis de demander l’arrêt ou le ralentissement d’un client.

Cette chronologie évite une histoire trop lisse. Le KoD n’était pas caché depuis l’origine dans la structure du paquet. Un espace disponible n’est pas un accord. Il a fallu qu’un coût opérationnel devienne visible, puis qu’une norme définisse les conditions et les conséquences de son emploi.

RFC 4330, en 2006, raconte ce coût. De très nombreux routeurs domestiques et de bureau avaient été configurés pour consulter le même serveur universitaire. Certains envoyaient une requête par seconde. La population installée augmentant, le trafic devint spectaculaire et l’opérateur dut prendre des mesures extrêmes.

Le constructeur avait localisé la facilité chez lui et exporté la charge ailleurs. Un nom de serveur inscrit une fois dans le logiciel créait des années de paquets, sans nouveau consentement et parfois sans moyen de mise à jour. Le problème n’était donc pas seulement la fréquence. C’était la durée d’une décision prise par un acteur qui ne payait pas directement le service qu’il sollicitait.

Le zéro changeait la nature de la preuve

RFC 4330 donna au stratum zéro une fonction nouvelle dans une réponse : le Reference Identifier de quatre caractères devenait un « kiss code ». DENY signalait un refus d’accès, RSTR une restriction de politique, RATE un dépassement de cadence. INIT et STEP décrivaient des états transitoires du serveur.

RFC 5905 fixa ensuite le comportement NTPv4. Un paquet de stratum zéro est impropre à la synchronisation. Ses Receive Timestamp et Transmit Timestamp sont indéfinis et doivent être rejetés. On ne peut donc pas le conserver comme une mesure faible, calculer un offset, puis lui attribuer une confiance réduite.

Le paquet change de catégorie probatoire. Une réponse ordinaire fournit des éléments pour estimer l’heure. Un KoD ne fournit que des éléments pour décider de la prochaine interaction. Le code décrit une intention du serveur ; il ne prouve ni que la restriction est légitime, ni que le serveur est bien celui qu’il prétend être, ni que le client a réellement modifié son comportement.

RATE avait besoin d’un erratum pour aller dans le bon sens

Pour DENY et RSTR, RFC 5905 demande de démobiliser l’association et de cesser d’envoyer des paquets à ce serveur. Pour RATE, le client doit espacer ses requêtes. Pourtant, le texte publié disait initialement qu’il fallait réduire l’intervalle de poll. Une réduction provoque davantage de paquets : le mécanisme de protection aurait alimenté la surcharge.

L’erratum vérifié 3007 corrige le verbe : le client augmente l’intervalle. Cette petite correction révèle un principe plus grand. La conformité à une étiquette ne suffit pas. Il faut vérifier le sens causal de la transition. Si les requêtes deviennent plus fréquentes après RATE, l’implémentation contredit le mécanisme, même si elle peut citer la phrase originale de la RFC.

Le KoD dépend ainsi d’une coopération exacte. Un client correct reconnaît le code, valide son contexte et change son minuteur. Un équipement ancien peut l’ignorer. Un logiciel défectueux peut accélérer. Le serveur n’exécute aucune instruction dans la machine distante ; il émet une proposition de transition.

Une réponse n’avait de place que derrière une question vivante

RFC 8633, Best Current Practice de 2019, exige que le KoD comporte un Origin Timestamp valide. Cette valeur doit correspondre à la requête que le client garde encore en attente. Un paquet arrivé hors de ce contexte n’a pas qualité pour modifier l’association.

La vérification réduit le champ de l’instruction, mais ne l’authentifie pas. Elle répond à « est-ce une réponse à ma question actuelle ? », non à « qui a écrit cette réponse ? ». Dans un échange sans protection cryptographique, un adversaire capable d’observer ou de deviner les éléments utiles peut chercher à fabriquer un refus plausible.

L’exploitation n’a pas besoin de falsifier l’heure. Un faux DENY retire une source ; un faux RATE retarde la prochaine mesure. L’attaque gouverne la collecte de preuves plutôt que la valeur de l’horloge.

Le client doit aussi refuser une délégation sans bornes. Accepter aveuglément une valeur de poll très élevée donnerait au serveur — ou au faussaire — le pouvoir de suspendre longtemps les consultations. RFC 8633 évoque comme plafond raisonnable un exposant de poll ne dépassant pas 13, soit environ deux heures. Le chiffre est une politique technique ; le principe est constitutionnel : le serveur peut exprimer sa pression, pas acquérir un droit illimité sur le calendrier futur du client.

Le message poli ne remplaçait pas le filtre

Le KoD ne protège que contre les clients qui savent l’écouter. RFC 8633 constate que certains l’ignorent ou l’implémentent de travers. Un serveur doit donc conserver une défense hors protocole : abandon de paquets, limiteur, protection des files et capacité adaptée.

Cette juxtaposition n’est pas un échec de conception. Elle trace la frontière entre coordination et coercition. Le message permet à un pair bien élevé de se retirer avec une cause compréhensible. Le filtre protège l’infrastructure quand aucune coopération ne peut être obtenue. Transformer le premier en faux pouvoir de police aurait masqué cette différence sans réparer les firmwares abandonnés.

NTSN : traverser une panne d’authentification sans abolir l’authentification

Network Time Security rend les réponses ordinaires vérifiables, mais crée un cas délicat. Si le serveur ne peut plus valider le cookie ou l’authenticator du client, il ne peut pas fabriquer la réponse protégée qui expliquerait cet échec. RFC 8915 définit alors le code spécial NTSN.

Le serveur ne joint pas les champs habituels NTS Cookie et NTS Authenticator and Encrypted Extension Fields. Le client qui avait déjà reçu des réponses authentiques exige toutefois un Unique Identifier correspondant à une requête en attente. Il attend le prochain poll normal ; si aucune réponse protégée valable n’arrive, il relance NTS-KE, limite la cadence de ces tentatives et conserve ses anciens paramètres jusqu’au succès.

Ce chemin est volontairement lent et étroit. NTSN n’authentifie pas magiquement un KoD. Il corrèle une exception non authentifiée à un échange précis et empêche cette exception de déclencher immédiatement une boucle coûteuse. Le dessin protège à la fois la récupération et la raison d’être de NTS.

Le registre coordonnait les mots, pas les machines

RFC 5905 créa un registre IANA afin d’éviter que plusieurs normes donnent des sens concurrents aux mêmes quatre caractères. RFC 9748 actualisa ce cadre en 2025 : jusqu’à quatre caractères ASCII, complément par des octets nuls, préfixe X réservé aux expériences, lettres majuscules et chiffres pour les nouveaux codes, enregistrement sous le régime Specification Required.

Le registre réduit les collisions sémantiques. Il ne certifie pas les implémentations et ne confère aucune autorité au paquet reçu. Un code enregistré peut être falsifié, ignoré ou mal exécuté. Sa fiche dit ce qu’une spécification entend par ces caractères ; elle ne dit pas ce qui s’est passé dans une machine donnée.

Le KoD reste ainsi une petite constitution entre pairs. La norme définit le message. Le serveur choisit de l’émettre. Le client conserve la validation et la décision locale. L’opérateur conserve le filtre. Aucune institution centrale ne choisit la source de temps de tous les appareils ni ne fixe leur cadence universelle.

L’autre histoire NTP publiée par BTW explique comment quatre horodatages, plusieurs sources et une horloge locale produisent une heure révisable. Celle-ci commence là où aucune mesure n’est fournie. Son objet est plus étroit : rendre le refus visible sans confondre visibilité et commandement.