[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
