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

Paul Ford-Hutchinson <paulfordh@uk.ibm.com> Tue, 23 November 2010 22:35 UTC

Return-Path: <paulfordh@uk.ibm.com>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5F028C11F for <ftpext@core3.amsl.com>; Tue, 23 Nov 2010 14:35:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.998
X-Spam-Level:
X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKxCAryfc-fR for <ftpext@core3.amsl.com>; Tue, 23 Nov 2010 14:35:53 -0800 (PST)
Received: from mtagate4.uk.ibm.com (mtagate4.uk.ibm.com [194.196.100.164]) by core3.amsl.com (Postfix) with ESMTP id 29C2B3A6997 for <ftpext@ietf.org>; Tue, 23 Nov 2010 14:35:52 -0800 (PST)
Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.13.1/8.13.1) with ESMTP id oANMannK026387 for <ftpext@ietf.org>; Tue, 23 Nov 2010 22:36:49 GMT
Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oANMamg43608592 for <ftpext@ietf.org>; Tue, 23 Nov 2010 22:36:48 GMT
Received: from d06av07.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oANMamhP015513 for <ftpext@ietf.org>; Tue, 23 Nov 2010 15:36:48 -0700
Received: from d06ml069.portsmouth.uk.ibm.com (d06ml069.portsmouth.uk.ibm.com [9.149.38.218]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id oANMam0j015510; Tue, 23 Nov 2010 15:36:48 -0700
In-Reply-To: <1145F0D0D8974C2A8DB587DD6F4E72C8@rhinooffice.net>
References: <A5FC996C3C37DC4DA5076F1046B5674C442CE618@TK5EX14MBXC125.redmond.corp.microsoft.com><D2BD569FC8F4431E85F609B71E61EB79@rhinooffice.net><AANLkTi=D8QLkyUxgXt3h+N2nM3qgpKTBDVXLe5-6BM7q@mail.gmail.com> <914CA95DAC22422C825C665E4E76F860@rhinooffice.net><Pine.LNX.4.64.1011230851130.6921@iskra.ottix.net> <6C3AA348BF6146F2885B2094B8E8E29C@rhinooffice.net> <OF8C6635BE.33D2510D-ON802577E4.0051C5FE-802577E4.0053A63D@uk.ibm.com> <1145F0D0D8974C2A8DB587DD6F4E72C8@rhinooffice.net>
To: "Mark P. Peterson" <mpp@rhinosoft.com>
MIME-Version: 1.0
X-KeepSent: ECAD328D:14EBDD49-802577E4:007A3769; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
From: Paul Ford-Hutchinson <paulfordh@uk.ibm.com>
Message-ID: <OFECAD328D.14EBDD49-ON802577E4.007A3769-802577E4.007C3599@uk.ibm.com>
Date: Tue, 23 Nov 2010 22:40:02 +0000
X-MIMETrack: Serialize by Router on D06ML069/06/M/IBM(Release 8.0.2FP2|June 22, 2009) at 23/11/2010 22:40:03, Serialize complete at 23/11/2010 22:40:03
Content-Type: multipart/alternative; boundary="=_alternative 007AD0DC802577E4_="
Cc: ftpext@ietf.org
Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Nov 2010 22:35:57 -0000

I understand that HOST is designed to do the job, but extensible crannies 
in protocols tend to get used for all sorts of things they aren't intended 
for.

In fact, it wouldn't surprise me if the review process ends up kicking the 
'extensible' bits of this command into the long grass.  (i.e. the argument 
that it's actually creating interoperability issues rather than preventing 
them - if there's a need for a value - it should be defined syntactically 
and semantically - otherwise it doesn't belong in a protocol spec.)

I suggest that there should be some discussion about what kind of 
information is valid in the CSID command/response and when a client/server 
might expect it to alter (or not).  And if it turns out it is tied to a 
"session" - point out that a "session" can mean a number of things in FTP, 
so that will need to be specified too.

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 +44 (0)7500 078379  (internal: 37269105)



From:
"Mark P. Peterson" <mpp@rhinosoft.com>
To:
<ftpext@ietf.org>, Paul Ford-Hutchinson/UK/IBM@IBMGB
Date:
23/11/2010 19:55
Subject:
Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions



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: +1(262) 560-9627
FAX: +1(262) 560-9628 

From: Paul Ford-Hutchinson 
Sent: Tuesday, November 23, 2010 9:16 AM
To: Mark P. Peterson ; ftpext@ietf.org 
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 +44 (0)7500 078379  (internal: 37269105) 


From: 
"Mark P. Peterson" <mpp@rhinosoft.com> 
To: 
"William F. Maton" <wmaton@ottix.net> 
Cc: 
ftpext@ietf.org 
Date: 
23/11/2010 14:45 
Subject: 
Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions 
Sent by: 
ftpext-bounces@ietf.org




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: +1(262) 560-9627
FAX: +1(262) 560-9628


--------------------------------------------------
From: "William F. Maton" <wmaton@ottix.net>
Sent: Tuesday, November 23, 2010 7:55 AM
To: "Mark P. Peterson" <mpp@rhinosoft.com>
Cc: "Damin" <damin@emuxperts.net>; <ftpext@ietf.org>
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: +1(262) 560-9627
> FAX: +1(262) 560-9628
>
>
>
> From: Damin
> Sent: Monday, November 22, 2010 10:17 PM
> To: ftpext@ietf.org
> Subject: Re: [ftpext] draft-peterson-streamlined-ftp-command-extensions
>
>
> Hi,
>
>
> On 22 November 2010 19:32, Mark P. Peterson <mpp@rhinosoft.com> 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: +1(262) 560-9627
> FAX: +1(262) 560-9628
>
>
> --------------------------------------------------
> From: "Robert McMurray" <robmcm@microsoft.com>
> Sent: Monday, November 22, 2010 5:01 PM
> To: <ftpext@ietf.org>; "'Anthony Bryan'" <anthonybryan@gmail.com>; 
<mark.peterson@rhinosoft.com>
> 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
> robmcm@microsoft.com
>
> _______________________________________________
> ftpext mailing list
> ftpext@ietf.org
> https://www.ietf.org/mailman/listinfo/ftpext
>
>
> _______________________________________________
> ftpext mailing list
> ftpext@ietf.org
> https://www.ietf.org/mailman/listinfo/ftpext
>
>
>
>
>
>
> _______________________________________________
> ftpext mailing list
> ftpext@ietf.org
> https://www.ietf.org/mailman/listinfo/ftpext
>
>
> _______________________________________________
> ftpext mailing list
> ftpext@ietf.org
> https://www.ietf.org/mailman/listinfo/ftpext
>

wfms 


_______________________________________________
ftpext mailing list
ftpext@ietf.org
https://www.ietf.org/mailman/listinfo/ftpext