Skip to main content

File Transfer Protocol HOST Command for Virtual Hosts
draft-hethmon-mcmurray-ftpext-ftp-hosts-05

Revision differences

Document history

Date Rev. By Action
2014-03-07
05 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-03-03
05 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-02-24
05 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-01-17
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-01-17
05 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2014-01-17
05 (System) RFC Editor state changed to EDIT
2014-01-17
05 (System) Announcement was received by RFC Editor
2014-01-16
05 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-01-16
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-01-16
05 (System) IANA Action state changed to In Progress
2014-01-16
05 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2014-01-16
05 Amy Vezza IESG has approved the document
2014-01-16
05 Amy Vezza Closed "Approve" ballot
2014-01-16
05 Amy Vezza Ballot approval text was generated
2014-01-16
05 Barry Leiba State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2014-01-16
05 Naveen Khan New revision available
2014-01-16
04 Sean Turner
[Ballot comment]
After discussing with the Apps AD, I'd prefer that there's some kind of recommendation for the support of TLS for protecting communications between …
[Ballot comment]
After discussing with the Apps AD, I'd prefer that there's some kind of recommendation for the support of TLS for protecting communications between the UA and the host.
2014-01-16
04 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2014-01-15
04 Sean Turner
[Ballot discuss]
Updated to clear the first part based on email exchange with author.  Researching the next bit.

This draft draws a comparison to HTTP …
[Ballot discuss]
Updated to clear the first part based on email exchange with author.  Researching the next bit.

This draft draws a comparison to HTTP for this draft's HOST command, I would like to draw another to the HTTP Basic Authentication schemes which when used MUST be paired with TLS.  And that is ... if the "security" extensions from RFC 2228 are to be used after a HOST command is issued or if the user name and password are to be exchanged after a HOST command then TLS MUST be used.
2014-01-15
04 Sean Turner Ballot discuss text updated for Sean Turner
2013-12-19
04 Gunter Van de Velde Request for Early review by OPSDIR Completed: Ready. Reviewer: Susan Hares.
2013-12-19
04 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Susan Hares
2013-12-19
04 Gunter Van de Velde Request for Early review by OPSDIR is assigned to Susan Hares
2013-12-12
04 Sean Turner
[Ballot discuss]
One of the big issues with TLS is how to represent and verify the identity of applications (see RFC 6125).  RFC 5280 …
[Ballot discuss]
One of the big issues with TLS is how to represent and verify the identity of applications (see RFC 6125).  RFC 5280 specifies how the FTP URI is used in the certificate something like ftp://192.0.2.1.  s3.1 of this document says that the address can include square brackets.  Is this document updating RFC 5280? Does the server_name included in the TLS handshake also include these brackets?

This draft draws a comparison to HTTP for this draft's HOST command, I would like to draw another to the HTTP Basic Authentication schemes which when used MUST be paired with TLS.  And that is ... if the "security" extensions from RFC 2228 are to be used after a HOST command is issued or if the user name and password are to be exchanged after a HOST command then TLS MUST be used.
2013-12-12
04 Sean Turner Ballot discuss text updated for Sean Turner
2013-11-04
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-11-04
04 Cindy Morgan New revision available
2013-10-31
03 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2013-10-24
03 Cindy Morgan State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2013-10-24
03 Ted Lemon
[Ballot comment]
Section 3.1 copies ABNF from RFC 3986 rather than incorporating it by reference.  The reader most likely knows what an IPv4 address and …
[Ballot comment]
Section 3.1 copies ABNF from RFC 3986 rather than incorporating it by reference.  The reader most likely knows what an IPv4 address and an IPv6 address looks like, and if they don't they can refer to RFC 3986.  So I would really encourage you to incorporate these by reference rather than copying the text.  Copying the text invites errors, and I don't think it adds value.

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

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

