Subject: [ftpext] 1st post; miscellaneous FTP additions.

From: "Alun Jones" <[email-masked]>
Date: Sat, 6 Nov 2010 14:48:03 -0700

First, thanks to everyone here for starting up another FTP extensions
Working Group. I enjoyed the last one and look forward to hearing much more
on the ways we can move FTP forward.

Having read the mailing list archives to date, here are a relatively random
list of observations:

1.       I found this mailing list through a rather random reading of the
IETF mailing list. Pure chance. Should this WG perhaps reach out to members
of the previous WG's mailing list to let them know that there is a new WG to
which they might wish to subscribe? [Or was there an announcement that I
simply missed?]

2.       I would very much like to see us address not only new and
interesting features, but some of the issues that cause enterprises to avoid
using FTP. Particularly, I note that there's a perception that FTP is
unsecure, that it's not standard (peculiarly enough, SFTP is given as the
standard alternative, despite not actually having any standards
documentation), that it's inefficient (not sure what is meant by that), that
it requires massive firewall holes, and that it frequently fails through
firewalls even if you think you have the right holes open. To that end:

a.       I would like to suggest the use of MODE B with the default data
port as common practice. In the absence of errors in communication, or
client-requested aborts, this works well through existing firewalls, as well
as with TLS, is portable to IPv6, has been a standard since at least RFC 959
days, and only requires that clients request and support MODE B as an
option. Some steps to improve this would include:

                                                               i.
Document how MODE B should recover from client-requested aborts, even if the
recovery is simply "close all connections and try again".

                                                             ii.
Augment MODE B - for instance, specify options to state that TYPE I, STRU F,
can avoid sending REST markers in the data stream.

b.      Where port assignments are made, use random port assignments as
specified in the recent BCP draft
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-randomization/ to
improve protection against port guessing. Are there any standard protocols
to use to open firewall holes in relation to existing traffic? UPnP springs
to mind, but if there are any other protocols we could use as FTP server /
client authors to open these ports (or avoid having to), it is important
that we document the use of these for FTP.

c.       To address storage security of transferred files, it may be
appropriate to add commands and responses for the following cases:

                                                               i.
Client requests that server receive next STOR / STOU as sensitive file, and
stores it in encrypted storage (with affirmative response if it can do this)

                                                             ii.      Server
refuses to send file in response to RETR until client asserts that it will
be storing it in encrypted storage.

3.       It was suggested earlier in the mailing list that a command be
provided for encrypting passwords in transit in some way. While I agree with
the general sentiment that TLS should be used for such cases (because the
password is generally only sensitive because of the data it protects, and
therefore the commands and data should be encrypted and integrity-protected
also), there is, or was, a standard for SASL passwords in FTP - I simply
can't find it right now.

4.       Keeping firewalls open through long data transfers can adequately
be achieved using the NOOP command at regular intervals, or if that command
is not supported, the STAT command, which is already documented to give a
user-readable status during a data transfer.

5.       GSSAPI FTP as defined in RFC 2228 should be deprecated, as it does
not provide for separate encryption contexts between the command and data
ports - because they share an encryption context, if a command is sent
during a transfer, the synchronization is lost, and all further data and
commands are garbled and unreadable.

6.       FTP URIs don't work as documented. I have yet to see a single
client implementation that treats "ftp://example.com/foo" as an invitation
to connect to example.com and issue the "CWD foo" command - they all issue
"CWD /foo". Clinging to ancient documentation that is always ignored seems
to be a waste of time. Deprecate the old behaviour, and as crappy as it may
be, adopt and accept the behaviour that "all paths are from the root unless
they begin with a dot. (ftp://example.com/./foo)"

Well, that's enough to be getting on with - let me know if any of these
ideas are worth considering, or should be discarded immediately.

Thanks again for setting this list up,

Alun Jones

[Author, WFTPD and WFTPD Pro - http://www.wftpd.com]

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 7 Nov 2010 19:29:33 +0100 (CET)

> appropriate to add commands and responses for the following cases:

I must say that I'm very skeptical about such peculiar and specific commands, 
and if you want to move ahead and suggest those they should be in a separate 
draft imho.

> 4.  Keeping firewalls open through long data transfers can adequately be 
> achieved using the NOOP command at regular intervals, or if that command is 
> not supported, the STAT command, which is already documented to give a 

Sorry, but I've tried this and it turned out that is not a reliable way to 
keep a connection alive. Several FTP server implementations just don't read 
the control connection while the data is being transfered.

We got better functionality by simply using the TCP KEEPALIVE option and 
setting the timers small enough (on the systems that allow that sort of 
configurability).

> commands are garbled and unreadable.

We can't just deprecate it because it one or more flaws if there are still 
users of that protocol in the wild. Can we?

> "CWD /foo".

What are you talking about? curl has done "CWD foo" since 1998 and I would 
strongly disagree to changing that URI definition at this point.

If I remember things correctly, there's a flaw in how empty path parts are 
supposed to be handled, as in ftp://example.com/foo//bar.

-- 

  / daniel.haxx.se

---

From: Anthony Bryan <[email-masked]>
Date: Sun, 7 Nov 2010 17:08:29 -0500

On Sat, Nov 6, 2010 at 5:48 PM, Alun Jones <[email-masked]> wrote:
> of the previous WG’s mailing list to let them know that there is a new WG to

hi, Alun, welcome!

that's a good idea, we should invite the previous members. (this isn't
quite a WG yet, but things should be finalized one way or another in
about 2 weeks).

there is talk of possible work on an "FTP in the 21st century" draft
and also a FTP URI scheme draft. these could address some of your
other issues.

from the draft charter http://www.ietf.org/iesg/evaluation/ftpext2-charter.txt

* Investigate the differences between FTP in theory
 (current RFCs) and practice, and recommend future work to align them.
 Any future work would require rechartering of the WG.

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads