Subject: IPP> What is a Firewall? - Repeated contribution

From: Carl-Uno Manros <[email-masked]>
Date: Fri, 03 Jul 1998 18:28:24 -0700

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Jul 1998 22:17:15 -0400

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

Yes, I saw it soon after you first posted it. 

The reason for using ipp: instead of http: is not to allow firewall
filtering.  Rather, it's implied by the use of a separate port for ipp,
and the firewall argument is one of several reasons for a separate port.
(There's also a lot of utility to be gained by using ipp:)

As for the ability to filter on content, rather than port.  Yes, firewalls 
do this.  And many of them do it poorly.  The higher on the stack that 
you try to do the filtering, the more complex the filter is, which
increases the potential for errors or corruption of the data.  It's
also more difficult to configure the firewall to do the right thing.
The last thing IESG and IAB want to do is to encourage more filtering
at higher levels by failing to provide a way to distinguish at lower
levels.  Port numbers work just as well, are a lot simpler to get 
right, and we have 18 or so years experience with them.
(more, if you count the experience with NCP that predated TCP)

I have no doubt whatsoever that firewall vendors believe their products -
no matter how complex they are - are the best things since sliced bread.
But as a user I've fought too many battles with broken firewalls from
major vendors, to have confidence in anything but the simplest ones.
It's not that port blocking provides any security in a strong sense, 
but it does narrow down the number of vulnerabilities that you have
to analyze.  And while content-filtering could potentially work better,
you end up buying a lot of complexity for marginal gain.

> Maybe you want to share this contribution with your fellow IESG members?

Tell you what.  If you seriously want to argue to IESG that http: is 
the way to go, and if you're willing to incur the extra delay that 
will inevitably result, along with an extremely low chance of success,
AND if you can get the backing of the working group to take this approach...
then go right ahead.   Set up a web page with your argument as to why
things should be this way, and I'll pass it along to IESG.  
Or just send it to [email-masked].  

Keith