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(_at_)mhof(_dot_)com]
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