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

[Keith Moore <[e-mail]>]

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

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 [e-mail].  

Keith