TFTP (Trivial File Transfer Protocol), un protocole simple de transfert de fichiers

Pour que deux ordinateurs puissent échanger des données sur le réseau, il est indispensable que ces deux machines parlent la même langue et se comprennent. Un des protocoles les plus simples qui ait été développé à cette fin est le Trivial File Transfer Protocol (TFTP), qui a joué un rôle important, en particulier au début de l’ère du Web.

Le Trivial File Transfer Protocol, abrégé en TFTP, est un protocole très simple de type client/serveur, qui permet de gérer le transfert de fichiers au sein de réseaux composés d’ordinateurs. Une première spécification de ce protocole a été publiée au mois de juin 1981 dans la RFC 783. La version actuelle date de 1992 de la RFC 1350 sous une mouture améliorée. Le protocole TFTP repose sur un autre protocole très simple, le protocole de transport UDP (User Datagram Protocol), qui permet d’effectuer un transfert de données sans connexion fixe entre les partenaires de communication. L’implémentation de TFTP sur la base d’autres protocoles est à la fois possible et envisageable.

Ce protocole, qui repose sur l’envoi de paquets de données, s’inscrit dans la famille des protocoles TCP/IP, et a été conçu de telle sorte qu’il reste le moins encombrant et le plus léger possible à l’implémentation. C’est la raison pour laquelle il est employé dans des processus pour transférer des fichiers ou des emails depuis un serveur, et même pour accéder au serveur en mode écriture. Afficher le contenu des répertoires ou définir des droits avec chmod, comme le permet le protocole FTP (File Transfer Protocol), n’est pas possible avec TFTP. Pour les requêtes, le protocole TFTP utilise le port 69 (tftp port 69). Par ailleurs, la communication se fait au moyen de numéros de ports attribués individuellement (entre 1024 et 65535), que le serveur TFTP soumet au client de destination sous la forme de TIDs (Transfer Identifiers).

Le transfert de données par TFTP est toujours basé sur une requête-client, qui demande un accès en écriture ou en lecture. Cette requête fait également office de demande de connexion, connexion qui est automatiquement établie si le serveur accepte l’accès. Ensuite, le client ou le serveur transmet le fichier sous forme de blocs dont la taille est prédéfinie. Dans les premières versions du protocole, on avait encore la valeur fixe de 512 octets – mais depuis le RFC 2348 le serveur et le client peuvent ajuster la taille du bloc avec plus de souplesse.

Le transfert se fait bloc par bloc sachant cependant que tout bloc réceptionné doit être validé par un accusé de réception (« Acknowledgement ») avant que le paquet suivant ne puisse être envoyé. Un paquet de données dont la taille est inférieure au nombre d’octets défini sera identifié comme paquet final du transfert. Si un paquet se perd pendant le transfert, cela déclenche une fin d’attente chez le destinataire, avec une nouvelle tentative de renvoi du dernier paquet. De cette manière, l’émetteur du paquet perdu est averti du fait qu’il doit renvoyer ce paquet. Les erreurs qui surviennent pendant un transfert TFTP engendrent des paquets erreurs qui provoquent généralement la rupture de la connexion. Parmi les sources d’erreurs, on distingue trois types d’événements :

• La demande ne peut pas être satisfaite, par exemple parce que le fichier est introuvable, parce que l’utilisateur n’existe pas ou s’il y a eu une violation d’accès (fichier en mode protection, etc.).
• Le client ou le serveur réceptionne un paquet qui ne peut s’expliquer par un délai ou une duplication sur le réseau, ce qui est le cas notamment pour un paquet mal formé.
• L’accès à une ressource nécessaire est alors perdu, par exemple dans le cas d’un disque dur plein.

Le protocole TFTP reconnaît en tout cinq types de paquets qui se caractérisent chacun par leur propre champ « Opcode » (Code opération) de 16 bits, avec une valeur correspondante :

La valeur du code opération n’est cependant pas le seul élément qui permet de distinguer les différents types de paquets de la liste.

Les messages RRQ, ainsi que les messages WRQ commencent par le champ code opération de 16 bits, caractéristique de ce protocole. Comme le montre le premier tableau, les paquets RRQ utilisent la valeur « 1 » tandis que les paquets WRQ sont identifiables par leur valeur « 2 ». S’ensuit une séquence de bits au format NetASCII de taille variable. Celle-ci renferme le nom du fichier qui doit être lu ou envoyé. La fin est marquée par un champ de 8 bits, composés uniquement de zéros.

Une autre chaîne de caractères, à longueur variable, renferme pour finir l’information concernant le mode de transfert des données. Il existe trois variantes « netascii », « octet » (pour le transfert d’un fichier au format 8 bits) et « mail » (pour le transfert vers une adresse email). Ici aussi, on définit la clôture du transfert au moyen d’un groupe 8 bits, composé uniquement de zéros.

