RE: Chaining of Callout Servers

["Joseph Hui" <Joseph.Hui@xxxxxxxxxx>]

I believe the support of callout server chaining/chain (CSC),
thus making pipelined content processing possible and scalable,
is a good thing.  

That said, I also believe, in consideration of security and privacy,
it'd be prudent to also require that the transitivity of trust
along a CSC be controllable to some reasonable extent by the CSC caller.
I'm using the "to some reasonable extent" phrase, because in
reality this will present a great challenge to the callout
protocol designers.  The key is to allow the caller some
means to manage, albeit not absolutely, the transitivity
of its trust, such as expressing its trust policy (as a
part of its security policy) in a callout metric where
the servers it trusts and to what degrees are listed.
Now, to trust a server (in a CSC) that the caller has no
direct contact with is inherently a precarious proposition.
Then again, the whole OPES model itself was a precarious
proposition; but we got over that.  Didn't we?  
Well, even if not entirely, the difference would be like
playing with fire or with a frying pan -- it's easy
to get burnt either way.  :-)
So might as well go for it: do the CSC.

As for impacts, the following is my immediate take,
which is by no means exhaustive.   

The value and usefulness of pipelined
processing can be trivially demonstrated, using a
Unix command line as an example, say, A|B|C.  That's
a positive.  Another positive I see is that, in case,
just in case, the OPES drive doesn't get where it wanted
to go, the IETF community would have at least learned
some very valuable lessons.  (Of course I don't mean
lessons on how to fail. ;-)

The first negative comes to mind is:
a typical CSC involves multiple servers instead of a
single server, consequently it presents a "fatter" target
for attackers, and more points of potential failure.
Data integrity should not be an issue.  TLS/TCP connections
can ensure secure/reliable transport.  Data fidelity, the
distortion of content from its original form due
to transformation performed by callout servers in a CSC,
may likely be proportionally affected by the number of
servers.

Cheers,

Joe Hui
Exodus, a Cable & Wireless service
===============================================

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@xxxxxxxx]
> Sent: Monday, July 22, 2002 7:29 PM
> To: OPES Group
> Subject: Chaining of Callout Servers
> 
> 
> 
> Hi,
> 
> we want to wrap up the existing three OPES WG documents and 
> issue a WG 
> last call as soon as possible!! In order to do so, we need to find 
> consensus on the few remaining open issues that came up during the 
> meeting last week!
> 
> One issue that affects all three documents is the question whether we 
> should allow/support chaining of OPES callout servers. Chaining of 
> OPES callout servers refers to a scenario in which an OPES processor 
> forwards a message to callout server A, and callout server A forwards 
> the same message for (additional) servicing to callout server B.
> 
> We had a brief discussion on this issue on the general OPES mailing 
> list before, in the context of OPES callout protocol 
> requirements, and 
> the feeling somehow was to *not* require protocol support for callout 
> server chaining. However, the scenarios doc (and the architecture 
> doc???) still have the notion of server chaining in.
> 
> Question to the group: What's the consensus - should we explicitly 
> allow/support callout server chaining? If yes, what are the impacts 
> with respect to complexity, reliability, fault-tolerance, data 
> integrity, privacy, security, etc? What are the specific scenarios in 
> which such a mechanism would be beneficial? And would the expected 
> benefits outweigh the additional complexity?
> 
> Any opinions on that?
> 
> Cheers,
>    Markus
> 
>