Subject: Ftp-WG: FTP Data Connection Assurance

From: Marc Huber <[email-masked]>
Date: Tue, 25 Jun 2002 07:15:44 -0500

The list has been pretty silent wrt. Gregory Lundbergs
draft-ftpext-data-connection-assurance-00.txt. This is
definitely worth reading and has the potential to solve
one of the long-standing FTP security issues.

Looking at chapters "3. PASSIVE ESTABLISH (ESTP)" and
"D.2 Automatically Finding the Specified Connection",
there are two distinct operation modes for ESTP:

Either
- the server ignores the argument and accepts the first
  connection
or
- the server honors the argument and accepts the matching
  connection

That behavior should to some extent be controllable by the
client. How about a slightly changed definition for ESTP
that makes the argument optional? E.g.:

  If the argument to ESTP is omitted, the server should
  accept the first connection from the listen queue and
  reply with a suitable 225 code (or 4xx/5xx on error).
  
  If the argument is present, the server may either
  - search the listen queue for the matching connection,
    accept it and reply with a 225 code (or 4xx/5xx on
    error/not found),
  or
  - ignore the argument, accept the first connection
    and return 225 (4xx/5xx on error).

For ESTP error recovery, I don't agree with making ABOR
dependant on the session context. I'd very much prefer:

  If the client detects a mismatch it may send an ABOR,
  followed by PASV/LPSV/EPSV to establish a new connection.
  It should not be expected that any socket related to the
  data connection survives ABOR.

"D.3 Using a Common Passive Socket" will obviously work
if all clients are ESTP compliant (and the server enforces
ESTP). In a mixed environment (ESTP clients and legacy
clients) however, an ESTP capable client would have to
announce that capability ("OPTS ESTA ...") to the server
before any PASV command is issued, and the server would
have to enforce usage of ESTP by this client. And from
a NAT/firewalling point of view, a common data socket in
a mixed environment doesn't give any advantage.

Marc

===================END FORWARDED MESSAGE===================

Paul Hethmon
[email-masked]
http://www.hethmon.com

---

From: "Gregory A Lundberg" <[email-masked]>
Date: Tue, 25 Jun 2002 17:56:25 -0500

> client.

My original vision was that the server ignore the argument because it really
is not needed.

I added the argument because I realized the server _could_ make use of it.
I don't however, see that the client need be aware of that or have any input
into it.

> How about a slightly changed definition for ESTP

I don't have a problem with making the ESTP argument optional.

>   data connection survives ABOR.

I don't see ABOR as being state dependant.  Except for the unnecessary and
misleading discussion of ABOR relative to EPSV in RFC 2428, the workings of
the ABOR command in the FTP have to do with the established data connection.
All I'm suggesting is, in this case, a natural use of the ABOR command with
respect to the ESTA/ESTP commands.

> a mixed environment doesn't give any advantage.

Well, I'm not sure the user could or should be expected to announce the
support of ESTA/ESTP, but you're correct that in a mixed environment, it
does not help the firewall rules.

The fact of the matter, though, is that I put D.3 in because it's the
logical end-point of the reasoning. I honestly do not expect it will ever
prove workable, but unless someone puts the idea out, nobody will look at it
and prove me wrong.