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 05:58:37 UTC