Résumé

  • Le RFC 10030 encapsule les modes client-serveur et symétriques de NTP dans des messages d’événement PTP unicast, afin d’accéder aux horodatages de cartes réseau qui ne reconnaissent que PTP et aux corrections de certaines horloges transparentes.
  • La précision supplémentaire reste une preuve bornée : les corrections PTP ne sont pas authentifiables, les résultats négatifs sont refusés, le root delay demeure inchangé et le client NTP conserve la sélection des sources.

Le problème se trouve dans le filtre matériel

Une carte réseau ne peut pas toujours horodater tous les paquets reçus au débit de la liaison. Le constructeur ajoute alors un filtre qui ne retient que les paquets PTP, parfois même un transport ou un type de message précis. Un paquet NTP ordinaire sur UDP 123 traverse le mauvais chemin pour obtenir le même horodatage matériel.

Le RFC 10030 ajoute donc un contenant, pas un nouveau maître du temps. Le message NTP prend place dans un TLV spécifique à une organisation, lui-même porté par un message d’événement PTP unicast. Les modes client, serveur et symétriques sont prévus ; la diffusion NTP ne l’est pas. Sous l’OUI IANA 00-00-5E, le sous-type 0x1 désigne désormais Network Time Protocol Message.

Le serveur doit répondre par le même transport. Sa réponse ne peut pas être plus longue que la requête, pour ne pas créer d’amplification. Le client peut ajouter du remplissage s’il prévoit une réponse plus grande. Pour une réponse de synchronisation, l’égalité de longueur est recommandée afin de limiter une asymétrie de délai lorsque tout le chemin ne sait pas traiter PTP.

Le texte final, signé Miroslav Lichvar, a été annoncé par le RFC Editor le 14 août 2026 après le travail du groupe Network Time Protocols. Il porte le numéro 10030 et le statut Proposed Standard.

Le prix opérationnel du port 319

Lorsque PTP emprunte UDP, la source et la destination devraient utiliser le port d’événement 319. Le filtre de la carte peut alors reconnaître le paquet. Mais un client qui randomise son port source selon le RFC 9109 risque de perdre l’horodatage matériel, puisque le filtre ne voit que 319.

Le gain n’est donc pas gratuit. L’opérateur échange une possibilité de randomisation contre une mesure plus proche du fil. Network Time Security reste utilisable pour le message NTP intérieur, sans pour autant authentifier l’en-tête PTP extérieur. Une provenance vérifiée dans une couche ne s’étend pas automatiquement à la couche qui la transporte.

Le domaine PTP encadre aussi la conversation. Avec PTP 2.1, les participants doivent contrôler domainNumber et sdoId. Les valeurs recommandées par défaut sont 123 et 0, mais le domaine peut changer en cas de conflit. Tous les interlocuteurs concernés doivent partager le même couple.

Ce contrôle écarte un message hors périmètre. Il ne certifie ni l’exactitude de la source NTP, ni sa disponibilité, ni sa place dans l’algorithme de sélection du client.

Une correction limitée, jamais transformée en signature

Les horloges transparentes one-step E2E ajoutent leur délai de transfert au correction field de PTP. Pour corriger un aller-retour, le client doit connaître les deux directions. La correction de la réponse se trouve dans son en-tête PTP ; celle de la requête revient dans un nouveau champ d’extension NTP Network Correction, de type 0x010A.

Le serveur doit ignorer la valeur que le client aurait placée dans sa requête. Le client devrait y écrire zéro. À réception des deux valeurs, il peut corriger le peer delay et l’offset, en tenant compte de la durée de réception du paquet et d’une erreur de fréquence supposée des horloges transparentes.

Trois garde-fous sont décisifs. Si le délai corrigé, la correction de requête ou celle de réponse est négatif, le résultat ne doit pas servir à la synchronisation. Le root delay ne doit pas être corrigé : le root distance, estimation de l’erreur maximale, reste indépendant des améliorations annoncées par le chemin. Enfin, les corrections PTP ne peuvent pas être authentifiées.

Un attaquant sur le chemin peut modifier le champ. Le client n’accepte que des corrections inférieures au délai mesuré, ce qui borne l’effet. Le RFC rapproche le risque restant de celui d’un attaquant qui retarde un paquet NTP intact. Borner une action n’équivaut pas à prouver son origine.

NTP garde le droit de comparer

NTP sait interroger plusieurs serveurs, filtrer les mesures, exclure des sources défaillantes et maintenir sa propre estimation d’erreur. PTP améliore ici le lieu de l’horodatage et peut fournir une mesure du délai de transit. Il ne choisit pas la source que le client doit suivre.

Un hôte peut même se synchroniser directement par PTP dans un domaine et employer un autre domaine uniquement pour transporter NTP. Aucune autre horloge PTP n’est indispensable au transport. Si des horloges transparentes compatibles sont présentes, leurs corrections deviennent exploitables ; sinon, l’horodatage matériel de la carte peut déjà justifier l’usage.

Cette séparation protège le code en fonctionnement. Le standard ajoute la plus petite interface commune nécessaire, puis laisse chaque réseau décider si son matériel, sa topologie et son exposition au port fixe justifient l’adoption. La coordination définit le passage ; elle ne confisque pas le jugement.

Sources