Subject: [BEHAVE] Comments on draft-van-beijnum-behave-ftp64-05

From: Dave Thaler <[email-masked]>
Date: Tue, 21 Jul 2009 20:29:58 +0000

Section 3:

> all FTP servers
> MUST be configurable to respond with an error to EPSV and EPRT
> commands, even though the server is capable of EPSV and/or EPRT.

First, I'd argue I'd argue for a SHOULD here instead of a MUST.
I imagine there may be FTP servers in devices that are only
designed to be used within a site or even within a subnet.

Second, it says "an error".  Any error in particular?  425? 520?

> All FTP servers MUST indicate support for EPSV and/or EPRT when
> available in response to the FEAT command and MUST NOT list EPSV
> and/or EPRT in response to the FEAT command when EPSV and/or EPRT is
> administratively disabled as outlined above.

Ambiguous.  Does this mean that support for RFC 2389 is required?
Or that this requirement only applies if RFC 2389 is supported?

Section 4:

> It is highly RECOMMENDED that FTP clients react by retrying with PASV
> or EPRT when the EPSV command fails, either because of an error
> response by the server, because the data connection couldn't be
> created or because the control channel session was terminated.

It says "an error response".  Is this for _all_ error responses?
Or only certain classes of error response?  E.g., are both 400 and
500 level responses considered errors for this purpose?

I also have some editorial-only comments, which I will send directly
to Iljitsch.

-Dave

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Jul 2009 13:18:08 +0200

> designed to be used within a site or even within a subnet.

We really need to avoid the situation where firewalls break EPSV as  
much as we can. As expecting the firewall vendors to keep up with  
evolving standards is apparently too much to ask and firealls are  
everywhere these days, I don't really see a way to meet this goal  
without this requirement.

Maybe "If a FTP server supports configuration, it MUST have a  
configurable option to respond to EPSV and EPRT with an error" ?

> Second, it says "an error".  Any error in particular?  425? 520?

I guess a temporary error would be inappropriate. Upon a 5xx error,  
IPv4 FTP clients retry with PASV, which is what we want. I'm guess 502  
command not implemented is a safe choice here, even if it's not  
entirely (but still mostly) correct.

> Or that this requirement only applies if RFC 2389 is supported?

The idea was that RFC 2389 MUST be supported.

> 500 level responses considered errors for this purpose?

I don't want to make a list of all error codes and how to respond to  
them... If we retry over v6 on occasion where retrying over v4 would  
have worked too that's not a huge deal, IMO. Maybe:

"When the client encounters an error response or other error condition  
that would otherwise lead to a failure of the file transfer, and the  
server's address as used for the control channel is an IPv6 address  
(and not an IPv4-mapped address in the range ::ffff:0:0/96), ..."

Unless anyone disagrees with the above I'll add it to the -06 version,  

> I also have some editorial-only comments, which I will send directly

Thanks,

Iljitsch

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 22 Jul 2009 14:37:26 +0300

> without this requirement.

The same logic can be applied to FTP servers, which have obviously failed to 
pick up EPSV. So... why put a MUST on the servers rather than on the 
firewalls? It appears that either way won't work. This is pointless.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Jul 2009 14:12:25 +0200

On 22 jul 2009, at 13:37, Rémi Denis-Courmont wrote:

>> As expecting the firewall vendors to keep up with
>> evolving standards is apparently too much to ask

> pick up EPSV.

Not really. In Dan's test, 65% of the _IPv4_ servers would do EPSV  
successfully. 28% didn't implement EPSV. But the problem is the  
remaining 7%: they support the EPSV command but it doesn't work.

> So... why put a MUST on the servers rather than on the

Originally, the draft just described the ALG, which didn't require any  
changes from FTP servers (or firewalls). However, the feedback that I  
got then was that we should do this right, and not just apply ugly  
hacks. The right solution is for both the clients and the servers to  
use EPSV and then everything works cleanly. So that's one of the  
requirements of the draft. It then goes on to tell clients how to get  
around non-conforming servers and describes the ALG in case the  
clients aren't updated either.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 22 Jul 2009 16:45:48 +0000

> without this requirement.

I don't follow.  I would think all you need for firewalls is that
the server be capable of EPSV.  Why would you need it to respond
with an error even though it supports EPSV to help firewalls?

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 22 Jul 2009 16:54:15 +0000

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Wednesday, July 22, 2009 4:18 AM
> To: Dave Thaler
> Cc: Behave WG
> Subject: Re: Comments on draft-van-beijnum-behave-ftp64-05
>

