Re: [RFC] ignore ftp_epsv off for IPv6

On 30/01/2014 1:44 p.m., Alex Rousskov wrote:
> 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.

Why do you see any difference in this broken firewall software for IPv4
or IPv6 based

A) The same bug is very likely to exist in IPv6 traffic handling on the
same broken firewall.

B) EPSV is not the only method available to Squid.

Ergo, if EPSV is known not to work. Skip it entirely and let those other
mechanisms have a shot.

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

Checking the code I see we already explicitly break them by not allowing
"EPSV 1" to be sent in response to a 522 message with "(1)" hint from
IPv6 server (and vice-versa on "(2)" from IPv4 server).

What I was meaning was this nasty beast:

 Squid requests "EPSV 2" (IPv6 data connection), server responds "522
... (1)" indicating only accepting IPv4 data connections.

 ftp_epsv off disabling IPv4 ...

EPSV blocked to "IPv6 server".

Both of these are very rare IME, and I see we are already preventing
Squid working in those cases. But are valid behaviour according to the RFC.

The main point being that in FTP with two TCP connections to a
Dual-stack server there is no simple distinction "IPv4 server" or "IPv6
server". You have to tie the version decision to either the ctrl or data
connection.

I'm just saying "off" should mean OFF completely.

More importantly perhapse these changes to IPv6 behaviour do nothing for
your described problem case which is entirely in IPv4-only traffic.

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

ftp_epsv with a set of flag options about when and how it can be used
seems simpler to me than a bunch of separate on/off directives.

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

protocol: IPv4 or IPv6 data connection

"skipping" ... like the dictionary says. Skip over one step in the
attempt-based algorithm.

 The "ftp_epsv off" solves yoru problem case but currently skips over
both IPv4 and IPv6 connections without considering their protocol type.
As you say that can be annoying *if* only one type is broken.

Your problem case is also solved by adding a flag "ftp_epsv ipv6" that
means only IPV6 ("EPSV 2") is to be used.

Amos
Received on Thu Jan 30 2014 - 03:51:25 MST