Shutting down FTP services
kernel.org
kernel.org
>>The protocol is inefficient and requires adding awkward kludges to firewalls and load-balancing daemons
I have always been aware that ftp across firewalls can be wonky, but never stopped to ask why.
http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html
>>The primary problems that the FTP poses to firewalls, NAT devices, and load-balancing devices (all of which will simply be referred to as Ârouting devices and not "routers" since gateway machines generally aren't problematic) are:
>>Additional TCP/IP connections are used for data transfers;
>>Data connections may be sent to random port numbers;
>>Data connections may originate from the server to the client, as well as originating from the client to the server;
>>Data connections destination addresses are negotiated on the fly between the client and server over the channel used for the control connection;
>>The control connection is idle while the data transfer takes place on the data connection.
What a protocol.
What is the most reliable for NAT traversal for all of the various implementations?
As for NAT traversal, p2p protocols would obviously suffer the same issues but anything with a stronger client / server relationship would fair much better. Something like SFTP is a better alternative to FTP in those instances.
1) FTP predates widespread usage of compressed file formats by quite a long time. JPEG, MPEG formats (MP3, AVI, etc), ZIP archived XML documents formats (OOXML, ODF, etc), they're all comparatively new in relation to FTP. GIF is much older than the above but still more than a decade older than FTP and frankly GIF wasn't even that widely used pre-WWW where as uncompressed bitmaps like BMP and PCX were common place. However a lot of text files were copied around in the early days of FTP (hence why FTP has an ASCII transfer mode in addition to binary) and given the modem speeds of the era, compression would have really helped - albeit it's questionable whether the machines were powerful enough to do real time deflating even against text files. That isn't so much a problem these days so it's well worth having compression built into the protocol if just to catch that extra 5%. Even if you think you don't care as an end user, it matters to us sysadmins hosting high traffic servers :)
2) TCP does have a CRC-32 checksum but that doesn't help against failed downloads, memory or other hardware errors etc. A lot of more modern protocols will compare a source and destination hash of each chunk of data and/or the completed file to ensure that the two copies are identical. Frankly, I wouldn't trust FTP for archiving data for that reason alone.
Where?
TCP has a checksum in the header, but it is neither 32 bits nor is it a CRC.
As a reference, I could usually read a text file faster than 2400 baud (roughly 240 characters per second) but not faster than 2400 baud with V.42bis compression.
For failed downloads, memory errors, and so on, a hash in the protocol isn't that helpful. You really do want a whole- filled hash check after the file is written persistently. (TCP's checksum is a performance optimization, although it doesn't work very well with wireless networks.)
P.s. "wools"? Stupid android keyboard.
I'd forgotten about FTP predating TCP though. Good point.
FTP has an ascii transfer mode because operating systems have different line endings and this automatically translates for them.
Indeed they did. But that was when the majority of users were technicians. These days we need a protocol for layman.
> FTP has an ascii transfer mode because operating systems have different line endings and this automatically translates for them.
I know, I left that part you because it wasn't relevant to my point but I'm glad you raised it as it's another feature that isn't necessary these days because, aside Notepad.exe, every text editor on the planet can handle different line endings. Thus ASCII mode is just another point to break files for inexperienced users (I'm not really happy with the kludge that some clients use either; by using the file extension to guess the correct method of transport)
The FTP standard (RFC959) actually includes RLE compression (see section 3.4.3).
(Almost no one implements it, since RLE is a pretty poor compression algorithm.)
NAT came along, and everyone broke everything. Now you can't make up neat protocols like this any more - everything must be user-initiated TCP or server based. I do wonder how much development and innovation this has held back. Even games back in the day had far more interesting network models - that were more sustainable long-term.
NAT was likely the first major crack in the wall of the open Internet, making it much weaker and the users more compliant than it previously was. I strongly believe that's one of the major reasons why we have what we're left with today.
Simple packet-filtering firewalls invented in 1988.
In addition you can force passive mode and confine FTP to a range of ports on just about every server and client out there. So your statement that FTP "flat out does not work" is untrue, unless you mean that your firewall is so much default-deny that you cannot even open incoming ports.
However, while it makes me a bit sad, I have to agree that there are better, simpler and more secure protocols now for downloading files. HTTP/2 in particular.
I'm surprised to see WebDAV mentioned here, to be honest, I thought it was a dead horse everywhere except in enterprise.
The modern web is much more about routes, resources, and URLs than directories and files.
FTP is a pretty conceited protocol, and one that deserves to go away. People say it made more sense in the 80's, but I was there and even then *NIX/Solaris admins found FTP to be about as much fun as that IRC pingback identd service; which is to say not very fun.
Of course this awesome ability was exploited by hackers (the FTP Bounce Attack: https://www.cert.org/historical/advisories/CA-1997-27.cfm - and they say that inventing fancy names for attacks is a new thing). This is why we can't have nice things :-)
I understand the argument for peer-to-peer gaming, but I don't see why for file transfer, FTP's design is better.
The big difference I see is that a separate TCP connection has separate flow control and avoids head-of-line blocking for multiple simultaneous transfers, but for static file transfers, the only cause of head-of-line blocking should be actual congestion, which would impact every connection simultaneously, right? (That is, it's better for the Internet to route all traffic between two hosts, where neither side is CPU-bound, over a single TCP connection so that TCP can do its thing.)
And certainly active mode (server connects back to client) doesn't seem like it has any benefits to congestion or anything else: once a connection is established, it doesn't matter who established it.
One file per connection also makes the implementation simpler. If you want to use one TCP connection for multiple transfers then you need some kind of a header and logic to determine start and end of file, and new control messages get delayed in queue behind already-buffered data. If you have a data connection for exactly one file then you just call sendfile() and then close().
And transferring a file with active mode FTP looks like this:
Client -> Server: I want to transfer a file, connect to 1.2.3.4:12345.
Server -> Client: TCP SYN to 1.2.3.4:12345
Client -> Server: I want to transfer a file, passive mode.
Server -> Client: OK, connect to 4.3.2.1:54321.
Client -> Server: TCP SYN to 4.3.2.1:54321
It's possible to run FTP over TLS. Hardly anybody does that because it makes the NAT problem worse, because then the NAT device can't even snoop the control connection and map the port. FTP programs could fix this by mapping the data port using something like NAT-PMP or PCP, but I'm not aware of any that currently do.
https://openconnect.netflix.com/publications/asiabsd_2015_tl...
edit: check this post first
Only in (very) high-bandwidth cases and (maybe!) for low-power cases. For most things it's just added complexity for no benefit.
A typical session looks like:
$ telnet ftp.kernel.org 21
Trying 149.20.4.69...
Connected to ftp.all.kernel.org.
Escape character is '^]'.
220 Welcome to kernel.org
USER anonymous
331 Please specify the password.
PASS
230 Login successful.
PASV
227 Entering Passive Mode (149,20,4,69,119,142).
So, on the second terminal I run:
$ telnet 149.20.4.69 30606
Trying 149.20.4.69...
Connected to 149.20.4.69.
Escape character is '^]'.
LIST
150 Here comes the directory listing.
226 Directory send OK.
drwxr-xr-x 9 ftp ftp 4096 Dec 01 2011 pub
Connection closed by foreign host.
$
Cheers.
this reminds me how some companies such as Nestle use term "chocolate candy" because in order to call it a chocolate, it actually needs to be a chocolate :)
>>>Additional TCP/IP connections are used for data transfers;
>>>Data connections may be sent to random port numbers;
>>>Data connections may originate from the server to the client, as well as originating from the client to the server;
>>>Data connections destination addresses are negotiated on the fly between the client and server over the channel used for the control connection;
>>>The control connection is idle while the data transfer takes place on the data connection.
>What a protocol.
These behaviors thought allows things like FXP, where you can actually transfer files from one FTP server to another without it having to go through you (this is especially useful when those FTP servers are on a fast connection, but you're not).
The part about using random ports, is half truth, by default transfers were happening on port 20. This port was opened on the client (to avoid mix-ups when multiple users are accessing the same server) and server connected to it.
As NAT was introduced this (an in fact NAT made a lot of things difficult, I'm glad IPv6 doesn't have NAT) became difficult so a PASV (passive) mode was introduced, where the server picked a random port and waited for client to connect to it.
The passive mode made firewalling a bit harder, but not that difficult. As an admin you could control the range of ports used by the server, also firewalls such as IPFilter had built-in FTP proxy[1]. It's also possible to do this in other firewalls but it might require an external ftp proxy rules.
[1] http://www.freebsdwiki.net/index.php/IPFILTER_(IPF)_Firewall...
On top of that there's never been a coherent standard for what directory listings are supposed to look like so there's no reliable way to emit directories in a machine readable format. It's always been arbitrary text.
The whole thing is junk and has deserved to die the day it was born.
Really, the problem is that NAT is a terrible idea and screws up the idea of a fully end-to-end Internet.
This is some weird astroturfing of the FTP protocol's goodwill, but it was never particularly good. Even for its time it's a curiously conceited protocol that is remarkably complicated without doing very much that a similarly intelligent RMI-style interface couldn't have worked with.
And in practice, many FTP clients basically left the control channel concept behind and began to use it as if it were streamed RMI, opening up multiple connections for transfers to help users deal with even 1980's network environments.
It stands out as complicated for its time.
\\live.sysinternals.com\tools says Hi
Just because it doesn't make sense to you, does not make it stupid.
Now they want to discontinue FTP. Two different things.