Subject: [ftpext] Question about draft-bryan-ftp-hash-07

From: Robert McMurray <[email-masked]>
Date: Fri, 20 Aug 2010 22:01:32 +0000

It's been a few weeks since we've discussed the draft for the HASH command, which is logical given the discussions that followed IETF 78, but from an admittedly biased implementation point-of-view I'd like to see this draft continue to move forward towards publication.

With that in mind, I've been thinking through implementation scenarios in the wake of the denial-of-service discussion that took place before IETF 78. More specifically, I've thinking about a scenario where the maximum file size could be configured at the server, so HASH commands could be prevented from stealing too many server resources when larger files are involved. This is purely a server implementation detail that has nothing to do with the draft with the exception of considering which reply code to return.

Looking at section "3.4. HASH Command Errors" in the draft it would seem that none of the 5yz errors that are listed would apply, but returning a 504 reply might seem to make sense in this scenario. If so, would it be worthwhile to add a statement like the following to the draft?

   The server-PI SHOULD reply with a 504 reply if the HASH command is
   used on a file that cannot be processed for policy reasons. (For
   example, the file size exceeds the server's hashing policy.)

Or would a 4yz reply be better since this is a configurable option at the server? Perhaps a 452 reply?

Thanks.

Robert McMurray
US-IIS Product Unit
Email: [email-masked]

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 21 Aug 2010 00:12:48 +0200 (CEST)

On Fri, 20 Aug 2010, Robert McMurray wrote:

> Looking at section "3.4. HASH Command Errors" in the draft it would seem 
> that none of the 5yz errors that are listed would apply, but returning a 504 
> reply might seem to make sense in this scenario. If so, would it be 
> worthwhile to add a statement like the following to the draft?
>

Seems fine to me!

> server? Perhaps a 452 reply?

I see your reasoning but I think rejecting an operation for a policy reason is 
"permanent" rather than "transient" as trying again surely has very little 
hope of working. I vote for a 5xx error.

-- 

  / daniel.haxx.se

---

From: Tim Kosse <[email-masked]>
Date: Sat, 21 Aug 2010 00:21:31 +0200

>    example, the file size exceeds the server's hashing policy.)

So far 504 is used for "Command not implemented for that parameter"
which doesn't seem to fit too well.

What about 554?

> Or would a 4yz reply be better since this is a configurable option at the server? Perhaps a 452 reply?heh

From my understanding, 4yz is for temporary errors that require no
intervention, encouraging the client to try again at some point in the
future.

Tim

---

From: Robert McMurray <[email-masked]>
Date: Fri, 20 Aug 2010 22:42:55 +0000

> which doesn't seem to fit too well.

RFC 1123 lists the 554 reply as "Requested action not taken: invalid REST parameter," so this wouldn't seem to make sense for HASH.

RFC 2228 lists the 534 reply as "Request denied for policy reasons," but that has always seemed to me to be more specific as a response to the security extensions that are defined in that RFC so I hadn’t suggested it, but I'll open that for debate. ;-]

---

From: Anthony Bryan <[email-masked]>
Date: Sat, 21 Aug 2010 16:06:56 -0400

> RFC 2228 lists the 534 reply as "Request denied for policy reasons," but that has always seemed to me to be more specific as a response to the security extensions that are defined in that RFC so I…

thanks, Robert. good suggestion. I've added this text while we iron
out the reply code:

Server operators might wish to allow the HASH command but restrict its
use to certain files, for example, if the file size exceeds the
server's hashing policy. A client MUST be able to understand that
refusal to process HASH commands may be permanent (if indicated by a
5yz response) and will not be honoured later.

The server-PI SHOULD reply with a 5yz reply if the HASH command is
used on a file that cannot be processed for policy reasons. (For
example, if the file size exceeds the server's hashing policy.)

suggestions?

btw, for anyone interested I believe I have all reply codes listed in
http://www.metalinker.org/test/ftp/draft-bryan-ftpbis-00.html#sec-4.2.3

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