- From: Carl-Uno Manros <carl@manros.com>
- Date: Thu, 4 Jun 1998 16:19:44 +0100 (BST)
- To: http-wg@cuckoo.hpl.hp.com, ipp@pwg.org
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 firewall do all levels, there is NO need to modify anything in the current IPP specs. If we move up (or down) to level 4), then we should go along with the MS approach, etc. My 2 cents, Carl-Uno
Received on Friday, 5 June 1998 11:52:58 UTC