Subject: TSV-DIR review of draft-hethmon-mcmurray-ftp-hosts-11.txt

From: Joe Touch <[email-masked]>
Date: Thu, 06 May 2010 10:47:54 -0700

Hi, all,

I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

The document defines a new FTP command called "HOST" that allows an FTP
server to support virtual hosts, i.e., multiple hosts on the same IP
address.

The document does raise an important concern from a transport viewpoint.
The document extends FTP to support the same kind of virtual hosting
common in the web. Although the Internet defines hosts by IP address,
virtual hosts are specified in various ways, including DNS names, that
may or may not map to the IP address of the connection to the server.

The extension is discussed in ways that imply that the user is
connecting to a HOST as indicated in the command, rather than the IP
address of the FTP connection. IMO, the HOST command ought to be
presented more as a way to provide context within a host, not to
indicate a host. That might be acheived by a name change (VHOST?) and/or
by revising some of the discussion accordingly.

Thus, I would strongly suggest the document be revised as follows. Notes
are included below that indicate places where thes critical issues
should be addressed, flagged by "####".
--
This document should emphasize that the argument to the host command is,
at the protocol level, an opaque string passed to the application that
indicates only a session context (including authentication, file system,
etc.). There should be no attempt for the protocol to validate,
translate, or interpret that string - e.g., as matching the IP address
of the connection, or providing a valid IP address or fqdn. That
validation can be performed by the server implementation, but should not
be a constraint of the protocol.

There are places where SHOULDs are used where I expected MUSTs. Any
place a SHOULD is used, the document ought to include a description of
what happens if not, i.e., if the SHOULD is not followed, and it'd be
useful to also include reasons why and conditions where this might be
useful or valid.

Also, in terminology, the document would benefit from a bit of
clarification and revision, notably its title and description of the
purpose of this command. The HOST command performes much the same
function as HTTP including the full URL in the GET command, which
similarly allows virtual hosting. The document should avoid confusing
this with multi-homing, which is not necessarily related.
--

I have provided some other feedback interspersed in the text below
(flagged with "++++"). The most notable is the issue of how to handle
multiple HOST commands, the potential for HOST commands after the USER
command (without a REIN command), and updating the state machine to
include the effects of REIN interactions with the HOST command.

I also found numerous places where "should" or "must" are used but not
capitalized; the document should be checked for these uses to confirm
the intent. If case is important, then Section 2 should include text to
indicate such (as noted there).

I'd like to also suggest that the alternatives discussed might consider
an opportunity to integrate this command with the USER command to accept
"name[@hoststring]" arguments, e.g., [email-masked] This syntax
would suffice, and might need only an additional error code (to indicate
that the hoststring is not valid, rather than the entire command
argument), rather than defining a new name and introducing an additional
round trip into the login process. It seems equally compatible with the
wrapper approach discussed (which, IMO, should also be noted as a goal
of the design, FWIW).

I'd be glad to discuss this further on whatever list would be useful.

Joe

---------------------

Network Working Group                                         P. Hethmon
Internet-Draft                                          Hethmon Brothers
Updates: 959                                                 R. McMurray
Intended status: Standards Track                               Microsoft
Expires: October 6, 2010                                      April 2010

                  File Transfer Protocol HOST Command
                  draft-hethmon-mcmurray-ftp-hosts-11

####
The title should more accurately indicate the nature of the command, e.g.,
"The File Transfer Protocol HOST Command for Virtual Hosts"
####

Abstract

   The File Transfer Protocol, as defined in RFC 959 and Section 4
   of RFC 1123, is one of the oldest and most widely used protocols on
   the Internet.

   This document addresses the subject of creating multi-homed hostname-
   based FTP servers on a single IP address.  This is achieved by
   extending the FTP specification to add a HOST command that is used
   to specify individual FTP hosts.

####
Multihoming is when a single host has more than one IP address This
extension supports 'virtual hosts', where more than one
fully-qualified DNS name (fqdn) resolves to the same IP address.

The terminology needs to be updated throughout to address this issue.
####

1. Introduction

   It is common on the Internet for many domain names to be allocated

++++
It is common in the Internet to allow multiple DNS host names to
resolve to the same IP address.

(they're not allocated, and they're not domain names)
++++

   to a single IP address.  This practice has introduced the concept of
   a "virtual host", where a host appears to exist as an independent
   entity, but in reality shares all of its resources with one or more

++++
physical resources
++++

   similar hosts.

   Such an arrangement presents some problems for FTP servers, as all
   an FTP server can detect is an incoming FTP connection to a
   particular IP address.  That is, all domain names that share an IP

####
an FTP server distinguishes incoming FTP connections by their IP
address, not their DNS names, because hosts are uniquely identified by
address rather than name. That is, all DNS names that share an IP...
####

   address also share the same FTP server, and more importantly, its

++++
are handled by the same FTP server
++++

Hethmon & McMurray           Expires October 6, 2010            [Page 2]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

   Network Virtual File System (NVFS).

   This means that different virtual hosts cannot offer different
   virtual file systems to clients, nor can they offer different
   authentication systems.

++++
[it's worth pointing out here that a similar situation existed for the
web many years ago, and how it was resolved, and that you want to do
the same thing here basically]
++++

   No scheme can overcome this without modifications of some kind to the
   user-PI and to the user-FTP process.  That process is the only entity

####
I think you mean to say that "Any scheme to overcome this needs to
indicate not only the destination IP address, but also a name
associated with the desired virtual FTP server. This information is
currently discarded in the FTP application at the user interface of
the client."

(note: I used the term "name" - not DNS name here; see preface text as
to why)
####

   that knows which virtual host is required.  It has performed the
   domain name-to-IP address translation, and thus has the original
   domain name available.

++++
I don't know why the following section is in the intro. You do need to
discuss alternatives not pursued, but maybe later.
++++

   One method that could be used to allow a style of virtual host would
   be for the client to simply send a "CWD" command after connecting,
   using the virtual host name as the argument to the CWD command.
   This would allow the server-FTP process to implement the file stores
   of the virtual hosts as sub-directories in its NVFS.  This is simple,
   and most server-FTP implementations support this without requiring
   any code changes.

   While that method is simple to describe, and to implement, it suffers
   from several drawbacks.  First, the "CWD" command is available only
   after the user-PI has authenticated itself to the server-FTP process.
   Thus, all virtual hosts would be required to share a common
   authentication scheme if they used this method.  Secondly, to make
   the virtual host truly transparent, either the server-FTP process
   needs to be modified to include information that shows the special
   nature of this first CWD command (negating most of the advantage of
   this scheme), or all users must see the same identical NVFS view upon
   connecting (they must connect in the same initial directory), or the
   NVFS must implement the full set of virtual host directories at each
   possible initial directory for any possible user.  Thirdly, and
   again, unless the server is specially modified, a user connecting
   this way to a virtual host would be able to easily move to any other
   virtual host supported at the same server-FTP process, exposing the
   nature of the virtual host.

++++
I think the above is too glib. The first point is worth noting - that
it is available only after the connection is established, and so
cannot be used to determine per-host parameters (including, but not
limited to, authentication). The second point can easily be overcome
with an optional standard prefix to the CWD command, e.g.:

	CWD fqdn:{path}

The ability of the user to move between virtual FTP servers can be
seen as a benefit, not a liability. The question is whether the
benefit is needed, and whether it presents new problems (e.g.,
re-authenticating on different servers may not be feasible).
++++

   Another suggested method is to simply overload the "ACCT" for FTP
   virtual hosts, but this proposal is unacceptable for several
   reasons with regard to when the ACCT command is sent during the
   request flow.  Sections 5.4 and 6 of [RFC959] document the request
   flow for a login sequence as USER -PASS -ACCT.  This flow of
   commands may be acceptable when you are considering a single user
   having multiple accounts on an FTP server, but fails to
   differentiate between virtual hosts when you consider the following
   two issues:

++++
I think this is easier to state. The problem is that you need to do
ACCT before you do USER or PASS, since you don't know on what virtual
server to validate the first two.