Does this mean "if the user agent is going to send a HOST command, it MUST send it before it authenticates?"  Or does it mean "User agents implementing this specification MUST send a HOST command before authenticating?"    I think it means the latter, but it could be read as meaning the former.
2013-10-24
03 Ted Lemon [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss
2013-10-24
03 Jari Arkko
[Ballot comment]
I'm clearing and making my discuss a comment; you now know the issue and I do not have a strong opinion about how …
[Ballot comment]
I'm clearing and making my discuss a comment; you now know the issue and I do not have a strong opinion about how to fix it. Here were my two significant comments:

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

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

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

See also Meral's Gen-ART review.
2013-10-24
03 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss
2013-10-24
03 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-10-24
03 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-10-23
03 Ted Lemon
[Ballot discuss]
Section 3, paragraph 1:
  This command MUST be
  issued before the user is authenticated, as this will allow the
  authentication …
[Ballot discuss]
Section 3, paragraph 1:
  This command MUST be
  issued before the user is authenticated, as this will allow the
  authentication scheme and set of legal users to be dependent upon the
  virtual host that is chosen.

Does this mean "if the user agent is going to send a HOST command, it MUST send it before it authenticates?"  Or does it mean "User agents implementing this specification MUST send a HOST command before authenticating?"    I think it means the latter, but it could be read as meaning the former.
2013-10-23
03 Ted Lemon
[Ballot comment]
Section 3.1 copies ABNF from RFC 3986 rather than incorporating it by reference.  The reader most likely knows what an IPv4 address and …
[Ballot comment]
Section 3.1 copies ABNF from RFC 3986 rather than incorporating it by reference.  The reader most likely knows what an IPv4 address and an IPv6 address looks like, and if they don't they can refer to RFC 3986.  So I would really encourage you to incorporate these by reference rather than copying the text.  Copying the text invites errors, and I don't think it adds value.
2013-10-23
03 Ted Lemon [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon
2013-10-23
03 Stephen Farrell
[Ballot comment]


- I support Sean's DISCUSS points

section 1 - "Such an arrangement presents some problems
for FTP servers, as an FTP server distinguishes …
[Ballot comment]


- I support Sean's DISCUSS points

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

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

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

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

Appendix A - I'm not sure all of the paths-not-taken are
required to be "unworkable" so the appendix title seems
odd.
2013-10-23
03 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-10-23
03 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2013-10-23
03 Sean Turner
[Ballot discuss]
One of the big issues with TLS is how to represent and verify the identity of applications (see RFC 6125).  RFC 5280 …
[Ballot discuss]
One of the big issues with TLS is how to represent and verify the identity of applications (see RFC 6125).  RFC 5280 specifies how the FTP URI is used in the certificate something like ftp://192.0.2.1.  s3.1 of this document says that the address can include square brackets.  Is this document updating RFC 5280? Does the server_name included in the TLS handshake also include these brackets?

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

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

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

If the hostname specified is unknown at the server, or if the server
is otherwise unwilling to treat the particular connection as a
connection to the hostname specified, the server SHOULD respond with
a 504 reply.
2013-10-23
03 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2013-10-23
03 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-10-23
03 Jari Arkko
[Ballot discuss]
Thanks for writing this document. It seems OK and the Gen-ART reviewer, Merat, was also largely OK with it. However, before recommending the …
[Ballot discuss]
Thanks for writing this document. It seems OK and the Gen-ART reviewer, Merat, was also largely OK with it. However, before recommending the approval I wanted to ask for clarification on two points to make sure that implementors can read this spec accurately.

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

Similarly, on page 18, I did not understand this: "a server implementation MUST treat an additional HOST command that was sent before a user has been authenticated as though a previous HOST command was not sent." Can you clarify?
2013-10-23
03 Jari Arkko [Ballot comment]
See also Meral's Gen-ART review.
2013-10-23
03 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko
2013-10-23
03 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-10-23
03 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2013-10-22
03 Brian Haberman
[Ballot comment]
I have no objection to the publication of this document, but I do have a non-blocking comment that I think would be useful …
[Ballot comment]
I have no objection to the publication of this document, but I do have a non-blocking comment that I think would be useful to consider.  The examples supplied in section 3.1 (top of pg. 8) are educational, but I am concerned about the use of link-local IPv6 addresses.  The examples do not seem like they need to use link-local IPv6 addresses, so using global addresses out of the documentation space (RFC 3849) would be a good choice.  My concern about using link-local IPv6 addresses is that their use requires more information than just the address.  In order to handle the non-uniqueness of these addresses, users have to specify which interface to use for the communication (e.g., "ftp FE80::1:2:3:4%en0").  RFC 4007 (section 11) discusses the reason for needing this additional information.  Given that, I would suggest changing the example to use the defined documentation (i.e., global) address range.
2013-10-22
03 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-10-22
03 Spencer Dawkins
[Ballot comment]
I have a few comments that you might wish to consider, along with any other comments you receive during IESG evaluation.

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

In section 3.1.  Syntax of the HOST command

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

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

In section 3.2.  HOST command semantics

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

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

In section 3.2.1.  REIN command semantics

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

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

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

Thank you for including Appendix A. It was helpful to me as a reviewer.
2013-10-22
03 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-10-22
03 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-10-21
03 Pete Resnick
[Ballot comment]
Section 3, para 1: "legal" is weird here. Don't you mean "authorized"?

Section 3.1: Why are these copied in here as opposed to …
[Ballot comment]
Section 3, para 1: "legal" is weird here. Don't you mean "authorized"?

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

Section 3.2.2, para 5: "An exception to the above statement..." Which above statement are you talking about?
2013-10-21
03 Pete Resnick Ballot comment text updated for Pete Resnick
2013-10-21
03 Pete Resnick
[Ballot comment]
Section 3, para 1: "legal" is weird here. Don't you mean "authorized"

Section 3.1: Why are these copied in here as opposed to …
[Ballot comment]
Section 3, para 1: "legal" is weird here. Don't you mean "authorized"

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

Section 3.2.2, para 5: "An exception to the above statement..." Which above statement are you talking about?
2013-10-21
03 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-10-21
03 Meral Shirazipour Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour.
2013-10-18
03 Barry Leiba State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-10-18
03 (System) State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-10-18)
2013-10-16
03 Barry Leiba Ballot has been issued
2013-10-16
03 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2013-10-16
03 Barry Leiba Created "Approve" ballot
2013-10-16
03 Barry Leiba Changed document writeup
2013-10-09
03 Barry Leiba Placed on agenda for telechat - 2013-10-24
2013-10-09
03 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2013-10-09
03 Amanda Baber
IESG/Authors/WG Chairs:

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

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

IANA's reviewer has the following comments/questions:

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

In the FTP Commands and Extensions registry at

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

a single new extension will be registered as follows:

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

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

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.
2013-09-26
03 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2013-09-26
03 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2013-09-26
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2013-09-26
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2013-09-20
03 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-09-20
03 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (File Transfer Protocol HOST Command for …
The following Last Call announcement was sent out:

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


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

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

Abstract


The File Transfer Protocol, as defined in RFC 959, does not provide a
  way for FTP clients and servers to differentiate between multiple DNS
  names that are registered for a single IP address.  This document
  defines a new FTP command that provides a mechanism for FTP clients
  and servers to identify individual virtual hosts on an FTP server.



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

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


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


2013-09-20
03 Amy Vezza State changed to In Last Call from Last Call Requested
2013-09-20
03 Barry Leiba Last call was requested
2013-09-20
03 Barry Leiba Last call announcement was generated
2013-09-20
03 Barry Leiba Ballot approval text was generated
2013-09-20
03 Barry Leiba State changed to Last Call Requested from AD Evaluation
2013-09-20
03 Barry Leiba State changed to AD Evaluation from Publication Requested
2013-09-20
03 Barry Leiba Ballot writeup was changed
2013-09-20
03 Barry Leiba Ballot writeup was generated
2013-09-20
03 Naveen Khan New revision available
2013-07-08
02 Barry Leiba Assigned to Applications Area
2013-07-08
02 Barry Leiba State Change Notice email list changed to phethmon@hethmon.com, robmcm@microsoft.com, draft-hethmon-mcmurray-ftpext-ftp-hosts@tools.ietf.org, tony@att.com
2013-07-08
02 Barry Leiba Intended Status changed to Proposed Standard
2013-07-08
02 Barry Leiba IESG process started in state Publication Requested
2013-07-08
02 (System) Earlier history may be found in the Comment Log for draft-ietf-ftpext2-hosts
2013-07-08
02 Barry Leiba Changed document writeup
2013-07-08
02 Barry Leiba Changed consensus to Yes from Unknown
2013-07-08
02 Barry Leiba Document shepherd changed to Tony Hansen
2013-05-16
02 Cindy Morgan New version available: draft-hethmon-mcmurray-ftpext-ftp-hosts-02.txt
2012-11-12
01 Stephanie McCammon New version available: draft-hethmon-mcmurray-ftpext-ftp-hosts-01.txt
2012-07-16
00 Stephanie McCammon New version available: draft-hethmon-mcmurray-ftpext-ftp-hosts-00.txt