Subject: [ftpext] HOST back to FTPEXT2 WG for more review

From: Anthony Bryan <[email-masked]>
Date: Thu, 14 Jul 2011 19:51:45 -0400

HOST has been brought back to our WG for more review, after being sent
to the IESG. HOST has had a long history and fair amount of
implementations, but there were some late comments and changes.

thank you to everyone who has contributed so far!

*** if you have not reviewed HOST yet, please take some time to do so.
it is one of the primary drafts that this WG was chartered to work on
& is in the final stages. please, review, make comments, & have them
addressed. :) ***

the WG really needs to focus on its official work, the 4 drafts at
http://tools.ietf.org/wg/ftpext2/ - I know there is a lot to do, & we
can be sidetracked a bit, as long as we are making progress on our
main goals. so, let's concentrate on HOST & our other mature work &
see if any other things needs to be done.

if you have reviewed HOST before, please review any changes in the
past few months. if you have comments, please make sure that they have
been addressed to your satisfaction and state whether you are for or
against the approval of HOST (even if you have in the past).

past discussion can be found on the list archives:
http://www.ietf.org/mail-archive/web/ftpext/current/maillist.html

the author also posted a pre-submission -04 revision that he will
submit once the ID submission moratorium is over (& may wish to put
online somewhere in plain text format):
http://www.ietf.org/mail-archive/web/ftpext/current/msg00366.html

fancy diffs are available at
http://tools.ietf.org/html/draft-ietf-ftpext2-hosts to see changes, so
you can minimize the time you need to spend re-reviewing.

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 22 Jul 2011 22:43:33 +0200 (CEST)

On Thu, 14 Jul 2011, Anthony Bryan wrote:

> if you have reviewed HOST before, please review any changes in the past few 
> months. if you have comments, please make sure that they have been addressed 
> to your satisfaction and state whether you are for or against the approval 
> of HOST (even if you have in the past).

I got back to this spec now and I still think the HOST should accept a port 
number and with the -03's new section 3.2.2 where it says:

    If a user-PI sends an additional HOST command before attempting to
    authenticate the user, a server-FTP process that conforms to this
    specification MUST treat the additional HOST command as though a REIN
    command was sent,

... I think even more strongly than before that it would make more sense to 
have section 3's two alternative versions a and b just be the version B as 
then a "wrongly placed" HOST would always imply a REIN. Nice and simple.

It seems we won't get a lot more feedback on this spec in this WG.

-- 

  / daniel.haxx.se

---

From: Paul Ford-Hutchinson <[email-masked]>
Date: Mon, 25 Jul 2011 11:34:51 +0100

> then a "wrongly placed" HOST would always imply a REIN. Nice and simple.

Just to clarify - this is the section that currently reads ...

   Server-FTP processes SHOULD treat a situation where the HOST command
   is issued after the user has been authenticated by 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 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 appropriate
       reply for the HOST command.

We have to think "why is this being described" and "in which situations is 
it relevant".

So, for "why is this being described" - I think we have 

- For Server processes to code to
- For Client implementations to code to

for "in which situations is it relevant" - We have

 - Servers that want to implement this command
 - Servers that don't want to implement this command but don't want to 
break any clients (this includes servers that don't want to change 
behaviour at all)
 - Clients that want to use the HOST command with servers which support it

For servers implementing HOST, you are correct, servers which implement 
this spec, should behave like (b) - and, if we wish to mandate that 
linkage in the spec (i.e. behaviour (a) is not permitted if the client 
knows the server supports HOST (either by FEAT or a successful HOST during 
the current session)) - feel free to do so.

However, servers which do not implement HOST, will do (a).

Therefore, for client writers, the client needs to be coded to expect the 
behaviour of the server to be (a) or (b) and MUST check the reply to the 
HOST to determine if an implicit REIN has happened.  Therefore (a) and (b) 
should be specified in the doc.

HOWEVER ... We should mandate an explicit REIN
===============================================

Just to mention it one more time in case it got buried in a previous 
comment....

I think that the REIN should be mandated as explicitly required; and a 
second or subsequent HOST should not be valid until the Client and Server 
have successfully completed a REIN/220 exchange.  This is because (for 
example in RFC4217) the REIN command itself may be governed by 'special' 
processing.  It is not specified in this document how such processing 
should, in general terms, be used for the HOST command.

I have been persuaded not to like "Command XXXX" implicitly does "Command 
YYYY".  In fact, I got told off for it during the draft stages of what 
became RFC4217, which is why "AUTH SSL" (bad) and "AUTH TLS" (good) are 
not functionally equivalent.

Paul
-- 

Paul Ford-Hutchinson CISSP - Tivoli Security Consultant
IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU

Tel +44 (0)7500 078379  (internal: 37269105)

