FTP and NAT devices

The representation of the IPs and ports in the PORT command and PASV reply poses another challenge for NAT devices in handling FTP. The NAT device must alter these values, so that they contain the IP of the NAT-ed client, and a port chosen by the NAT device for the data connection. The new IP and port will probably differ in length in their decimal representation from the original IP and port. This means that altering the values on the control connection by the NAT device must be done carefully, changing the TCP and Acknowledgment fields for all subsequent packets.

For example: A client with an IP of 192.168.0.1, starting an active mode transfer on port 1025, will send the string "PORT 192,168,0,1,4,1". A NAT device masquerading this client with an IP of 192.168.15.5, with a chosen port of 2000 for the data connection, will need to replace the above string with "PORT 192,168,15,5,7,208".

The new string is 23 characters long, compared to 20 characters in the original packet. The Acknowledgment field by the server to this packet will need to be decreased by 3 bytes by the NAT device for the client to correctly understand that the PORT command has arrived to the server. If the NAT device is not capable of correcting the Sequence and Acknowledgement fields, it will not be possible to use active mode FTP. Passive mode FTP will work in this case, because the information about the IP and port for the data connection is sent by the server, which doesn't need to be NATed. If NAT is performed on the server by the NAT device, then the exact opposite will happen. Active mode will work, but passive mode will fail.

It should be noted that many NAT devices perform this protocol inspection and modify the PORT command without being explicitly told to do so by the user. This can lead to several problems. First of all, there is no guarantee that the used protocol really is FTP, or it might use some extension not understood by the NAT device. One example would be an SSL secured FTP connection. Due to the encryption, the NAT device will be unable to modify the address. As result, active mode transfers will fail only if encryption is used, much to the confusion of the user.

The proper way to solve this is to tell the client which IP address and ports to use for active mode. Furthermore, the NAT device has to be configured to forward the selected range of ports to the client's machine.

FTP and web browsers

Most recent web browsers and file managers can connect to FTP servers, although they may lack the support for protocol extensions such as FTPS. This allows manipulation of remote files over FTP through an interface similar to that used for local files. This is done via an FTP URL, which takes the form ftp(s)://<ftpserveraddress> (e.g., ftp://ftp.gimp.org/). A password can optionally be given in the URL, e.g.: ftp(s)://<login>:<password>@<ftpserveraddress>:<port>. Most web-browsers require the use of passive mode FTP, which not all FTP servers are capable of handling. Some browsers allow only the downloading of files, but offer no way to upload files to the server

FTP return codes

FTP server return codes indicate their status by the digits within them. A brief explanation of various digits' meanings are given below:

• 1xx: Positive Preliminary reply. The action requested is being initiated but there will be another reply before it begins.
• 2xx: Positive Completion reply. The action requested has been completed. The client may now issue a new command.
• 3xx: Positive Intermediate reply. The command was successful, but a further command is required before the server can act upon the request.
• 4xx: Transient Negative Completion reply. The command was not successful, but the client is free to try the command again as the failure is only temporary.
• 5xx: Permanent Negative Completion reply. The command was not successful and the client should not attempt to repeat it again.
• x0x: The failure was due to syntax error.
• x1x: This response is a reply to a request for information.
• x2x: This response is a reply relating to connection information.
• x3x: This response is a reply relating to accounting and authorization.
• x4x: Unspecified as yet
• x5x: These responses indicate the status of the Server file system vis-a-vis the requested

Securtity Problems

The original FTP specification is an inherently insecure method of transferring files because there is no method specified for transferring data in an encrypted fashion. This means that under most network configurations, user names, passwords, FTP commands and transferred files can be "sniffed" or viewed by anyone on the same network using a packet sniffer. This is a problem common to many Internet protocol specifications written prior to the creation of SSL such as HTTP, SMTP and TELNET. The common solution to this problem is to use either the SFTP (SSH File Transfer Protocol), or FTPS(FTP over SSl), which adds SSL to FTP as specified in RFC 2417

Criticisms of FTP