Les paquets DATA commencent eux-aussi par le code opération, auquel est attribuée dans ce cas la valeur « 3 ». La séquence 16 bits qui s’ensuit marque le numéro du bloc de données, avec la valeur « 1 » comme valeur initiale. Cette valeur est automatiquement incrémentée de 1 pour chaque bloc de données appartenant au fichier. Les blocs se retrouvent quant à eux dans le Champ des données, dont la taille varie entre 0 et 512 octets (4096 bits), dans la mesure où le serveur et le client TFTP n’ont pas convenu d’une autre taille maximale pour les blocs. Si une taille maximale a été précisée, un signal indique que le paquet DATA ne renferme pas le dernier bloc de données du fichier. Ce dernier bloc qui indique la fin d’un transfert de données doit toujours être au moins inférieur d’un octet. Dans le cas où, par hasard, la partie restante du fichier à transférer a une taille identique à celle du bloc, l’expéditeur devra ajouter un dernier paquet avec un bloc de données vide.

Tous les paquets WRQ, ainsi que tous les paquets de données qui n’indiquent pas la fin du transfert, sont confirmés au moyend’un accusé de réception ACK par le Trivial File Transfer Protocol (excepté en cas de Timeout).

Les accusés de réception ACK de la communication du protocole TFTP sont composés d’un code d’opération long de 16 bits, auquel a été assigné la valeur « 4 » et du numéro du bloc de données, lui aussi long de 16 bits permettant de valider l’accusé de réception ACK. S’il s’agit d’une réponse à une demande WRQ, le paquet ACK porte le numéro de bloc de données « 0 ».

Derrière le code opération (valeur « 5 ») que l’on a aussi dans les messages de type ERROR, se trouve un champ long de 16 bits, et qui contient le code d’erreur. La valeur « 1 » indique par exemple que le fichier est introuvable, alors que la valeur « 6 » précise au système que ce fichier existe déjà. Le message d’erreur qui est annexé permet à l’utilisateur de cerner le problème. C’est aussi pour cette raison que cette chaîne de caractères de taille variable est généralement au format NetASCII. La fin est marquée par un champ 8 bits, composé de zéros.

Le protocole TFTP vous séduit avant tout par sa simplicité. Le protocole doit permettre l’écriture et la lecture de fichiers, un rôle qu’il assume parfaitement sans devoir établir une connexion entre le client et le serveur. Le protocole TFTP est de ce fait non seulement facile à implémenter, mais il favorise aussi un transfert rapide des données. Les identificateurs de transfert (TID) et les numéros univoques des blocs de données constituent la base permettant à chaque fichier d’être reçu dans son intégralité par le destinataire.

L’absence de cryptage, mais aussi l’absence d’authentification et de moyens de contrôle sur l’accès des fichiers expose d’éventuels fichiers sensibles par TFTP à un niveau de risque assez élevé. C’est la raison pour laquelle on utilise des options plus sécurisées, comme par exemple le protocole FTP qui reste cependant plus complexe. Par ailleurs, sur plusieurs serveurs TFPT, il n’est pas possible de supprimer, ni de renommer les fichiers.

Le protocole TFTP est étroitement lié à ce que l’on appelle le boot-réseau (désigné aussi par le mot « bootstrapping »). Cette technique, employée en particulier dans les années 1980, permettait à un ordinateur du réseau de démarrer le système d’un serveur central. Dans ce contexte, le développement et l’implémentation du TFTP était d’une importance capitale, notamment pour les terminaux et les postes de travail sans disque dur qui n’avaient pas leur propre système d’exploitation. Le protocole de transfert de données a donc été soutenu par le BOOTP, paru en 1985, grâce auquel les clients du serveur pouvaient automatiquement récupérer l’adresse du serveur TFTP.

De nos jours, le Trivial File Transfer Protocol est de moins en moins utilisé. À l’heure actuelle, les réseaux disposent de leurs propres systèmes d’exploitation qui renferment tous des protocoles d’amorçage uniques, avec des formes diverses et variées. On peut de cette manière procéder à l’installation de logiciels, à des opérations de maintenance, à des mises à jour de pilotes ou à la détection de virus en passant par des systèmes d’aide auxiliaire, et réduire ainsi les tâches d’administration. Il n’est pas rare non plus d’implémenter le TFTP dans des mémoires non volatiles (mémoires ROM), car l’absence de connexion de ce protocole est un gage de simplicité. On utilise par ailleurs des serveurs TFTP pour enregistrer des configurations et des images-systèmes de routeurs Cisco, ou encore dans les systèmes téléphoniques de la marque Siemens pour y enregistrer des jeux de données applicables aux différents coûts des communications.