Re: [BEHAVE] FW: Last Call: <draft-ietf-behave-ftp64-10.txt> (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard

[Iljitsch van Beijnum <[e-mail]>]

FTP ALG implementers: please respond if you have an opinion, some stuff below may make your life harder! (This is a response to two different messages.)

On 3 jun 2011, at 14:06, David Harrington wrote:

> Can you address these issues?
> Do you have any other comments you know of that need to be included in
> a new rev?

There were three reviews. See below for two, I'm trying to clear something up about the other more directly.

On 30 mei 2011, at 11:10, Pekka Savola wrote:

> This is an ops-dir review of draft-ietf-behave-ftp64-10.

> substantial comments
> --------------------

> The document does not mention or discuss LPRT and LPSV. Is that intentional?
> The IANA registry says these are now obsolete, but RFC1639 is still
> experimental and no document has (formally) obsoleted these.

I managed to overlook RFC 1639, and it wasn't brought up by anyone else during the process. Apparently wu-ftpd implements this and curl used to, but both failed to see any real-world usage so I think we can ignore this without creating problems.

>   Telnet option negotiation attempts by either the client or the
>   server, except for those allowed by [RFC1123], MUST be rejected by
>   the FTP ALG without relaying those attempts.  This avoids the
>   situation where the client and the server negotiate Telnet options
>   that are unimplemented by the FTP ALG.

> ... what does "rejected" mean exactly?  Does the ALG send back to
> the negotiation attempter some error code?  Does it abort the connection?
> ignore these options?  strip them out when connecting to the other end?

What I had in mind was reply with a "DON'T". Is this text more clear?

  Telnet option negotiation attempts by either the client or the
  server, except for those allowed by [RFC1123], MUST be rejected by
  the FTP ALG without relaying those attempts. For the purpose of
  Telnet option negotiation, an FTP ALG MUST follow the behavior of
  an FTP server as specified in [RFC1123] section 4.1.2.12. This...

That section says:

         4.1.2.12  Connections: RFC-959 Section 5.2

            The words "and the port used" in the second paragraph of
            this section of RFC-959 are erroneous (historical), and they
            should be ignored.

            On a multihomed server host, the default data transfer port
            (L-1) MUST be associated with the same local IP address as
            the corresponding control connection to port L.

            A user-FTP MUST NOT send any Telnet controls other than
            SYNCH and IP on an FTP control connection. In particular, it
            MUST NOT attempt to negotiate Telnet options on the control
            connection.  However, a server-FTP MUST be capable of
            accepting and refusing Telnet negotiations (i.e., sending
            DONT/WONT).

            DISCUSSION:
                 Although the RFC says: "Server- and User- processes
                 should follow the conventions for the Telnet
                 protocol...[on the control connection]", it is not the
                 intent that Telnet option negotiation is to be
                 employed.

> 8. Default port 20 translation

>   If the client does not issue an EPSV/PASV or EPRT/PORT command prior
>   to initiating a file transfer, it is invoking the default active FTP
>   behavior where the server sets up a TCP session towards the client.
>   In this situation, the source port number is the default FTP data
>   port (port 20) and the destination port is the port the client uses
>   as the source port for the control channel session.

> .. is it?  I thought the source port used by the server is orthogonal to
> whether pasv/port is issued.  AFAIK, multiple FTP server implementations
> never use port 20.  But I have not recently tested this myself.

RFC 959:

   3.2.  ESTABLISHING DATA CONNECTIONS

      The mechanics of transferring data consists of setting up the data
      connection to the appropriate ports and choosing the parameters
      for transfer.  Both the user and the server-DTPs have a default
      data port.  The user-process default data port is the same as the
      control connection port (i.e., U).  The server-process default
      data port is the port adjacent to the control connection port
      (i.e., L-1).

>   The ALG MUST enable or disable EPSV to PASV translation as requested.
>   If EPRT to PORT translation is supported, ALGS ENABLE64 SHOULD enable
>   it and ALGS DISABLE64 SHOULD disable it along with enabling or
>   disabling EPSV to PASV translation, respectively.  If EPRT to PORT
>   translation is not supported, ALGS ENABLE64 only enables EPSV to PASV
>   translation.

> .. what does this SHOULD..along with.. mean?  I read it so that it's OK
> that for "ALGS DISABLE64" EPSV->PASV is disabled but EPRT->PORT is not
> disabled?  A different way to read it would be that both EPSV->PASV and
> EPRT->PORT are SHOULDs.

I think what it says is that it's optional to disable PORT->EPRT upon DISABLE64. Enabling is optional because the feature is optional, but I guess if you have the feature disabling should be mandatory, so SHOULD->MUST:

  The ALG MUST enable or disable EPSV to PASV translation as requested.
  If EPRT to PORT translation is supported, ALGS ENABLE64 MUST enable
  it and ALGS DISABLE64 MUST disable it along with...

Agree?

>   A survey done in April of 2009 of 25 randomly picked and/or well-
>   known FTP sites reachable over IPv4 showed that only 12 of them
>   supported EPSV over IPv4.

> .. fwiw, Dan Wing redid this test on 18 May 2011, reporting on behave list.
> the results didn't differ much (I didn't look at the numbers), but if you
> want to update this, now would be the chance.