I.e., same issue as before. Don't beat a dead horse, just note it and
move on.
++++

      a. The first problem with overloading the ACCT command is
      certificate negotiation when using the FTP security extensions
      that are documented in [RFC2228] and [RFC4217].  In order to
      safeguard user credentials, security mechanism and certificate

Hethmon & McMurray           Expires October 6, 2010            [Page 3]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

      negotiation must occur before login credentials are sent by the
      client.  The problem with using the ACCT command in this scenario
      is that there is no way of ensuring that the certificate matches
      the correct virtual host before the user credentials are sent.

      b. The second problem with overloading the ACCT command is how
      user credentials are implemented for FTP virtual hosts.  FTP
      server implementations may allow the use of custom user
      credentials on a per-virtual-host basis.  For example, in one
      particular implementation the virtual host negotiation occurs,
      and then the user credentials are looked up using the account
      mechanism that is specific to that virtual host.  So once again
      the virtual host negotiation must take place before the user
      credentials are sent.

   The conclusion from the examination of the existing possibilities
   seems to be that to obtain an adequate emulation of "real" FTP
   servers, server modifications to support virtual hosts are
   necessary.  A new FTP command seems the most likely solution to
   provide the required level of support.

++++
I think you may need to say:

  a new command that *precedes* USER is required.

However, I think it isn't. You can easily do the colon trick:

	 vhostname:username

or even the at-sign trick:

	username@vhostname

That seems like it's also potentially more easily understood to users
(it's already supported by many FTP command lines using that syntax),
and reduces the login by one round trip exchange as well.
++++

2. Document Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC2119].

++++
The document uses these terms in lower case, presumably not as key
words. If that is desired, it would be useful to be explicit about the
difference, e.g., by including the following text:

   When used in lower case, these words have their conventional meaning
   and do not convey the interpretations in [RFC2119].
++++

   In examples, "C>" and "S>" indicate lines sent by the client and
   server, respectively.

   This document also uses notation defined in [RFC959] and [RFC1123].
   In particular, the terms "reply", "user", "NVFS", "NVT", "file",
   "pathname", "FTP commands", "DTP", "user-FTP process", "user-PI",
   "user-DTP", "server-FTP process", "server-PI", "server-DTP", "mode",
   "type", "control connection", "data connection", and "ASCII", are
   all used here as defined there.

   Syntax required is defined using the Augmented BNF defined in
   [RFC5234]. Some general ABNF definitions are required throughout the
   document, those will be defined later in this section.  At first
   reading, it may be wise to simply recall that these definitions
   exist here, and skip to the next section.

2.1. Basic Tokens

   This document imports the core definitions given in Appendix B of
   [RFC5234].  There definitions will be found for basic ABNF elements
   like ALPHA, DIGIT, SP, etc.  To that, the following term is added
   for use in this document.

        TCHAR = VCHAR / SP / HTAB    ; visible plus white space

Hethmon & McMurray           Expires October 6, 2010            [Page 4]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

   The VCHAR (from [RFC5234]) and TCHAR rules give basic character
   types from varying sub-sets of the ASCII character set for use in
   various commands and responses.

   Note that in ABNF, string literals are case insensitive.  That
   convention is preserved in this document, and implies that FTP
   commands and parameters that are added by this specification have
   values that can be represented in any case.  That is, "HOST" is the
   same as "host", "Host", "HoSt", etc., and "ftp.example.com" is the
   same as "Ftp.Example.Com", "fTp.eXample.cOm", etc.

2.2. Server Replies

   Section 4.2 of [RFC959] defines the format and meaning of replies
   by the server-PI to FTP commands from the user-PI.  Those reply
   conventions are used here without change.

        error-response = error-code SP *TCHAR CRLF
        error-code     = ("4" / "5") 2DIGIT

   Implementers should note that the ABNF syntax (which was not used in
   [RFC959]) used in this document, and other FTP related documents,
   sometimes shows replies using the one line format.  Unless otherwise
   explicitly stated, that is not intended to imply that multi-line
   responses are not permitted.  Implementers should assume that, unless
   stated to the contrary, any reply to any FTP command (including QUIT)
   may be of the multi-line format described in [RFC959].

   Throughout this document, replies will be identified by the three
   digit code that is their first element.  Thus the term "500 reply"
   means a reply from the server-PI using the three digit code "500".

3. The HOST command

   A new command "HOST" is added to the FTP command set to allow the
   server-FTP process to determine to which of possibly many virtual
   hosts the client wishes to connect.  This command SHOULD be issued
   before the user is authenticated, allowing the authentication scheme,

####
When can this command ever come AFTER a user is authenticated? Is that
ever intended to be valid? If not, then change the SHOULD to
MUST. However, as noted above, embedding this info in the USER command
would have achieved the same effect without requiring protocol
machinery to determine the order of commands.
####

   and set of legal users, to be dependent upon the virtual host chosen.
   Server-FTP processes SHOULD treat a situation where the HOST command
   is issued after the user has been authenticated using one of the
   following two behaviors:

      a. Treat the late HOST command as an erroneous sequence of
      commands and return a 503 reply.

      b. Treat the late HOST command as a though a REIN command was
      sent before the HOST command and reset the user-PI to the state
      that existed after the TCP connection was first established and
      before the initial user authentication, and then return the

Hethmon & McMurray           Expires October 6, 2010            [Page 5]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

      appropriate reply for the HOST command.

++++
This is further evidence that this info might be easier to embed in
the USER command. The REIN effectively does a logout, and then the
next USER command would be expected to have the needed vhostname
information anyway.
++++

   Servers should note that the response to the HOST command is a
   sensible time to send their "welcome" message.  This allows the
   message to be personalized for any virtual hosts that are supported,
   and also allows the client to determine the supported languages, or
   representations, for the message, and other messages, via the FEAT
   response, and select an appropriate one via the LANG command.  See
   [RFC2640] for more information.

3.1. Syntax of the HOST command

   The HOST command is defined as follows.

     host-command  = "HOST" SP hostname CRLF
     hostname      = domain / IP-literal

####
IMO,
     hostname = bytetring

I see no reason to specify it further. To the protocol, it can/should
be opaque. The server can decide whether it likes it or not. If I want
to call a vhost "mickey_mouse!!@@##" I should be able to, IMO.

The rest of the syntax can be omitted.
####

     domain        = sub-domain *("." sub-domain)
     sub-domain    = let-dig [ldh-str]
     let-dig       = ALPHA / DIGIT
     ldh-str       = *( ALPHA / DIGIT / "-" ) let-dig

     IP-literal    = ( "[" IPv6address "]" ) / IPv4address

     IPv6address   =                              6( h16 ":" ) ls32
                     /                       "::" 5( h16 ":" ) ls32
                     / [               h16 ] "::" 4( h16 ":" ) ls32
                     / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
                     / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
                     / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
                     / [ *4( h16 ":" ) h16 ] "::"              ls32
                     / [ *5( h16 ":" ) h16 ] "::"              h16
                     / [ *6( h16 ":" ) h16 ] "::"

     ls32          = ( h16 ":" h16 ) / IPv4address
                     ; least-significant 32 bits of address

     h16           = 1*4HEXDIG
                     ; 16 bits of address represented in hexadecimal

     IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet

     dec-octet     = DIGIT                 ; 0-9
                     / %x31-39 DIGIT       ; 10-99
                     / "1" 2DIGIT          ; 100-199
                     / "2" %x30-34 DIGIT   ; 200-249
                     / "25" %x30-35        ; 250-255

     host-response = host-ok / error-response
     host-ok       = "220" [ SP *TCHAR ] CRLF

Hethmon & McMurray           Expires October 6, 2010            [Page 6]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

   As with all FTP commands, the "HOST" command word is case
   independent, and may be specified in any character case desired.

   The "hostname" (given as a parameter) specifies the virtual host to
   which access is desired.  It should normally 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 disagree with the above paragraph. The contents of the hostname
argument MUST be opaque to the protocol.

The remainder of this section (and/or document) needs to be updated
accordingly, IMO.

That also means that the client can send what it wants - fully
qualified or not. That's up to the client implentation to decide. The
semantics of that name should be meaningless to the protocol.
####

   Internationalization of domain names is only supported through the
   use of Punycode as described in [RFC3492].

