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: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu May 22 2003 - 13:01:19 EDT

  • Next message: Michael Sweet: "Re: IPP> Document Object Spec Comments... [Validate-Job for each document vs. Create-Document/Send-Data]"

    Note that we've added new status codes for Send-Document and Send-URI in the
    latest Document Object spec:

    13 Status codes

    This section defines additional status codes for use with multi-document
    jobs.

    13.1 server-error-too-many-jobs (0x050B)

    The client has attempted to create a Job using any of the Job Creation
    operations which would exceed the capacity of the Printer and/or the policy
    for this user or type of job. The client SHOULD NOT try again later.

    13.2 server-error-too-many-documents (0x050C)

    The client has attempted to create a Document using any of the Document
    Creation operations which would exceed the capacity of the Printer for this
    Job and/or the policy for this user or type of job. The client SHOULD NOT
    try again later.

    OK?

    Tom

    -----Original Message-----
    From: Michael Sweet [mailto:mike@easysw.com]
    Sent: Thursday, May 22, 2003 08:31
    To: Dennis Carney
    Cc: ipp@pwg.org
    Subject: Re: IPP> Document Object Spec Comments... [Validate-Job for
    each document vs. Create-Document/Send-Data]

    Dennis Carney wrote:
    > Regarding DoS attacks, it seems like we've already got that problem
    > with Print-Job, don't we? I can write a client that sends a 10Mb
    > print job using Print-Job, in 1 byte chunks, sent every 5 seconds.
    > Then call that client 100 times concurrently, and I think I've
    > probably pretty much taken the IPP printer out of commission. Right?

    Not necessarily; print-job, print-uri, create-job, send-document,
    and send-uri all define status codes and error handling scenarios
    that allow the IPP printer/server to tell the client that it won't
    accept any more jobs/documents, while the Create-Document and
    Send-Data operations do not.

    I'm not saying that we can prevent DoS attacks (we can't), but
    the new operations did not define the necessary status codes and
    implementation guidelines to prevent a conforming client
    implementation from causing a DoS attack "accidentally" as a
    result of its error handling, e.g. retrying the request(s).

    So, as my comments have indicated all along, if we need the
    functionality provided by Create-Document and Send-Data (and
    so far I haven't seen any use cases that aren't adequately
    handled by using the existing Validate-Job and Send-Document
    operations), then we need to define the necessary additional
    status codes and specify the appropriate error handling behavior
    of clients to 1) allow servers to detect and handle resource
    abuse, and 2) allow clients to respond to server resource errors
    appropriately to prevent accidental DoS attacks.

    > I would think the same sort of attack would work against LPR, raw
    > ports (9100), and probably most (all?) other print protocols.

    Actually, in the case of many printers, only a single client can
    connect to a printer's network interface (for printing anyways),
    so a simple DoS attack is to just hold a connection open to prevent
    others from printing. However, that is at a different level and
    the extensions we are talking about will likely *not* be
    implemented for resource-limited devices such as network cards
    in printers...

    > So getting rid of Create-Document and Send-Data purely for DoS
    > reasons do not seem to make sense to me.

    That isn't the reason for removing them, just to fix them. The
    fact that Validate-Job and Send-Document can provide the same
    functionality is a much better reason IMHO.

    -- 
    ______________________________________________________________________
    Michael Sweet, Easy Software Products           mike at easysw dot com
    Printing Software for UNIX                       http://www.easysw.com
    



    This archive was generated by hypermail 2b29 : Thu May 22 2003 - 13:01:43 EDT