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 tsv-...@ietf.org 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 "na...@hoststring]" arguments, e.g., sm...@host.example.com 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
RE: TSV-DIR review of draft-hethmon-mcmurray-ftp-hosts-11.txt
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. ) In any event, I am still working on an updated draft. Thanks again for the feedback. Robert -Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Thursday, May 06, 2010 10:48 AM To: IETF discussion list Cc: TSV Dir; draft-hethmon-mcmurray-ftp-ho...@tools.ietf.org; tsv-...@tools.ietf.org 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 tsv-...@ietf.org 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 "na...@hoststring]" arguments, e.g., sm...@host.example.com 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 addi
Re: TSV-DIR review of draft-hethmon-mcmurray-ftp-hosts-11.txt
On 5/17/10 10:06 AM, Joe Touch wrote: 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: TSV-DIR review of draft-hethmon-mcmurray-ftp-hosts-11.txt
Douglas Otis wrote: > > On 5/17/10 10:06 AM, Joe Touch wrote: > > 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. > > > 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
