Ftp-WG: FTP Data Connection Assurance

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 protected]
http://www.hethmon.com