1 – Introduction au protocole NTP

Pourquoi NTP est indispensable, actuellement tout équipement informatique dispose d’une horloge matérielle ou logicielle à laquelle il est fait référence pour horodater des fichiers, des transactions, des courriers électroniques, etc… Cette horloge, bien que conçue autour d’un oscillateur à quartz, dérive comme toute montre ordinaire.

Ceci est d’autant plus gênant lorsque les machines sont en réseau et partagent des ressources communes comme des systèmes de fichiers. Par exemple, certains outils de développement, comme la commande Unix « make », basent leur travail sur la comparaison des dates de modification de fichiers. De même, la cohérence et la comparaison de messages de « logs » de plusieurs systèmes devient très difficile s’ils ne sont pas à la même heure.

La nécessité de synchroniser des équipements en réseau paraît alors évidente. C’est la finalité du protocole Network Time Protocol (NTP), qui synchronise les machines et les routeurs des réseaux. Au cours des 20 dernières années de recherches sur ce sujet sensible, trois protocoles ont vu le jour, avec pour aboutissement la version actuelle de NTP utilisée par les systèmes.

Nous allons passer rapidement sur ces précurseurs du protocole NTP. Nous définirons ensuite les buts du protocole. Puis nous verrons les différentes architectures qui implémentent ce protocole. Nous détaillerons enfin les mécanismes de synchronisation mis en place dans NTP.

2 – Nécessité d’avoir un temps précis et fiable

• Bases de données distribuées : transactions, journalisation, logs
• Estampilles de documents sécurisés : certification et cryptographie
• Aviation : contrôle de trafic et enregistrement de positions
• Programmation télévision et radio
• Multimédia : synchronisation pour les téléconférences en temps réel
• Gestion des réseaux
• …

3 – Bref historique de NTP

Le temps légal défini par la seconde légale a été basé :

• Sur le temps universel (TU) jusqu’en 1956.
• Sur le temps des éphémérides (TE) de 1956 à 1967.
• Sur le temps atomique à jet de césium à partir de 1967.

Jusqu’en 1956 la seconde légale était définie comme la 86400ème partie du jour solaire moyen. A partir de 1956 la seconde des éphémérides a été définie par le comité international des poids et mesure comme étant la fraction 1/31556925.9747 de l’année tropique pour 1900 janvier 0 à 12 heures de temps des éphémérides. Depuis 1967 la seconde légale est définie comme la durée de 9 192 631 770 périodes de la radiation correspondant à la transition entre les deux niveaux hyperfins de l’état fondamental de l’atome de césium 133.

Afin de de synchroniser les systèmes à travers les réseaux, plusieurs protocoles ont vu le jour avant l’arrivée de la version de NTP actuellement utilisée.

3.1 – TP

En 1983, un premier protocole, le Time Protocole est réalisé RFC 868. Il est rapidement popularisé et repris sur les systèmes Unix au travers du démons timed et de la commande rdate. Cependant ses limites sont vite atteintes car, d’une part, il n’offre qu’une précision de l’ordre de la seconde, et d’autre part, il n’implémente aucun mécanisme pour compenser la dérive des horloges.

3.2 – NTP

Dans le même temps, les toutes premières versions de NTP sont élaborées sous le nom d’Internet Clock Service. On voit cette implémentation utilisée dans le protocole de routage HELLO. Cependant, la première version de NTP à proprement parlé apparaît en 1988 et ses spécifications sont relatées dans le RFC 1059. Dans cette version sont déjà présents les modes de communication client/serveur et symétrique pour la distribution du temps. Un an plus tard (1989), apparaît la deuxième version de NTP RFC 1119 qui introduit un aspect sécuritaire car il permet de crypter les paquets de communication grâce à un algorithme de chiffrage à clé secrète (DES-CBS). De son coté, la Digital Equipment Corporation (DEC) met au point le Digital Time Synchronisation Service (DTSS). Se basant alors sur les bonnes idées de ce dernier et sur NTPv2, une troisième version de NTP voit le jour en 1992 RFC 1305. C’est la plus utilisée jusqu’à ce jour. Depuis 1994, une nouvelle spécification de NTP est à l’étude pour prendre en compte les changements de l’Internet comme le support d’IPv6 ou bien encore le chiffrement des paquets avec un système à clé publique. Bien que cette dernière spécification n’ai toujours pas été rendue publique, une implémentation de cette version est déjà disponible. Pour le moment elle est très peu répandue bien qu’elle assure comme ses prédécesseurs une compatibilité ascendante. On la trouve surtout sur le réseau « DCnet Research Network » où son comportement est mis à l’épreuve. Bien évidemment, chaque version de NTP a apporté son lot d’améliorations quant à l’efficacité des algorithmes afin d’obtenir une meilleure fiabilité et disponibilité du système.

