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 at easysw.com]
Sent: Thursday, May 22, 2003 08:31
To: Dennis Carney
Cc: ipp at 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