IPP Mail Archive: RE: IPP> Document Object Spec Comments...

RE: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed May 14 2003 - 17:47:15 EDT

  • Next message: Carl: "IPP> Job Opening for IPP WG Member"

    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