Subject: Ftp-WG: SIZE

From: "Shesterikov Maxim (sm)" <[email-masked]>
Date: Mon, 3 Jan 2000 09:54:52 -0500

The paragraph "Security considerations" in the draft states that SIZE is
vulnerable but "Servers have, however, implemented this for many years,
without significant reported difficulties." IMHO this position is a weakness
of the draft. In no case we should end up with this "Maybe yes, Maybe no"
By implementing an anonymous FTP at Moscow State University the development
team decided to forbid RESTAT in ASCII mode. RESTART in IMAGE mode is
perfectly legal. I do not think that this solution is acceptable everwhere -
on DOS systems evaluating the size of file in both modes does not creates
high load on the server. Probably it can be reflected somehow in FEAT
response.
regards 
Maxim

---

From: Stephen Tihor <[email-masked]>
Date: Mon, 3 Jan 2000 10:48:00 -0500

Or one could just say:

For systems which need to read through an entire file to compute the
size in Ascii mode and on which this is a major drain of resources
either SIZE and restartable transfers should be disabled or a throttling
mechanism used to avoid denial of service attacks through stimulation of
this high cost operation on large files.

---

From: Alun Jones <[email-masked]>
Date: Mon, 3 Jan 2000 12:08:39 -0500

>this high cost operation on large files.

One might also note that there are several other existing behaviours that 
can induce this kind of drain on resources.  How many large servers, for 
instance, allow "LIST -R" from their root directory, and sort the output as 
they go?  Or "STAT -R" for the same effect?  Then there's the servers that 
allow in-line compression into ZIP/ZOO/GZIP/whatever format.  Each of these 
produces a processor drain on the server that is relatively large compared 
to the drain on the client's resources.  But then we start getting into 
wondering whether we should note that a fast client connecting to a slower 
server might also provide for an effective denial-of-service attack. :-)

There is a limit to what an RFC can cover in terms of such decisions as to 
what is worth implementing, and what is likely to be abused; my own 
suggestion would be to update the "Error responses" paragraph to note "too 
expensive to compute" as another allowed reason for generating 550 (or 
perhaps another code could be used?  how would that affect existing clients 
that use SIZE?)

Needless to say, if the 550 code is used, the presence of a 550 return from 
SIZE must not be treated as an assertion that the file does not exist, as I 
have seen some clients believe.

Are there any systems that might find it difficult to calculate transfer 
size in modes other than ASCII?

Alun.
~~~~

--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email
Cedar Park TX 78613     | us at [email-masked].  VISA / MC accepted.
Fax +1 (512) 378 3246   | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*WFTPD and WFTPD Pro now available as native Alpha versions for NT*