Re: IPP> RE: Implications of introducing new scheme and port for existing HTTP servers

The past few comments about firewalls do not (IMHO) appear to pose a
problem for IPP deployment. If the majority of the installed base of
firewall products do not do HTTP method inspection then thats ok.
everything would work. When the "next-generation" products that can perform
this type of inspection, then during installation of this new
infrastructure, the administrator will then enable IPP (or WEBDAV) or
whatever at that time.

Ultimately, I believe firewall admins will explicitly enable internet
printing or faxing or whatever, and I don't think a firewall issue should
impose undue design constraints on what we (the WG) want to do.
Firewall admins already do this explicitly enabling/disabling of
application protocols (POP, FTP, IMAP, etc.) and I think we're just another
application. I don't think these protocol designers were too bogged down in
firewall issues during the development process. At least with the
Checkpoint Firewall-1 product, it takes about 45 seconds to bring up the
console and enable or disable a particular application protocol.

Just my (possibly more than) $0.02

Randy



At 08:15 AM 6/2/98 -0700, Vinod Valloppillil (Exchange) wrote:
>Rob's argument is broadly correct -- as a long term firewall design issue,
>method inspection (and occasionally payload inspection) will become the
>rule.
>
>However, as a small carrot to today's protocol designers, the vast majority
>of the installed base of firewalls do no method / payload inspection on HTTP
>data being passed through.   Purely from the perspective of 'reach' there's
>no impediment to IPP using it's own method in the short run.
>
>> -----Original Message-----
>> From:	Rob Polansky [SMTP:polansky@raptor.com]
>> Sent:	Tuesday, June 02, 1998 6:06 AM
>> To:	David W. Morris
>> Cc:	http-wg; ipp@pwg.org
>> Subject:	RE: Implications of introducing new scheme and port for
>> existing  HTTP servers
>> 
>> I know of at least one :-) firewall that not only rejects unknown methods
>> but also examines the HTTP request method as part of its "algorithm". From
>> a
>> protocol and security perspective, it appears to be the right thing to do.
>> If you don't understand the method, how can you properly proxy it? Take
>> the
>> CONNECT method as an example.
>> 
>> In summary, any proxy that is more than a simple packet passer (supports
>> CONNECT, protocol conversion, proxy authentication, etc.) runs the risk of
>> failing to pass IPP if it uses a new scheme and/or a new method. Not that
>> that's a bad thing... :-)
>> 
>> -Rob Polansky
>> 
>> > -----Original Message-----
>> > From: David W. Morris [mailto:dwm@xpasc.com]
>> > Sent: Monday, June 01, 1998 10:34 PM
>> > To: Carl-Uno Manros
>> > Cc: http-wg@cuckoo.hpl.hp.com; ipp@pwg.org; http-wg@hplb.hpl.hp.com
>> > Subject: Re: Implications of introducing new scheme and port for
>> > existing HTTP servers
>> >
>> > (I'm also not wild about new HTTP methods as I know of existing proxies
>> > which will reject unknown methods. Don't know of any which will accept
>> > unknown methods. I'm also unaware of any firewall software which
>> examines
>> > the HTTP request method as part of its algorithm but then I'm not a
>> > firewall expert.)
>> >
>

Received on Tuesday, 2 June 1998 08:36:01 UTC