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

When you say "change the standard" are you referring to RFC 2068 or the IPP
standard?

			Thanks,
					Yaron

> -----Original Message-----
> From: Rob Polansky [mailto:polansky@raptor.com]
> Sent: Wednesday, June 03, 1998 5:55 AM
> To: Paul Moore
> Cc: http-wg; ipp@pwg.org
> Subject: RE: IPP> RE: Implications of introducing new scheme and port
> for existing HTTP servers
> 
> 
> This kind of flamebait is not really helpful to our 
> discussion. Firewalls
> serve legitimate technical and business needs as our friends 
> from Microsoft
> know, and those firewalls with application proxies look at 
> protocols from a
> different point of view than your typical caching proxies. 
> The beauty of it
> is that protocol compliant implementations from either the 
> firewall or the
> cache point of view will interoperate. The difference is when 
> they encounter
> something unexpected. Firewalls by definition must "fail 
> closed" so as not
> to make their protected resources vulnerable to attacks; most 
> other software
> makes a best effort to pass data. I don't see anything wrong with that
> difference.
> 
> Once again, if IPP uses existing methods and schemes, it 
> should be passable
> through all proxies without trouble. Add a new method and/or 
> scheme i.e.
> CHANGE THE STANDARD, and you should expect that existing 
> implemenations will
> not understand it and some (not many) may not pass it.
> 
> -Rob Polansky
> 
> > -----Original Message-----
> > From: Paul Moore [mailto:paulmo@microsoft.com]
> > Sent: Tuesday, June 02, 1998 8:37 PM
> > To: 'Randy Turner'; 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 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 Wednesday, 3 June 1998 11:06:04 UTC