On 29/01/2014 9:24 a.m., Alex Rousskov wrote: > On 01/25/2014 06:05 PM, Amos Jeffries wrote: >> On 25/01/2014 9:27 a.m., Alex Rousskov wrote: >> >>> I propose to limit squid.conf "ftp_epsv off" prohibition to IPv4 FTP >>> servers. > ... >>> Do you think it would be OK to allow the use of EPSV commands with IPv6 >>> servers even if ftp_epsv is off? > > >> "off" should never be abused to mean half-off. We are having enough >> trouble with "forwarded_for off" historically meaning something other >> than disable XFF feature. > > The problem here is that the directive itself was misnamed IMO. It > should have been ftp_epsv_for_ipv4 or similar.
It is named correctly for its scope of "whether to send EPSV command in FTP". >> I think extending the directive to allow selective disabling with >> no-ipv6 or no-ipv4 values would be better. > > I do not like negative names so I would suggest "ipv6" instead of "no-ipv4". > Fine. Up to you as implementer. Though these extensions are supposed to be protocol agnostic FTP commands and that means future addressing types will put admin who use "ipv6" at a disadvantage by default-off instead of default-attempt for any new connection types we add. > However, what should Squid do when it is talking to an IPv6 server and > ftp_epsv is "off" or "ipv4"? Does it really make sense to write more > code to handle that essentially misconfigured (but inherited from the > old configs) case? I doubt... > When talking to an IPv6 server with ftp_epsv "off" or "ipv4" the expected behaviour is that Squid uses active-FTP immediately (EPRT command) without even trying the passive connection first. > > How about this alternative: > > 1. Add ftp_epsv_for_ipv4 on/off. > 2. Deprecate ftp_epsv in favor of the newly added ftp_epsv_for_ipv4. > 3. Treat ftp_epsv on/off as ftp_epsv_for_ipv4 on/off. > > This would avoid writing useless code to handle misconfigurations > because it would be impossible to misconfigure Squid in this area. It is not an isolated command, but one of a set of 5 connection possibilities. The commands permutations are attempted as follows, any one command may be skipped by a matching squid.conf directive, first to succeed wins: * contacting IPv4 server EPSV ALL - skipped when ftp_passive off, ftp_epsv_all off, ftp_epsv_all ipv6 - default is skip due to broken NATs and lack of failover possibilities. EPSV <port> - skipped when ftp_passive off, ftp_epsv off, ftp_epsv ipv6 - default to attempt since failover is easy and IPv6 benefits outweight the RTT cost. PASV - skipped when ftp_passive off - default to attempt due to RFC requirements EPRT <ipv4> - skipped when ftp_eprt off - default to attempt since failover is easy and IPv6 benefits outweight the RTT cost. PORT <ipv4> Send Failed connection error to client * contacting IPv6 server EPSV ALL - skipped when ftp_passive off, ftp_epsv_all off, ftp_epsv_all ipv4 - default is skip due to broken NATs and lack of failover possibilities. EPSV <port> - skipped when ftp_passive off, ftp_epsv off, ftp_epsv ipv4 - default to attempt PASV - not possible. always skipped. EPRT <ipv6> - skipped when ftp_eprt off - default to attempt (unless patched by RHEL to send EPSV again) PORT - not possible. always skipped. Send Failed connection error to client PS. ftp_eprt and ftp_epsv_all could do with matching updates. HTH Amos
