|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" <[email protected]> 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 >[email protected] >https://www.ietf.org/mailman/listinfo/behave
