RE: OPES protocol, pre-draft

agreed,

abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com] 
> Sent: Wednesday, February 19, 2003 2:02 PM
> To: ietf-openproxy(_at_)imc(_dot_)org
> Subject: RE: OPES protocol, pre-draft
>
>
>
> On Wed, 19 Feb 2003, Abbie Barbir wrote:
>
> > > If there is a consensus that OPES server cannot modify source and 
> > > destination info, then we can simplify the protocol a 
> little bit. Is 
> > > there a consensus regarding this design decision? Perhaps Abbie's 
> > > poll will show...
> > well, it seems we do not have one, so here, please i would 
> like direct 
> > votes.
> >
> > Chairs, Can u please remark on this requirement???????
> >
> > For the recored, I think that OPES should be able to
> For the record, I also think that OPES should be able to. I 
> think so because (a) it allows for broader manipulations and 
> (b) some of those manipulations would be possible (in an 
> awkward way) anyway, tempting violators.
>
> The security/privacy part of the protocol should be 
> especially strong when it comes to source/destination 
> changes, of course.
>
> An example for the item (b) above. Consider two HTTP proxies 
> that are chained together. The first proxy on the request 
> path has an OPES callout server attached. A request for 
> origin server A arrives at the first proxy. The callout 
> server modifies HTTP headers so that the request is now 
> destined to a different origin server B. The modified request 
> is forwarded to the second proxy (the first proxy is not 
> aware of the destination changes). The second proxy is not 
> OPES-aware. It simply forwards the request to B. Thus, if I 
> use two proxies, I can implicitly modify request destination 
> using OPES! If this can be hacked, we would be better off 
> allowing (and controlling) it explicitly.
>
> Alex.