[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 draft-ietf-ftpext2-hosts

Network Working Group                                         P. Hethmon
INTERNET-DRAFT                                          Hethmon Brothers
draft-hethmon-mcmurray-ftp-hosts-01.txt                      R. McMurray
Updates: 959                                                   Microsoft
Category: Experimental                                         July 2008


                  File Transfer Protocol HOST Command

Status of this Internet-Draft

   This draft defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this draft is unlimited.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

Copyright Notice

   Copyright (C) The IETF Trust (2007).  All Rights Reserved.

Abstract

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

   This document addresses the subject of creating multi-homed FTP hosts
   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.

Table of Contents

   1. Overview ........................................................2
   2. Document Conventions  ...........................................3
     2.1. Basic Tokens  ...............................................3
     2.2. Server Replies  .............................................3
   3. The HOST command ................................................4
     3.1. Syntax of the HOST command ..................................4
     3.2. HOST command semantics ......................................5
       3.2.1. The REIN command  .......................................6
       3.2.2. User-PI usage of HOST ...................................6
     3.3. HOST command errors .........................................7
     3.4. FEAT response for HOST command ..............................8
   4. Security Considerations .........................................8

Hethmon & McMurray          Expires November 26, 2008           [Page 1]


INTERNET-DRAFT       File Transfer Protocol HOST Command       July 2008

   5. References ......................................................8
   6. Acknowledgments .................................................9
   7. Authors' Addresses ..............................................9

1.  Overview

   It has become common in the Internet for many domain names to be
   allocated to a single IP address.  This 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,
   other such hosts.

   Such an arrangement presents some problems for FTP Servers, as all
   the FTP Server can detect is an incoming FTP connection to a
   particular IP address.  That is, all domain names which share the IP
   address also share the FTP server, and more importantly, its NVFS.

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

   No scheme can overcome this without modifications of some kind to the
   user-PI and the user-FTP process.  That process is the only entity
   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.

   One method which 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 supported by essentially all server-FTP implementations 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.  Second, either the server-FTP process needs
   to be modified to understand 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, or the virtual host will not be
   truly transparent.  Third, and again unless the server is specially
   modified, a user connecting this way to a virtual host would be able
   to trivially move to any other virtual host supported at the same
   server-FTP process, exposing the nature of the virtual host.


Hethmon & McMurray          Expires November 26, 2008           [Page 2]


INTERNET-DRAFT       File Transfer Protocol HOST Command       July 2008

   Other schemes overloading other existing FTP commands have also been
   proposed.  None of those have sufficient merit to be worth
   discussion.

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

2. Document Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
   as shown) are to be interpreted as described in RFC 2119 [2].

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

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

   Syntax required is defined using the Augmented BNF defined in [3].
   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 A of
   [3].  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

   The VCHAR (from [3]) and TCHAR types 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 added by this specification have names that can be
   represented in any case.  That is, "HOST" is the same as "host",
   "Host" and "HoSt" etc.  However note that ALPHA, in particular, is
   case sensitive.


Hethmon & McMurray          Expires November 26, 2008           [Page 3]


INTERNET-DRAFT       File Transfer Protocol HOST Command       July 2008

2.2. Server Replies

   Section 4.2 of RFC 959 [1] 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

   Implementors should note that the ABNF syntax (which was not used in
   RFC 959 [1]) 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.  Implementors 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 RFC 959 [1].

   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
   server-FTP process to determine to which of possibly many virtual
   hosts the client wishes to connect.  This command is intended to be
   issued before the user is authenticated, allowing the authentication
   scheme, and set of legal users, to be dependent upon the virtual host
   chosen.  Server-FTP processes may, if they desire, permit the HOST
   command to be issued after the user has been authenticated, or may
   treat that as an erroneous sequence of commands.  The behavior of the
   server-FTP process which does allow late HOST commands is undefined.
   One reasonable interpretation would be for the user-PI to be returned
   to the state that existed after the TCP connection was first
   established, before user authentication.

   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 have determined supported languages, or
   representations, for the message, and other messages, via the FEAT
   response, and selected an appropriate one via the LANG command.  See
   [5] for more information.

3.1. Syntax of the HOST command

   The HOST command is defined as follows.

        host-command     = "Host" SP hostname CRLF
        hostname         = 1*DNCHAR 1*( "." 1*DNCHAR ) [ "." ]
        DNCHAR           = ALPHA / DIGIT / "-" / "_" / "$" /

Hethmon & McMurray          Expires November 26, 2008           [Page 4]


