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

The issue is proxies - enablers - not firewalls - disablers. If you replace
my proxy by a passthrough cable I cannot do anything, if you replace my
firewall by a cable you can do anything. 

> -----Original Message-----
> From:	Randy Turner [SMTP:rturner@sharplabs.com]
> Sent:	Tuesday, June 02, 1998 8:34 AM
> To:	Vinod Valloppillil (Exchange); 'Rob Polansky'; David W. Morris
> Cc:	http-wg; ipp@pwg.org
> Subject:	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 Friday, 5 June 1998 11:51:09 UTC