Network Working Group K. Sollins Request For Comments: 1350 MIT STD: 33 July 1992 Obsoletes: RFC 783 PROTOCOLLO TFTP (REVISIONE 2) Traduzione a cura di ComiSAT Brescia, Ago. 2006 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di questo documento Questa RFC specifica un protocollo IAB standard per la comunita' Internet, e richiede discussioni e suggerimenti per migliorie. Per il livello di standardizzazione e lo status di questo protocollo si faccia riferimento all'edizione corrente del "IAB Official Protocol Standards". La distribuzione di questo documento non e' soggetta a limitazioni. Sommario Il TFTP e' un protocollo molto semplice utilizzato per il trasferimento di files. E' da questo che deriva il suo nome, Trivial File Transfer Protocol (modesto protocollo per il trasferimento di file) o TFTP. Ogni pacchetto non terminale viene riconosciuto separatamente. Questo documento descrive il protocollo e i suoi tipi di pacchetto. Il documento spiega inoltre i motivi alla base di alcune scelte progettuali. Riconoscimenti Il protocollo fu in origine sviluppato da Noel Chiappa, poi ridisegnato da lui, Bob Baldwin e Dave Clark, con osservazioni di Steve Szymanski. La revisione corrente del documento comprende modifiche derivate da discussioni e suggerimenti di Larry Allen, Noel Chiappa, Dave Clark, Geoff Cooper, Mike Greenwald, Liza Martin, David Reed, Craig Milo Rogers (del USC-ISI), Kathy Yellick, e l'autore. Il riconoscimento e lo schema di ritrasmissione si ispira al TCP, e il meccanismo d'errore e' stato suggerito dal messaggio di abort dell'EFTP del PARC. Nel Maggio 1992, e' stata compiuta da Noel Chiappa una revisione per correggere il bug di protocollo noto come "Sorcerer's Apprentice" e altri problemi minori. Questa ricerca e' stata supportata dall'Advanced Research Projects Agency del Dipartimento di Difesa e monitorata dall' Office of Naval Research sotto il contratto numero N00014-75-C-0661. 1. Obiettivo Il TFTP e' un protocollo semplice per trasferire files, e per questo e' stato nominato Trivial File Transfer Protocol o TFTP. E' stato implementato sopra l'Internet User Datagram Protocol (UDP o Datagramma) [2] Sollins [Page 1] RFC 1350 TFTP Revision 2 July 1992 cosi' da poter essere usato per muovere files tra macchine su reti diverse che implementano l'UDP. (Questo non dovrebbe escludere la possibilita' di implementare il TFTP su altri protocolli datagramma). Esso e' concepito per essere piccolo e facilmente implementabile. Di conseguenza, e' carente di molte delle caretteristiche del normale FTP. L'unica cosa che puo' fare e' leggere e scrivere files (o mail) da/a un server remoto. Non puo' listare directories, e attualmente non e' dotato di misure di autenticazione utente. Come altri protocolli Internet, esso trasferisce dati di bytes a 8 bit. Attualmente sono supportate tre modalita' di trasferimento: netascii (l'ascii come definito nel "USA Standard Code for Information Interchange" [1] con le modifiche specificate nella "Specifica del Protocollo Telnet" [3]. Si tenga presente che quest' e' ascii a 8 bit. Il termine "netascii" verra' usato in questo documento per indicare questa particolare versione dell'ascii); ottetto (sostituisce la modalita' "binaria" della versione precedente di questo documento) raw bytes a 8 bit; mail, caratteri netascii inviati ad un utente anziche' un file (la modalita' mail e' obsoleta e non dovrebbe venire implementata o usata). Modalita' supplementari possono essere definite da una coppia di host cooperanti. Il riferimento [4] (sezione 4.2) dovrebbe essere consultato per ulteriori importanti direttive e suggerimenti sul TFTP. 2. Panoramica sul Protocollo Ogni trasferimento inizia con la richiesta di lettura o scrittura di un file, che serve anche a richiedere una connessione. Se il server concede la richiesta, si apre la connessione e il file viene inviato in blocchi a lunghezza fissa di 512 bytes. Ciascun pacchetto di dati contiene un blocco di dati, e deve essere riconosciuto da un pacchetto di riconoscimento prima che il prossimo pacchetto possa essere spedito. Un pacchetto di dati inferiore a 512 bytes segna il termine di un trasferimento. Se un pacchetto viene perso per la rete, il destinatario andra' in timeout e potra' ritrasmettere il suo ultimo pacchetto (che si tratti di un pacchetto dati o un pacchetto di riconoscimento), sebbene comporti che il mittente del pacchetto perduto ritrasmetta tale pacchetto. Il mittente deve tenere in mano solo un pacchetto per la ritrasmissione, dal momento che il passo di riconoscimento bloccato garantisce che tutti i vecchi pacchetti sono stati ricevuti. Si tenga presente che entrambe le macchine coinvolte nel trasferimento vengono considerate mittenti e destinatari. Una invia dati e riceve riconoscimenti, l'altra invia riconoscimenti e riceve dati. La maggior parte degli errori causa il termine della connessione. Un errore viene segnalato mediante l'invio di un pacchetto di errore. Tale pacchetto non viene riconosciuto e non ritrasmesso (e quindi, un server TFTP o un utente potrebbe terminare dopo l'inzio di messaggio di errore), cosi' l'altro capo della connessione potrebbe non riceverlo. Di conseguenza si utilizzano timeout per rilevare una tale conclusione qualora il pacchetto d'errore sia stato perso. Sollins [Page 2] RFC 1350 TFTP Revision 2 July 1992 Gli errori sono causati da tre tipi di eventi: il non essere in grado di soddisfare la richiesta (ad esempio, file non trovato, violazione d'accesso, o utente inesistente), la ricezione di un pacchetto che non puo' essere spiegato per un ritardo o una duplicazione in rete (ad esempio, un pacchetto formato in maniera non corretta), e la perdita' d'accesso ad un risorsa necessaria (ad esempio, disco pieno o accesso negato durante un trasferimento). Il TFTP riconosce solo una condizione d'errore che non determina fine della connessione, la porta sorgente di un pacchetto ricevuto e' incorretta. In questo caso, viene spiedito un pacchetto d'errore all' host di origine. Questo protocollo e' molto restrittivo, cosi' da semplificarne l'implementazione. Per esempio, i blocchi a lunghezza fissata creano allocazione di inoltro rettilineo, e il blocco del passo di riconoscimento fornisce controllo di flusso ed elimina la necessita' di riordinare i pacchetti di dati in arrivo. 3. Relazioni con altri Protocolli Come menzionato il TFTP e' concepito per essere implementato sopra l'UDP. Poiche' il Datagramma viene implementato sul protocollo IP, i pacchetti avranno un'intestazione Internet, un'intestazione Datagramma ed un'intestazione TFTP. In aggiunta, i pacchetti potrebbero avere un'intestazione (LNI, ARPA, ecc.) per consentir loro di attraversare i mezzi di trasporto locale. Come mostrato dalla Figura 3-1, l'ordine dei contenuti di un pacchetto sara': intestazione del mezzo locale, se usato, intestazione Internet, intestazione Datagramma, intestazione TFTP, segute dal resto del pacchetto TFTP. (Questo puo' o meno essere dati a seconda del tipo di pacchetto come specificato nell'intestazione TFTP). Il TFTP non specifica alcun valore nell'intestazione IP. D'altro canto, i campi di porta sorgente e di destinazione dell'intestazione UDP (il cui formato viene riportato in appendice) sono usati dal TFTP e il campo lunghezza riflesse la dimensione del pacchetto TFTP. Gli identificatori di trasferimento (TID) utilizzati dal TFTP sono passati al livello Datagramma per essere usati come porte; per tale motivo essi devono essere compresi tra 0 e 64535. L'inizializzazione dei TID e' discussa nella sezione relativa al protocollo iniziale di connessione. L'intestazione TFTP consiste in un campo di codice (opcode) di 2 byte che indica il tipo di pacchetto (ad esempio, DATA, ERROR, ecc). Tali codici e formati dei vari tipi di pacchetto sono discussi piu' avanti nella sezione relativa ai pacchetti TFTP. Sollins [Page 3] RFC 1350 TFTP Revision 2 July 1992 ----------------------------------------------------- | Mezzo locale | Internet | Datagramma | TFTP | ----------------------------------------------------- Figura 3-1: Ordine delle Intestazioni 4. Protocollo di Connessione Iniziale Un trasferimento viene stabilito inviando una richiesta (WRQ per scrivere in un file system straniero oppure RRQ per leggere da esso), e ricevendo una risposta positiva, un pacchetto di riconoscimento per la scrittura o il primo pacchetto dati per la lettura. In linea generale, un pacchetto di riconoscimento conterra' il numero di blocco del pacchetto di dati che viene riconosciuto. Ciascun pacchetto di dati ha associato un numero di blocco; i numeri di blocco sono consecutivi e iniziano con uno. Dal momento che la risposta positiva ad una richiesta di scrittura e' un pacchetto di riconoscimento, in questo caso speciale il numero di blocco sara' zero (solitamente, dal momento che un pacchetto di riconoscimento riconosce un pacchetto dati, il pacchetto di riconoscimento conterra' il numero di blocco del pacchetto dati che viene riconosciuto). Se la risposta e' un pacchetto d'errore, allora la richiesta e' stata rifiutata. Per poter creare una connessione, ciascun capo della stessa sceglie per se' stesso un TID, da usare per la durata della connessione. Il TID scelto per una connessione dovrebbe essere scelto in modo casuale, di modo che la probabilita' che venga scelto lo stesso numero in immediata successione sia molto bassa. Tutti i pacchetti hanno a loro associati i due TID dei due capi di connessione, il TID sorgente e il TID di destinazione. Tali TID vengono usati come supporto all'UDP (o ad altri protocolli datagramma) per le porte sorgente e destinazione. Un host richiedente sceglie il suo TID sorgente come sopra descritto, ed invia la sua richiesta iniziale al noto TID 69 (105 ottale) sull'host server. La risposta alla richiesta, in operazione normale, utilizza un TID scelto dal server come suo TID sorgente ed il TID scelto per il messaggio precedente dal richiedente come suo TID di destinazione. I due TID scelti vengono poi usati per il resto del trasferimento. Come esempio, cio' che segue mostra i passi usati per stabilire una connessione finalizzata alla scrittura di un file. Si noti che i WRQ, ACK e DATA sono, rispettivamente, i nomi di richiesta di scrittura, riconoscimento e tipi di pacchetto. L'appendice contiene l'esempio analogo per la lettura di un file. Sollins [Page 4] RFC 1350 TFTP Revision 2 July 1992 1. L'host A invia una "WRQ" all'host B con sorgente= TID di A, destinazione= 69. 2. L'host B invia un "ACK" (con numero di blocco = 0) all'host A con sorgente = TID di B, destinazione= TID di A. A questo punto la connessione viene stabilita e il primo pacchetto di dati puo' essere spedito dall'Host A con un numero di sequenza di 1. Nel passo successivo, e in tutti i passi a seguire, gli host dovrebbero accertarsi che il TID sorgente corrisponda al valore accordato nei punti 1 e 2. Se un TID sorgente non corrisponde, il pacchetto dovrebbe essere scartato come se spedito erroneamente da qualcun altro. Un pacchetto d'errore dovrebbe quindi essere inviato alla sorgente del pacchetto non corretto, senza disturbare la trasmissione. Questo puo' essere fatto solamente se il TFTP riceve infatti un pacchetto con un TIP non corretto. Se i protocolli di supporto non lo consentono, questa condizione particolare non si verifichera'. L'esempio che segue dimostra un'operazione corretta del protocollo nella quale si verifica la situazione di cui sopra. L'host A invia una richiesta all'host B. Da qualche parte nella rete, il pacchetto di richiesta viene duplicato, e come risultato vengono tornati all'host A due riconoscimenti cone TID diversi scelti dall'host B in risposta di due richieste. Quando arriva la prima risposta, l'host A continuera' la connessione. Quando arriva la seconda, essa verra' scartata, ma non vi e' motivo di terminare la prima connessione. Cosi', se vengono scelti due diversi TID per le due connessioni sull'host B e l'host A verifica il TID sorgente dei messaggi che riceve, la prima connessione puo' essere mantenuta mentre la seconda rifiutata ritornando un pacchetto d'errore. 5. Pacchetti TFTP Il TFTP supporta cinque tipi di pacchetti, tutti menzionati sopra: opcode operazione 1 Richiesta di lettura (RRQ) 2 Richiesta di scrittura (WRQ) 3 Dati (DATA) 4 Riconoscimento (ACK) 5 Errore (ERROR) L'intestazione TFTP di un pacchetto contiene l'opcode associtato a quel pacchetto. Sollins [Page 5] RFC 1350 TFTP Revision 2 July 1992 2 bytes stringa 1 byte stringa 1 byte -------------------------------------------------- | Opcode | Nomedelfile | 0 | Modalita' | 0 | -------------------------------------------------- Figura 5-1: pacchetto RRQ/WRQ I pacchetti RRQ e WRQ (opcode 1 e 2 rispettivamente) hanno il formato mostrato in Figura 5-1. Il nome del file e' una sequenza di byte in "netascii" terminante con un bytes zero. Il campo modalita' contiene la stringa "netascii", "octet" o "mail" (o una qualsiasi combinazione di caratteri maiuscoli/minuscoli come NETASCII", NetAscii", ecc.) in netascii per indicare le tre modalita' definite dal protocollo. Un host che riceve dati in modalita' netascii deve interpretare i dati nel suo formato. La modalita' ottetto viene usata per trasferire un file che e' nel formato 8-bit della macchina dal quale il file viene trasferito. Si considera che ciascuna macchina abbia un singolo formato 8-bit piu' comune e che quello sia il formato scelto. Ad esempio, su un DEC-20, una macchina a 36-bit, questo e' quattro bytes a 8-bit per una word cone 4 bit di rottura. Se un host riceve un file ottetto e lo ritorna, il file ritornato dev'essere identico all'originale. La modalita' mail utilizza il nome di destinatario mail al posto del file e deve iniziare con una WRQ. Per il resto, e' identica alla modalita' netascii. La stringa del destinatario mail dev'essere nel formato "nomeutente" o "nomeutente@nomehost". Se viene utilizzata la seconda forma, e' consentita l'opzione di mail forwarding da un computer ritrasmettitore. La discussione di cui sopra considera che sia il mittente che il destinatario siamo operativi nello stesso modo, ma non vi e' ragione che questo debba essere la realta'. Per esempio, uno potrebbe costruire un server d'archiviazione. Non c'e' motivo che tale macchina necessiti di trasformare il netascii nel suo formato di testo utilizzato. Piuttosto, il mittente potrebbe inviare file in netascii ed il server potrebbe semplicemente archiviarli senza alcuna trasformazione in formato 8-bit. Un'altra situazione simile e' un problema che sussiste attualmente sui sistemi DEC-20. Ne' il netascii ne' l'ottetto accedono a tutti i bits di una word. Uno potrebbe creare una modalita' speciale per una tale macchina che legga tutti i bits di una word, ma nella quale il ricevente archivi le informazioni nel formato 8-bit. Quando un file viene richiesto dall'archivio, esso dev'essere riarchiviato nel suo formato originale per essere d'utilizzo, cosi' dev'essere implementata anche la modalita' inversa. Per far questo l'utente dovra' ricordarsi alcune informazioni. In entrambi questi esempi, i pacchetti di richiesta dovrebbe specificare la modalita' ottetto all'host esterno, ma l'host locale dovrebbe trovarsi in qualche altra modalita'. Nel TFTP non e' stata specificata alcuna macchina o modalita' specifica di applicazione, ma uno dovrebbe essere compatibile con questa specifica. E' anche possibile definire altre modalita' per una coppia di host Sollins [Page 6] RFC 1350 TFTP Revision 2 July 1992 cooperanti, sebbene questo debba essere fatto con attenzione. Non vi e' requisito che alcun host implementi questo. Non vi e' autorita' centrale che definira' queste modalita' o assegnera' loro dei nomi. 2 bytes 2 bytes n bytes ---------------------------------- | Opcode | # Blocco | Dati | ---------------------------------- Figura 5-2: pacchetto DATA I dati vengono attualmente trasferiti in pacchetti DATA come rappresentato in Figura 5-2. I pacchetti DATA (opcode = 3) hanno il numero di blocco e il campo dati. I numeri di blocco nei pacchetti dati iniziano con uno ed incrementato di uno per ciascun nuovo blocco di dati. Questa restrizione consente al programma di utilizzare un singolo numero per differenziare pacchetti nuovi da duplicati. Il campo dati e' di lunghezza da 0 a 512 bytes. Se e' di 512 bytes, il blocco non e' l'ultimo blocco dei dati; se e' di lunghezza tra 0 e 511 bytes, esso segna la fine del trasferimento. (Per dettagli si veda la sezione Terminazione Normale). Tutti i pacchetti diversi dai duplicati ACK e quelli usati per la terminazione sono riconosciuti senza che si verifichi un timeout [4]. L'invio di un pacchetto DATA e' un riconoscimento per il primo pacchetto ACK del pacchetto DATA precedente. I pacchetti WRQ e DATA sono riconosciuti dai pacchetti ACK o ERROR, mentre i pacchetti RRQ 2 bytes 2 bytes --------------------- | Opcode | # Blocco | --------------------- Figura 5-3: pacchetto ACK e ACK sono riconosciuti dai pacchetti DATA o ERROR. La Figura 5-3 rappresenta un pacchetto ACK; l'opcode e' 4. Il numero di blocco in un ACK e' il ritorno del numero di blocco del pacchetto DATA che e' stato riconosciuto. Un WRQ viene riconosciuto con un pacchetto ACK avente numero di blocco pari a zero. Sollins [Page 7] RFC 1350 TFTP Revision 2 July 1992 2 bytes 2 bytes string 1 byte -------------------------------------------------------- | Opcode | CodicediErrore | MessaggiodiErrore | 0 | -------------------------------------------------------- Figura 5-4: pacchetto ERROR Un pacchetto ERROR (opcode 5) assume la forma rappresentata nella Figura 5-4. Un pacchetto ERROR puo' essere il riconoscimento di qualsiasi altro tipo di pacchetto. Il codice di errore e' un numero intero che indica la natura dell'errore. Una tabella di valori e dei relativi significati viene riportata in appendice. (Si tenga presente che svariati codici d'errore sono stati aggiunti a questa versione di questo documento). Il messaggio di errore e' concepito per la comprensione umana, e dovrebbe essere in netascii. Come tutte le altre stringhe, esso termina con un byte zero. 6. Terminazione Normale La fine del trasferimento e' marchiata da un pacchetto DATA che contiene da 0 a 511 bytes di dati (ad esempio, Datagramma di lunghezza < 516). Tale pacchetto viene riconosciuto da un pacchetto ACK come tutti gli altri pacchetti DATA. L'host che riconosce il pacchetto DATA finale puo' terminare la connessione dal suo lato inviando l'ACK finale. Sull'altro lato e' consigliata l'attesa. Questo significa che l'host che invia l'ACK finale aspettera' un attimo prima di chiudere in modo da ritrasmettere l'ACK finale se questo fosse stato perso. Il riconoscitore sapra' che l'ACK e' stato perso se riceve nuovamente il pacchetto DATA finale. L'host mittente dell'ultimo DATA deve ritrasmetterlo finche' il pacchetto viene riconosciuto o l'host mittente vada in timeout. Se la risposta e' un ACK, la trasmissione viene terminata con successo. Se il mittente dei dati va in time oute e non e' pronto per ritrasmettere alcunche', il trasferimento potrebbe anche esser stato completato con successo, dopo che il riconoscitore o la rete possono aver avvertito il problema. E' anche possibile in questo caso che il trasferimento non sia andato a buon fine. In ogni caso, la connessione e' stata chiusa. 7. Terminazione Prematura Se una richiesta non puo' essere soddisfatta, o si verifica qualche errore durante il trasferimento, viene spedito un pacchetto ERROR (opcode 5). Questo e' soltanto un fatto di cortesia dal momento che essa non verra' ritrasmessa o riconosciuta, e quindi non potra' mai essere ricevuta. Per rilevare errori devono essere utilizzati anche i timeout. Sollins [Page 8] RFC 1350 TFTP Revision 2 July 1992 I. Appendice Ordine delle Intestazioni 2 bytes ---------------------------------------------------------- | Mezzo locale | Internet | Datagramma | Opcode TFTP | ---------------------------------------------------------- Formati TFTP Tipo # Op Formati senza intestazione 2 bytes stringa 1 byte stringa 1 byte ----------------------------------------------- RRQ/ | 01/02 | Nomefile | 0 | Modalita | 0 | WRQ ----------------------------------------------- 2 bytes 2 bytes n bytes --------------------------------- DATA | 03 | # Blocco | Data | --------------------------------- 2 bytes 2 bytes ------------------- ACK | 04 | # Blocco | -------------------- 2 bytes 2 bytes stringa 1 byte ------------------------------------------ ERROR | 05 | CodicediErrore | MsgErrore | 0 | ------------------------------------------ Protocollo di Connessione Iniziale per la lettura di un file 1. L'host A invia una "RRQ" all'host B con sorgente= TID di A, destinazione= 69. 2. L'host B invia un "DATA" (con # blocco= 1) all'host A con sorgente= TID di B, destinazione= TID di A. Sollins [Page 9] RFC 1350 TFTP Revision 2 July 1992 Codici di Errore Valore Significato 0 Non definito, si veda il messaggio di errore (se presente). 1 File non trovato. 2 Violazione d'accesso. 3 Disco pieno o allocazione superata. 4 Operazione TFTP illegale. 5 ID di trasferimento sconosciuto. 6 Il file esiste gia'. 7 Utente inesistente. Intestazione Internet Datagramma Utente [2] (Questo e' stato incluso solo per convenienza. Il TFTP non implica l'implementazione sopra l'UDP). Formato 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Porta Sorgente | Porta di destinazione | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lunghezza | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valori dei Campi Porta Sorgente Determinata da chi ha originato il pacchetto Porta di Dest. Determinata dalla macchina di dest. (69 per RRQ o WRQ). Lunghezza Numero di bytes del pacchetto UDP, compresa l'intestazione UDP. Checksum Il riferimento 2 descrive le regole di computazione del checksum. (Chi lo implementa dovrebbe essere sicuro che venga qui usato l'algoritmo corretto). Se non utilizzato il campo contiene zero. Nota: il TFTP passa gli identificatori di trasferimento (TID) all'UDP affinche' siano usati come porte sorgente e di destinazione. Sollins [Page 10] RFC 1350 TFTP Revision 2 July 1992 Riferimenti [1] USA Standard Code for Information Interchange, USASI X3.4-1968. [2] Postel, J., "User Datagram Protocol," RFC 768, USC/Information Sciences Institute, 28 August 1980. [3] Postel, J., "Telnet Protocol Specification," RFC 764, USC/Information Sciences Institute, June, 1980. [4] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989. Considerazioni sulla Sicurezza Dal momento che il TFTP non comprende alcun meccanismo di login o di controllo d'accesso, l'attenzione dev'essere posta alle giuste accettazioni di richieste del processo server FTP di modo che non violino la sicurezza del file system dell'host server. Il TFTP viene spesso installato con controlli tali che soltanto i files che hanno pubblico accesso in lettura siano disponibili via TFTP mentre non viene concessa la scrittura di files via TFTP. Indirizzo dell'Autore Karen R. Sollins Massachusetts Institute of Technology Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139-1986 Phone: (617) 253-6006 EMail: SOLLINS@LCS.MIT.EDU Sollins [Page 11]