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

Pour que deux or­di­na­teurs puissent échanger des données sur le réseau, il est in­dis­pen­sable que ces deux machines parlent la même langue et se com­pren­nent. Un des pro­to­coles 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 par­ti­cu­lier 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’or­di­na­teurs. Une première spé­ci­fi­ca­tion 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 par­te­naires de com­mu­ni­ca­tion. L’im­plé­men­ta­tion de TFTP sur la base d’autres pro­to­coles est à la fois possible et en­vi­sa­geable.

Ce protocole, qui repose sur l’envoi de paquets de données, s’inscrit dans la famille des pro­to­coles TCP/IP, et a été conçu de telle sorte qu’il reste le moins en­com­brant et le plus léger possible à l’im­plé­men­ta­tion. C’est la raison pour laquelle il est employé dans des processus pour trans­fé­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é­per­toires 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 com­mu­ni­ca­tion se fait au moyen de numéros de ports attribués in­di­vi­duel­le­ment (entre 1024 et 65535), que le serveur TFTP soumet au client de des­ti­na­tion 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 au­to­ma­ti­que­ment é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é­fi­nie. 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é­cep­tionné doit être validé par un accusé de réception (« Ack­now­led­ge­ment ») avant que le paquet suivant ne puisse être envoyé. Un paquet de données dont la taille est in­fé­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 des­ti­na­taire, 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 sur­vien­nent pendant un transfert TFTP en­gendrent des paquets erreurs qui pro­vo­quent gé­né­ra­le­ment la rupture de la connexion. Parmi les sources d’erreurs, on distingue trois types d’évé­ne­ments :

• La demande ne peut pas être sa­tis­faite, par exemple parce que le fichier est in­trou­vable, parce que l’uti­li­sa­teur n’existe pas ou s’il y a eu une violation d’accès (fichier en mode pro­tec­tion, etc.).
• Le client ou le serveur ré­cep­tionne un paquet qui ne peut s’expliquer par un délai ou une du­pli­ca­tion sur le réseau, ce qui est le cas notamment pour un paquet mal formé.
• L’accès à une ressource né­ces­saire 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 ca­rac­té­ri­sent chacun par leur propre champ « Opcode » (Code opération) de 16 bits, avec une valeur cor­res­pon­dante :

La valeur du code opération n’est cependant pas le seul élément qui permet de dis­tin­guer les dif­fé­rents types de paquets de la liste.

Les messages RRQ, ainsi que les messages WRQ com­men­cent par le champ code opération de 16 bits, ca­rac­té­ris­tique de ce protocole. Comme le montre le premier tableau, les paquets RRQ utilisent la valeur « 1 » tandis que les paquets WRQ sont iden­ti­fiables 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 uni­que­ment de zéros.

Une autre chaîne de ca­rac­tères, à longueur variable, renferme pour finir l’in­for­ma­tion con­cer­nant 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é uni­que­ment de zéros.

Les paquets DATA com­men­cent 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 au­to­ma­ti­que­ment in­cré­men­tée de 1 pour chaque bloc de données ap­par­te­nant au fichier. Les blocs se re­trou­vent 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 à trans­fé­rer a une taille identique à celle du bloc, l’ex­pé­di­teur 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 moyen d’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 com­mu­ni­ca­tion 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 per­met­tant 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 in­trou­vable, 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’uti­li­sa­teur de cerner le problème. C’est aussi pour cette raison que cette chaîne de ca­rac­tères de taille variable est gé­né­ra­le­ment 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 sim­pli­cité. Le protocole doit permettre l’écriture et la lecture de fichiers, un rôle qu’il assume par­fai­te­ment sans devoir établir une connexion entre le client et le serveur. Le protocole TFTP est de ce fait non seulement facile à im­plé­men­ter, mais il favorise aussi un transfert rapide des données. Les iden­ti­fi­ca­teurs de transfert (TID) et les numéros univoques des blocs de données cons­ti­tuent la base per­met­tant à chaque fichier d’être reçu dans son in­té­gra­lité par le des­ti­na­taire.

L’absence de cryptage, mais aussi l’absence d’au­then­ti­fi­ca­tion 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é­cu­ri­sé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 étroi­te­ment lié à ce que l’on appelle le boot-réseau (désigné aussi par le mot « boots­trap­ping »). Cette technique, employée en par­ti­cu­lier dans les années 1980, per­met­tait à un or­di­na­teur du réseau de démarrer le système d’un serveur central. Dans ce contexte, le dé­ve­lop­pe­ment et l’im­plé­men­ta­tion du TFTP était d’une im­por­tance capitale, notamment pour les terminaux et les postes de travail sans disque dur qui n’avaient pas leur propre système d’ex­ploi­ta­tion. 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 au­to­ma­ti­que­ment 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’ex­ploi­ta­tion qui ren­fer­ment tous des pro­to­coles d’amorçage uniques, avec des formes diverses et variées. On peut de cette manière procéder à l’ins­tal­la­tion de logiciels, à des opé­ra­tions de main­te­nance, à des mises à jour de pilotes ou à la détection de virus en passant par des systèmes d’aide auxi­liaire, et réduire ainsi les tâches d’ad­mi­nis­tra­tion. Il n’est pas rare non plus d’im­plé­men­ter le TFTP dans des mémoires non volatiles (mémoires ROM), car l’absence de connexion de ce protocole est un gage de sim­pli­cité. On utilise par ailleurs des serveurs TFTP pour en­re­gis­trer des con­fi­gu­ra­tions et des images-systèmes de routeurs Cisco, ou encore dans les systèmes té­lé­pho­niques de la marque Siemens pour y en­re­gis­trer des jeux de données ap­pli­cables aux dif­fé­rents coûts des com­mu­ni­ca­tions.