---

From: Robert McMurray <[email-masked]>
Date: Tue, 26 Jul 2011 02:17:52 +0000

In response to Daniel's and Paul's emails, which are archived at http://www.ietf.org/mail-archive/web/ftpext/current/msg00388.html and http://www.ietf.org/mail-archive/web/ftpext/current/msg00389.html respectively, Daniel brings up a point in section 3 that has been addressed before, which is where I documented two possible options when a HOST command is issued after the user has been authenticated.

After recent discussions, I do not think that this is necessary after all. In a separate thread it was suggested that the HOST draft should be specific and not provide both options, and after looking at Daniel's and Paul's emails I concede the point that it is probably better for the HOST draft to specify only one option. That being said, I agree with Paul that an implicit REIN is not the way to implement this. FTP already has a REIN command, and it's simple enough for a client to send a REIN command followed by HOST command if that's the desired behavior. Therefore the better option is to return a 503 reply for an erroneous sequence of commands when a HOST command is issued after the user has been authenticated. With that in mind, I am rewording that portion of section 3 as follows:

"Server-FTP processes that conform to this specification MUST treat a situation where the HOST command is issued more than once before the user has been authenticated as though a previous HOST command was not sent, and return the appropriate reply for the new HOST command. Server-FTP processes MUST treat a situation where the HOST command is issued after the user has been authenticated as an erroneous sequence of commands and return a 503 reply."

Of course, in situations where a server-FTP process does NOT implement the HOST command, the server-FTP process will return a 500 or 502 reply, as it would with any other unrecognized command.

As far as specifying a port is concerned, it does not make sense to pass a port in the HOST command. This concept has been discussed previously, see http://www.ietf.org/mail-archive/web/ftpext/current/msg00264.html for details.

Thanks!

--Robert

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 26 Jul 2011 07:19:10 +0300

> Of course, in situations where a server-FTP process does NOT implement the HOST command, the server-FTP process will return a 500 or 502 reply, as it would with any other unrecognized command.
+1.  Such approach seems to be fine and wise.  I think the document is 
now ready for IESG review.  Mykyta

---

From: "Alun Jones" <[email-masked]>
Date: Mon, 25 Jul 2011 21:57:51 -0700

Calling HOST _after_ AUTH - is that deliberately undefined behaviour?

I can imagine a scenario where a somewhat public gateway FTP server feeds to
a number of more private backend FTP servers, where it's not considered a
good idea to publicise which server you're eventually connecting to.

Alun.
~~~~

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Robert McMurray
> Sent: Monday, July 25, 2011 7:18 PM
> To: Paul Ford-Hutchinson; Daniel Stenberg; [email-masked]
> Subject: Re: [ftpext] HOST back to FTPEXT2 WG for more review
> 
> In response to Daniel's and Paul's emails, which are archived at
> http://www.ietf.org/mail-archive/web/ftpext/current/msg00388.html and
> http://www.ietf.org/mail-archive/web/ftpext/current/msg00389.html
> respectively, Daniel brings up a point in section 3 that has been
addressed
> before, which is where I documented two possible options when a HOST
> command is issued after the user has been authenticated.
> 
> After recent discussions, I do not think that this is necessary after all.
In a
> separate thread it was suggested that the HOST draft should be specific
and
> not provide both options, and after looking at Daniel's and Paul's emails
I
> concede the point that it is probably better for the HOST draft to specify
only
> one option. That being said, I agree with Paul that an implicit REIN is
not the
> way to implement this. FTP already has a REIN command, and it's simple
> enough for a client to send a REIN command followed by HOST command if
> that's the desired behavior. Therefore the better option is to return a
503
> reply for an erroneous sequence of commands when a HOST command is
> issued after the user has been authenticated. With that in mind, I am
> rewording that portion of section 3 as follows:
> 
> "Server-FTP processes that conform to this specification MUST treat a
> situation where the HOST command is issued more than once before the
> user has been authenticated as though a previous HOST command was not
> sent, and return the appropriate reply for the new HOST command. Server-
> FTP processes MUST treat a situation where the HOST command is issued
> after the user has been authenticated as an erroneous sequence of
> commands and return a 503 reply."
> 
> Of course, in situations where a server-FTP process does NOT implement the
> HOST command, the server-FTP process will return a 500 or 502 reply, as it
> would with any other unrecognized command.
> 
> As far as specifying a port is concerned, it does not make sense to pass a
port
> in the HOST command. This concept has been discussed previously, see
> http://www.ietf.org/mail-archive/web/ftpext/current/msg00264.html for
> details.
> 
> Thanks!
> 
> --Robert
> 
> 
> 
> 
> 
> 
> _______________________________________________
> ftpext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ftpext