TFTP (Trivial File Transfer Protocol), il pro­to­col­lo semplice per il tra­sfe­ri­men­to di file

Per con­sen­ti­re lo scambio di dati tra due sistemi in­for­ma­ti­ci in rete è in­di­spen­sa­bi­le una base di com­pren­sio­ne comune. Uno dei pro­to­col­li più semplici svi­lup­pa­ti a tale scopo è il Trivial File Transfer Protocol (TFTP), che ha giocato un ruolo im­por­tan­te in par­ti­co­la­re agli inizi di Internet.

Il Trivial File Transfer Protocol, in breve TFTP, è un pro­to­col­lo del Client Server molto semplice, il quale regola il tra­sfe­ri­men­to di file nelle reti in­for­ma­ti­che. Una prima specifica fu pub­bli­ca­ta nel giugno 1981 in RFC 783. Lo standard attuale è di­spo­ni­bi­le in RFC 1350, apparso nel 1992. Il pro­to­col­lo TFTP si avvale di default dell’al­tret­tan­to mi­ni­ma­li­sta pro­to­col­lo di trasporto UDP (User Datagram Protocol), che prevede un tra­sfe­ri­men­to di dati tra le parti co­mu­ni­can­ti senza un col­le­ga­men­to fisso. Comunque l’im­ple­men­ta­zio­ne di TFTP è possibile anche sulla base di altri pro­to­col­li.

Il pro­to­col­lo di tra­sfe­ri­men­to di file orientato ai pacchetti, parte della famiglia di pro­to­col­li TCP/IP, fu ap­po­si­ta­men­te pro­get­ta­to con di­men­sio­ni ridotte per essere facile da im­ple­men­ta­re. Pertanto, descrive solo i metodi di lettura e scrittura per file o mail da un server. Un elenco di directory o l’as­se­gna­zio­ne di diritti mediante chmod (come con­sen­ti­to dal più noto File Transfer Protocol (FTP)), non sono possibili con TFTP. Per le richieste, TFTP utilizza la porta 69. Suc­ces­si­va­men­te, la co­mu­ni­ca­zio­ne avviene mediante numeri di porte assegnati in­di­vi­dual­men­te (tra 1024 e 65535), che il server TFTP trasmette al client ri­chie­den­te in forma di TID (Transfer Identifiers).

Il tra­sfe­ri­men­to di file tramite TFTP si basa sempre su una richiesta client, in cui viene richiesto l’accesso di scrittura o lettura. Questa richiesta serve anche come domanda di con­nes­sio­ne, che viene concessa au­to­ma­ti­ca­men­te quando il server accetta l’accesso. Suc­ces­si­va­men­te, client o server inviano il ri­spet­ti­vo file in blocchi con una di­men­sio­ne definita. Nelle prime versioni di pro­to­col­lo si applicava ancora il valore fisso di 512 bytes; dal RFC 2348, server e client sono in grado di negoziare in­di­vi­dual­men­te le di­men­sio­ni del blocco.

La spe­di­zio­ne ha luogo blocco per blocco; ogni blocco ricevuto va con­fer­ma­to at­tra­ver­so un pacchetto specifico (“Ac­k­no­w­led­ge­ment”) prima che il suc­ces­si­vo possa essere inviato. Un pacchetto dati di di­men­sio­ni ridotte rispetto a quella definita in byte indica la fine del tra­sfe­ri­men­to di file. Se un pacchetto viene perso durante il tra­sfe­ri­men­to, il de­sti­na­ta­rio riceve un timeout, in seguito al quale egli invia nuo­va­men­te l’ultimo pacchetto inviato. In questo modo, il mittente del pacchetto perso viene a sapere che è ne­ces­sa­rio ri­tra­sfe­rir­lo. Gli errori emersi durante il tra­sfe­ri­men­to di file TFTP portano a pacchetti di errore che, nella maggior parte dei casi, con­clu­do­no il tra­sfe­ri­men­to. Di seguito sono riportate tre possibili fonti di errore:

• la richiesta non può essere evasa ade­gua­ta­men­te, ad esempio perché non è stato possibile trovare il file, in quanto l’utente non esiste o per via di una vio­la­zio­ne d’accesso (file protetto, ecc.);
• client o server ricevono un pacchetto che non può essere spiegato con un ritardo o una du­pli­ca­zio­ne in rete; ciò può ve­ri­fi­car­si in caso di pacchetti mal­for­ma­ti;
• l’accesso ad una risorsa ne­ces­sa­ria viene perso, ad esempio in assenza di spazio suf­fi­cien­te sul disco rigido.

Il pro­to­col­lo TFTP supporta com­ples­si­va­men­te 5 tipi di pacchetti, i quali si an­nun­cia­no mediante un proprio campo “Opcode” (che sta per Operation Code) a 16 bit con il ri­spet­ti­vo valore:

Tuttavia, il valore Opcode non è l’unico com­po­nen­te in cui la struttura dei tipi di pacchetti elencati si dif­fe­ren­zia.

Sia i messaggi RRQ che WRQ iniziano con il campo Opcode a 16 bit tipico del pro­to­col­lo. Come mostra la prima tabella, i pacchetti RRQ sfruttano qui il valore “1”, mentre i pacchetti WRQ sono con­tras­se­gna­ti con il valore “2”. Segue una sequenza di bit in formato NetASCII di di­men­sio­ne variabile; questa include il nome del file da leggere o inviare. La fine è ca­rat­te­riz­za­ta da un campo di zeri a 8 bit.

