Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions

["Mark P. Peterson" <[e-mail]>]

Hi Paul,

Thank you for taking the time to respond.

Point 1
====== 
I agree with your points.  I will clarify the document.

Point 2 
====== 
CSID doesn't contain any host specific information, the intent is only to exchange information about the software between server and client.  As for HOST this is being proposed in a different draft for FTP.  I believe the information passed between the client and server should only apply to the actual software and platform and is independent from the login information.  In other words it should always return the same information.

Mark P. Peterson - President
http://www.RhinoSoft.com
Voice: [phone]
FAX: [phone]  



From: Paul Ford-Hutchinson 
Sent: Tuesday, November 23, 2010 9:16 AM
To: Mark P. Peterson ; [e-mail] 
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions



Two comments about the CSID before login question: 

1) RFCs define protocols not implementations, so the discussion should be about what _can_ happen and how a client/server should respond. 
2) I'd like to be 100% certain what payload CSID can carry before banning it totally prior to authentication. 


Point 1 (the protocol vs implementation thing) 
====== 

We need to say what is and isn't allowed in the protocol, comments about implementations are interesting but not really the thrust of an RFC.  In this case, we need to state when a client may send CSID; what a server should do if the client sends it at the wrong time - and at the right time; whether the client should expect that a server might refuse to answer a CSID command because it is in a particular state and that it might be sensible for it to try again when in a different state in the protocol (e.g. logged in). 

Also, don't forget that users can log out too - so simply stating after a USER command (or some such) isn't really good enough. 

Point 2 
====== 

HTTPS is broken because of something similar.  Multi-homed http servers cannot operate on HTTPS because the server needs to present the cert to the client before the client tells the server which certificate (i.e. host) it should be. 

I don't know if CSID may contain host specific info  (ext_cfactname and local_fact seem to be a bit of a catch all that might get used for "hostname" or some such.) but be very wary of this catching people out.  At the very least, if CSID should not be used for host identification, then ban such values from being in these fields. 



Perhaps CSID could be permitted to pass different information depending on the state of the user's session.  (which brings us back to the protocol vs implementation issue - should CSID always pass the same information regardless of session state or is the peer allowed to use session context to decide what to include - thus meaning that two calls to CSID might be allowed to pass different values. In fact - is a client allowed to send multiple CSID commands and what should a server do if the information passed in the second command does not match that from the first (and does REIN need to be involved?)?) 

Cheers, 
Paul 

-- 

Paul Ford-Hutchinson CISSP - Tivoli Security Consultant
IBM UK Ltd. - NHBR - 1PH - North Harbour - Portsmouth - PO6 3AU
IBM Certified Deployment Professional - Tivoli Compliance Insight Manager V8.5

Tel [phone]  (internal: 37269105) 


      From:  "Mark P. Peterson" <[e-mail]>  
      To:  "William F. Maton" <[e-mail]>  
      Cc:  [e-mail]  
      Date:  23/11/2010 14:45  
      Subject:  Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions  
      Sent by:  [e-mail] 


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



Hi William,

Thank you for taking the time to respond.  I cannot think
of any real reason why CSID shouldn't only be allowed after login.
I will change the document to reflect this.

Mark P. Peterson - President
http://www.RhinoSoft.com
Voice: [phone]
FAX: [phone]


--------------------------------------------------
From: "William F. Maton" <[e-mail]>
Sent: Tuesday, November 23, 2010 7:55 AM
To: "Mark P. Peterson" <[e-mail]>
Cc: "Damin" <[e-mail]>; <[e-mail]>
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions

On Tue, 23 Nov 2010, Mark P. Peterson wrote:

> Hi All,
>
> Is there anyone else that agrees with Damin about CSID?  He says it SHOULD be available only after login.

Hi Mark,
 I'm certainly and old enough salt at systems administration to
think that identification before authentication or authorization is not a
good thing.  It makes it easier for the scanners to pick-off what servers
are running.  I'd like to force them into making the extra effort, since
it might as well cost them more work and I can monitor the activity
better.

 I think standardizing CSID (from the old non-standard CLNT) is a
good thing though.  It should be left up to the implementor to support it.

 I've also read he rest of that I-D and have more thoughts on it,
