Re: [RFC] ignore ftp_epsv off for IPv6

On 01/28/2014 09:29 PM, Amos Jeffries wrote:
> On 29/01/2014 9:24 a.m., Alex Rousskov wrote:
>> On 01/25/2014 06:05 PM, Amos Jeffries wrote:
>>> "off" should never be abused to mean half-off.

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

OK, then its scope is wrong. There should not be an option to enable or
disable a required command; EPSV (or EPRT) are required for IPv6 servers
to work.

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

Whether default-off is more advantageous than default-attempt depends on
the consequences of those attempts. Today, the consequences of
default-attempt are already bad for IPv4 in many cases. However, this
thread is not about the arguably wrong defaults.

If "future addressing types" require more complex expressions, we should
switch to ACLs that can express both positive and negative conditions
equally well.

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

I assume EPRT is similarly disabled, of course. The two options ought to
be treated the same for the purpose of this discussion.

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

The current approach does not work well in practice because, while it
looks reasonable when IPv4 and IPv6 actions are documented separately,
the [necessarily single] configuration breaks either IPv4 or IPv6 servers:

If ftp_epsv is on (default):

  contacting an IPv4 server may break because the network breaks EPSV.

If ftp_epsv is off:

  contacting IPv6 servers breaks because they need EPSV.

(I am omitting the cases of ESPV ALL and EPRT for clarity, they do not
add value to the current discussion).

I suspect the initial attempt-based algorithm was developed for PASV and
PORT only, where it makes sense. It was wrong to add similar EPSV and
EPRT configuration to that IPv4-specific algorithm because a single
ftp_epsv option setting does work for a mix of IPv4 and IPv6 servers.

Alex.
Received on Wed Jan 29 2014 - 05:41:05 MST