Subject: Re: IPP> Re: On the harm of adding new methods

From: Harry Lewis <[email-masked]>
Date: Thu, 11 Jun 1998 12:00:49 -0400

Roy, thanks for commenting on some of the last remaining issues with IPP and
the current recommendation of our area director to specify a default port and a
new name for the URI scheme. I am most likely not as knowledgeable as you
regarding HTTP, it's design and various uses, so I would like to ask for some
clarifications and share some observations.

You said

>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? I don't think I should read this as "all (filtering) routers
always use everything in the request as a filter", right?

Larry said

>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 don't think anyone is recommending the treatment of POST to an HTTP server
(acting as a print server) any differently than POST directly to a printer or
differently from any POST to any HTTP server, for that matter. Just, if you
want to filter on mime-type, you can.

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.

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?

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?

Harry Lewis

[email-masked] on 06/10/98 07:46:14 PM
Please respond to [email-masked]
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: IPP> Re: On the harm of adding new methods

I disagree with some of Larry's points.  The design of HTTP was intended
for method extension whenever there is a standardizable semantics
that can be shared between client and server (and, most importantly,
between those agents and any intermediaries that may be between them).

>There are two functions of a proxy: filtering and forwarding.
>A filter decides whether or not to accept a request, and a forwarder
>actually forwards the request and processes the result; forwarding
>implements caching, protocol translation, tunneling, while filtering
>is generally a binary "allowed" or "not allowed". There are some
>forwarders that do rewriting in lieu of filtering (allow but modify).

And also those that do transformation and forwarding, though that's
not an issue here.  Basically, there exist active and passive
intermediaries.

>Forwarders MUST actually understand methods, because -- unfortunately --
>the meaning of HTTP headers and responses differ based on the method
>of the request (e.g., Content-Length for HEAD vs GET). Many forwarding
>systems will not accept new methods gracefully.

Actually, that is only true for HEAD and GET -- all header fields have
the same meaning for all other methods.  HEAD is the only method for
which Content-Length has a different meaning, and no new method can change
the message length calculation.  GET/HEAD is the only method for which
conditional request header fields have the 304 meaning, whereas for all
other methods they have the 412 meaning.  I can't think of any other
exceptions at the moment -- if any have been added in the past year
or so, they need to be removed.

HTTP/1.1 is designed to enable forwarding without understanding the
method semantics, provided that such forwarding fits within the security
policy set at the intermediary.

>Any new METHOD in HTTP is a serious modification to the protocol, because
>the forwarding function must be aware of it. A new content-type, however,
>can be as easily recognized in the filter layer as a new method, but
>requires NO changes to the forwarding function. Many filters already filter
>on content-type anyway.

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.  What you
are saying is that it is better for filtering to eliminate one of the
criteria by which an intermediary can do filtering, in this case the
one that is easiest to find and interpret quickly in an HTTP request.
I think that is a bad design when there are semantics that can be easily
distinguished via the method.

>In the case of IPP, it is perfectly adequate to filter on content-type,
>since all IPP content is carried in application/IPP. The arguments for
>adding a new method (that it is somehow 'easier' to filter on the first
>few bytes of the protocol) are specious because most filters that are
>looking at the protocol at all are looking at content-type. So the
>"firewall filtering" rationale just doesn't hold as a reason for adding
>new methods.

Well, it seems I disagree with everyone on this part.  There is nothing
special about Internet printing that requires independent firewall
semantics.  Nothing.  A printer is a network resource that must be
protected like all other network resources -- as a resource.  There is
no difference between sending a POST full of data to an HTTP server
acting as a printer gateway and sending a POST full of data to the
printer directly.  Treating the two as being different violates one
of the basic principles of the Web architecture.

That does not mean we should add a PRINT method to the protocol.
PRINT does not say anything semantically interesting.  Why should the
client care what mechanism is being used behind the curtains?  Should the
semantics need to change if the server is actually a pipeline like

     client ----  proxy  -----  fax  -----  fax  ---- printer

If you look at any modern operating system design, you will find such
differences abstracted away so that every application does not need
separate interface protocols for every device type.  Why should the
Internet be any different?

RENDER would be a more semantically meaningful choice, since what the
client is saying is that it wants the service to render the data as
specified and then discard it.  However, the reason for defining this
new method has nothing to do with firewall filtering.

The IPP design is poor because it conflates an intended action with
the transfer syntax of the data, thus reducing the normal mechanisms of
allowing selective access to a printer's resources using any of the
independently defined security mechanisms of HTTP.  While it may be
nice to think of Internet printing as a layered protocol on top of HTTP,
the result is something that is neither efficient nor capable of reusing
many of the advantages of HTTP.  Instead, printing should have been
designed as a service with a defined resource model; standard Web agents
could then manipulate that resource model using the same protocols
as everyone else's resources.  For those cases where data and control
information is to be sent in one action, an application-independent
transfer syntax should be used to group them (a la multipart/related).
Of course, there is nothing to prevent such an implementation from
coexisting with IPP, so I am not suggesting that IPP be changed at this time.

Attempting to isolate printer services from other services using any of
the options suggested (new URI scheme, separate port, new method, obscure
media type) is ultimately futile.  None of these provide anything useful
in the way of securing access to resources; the first two in particular
are a total waste of time since the "http" URI scheme is port-independent.
The only thing you accomplish is making the implementations more complicated.
Control of network resource access is already provided at the URI level
and in the underlying protocol layers upon which the HTTP communication
takes place.

 ...Roy T. Fielding
    Department of Information & Computer Science    ([email-masked])
    University of California, Irvine, CA 92697-3425    fax:+1(949)824-1715
    http://www.ics.uci.edu/~fielding/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 11 Jun 1998 19:23:41 -0700

>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.

>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.

>From an implementation standpoint, you want to make it easy for
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.

>   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.

>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.

>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