Résumé

  • RFC 3617 a défini une syntaxe commune pour les références TFTP, mais recommande fortement de ne plus employer ce protocole sauf dans des circonstances très limitées. L’enregistrement du schéma décrit un mécanisme ; il ne l’approuve pas.
  • L’URI valide, l’OACK, le dernier ACK, le contrôle d’empreinte, l’installation et le démarrage observé sont des reçus distincts. TFTP n’apporte à lui seul ni contrôle d’accès, ni authentification de l’éditeur, ni confidentialité, ni preuve intrinsèque d’intégrité.

Une image qui démarre peut encore être la mauvaise

Le premier signe visible d’un provisionnement réussi est souvent spectaculaire : l’équipement revient en ligne. Cette observation est utile, mais elle arrive à la fin d’une chaîne dont plusieurs maillons peuvent être restés invisibles. Le redémarrage ne dit pas quel serveur a répondu, quelle image a été reçue ni si l’image correspondait à la décision de changement.

RFC 3617, publié en octobre 2003 comme RFC informationnel, organise le début de cette chaîne. Il définit la forme d’un URI tftp: afin que logiciels et opérateurs parlent de la même chose. Il précise aussi qu’il ne s’agit pas d’une norme Internet et déconseille avec insistance la poursuite de TFTP. Le document voit même la syntaxe commune comme un moyen de faciliter la migration vers des mécanismes modernes.

Il faut conserver les deux propositions. Décrire précisément une dépendance ancienne n’est pas lui accorder une légitimité nouvelle. Au contraire, un inventaire ne peut remplacer ce qu’il ne sait pas nommer. Le schéma rend l’usage détectable, comparable et remplaçable.

Le registre IANA contient aujourd’hui l’entrée tftp et renvoie à RFC 3617. Cette ligne prouve qu’un identifiant de schéma a un document de référence. Elle ne prouve ni la présence d’un service, ni la sécurité d’un serveur, ni l’adoption par un constructeur, ni la conformité d’une implémentation réelle.

Le nom contient une route, pas une autorisation

La grammaire de RFC 3617 assemble le schéma, un hôte, un nom de fichier et, éventuellement, ;mode=netascii ou ;mode=octet. Sans option, octet s’applique. L’ancien mode mail n’est plus admis.

Cette chaîne ne contient pourtant aucune version d’artefact, empreinte, signature, identité d’éditeur, fenêtre de validité, ticket d’approbation ou emplacement de retour arrière. Le nom de fichier reste une interprétation locale du serveur. Deux serveurs peuvent servir des octets différents sous un chemin identique ; un même serveur peut remplacer le contenu sans changer l’URI.

Les opérations prévues sont la lecture et l’écriture. La présence d’un URI ne confère aucun droit sur l’une ou l’autre. Le protocole ne porte pas son propre contrôle d’accès. Une liste de configuration qui expose une destination d’écriture doit donc être traitée comme la description d’une capacité potentiellement destructive, non comme une permission.

Le document indique aussi qu’il n’est pas possible de connaître avant le transfert l’existence du fichier ou ses permissions par cette interface. La complétude et la fiabilité ne sont pas garanties. Un URI parfaitement conforme peut ainsi désigner une ressource absente, interdite, tronquée ou différente de celle qu’attendait l’opérateur.

Le mode netascii rend la question des octets encore plus explicite : une transformation de représentation peut intervenir entre les extrémités. Le mode octet évite cette conversion, mais ne fournit toujours pas de preuve cryptographique. Le mode choisi et l’identité immuable du contenu sont deux assertions distinctes.

Le dernier ACK ferme un échange, pas une enquête

RFC 1350 décrit les requêtes de lecture et d’écriture, les blocs DATA, les ACK et les erreurs. Dans le déroulement attendu, le dernier bloc et son accusé terminent la conversation. Ce reçu appartient au protocole de transport minimal ; il ne certifie pas la provenance.

Un observateur peut montrer que des blocs numérotés ont été acceptés. Il ne peut pas en déduire que l’hôte résolu était le serveur voulu, qu’un intermédiaire n’a rien substitué, que le fichier correspond à une publication approuvée ou que le stockage local a conservé les mêmes octets.