####
This might say that internationalization of the opaque string is
handled via Punycode. It should not refer to domain names per se; that
is an interpretation that can be made by the server, but must not be
assumed in the protocol.
####

   If the user was given an IPv4 or IPv6 literal address, and
   consequently was not required to derive the literal address from a
   hostname, the client should send the HOST command with the IPv4 or
   IPv6 literal address as specified to it.  While it may seem
   counter-intuitive to specify a literal address by using the HOST
   command after the client has already connected to the server using
   a literal address, this should be expected behavior because a
   user-FTP process should not be required to differentiate between a
   fully qualified domain name and an IPv4 or IPv6 network literal
   address.  That being said, if the IPv4 or IPv6 literal address
   specified by the client does not match the literal address for the
   server, the server SHOULD respond with a 504 reply to indicate that
   the IPv4 or IPv6 literal address is not valid.

####
First, these strings ought to be opaque to the protocol. The server
can decide to check them, but the protocol MUST NOT, IMO.

Note, though, that even if the server interprets them, let's discuss
whether the server should do the above or not (i.e., this would be an
implementation/configuration choice, not a protocol requirement, if
so).

If you are intending to support only virtual hosting, then there is
never a need to send the IP address in a HOST command. However, if you
do want to allow it for completeness, then it MUST respond with a 504
if the address does not match (this can't be a SHOULD unless there is
a valid reason for either another response, or a valid action, and
this doc doesn't argue for either).

However, there could be a case where the FTP server listens on
multiple addresses on a multihomed host. In that case, this command
would appear to provide a valid way to connect to one address and
access the data on the other. Since this would succeed (even if not
intended!) if the user had provided a fqdn, I see no reason why it
should fail when they provide an IP address. Consider:

       a.example.net = 10.0.0.1
       b.example.com = 192.0.0.2

A user might issue:
  ftp a.example.net [email-masked]
      connecting to:	10.0.0.1
      issuing:		HOST b.example.net

if that works (and I can't see why it wouldn't, so far), then the
following should also work:

  ftp 10.0.0.1 [email-masked]
      connecting to:	10.0.0.1
      issuing:		HOST 192.0.0.2

If you don't want either example to work, then you missed a step on
the HOST command:

    HOST fqdn
	 resolve fqdn to a set of IP addresses "S"
	 the current connection IP destination address MUST
	 match an address in S, otherwise the server MUST
	 return an error

HOWEVER, I strongly discourage this sort of rule. Overall, IMO, the
HOST command takes an *arbitrary* argument that is interpreted *only*
as the context of access control and the NVFS. As a result, *all* such
checks that attempt to match any contents of this identifier to the
current connection MUST NOT be prohibited by the protocol (the server
configuration MAY check these or not, as supported and/or configured).
####

   When the hostname parameter contains a literal address, square
   brackets are expected to disambiguate port numbers syntax from IPv6
   address syntax.

++++
This doesn't make sense; below you prohibit the use of port numbers in
the command, so why do you need to disambiguate them?
++++

   Therefore, if the literal address is an IPv6
   address, the IPv6 address should be enclosed in square brackets
   (after eliminating any syntax that might also - but is not required
   to - be enclosed in brackets, and from which the server deduced that
   a literal address had been specified.)  For example:

        HOST 192.0.2.1
        HOST [FE80::c000:0201]
        HOST [::192.0.2.1]

   should be sent if the client had been instructed to respectively
   connect to "192.0.2.1", "FE80::c000:0201", or "192.0.2.1" and IPv6
   syntax is preferred.

   The client MUST NOT send the port number as part of the HOST
   command, even when the client has been instructed to connect to a
   non-standard port.  For example, the server-PI should respond with
   a 501 reply if the client sends a HOST command with syntax like
   "HOST 192.0.2.1:2112" or "HOST [FE80::c000:0201]:2112".

####
If raw addresses are deemed useful, then ports should be as well.

Further ports MUST be allowed to be specified either by their number
or their service name (e.g., "ftp"), IMO.

I would assume that service names MUST NOT be translated or validated
by the protocol, just as the fqdn MUST NOT be. The server
implementation MAY check/translate these as needed to coordinate with
their configuration, but this is outside the scope of the protocol,
IMO.
####

   The hostname parameter is otherwise to be treated as a fully

Hethmon & McMurray           Expires October 6, 2010            [Page 7]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

   qualified domain name or relative name as those terms are defined
   in section 3.1 of [RFC1034].  This implies that the name is to be
   treated as a case-independent string, meaning that uppercase ASCII
   characters are to be treated as equivalent to their corresponding
   lowercase ASCII characters, but otherwise preserved as given.  It
   also implies some limits on the length of the parameter and of the
   components that create its internal structure.  Those limits are not
   altered in any way here.

####
None of this should be validated, translated, or checked in the
protocol. The server implementation can decide whether it likes the
name, or it matches its configuration tables.
####

   Neither [RFC1034] nor [RFC1035] impose any other restrictions upon
   what kinds of names can be stored in the DNS.  This specification,
   however, allows only the of names that can be inferred from the ABNF
   grammar given for the "hostname".

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.  The resultant
   actions needed to create that environment are not specified here, and
   may range from doing nothing at all, to performing a simple change of
   working directory, to making much more elaborate state changes, as
   required.

++++
It might be useful to mention other changes, such as using different
username/password lists.
++++

   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 will respond with a
   504 reply.

   Note: servers may require that the name specified is in some sense
   equivalent to the particular network address that was used to reach
   the server.

####
Agreed - that is a server configuration issue. It's important to note
here that this MUST NOT be checked in the protocol itself, though.
####

   If the hostname specified would normally be acceptable, but for any
   reason is temporarily unavailable, the server-FTP process SHOULD
   reply to the HOST command with a 421 reply and close the connection.

++++
If you say SHOULD, you ought to indicate conditions under which you
might not, i.e., when would you not reply with 421? would you reply
with a different code, or just wait? It's not useful to include
SHOULDs without giving a hint as to why they are not MUSTs, IMO.
++++

   The "220" reply code for the HOST command is the same as the code
   that is used in the initial "welcome" message that is sent after
   the connection is established.  This reply code is used deliberately
   in order to allow the implementation of the front-end FTP server as
   a wrapper, which simply waits for the HOST command, and then invokes
   a server that is compliant with [RFC959] in the appropriate
   environment for the particular hostname received.

++++
A wrapper could as easily wait for a custom response command. I am not
sure why the response command is the same as for the initial
connection. Many other commands have their own response codes; IMO,
this should as well:

	    260 HOST command accepted
++++

3.2.1. REIN command semantics

   As specified in [RFC959], the REIN command returns the state of
   the connection to that it was immediately after the transport
   connection was opened.  This specification makes no changes to that

Hethmon & McMurray           Expires October 6, 2010            [Page 8]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

   behavior.  The effect of a HOST command will be lost if a REIN
   command is performed, and a new HOST command must be issued.

++++
The effect of a HOST command MUST be reset if a REIN command is performed.

(i.e., the FTP authentication and NVFS parameters are set to the
initial connection default after a REIN command).
++++

   Implementers of user-FTP should be aware that server-FTP
   implementations that implement the HOST command as a wrapper around
   older implementations will be unable to correctly implement the REIN
   command.  If they do, REIN will typically return the server-FTP to
   the state that it was in immediately after the HOST command was
   issued, instead of to the state that it was in immediately after the
   connection was opened.

++++
This seems like a problem; it seems like you need a few things here:

     1) a way to find out what the current HOST environment is

     CHOSTIS
     SHOST a.example.com

     2) a way to set the host to the default of a server, e.g.,
     using the HOST command with no argument??

     CHOST
     SHOST set to server default

(note: you now need to allow successive HOST commands to be permitted
after either login on REIN)
++++

3.2.2. User-PI usage of HOST

   A user-PI that conforms to this specification MUST send the HOST
   command after opening the transport connection, or after any REIN
   command, before attempting to authenticate the user with the USER
   command. The following example illustrates what a typical login
   sequence might look like when the HOST command is used:

        CHOST foobar.com
        S220 Host accepted

