Please Whitelist This Site?

I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)

If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.

If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.

Thanks for your understanding!

Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide


NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The Book is Here... and Now On Sale!

Read offline with no ads or diagram watermarks!
The TCP/IP Guide

Custom Search







Table Of Contents  The TCP/IP Guide
 9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)
      9  TCP/IP Key Applications and Application Protocols
           9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)
                9  TCP/IP General File Transfer Protocols (FTP and TFTP)
                     9  File Transfer Protocol (FTP)
                          9  FTP Concepts and General Operation

Previous Topic/Section
FTP Control Connection Establishment, User Authentication and Anonymous FTP Access
Previous Page
Pages in Current Topic/Section
123
4
Next Page
FTP General Data Communication and Transmission Modes
Next Topic/Section

FTP Data Connection Management, Normal (Active) and Passive Data Connections and Port Usage
(Page 4 of 4)

Efficiency and Security Issues In Choosing a Connection Method

This leaves one nagging question, of course: who cares? J I already said that in either case, the data transfer can go in both directions. So what does it matter who initiates the data connection? Isn't this like arguing over who makes a local telephone call?

The answer is related to the dreaded “S word”: security. The fact that FTP uses more than one TCP connection can cause problems for the hardware and software that people use to ensure the security of their systems.

Consider what is happening in the case of an active data connection as described in the example above. From the perspective of the client, there's an established control connection from the client's port 1678 to the server's port 21. But the data connection is initiated by the server. So the client sees an incoming connection request to port 1678 (or some other port). Many clients are suspicious about receiving such incoming connections, since under normal circumstances clients establish connections, they don’t respond to them. Since incoming TCP connections can potentially be a security risk, many clients are configured to block them using firewall hardware or software.

Why not just make it so the client always accepts connections to the port number one above the ephemeral number used for the control connection? The problem here is that clients often use different port numbers for each transfer by using the PORT command. And why is this done? Because of the rules of TCP. As I describe in the section on TCP, after a connection is closed, a period of time must elapse before the port can be used again, to prevent mixing up consecutive sessions. This would cause delays when sending multiple files one after the other, so to avoid this, clients usually use different port numbers for each transfer. This is more efficient, but means a firewall protecting the client would be asked to accept incoming connections that appear to be going to many unpredictable port numbers.

The use of passive connections largely eliminates this problem. Most firewalls have a lot more difficulty dealing with incoming connections to odd ports than outgoing connections. RFC 1579, Firewall-Friendly FTP, discusses this issue in detail. It recommends that clients use passive data connections by default instead of using normal connections with the PORT command, to avoid the port-blocking problem.

Of course, passive data connections don't really eliminate the problem, they just push it off onto servers. These servers now must face the issue of incoming connections to various ports. Still, it is, generally speaking, easier to deal with security issues on a relatively smaller number of servers than a large number of clients. FTP servers must be able to accept passive mode transfers from clients anyway, so the usual approach is to set aside a block of ports for this purpose, which the server's security provisions allow to accept incoming connections, while blocking incoming connection requests on other ports.

Note: As an aside, it is that it is a significant violation of the layering principle of networks to pass IP addresses and port numbers in FTP commands such as PORT and PASV and the replies to them. This isn’t just a philosophical issue: applications aren't supposed to deal with port numbers, and this creates issues when certain lower-layer technologies are used. For example, consider the use of Network Address Translation, which modifies IP addresses and possibly port numbers. In order to prevent NAT from “breaking” when FTP is used, special provision must be made to handle the protocol.


Key Concept: FTP supports two different models for establishing data connections between the client and server. In normal, or active data connections, the server initiates the connection when the client requests a transfer, and the client responds; in a passive data connection, the client tells the server it will initiate the connection, and the server responds. Since TCP is bidirectional, data can flow either way in both cases; the chief difference between the two modes has to do with security. In particular, passive mode is often used because many client devices today are not able to accept incoming connections from servers.



Previous Topic/Section
FTP Control Connection Establishment, User Authentication and Anonymous FTP Access
Previous Page
Pages in Current Topic/Section
123
4
Next Page
FTP General Data Communication and Transmission Modes
Next Topic/Section

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $



Home - Table Of Contents - Contact Us

The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005

© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.