3.3 – SNTP

En dernier lieu, une version simplifiée du protocole NTP est développée en parallèle. Il s’agit du Simple Network Time Protocol (SNTP) spécifié dans la RFC 4330 et qui en est déjà à sa quatrième version. SNTP est destiné à des réseaux où la précision de l’ordre de la seconde est suffisante (exemple : workstations). A la base, SNTP amène un allègement des algorithmes de traitement des paquets NTP, ce qui permet d’envisager SNTP sur des systèmes embarqués où la capacité de calculs, notamment à virgule flottante, est généralement très limité. L’objectif de ce nouveau protocole est de faciliter l’implémentation d’un client NTP n’ayant pas besoin de beaucoup de précision tout en étant capable de dialoguer avec des serveurs NTP standards. Cependant, l’utilisation de SNTP doit rester limitée pour ne pas perturber et fausser le réseau NTP. En fait, il est vivement recommandé de n’utiliser SNTP qu’en bout de chaîne dans les échange NTP, c’est à dire directement sur une horloge de référence (horloge atomique) ou bien sur les systèmes clients exclusivement. On doit ainsi éviter de faire d’un système réglé par SNTP, une référence pour un autre système.

4 – Objectifs du protocole NTP

Ce à quoi sert NTP

• donner la meilleure précision possible compte tenu des conditions matérielles
• résister à une multitude de pannes (y compris les bugs d’implémentation)
• optimiser l’utilisation de la diversité et de la redondance présentes sur Internet
• organiser de manière automatique la topologie d’un sous-réseau afin d’avoir une précision et une fiabilité optimales
• réaliser l’authentification cryptographique basée sur des infrastructures de clefs symétriques et de clefs publiques

Ce à quoi ne sert pas NTP

• temps local : le noyau le fait
• contrôle d’accès : firewall
• non-répudiation : utiliser un protocole spécifique si besoin

5 – Architecture système et réseau, NTPv3

NTP est un protocole basé sur les protocoles UDP et IP. C’est donc un protocole Internet basé sur l’adressage IP, en mode non connecté avec User Datagram Protocol sur le port 123.

La synchronisation de l’heure est diffusée depuis des serveurs primaires dans une arborescence en réseau. Près de 200 000 clients et serveurs utilisent NTP sur internet.

NTP a été porté sur la plupart des plateformes dont Windows, Linux, Unix,… La version 3 de NTP, dont nous parlons ici, est utilisée depuis 1992.

5.1 – Références de temps

Elles sont toutes dérivées plus ou moins directement d’horloges atomiques. On peut citer :

• les horloges pilotées par des signaux radio émis par des émetteurs spécialisés comme DCF77 en Allemagne
• les horloges pilotées par des émetteurs de radio-diffusion publiques transmettant, en plus de leur programme, des informations horaires comme l’émetteur TDF d’Allouis diffusant France-Inter
• les systèmes de positionnement, comme le GPS, constituent d’excellentes sources de référence

5.2 – Précision

Le protocole NTP fournit différents niveaux de précision :

• de l’ordre d’une dizaine de millisecondes sur les réseaux WAN
• inférieure à la milliseconde sur les réseaux LAN
• inférieure à la microseconde lorsqu’on utilise une référence de temps de type GPS (sur les LAN)

L’architecture de NTPv4 permet d’atteindre une précision 10 fois plus grande, de l’ordre de la microseconde sur les nouveaux réseaux plus performants.

5.3 – Structure d’un réseau NTP

L’une des caractéristiques principales d’un réseau NTP est sa structure pyramidale. Un certain nombre de sources de référence, dites primaires, synchronisées par la radio ou un réseau filaire sur les standards nationaux, sont connectées à des ressources largement accessibles, comme des passerelles de backbone et des serveurs de temps primaires.

Le but de NTP est de transporter ces informations de temps de ces serveurs vers d’autres serveurs de temps reliés à Internet. Il vérifie aussi les horloges pour minimiser les erreurs dues aux problèmes de propagation sur le réseau.

