TFTP -- Trivial File Transfer Protocol


TFTP, Trivial File Transfer Protocol, is a very simple protocol designed to transfer files across a network, hence the term trivial. This protocol was originally designed by Noel Chippa, it was later revised by Chippa, Bob Baldwin and Dave Clark. TFTP, the Trivial File Transfer Protocol was designed, as its name implies, to be a very simplistic protocol that encompasses only the basics of transferring files, and does not include many of the features of standard FTP. The capabilities of TFTP are basically limited to reading and writing files to and from a remote server. Because it was designed to be simple, it is also very restrictive as to what it can do. The TFTP protocol itself is implemented on top of User Data Protocol (UDP) which in turn runs on top of the Internet Protocol (IP). UDP provides connection-less service at layer four of the OSI network protocol model. Since TFTP is implemented using IP, the computer using TFTP must be capable of receiving IP packets of up to 524 bytes in length (excluding IP header information), since TFTP data packets are 516 bytes long, and UDP headers are 8 bytes long.


The primary, and only practical, purpose of TFTP is for bootstrapping host over a local network. Bootstrapping allows machines that are new to the system, and machines that have lost everything to become active on the network. Because TFTP is based on the standard Internet Protocol (IP), it can be easily implemented in both the machine being booted, and the server located elsewhere on the net. One drawback of TFTP is the fact that it is a relatively slow protocol; however, speed is often not a major issue when bootstrapping a computer. If however, performance is an issue, it is possible to use TFTP for the primary bootstrap, and another faster protocol can be used as the secondary bootstrap. Any computer on a network may need to be bootstrapped remotely, one example would be a diskless workstation that may need certain files to be copied to it in order for it to become active. In order to load a file from a remote server, the booter (the computer being booted) sends a standard TFTP read request to the server. The read request contains the name of the file to be transferred. Once the transfer has begun, the server sends data packets one at a time, and the booter sends acknowledgment packets for each packet until the transfer is complete. There are five different types of TFTP packets that can be transmitted. There is a Read Request packet (RRQ) which the booter sends to the server to request that the file named in the RRQ packet be transferred, a Write Request packet (WRQ) which is sent to request that the sender be able to write a file to the receiver's machine. A Data packet is a packet that contains part or all of the file being transferred. An Acknowledgment packet (ACK) is sent for each data packet received, when bootstrapping, the server does not transmit the next Data packet until it has received an Acknowledgment packet for the previous Data packet that it sent. The final type of packet is an Error packet, which is sent to state that an error has occurred, it contains a message for human analysis, and usually causes the TFTP process to terminate. The normal end of a transmission is denoted by the server sending a data packet of length less than the maximum 512 bytes, when this occurs the transfer is complete.

Working with ARP and RARP

TFTP often works with the Address Resolution Protocol (ARP) and the Reverse Address Resolution Protocol (RARP) to help bootstrap a machine. Often when booting a computer on a network, if the machine is new, the booter may not know its internet address, only its low level (Ethernet, Token Ring, etc) address. In this case, before it can send a TFTP Read Request packet to the server it must find out its internet address by sending out a RARP request to find out what his internet address is. It is also possible, but less likely, that a machine may know its IP address, but not its low level address, in this case, the machine may send out an ARP request to find out its low level address. In either case, this information can be used when the booter sends out a Read Request to the server.


TFTP itself was designed to be a very simple way to transfer files between machines, because it was designed to be so very simple the things that is does in terms of maintaining security can be summed up in two words: "almost nothing". TFTP provides no login or access control mechanisms whatsoever. Because TFTP provides no means for validating the identity of a computer requesting file transfers, the security of TFTP can be a major concern. Since TFPT requires no authentication, it can be a relatively simple process for a rogue machine to become a legal computer on the network by saying "hey, I'm new here and I need to be booted", and since there is no way for TFTP to check if the computer is legitimate or not, this machine could become a legal machine on the network. A huge security breach can occur if TFTP is not configured correctly. When TFPT is configured correctly, it can ensure that only those files related to bootstrapping can be transferred, usually it is restricted to a certain directory, or sometimes it may transfer only those files which are world readable anyway. If however, TFTP is not configured correctly, and it is not restricted to a directory only containing files for bootstrapping purposes, it may be possible for any machine to come in using TFTP and copy any file ( /etc/passwd for example ) to his own machine without any sort of authentication check, and no file or directory permission checks (this is bad). A common way for someone to look for machines with TFTP configured incorrectly is to perform directed broadcasts of TFTP Request packets to different networks and see which machines respond. From that point, all the person has to do is try each of those machines, and see which ones are willing to give up important files.


Basically speaking, TFTP does nothing in terms of security, it does not provide any sort of access control. If it is configured incorrectly, the results can be disastrous because it can allow any file to be copied to any computer without performing any kind of user validation. Because of these risks, some sites do not allow TFTP access from outside of their sites, while some simply choose not to run the TFTP daemon on their machines that hold sensitive material.


1. Sollins, K., "The TFTP Protocol (Revision 2)", RFC783, June 1981.
2. Finlayson, R., "Bootstrap Loading using TFTP", RFC906, June 1984.

Thanks to Dr. Karen Sollins and Dr. Gary Malkin for responding to my email, and to Nihil for his comments via Usenet.

TFTP is publically available at sites such as the Coast Archive at Purdue University.