Keith,
As we still seem to be talking primarily about a firewall issue, or it least
it was in your earlier
comment paper (now it seems that is suddenly become a user issue), here is a
reprint of a contribution from a from a few weeks ago, which I am not sure
that you ever saw.
The contribution was made to the IPP and HTTP DLs. FYI, the contribution was
based on detailed discussions that I held with real life
designers/developers of firewall software, who do this for a living.
------
I have been trying to figure out how we can get the discussion about how to
distinguish IPP in firewalls a little more structured and not talk past each
other. Let me try to sketch up a simple model of how I think firewalls work,
and where the different proposals come in.
NOTE, that there is no standard what-so-ever for firewalls, so whatever
model you come up with will not fit every firewall implementation. If there
was a firewall standard in the IETF, we would not have this discussion.
I think a common feature of all firewalls is that they have a hierachy,
which sometimes is shallow and sometimes is deep. Here is my try at
describing the more important "layers".
1) Host address TCP/IP address
2) Port number Default 80 for HTTP
3) Protocol "http" for HTTP
4) Method POST etc. for HTTP
5) Content HTML etc.
Filtering in the firewall can be done on any of these layers. Usually the
firewall only let things through that it can identify and refuses the rest.
Keith Moore suggests that we need to change both layer 2) and 3) above to
give the firewall a chance to distinguish IPP from HTPP traffic.
MS experts and a couple of others have suggested that the filtering takes
place on layer 4), by allocating a new PRINT method for IPP and we do not
need to touch layers 2) and 3).
In discussions that I had with firewall experts last year, they indicated
that they had no problem to filter on layer 5), e.g. distinguishing IPP from
HTML etc. by identifying the content as an "application/ipp" MIME type.
So what it all boils down to is how versatile the firewall implementation is.
To make a concious decision about filtering in/out IPP from other HTTP
traffic, any current firewall will need to be reconfigured or modified in
same way.
Looking at my hierachy, I suggest that if a firewall do all levels, there is
NO need to modify anything in the current IPP specs. (Note: This referred to
the earlier set of IPP drafts!)
----
Since I wrote this contribution, it has been pointed out that values in
layers 2) and 3) are often linked when defaults are used, but non-default
combinations are usually allowed. The latest IPP proposals now gives a
firewall administrator the possibility to filter IPP traffic on 1), 2) and
5). Do REALLY think that it is necessary that filtering also has to be done
on layer 3)? There might actually be people who want to allow IPP to come in
fairly unrestricted e.g. sales organizations.
Firewall people are generally very clever and very flexibel people; if not
they are quickly out of business.
I realize that they would probably never come to the IETF to develop a standard.
Maybe you want to share this contribution with your fellow IESG members?
Carl-Uno