Hastings, Tom N wrote:
> ...
> 1. Use Case 1: One Printer supports multiple dissimilar devices
>
> One case where this scenario doesn't quite work is for a Printer that
> is fronting for a number of actual dissimilar devices, in which no
> one device is a superset of all of the others. For example, a duplex
> black and white printer and a simplex color printer (not an uncommon
> mixture). Here a Validate-Job with "sides"='two-sided-long' for the
I've never seen such a combination, but assuming that such a composite
printer object exists, it *should* be smart enough to route B&W jobs
to the B&W printer and color jobs to the color printer. If the job
gets bound to a single output device then the implementation is no
better than one that exposes multiple printer objects.
> ...
> Then the client can decide to break the job into two jobs and submit
> each document as separate jobs or find another Printer (without
> having sent *any* document data for either document).
How is this different from the Send-Document case?
> ...
> 2. Use Case 2: client doesn't have all of the documents up front
>
> A second use case that the Create-Document operation allows is a
> client that is collecting documents over a period of time (if the
> Printer's "multiple-operations-time-out" Printer Description
> attribute value is large enough). For example a mail reader or a
> browser that submits each document as the user selets it, but want
> all of the documents to come out as one job. (Of course, you could
> argue that the client should buffer up all of the selected documents
> as the user selects them and then submit them all at once with
> Create-Job and Send-Document). That client could perform each
> Create-Document operation as the document was available, but not send
> the data for any until the client was assured that all documents
> would be acceptabel to the Printer. (Note: if the client sends the
> data as each document was available, then that client could have used
> the Send-Document instead.)
>
> I'll add some more explanation of this in the spec.
But that, too, doesn't hold up. Nothing prevents the client from
mixing Validate-Job and Send-Document operations on-the-fly.
> 3. Denial of Service attacks with multiple Create-Document requests
>
> You mention the down side to having Create-Document is the denial of
> service where a client could issue a large number of Create-Documents
> and use up the Printer's slots for documents. However, how is this
> any different to such a malicious client issuing a large number of
> Create-Job operations? It seems to me that a robust Printer
Because for Create-Job we have defined a status code that allows the
server to tell the client that they can't create any more jobs,
which allows the server to provide configurable max-jobs,
max-jobs-per-printer, max-jobs-per-user, etc. limits to prevent a
DoS attack or simple abuse (CUPS provides all of these BTW...)
> implementation has to design its data structures and use of disk
> memory so as not to have artificial limits of either Jobs or
> Documents. Only when the total space is used up would be the denial
> of service occur. So a robust Printer implementation also needs to
> defend against an excessive number of Create-Job requests and
> Create-Document requests.
Indeed, and such implementations already exist.
Also, just because you have disk/RAM available doesn't mean that you
want to allow a user to successfully attack your server.
Again, in my comments I suggested that *if* Create-Document and
Send-Data were absolutely necessary (and I still haven't heard a
compelling reason for it), then we should also define a similar
status code which allows the server to apply limits to the number
of reserved documents in a job and tell the client when it can't/
won't add another to a job.
> I'll add some discussion of these two denial of service attacks in
> the Security Considerations section. Presumably, a Printer would
> return either a 'server-error-service-unavailable (0x0502)' status
> code ([rfc2911] section 13.1.5.3) or a 'server-error-temporary-error'
> (0x0505) status code ([rfc2911] 13.1.5.6).
Neither of these is specific enough to be of any use to the client;
unless it knows that it *cannot* create another document in a job,
then it will keep retrying, right?
> 4. Bottom line on Create-Document operation:
>
> ISSUE 02: So the real debate should be whether these two use cases
> are sufficiently compelling to have the added complexity of
> Create-Document and Send-Data? Or is doing a Validate-Job for each
> document sufficient (either before the Create-Job or before each
> Send-Document) and we can remove Create-Document and Send-Data from
> the spec?
I personally don't think that Create-Job and Send-Data are necessary,
and as presently defined they open up a serious (and obvious)
security hole WRT DoS attacks. While we cannot provide absolute
protection against such attacks, we *can* provide the necessary hooks
so that implementations can provide controls/limits/algorithms and
properly handle DoS cases.
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com
This archive was generated by hypermail 2b29 : Sat May 03 2003 - 23:00:48 EDT