Re: [RFC] ignore ftp_epsv off for IPv6

On 01/29/2014 12:30 AM, Amos Jeffries wrote:
>>>>> "off" should never be abused to mean half-off.
>>>> The problem here is that the directive itself was misnamed IMO.
>>> It is named correctly for its scope
>> OK, then its scope is wrong.
> The scope is right.

For IPv4, it is right. For IPv6, it is right. For a world where the two
co-exist, the approach does not work. It is probably pointless to argue
whether it is the name, the scope, the implementation, or something else
that went wrong. The fact remains: There is no way for Squid to operate
well with any of the currently supported EPSV option settings. Let's
focus on that problem.

> So this is one of those instances you mentioned in the -n discussion
> where Squid can be badly configured but a smart admin does not do so and
> we should be allowing configuration rather than denying it.

It is the opposite of that: In this case, a smart admin cannot configure
Squid to work well, no matter how hard she tries.

> NP: a smart admin may actually disable both if the network was gatewayed
> over software which dies on both. The clients could not contact
> IPv6-only servers, but that is the smart admins intent. Fail-fast on
> IPv6 rather than trying slow-ish things and killing the gateway router
> on the way.

The use case is different: IPv6 servers work fine. IPv4 servers work
fine with standard FTP commands. Transactions stall when Squid
"attempts" to use EPSV with some IPv4 servers. To avoid that breakage,
the admin needs a way to tell Squid "do not try EPSV with IPv4 servers
while still using EPSV with IPv6 servers".

>> If ftp_epsv is on (default):
>>
>> contacting an IPv4 server may break because the network breaks EPSV.
>>
>> If ftp_epsv is off:
>>
>> contacting IPv6 servers breaks because they need EPSV.
>>
>>
>> (I am omitting the cases of ESPV ALL and EPRT for clarity, they do not
>> add value to the current discussion).
>
> They *do* add value. Since EPRT may be working perfectly and nullify
> your second example of when "ftp_epsv off".

To make sure we are making progress, please do not through in other use
cases until we agree on how cover the current one. In the current use
case, EPRT setting is irrelevant because transaction stalls before Squid
tries to use EPRT (and may stall even if Squid does try to use EPRT, but
I do not really know).

To avoid misunderstanding, I do agree that any change should not make
other important use cases [much] worse, at least not without a
discussion about trade-offs. So other use cases are important. I just
want to make sure we find a solution for my use case first since it
appears to be surprisingly difficult even without adding more use cases
into the mix.

> Also note that by "break" you mean:
> IPv6 connectivity to IPv6-only servers over a faulty router is not
> possible.

I do not mean that. IPv6 servers work fine if they are sent an EPSV
command. A faulty network (outside of the admin control) breaks IPv4
servers that support EPSV, tricking Squid into sending EPSV to them.

> So, what can we possibly do that would not make that broken? IPv4
> connectivity to IPv4-enabled servers is still possible. Which is the
> scope of your change, yes? to selectively disable the EPSV command being
> sent depending on IPv4 or IPv6.

Yes, treating IPv4 and IPv6 servers differently is at the root of all my
proposals on this thread.

>> I suspect the initial attempt-based algorithm was developed for PASV and
>> PORT only, where it makes sense. It was wrong to add similar EPSV and
>> EPRT configuration to that IPv4-specific algorithm because a single
>> ftp_epsv option setting does work for a mix of IPv4 and IPv6 servers.
>
> The algorithm is baked into RFC 2428. See section 2 about the meaning of
> that 1-digit <net-prt> parameteron EPSV; 1 = IPv4 wanted, 2 = IPv6. The
> server accepts or rejects with 522 and a list of supported protocols
> which can be tried on the followup attempt.

Server actions are irrelevant in this use case. It is the network that
breaks things. The servers are working fine and comply with FTP RFCs.

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

> In theory only EPSV/EPRT should ever be needed. In practice, for
> IPv4-enabled servers all 4 commands should still work fine

... but do not. In practice, faulty firewalls prevent EPSV from working
fine with IPv4 servers that _do_ support EPSV. We can, of course,
declare that we are not going to do anything about it. I do not think
the Project should take such a position in this case because the fix
appears to be relatively straightforward [to me], despite this painful
discussion.

The only known [to me] negative side-effect is that some IPv4 servers on
good networks will not use EPSV if Squid admin choses to disable EPSV
for for IPv4 servers. Those servers will continue to use PASV, of course.

PASV/PORT support is required for IPv4 FTP servers, but if it turns out
that there are IPv4 servers or networks that cannot use PASV/PORT, but
can use EPSV/EPRT, we can consider restructuring the whole
active/passive configuration to allow for server-specific ACLs. If you
insist, we can even do that now (but such restructuring is a lot of work
so it feels a bit premature to me without the real-world cases to back
it up).

I hope that focusing on a single use case first will allow us to make
progress. 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.

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.

Again, we should and will consider EPRT and other use cases if there is
an agreement on the best way to proceed with EPSV and this particular
use case.

Thank you,

Alex.
Received on Wed Jan 29 2014 - 16:58:14 MST