Re: [ftpext] I-D ACTION:draft-ietf-ftpext2-hosts-01.txt

[Robert McMurray <[e-mail]>]

Daniel,

Thanks for the great feedback. Sorry for the delayed response, I've been on vacation.

The reason that there are two possible responses for an out-of-sequence is because I didn't think that it was absolutely necessary to mandate one or the other in this situation. Of the two possibilities I personally favor the first option, which is to treat the late HOST command as an erroneous sequence of commands and return a 503 reply. This is because the general idea is that the HOST command is part of a login sequence, like the USER, PASS, and ACCT commands - and you can't use those commands out-of-order. But that being said, I could see where an implementer might want to choose the REIN behavior, and I think that a client and server could negotiate this condition pretty easily. But if there was a consensus to drop one or the other, I'd side with the 503 reply so the client always knows that it should send a REIN command.

As far as sending a port goes, there was a discussion about that concept a year and a half ago with the old HOST draft before the Working Group was formed, and it took me a little while to find my notes on that. The basic outcome of that discussion is that it doesn't sense to pass a port - and I'm paraphrasing some of my notes from that discussion.

When the client has already connected to the server on the control port, the connection has already been made and therefore specifying a port as part of the HOST command has no real meaning. Once a connection has been established, the PORT and PASV commands control any secondary (data) connections, but control is still over the existing command connection. To me specifying a port seemed analogous to issuing an HTTP request like http://example.com:p1:p2, where p1 is the first port to connect to and p2 is the second port. So the port is superfluous in this scenario, and might actually cause unnecessary problems in a NAT or firewall scenario, which I explain later.

I had mentioned in the previous discussion that I had thought about an example NAT/firewall situation like the following:

a. The site ftp.example.com is behind a NAT/firewall

b. Client wants to connect to ftp.example.com on port 2112

c. Client looks up ftp.example.com in DNS, sees that it's 10.0.0.1 (which is NAT/firewall's address)

d. Client connects to 10.0.0.1 on port 2112

e. NAT/firewall looks up the FTP mapping for 10.0.0.1 on port 2112, sees that it's routed to the FTP server at 192.168.0.1 on port 2112, and routes the connection traffic accordingly

f. Client sends HOST ftp.example.com:2112

In this last step - both connections have already been made; the client has connected to the NAT/firewall on the control channel over port 2112, and the NAT/firewall has connected to the intended FTP server on the control channel over port 2112. So once again the addition of the port is unnecessary.

I had also considered changing ports through the HOST command with regard to a NAT/firewall situation, which you had mentioned in your email, but that doesn't make sense, either. Pardon my anthropomorphizing this a little, but I spent some time thinking through this scenario with the mindset of a client saying to a NAT/firewall: "I want to talk to you (ServerA) on port 1111, but I want to talk to someone that's hiding behind you (ServerB) on port 2222." So the client connects to ServerA on port 1111, then sends HOST ServerB:2222. This seemed to me like a scenario that might be feasible.

That said, my argument in favor of that scenario fell apart rather quickly when considering it from a client perspective. If I have an FTP client and I want to use a front-end NAT/firewall and back-end FTP server with differing ports, I would now need to start configuring two ports for every FTP connection: the first port for my communication with the front-end and the second port for the back-end. That just didn't make sense.

In the end, the arguments that won out in my considerations was the way that I currently configure an FTP server behind a NAT server - I configure external-facing DNS names (admin.example.com and author.example.com) and I configure routing rules to different ports on my back-end FTP server. So the NAT server performs the port translation, and adding a port in the HOST command would just mess things up.

All that being said, for most clients, they are never aware that they are dealing with a firewall or NAT server, so trying to force the client to become aware of special syntax to communicate through the NAT/firewall to a back-end seemed to defeat some of the justification for having the NAT/firewall in the first place. Also, it seemed a bad idea to be exposing the remote server information to clients through the NAT/firewall.

Considering a two-port configuration just didn't work for any of the scenarios that I considered because that was simply not the way that the HOST command was intended, and there would be way too many barriers to finding a way to make that work. I think that for the NAT/firewall situations you would need to have a different command that specifically addressed those scenarios, something like a "RTCN 192.168.0.1:3333" command for a Remote Connection to a back-end server, although personally I still think that it's a bad idea to expose the remote connection information through the NAT/firewall.

Thanks again!

--Robert

-----Original Message-----
From: Daniel Stenberg [mailto:[e-mail]] 
Sent: Wednesday, December 08, 2010 2:22 PM
To: [e-mail]
Subject: Re: [ftpext] I-D ACTION:draft-ietf-ftpext2-hosts-01.txt

On Wed, 8 Dec 2010, [e-mail] wrote:

> This document defines a new FTP command that provides a mechanism for FTP 
> clients and servers to identify individual virtual hosts on an FTP server.

This is a very well written document and I really like it. Two 
comments/remarks:

Section 3 (and 3.3) mentions that the server can respond to a late HOST in one 
of two ways (a or b).

Why two? Why not just specify one specific way which will make it easier for 
both client and server authors to behave? (I would personally prefer b but it 
is not a strong preference).

Section 3.1 details that HOST only specify host name or IP address, not port 
number. The HTTP Host: header can (optionally) include a port number. The text 
says that the port number is pointless but I'm not sure that it always is and 
will be. In a time when we use NATs and port forwarders and so on, I can 
imagine a case when you have a front end port (port A) open for clients to 
connect to, but once connected you forward the traffic to an internal site on 
port B (or C or D perhaps when load ballancing for example) and thus the 
internal receiver of the traffic doesn't know which port the client originally 
connected to unless it mentions that.

It's just so easy to also support the port number as I think it would be a 
shame to forbid it since there may actually be usecases for it!

-- 

  / daniel.haxx.se