I don't see the need to.

> If
>   such a multi-purpose ALG forbids the use of the AUTH command for
>   policy reasons, the side effect of making the ALG stop performing the
>   translations described here, as well as other possible interventions
>   related to IPv6-to-IPv4 translation, MUST be retained even if the ALG
>   responds to the AUTH command with an error and does not propagate the
>   command to the server.

> .. I had a hard time following what this one sentence includign a MUST
> actually requires.  Maybe break down to more easily digestible sentences?

What about this:

If such a multi-purpose ALG forbids the use of the AUTH command for
policy reasons, the side effect of the AUTH command as described in this
document MUST be retained. In other words, if the ALG does not propagate the AUTH command to the server, the ALG MUST still stop all possible interventions related to IPv6-to-IPv4 translation. This is true for the remaining duration
of the control channel session, and applies even if the ALG
responds to the AUTH command with an error.

>   [Bernstein]
>              Bernstein, D., "PASV security and PORT security", 2000,
>              <http://cr.yp.to/ftp/security.html>.

> .. this reference is not cited in the doc, add or remove?

I'll remove it.


On 4 jun 2011, at 0:16, Fernando Gont wrote:

> I've reviewed this document as part of the transport area directorate's
> ongoing effort to review key IETF documents.


> * Section 1, page 3:
>   In 5 cases, issuing the EPSV
>   command to the server led to a significant delay, in 3 cases followed
>   by a control channel reset.

> Could you please clarify what was the cause of the delay? And, btw, have
> you guys put the details of your results publicly available somewhere?

What about the following text:

Due to lack of additional information, it is impossible to determine conclusively why certain FTP servers reset the control channel connection some time after issueing an EPSV command. However, a reasonable explanation would be that these FTP servers are located behind application-aware firewalls which monitor the control channel session and only allow the creation of data channel sessions to the ports listed in the responses to PASV (and maybe PORT) commands. As the response to an EPSV command is different (a 229 code rather than a 227 code), a firewall that is unaware of the EPSV command would block the subsequent data channel setup attempt, after which the FTP server may decide to terminate the control channel session which isn't progressing the way it should.

> * Section 1, page 3-4:
>   Clients that want to engage in more complex behavior, such as server-
>   to-server transfers, may make an FTP application layer gateway (ALG)
>   go into transparent mode by issuing AUTH or ALGS commands as
>   explained in Section 5.

> I thought server-to-server transfer had been banned for many years now
> (it was exploited for address scan purposes). Am I missing something?

Do you have a reference?