RFC 3617 énumère les limites : absence de protection contre l’interception active, absence de vérification intrinsèque d’intégrité, impossibilité de reprendre au milieu, fonctionnement initial en pas à pas, temporisations simples, absence de démarrage lent sophistiqué et absence de sémantique sûre de cache. Le passage entre domaines administratifs ajoute les incertitudes d’UDP, des pare-feu et des traducteurs d’adresses.

La taille inconnue avant le transfert, dans la sémantique de base, impose également une limite de ressources. Le client doit protéger mémoire et disque. Le suffixe .img n’atteste ni une taille raisonnable ni une destination sûre.

Un paramètre négocié n’est pas une identité négociée

RFC 2347 introduit les options demandées par le client et l’OACK renvoyé par le serveur. Le serveur peut omettre une option qu’il ne reconnaît pas ; elle doit alors être ignorée comme si elle n’avait jamais été demandée. Le reçu utile est donc le jeu effectif, pas seulement la configuration souhaitée.

RFC 2348 permet de choisir la taille des blocs. RFC 2349 ajoute temporisation et taille de transfert. Ces valeurs améliorent l’exploitation et peuvent empêcher certaines erreurs de capacité. Une taille annoncée reste toutefois un nombre fourni dans la conversation, non une empreinte de l’objet.

RFC 7440 ouvre une fenêtre de plusieurs blocs pour réduire le coût du pas à pas. Il rappelle que TFTP ne possède ni connexion utilisateur ni contrôle d’accès et que l’extension n’ajoute aucune sécurité. Le débit peut progresser alors que le niveau de confiance demeure immobile.

Cette dissociation doit apparaître dans la télémétrie. OACK reçu, dernier ACK reçu, empreinte externe vérifiée, signature approuvée, image installée et version active observée ne doivent jamais être fusionnés dans un seul état « réussi ».

Le démarrage agrandit le rayon de conséquence

La famille BOOTP puis DHCP a rendu pratique l’indication d’un serveur et d’un fichier de démarrage. Les sources attestent cette architecture historique, pas l’usage actuel d’un produit particulier. Dans une enclave de secours, la simplicité de TFTP peut encore être recherchée parce que peu de composants doivent fonctionner.

Mais plus le mécanisme est proche du démarrage, plus la preuve externe est importante. L’artefact téléchargé peut modifier le système qui devrait ensuite rendre compte de sa propre identité. Si l’ancienne image est écrasée avant vérification, le système perd aussi son témoin indépendant.

Un reçu solide commence par l’artefact approuvé : empreinte, signature, taille, classe d’équipement, propriétaire de la décision et créneau. Il continue avec l’URI exact, la résolution du nom, le segment, le serveur autorisé par une mesure externe, le mode, les options demandées et acceptées, le nombre d’octets et l’empreinte calculée à réception. Enfin viennent l’emplacement d’installation, l’activation, l’identité mesurée après démarrage et la disponibilité du retour arrière.

Chaque étape répond à une question. Le registre coordonne un nom. Le DNS localise une adresse. TFTP transporte des blocs. Un vérificateur externe compare le contenu. Le chargeur installe. Le système en exécution produit une observation. Aucun acteur ne doit être crédité des preuves des autres.

Organiser la sortie sans casser le dernier chemin de secours

Une migration sérieuse ne consiste pas à supprimer à l’aveugle toutes les chaînes tftp:. Certaines peuvent appartenir à un mode de récupération qui n’est testé que lorsque le reste est tombé. Retirer ce chemin avant de qualifier son remplaçant transforme une réduction de risque en perte de continuité.

Il faut d’abord découvrir et classer : provisionnement quotidien, laboratoire, héritage inactif ou secours. Ensuite contenir : interfaces, clients, fichiers, opérations et segments minimaux. Puis remplacer par un transport authentifié et une vérification d’artefact indépendante. Enfin tester la panne qui oblige réellement à utiliser la voie de secours.

La primauté du code en exécution, chez Heng Lu, empêche le registre de devenir une autorité imaginaire. La spécification initiale peut fixer une syntaxe minimale et déterministe. L’opérateur conserve la décision locale de permettre, isoler ou refuser. L’adoption et la sécurité se constatent par des transitions observées, non par le prestige du document.

Le paradoxe de RFC 3617 est donc une discipline : normaliser assez pour voir l’ancien mécanisme, sans laisser la normalisation blanchir ses limites.

Sources