Hi, Iljitsch, [I'm responding only to those parts that correspond to my tsv-dir review]
On 06/27/2011 01:17 PM, Iljitsch van Beijnum wrote: > 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. Works for me. :-) -- If you have an external document with more data about this experiment, it might eb good to provide a link to it. >> * 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? * http://nmap.org/hobbit.ftpbounce.txt * http://www.cert.org/advisories/CA-1997-27.html * http://cr.yp.to/ftp/security.html * IETF RFC 2577 > 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. The point is that proxy FTP is not supporting in the FTP software I checked. >> * 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 Well, *TCP* does not state what should be done with the urgent data, since it doesn't know what's the application on top. But if you ignore urgent indications, you won't be able to interrupt ongoing commands (e.g. RETR). -- so my take is that this is important for FTP. Unfortunately, as noted in RFC6093, some middleboxes already play with urgent indications. BUt if you deliberatly ignore it, this would exacerbate the problem. >> 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? My understanding is that the implications of this is that you no longer will be able to abort commands (head of line blocking). >> * 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. Ok... I thought it was the wording of your explanation (RFC-Ed seems to prefer "can't" -> cannot "you're" -> "you are", etc.) (FWIW, I've omitted responses to comments that you've already addresses and that needed no further discussion). Thanks! Best regards, -- Fernando Gont e-mail: [email protected] || [email protected] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