++++
I think you need to say:
	  S220 Service ready for new user

However, I prefer:
	  S260 HOST accepted
++++

        CUSER foo
        S331 Password required
        CPASS bar
        S230 User logged in

   The HOST command can be used in combination with the ACCT command
   to differentiate between a user's various accounts on a specific
   virtual host.  In this scenario, the user-PI sends a HOST command
   which the server-PI uses to route activity to the correct virtual
   host, the user-PI sends credentials using the USER and PASS commands
   which the server-PI validates, then the user-PI sends an ACCT
   command to specify any additional account information for the
   server-PI implementation.  The following example illustrates a
   sequential series of client commands that specify both a HOST and
   ACCT, with the server responses omitted for brevity:

        CHOST foobar.com
        CUSER foo
        CPASS bar
        CACCT project1

   This is also true when the HOST command is used with the AUTH and
   ADAT commands that are discussed in [RFC2228] and [RFC4217].  In
   this scenario, the user-PI sends a HOST command which the server-PI
   uses to route activity to the correct virtual host, then the user-PI
   uses the AUTH and ADAT commands to negotiate the security mechanism
   and certificate with the server-PI, then the user-PI sends user
   credentials using the USER and PASS commands which the server-PI
   validates.  After which the user-PI may send an ACCT command to
   specify any additional account information for the server-PI

Hethmon & McMurray           Expires October 6, 2010            [Page 9]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

   implementation. The following example illustrates a sequential
   series of client commands that specify both a HOST and ACCT when
   used in conjunction with the security commands that are discussed
   in [RFC2228] and [RFC4217], with the server responses omitted for
   brevity:

        CHOST foobar.com
        CAUTH <mechanism-name>
        CADAT <base64data>
        CUSER foo
        CPASS bar
        CACCT project1

3.2.3. State Diagrams

   The state diagrams in this section illustrate typical sequences for
   command and reply interchange between the user-PI and server-PI.
   These diagrams are modeled on the similar diagrams in section 6 of
   [RFC959].

   In both diagrams, the (B) "begin" state is assumed to occur after
   the transport connection has opened, or after a REIN command has
   succeeded.  Other commands (such as FEAT [RFC2389]) that require no
   authentication may have intervened.

   In each diagram, a three-digit reply indicates a precise server reply
   code.  A single digit on a reply path indicates any server reply that
   begins with that digit, except where a precise server reply code is
   defined on another path.  For example, a single digit "5" will apply
   to "500", "501", "502", etc., when those reply codes are not
   expressly defined in the diagram.  For each command there are three
   possible outcomes: success (S), failure (F), and error (E).  In the
   state diagrams below we use the symbol B for "begin", and the
   symbol W for "wait for reply".

####
I think this should allow for multiple HOST commands.

It should also show how the REIN command sets you back to a state
where you can accept new HOST commands.
####

              +---+   HOST    +---+ 1,3,5
              | B |---------->| W |-----------------
              +---+           +---+                 |
                               | |                  |
                     2,500,502 | | 4,501,503,504    |
                 --------------   -------------     |
                |                              |    |
                V                   1          |    V
              +---+   USER    +---+-------------->+---+
              |   |---------->| W | 2       ----->| E |
              +---+           +---+------  |  --->+---+
                               | |       | | | |
                             3 | | 4,5   | | | |
                 --------------   -----  | | | |
                |                      | | | | |

Hethmon & McMurray           Expires October 6, 2010           [Page 10]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

                |                      | | | | |
                |                ----------  | |
                |              1|      | |   | |
                V               |      | |   | |
              +---+   PASS    +---+ 2  |  ------->+---+
              |   |---------->| W |-------------->| S |
              +---+           +---+   ----------->+---+
                               | |   | |     | |
                             3 | |4,5| |     | |
                 --------------   --------   |  ----
                |                    | |  |  |      |
                |                    | |  |  |      |
                |                ------------       |
                |            1,3|    | |  |         |
                V               |   2| |  |         V
              +---+   ACCT    +---+--  |   ------>+---+
              |   |---------->| W | 4,5 --------->| F |
              +---+           +---+-------------->+---+

   When the HOST command is used in combination with the FTP security
   extensions that were introduced in [RFC2228], it SHOULD precede
   the security handshake.  This allows both user-PI and server-FTP
   processes to map an FTP HOST to security data appropriately.

   The following state diagram shows a typical sequence of flow of
   control when HOST is used with the AUTH and ADAT commands that are
   discussed in [RFC2228].  The explanations that were given for the
   previous diagram also apply to this diagram.

              +---+   HOST    +---+ 1,3,5
              | B |---------->| W |-----------------
              +---+           +---+                 |
                               | |                  |
                     2,500,502 | | 4,501,503,504    |
                +--------------   -------------     |
                |                              |    |
                V                              |    |
              +---+   AUTH    +---+ 4,5        |    |
              |   |---------->| W |----------->|    |
              +---+           +---+            |    |
                          234 | |              |    |
                     ---------  | 334          |    |
                    |           |              |    |
                 ---------------|------        |    |
                |   |           |      |       |    |
                V   |           V  335 |       |    |
              +---+ | ADAT    +---+----        |    |
              |   |---------->| W | 4,5        |    |

Hethmon & McMurray           Expires October 6, 2010           [Page 11]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

              +---+ |         +---+----------->|    |
                    |           |              |    |
                ----         235|              |    |
               |  --------------               |    |
               | |                             |    |
               V V                  1          |    V
              +---+   USER    +---+-------------->+---+
              |   |---------->| W | 2       ----->| E |
              +---+           +---+------  |  --->+---+
                               | |       | | | |
                             3 | | 4,5   | | | |
                 --------------   -----  | | | |
                |                      | | | | |
                |                      | | | | |
                |                ----------  | |
                |              1|      | |   | |
                V               |      | |   | |
              +---+   PASS    +---+ 2  |  ------->+---+
              |   |---------->| W |-------------->| S |
              +---+           +---+   ----------->+---+
                               | |   | |     | |
                             3 | |4,5| |     |  ----
                 --------------   --------   |      |
                |                    | |  |  |      |
                |                    | |  |  |      |
                |                ------------       |
                |            1,3|    | |  |         |
                V               |   2| |  |         V
              +---+   ACCT    +---+--  |   ------>+---+
              |   |---------->| W | 4,5 --------->| F |
              +---+           +---+-------------->+---+

3.3. HOST command errors

   The server-PI should reply with a 500 or 502 reply if the HOST
   command is unrecognized or unimplemented.  A 503 reply may be sent
   if the HOST command is given after a previous HOST command, or after
   a user has been authenticated.  Alternately, the server may define

++++
Please explain why successive HOST commands should be invalid. I can't
see a reason, and there's potential utility (e.g., to allow REIN
wrappers, as described earlier).
++++

   behavior that allows the HOST command after a user has been
   authenticated.  A 501 reply should be sent if the hostname given is
   syntactically invalid, and a 504 reply should be sent if a
   syntactically valid hostname is not a valid virtual host name for the
   server.  In all such cases, the server-FTP process should act as if
   no HOST command had been given.

   A user-PI receiving a 500 or 502 reply should assume that the
   server-PI does not implement virtual servers by using the HOST
   command.  The user-PI may then proceed to login as if the HOST
   command had succeeded, and may attempt a CWD command to the hostname
   after authenticating the user.

Hethmon & McMurray           Expires October 6, 2010           [Page 12]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

   A user-PI receiving an error reply that is different from the errors
   that have been described here should assume that the virtual HOST is
   unavailable, and terminate communications.

   A server-PI that receives a USER command, beginning the
   authentication sequence, without having received a HOST command,
   SHOULD NOT reject the USER command.  Clients conforming to earlier
   FTP specifications do not send HOST commands.  In this case the
   server may act as if some default virtual host had been explicitly
   selected, or may enter an environment different from that of any
   supported virtual hosts, perhaps one in which a union of all
   available accounts exists, and which presents an NVFS that appears
   to contain subdirectories that contain the NVFS for all supported
   virtual hosts.

