One of the innovations of HTTP in respect to many other protocols is that
you do not need to modify the HTTP standard in order to add new methods for
use with HTTP. Rather HTTP defines exactly how one is to act if one receives
an unknown method. Thus one can safely add new methods and know that at the
worst one will simply receive a method unknown error from servers/firewalls
and be tunneled by proxies.
Firewall designers understood this simple design goal and thus allowed
administrators to specify which methods they did and did not want to allow
through their firewall. Thus the issue is not forcing administrators to rev
their firewalls to be compliant with some new standard but rather having
administrators brought into the loop in order to approve the use of a new
method through their firewall. Once they approve they need only change
settings on their firewall to permit the new method. It is this very process
that firewalls were introduced to enforce. Administrators realized they
could not possibly control what every server in their network did. Rather
than chasing after every user in order to ensure they were not running
"unapproved" or "insecure" software they configured their network such that
anyone wishing to do anything external to the network had to run through
their firewall.
Thus were IPP to use a new method there would be absolutely no need to alter
the HTTP standard and IPP would be acting in a manner consistent with the
express desires of the administrative community.
Yaron
> -----Original Message-----
> From: Yaron Goland
> Sent: Wednesday, June 03, 1998 11:03 AM
> To: 'Rob Polansky'; Paul Moore
> Cc: http-wg; ipp@pwg.org
> Subject: 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.)
> > > > >> >
> > > > >
> > >
> >
>