INTERNET-DRAFT       File Transfer Protocol HOST Command       July 2008

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

   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 name that
   was used to obtain the IP address to which the FTP control connection
   was made, after any client conversions to 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.

   If the client was given a network literal address, and consequently
   was not required to derive it from a hostname, it should send the
   HOST command with the network address, as specified to it, enclosed
   in brackets (after eliminating any syntax, which might also be
   brackets, but is not required to be, from which the server deduced
   that a literal address had been specified.) That is, for example

                         HOST [10.1.2.3]

   should be sent if the client had been instructed to connect to
   "10.1.2.3", or "[10.1.2.3]", or perhaps even IPv4:10.1.2.3.  The
   method of indicating to a client that a literal address is to be used
   is beyond the scope of this specification.

   The parameter is otherwise to be treated as a "complete domain name",
   as that term is defined in section 3.1 of RFC 1034 [7].  That
   implies that the name is to be treated as a case independent string,
   in that upper case ASCII characters are to be treated as equivalent
   to the corresponding lower case 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.

   RFC 1034 imposes no other restrictions upon what kinds of names can
   be stored in the DNS.  Nor does RFC 1035.  This specification,
   however, allows only a restricted set of names for the purposes of
   the HOST command.  Those restrictions 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 so, establish the
   appropriate environment for that virtual host.  The meaning of that
   is not specified here, and may range from doing nothing at all, or

Hethmon & McMurray          Expires November 26, 2008           [Page 5]


INTERNET-DRAFT       File Transfer Protocol HOST Command       July 2008

   performing a simple change of working directory, to much more
   elaborate state changes, as required.

   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.

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

   The "220" reply code for the HOST command is the same as the code
   used on the initial connection established "welcome" message.  This
   is done deliberately so as to allow the implementation to implement
   the front-end FTP server as a wrapper which simply waits for the HOST
   command, and then invokes an older, RFC 959 compliant, server in the
   appropriate environment for the particular hostname received.

3.2.1. The REIN command

   As specified in RFC 959 [1], the REIN command returns the state of
   the connection to that it was immediately after the transport
   connection was opened.  That is not changed here.  The effect of a
   HOST command will be lost if a REIN command is performed, a new HOST
   command must be issued.

   Implementors of user-FTP should be aware that server-FTP
   implementations which implement the HOST command as a wrapper around
   older implementations will be unable to correctly implement the REIN
   command.  In such an implementation, REIN will typically return the
   server-FTP to the state that existed immediately after the HOST
   command was issued, instead of to the state immediately after the
   connection was opened.

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 state diagram shows a typical sequence of flow of
   control, where the "B" (begin) state is assumed to occur after the
   transport connection has opened, or a REIN command has succeeded.
   Other commands (such as FEAT [4]) which require no authentication may
   have intervened.  This diagram is modeled upon (and largely borrowed

Hethmon & McMurray          Expires November 26, 2008           [Page 6]


INTERNET-DRAFT       File Transfer Protocol HOST Command       July 2008

   from) the similar diagram in section 6 of RFC 959 [1].

   In this diagram, a three digit reply indicates that precise server
   reply code, a single digit on a reply path indicates any server reply
   beginning with that digit, other than any three digit replies that
   might take another path.

   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".


              +---+   HOST    +---+ 1,3,5
              | B |---------->| W |-----------------
              +---+           +---+                 |
                               | |                  |
                     2,500,502 | | 4,501,503,504    |
                 --------------   -------------     |
                |                              |    |
                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

Hethmon & McMurray          Expires November 26, 2008           [Page 7]


INTERNET-DRAFT       File Transfer Protocol HOST Command       July 2008

   a user has been authenticated.  Alternately, the server may accept
   the command at such a time, with server-defined behavior.  A 501
   reply should be sent if the hostname given is syntactically invalid,
   and a 504 reply 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 the HOST command style virtual server.
   It may then proceed to login as if the HOST command had succeeded,
   and perhaps, attempt a CWD command to the hostname after
   authenticating the user.

   A user-PI receiving some other error reply 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 all
   supported virtual hosts, perhaps one in which a union of all
   available accounts exists, and which presents a NVFS which appears to
   contain sub-directories containing the NVFS for all virtual hosts
   supported.

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 [4], a
   feature line indicating that the HOST command is supported.  This
   line should contain the single word "HOST".  This MAY be sent in
   upper or lower case, or a mixture of both (it is case insensitive)
   but SHOULD be transmitted in upper case only.  That is, the response
   SHOULD be

        C> Feat
        S> 211- <any descriptive text>
        S>  ...
        S>  HOST
        S>  ...
        S> 211 End

   The ellipses indicate place holders where other features may be
   included, and are not required.  The one space indentation of the
   feature lines is mandatory [4].

4. Security Considerations

Hethmon & McMurray          Expires November 26, 2008           [Page 8]


INTERNET-DRAFT       File Transfer Protocol HOST Command       July 2008


   With the introduction of virtual hosts to FTP, and the possible
   accompanying multiple authentication environments, server
   implementors will need to take some care to ensure that integrity is
   maintained.

   A general discussion of issues related to the security of FTP can be
   found in [8].

5. References

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

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

   [3]  Crocker, D., Overell, P., "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997

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

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

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

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

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

6. 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.

7. Authors' Addresses

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

Hethmon & McMurray          Expires November 26, 2008           [Page 9]


INTERNET-DRAFT       File Transfer Protocol HOST Command       July 2008


   Email: phethmon@hethmon.com

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

   Email: robmcm@microsoft.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).  All Rights Reserved.

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be

Hethmon & McMurray          Expires November 26, 2008          [Page 10]


INTERNET-DRAFT       File Transfer Protocol HOST Command       July 2008

   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.






































Hethmon & McMurray          Expires November 26, 2008          [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/