3.4. FEAT response for HOST command

   A server-FTP process that supports the HOST command and virtual FTP
   servers MUST include, in the response to the FEAT command [RFC2389],
   a feature line indicating that the HOST command is supported.  This
   line should contain the single word "HOST".  This command word is
   case insensitive, but it SHOULD be transmitted in upper case only.
   That is, the response SHOULD be:

        CFEAT
        S211- <any descriptive text>
        S ...
        S HOST
        S ...
        S211 End

   The ellipses indicate place holders where other features may be
   included, and are not required.  The single space indentation of each
   feature line is mandatory [RFC2389].

4. Security Considerations

   With the introduction of virtual hosts to FTP, and the possible
   accompanying multiple authentication environments, server
   implementers will need to take some care to ensure that the integrity
   of user credentials is maintained. A general discussion of issues
   related to the security of FTP can be found in [RFC2577].

++++
I think you need to have more here, esp. on how the server MUST reset
security parameters when a HOST command is issued, and new commands
MUST be interpreted in the security context of the most recent HOST
command.
++++

####
There's also the issue of whether a server should validate the HOST
command parameters as matching the incoming connection. IMO, that is
something that the server should be checking, not the protocol, but it
might be important to note whether there should be a default (MUST
validate?) or whether there should be no such assumptions because the
HOST command argument is treated by the protocol as an opaque string
(IMO, that's the better answer here).
####

5. IANA Considerations

   IANA is requested to register the following FTP extension according
   to the procedure established by [RFC5797]:

   +-------+------+-------------------+------+------+------------------+
   | cmd   | FEAT | description       | type | conf | RFC#s/References |

Hethmon & McMurray           Expires October 6, 2010           [Page 13]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

   |       | Code |                   |      |      | and Notes        |
   +-------+------+-------------------+------+------+------------------+
   | HOST  | HOST | Hostname          | a    | o    | [#1]             |
   +-------+------+-------------------+------+------+------------------+

   [[ RFC Editor: Please update note #1 in the above table with the
   number of this document. ]]

6. References

6.1.  Normative References

   [RFC959]  Postel, J., Reynolds, J., "File Transfer Protocol (FTP)",
             STD 9, RFC 959, October 1985

   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
             STD 13, RFC 1034, November 1987

   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
             Specification", STD 13, RFC 1035, November 1987

   [RFC1123] Braden, R,. "Requirements for Internet Hosts --
             Application and Support", STD 3, RFC 1123, October 1989

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997

   [RFC2228] Horowitz, M., Lunt, S., "FTP Security Extensions",
             RFC 2228, October 1997

   [RFC2389] Hethmon, P., Elz, R., "Feature negotiation mechanism for
             the File Transfer Protocol", RFC 2389, August 1998

   [RFC2640] Curtin, W., "Internationalization of the File Transfer
             Protocol", RFC 2640, July 1999

   [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
             for Internationalized Domain Names in Applications (IDNA)",
             RFC 3492, March 2003

   [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
             October 2005

   [RFC5234] Crocker, D., Overell, P., "Augmented BNF for Syntax
             Specifications: ABNF", RFC 5234, January 2008

6.2.  Informative References

   [RFC2577] Allman, M., Ostermann, S., "FTP Security Considerations",
             RFC 2577, May 1999

Hethmon & McMurray           Expires October 6, 2010           [Page 14]

INTERNET-DRAFT      File Transfer Protocol HOST Command       April 2010

   [RFC5797] Klensin, J., Hoenes, A., "FTP Command and Extension
             Registry", March 2010

7. Acknowledgments

   Robert Elz and Paul Hethmon provided a detailed discussion of the
   HOST command in their Internet draft titled "Extensions to FTP"
   as part of their work with the FTPEXT Working Group at the IETF.
   Their work formed the basis for much of this document, and their
   help has been greatly appreciated.  They would also like to credit
   Bernhard Rosenkraenzer for having first suggested and described the
   HOST command.

   Alexey Melnikov, Alfred Hoenes, and John Klensin have made several
   suggestions about earlier versions of this document, most of which
   have been incorporated and their contributions are gratefully
   acknowledged.

8. Authors' Addresses

   Paul Hethmon
   Hethmon Brothers
   2305 Chukar Road
   Knoxville, TN 37923 USA

   Email: [email-masked]

   Robert McMurray
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399

   Email: [email-masked]

Hethmon & McMurray           Expires October 6, 2010           [Page 15]

---

From: Robert McMurray <[email-masked]>
Date: Sat, 15 May 2010 01:22:24 +0000

Hi, Joe.

Thanks very much for the feedback. You make some good points, and I am working on a new draft where I have incorporated a lot of the semantic changes that you recommended as they will make some areas of the draft a little clearer. As far as changing the title of the draft is concern, I am not opposed to changing the title, but I tried to follow the examples from other RFCs. Looking at a couple of recent RFCs like 5789 and 5689 perhaps you might prefer "HOST Command for File Transfer Protocol."

I have a few key points that I would like to discuss with regard to your analysis of the draft, although I would like to mention in advance that I believe that some areas of the draft and your subsequent analysis might be saying the same thing and we only differ semantically. If so, I might need to clarify something in order to remove any ambiguity between what I wrote and what you understood. <grin>

--------------------
1. Identifying the use of the HOST command with regard to which type of host names to which the draft is referring.
--------------------

Just to make sure that we're on the same page, the use of the HOST command will be the most advantageous to servers that want to support multiple FQDN-based FTP sites on a single server. For example, the FTP sites ftp.foo.com and ftp.bar.com are both physically located on a server at 192.168.1.1 and those two names are mapped via DNS to that IP address, or the FTP sites foo.example.com and bar.example.com are both physically located on a server at 192.168.2.1 and once again those two names are mapped via DNS to that IP address. As you alluded to in your email, HTTP accommodates this through the use of the Host header.

It is the intention for the HOST command to work in much the same way, in that a typical scenario will involve a user-FTP process making a connection to an FTP server using an IP address, and then send a HOST command with the name of the host to connect to that the server-FTP process will process accordingly. In actual practice this will most often resemble a person entering an FQDN into an FTP client software application and that application will look up the IP address to physically connect to the FTP server. Once the connection is established using the IP address, the FTP client application will then send the HOST command with the FQDN for the desired FTP site, which the FTP server will use to route the connection according to its design.

So with that in mind, the parameter for the HOST command is supposed to be indicating a hostname; this will typically be an FQDN, but that's not a requirement. For example, Windows networks can use short host names for network names, but everything in the above scenario would still hold true for a Windows network where the virtual hosts "foobar1" and "foobar2" are both physically located on the same FTP server.

But in any case, my expectation was that the parameter for the HOST command should be mapped to the IP address. As your email indicated, these are multiple virtual hosts on a single physical host. If I have not made that clear then please let me know.

--------------------
2. Overloading the USER command to differentiate hosts.
--------------------

This was an early consideration of ours, and I have seen that there are some limited FTP server implementations that resemble something similar to that already. As just one example, some versions of the Microsoft FTP server allow for USER syntax like "USER hostname|username" or "USER hostname\username" where the hostname is used to internally route the FTP request to the correct FTP site on the server. There are several reasons why this suggestion is impractical outside of a limited-scope server implementation, but one of my arguments against overloading the USER command stems from a series of discussions that were held several years ago where it was agreed that syntax like "username@hostname" is unfortunately already overloaded in a variety of scenarios and therefore simply unworkable in a practical sense.

For example, in network environments where "username@hostname is already in use as a network login where the hostname portion refers to the location of the user's credentials within the network hierarchy, that would necessitate having to determine how to implement differentiation between FTP hosts and network credential stores, and you could easily wind up with syntax like "USER username@credentialstore@ftphostname" or "USER username@ftphostname@credentialstore", or you could wind up with a scenario where an FTP service won't know the difference between "USER username@credentialstore" and "USER username@ftphostname".

--------------------
3. Passing the parameter for the HOST command as an opaque string.
--------------------

I disagree with the suggestion that the parameter for the HOST command should be an opaque string rather than constraining the parameter through the protocol. The intention of this draft is to allow an FTP client to specify the correct hostname (typically an FQDN) for an FTP server to use after an FTP client has connected, so that limits the parameter for the HOST command to hostnames that are already constrained by protocol, although I tried to make allowances for an FTP client to send the IP address via the HOST command rather than force the client to know the difference between an FQDN and an IP address. (An actual human using an FTP client should be able to tell the difference, of course, but their FTP software application might not. <grin>)

In any event, I am still working on an updated draft. Thanks again for the feedback.

Robert

-----Original Message-----
From: Joe Touch [mailto:[email-masked]]
Sent: Thursday, May 06, 2010 10:48 AM
To: IETF discussion list
Cc: TSV Dir; [email-masked]; [email-masked]
Subject: TSV-DIR review of draft-hethmon-mcmurray-ftp-hosts-11.txt

Hi, all,

I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [email-masked] if you reply to or forward this review.

The document defines a new FTP command called "HOST" that allows an FTP server to support virtual hosts, i.e., multiple hosts on the same IP address.

The document does raise an important concern from a transport viewpoint.
The document extends FTP to support the same kind of virtual hosting common in the web. Although the Internet defines hosts by IP address, virtual hosts are specified in various ways, including DNS names, that may or may not map to the IP address of the connection to the server.

The extension is discussed in ways that imply that the user is connecting to a HOST as indicated in the command, rather than the IP address of the FTP connection. IMO, the HOST command ought to be presented more as a way to provide context within a host, not to indicate a host. That might be acheived by a name change (VHOST?) and/or by revising some of the discussion accordingly.

Thus, I would strongly suggest the document be revised as follows. Notes are included below that indicate places where thes critical issues should be addressed, flagged by "####".
--
This document should emphasize that the argument to the host command is, at the protocol level, an opaque string passed to the application that indicates only a session context (including authentication, file system, etc.). There should be no attempt for the protocol to validate, translate, or interpret that string - e.g., as matching the IP address of the connection, or providing a valid IP address or fqdn. That validation can be performed by the server implementation, but should not be a constraint of the protocol.

There are places where SHOULDs are used where I expected MUSTs. Any place a SHOULD is used, the document ought to include a description of what happens if not, i.e., if the SHOULD is not followed, and it'd be useful to also include reasons why and conditions where this might be useful or valid.

Also, in terminology, the document would benefit from a bit of clarification and revision, notably its title and description of the purpose of this command. The HOST command performes much the same function as HTTP including the full URL in the GET command, which similarly allows virtual hosting. The document should avoid confusing this with multi-homing, which is not necessarily related.
--

I have provided some other feedback interspersed in the text below (flagged with "++++"). The most notable is the issue of how to handle multiple HOST commands, the potential for HOST commands after the USER command (without a REIN command), and updating the state machine to include the effects of REIN interactions with the HOST command.

I also found numerous places where "should" or "must" are used but not capitalized; the document should be checked for these uses to confirm the intent. If case is important, then Section 2 should include text to indicate such (as noted there).

I'd like to also suggest that the alternatives discussed might consider an opportunity to integrate this command with the USER command to accept "name[@hoststring]" arguments, e.g., [email-masked] This syntax would suffice, and might need only an additional error code (to indicate that the hoststring is not valid, rather than the entire command argument), rather than defining a new name and introducing an additional round trip into the login process. It seems equally compatible with the wrapper approach discussed (which, IMO, should also be noted as a goal of the design, FWIW).

Joe

---------------------

####
The title should more accurately indicate the nature of the command, e.g., "The File Transfer Protocol HOST Command for Virtual Hosts"
####

Abstract

####
Multihoming is when a single host has more than one IP address This extension supports 'virtual hosts', where more than one fully-qualified DNS name (fqdn) resolves to the same IP address.

1. Introduction

++++
It is common in the Internet to allow multiple DNS host names to resolve to the same IP address.

++++
physical resources
++++

   similar hosts.

####
an FTP server distinguishes incoming FTP connections by their IP address, not their DNS names, because hosts are uniquely identified by address rather than name. That is, all DNS names that share an IP...
####

++++

++++
[it's worth pointing out here that a similar situation existed for the web many years ago, and how it was resolved, and that you want to do the same thing here basically]
++++

####
I think you mean to say that "Any scheme to overcome this needs to indicate not only the destination IP address, but also a name associated with the desired virtual FTP server. This information is currently discarded in the FTP application at the user interface of the client."

(note: I used the term "name" - not DNS name here; see preface text as to why) ####

++++
I don't know why the following section is in the intro. You do need to discuss alternatives not pursued, but maybe later.
++++

++++
I think the above is too glib. The first point is worth noting - that it is available only after the connection is established, and so cannot be used to determine per-host parameters (including, but not limited to, authentication). The second point can easily be overcome with an optional standard prefix to the CWD command, e.g.:

        CWD fqdn:{path}

The ability of the user to move between virtual FTP servers can be seen as a benefit, not a liability. The question is whether the benefit is needed, and whether it presents new problems (e.g., re-authenticating on different servers may not be feasible).
++++

++++
I think this is easier to state. The problem is that you need to do ACCT before you do USER or PASS, since you don't know on what virtual server to validate the first two.

I.e., same issue as before. Don't beat a dead horse, just note it and move on.
++++

++++

         vhostname:username

        username@vhostname

That seems like it's also potentially more easily understood to users (it's already supported by many FTP command lines using that syntax), and reduces the login by one round trip exchange as well.
++++

2. Document Conventions

++++
The document uses these terms in lower case, presumably not as key words. If that is desired, it would be useful to be explicit about the difference, e.g., by including the following text:

2.1. Basic Tokens

2.2. Server Replies

3. The HOST command

####
When can this command ever come AFTER a user is authenticated? Is that ever intended to be valid? If not, then change the SHOULD to MUST. However, as noted above, embedding this info in the USER command would have achieved the same effect without requiring protocol machinery to determine the order of commands.
####

++++
This is further evidence that this info might be easier to embed in the USER command. The REIN effectively does a logout, and then the next USER command would be expected to have the needed vhostname information anyway.
++++

####
IMO,
     hostname = bytetring

I see no reason to specify it further. To the protocol, it can/should be opaque. The server can decide whether it likes it or not. If I want to call a vhost "mickey_mouse!!@@##" I should be able to, IMO.

     h16           = 1*4HEXDIG

     dec-octet     = DIGIT                 ; 0-9
                     / %x31-39 DIGIT       ; 10-99
                     / "1" 2DIGIT          ; 100-199

####
I disagree with the above paragraph. The contents of the hostname argument MUST be opaque to the protocol.

The remainder of this section (and/or document) needs to be updated accordingly, IMO.

That also means that the client can send what it wants - fully qualified or not. That's up to the client implentation to decide. The semantics of that name should be meaningless to the protocol.
####

####
This might say that internationalization of the opaque string is handled via Punycode. It should not refer to domain names per se; that is an interpretation that can be made by the server, but must not be assumed in the protocol.
####

####
First, these strings ought to be opaque to the protocol. The server can decide to check them, but the protocol MUST NOT, IMO.

Note, though, that even if the server interprets them, let's discuss whether the server should do the above or not (i.e., this would be an implementation/configuration choice, not a protocol requirement, if so).

If you are intending to support only virtual hosting, then there is never a need to send the IP address in a HOST command. However, if you do want to allow it for completeness, then it MUST respond with a 504 if the address does not match (this can't be a SHOULD unless there is a valid reason for either another response, or a valid action, and this doc doesn't argue for either).

However, there could be a case where the FTP server listens on multiple addresses on a multihomed host. In that case, this command would appear to provide a valid way to connect to one address and access the data on the other. Since this would succeed (even if not
intended!) if the user had provided a fqdn, I see no reason why it should fail when they provide an IP address. Consider:

       a.example.net = 10.0.0.1

A user might issue:

if that works (and I can't see why it wouldn't, so far), then the following should also work:

If you don't want either example to work, then you missed a step on the HOST command:

    HOST fqdn

HOWEVER, I strongly discourage this sort of rule. Overall, IMO, the HOST command takes an *arbitrary* argument that is interpreted *only* as the context of access control and the NVFS. As a result, *all* such checks that attempt to match any contents of this identifier to the current connection MUST NOT be prohibited by the protocol (the server configuration MAY check these or not, as supported and/or configured).
####

++++
This doesn't make sense; below you prohibit the use of port numbers in the command, so why do you need to disambiguate them?
++++

        HOST 192.0.2.1
        HOST [FE80::c000:0201]
        HOST [::192.0.2.1]

####

Further ports MUST be allowed to be specified either by their number or their service name (e.g., "ftp"), IMO.

I would assume that service names MUST NOT be translated or validated by the protocol, just as the fqdn MUST NOT be. The server implementation MAY check/translate these as needed to coordinate with their configuration, but this is outside the scope of the protocol, IMO.
####

####
None of this should be validated, translated, or checked in the protocol. The server implementation can decide whether it likes the name, or it matches its configuration tables.
####

++++
It might be useful to mention other changes, such as using different username/password lists.
++++

####
Agreed - that is a server configuration issue. It's important to note here that this MUST NOT be checked in the protocol itself, though.
####

++++
If you say SHOULD, you ought to indicate conditions under which you might not, i.e., when would you not reply with 421? would you reply with a different code, or just wait? It's not useful to include SHOULDs without giving a hint as to why they are not MUSTs, IMO.
++++

++++
A wrapper could as easily wait for a custom response command. I am not sure why the response command is the same as for the initial connection. Many other commands have their own response codes; IMO, this should as well:

++++

(i.e., the FTP authentication and NVFS parameters are set to the initial connection default after a REIN command).
++++

++++

     CHOSTIS
     SHOST a.example.com

     CHOST

(note: you now need to allow successive HOST commands to be permitted after either login on REIN)
++++

        CHOST foobar.com
        S220 Host accepted

++++
I think you need to say:

However, I prefer:
          S260 HOST accepted
++++

        CUSER foo
        S331 Password required
        CPASS bar
        S230 User logged in

        CHOST foobar.com
        CUSER foo
        CPASS bar
        CACCT project1

        CHOST foobar.com
        CAUTH <mechanism-name>
        CADAT <base64data>
        CUSER foo
        CPASS bar
        CACCT project1

3.2.3. State Diagrams

####

It should also show how the REIN command sets you back to a state where you can accept new HOST commands.
####

              +---+   HOST    +---+ 1,3,5

                |                      | | | | |
                |                ----------  | |
                |              1|      | |   | |
                V               |      | |   | |

              +---+   HOST    +---+ 1,3,5

3.3. HOST command errors

++++
Please explain why successive HOST commands should be invalid. I can't see a reason, and there's potential utility (e.g., to allow REIN wrappers, as described earlier).
++++

        CFEAT

++++
I think you need to have more here, esp. on how the server MUST reset security parameters when a HOST command is issued, and new commands MUST be interpreted in the security context of the most recent HOST command.
++++

####
There's also the issue of whether a server should validate the HOST command parameters as matching the incoming connection. IMO, that is something that the server should be checking, not the protocol, but it might be important to note whether there should be a default (MUST
validate?) or whether there should be no such assumptions because the HOST command argument is treated by the protocol as an opaque string (IMO, that's the better answer here).
####

5. IANA Considerations

6. References

7. Acknowledgments

8. Authors' Addresses

   Paul Hethmon
   Hethmon Brothers
   2305 Chukar Road
   Knoxville, TN 37923 USA

   Robert McMurray
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 May 2010 10:06:37 -0700

Hi, Robert,

Some clarification below, which I hope will be useful. Overall, most of
my points were minor and I'd be glad to discuss them either offline or
on the list.

Joe

Robert McMurray wrote:
> Hi, Joe.
> 
> Thanks very much for the feedback. You make some good points, and I 
> am working on a new draft where I have incorporated a lot of the
> semantic changes that you recommended as they will make some areas of
> the draft a little clearer. As far as changing the title of the draft
> is concern, I am not opposed to changing the title, but I tried to
> follow the examples from other RFCs. Looking at a couple of recent
> RFCs like 5789 and 5689 perhaps you might prefer "HOST Command for
> File Transfer Protocol."

My concern is whether it would be useful to be more clear about the
reason for the command, rather than just naming the command. I
appreciate that this may not have been addressed in other RFCs for FTP
commands, but would prefer if this were decided on its own merit rather
than merely past examples. Regardless, this is a very minor concern, though.

> I have a few key points that I would like to discuss with regard to 
> your analysis of the draft, although I would like to mention in
> advance that I believe that some areas of the draft and your
> subsequent analysis might be saying the same thing and we only differ
> semantically. If so, I might need to clarify something in order to
> remove any ambiguity between what I wrote and what you understood.
> <grin>
> 
> --------------------
> 1. Identifying the use of the HOST command with regard to which type
> of host names to which the draft is referring.
> --------------------
> 
> Just to make sure that we're on the same page, the use of the HOST 
> command will be the most advantageous to servers that want to support
>  multiple FQDN-based FTP sites on a single server. For example, the
> FTP sites ftp.foo.com and ftp.bar.com are both physically located on
> a server at 192.168.1.1 and those two names are mapped via DNS to
> that IP address, or the FTP sites foo.example.com and bar.example.com
> are both physically located on a server at 192.168.2.1 and once again
> those two names are mapped via DNS to that IP address. As you alluded
> to in your email, HTTP accommodates this through the use of the Host
> header.

Yes, we're on the same page here.

> It is the intention for the HOST command to work in much the same 
> way, in that a typical scenario will involve a user-FTP process
> making a connection to an FTP server using an IP address, and then
> send a HOST command with the name of the host to connect to that the
> server-FTP process will process accordingly. In actual practice this
> will most often resemble a person entering an FQDN into an FTP client
> software application and that application will look up the IP address
> to physically connect to the FTP server. Once the connection is
> established using the IP address, the FTP client application will
> then send the HOST command with the FQDN for the desired FTP site,
> which the FTP server will use to route the connection according to
> its design.
> 
> So with that in mind, the parameter for the HOST command is supposed 
> to be indicating a hostname; this will typically be an FQDN, but
> that's not a requirement. For example, Windows networks can use short
> host names for network names, but everything in the above scenario
> would still hold true for a Windows network where the virtual hosts
> "foobar1" and "foobar2" are both physically located on the same FTP
> server.
>
> But in any case, my expectation was that the parameter for the HOST 
> command should be mapped to the IP address. As your email indicated, 
> these are multiple virtual hosts on a single physical host. If I have
> not made that clear then please let me know.

Nope - we're on the same page there. I now see why you want to ensure it
is a FQDN, though I think there's utility to considering this more
generally. More below...

> This was an early consideration of ours, and I have seen that there 
> are some limited FTP server implementations that resemble something 
> similar to that already. As just one example, some versions of the 
> Microsoft FTP server allow for USER syntax like "USER
> hostname|username" or "USER hostname\username" where the hostname is
> used to internally route the FTP request to the correct FTP site on
> the server. There are several reasons why this suggestion is
> impractical outside of a limited-scope server implementation, but one
> of my arguments against overloading the USER command stems from a
> series of discussions that were held several years ago where it was
> agreed that syntax like "username@hostname" is unfortunately already
> overloaded in a variety of scenarios and therefore simply unworkable
> in a practical sense.
> 
> For example, in network environments where "username@hostname is 
> already in use as a network login where the hostname portion refers
> to the location of the user's credentials within the network
> hierarchy, that would necessitate having to determine how to
> implement differentiation between FTP hosts and network credential
> stores, and you could easily wind up with syntax like "USER 
> username@credentialstore@ftphostname" or "USER 
> username@ftphostname@credentialstore", or you could wind up with a 
> scenario where an FTP service won't know the difference between "USER
> username@credentialstore" and "USER username@ftphostname".

I believe your version of the command already overloads these two as
equivalent, i.e., "HOST vhostname" already overloads the command with
both indicating the credentialstore of the subsequent USER command and
the ftphostname. As a result, I don't see why putting this at the end of
the username needs to be confusing - it means the same thing (i.e., both
credentialstore and ftphostname).

My point here is that if you're discussing alternatives, you need to
address why this alternative was not used. There may be useful reasons
(in specific, using a separate command allows you to reuse some error
codes more usefully), but you're also incurring an extra round trip,
which people tend to count these days.

> --------------------
> 
> I disagree with the suggestion that the parameter for the HOST 
> command should be an opaque string rather than constraining the
> parameter through the protocol. The intention of this draft is to
> allow an FTP client to specify the correct hostname (typically an
> FQDN) for an FTP server to use after an FTP client has connected, so
> that limits the parameter for the HOST command to hostnames that are
> already constrained by protocol, although I tried to make allowances
> for an FTP client to send the IP address via the HOST command rather
> than force the client to know the difference between an FQDN and an
> IP address. (An actual human using an FTP client should be able to
> tell the difference, of course, but their FTP software application
> might not. <grin>)

My primary concern with assuming this is a FQDN is giving the
misimpression that FQDNs name Internet hosts, rather than the idea that
this command really uses an arbitrary string to identify a vhost --
which has no requirement of how it must be named (AFAICT).

I don't disagree that the app might check and only allow FQDNs, but I
don't see why the protocol needs to check this. Glad to discuss this
further if useful, but again this is a minor point.

Joe

> I've reviewed this document as part of the transport area 
> directorate's ongoing effort to review key IETF documents. These 
> comments were written primarily for the transport area directors, but
>  are copied to the document's authors for their information and to
> allow them to address any issues raised. The authors should consider
> this review together with any other last-call comments they receive.
> Please always CC [email-masked] if you reply to or forward this
> review.
> 
> The document defines a new FTP command called "HOST" that allows an 
> FTP server to support virtual hosts, i.e., multiple hosts on the same
> IP address.
> 
> The document does raise an important concern from a transport 
> viewpoint. The document extends FTP to support the same kind of 
> virtual hosting common in the web. Although the Internet defines
> hosts by IP address, virtual hosts are specified in various ways,
> including DNS names, that may or may not map to the IP address of the
> connection to the server.
> 
> indicate a host. That might be acheived by a name change (VHOST?)
> and/or by revising some of the discussion accordingly.
> 
> Thus, I would strongly suggest the document be revised as follows. 
> Notes are included below that indicate places where thes critical
> issues should be addressed, flagged by "####". -- This document
> should emphasize that the argument to the host command is, at the
> protocol level, an opaque string passed to the application that
> indicates only a session context (including authentication, file 
> system, etc.). There should be no attempt for the protocol to
> validate, translate, or interpret that string - e.g., as matching the
> IP address of the connection, or providing a valid IP address or
> fqdn. That validation can be performed by the server implementation,
> but should not be a constraint of the protocol.
> 
> place a SHOULD is used, the document ought to include a description
> of what happens if not, i.e., if the SHOULD is not followed, and it'd
> be useful to also include reasons why and conditions where this might
> be useful or valid.
> 
>  this with multi-homing, which is not necessarily related. --
> 
>  multiple HOST commands, the potential for HOST commands after the
> USER command (without a REIN command), and updating the state machine
> to include the effects of REIN interactions with the HOST command.
> 
> I also found numerous places where "should" or "must" are used but 
> not capitalized; the document should be checked for these uses to
> confirm the intent. If case is important, then Section 2 should
> include text to indicate such (as noted there).
> 
> I'd like to also suggest that the alternatives discussed might 
> consider an opportunity to integrate this command with the USER
> command to accept "name[@hoststring]" arguments, e.g.,
> [email-masked] This syntax would suffice, and might need only
> an additional error code (to indicate that the hoststring is not
> valid, rather than the entire command argument), rather than defining
> a new name and introducing an additional round trip into the login
> process. It seems equally compatible with the wrapper approach
> discussed (which, IMO, should also be noted as a goal of the design,
> FWIW).
> 
> The title should more accurately indicate the nature of the command,
> e.g., "The File Transfer Protocol HOST Command for Virtual Hosts"
> ####
> 
> Abstract
> 
> address, not their DNS names, because hosts are uniquely identified
> by address rather than name. That is, all DNS names that share an
> IP...
> ####
> 
> [it's worth pointing out here that a similar situation existed for 
> the web many years ago, and how it was resolved, and that you want to
> do the same thing here basically]
> ++++
> 
> (note: I used the term "name" - not DNS name here; see preface text 
> as to why)
> ####
> 
> I don't know why the following section is in the intro. You do need
> to discuss alternatives not pursued, but maybe later.
> ++++
> 
> (it's already supported by many FTP command lines using that
> syntax), and reduces the login by one round trip exchange as well.
> ++++
> 
> 
> 2. Document Conventions
> 
> When can this command ever come AFTER a user is authenticated? Is 
> that ever intended to be valid? If not, then change the SHOULD to
> MUST. However, as noted above, embedding this info in the USER
> command would have achieved the same effect without requiring
> protocol machinery to determine the order of commands.
> ####
> 
> be opaque. The server can decide whether it likes it or not. If I
> want to call a vhost "mickey_mouse!!@@##" I should be able to, IMO.
> 
>  semantics of that name should be meaningless to the protocol.> ####
> 
> handled via Punycode. It should not refer to domain names per se;
> that is an interpretation that can be made by the server, but must
> not be assumed in the protocol.
> ####
> 
> never a need to send the IP address in a HOST command. However, if
> you do want to allow it for completeness, then it MUST respond with a
> 504 if the address does not match (this can't be a SHOULD unless
> there is a valid reason for either another response, or a valid
> action, and this doc doesn't argue for either).
> 
> as the context of access control and the NVFS. As a result, *all*
> such checks that attempt to match any contents of this identifier to
> the current connection MUST NOT be prohibited by the protocol (the
> server configuration MAY check these or not, as supported and/or
> configured).
> ####
> 
> This doesn't make sense; below you prohibit the use of port numbers
> in the command, so why do you need to disambiguate them?
> ++++
> 
> A wrapper could as easily wait for a custom response command. I am 
> not sure why the response command is the same as for the initial
>         CAUTH <mechanism-name>         CADAT <base64data>         CUSER foo
>         CPASS bar
>         CACCT project1
> 
> 3.2.3. State Diagrams
> 
> Please explain why successive HOST commands should be invalid. I 
> can't see a reason, and there's potential utility (e.g., to allow
> REIN wrappers, as described earlier).
> ++++
> 
>         S211- <any descriptive text>         S ...
>         S HOST
>         S ...
>         S211 End
> 
> something that the server should be checking, not the protocol, but
> it might be important to note whether there should be a default (MUST
>  validate?) or whether there should be no such assumptions because
> the HOST command argument is treated by the protocol as an opaque
> string (IMO, that's the better answer here).
> ####
> 
> 5. IANA Considerations
>

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 May 2010 14:23:09 -0700

> which people tend to count these days.
Joe,

The use of AUTH follows HOST and precedes USER and PASS.  Your 
suggestion of combining USER+HOST exposes USER.

International consensus was reached between the ISO, IETF, ITU, and 
UNCEFACT on use of UTF-8 for interoperability.  However, this draft 
requires Puny-code input for international domain names.  While 
Puny-code allows IDNs to be encoded using ASCII, Puny-code is not 
intended as a human interface, nor is Puny-code interoperable with 
existing name services, and certificate validations.  Distinguished 
names in certs are UTF-8 encoded.   Local name services such as LLMNR, 
mDNS or Bonjour resolve domain names using UTF-8 queries.

Don't assume a server responding represents a valid server for the 
host.  More attention should be given to client compliance checks and 
the human interface.

-Doug

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 May 2010 23:39:57 +0200 (MEST)

> mDNS or Bonjour resolve domain names using UTF-8 queries.

There may be a misunderstanding.

When performing server endpoint identification (similar to what is
suggested for HTTP over TLS in rfc-2818), then the prefered method
is to match against dNSName subjectAltNames, which are IA5String.

Hostnames in the CN= part of certificates are also pure IA5Strings,
because hostnames were pure IA5Strings when this scheme was
originally devised and it has been deprecated many years ago.

-Martin