Re: [RFC] ignore ftp_epsv off for IPv6

[if you don't want the point-by-point skip to the end ]

On 2014-01-30 05:57, Alex Rousskov wrote:
> 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).

You argued "IPv6 servers breaks" against disabling *only* EPSV and
letting the overall algorithm complete the whole sequence. I provided
the case why only-EPSV disabling is required for the sequence to work by
reaching a later EPRT, proving that a false assertion.

  "may break" sure, but not always. And certainly not in the common case
of a working IPv6 server set to a active-FTP because the NAT gateway has
problems with EPSV.

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

Your single failure use-case is more important than keeping working the
multiple cases which work today? no.
  We had a handful of complaints about EPSV crashing Cisco NAT routers
regardless of IPv4/IPv6. So far one (you) with this new case. Which
seems more common/important?

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

If anything breaks on the server itself or the pathway there the method
of connection is broken and cannot be used. Normally we have a "direct"
connection to FTP servers with any middleware *supposed* to be
transparent.

>
>> 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 am in agreement with doing it. I am in disagreement with a) exploding
the config options into a large set, and/or b) dropping the existing
algorithm which has been working for other breakage cases just to fix
this one case.

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

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?

The one case I know of for NAT/firewall breaking with EPSV while working
with PASV is when they hang the control channel by a) NAT code crashing
on processing the 'supported' new command, or b) dropping the unknown
command without sending an error code back.

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

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.

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

false.

> but if it turns out
> that there are IPv4 servers or networks that cannot use PASV/PORT, but
> can use EPSV/EPRT,

Have not seen any evidence of this. The FTP software I've found has
either supported both sets fro IPv4 or just the PASV/PORT ones.

> 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 don't insist. The semi-recursive algorithm already supports skipping
just one step as/when needed and extending that to skip per-protocol.
The squid.conf directive is where the skip is not supported.

>
> I hope that focusing on a single use case first will allow us to make
> progress.

It wont. The existence of this discussion is ample proof of that.

  The existing code was created for the use-case where FTP was going over
broken NAT/firewall which crash in their processing of the command
syntax itself (regardless of IPv4/IPv6 details) and hang or terminate
the entire ctrl channel.

  Dropping the algorithm re-opens the multiple use-cases where that
behaviour was found. Being found a whole year or two earlier than this
"new" case indicates to me that it is the more common breakage case(s).
We don't see that now because Squid is recovering silently via the
existing algorithm.

> 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.
  Confusing the admin with: 'off' does not mean OFF

It is not a desirable setting really, but some admin do already need it
to mean fully-off for (only) EPSV command.

> 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

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

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

P2: extend the incomplete ftp_epsv_all squid.conf setting to configure
per-protocol skipping of EPSV ALL

P3: extend the incomplete ftp_eprt squid.conf setting to configure
per-protocol skipping of EPRT

P4: enjoy the holiday or look for any more breakage

Amos
Received on Wed Jan 29 2014 - 22:19:41 MST