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

[Rockson Li <[e-mail]>]

|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.


[RL] It looks like sec 2.5 of RFC5797 has obsoleted those two commands.


Regards,
-Rockson

On 6/28/11 12:17 AM, "Iljitsch van Beijnum" <[e-mail]> wrote:

>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.
>_______________________________________________
>Behave mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/behave