TFTP -- Trivial File Transfer Protocol
Overview
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.
Uses
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.
Security
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.
Summary
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.
References
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.