As it's only listed here as an example of something that isn't addressed, I don't think it's an issue to include this here.

> * Section 5:
>   In the second case, an implementation MUST have the ability to track
>   and update TCP sequence numbers when translating packets as well as
>   the ability to break up packets into smaller packets after
> [....]

> What about the TCP URG flag and the Urgent Pointer? FTP is one of the
> few legacy applications that make use of TCP's urgent mode. And while
> use in new applications is deprecated, and TCP urgent mode itself is
> unreliable (see RFC 6093), you should make an explicit decision about
> what to do with TCP urgent mode when used for the FTP control channel.

The word "urgent" isn't mentioned in RFC 959 or the FTP-related part of RFC 1123. But RFC 959 does mention using the Telnet SYNCH signal, which involves using urgent data. However, it looks like it's legal to ignore the urgent pointer, from RFC 793:

  TCP also provides a means to communicate to the receiver of data that
  at some point further along in the data stream than the receiver is
  currently reading there is urgent data.  TCP does not attempt to
  define what the user specifically does upon being notified of pending
  urgent data, but the general notion is that the receiving process will
  take action to process the urgent data quickly

> When packets are translated individually, the ALG should update the
> Urgent Pointer if/where necessary. If the ALG terminates the IPv6 TCP
> session, there's the question of whether urgent mode should be "copied"
> from the IPv6 session to the IPv4 session.

I think it's not worth the trouble and unlikely to be tested well, so I would be in favor of clearing the URG flag. Any objections?

> * Section 5.1, page 7:
> For the time being, ALG implementations may employ
>   one of the following strategies regarding LANG negotiation

> Should you s/may/MAY/?

Not really. I'll see what the RFC Editor says.

> * Section 5.1, page 8:
>   3.  Block LANG negotiation by translating the LANG command to a NOOP
>       command, and translating the resulting 200 response into a
>       response appropriate for unsupported commands, such as 500.  Text
>       is sent in the default language.

> I think you should mandate which exact code the 200 should be translated
> to, rather than just provide an example.

Let's make it a 502 then.

>   The File Transfer Protocol (FTP) has a very long history, and despite
>   the fact that today, other options exist to perform file transfers,
>   FTP is still in common use.

> Remove the comma between "today" and "others"

Ok.

>   translators
>   are used to bridge that gap, FTP is made to work through these
>   translators as best it can.

> s/as best as it can/to the best possible extent/?

Why not.

> * Section 5.1 (page 7) and elsewhere:
>   So the situation where the client and server try to
>   negotiate a language that the ALG doesn't support can't be avoided.

> Expand doesn't to "does not", "can't" to "cannot", etc.

Hm, the 425 code has "can't" in it. I'll leave this open and see what the RFC Editor says.

> * Section 5.1, page 8:
>   Note that [RFC2640] section 3.1 specifies new handling for spaces and
>   the CR character in path names.

> Rephrase to "Note that Section 3.1 of [RFC2640]..."

I adopted the word order but not the capitalization.

> * Section 11, page 12:
>   ALGs MUST support the new ALGS (ALG status) command that allows
>   command MUST be passed on to the server without modification, and the
>   clients to query and set the ALG's status.

> I had trouble parsing this sentence.

This is the text that is in -10:

  ALGs MUST support the new ALGS (ALG status) command that allows
  clients to query and set the ALG's status.  FTP servers (as opposed
  to ALGs) MUST NOT perform any actions upon receiving the ALGS
  command. FTP servers MUST still send a response, however.
  If FTP servers recognize the ALGS command, the best course
  of action would be to return a 202 response:

Apparently two lines got lost at your end.

> * Section 11, page 12:
>   A client can use the ALGS command to request the ALG's status and to
>   enable and disable EPSV to PASV and, if implemented, EPRT to PORT
>   translation.

> Please rephrase to "...disable EPSV to PASV translation and, if
> implemented, EPRT to PORT translation".

Ok.

Both of you, thanks for the reviews.