• Passwords and file contents are sent in clear text, which can be intercepted by eavesdroppers. There are protocol enhancements that circumvent this, for instance by using SSL, TLS or kerberos.
• Multiple TCP/IP connections are used, one for the control connection, and one for each download, upload, or directory listing. Firewalls may need additional logic and or configuration changes to account for these connections.
• It is hard to filter active mode FTP traffic on the client side by using a firewall, since the client must open an arbitrary the portin order to receive the connection. This problem is largely resolved by using passive mode FTP.
• It is possible to abuse the protocol's built-in proxy features to tell a server to send data to an arbitrary port of a third computer; see FXP.
• FTP is a high latency protocol due to the number of commands needed to initiate a transfer.
• No integrity check on the receiver side. If a transfer is interrupted, the receiver has no way to know if the received file is complete or not. Some servers support extensions to calculate for example a file's , however even then the client has to make explicit use of them. In the absence of such extensions, integrity checks have to be managed externally.
• No date/timestamp attribute transfer. Uploaded files are given a new current timestamp, unlike other file transfer protocols such as SFTP, which allow attributes to be included. There is no way in the standard FTP protocol to set the time-last-modified (or time-created) datestamp that most modern filesystems preserve. There is a draft of a proposed extension that adds new commands for this, but as of yet, most of the popular FTP servers do not support it.

Connection methods of FTP

FTP runs exclusively over TCP. FTP servers by default listen on the port 21 for incoming connections from FTP clients. A connection to this port from the FTP Client forms the control stream on which commands are passed to the FTP server from the FTP client and on occasion from the FTP server to the FTP client. FTP uses the out-of -band control which means it uses a separate connection for control and data. Thus, for the actual file transfer to take place, a different connection is required which is called the data stream. Depending on the transfer mode, the process of setting up the data stream is different.

In active mode, the FTP client opens the Dynamic Port (49152–65535), sends the FTP server the dynamic port number on which it is listening over the control stream and waits for a connection from the FTP server. When the FTP server initiates the data connection to the FTP client it binds the source port to port 20 on the FTP server.

In order to use active mode, the client sends a PORT command, with the IP and port as argument. The format for the IP and port is "h1,h2,h3,h4,p1,p2". Each field is a decimal representation of 8 bits of the host IP, followed by the chosen data port. For example, a client with an IP of 192.168.0.1, listening on port 49154 for the data connection will send the command "PORT 192,168,0,1,192,2". The port fields should be interpreted as p1×256 + p2 = port, or, in this example, 192×256 + 2 = 49154.

In passive mode, the FTP server opens a dynamic port (49152–65535), sends the FTP client the server's IP address to connect to and the port on which it is listening (a 16 bit value broken into a high and low byte, like explained before) over the control stream and waits for a connection from the FTP client. In this case the FTP client binds the source port of the connection to a dynamic port between 49152 and 65535.

To use passive mode, the client sends the PASV command to which the server would reply with something similar to "227 Entering Passive Mode (127,0,0,1,192,52)". The syntax of the IP address and port are the same as for the argument to the PORT command.

In extended passive mode, the FTP server operates exactly the same as passive mode, however it only transmits the port number (not broken into high and low bytes) and the client is to assume that it connects to the same IP address that was originally connected to. Extended passive mode was added by the RFC 2428 September 1998.

While data is being transferred via the data stream, the control stream sits idle. This can cause problems with large data transfers through the firewalls which time out sessions after lengthy periods of idleness. While the file may well be successfully transferred, the control session can be disconnected by the firewall, causing an error to be generated.

The FTP protocol supports resuming of interrupted downloads using the REST command. The client passes the number of bytes it has already received as argument to the REST command and restarts the transfer. In some commandline clients for example, there is an often-ignored but valuable command, "reget" (meaning "get again") that will cause an interrupted "get" command to be continued, hopefully to completion, after a communications interruption.

Resuming uploads is not as easy. Although the FTP protocol supports the APPE command to append data to a file on the server, the client does not know the exact position at which a transfer got interrupted. It has to obtain the size of the file some other way, for example over a directory listing or using the SIZE command.

In ASCII mode (see below), resuming transfers can be troublesome if client and server use different end of line characters

The objectives of FTP, as outlined by its RFC are

1. To promote sharing of files (computer programs and/or data).
2. To encourage indirect or implicit use of the remote computers.
   
3. To shield a user from variations in file storage systems among different hosts.
4. To transfer data, and efficiently.

File Transfer Protocol

File Transfer Protocol (FTP) is a network protocol to transfer data from one computer to another through a network, such as over the Internet.

FTP is a file transfer protocol for exchanging files over any TCP/IP based network to manipulate files on another computer on that network regardless of which operating systems are involved (if the computers permit FTP access). There are many existing FTP client and server programs. FTP servers can be set up anywhere between game servers, voice servers, internet hosts, and other physical servers.