Quelques machines ou passerelles des réseaux locaux, agissant en tant que serveurs de temps secondaires, font tourner NTP, en connexion avec un ou plusieurs serveurs primaires.

Dans l’optique de réduire le trafic engendré par le protocole, les serveurs de temps secondaires distribuent le temps via NTP aux machines restantes sur le réseau local.

Dans un souci de fiabilité, certaines machines peuvent être équipées avec des horloges moins précises, mais aussi moins chères, afin d’être utilisées pour des sauvegardes, en cas de défaillance des serveurs de temps (primaires ou secondaires) ou des chemins réseaux.

Pour résumer : des références de temps synchronisent des serveurs NTP qui leur sont directement raccordés. Ceux-ci constituent la « strate 1 » et ils vont synchroniser chacun plusieurs dizaines d’autres serveurs qui vont constituer la « strate 2 » et ainsi de suite jusqu’aux clients terminaux. Ce principe permet de bien répartir la charge des serveurs tout en conservant une distance aux sources de référence relativement faible. Relations entre serveurs NTP :

5.4 – Fonctionnement d’un serveur NTP : cinq modes différents

Sauf dans le mode broadcast, une association est créée quand deux machines échangent des messages. Une association peut fonctionner dans un des cinq modes suivants :

• Mode symétrique actif
  Un serveur fonctionnant dans ce mode envoie périodiquement des messages, sans se soucier de l’état de ses voisins (joignables, serveurs primaires ou secondaires, clients). Il indique ainsi sa « volonté » de synchroniser d’autres serveurs et d’être synchroniser par eux.
• Mode symétrique passif
  Ce type d’association est généralement créée lors de l’arrivée sur le serveur d’un message d’un autre serveur (en mode symétrique actif). Le serveur annonce son intention de synchroniser et d’être synchronisé. Seulement il ne le fait qu’après avoir été sollicité par un autre serveur. 
• Mode client
  La machine envoie des messages régulièrement, sans se préoccuper de l’état de ses voisins. La station (typiquement, elle appartient à un réseau LAN) indique ainsi sa « volonté » d’être synchronisée.
• Mode serveur
  L’association de ce mode est créée lors de la réception d’une requête (un message) d’une station en mode client.
• Mode broadcast
  Destiné aux réseaux locaux, il se limite à une diffusion d’informations horaires pour des clients pouvant être soit passifs, soit découvrant ainsi les serveurs avec lesquels ils vont se synchroniser.

La fiabilité du système est assurée par la redondance des serveurs et l’existence de plusieurs chemins dans un réseau, pour aller d’un point à un autre.

Les serveurs primaires (strate 1) se synchronisent sur des horloges de référence par radio, ou autre. Il en existe environ 230 dans le monde. Les clients et serveurs communiquent en mode client/serveur, symétrique ou multicast, avec ou sans cryptage.

Les serveurs secondaires (environ 4500)(ex : serveurs de campus universitaires) se synchronisent sur plusieurs serveurs primaires en mode client/serveur, et avec d’autres serveurs secondaires en mode symétrique.

D’une manière générale, les serveurs d’une strate se synchronisent sur plusieurs serveurs de la strate supérieure en mode client/serveur, et avec d’autres serveurs de la même strate en mode symétrique.

Les simples clients se synchronisent en mode client/serveur s’ils sont isolés, ou en mode multicast s’ils font partie d’un réseau (ex : machines universitaires se synchronisant sur plusieurs serveurs de strate 3, comme les serveurs des départements universitaires).

Une station en mode client envoie de temps en temps un message NTP à une station en mode serveur, généralement peu de temps après avoir redémarré. Le serveur n’a pas besoin d’enregistrer des informations sur l’état du client, puisque c’est le client qui décide quand envoyer une requête, en fonction de son état en local. Dans ce mode, le fonctionnement pourrait être simplifié en un mécanisme de RPC sans perdre de précision ni de robustesse, surtout dans le cadre d’un réseau LAN à haut débit.

Dans les modes symétriques, la distinction client/serveur disparaît. Le mode passif est destiné aux serveurs de temps qui se trouvent près de la racine du système de synchronisation (les serveurs de la strate 1 ou 2).

