Re: [RFC] ignore ftp_epsv off for IPv6

On 01/29/2014 03:19 PM, Amos Jeffries wrote:
> [if you don't want the point-by-point skip to the end ]

I skipped discussion of other use cases. I want to focus on my simple
use case before considering others (and no, I did not say my case is
more important than others; just that I want to focus on it first. If we
cannot address my case, I will let others deal with other cases they
care about).

> Perhapse we should go back to the reason you are proposing this RFC.
> How exactly is the breakage appearing in the case of EPSV both ctrl
> channel details and TCP actions?

AFAIK, Squid sends EPSV to an IPv4 origin server. The server responds
with an IPv4 address. Squid tries to connect to that address. A broken
firewall in front of the origin server stalls that data connection.
Users get upset.

Without Squid, everything works because the client sends PASV command
that the firewall understands and allows the data connection through.

AFAIK, this happens with several FTP servers around the world, not just
some unlucky one.

>>> The data connection to an FTP server is not necessarily going to be the
>>> same protocol as the ctrl channel connection due to dual-stack servers
>>> in IPv6.
>>
>> The use case under consideration assumes the same IP address for both
>> data and control connections.
>
> This is then assuming that:
> 1) EPSV got through to the server, and
> 2) the server reply got back to Squid with protocol:IP:port details, and
> 3) breakage occurs when opening a normal TCP connection to that IP:port

Yes. And all addresses are IPv4.

> Details on how this is possible without also assuming misconfiguration
> of the FTP servers gateway would be useful. Note that the CTRL channel
> was setup in the first place by opening just such a TCP connection
> through apparently the same pathway.

See above. The control channel works fine because the firewall allows
control connections to the FTP server port. The data connection is not
going to the same port, of course. The firewall is supposed to let that
data connection in based on the previous EPSV response, but, evidently,
there is a bug with handling/recognizing that response and so the data
connection stalls.

>> Are you comfortable with any of my proposals for that specific
>> use case, as a starting point? Here is a brief summary:
>>
>> P1: ignore "ftp_epsv off" for IPv6 servers.

> No. That breaks the already fixed group of breakage cases. Plenty of FTP
> servers are listening on and operating on IPv6 and configured only to
> accept data connections via IPv4.

How will ignoring "ftp_epsv off" for IPv6 servers break "FTP servers are
listening on and operating on IPv6 and configured only to accept data
connections via IPv4"? AFAICT, those servers will receive an EPSV
command, respond with an IPv4 address, and the data will flow over an
IPv4 connection, just like today. No change for those servers!

> Confusing the admin with: 'off' does not mean OFF

Agreed (hence the renaming proposals).

>> P2: add "ftp_epsv ipv6" that will disable EPSV use with IPv4 servers.
>>
>> P3: rename ftp_epsv to ftp_epsv_for_ipv4 (essentially) and
>> naturally ignore the renamed version for IPv6 servers.

> Take a longer view. We will face matching breakage cases with all the
> commands we implement. Using this approach will explode the currently 4
> directives out to 12 on/off settings when the other currently cases are
> dealt with.
> I want something simpler and more intuitive for admin than
> directives_documented_with_a_sentence_about_what_is_does_in_its_own_name
> on/off

I would certainly welcome simpler and more intuitive alternatives!

> Simple:
> ... leave the (working) attempt-based algorithm from RFC 2428
>
> P1: extend the incomplete ftp_epsv squid.conf setting to configure
> per-protocol skipping of EPSV 1|2

Can you detail that a little please? I do not understand what you are
proposing. What is "protocol" and "skipping" in this context, exactly?
It may help if you can give a configuration example addressing the use
case in question.

Thank you,

Alex.
Received on Thu Jan 30 2014 - 00:44:35 MST