Showing posts with label TFTP session. Show all posts
Showing posts with label TFTP session. Show all posts

Anonymous FTP

A host which provides an FTP service may additionally provide Anonymous FTP access as well. Under this arrangement, users do not strictly need an account on the host. Instead the user typically enters 'anonymous' or 'ftp' when prompted for username. Although users are commonly asked to send their email address as their password, little to no verification is actually performed on the supplied data.

As modern FTP clients typically hide the anonymous login process from the user, the ftp client will supply dummy data as the password (since the user's email address may not be known to the application).

For example, the following ftp user agents specify the listed passwords for anonymous logins:

* Mozilla Firefox (2.0) — mozilla@example.com

* KDE Konqueror (3.5) — anonymous@

* wget (1.10.2) — -wget@

* lftp (3.4.4) — lftp@

Anonymous FTP

The Gopher protocol has been suggested as an alternative to anonymous FTP, as well as Trivial File Transfer Protocol and File Service Protocol.


Trivial File Transfer Protocol

Trivial File Transfer Protocol (TFTP) is a very simple file transfer protocol, with the functionality of a very basic form of FTP; it was first defined in 1980.

Since it is so simple, it is easy to implement in a very small amount of memory — an important consideration at that time. TFTP was therefore useful for booting computers such as routers which did not have any data storage devices. It is still used to transfer small files between hosts on a network, such as when a remote X Window System terminal or any other thin client boots from a network host or server.

TFTP is based in part on the earlier protocol EFTP, which was part of the PUP protocol suite. In the early days of work on the TCP/IP protocol suite, TFTP was often the first protocol implemented on a new host type, because it was so simple.

The original versions of TFTP, prior to RFC 1350, displayed a particularly bad protocol flaw, which was named Sorcerer's Apprentice Syndrome (after the Sorcerer's Apprentice segment of Fantasia) when it was discovered.

TFTP appeared first as part of 4.3 BSD. It is included with Mac OS X through at least version 10.5.

Recently, TFTP has been used by computer worms, such as Blaster, as a method of spreading and infecting new hosts.

Technical information

Some details of TFTP

* It uses UDP port 69 as its transport protocol (unlike FTP which uses TCP port 21).
* It cannot list directory contents.
* It has no authentication or encryption mechanisms.
* It is used to read files from, or write files to, a remote server.
* It supports three different transfer modes, "netascii", "octet" and "mail", with the first two corresponding to the "ASCII" and "image" (binary) modes of the FTP protocol; the third is obsoleted by RFC1350.
* The original protocol has a file size limit of 32 MB, although this was extended when RFC 2347 introduced option negotiation, which was used in RFC 2348 to introduce block-size negotiation in 1998 (allowing a maximum of 4 GB and potentially higher throughput). If the server and client support block number wraparound, file size is essentially unlimited.
* Since TFTP utilizes UDP, it has to supply its own transport and session support. Each file transferred via TFTP constitutes an independent exchange. That transfer is performed in lock-step, with only one packet (either a block of data, or an 'acknowledgement') ever in flight on the network at any time. Due to this lack of windowing, TFTP provides low throughput over high latency links.
* Due to the lack of security, it is dangerous over the open Internet. Thus, TFTP is generally only used on private, local networks.

Details of a TFTP session

* The initiating host A sends an RRQ (read request) or WRQ (write request) packet to host B at the well-known port number 69, containing the filename and transfer mode.
* B replies with an ACK (acknowledgement) packet to WRQ and directly with a DATA packet to RRQ. Packet is sent from a freshly allocated ephemeral port, and all future packets to host B should be to this port.
* The source host sends numbered DATA packets to the destination host, all but the last containing a full-sized block of data. The destination host replies with numbered ACK packets for all DATA packets.
* The final DATA packet must contain less than a full-sized block of data to signal that it is the last. If the size of the transferred file is an exact multiple of the block-size, the source sends a final DATA packet containing 0 bytes of data