Re: [RFC] ignore ftp_epsv off for IPv6

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
Received on Wed Jan 29 2014 - 04:29:43 MST