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

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: Mike Sweet (mike@easysw.com)
Date: Sat May 03 2003 - 22:59:54 EDT

  • Next message: Hastings, Tom N: "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 : Sat May 03 2003 - 23:00:48 EDT