but that's for another email.


> Mark P. Peterson - President
> http://www.RhinoSoft.com
> Voice: [phone]
> FAX: [phone]
>
>
>
> From: Damin
> Sent: Monday, November 22, 2010 10:17 PM
> To: [e-mail]
> Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions
>
>
> Hi,
>
>
> On 22 November 2010 19:32, Mark P. Peterson <[e-mail]> wrote:
>
> Hi Robert,
>
> Thank you for taking the time to review the commands.  If you don't mind I would
> like to respond to your comments:
>
> CSID:
>
>> For security reasons I would probably want the CSID exchange to occur AFTER the client has logged in, but I might be 
>> overreacting.
>
>
> There is a lot of discussion on the Internet about servers providing "too" much information, especially prior to login.  But 
> having
> worked on both sides of the FTP process, it's usually very easy for the client to identify what brand or flavor the server is.
> There are details which usually identify the server such as the completeness of the FEAT response, the welcome message, responses 
> to
> certain messages, etc.  So, I think it's okay to be available prior to login.  I could change the document to read that it should 
> be
> up to the server's implementation whether or not it's available.
>
> I prefer to edge on the side of caution. I don´t see any good reason that this SHOULD be available before login. Commands 
> available
> prior to login should be as limited as possible.
>
>
> RMDA:
>
>> In a server implementation I would probably make this command configurable, so administrators would have an option to disable the
>> feature.  In which case I would probably hide the command from a FEAT response so it would not be discoverable and have the 
>> server
>> return a 500 or 502 reply when RMDA is sent by the client and disabled at the server.
>
>
> I don't think my document specifies that it isn't configurable.  My implementation in Serv-U is configurable as is almost all 
> other
> FTP commands.  I think this can be left up to the server implementation.  Your possible implementation is exactly how Serv-U
> implements it.  If the feature is disabled, it doesn't appear in the FEAT response, nor is it available through the HELP command.
>
>
> AVBL:
>> ...
>
> Your comments address the reason for its existence.  The client-side implementation in SmartFTP uses the command in this manner.
>
> DSIZ:
>> This could certainly be useful, although I would probably want a user to be logged in...
>
> Any information about paths or files requires login in FTP.  I am sure this is the case here as well.  If a server wouldn't want 
> the
> "anonymous" user to have access to this command it could be configured to disallow this command at the server's implementation or
> configuration.  This should be left up to the implementation of the server or administrator of the server.
>
>> I'd probably make it configurable so as not to tie up too many server resources for large directory structures;...
>
> Agreed, the time-consuming nature of the implementation is discussed but configuration by an administrator or 
> server-implementation
> is not.   Do you think such verbiage is required?
>
>
> THMB:
>
>> I'm not a big fan of computing the thumbnail dynamically, nor am I fond of allowing the client to specify the thumbnail format 
>> and
>> size.
>
>
> That's the point of the command, though.  It's to reduce the amount of data that is required to travel over the wire.  The idea is
> to shorten delivery time to the client, letting the client decide what is best for the client, not the server.  Some clients may
> want very small images, say for a Windows Explorer style listing, others may want larger images (640x480 for example) to show a
> slide show.  I think the client needs to make that determination.  If the server decides to cache these generated images it can.
>
>
>> I think that it would be better if the server could pre-cache thumbnails for any file type in a server-determined size and image
>> format, and then return the binary data and image format information to the client.
>
>
> This could waste server-side resources, the client might not even make a request for thumbnail images.
>
>
>> For example, most graphically-based operating systems have some method for displaying file icons to a user that is seated at a
>> computer terminal, so an FTP server implementation could simply return that same icon to a client in response to a THMB request.
>
>
> Right, but this isn't really the purpose of this command.  The purpose is to take an original image file and reduce it to a
> specified size, not to return the OS's icon representation for that particular file type (i.e., not SHGetFileInfo() in Windows).
>
> My proposed implementation is fairly straightforward.  If supported the FEAT command replies with THMB and the supported file 
> types.
> When the client wants a thumbnail it asks for it with a single command.  Here is a sample result from FTP Voyager and Serv-U:
>
> PORT 192,168,0,30,199,53
> 200 PORT command successful.
> THMB PNG 98 88 Thomas.JPG
> 150 Opening thumbnail image transfer BINARY mode data connection (19738 Bytes) for Thomas.JPG.
> 226 Transfer complete. 19,738 bytes (19,756 compressed to 100.09%) transferred. 19.29 actual KB/sec,  19.28 effective KB/sec.
>
> The client opens a data channel just like any other file transfer, then requests the file using THMB, followed by the output type,
> width, height, and the file name.  The server responds just like a file transfer but also includes the resulting size in
> parentheses.
>
> While designing this command the idea was to first make it simple for both sides, second to make it operate as any other download,
> and third to make it as flexible as possible, allowing the client to decide how the resulting data is to be used and what is 
> needed.
> Of course the server could be configured in any way needed.  For example if the server wanted to limit the size of the thumbnails,
> the server could do that.  Our implementation limits the number of simultaneous threads allowed to create the thumbnails at any
> given time.  I think these details need to be left to the server implementation.
>
> As for using an OPT command to configure an upcoming THMB command for its image type and the thumbnail size, that seems to
> complicate the command.  It's very easy to add these parameters into a single command, eliminating the required handshaking 
> between
> the client and server.  An added benefit is that neither the client nor the server are required to maintain these "options"
> throughout a session, rather all of the information required is sent in a single command.
>
> If you're interested in seeing it in action, download Serv-U and FTP Voyager or SmartFTP.  Login to the server, switch FTP Voyager
> to "Thumbnails" view.  With SmartFTP simply select an image file and a thumbnail image, of dynamic size, will appear in the 
> preview
> pane.
>
>
> Thank you again for taking the time to provide your feedback.  I look forward to your comments to the above.
>
> Mark P. Peterson - President
> http://www.RhinoSoft.com
> Voice: [phone]
> FAX: [phone]
>
>
> --------------------------------------------------
> From: "Robert McMurray" <[e-mail]>
> Sent: Monday, November 22, 2010 5:01 PM
> To: <[e-mail]>; "'Anthony Bryan'" <[e-mail]>; <[e-mail]>
> Subject: [ftpext] draft-peterson-streamlined-ftp-command-extensions
>
>
> [Note: Renaming the thread from 'Submitting new drafts'.]
>
>> Anthony Bryan wrote:
>>
>> I don't mean to single you out, but
>> you showed interest in an CSID/AGNT
>> command. Do you have any opinion on
>> the other 4 commands in the draft?
>
> Thanks, Anthony.
>
> No worries - I meant to send a better response in the wake of my withdrawn AGNT draft and Mark's current Streamlined FTP Command
> Extensions draft, but I had been remiss at taking the time to collect my thoughts in a more meaningful way. But since you asked,
> this seems like as good at time as any. ;-]
>
> CSID - As evidenced by my short-lived AGNT proposal, I think it's very useful to have some sort of client/server discovery 
> command.
> FEAT does a good job of advertising the list of commands that are supported by a server, but Mark's proposed CSID command sequence
> provides a much better way for servers and client to identify their features to each other in detail. For security reasons I would
> probably want the CSID exchange to occur AFTER the client has logged in, but I might be overreacting.
>
> RMDA - This could be a very useful command, and it would parallel the functionality that I'm sure we all typically use in a native
> operating system environment. In a server implementation I would probably make this command configurable, so administrators would
> have an option to disable the feature. In which case I would probably hide the command from a FEAT response so it would not be
> discoverable and have the server return a 500 or 502 reply when RMDA is sent by the client and disabled at the server.
>
> (Note: I mention my thoughts about server implementation details just to open up the discussion as to whether any implementation
> details should be called out in the draft, or if we should leave that up to the implementers to decide.)
>
> AVBL - This command could be very useful in a client/server world; our FTP server implementation currently returns the available
> size after a successful login sequence, and the available size is based on server disk quotas and such. That being said, not every
> FTP client will bubble that information up to the user interface. Having an AVBL command would make it possible for a client to
> determine whether enough storage space is available at the server BEFORE sending a file, which would be great when you're about to
> send a 10GB file and you only have 9.99GB of storage space left. ;-]
>
> DSIZ - This could certainly be useful, although I would probably want a user to be logged in (not anonymous) before I supported 
> this
> command in order to reduce the risk of denial-of-service. I'd probably make it configurable so as not to tie up too many server
> resources for large directory structures; and once again, if the feature were disabled I would probably hide the command from a 
> FEAT
> response so it would not be discoverable and return a 500 or 502 reply when DSIZ is sent by the client and disabled at the server.
>
> THMB - I have to admit, I don't work on a graphical FTP client, so this command is less useful to me personally, but I can see the
> merit that it might have to someone that designs a graphical client. That being said, I'm not a big fan of computing the thumbnail
> dynamically, nor am I fond of allowing the client to specify the thumbnail format and size. I think that it would be better if the
> server could pre-cache thumbnails for any file type in a server-determined size and image format, and then return the binary data
> and image format information to the client. For example, most graphically-based operating systems have some method for displaying
> file icons to a user that is seated at a computer terminal, so an FTP server implementation could simply return that same icon to 
> a
> client in response to a THMB request.
>
> Please bear in mind, I haven't given a lot of thought as to what the client/server interchange might look like if the server were
> more in control of the response to a THMB request, but it would probably be sufficient to simply return the image type as part of
> the response and let the client determine the image dimensions based on the client's capabilities for reading the image data. (As 
> a
> server guy I like to push any client-friendly processing on the client whenever possible. ;-]) You could borrow an idea from the
> HASH discussion that we've been having and make the thumbnail image type configurable for the client by using an OPTS command, 
> which
> might look like the following examples.
>
> In this first example, the server has a pre-configured thumbnail image type of JPG, and may have pre-cached the thumbnails for
> files; any THMB request with no OPTS specified would use the server's pre-configured thumbnail image type of JPG and image type is
> specified in the command channel response:
>
> C> THMB widget.png
> S> 150 JPG Starting thumbnail transfer (1234 Bytes) for widget.png
> S> 226 Transfer complete.
>
> In these next examples a client is asking for different thumbnail image types by using OPTS commands, and the thumbnail image 
> types
> would still be specified in the command channel responses:
>
> C> OPTS THMB GIF
> S> 200 OPTS THMB GIF command successful.
>
> C> THMB widget.psp
> S> 150 GIF Starting thumbnail transfer (1234 Bytes) for widget.psp
> S> 226 Transfer complete.
>
> C> OPTS THMB PNG
> S> 200 OPTS THMB PNG command successful.
>
> C> THMB widget.doc
> S> 150 PNG Starting thumbnail transfer (1234 Bytes) for widget.doc
> S> 226 Transfer complete.
>
> In this next example a client is asking for an unsupported image type, so the server would simply return the appropriate error
> reply:
>
> C> OPTS THMB FOO
> S> 501 Unsupported thumbnail format.
>
> In this next example a client is asking for the currently-configured thumbnail image type, so the server would return the
> appropriate response:
>
> C> OPTS THMB
> S> 200 JPG
>
> You might take this one step further - the server might choose to only support its pre-configured thumbnail image type, thereby
> allowing pre-caching of all thumbnails in one specific image format. In this example a client is asking for PNG thumbnails, which
> SHOULD be a supported image type, but the server only supports a pre-configured thumbnail image type for JPG files and returns the
> appropriate error reply (504?) and the server's pre-configured thumbnail image type is specified in the subsequent command channel
> response to a THMB request:
>
> C> OPTS THMB PNG
> S> 504 Specifying thumbnail formats is unsupported.
>
> C> THMB widget.xls
> S> 150 JPG Starting thumbnail transfer (1234 Bytes) for widget.xls
> S> 226 Transfer complete.
>
> As I said earlier, I hadn't given much thought as to what the client/server THMB interchange might look like if you put the server
> in control instead of the client, but as a server guy I'd rather see THMB look a little more like the examples that I gave. ;-]
>
> Thanks again!
>
> Robert McMurray
> [e-mail]
>
> _______________________________________________
> ftpext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ftpext
>
>
> _______________________________________________
> ftpext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ftpext
>
>
>
>
>
>
> _______________________________________________
> ftpext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ftpext
>
>
> _______________________________________________
> ftpext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ftpext
>

wfms 


_______________________________________________
ftpext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ftpext