File Transfer Protocol HOST Command for Virtual Hosts
RFC 7151

[Ballot comment]
After discussing with the Apps AD, I'd prefer that there's some kind of recommendation for the support of TLS for protecting communications between the UA and the host.

[Ballot discuss]
Updated to clear the first part based on email exchange with author.  Researching the next bit.

This draft draws a comparison to HTTP for this draft's HOST command, I would like to draw another to the HTTP Basic Authentication schemes which when used MUST be paired with TLS.  And that is ... if the "security" extensions from RFC 2228 are to be used after a HOST command is issued or if the user name and password are to be exchanged after a HOST command then TLS MUST be used.

[Ballot discuss]
One of the big issues with TLS is how to represent and verify the identity of applications (see RFC 6125).  RFC 5280 specifies how the FTP URI is used in the certificate something like ftp://192.0.2.1.  s3.1 of this document says that the address can include square brackets.  Is this document updating RFC 5280? Does the server_name included in the TLS handshake also include these brackets?

This draft draws a comparison to HTTP for this draft's HOST command, I would like to draw another to the HTTP Basic Authentication schemes which when used MUST be paired with TLS.  And that is ... if the "security" extensions from RFC 2228 are to be used after a HOST command is issued or if the user name and password are to be exchanged after a HOST command then TLS MUST be used.

[Ballot comment]
Section 3.1 copies ABNF from RFC 3986 rather than incorporating it by reference.  The reader most likely knows what an IPv4 address and an IPv6 address looks like, and if they don't they can refer to RFC 3986.  So I would really encourage you to incorporate these by reference rather than copying the text.  Copying the text invites errors, and I don't think it adds value.

Dropping the following DISCUSS based on Barry's agreement to address it.  There is still some discussion ongoing with the authors about other concerns that came up during the discussion of the DISCUSS, but I don't think they are DISCUSS-worthy.

Section 3, paragraph 1:
  This command MUST be
  issued before the user is authenticated, as this will allow the
  authentication scheme and set of legal users to be dependent upon the
  virtual host that is chosen.

Does this mean "if the user agent is going to send a HOST command, it MUST send it before it authenticates?"  Or does it mean "User agents implementing this specification MUST send a HOST command before authenticating?"    I think it means the latter, but it could be read as meaning the former.

[Ballot comment]
I'm clearing and making my discuss a comment; you now know the issue and I do not have a strong opinion about how to fix it. Here were my two significant comments:

Bbefore recommending the approval I wanted to ask for clarification on two points to make sure that implementors can read this spec accurately.

I had trouble understanding what the "chooses not conform" on page 17 means. Did you mean "chooses not to use"?

Similarly, on page 18, I did not understand this: "a server implementation MUST treat an additional HOST command that was sent before a user has been authenticated as though a previous HOST command was not sent." Can you clarify?

See also Meral's Gen-ART review.

[Ballot discuss]
Section 3, paragraph 1:
  This command MUST be
  issued before the user is authenticated, as this will allow the
  authentication scheme and set of legal users to be dependent upon the
  virtual host that is chosen.

Does this mean "if the user agent is going to send a HOST command, it MUST send it before it authenticates?"  Or does it mean "User agents implementing this specification MUST send a HOST command before authenticating?"    I think it means the latter, but it could be read as meaning the former.

[Ballot comment]
Section 3.1 copies ABNF from RFC 3986 rather than incorporating it by reference.  The reader most likely knows what an IPv4 address and an IPv6 address looks like, and if they don't they can refer to RFC 3986.  So I would really encourage you to incorporate these by reference rather than copying the text.  Copying the text invites errors, and I don't think it adds value.

[Ballot comment]


- I support Sean's DISCUSS points

section 1 - "Such an arrangement presents some problems
for FTP servers, as an FTP server distinguishes incoming
FTP connections by their IP addresses rather than their
DNS names." is a bit confusing, I think s/IP
address/inbound destination IP address/ would clarify.
I was temporarily confused by that fwiw.

section 3 - with a host, auth, host sequence the 2nd
host command gets a 503 response. But what else happens,
if anything? You probably should say if its not implied
by the 503.

3.1 - say if a server is behind a NAT/CGN. Then it might
be genuinely presented with an IP address literal that's
not the one by which it knows itself.  Very much a
corner case, but do you really want that MUST for
sending a 504 in that case?  Actually now that I think
about that, it might be a real issue for WebRTC handling
of ftp: URLs maybe.  I guess there might also be a
corner case wrt MPTCP there too, can't recall.

3.2.1 - corner case - with an OTP REIN isn't quite what
its supposed to be, but that's independent of HOST I
guess

Appendix A - I'm not sure all of the paths-not-taken are
required to be "unworkable" so the appendix title seems
odd.

[Ballot discuss]
One of the big issues with TLS is how to represent and verify the identity of applications (see RFC 6125).  RFC 5280 specifies how the FTP URI is used in the certificate something like ftp://192.0.2.1.  s3.1 of this document says that the address can include square brackets.  Is this document updating RFC 5280? Does the server_name included in the TLS handshake also include these brackets?

This draft draws a comparison to HTTP for this draft's HOST command, I would like to draw another to the HTTP Basic Authentication schemes which when used MUST be paired with TLS.  And that is ... if the "security" extensions from RFC 2228 are to be used after a HOST command is issued or if the user name and password are to be exchanged after a HOST command then TLS MUST be used.

s3.2: I'm unsure why these are not MUSTs:

Upon receiving the HOST command, before authenticating the user-PI, a
server-FTP process SHOULD validate that the hostname given represents
a valid virtual host for that server, and, if it is valid, establish
the appropriate environment for that virtual host.

