Michael wrote:
I personally don't think that Create-Job [I think you meant Create-Document,
right?] 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.
Why do Create-Document and Send-Data open up any more security holes that
Create-Job and Send-Document don't already open up? Aren't the Printer
defenses the same for each security hole pair? But it would be good to have
separate new status codes for too many Create-Jobs and too many
Send-Documents or Create-Documents.
I agree that the arguments for Create-Document and Send-Data aren't too
compelling, so that unless we can agree that they are worth being REQUIRED
for conformance to the Document Object spec, we shouldn't have them at all
and should rely on the Validate-Job operation to allow a client to validate
each document (independently) before sending the attributes and data with
Send-Document, if the client wants to. And a good Printer implementation
SHOULD validate a Send-Docuement attributes in the context of the other
already created Document objects and SHOULD reject as soon as it can if all
of the documents can't be printed in one Job, rather than waiting until all
of the data arrives for that Send-Document.
Then the only loss will be that a client cannot validate *all* documents as
being acceptable in a single Job before sending *any* data. Such a client
gets close by doing the Validate-Job operation for each document before
sending any document data with Send-Document. However, the Printer won't be
able to reject the validation of a single job containing both a two-sided
black and white document and a one-sided color document. Each document will
validate in the Validate-Job operation, but the Printer can't print it as a
single two-document job on either of its duplex black and white device or
its simplex color device. Of course, such an implementation could split the
job into two jobs with a notation to the user on the start sheet to go get
the other part on the other device.
Tom
-----Original Message-----
From: Mike Sweet [mailto:mike@easysw.com]
Sent: Saturday, May 03, 2003 20:00
To: Hastings, Tom N
Cc: ipp@pwg.org; McDonald, Ira
Subject: Re: IPP> Document Object Spec Comments... [Validate-Job for
each document vs. Create-Document/Send-Data]
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 : Wed May 14 2003 - 17:47:47 EDT