Résumé

  • Un paquet Kiss-o'-Death place Stratum à 0 et transforme le Reference Identifier en code de statut : ses timestamps serveur doivent être écartés et ne peuvent régler l'horloge.
  • Le client ne peut obéir qu'après avoir rattaché la réponse à sa requête, puis il applique l'effet précis de DENY, RSTR ou RATE sous une limite locale, car un refus non authentifié peut lui-même servir au déni de service.

Ce que le silence ne pouvait pas demander

L'origine pratique du mécanisme apparaît dans le RFC 4330. De nombreux routeurs domestiques et de bureau avaient été configurés pour interroger un serveur de temps universitaire. Dans certaines conditions d'erreur, une fraction importante envoyait un paquet par seconde. Le pic fut spectaculaire et sa maîtrise exigea des mesures extrêmes.

La panne n'était pas seulement un excès de débit. Elle révélait une asymétrie : le client savait demander, le serveur savait répondre ou jeter, mais la réponse ordinaire ne disposait pas d'un vocabulaire borné pour dire « arrêtez » ou « ralentissez ». Un paquet perdu pouvait d'ailleurs être interprété comme une raison de recommencer.

La place technique existait déjà. Le RFC 1305 qualifiait le Stratum 0 de non spécifié sans attribuer, dans ce cas, un rôle de message au Reference Identifier. RFC 4330 utilisa ce couple vacant. Avec Stratum 0, les quatre octets du champ devinrent un kiss code ASCII. La réponse fut nommée Kiss-o'-Death, ou KoD.

Le protocole n'ajoutait donc ni port ni conversation de contrôle. Il faisait voyager une information négative sur le chemin même de la demande. Cette économie facilitait la coopération d'un grand nombre de clients, mais elle imposait de distinguer très nettement le statut de la mesure.

Le paquet quittait le calcul du temps

Une réponse NTP normale apporte les timestamps de réception et d'émission du serveur. Avec les instants observés par le client, ils contribuent à estimer décalage et délai. Un KoD conserve la forme mais retire la valeur probante.

Le RFC 5905 dit que Stratum 0 implique une valeur non spécifiée ou invalide. Le Reference Identifier peut alors transporter un état ou un contrôle d'accès. Surtout, les Receive et Transmit Timestamps du serveur sont indéfinis : le destinataire ne doit pas s'y fier et doit les écarter.

Il ne s'agit donc pas d'un échantillon médiocre auquel serait jointe une alerte. C'est une autre catégorie de message. Son effet possible porte sur l'association et le rythme des requêtes, jamais sur la correction de l'horloge. En séparant l'entrée « mesure » de l'entrée « commande négative », NTP évitait que la protection du serveur ne contamine directement le temps du client.

Une provenance liée à la requête

Reconnaître quatre lettres ne suffit pas. Dans l'échange client-serveur, l'Origin Timestamp de la réponse doit reprendre le Transmit Timestamp de la demande. RFC 5905 utilise cette égalité pour repérer paquet trompeur ou rejeu. Le RFC 8633 en fait une condition explicite : un client ne doit accepter un KoD que si l'Origin Timestamp est valide.

La séquence correcte est ainsi ordonnée. Le client rattache d'abord le paquet à une requête en attente. Il constate ensuite Stratum 0, retire les timestamps serveur de toute discipline d'horloge, lit le code et n'accorde que l'action prévue.

Cette liaison n'est pas une authentification cryptographique. Elle réduit la capacité d'un datagramme arbitraire à se faire obéir, mais elle ne démontre pas l'identité institutionnelle du serveur ni la véracité du motif. La provenance disponible dépend encore de ce qu'un attaquant peut observer ou apprendre du flux.

Trois refus, trois transitions

DENY signifie que le serveur distant refuse l'accès ; RSTR, qu'une politique locale le restreint. Dans les deux cas, RFC 5905 exige la démobilisation de l'association et l'arrêt des paquets vers ce serveur. RATE indique un seuil de requêtes dépassé : le client doit diminuer immédiatement sa fréquence et continuer de reculer si les RATE se répètent.

Ces conséquences ne forment pas une commande générique. RATE laisse ouverte une mesure future. DENY et RSTR mettent fin à cette relation. Aucun des trois ne permet de régler l'heure. Les codes commençant par X restent privés ou expérimentaux, et une valeur inconnue n'autorise pas une transformation arbitraire de l'état local.