Le mode symétrique actif est destiné aux serveurs de temps qui se trouvent près des feuilles du réseau de synchronisation, sur les strates les plus élevées. La fiabilité du service de temps peut être généralement assurée avec deux stations sur le niveau au-dessus (strate plus petite) et une station sur le même niveau. Normalement, une station fonctionne en mode actif (symétrique, client ou broacast) avec une configuration donnée au démarrage, alors que les autres sont en mode passif (symétrique ou serveur) sans configuration préalable.

Cependant une erreur intervient lorsque deux stations qui communiquent sont dans le même mode, sauf pour le mode symétrique actif. Dans ce cas, chaque station ignore les messages de l’autre et l’association créée par cet échange n’est rompue qu’en cas de coupure de réseau entre les deux stations.

Le mode broadcast est surtout destiné aux réseaux locaux avec beaucoup de stations et où la précision requise n’est pas très importante. Le déroulement classique est le suivant : un ou plusieurs serveurs de temps du réseau envoie régulièrement des broacasts aux stations, pour déterminer l’heure, avec une latence de l’ordre de quelques millisecondes.

Comme dans le mode client/serveur, le protocole utilisé peut être simplifié. Ainsi, un système basé sur l’algorithme de sélection d’horloge peut être utilisé dans le cas où on dispose de multiples serveurs de temps, afin d’optimiser la fiabilité.

NTP intègre un système d’exploration du réseau pour découvrir automatiquement de nouveaux serveurs NTP, par différentes méthodes :

• Multicast :
  • Les serveurs inondent périodiquement le réseau local par un message multicast.
  • Les clients utilisent le mode client/serveur lors du premier contact pour mesurer le temps de propagation puis restent en écoute.
• Manycast : (mode plus précis)
  • Les clients inondent le réseau local par un message multicast.
  • Les serveurs répondent en multicast.
  • Les clients communiquent ensuite avec les serveurs comme s’ils avaient été configurés en unicast.

Des contrôles de time-out et de TTL garantissent le bon déroulement de la configuration.

6 – Mécanismes de synchronisation

6.1 – Gestion des messages

Comme beaucoup de systèmes distribués sur un réseau, les hôtes NTP (clients ou serveurs) utilisent des messages pour communiquer.

Voici les champs contenus dans un paquet NTP :

La synchronisation d’un client nécessite plusieurs échanges de messages afin d’améliorer à chaque fois l’estimation du temps. Dans la pratique, il faut à peu près cinq minutes pour que l’horloge du système devienne fiable. Une fois cette synchronisation effectuée, le client pourra devenir à son tour un système de référence. De plus, plus le client échange des messages avec ses serveurs de référence, plus il est capable de discerner, parmi eux, ceux qui amènent une certaine part d’erreur dans la détermination du temps. Le cas échéant, il peut décider de ne plus faire appel à ces systèmes appelés « falsetickers ».

L’échange de messages conduisant à la synchronisation suit la procédure suivante :

• Le système désirant être synchronisé envoie d’abord un paquet dans lequel il initialise au moment t0 le champ TT « Transmit Timestamp » avec sa propre heure système.
• Le serveur stocke ensuite l’heure de réception du paquet dans le champ « Receive Timestamp » à t+1 du même paquet.
• Ensuite il effectue un contrôle de validité du paquet pour s’assurer qu’il doit bien effectuer le traitement (vérification du stratum du client, authentification, …).
• Avant de retourner le paquet à l’expéditeur, le champ TT « Transmit Timestamp » est copié dans le champ OT « Originate timestamp » et le champ TT « Transmit Timestamp » est renseigné à t+2.
• Le client enregistre l’heure de réception de la réponse à t+3 afin de pouvoir estimer le temps de trajet du paquet. En supposant que les délais de transmission des messages sont symétriques, le temps de trajet correspond à la moitié du temps d’attente total moins le temps de traitement sur la machine distante. (NTP implémente un algorithme de Huff&Puff pour compenser les délais de transmission asymétriques)
• Le client lui aussi vérifie la validité de la réponse pour savoir si elle doit être prise en compte.
• Le système client peut alors estimer le décalage de son horloge avec le système de référence.

6.2 – Traitements internes

Une fois la réponse du serveur obtenue, un ensemble d’algorithmes prend le relais afin de déterminer le décalage de l’horloge locale avec le système distant.

On peut représenter la suite des traitements comme ci-dessous :

Les premières étapes à franchir servent à assurer la sécurité du protocole :