If the hostname specified is unknown at the server, or if the server
is otherwise unwilling to treat the particular connection as a
connection to the hostname specified, the server SHOULD respond with
a 504 reply.

[Ballot discuss]
Thanks for writing this document. It seems OK and the Gen-ART reviewer, Merat, was also largely OK with it. However, before recommending the approval I wanted to ask for clarification on two points to make sure that implementors can read this spec accurately.

I had trouble understanding what the "chooses not conform" on page 17 means. Did you mean "chooses not to use"?

Similarly, on page 18, I did not understand this: "a server implementation MUST treat an additional HOST command that was sent before a user has been authenticated as though a previous HOST command was not sent." Can you clarify?

[Ballot comment]
I have no objection to the publication of this document, but I do have a non-blocking comment that I think would be useful to consider.  The examples supplied in section 3.1 (top of pg. 8) are educational, but I am concerned about the use of link-local IPv6 addresses.  The examples do not seem like they need to use link-local IPv6 addresses, so using global addresses out of the documentation space (RFC 3849) would be a good choice.  My concern about using link-local IPv6 addresses is that their use requires more information than just the address.  In order to handle the non-uniqueness of these addresses, users have to specify which interface to use for the communication (e.g., "ftp FE80::1:2:3:4%en0").  RFC 4007 (section 11) discusses the reason for needing this additional information.  Given that, I would suggest changing the example to use the defined documentation (i.e., global) address range.

[Ballot comment]
I have a few comments that you might wish to consider, along with any other comments you receive during IESG evaluation.

In section 3.1.  Syntax of the HOST command

  The "hostname" (given as a parameter) specifies the virtual host to
  which access is desired.  This SHOULD be the same host name that was
  used to obtain the IP address to which the FTP control connection was
  made, after any client conversions have been completed that convert
  an abbreviated or local alias to a complete (fully qualified) domain
  name, but before resolving a DNS alias (owner of a CNAME resource
  record) to its canonical name.

I'm not understanding why this is a SHOULD. Does something break in the protocol if you don't do this? Can the server-FTP process even tell that the user-FTP process has specified a host name that wasn't used to obtain the IP address?

In section 3.2.  HOST command semantics

  Upon receiving the HOST command, before authenticating the user-PI, a
  server-FTP process SHOULD validate that the hostname given represents
  a valid virtual host for that server, and, if it is valid, establish
  the appropriate environment for that virtual host.

I'm not understanding why this is a SHOULD. Is this just so a server-FTP process that treats all of its virtual hosts as identical doesn't have to reject a HOST command from a user-FTP process that uses the HOST command to be robust in the presence of virtual hosts that aren't identical?

In section 3.2.1.  REIN command semantics

  As specified in [RFC0959], the REIN command returns the state of the
  connection to what it was immediately after the transport connection
  was opened.  This specification makes no changes to that behavior.
  The effect of a HOST command MUST be reset if a REIN command is
  performed, and a new HOST command MUST be issued afterwards in order
  to connect to a virtual host.

I think I was able to figure out what this is saying, but the (I think) similar text at the beginning of Section 4 was much easier for me to understand. You might consider stealing some of that phrasing, perhaps something like

  As specified in [RFC0959], the REIN command returns the state of the
  connection to what it was immediately after the transport connection
  was opened.  This specification makes no changes to that behavior.
  In this situation, the server implementation MUST reset the
  authentication environment as though a previous HOST command was not
  sent, and a new HOST command MUST be issued afterwards in order
  to connect to a virtual host.

Thank you for including Appendix A. It was helpful to me as a reviewer.

[Ballot comment]
Section 3, para 1: "legal" is weird here. Don't you mean "authorized"?

Section 3.1: Why are these copied in here as opposed to being included by reference? Especially given that you've got a change to hostname and not to the literals, you're bound to cause confusion by mixing them. But we've seen this before and I leave it to the authors and AD to make the right choice.

Section 3.2.2, para 5: "An exception to the above statement..." Which above statement are you talking about?

[Ballot comment]
Section 3, para 1: "legal" is weird here. Don't you mean "authorized"

Section 3.1: Why are these copied in here as opposed to being included by reference? Especially given that you've got a change to hostname and not to the literals, you're bound to cause confusion by mixing them. But we've seen this before and I leave it to the authors and AD to make the right choice.

Section 3.2.2, para 5: "An exception to the above statement..." Which above statement are you talking about?

IESG/Authors/WG Chairs:

IANA has reviewed draft-hethmon-mcmurray-ftpext-ftp-hosts-03. Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the FTP Commands and Extensions registry at

http://www.iana.org/assignments/ftp-commands-extensions/

a single new extension will be registered as follows:

+------+--------+---------------+------+------+---------------------+
| cmd  | FEAT  | description  | type | conf | RFC#s/References    |
|      | Code  |              |      |      | and Notes          |
+------+--------+---------------+------+------+---------------------+
| HOST | HOST  | Hostname      | a    | o    | [ RFC-to-be ]      |
+------+--------+---------------+------+------+---------------------+

IANA understands that this is the only action required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (File Transfer Protocol HOST Command for Virtual Hosts) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'File Transfer Protocol HOST Command for Virtual Hosts'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-10-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


The File Transfer Protocol, as defined in RFC 959, does not provide a
  way for FTP clients and servers to differentiate between multiple DNS
  names that are registered for a single IP address.  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.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-hethmon-mcmurray-ftpext-ftp-hosts/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-hethmon-mcmurray-ftpext-ftp-hosts/ballot/


No IPR declarations have been submitted directly on this I-D.