Firewalls are a completely legitimate and valuable tool in the Internet and
I think that issues associtaed with IPP and its penetration or otherwise
through them are extremely important. Having said that I think that the
proxy issue is the more important one because:-
a) This is how most businesses users access the Internet
b) They invert the firewall model (a firewall blocks, a proxy enables)
If we use a mechanism not carried by the current proxy installed base then
the majority of business users will not be able to use IPP to talk to
'printers' on the Internet. This would be a big change. I do not place a
value judement on this - I merely point out the enormity of the change that
would occur.
I should point out that at one of the first IPP meeting attended by MS we
pointed out that using HTTP primarily as a means of 'stealthing' through
firewalls was totally bogus and this continues to be our position. The PWG
came to an uneasy agreement that the 'firewall issue' was no longer open for
debate since the group divided in two on it and would not be reconciled.
> -----Original Message-----
> From: Rob Polansky [SMTP: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.)
> > > >> >
> > > >
> >