Re: [RFC] ignore ftp_epsv off for IPv6

[I may have figured out why we could not make progress before, and we
may be finally converging on a solution. P4 at the bottom. ]

On 01/29/2014 08:51 PM, Amos Jeffries wrote:
> On 30/01/2014 1:44 p.m., Alex Rousskov wrote:

>>>> P1: ignore "ftp_epsv off" for IPv6 servers.

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

I suspect we are using a different definition of "IPv6 server". For this
discussion, I am defining "IPv6 server" as a server that Squid [intends
to] send FTP commands using an IPv6 destination address. The data
connection protocol is irrelevant for this definition.

Given my definition, proposal P1 above does not result in "ftp_epsv off
disabling IPv4" for the IPv6 server you are describing. With P1,
ftp_epsv setting would have no effect on IPv6 servers at all.

I define IPv4 server the same way (s/6/4/g), of course.

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

I am using the definition above. It is not affected by the data
connections. I am sorry if I have not been clear about this from the
beginning and have not realized that you actually do not know what I
mean by "IPv6 server".

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

Perhaps now that we have resolved the terminology problem, you will see
how P1-3 work to address the case I am after, using my definition of the
"IPv6 server".

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

Which is what my P2 proposes, but my understanding is that you objected
to that as not "longer view" enough and/or "exploding" too much.

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

OK. I cannot think of a configuration approach that would allow Squid to
make the right decision in my use case based on the data connection
protocol. I do not want to tell Squid to disable support for IPv4 data
connections or IPv6 data connections! Can you give an example of how
this "long view" configuration could look like when addressing my use case?

> The "ftp_epsv off" solves yoru problem case but currently skips over
> both IPv4 and IPv6 connections without considering their protocol type.

"ftp_epsv off" (as currently implemented) solves my use case but
disables support for IPv6 servers that cannot use IPv4 data connections.
That is why I am looking for a better solution.

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

No, my P2 means that EPSV is only sent to IPv6 servers (my definition).
Those IPv6 servers are still free to use IPv4 and IPv6 data connections.
P2 is less restrictive than you think.

Needless to say, we may need to add more knobs to address more cases.
Still focusing on just EPSV, Squid can make two decisions:

* What flavor of EPSV to send: none, EPSV, EPSV 1, EPSV 2.
* Where to send it: Any server, IPv4 server, IPv6 server.
  (using my control connection-based definition of IPvN server)

To gain full control, we would need to support something like this:

* P4: ftp_epsv <flavor> [for <destination>]

For example:

  # do not send EPSV do any servers:
  ftp_epsv off

  # do not send EPSV to IPv4 servers:
  ftp_epsv off for ipv4_server

  # send EPSV 1 to IPv4 servers:
  ftp_epsv 1 for ipv4_server

  # send parameterless EPSV to IPv6 servers:
  ftp_epsv on for ipv6_server

with "on" as the default for not explicitly covered cases (we can
discuss whether "on" is the right default separately, but that is what
the current code is using).

I do not know whether we will ever need any of the above except

  # do not send EPSV to IPv4 servers:
  ftp_epsv off for ipv4_server

Do you?

If not, we can implement support for just three lines (for now):
  ftp_epsv on
  ftp_epsv off
  ftp_epsv off for ipv4_server

In the future, I suspect we will eventually need ACLs. The proposed
"for" clause in P4 will accept ACLs nicely, even without squid.conf
changes (if we add an ipv4_server ACL). That is why I used "for" instead
of the more restrictive "to" keyword. The ACLs may use the source
address as well as the destination address, of course.

If you like the overall P4 approach, do you think we should drop the
explicit "for" keyword? The explicit key word is needed if you want to
extend this further to multiple EPSV flavors per line, but perhaps we
should keep it simple, with one flavor per line only. Then "for" is not
really needed.

Thank you,

Alex.
Received on Thu Jan 30 2014 - 18:35:43 MST