Un’altra stringa di lunghezza variabile contiene infine l’in­for­ma­zio­ne sulla modalità di tra­sfe­ri­men­to dei dati. Qui sono di­spo­ni­bi­li tre varianti “netascii”, “octet” (per il tra­sfe­ri­men­to di un file di formato a 8 bit) e “mail” (per il tra­sfe­ri­men­to di un indirizzo e-mail). Anche la fine di questo campo è con­tras­se­gna­ta dall’aggiunta di un gruppo di zeri a 8 bit.

Anche i pacchetti DATA iniziano con il campo Opcode a cui, in questo caso, è assegnato il valore “3”. La suc­ces­si­va sequenza a 16 bit ca­rat­te­riz­za il numero del blocco dati, in cui il valore “1” funge da numero iniziale. Tale valore aumenta au­to­ma­ti­ca­men­te di 1 ad ogni blocco dati ulteriore ap­par­te­nen­te al file. Al contempo, i blocchi stessi si ritrovano nel campo dati di di­men­sio­ni tra 0 e 512 bytes (4096 bit) se server e client TFTP non hanno trattato altre di­men­sio­ni massime per i blocchi. Se la ri­spet­ti­va di­men­sio­ne massima viene com­ple­ta­ta, questo è un segno che il pacchetto DATA non contiene l’ultimo blocco dati del file.

Questo ultimo blocco, che con­trad­di­stin­gue la fine del tra­sfe­ri­men­to dati, è sempre inferiore di almeno un byte. Se il resto del file da tra­sfe­ri­re presenta ca­sual­men­te la medesima di­men­sio­ne del blocco, il mittente è tenuto ad inviare un altro pacchetto con blocco dati vuoto.

Tutti i pacchetti WRQ e i pacchetti dati che non con­trad­di­stin­guo­no la fine del tra­sfe­ri­men­to dati vengono con­fer­ma­ti dal Trivial File Transfer Protocol con messaggi ACK, se la co­mu­ni­ca­zio­ne funziona cor­ret­ta­men­te (tranne in caso di timeout).

I messaggi ACK della co­mu­ni­ca­zio­ne pro­to­col­lo TFTP sono composti dall’Opcode a 16 bit, che accetta il valore “4” e dal numero a 16 bit del blocco dati che il messaggio ACK conferma. Se si tratta di una risposta a una richiesta WRQ, il pacchetto ACK presenta il numero del blocco dati “0”.

Dopo l’Opcode (valore “5”), che occupa la prima posizione anche nei messaggi ERROR, segue un campo a 16 bit con­te­nen­te il codice errore. Il valore “1” indica quindi per esempio che non è stato possibile trovare il relativo file, mentre il valore “6” svela al sistema ricevente che il file esiste già. Il suc­ces­si­vo messaggio di errore aiuta l’utente a com­pren­de­re il problema. Anche per questo motivo, la stringa di caratteri con di­men­sio­ni variabili è tipica nel formato NetASCII. La con­clu­sio­ne è un campo di zeri a 8 bit.

TFTP convince in primo luogo per la sua sem­pli­ci­tà. Il pro­to­col­lo punta a con­sen­ti­re la scrittura e la lettura di file e svolge questo ruolo senza la necessità di creare una con­nes­sio­ne tra client e server. Di con­se­guen­za, non solo il pro­to­col­lo TFTP è facile da im­ple­men­ta­re, ma consente anche un rapido tra­sfe­ri­men­to dei dati. I transfer Iden­ti­fier (TID) e i numeri di blocchi di dati unici con­sen­to­no l’arrivo a de­sti­na­zio­ne del ri­spet­ti­vo file completo.

La mancanza di una cifratura e di un mec­ca­ni­smo di au­ten­ti­ca­zio­ne o controllo dell’accesso rende la spe­di­zio­ne di file sensibili mediante TFTP molto rischiosa; per questo si ricercano al­ter­na­ti­ve più sicure come il più complesso FTP. Inoltre, non è ammesso eliminare e ri­no­mi­na­re i file su tanti server TFTP.

Il pro­to­col­lo TFTP è stret­ta­men­te legato al co­sid­det­to booting di rete (anche “boo­tstrap­ping”). In questa tecnica, par­ti­co­lar­men­te uti­liz­za­ta negli anni ’80, un computer di rete ottiene e avvia il sistema operativo da un server centrale. In par­ti­co­la­re per i terminal e le work­sta­tion senza disco rigido che non con­sen­to­no l’in­stal­la­zio­ne di un proprio sistema operativo, lo sviluppo e l’im­ple­men­ta­zio­ne di TFTP sono stati decisivi. Il pro­to­col­lo di tra­sfe­ri­men­to del file era sup­por­ta­to dal BOOTP pub­bli­ca­to nel 1985, che con­sen­ti­va ai client di rete di ottenere au­to­ma­ti­ca­men­te l’indirizzo del server TFTP.

Oggi il Trivial File Transfer Protocol viene impiegato molto più raramente. Nelle reti i cui par­te­ci­pan­ti di­spon­go­no ora di propri sistemi operativi, il metodo di avvio della rete può essere trovato solo isolato e in forma mo­di­fi­ca­ta. Ad esempio, in­stal­la­zio­ni di sistema, ma­nu­ten­zio­ni, ag­gior­na­men­ti del firmware o scansioni antivirus possono aiutare a ridurre il so­vrac­ca­ri­co am­mi­ni­stra­ti­vo at­tra­ver­so i co­sid­det­ti sistemi operativi ausiliari. Anche nelle memorie ROM si trova im­ple­men­ta­to il TFTP, in quanto richiede un utilizzo di risorse limitate per via della mancanza di con­nes­sio­ne del pro­to­col­lo. Inoltre, i server TFTP vengono uti­liz­za­ti per pro­teg­ge­re le con­fi­gu­ra­zio­ni e le immagini di sistema di router e switch Cisco e per ar­chi­via­re i record di dati tariffari presso i sistemi te­le­fo­ni­ci Siemens.