Le registre actuel des paramètres NTP de l'IANA maintient ce vocabulaire, avec notamment DENY, RSTR, RATE et NTSN. Il stabilise le sens documentaire d'un identifiant. Il ne certifie ni le paquet reçu, ni l'existence de la condition annoncée, ni la sûreté d'une réaction particulière pour ce client.

Obéir sans disparaître

Le RFC 8633 recommande de respecter le KoD, en particulier sur les appareils embarqués dépourvus d'interface de contrôle visible. Pour RATE, l'intervalle de sondage devrait monter jusqu'à un maximum raisonnable défini par l'implémentation, sans dépasser l'exposant 13, soit deux heures.

Mais le client ne doit pas copier aveuglément la valeur poll proposée. Une valeur énorme peut suspendre les demandes assez longtemps pour produire un déni de service. La protection d'un serveur ne justifie pas l'abandon indéfini du besoin de temps du client.

L'autre côté n'est pas garanti non plus. Certains clients ignorent RATE ; d'autres implémentations défectueuses peuvent accroître le trafic. Le serveur doit conserver des moyens hors protocole : rejet, limitation, filtrage et observation. KoD ajoute une coopération possible, pas une garantie de civisme.

La décision est donc distribuée. Le serveur décrit sa limite. Le client juge si la réponse lui appartient, borne le recul, choisit une source de remplacement et décide quand reprendre. Le signal n'est utile que parce qu'aucun de ces rôles ne possède seul toute l'autorité.

NTS renforça le rattachement sans transformer le refus en heure

Le RFC 8915 définit Network Time Security pour le mode client-serveur. Une réponse protégée doit contenir le Unique Identifier d'une requête en attente et être authentique sous la clé serveur-vers-client correspondante. Un échec de l'une ou l'autre vérification impose l'abandon du paquet.

Si le serveur ne peut valider le cookie ou authentifier la requête, il peut produire un KoD NTSN, pour NTS negative acknowledgment. Puisqu'il n'a pas récupéré l'état protégé, cette réponse ne contient ni NTS Cookie ni champ Authenticator.

Cette exception n'offre pas un bouton de déclassement. Après des réponses NTS authentiques, un KoD ultérieur doit reprendre le Unique Identifier d'une requête en attente ; sinon le client le jette. Une nouvelle négociation NTS-KE peut suivre une dissociation forcée, mais ses reprises doivent être limitées afin de ne pas créer une boucle supplémentaire. Le client ne bascule pas automatiquement vers NTP non protégé.

L'authentification améliore donc la réponse à « est-ce bien mon échange ? ». Elle ne change pas la réponse à « de quel type d'information s'agit-il ? » : le KoD reste un contrôle négatif dont les timestamps ne valent pas mesure.

Quatre octets sous gouvernance

RFC 5905 créa les registres IANA des Reference Identifiers et des kiss codes. Le RFC 9748 passa ensuite leur procédure à Specification Required, limita les nouvelles valeurs ASCII aux majuscules et aux chiffres complétés à droite par des zéros, réserva le préfixe X à l'expérimentation et demanda l'accord de deux experts désignés sur trois.

Ce contrôle est proportionné à la portée potentielle d'un code minuscule. Quatre octets peuvent être intégrés dans des appareils qui resteront actifs des années. Une spécification publique et un examen de l'objectif réduisent les collisions de sens.

Le registre ne gouverne pourtant que la langue commune. Légitimité et prudence se construisent à l'exécution : requête correspondante, authentification disponible, code reconnu, effet limité et stratégie de retour. Le paquet d'heure qui ne donnait pas l'heure a rendu le refus exploitable précisément sans lui accorder la souveraineté sur l'horloge ou la disponibilité du client.

Sources et limites

Le vide antérieur vient du RFC 1305, l'incident et le KoD explicite du RFC 4330. Les actions et l'abandon des timestamps sont dans le RFC 5905, les bornes opérationnelles dans le RFC 8633, le traitement NTS dans le RFC 8915, et la gouvernance dans le RFC 9748 et le registre IANA. Ces sources ne mesurent ni déploiement, ni conformité, ni fréquence d'attaque en 2026.