• Les filtres éliminent les réponses non conformes aux attentes du protocole.
• L’algorithme de sélection détecte les données erronées afin de lutter contre les comportements byzantins des serveurs.

Ensuite l’algorithme de combinaison compare les réponses des différents serveurs entres elles et avec les réponses précédentes pour déterminer le mieux possible le décalage de l’horloge locale.

Enfin l’algorithme de contrôle de l’horloge utilisera les méthodes qui sont à sa disposition pour recaler l’horloge.

6.3 – Réglage de l’horloge

Une fois que le décalage a été déterminé, il faut agir sur l’horloge pour se synchroniser. Plusieurs possibilités d’action s’offrent alors au processus qui interagit avec l’horloge:

• Il peut changer brutalement l’heure système. Cette technique est à éviter car elle perturbe les applications utilisant l’horloge du système et peut même engendrer une certaine instabilité.
• Le processus peut aussi faire varier la fréquence d’horloge: la ralentir si elle est en avance ou inversement, l’accélérer pour lui faire rattraper son retard. Cette technique permet un contrôle plus fin de l’heure locale et a l’avantage de préserver l’intégrité du système.

Le choix de l’action à entreprendre dépend en fait de l’importance du décalage constaté :

• Pour un décalage minuscule, la fréquence d’horloge est modifiée.
• Si ensuite on constate des décalages plus grands (de l’ordre de la seconde), le processus ne tient pas compte de la réponse des serveurs et préfèrera faire des calculs statistiques sur les anciens décalages afin de déterminer la marche à suivre.
• Au bout d’un moment, si des décalages encore importants sont constatés, ils seront pris en compte : pour les plus petits d’entre eux, la fréquence d’horloge sera modifiée tandis que pour les plus grands (sans toutefois être énormes), l’horloge est réinitialisée brutalement.
• Dans le cas d’un décalage vraiment très important, la réponse des serveurs est rejetée et le processus NTP s’arrête car il pense que ses systèmes de référence sont entrés dans un état non fiable.

7 – Exemple de trame NTP

Fichier de capture NTP

8 – Les serveurs NTP d’Internet

Le principe est de se synchroniser vis à vis d’un serveur de temps de référence. Pour résoudre la problématique de charge sur ce serveur de temps, un groupement de serveur à lieu et la redistribution se fait à l’aide du Round Robin DNS. Vous pouvez requêter plusieurs noms d’hôtes différent :

• pool.ntp.org
• 0.pool.ntp.org
• 1.pool.ntp.org
• 2.pool.ntp.org
• 3.pool.ntp.org

Pour obtenir une meilleur précision, vous pouvez aussi spécifier le pays où vous désirez prendre le temps de référence, comme par exemple la France qui vous garantira un temps de réponse plus rapide et plus pertinent. Pour cela, vous rajoutez fr comme cela :

• fr.pool.ntp.org
• 0.fr.pool.ntp.org
• 1.fr.pool.ntp.org
• 2.fr.pool.ntp.org
• 3.fr.pool.ntp.org

9 – Conclusion

Le protocole NTP est le plus utilisé à travers le monde pour la synchronisation des machines. Son succès est du à sa facilité de mise en place, à sa haute fiabilité ainsi qu’à l’expérience des chercheurs qui travaillent sur le projet depuis plus de vingt ans.

La quatrième version du protocole permettra encore plus de fiabilité et de précision dans la détermination du temps. Mais la version actuellement utilisée en fait déjà un protocole incontournable que tout bon informaticien devrait connaître.

10 – Les vidéos

• 10.1 - NTP and NTP Authentication

  Vidéo en anglais présentant le protocole NTP et son authentification. This course is designed to cover the security topics on the R&S blueprints for the written and the lab. The way the blueprint describes the content is the way we will approach the topics, some from a fundamental perspective and others more in depth. We’ll start off with control plane security, policing and protection so that you can help minimize the impact on the device. Taking off from there we will jump into device security, from a management perspective. Then we’ll wrap up with Layer 2 and Layer 3 security in the data plane and how that works.

  

• 10.2 - Network Time Protocol par Mr Cisco

  Vidéo en anglais de Mr Cisco présentant le protocole NTP (Network Time Protocol).

  

11 – Suivi du document

Création et suivi de la documentation par _SebF

Modification de la documentation par Bastien

• Correction du chapitre « 6.1 – Gestion des messages »

12 – Discussion autour du protocole NTP

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos du protocole NTP. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :