Re: [RFC] ignore ftp_epsv off for IPv6

On 2014-01-31 07:35, Alex Rousskov wrote:
> [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
>

s/ on for ipv6_server/ ipv6/
s/ off for ipv4_server/ ipv6/

... and you have what I was suggesting back in the first reply.

  "1 for ipv4_server" is currently hard-coded due to user demand. The
common case for FTP servers only listening on IPv4 seems to be not to
support the dual-stack possibilities from the RFC.
  Making this equivalent to "ftp_epsv on for ipv4_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?

We will need generic OFF if the gateway firewall used for general
Internet access by the proxy is where the breakage occurs.
We will need OFF for IPv6 if the IPv6-enabled FTP server has broken EPSV
support but working PASV/EPRT/PORT (some experimental vsftpd had this
type of thing).

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

Yes "for" is not needed.

With ACLs it is a lot more consistent with other ACL driven directives
to go with "[allow/deny/ipv4/ipv6]" instead of on/off/"off for" or
anything else.

P4-b: Shall we skip the arguing and go straight to ACL driven in that
format? I think it may be faster to simply write up a patch for ACLs
with a default "allow all" and simply allow/deny action choice than to
continue discussions around the on/off scoping. We are clearly focusing
on different use-cases and error conditions being more or less
subjectively important. The admin on the ground can probably get that
right far better than we can anyway.

Amos
Received on Thu Jan 30 2014 - 22:35:56 MST