>>On the contrary, the forwarding function is based on the URI,
>>not on the method or media type. The filtering function
>>(or, more accurately, the routing function) is based on
>>everything in the request.
>>I should interpret this as "anything in the request might be useful for
>filtering", right?
Right. Proxies will use whatever is easiest first, depending on the
level of security enforced by the site. A true firewall will look at
everything, even though this will considerably slow processing.
>>In the case of IPP, it is perfectly adequate to filter on
>>content-type, since all IPP content is carried in application/IPP.
>>To which you replied
>>>There is nothing special about Internet printing that requires
>>independent firewall semantics.
>>Since media-type is part of "everything in the request"... why do you refer to
>this recommendation as "independent firewall semantics"? It seems valid for
>Larry to point out that mime-type is consistent for IPP and, therefore, can be
>considered a reliable filter.
I was saying that there is no need to block IPP requests via the protocol.
For incoming requests, a firewall is going to be blocking first according
to the resource (the URI or IP address) and, if selective access is enabled,
the method.
For outgoing requests, blocking via the resource is not really feasible
unless you want to restrict access to only named portions of the Internet,
so the request will be blocked by method or header field or content
(in order of increasing performance cost). But why would a firewall want
to block an outgoing IPP request? The only security policy that applies
here is that the site doesn't want the INFORMATION to go outside the
firewall, and it just doesn't matter what data format is being used
to contain that information. That is why application/ipp is useless as
a "reliable filter".
So, from a security standpoint this whole discussion is pointless.
applications to understand the request quickly so that the process
of filtering doesn't overwhelm usability. Extracting and comparing
the method from an HTTP request can be done in two instructions once
the message beginning is found. Extracting and comparing the media
type requires parsing all of the header fields, finding the one named
Content-Type (being aware that an attacker might provide several such
fields in the hope that the firewall would look at the first while the
application would look at the last), parsing that field to extract the
major and minor type, and then comparing it against "application/ipp".
I'm not sure exactly how many instructions that costs, but I do know
from experience that it is significant. That is why using RENDER as
a method is a better engineering choice from the standpoint of a firewall
implementer, since it expresses the semantics that the outgoing
firewall wants to block in a way that is easiest to process.
>You wrap up with two additional points (paraphrased):
>>1. Because IPP is mapped to HTTP, it does not allow
> selective access to the printer's resources.
No, I said the opposite. Because IPP is hidden within a media type,
it is not using HTTP for anything but transport. HTTP is not a transport
protocol; it is an application protocol. The reason HTTP is allowed
through firewalls is because it expresses enough of the application's
intent that intelligent filtering is possible. Selective access means that
you may not have access to POST, but you do have access to OPTIONS,
printer status, job queue, MTBF statistics, toner levels, etc.
There are many service queries that you might want an off-site person
to investigate which do not result in printing cost, and you don't
want those things to be blocked at the firewall implementation.
>IPP allows access to resources such as configuration or job information,
>regardless of the protocol mapping. Is this what you are referring to?
>What other resources of the printer do you want to access independently? Are
>you thinking of things like firmware refresh or font libraries?
I am thinking of everything that has identity on the server within
the printer. A server based on a printer is no different from a server
based on a hard disk -- it controls access to a namespace consisting of
identified resources on that server (the Web's notion of a resource is
defined in the URI syntax draft). Each of those resources can be
represented by some media type, and therefore can be GET-able by any
HTTP application. If desired, you can even define a standard
namespace for typical printer resources, just like SNMP has a MIB.
>2. Control of network resource access is already
> provided at the URI level and in the underlying
> protocol layers upon which HTTP takes place.
>>Right... doesn't this confirm or choice of HTTP as the initial mapping?
No. You'd get the same from binary messages on TCP. IPP is just an
incredibly inefficient implementation of RPC that runs on port 80.
A true mapping to HTTP maps the protocol user's actions to something that
can be expressed using HTTP semantics, thus creating a network-based API
to printer services which can be understood by agents and intermediaries
without any knowledge of printing as an application.
...Roy T. Fielding
Department of Information & Computer Science (fielding at ics.uci.edu)
University of California, Irvine, CA 92697-3425 fax:+1(949)824-1715
http://www.ics.uci.edu/~fielding/