Résumé

  • RFC 9760 fixe un profil PTP interopérable pour l’entreprise, sans imposer de performance temporelle.
  • L’algorithme Best TimeTransmitter choisit un Grandmaster à partir des propriétés Announce ; il attribue un rôle dans un domaine, sans certifier la référence externe ni le délai du trajet.
  • La comparaison de plusieurs domaines, la diversité réelle des chemins, l’autorisation des sources et l’observation au niveau de l’application sont des reçus distincts.

Neuf décimales ne font pas une preuve

Le moteur d’horodatage inscrivit l’événement à la nanoseconde. Le Grandmaster était bien celui qu’avait choisi le domaine, les messages Announce continuaient d’arriver et aucun port PTP ne signalait de panne. Pourtant, le repère externe de la source s’était décalé.

RFC 9760 rend cette scène possible sans incohérence normative. Son profil d’entreprise réduit les choix de PTPv2.1, organise les échanges et impose l’algorithme standard de sélection. Il précise toutefois qu’il ne définit aucune exigence de performance temporelle. L’environnement financier cité peut viser de 100 microsecondes à 1 nanoseconde par rapport au Grandmaster ; cette motivation ne devient pas une garantie.

Il faut donc distinguer la finesse de représentation, la conformité du profil, la sélection de la source, la discipline de l’horloge et l’exactitude de l’événement métier. Un système peut réussir les quatre premiers contrôles apparents et échouer au dernier.

Le profil réduit l’ambiguïté de configuration

Un profil PTP indique les options obligatoires, permises et interdites. Ici, le transport est UDP sur IPv4 ou IPv6, la mesure du délai est End-to-End, certains messages communs sont multidiffusés et les réponses propres à un récepteur peuvent être envoyées en unicast. Le gain principal est l’interopérabilité entre équipements indépendants.

Les registres complètent cette coordination. Le registre IANA des services et ports donne un sens commun aux numéros de transport ; le registre des adresses multicast IPv6 fixe l’espace d’adressage partagé. Ces inscriptions ne constatent ni le profil chargé, ni l’identité réelle du trafic, ni le résultat d’une mesure.

Le profil interdit aussi plusieurs variantes : mesure Peer-to-Peer, Grandmaster Clusters, émetteur alternatif, échelles de temps alternatives, découverte unicast et négociation des cadences unicast. Une mise en œuvre ne doit pas assouplir ces règles pour revendiquer l’interopérabilité. Mais un choix interdit dans un fichier et absent du code actif sont encore deux preuves différentes.

Announce choisit le rôle, pas la vérité

Les messages Announce transportent les propriétés comparées par le Best TimeTransmitter Clock Algorithm. Les décisions de port construisent l’arbre du domaine et le meilleur candidat devient Grandmaster. L’algorithme donne une réponse déterministe à des entrées observées.

Il ne visite pas l’antenne GNSS, ne mesure pas l’oscillateur et ne demande pas à une autorité indépendante si la source dit vrai. RFC 7384 sépare justement l’usurpation, le rejeu, la manipulation des paquets, l’attaque du scrutin, le retard malveillant et l’attaque de la source externe. Un Grandmaster légitime peut diffuser une heure fausse après brouillage ou imitation de son signal de référence.

RFC 9760 exige qu’un port émetteur possède une valeur actuelle du nombre de secondes intercalaires UTC. Un récepteur peut aussi tenir une table des émetteurs acceptables. La première règle ferme une lacune de contexte ; la seconde exprime une autorisation locale. Ni l’une ni l’autre ne mesure l’exactitude présente.

Le mot « meilleur » demeure relatif aux candidats et aux propriétés disponibles. Il ne signifie pas « vrai ».

Multicast pour le commun, unicast pour le particulier

Sync et Announce sont multicast. Un émetteur à deux étapes multidiffuse également Follow-up. Le récepteur peut envoyer Delay Request en multicast ou en unicast ; Delay Response reprend le même mode. Cette asymétrie fonctionnelle évite de distribuer à des centaines de nœuds des réponses qui ne concernent qu’un seul.

La sobriété réseau ne change pas la portée d’un message. Mille récepteurs d’un Sync ne fournissent pas mille validations indépendantes. Une réponse unicast n’est pas plus vraie parce qu’elle est ciblée. Il faut conserver le domaine, Clock Identity, numéro de séquence, mode, correction et trajet.

La cadence par défaut de Sync, Announce et Delay Request est d’un message par seconde. La régularité facilite le suivi. Elle peut aussi masquer un défaut stable : un mauvais temps livré ponctuellement reste mauvais.

L’identité d’horloge traverse les changements d’adresse

Une Transparent Clock mesure son temps de transit et corrige le message. Elle peut réémettre un nouveau paquet avec sa propre adresse IP ou sa propre adresse de couche 2. RFC 9760 demande donc de suivre la Clock Identity sur 64 bits, plutôt que de confondre l’enveloppe réseau avec l’horloge d’origine.