> configurable option to respond to EPSV and EPRT with an error" ?

Better, but I'd still rather see it more along the lines of supporting
connections that may pass through a firewall, as opposed to local
LAN or something.  But since I don't know of any specific cases
where it would matter, I don't feel strongly here.

> entirely (but still mostly) correct.

The draft should be explicit about what error is to be returned.

> The idea was that RFC 2389 MUST be supported.

Why?  There's nowhere in the doc that actually says that a client
has to send a FEAT request.  The 2nd paragraph of section 4 of your
draft is ambiguous as to whether the client is required to send it
or not.

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Jul 2009 10:05:12 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Thaler
> Sent: Wednesday, July 22, 2009 9:46 AM
> To: Rémi Denis-Courmont; [email-masked]
> Subject: Re: [BEHAVE] Comments on draft-van-beijnum-behave-ftp64-05
> 

The situation is where a firewall doesn't properly handle EPSV 
(e.g., it doesn't open the necessary TCP pinhole) and that firewall
cannot be fixed/upgraded.  In that situation, the FTP server needs
to be configured to not support EPSV, because EPSV will fail.

If the I-D mentioned the firewall reasoning in a "Note:" it would
be clearer.

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Jul 2009 20:18:39 +0200

On 22 jul 2009, at 18:54, Dave Thaler wrote:

> Why would you need it to respond

See Dan's response. I'll add text.

> The draft should be explicit about what error is to be returned.

I'll put in SHOULD 502.

> Why?

I guess one reason is that it annoys me a lot that this is such a mess  
today. FEAT is widely supported but in most cases, EPSV/EPRT aren't  
listed in the FEAT response, defeating the purpose (for our purposes,  
at least).

The transition from EPSV not being in the FEAT response to it being in  
the FEAT response would be a good indication that EPSV now works even  
though the presence of EPSV without knowledge of the prior situation  
doesn't necessarily mean it does, nor is the opposite true.

> There's nowhere in the doc that actually says that a client
> has to send a FEAT request.

I don't think it HAS to, but if it does it should be able to trust  
what it gets back.

I suppose I could change the text to say "if the server supports FEAT  
it MUST list EPSV and/or EPRT if they are supported and enabled, and  
not list them if they're not supported or not enabled".

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 23 Jul 2009 09:34:37 +0300

> to be configured to not support EPSV, because EPSV will fail.

I think we should just point out that an FTP server allowing EPSV should not 
be deployed behind an inbound firewall not allowing.

Well, generally, you should not deploy a service behind a firewall not 
compatible with that service. More generally, you should deploy compatible 
equipment on your network. I don't think BEHAVE should decide to blame the 
software for lacking a toggle because of old or crappy firewalls. And I guess 
most FTP operators wouldn't know how to use the toggle anyway.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 23 Jul 2009 10:35:18 +0200

> be deployed behind an inbound firewall not allowing.

Do you think that Dell, Sun and Lexmark, who do this today, are going  
to replace their firewalls? I'm sure they get complaints from users  
once in a while, and apparently they don't care.

_Maybe_ they'll be prepared to flip a switch in a config file, but  
buying a new device, I don't see it happen.

> most FTP operators wouldn't know how to use the toggle anyway.

The world would be a much better place without firewalls. Or NATs. But  
that's not the world we live in. As an operator, there's lots of  
things that you can't do, because you don't write your own protocols  
or software and don't build your own hardware. But changing a  
configuration IS something most operators can do. Giving them that  
won't magically solve all problems but at least it's something.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 23 Jul 2009 11:48:22 +0300

On Thursday 23 July 2009 11:35:18 ext Iljitsch van Beijnum wrote:
> > I think we should just point out that an FTP server allowing EPSV
> > should not be deployed behind an inbound firewall not allowing.
>

They could buy the FTP server as an appliance as well, or simply subcontract 
it as a service. Not to mention that they could configure the firewall 
properly, so that it allows inbound TCP connections to non-privileged ports...

> won't magically solve all problems but at least it's something.

The same argument could be made that firewall must support EPSV (or must 
support a toggle for it). A firewall is a piece of hardware with software in 
it, and depending on the vendor and contract, may or may not be "fixable". So 
is an FTP server.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 23 Jul 2009 11:39:33 +0200

> it, and depending on the vendor and contract, may or may not be  

Even more so than NATs, firewalls exist to break specifications. You  
can't fix them with better specs. EPSV has been around for 11 years.