Subject: RE: OPES protocol, pre-draft

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 19 Feb 2003 14:15:38 -0500

agreed,

abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Wednesday, February 19, 2003 2:02 PM
> To: [email-masked]
> 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.
> 
>

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 19 Feb 2003 13:19:42 -0700

If you are going to allow the callout processor to have that much
control, then it should be a fully general engine and be able to
select the transport protocol, port numbers, application protocol,
etc.  Heck, it should be able to open the connections itself.  I'd
presented this concept at one of the pre-WG meetings, as an additional
work item that might go onto a charter someday, but there was no
interest.  It's still a fine idea, but not for this WG.

The very focused approach of in-the-flow content adaptation that we have
now is a good one, and it reflects current practice and engineering
principles that are known to work very efficiently.  In this model,
the communication control point is the OPES box, and it is not slaved
to the callout servers.  The OPES rules can be used to change the source
and destination, and the OPES box is the most efficient place to accomplish
that function.

Spreading the essential control functions over a set of callout servers sets
up all kinds of configuration nightmares that will hinder adoption of
OPES.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 19 Feb 2003 14:48:40 -0700 (MST)

On Wed, 19 Feb 2003, The Purple Streak, Hilarie Orman wrote:

> etc.

Yes, the scope of the allowed callout server modifications is not
obvious:

	- Limit to application message content/payload only?
	  but modifying content often requires modifying headers!
	  but content is sometimes passed in the headers!
	  but e-mail applications require modifying destination
	  addresses!

	- Limit to application message (headers+payload) only?
	  but examples demonstrate that it is often possible
	  to modify the destination address and even the
	  protocol by modifying the message headers and
	  tricking OPES processor into modifying connection-level
	  properties; if tricks are possible we should make
	  them explicit!

	- Limit to any changes within the same application protocol?
	  but I want to convert FTP to HTTP!

	- Limit nothing?
	  but can we address privacy/security concerns if there are
	  no limits to what OPES can do?

> Heck, it should be able to open the connections itself.

I do not think we can technically prevent/prohibit that.

Ideally, our goal should be NOT to prohibit all "bad" actions we can
think of, but design the protocol that makes privacy/security
violations detectable and traceable. We cannot control real-world
implementations; they will violate our MUSTs if our MUSTs are too
restrictive (HTTP is a good example). What we might be able to do is
to enable data consumers and data producers to optionally detect and
attribute violations of their preferences.

For example: the client does not care whether a callout server opened
a connection to doubleckick.com while processing an HTTP transaction.
The client only cares that doubleckick.com does not insert an X-rated
ad into the response.

> I'd presented this concept at one of the pre-WG meetings, as an
> additional work item that might go onto a charter someday, but there
> was no interest.  It's still a fine idea, but not for this WG.

It seems within current WG scope though. Content adaptation may
include "redirecting" content to a better "adapter".

> The very focused approach of in-the-flow content adaptation that we
> have now is a good one, and it reflects current practice and
> engineering principles that are known to work very efficiently.

True. That is why I originally asked whether there is consensus on
this issue. If others are convinced by your arguments, I will adjust
the protocol draft accordingly.

> ... The OPES rules can be used to change the source and destination,
> and the OPES box is the most efficient place to accomplish that
> function.

That's a very good point! However, I am not sure the current drafts
allow what you want. draft-ietf-opes-architecture-04.txt says "OPES
rules:  these specify when and how to execute OPES services." This
does not seem to include any modifications.
draft-beck-opes-irml-02.txt does not seem to have any rules that can
modify anything. The rules in that draft are only for invoking an
appropriate OPES service.

So, it looks like there is a second, related question to be asked. Do
we want OPES rules to be able to modify something? For example, should
OPES rules be able to modify destination of an application message?

If we allow modification-by-rules but not by callout servers, how can
an OPES system implement the following modifications?

	- if HTTP request contains an XSS (cross-site script),
	  encode XSS to be HTML-safe, and change the destination
	  URL to example.com/explain/XSS.

	- if incoming e-mail contains a virus, delete the
	  virus and redirect the e-mail to [email-masked];
	  send a notification to the recipient

As you can see, the above examples make destination modification
dependent on content filtering/modification done by the callout
server. Can/should OPES support the above?

Thank you,

Alex.