Cette règle devient essentielle quand la réponse Delay doit retrouver le bon récepteur. Une table peut devoir associer adresse et Clock Identity. Un NAT peut encore masquer les adresses et limiter la topologie, sans que le RFC définisse sa mise en œuvre.

Le reçu doit montrer la chaîne : adresse reçue, interface, Clock Identity, horloge intermédiaire, domaine et parent choisi. Une identité de protocole établit une continuité d’attribution. Elle n’authentifie pas par magie la source externe et ne mesure pas son erreur.

Un trajet asymétrique déforme des paquets corrects

La mesure End-to-End suppose que le délai aller égale le délai retour. Dans un réseau IP, Sync et Delay Request peuvent emprunter des chemins physiques différents. RFC 9760 recommande de les aligner lorsque c’est possible, mais laisse l’ingénierie de trafic hors de son périmètre.

Le piège est discret. Les messages peuvent être syntaxiquement valides, provenir de l’identité attendue et arriver dans l’ordre, tandis qu’une file ou un changement ECMP ajoute du délai dans une seule direction. Le récepteur transforme alors l’asymétrie en offset d’horloge.

RFC 8915, consacré à NTS pour NTP, expose une limite physique transposable avec prudence : un attaquant peut retarder des paquets authentiques sans en modifier le contenu, et la cryptographie ne sait pas supprimer ce biais. Il ne s’agit pas d’appliquer NTS à ce profil PTP, mais de ne pas confondre intégrité et symétrie.

Conserver seulement « message valide » détruit la preuve décisive. Il faut aussi conserver le délai, la correction, la variance, le chemin et son changement.

Plusieurs domaines offrent une comparaison

Plusieurs Grandmasters simultanés sont permis s’ils résident dans des domaines différents. Un équipement feuille peut faire fonctionner plusieurs piles PTP et comparer ou combiner leurs informations dans sa boucle de contrôle. Le profil recommande, lorsque c’est faisable, des chemins réseau distincts.

Cette architecture réduit la portée d’une source fautive ou d’un chemin attaqué. Elle ne crée pas automatiquement l’indépendance. Deux Clock Identities peuvent partager une antenne, une alimentation, une version logicielle, un commutateur ou une erreur de configuration.

Une Boundary Clock suit une autre règle : elle peut maintenir plusieurs domaines, mais ne doit pas fusionner leurs informations temporelles. L’ensemble observé par une feuille et la redistribution d’une horloge de frontière ne sont donc pas le même mécanisme.

La recommandation NTP de RFC 8633 renforce le principe d’exploitation : utiliser assez de sources, diversifier leurs références et surveiller leur synchronisation. Les algorithmes NTP et PTP ne sont pas identiques ; la leçon commune est que l’indépendance doit être démontrée.

La sécurité reste une couche séparée

Le récepteur doit continuer à fonctionner en présence d’un émetteur rogue et ne devrait pas se synchroniser sur un émetteur qui n’est pas Best dans son domaine. Une table d’acceptation peut exclure une identité inconnue. Ces contrôles empêchent certaines substitutions ; ils ne garantissent pas l’exactitude d’une identité autorisée.

RFC 9760 place les mécanismes de sécurité supplémentaires hors champ et déconseille les messages de gestion PTP dépourvus de protection. Il cite une gestion sécurisée externe telle que NETCONF. Protéger la transaction de configuration est nécessaire, mais le canal de gestion ne voit pas forcément le signal de référence, le trajet ou la boucle servo.

RFC 5905 offre un cadre NTPv4 mûr pour la sélection et la discipline d’horloge. Il sert ici de comparaison, pas de preuve indirecte pour PTP. Un réseau doit documenter explicitement tout lien entre ses deux surfaces temporelles.

L’application doit signer son propre reçu logique

Une horloge système correcte peut encore produire un mauvais enregistrement métier. Le programme peut horodater avant une file, après un lot, sur un cœur dont la lecture diffère, ou utiliser une valeur mise en cache. La base peut ensuite réordonner des écritures.

RFC 8877 discipline la définition des formats d’horodatage. L’époque, la résolution, l’intervalle et le débordement comptent. Mais une représentation parfaite ne prouve ni la source, ni l’instant de capture, ni l’usage ultérieur.

La théorie des couches de réalité de Heng Lu évite cette fusion : norme, registre, configuration, paquet, sélection, correction, horloge locale et événement sont des objets différents. La primauté du code en fonctionnement exige d’observer les processus et équipements actifs. Une spécification initiale minimale avec décision future localisée laisse au profil le rôle de coordonner, et à l’opérateur celui de décider l’objectif, les sources et le risque.

La sélection du Grandmaster est un bon reçu. Elle devient dangereuse seulement lorsqu’on la fait parler à la place de tous les autres.