[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    Re: [RFC] ignore =?UTF-8?Q?ftp=5Fepsv=20off=20for=20IPv=36?=
From:       Amos Jeffries <squid3 () treenet ! co ! nz>
Date:       2014-01-30 22:35:50
Message-ID: 7d554af1e1e251f0287d7c1794e7a3b7 () treenet ! co ! nz
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]