-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of The
Purple Streak
(Hilarie Orman)
Sent: Thursday, June 06, 2002 8:01 PM
Cc: OPES Group
Subject: Re: Content Provider Notification
Oskar Batuner wrote:
On OPES advertisement/notification headers:
The main idea is to let the content server know that
there is an OPES entity in the dataflow path. Adding
an "existence and capabilities" notification to request
or response does not replace tracing and reporting
mechanism, it just supplements it and helps to overcome
limitations imposed by "don't break end-to-end HTTP" rule.
If such notification is present it SHALL include:
a) OPES protocol extensions level supported, including
tracing and reporting support available;
b) method to be used by the content server to communicate
with OPES server - OPES extensions to base protocol or
out-of-band. In the latter case OPES server address
MUST be included.
[HKO] This implies that there is a new communication protocol and
that the OPES server MUST be directly addressable from outside
the content path. That opens a security hole for DOS attacks
that didn't have to be there before.
I'm afraid this is not exactly correct, see draft p.9:
"One of those annotations could be a URL with more detailed
information on the transformation that occurred to the data
on the OPES flow."
I do not see an additional risk in both cases: If I understand
correctly the architecture statements (like Figure 1) - OPES
works over TCP/IP connection that terminates at OPES entity.
This means that the entity's IP is already exposed. Explicit
declaration just removes dependency from the underlying
protocol and points to the address that OPES entity wants to
use for communication. Very convenient for legitimate usage
(may be different from the connection IP) but not essential for
attackers - they may use IP anyway.
As for adding out-of-band capabilities - you are right about
complexity that comes with them, but satisfying all OPES
requirements in-band may also be tricky. It may result in
unnecessary growth of OPES-related information added to each
message - in-band channel may be closed after any
request/response exchange and there will be no second
chance to ask questions.
It MAY also include:
c) OPES server origin-of-authority address (if one is different
from the OPES server itself and the OPES server is willing to
expose one). This may be useful for out-of-band negotiations
(for example getting/checking authorization for certain actions
or signing up for pay-per-use services);
[HKO] Signing up for services is not part of the OPES callout or
tracing protocol. The architecture specifies this as a separate
function. I don't see how an SOA in a request helps the process.
Let's suppose some service requires authorization for usage or
control. Content server (or user agent) may go to the SOA
server and get an authorization. How this is done is outside
of OPES architecture. But then this authorization will be
included into all (restricted) instructions to the OPES
server - probably using OPES extension to the base
protocol.
d) services or classes of services available.
[HKO] Do you mean "available" or "might be applied sometime to the
result of this request"? What about subsequent requests for the
same content, requests that do not go to the origin server? If
the OPES data processor changes it policies, must it notify all
origin servers for which it holds cached data of the changes?
I mean "available in general". As you've pointed out earlier
it may be not possible to determine what rules will be applied
without analyzing the response, and I do not propose notifying
server of all possible variations.
The goal is to give the server (or user agent) a possibility to
add some advise/instructions related to the specific service
class. Some (naive) examples are:
"I'm a translation service" - "Include original text with
translation"
"I'm going to insert regional ads" - "Sports related will
work best with this content"
Due to the generic nature of such instructions they remain
valid for subsequent requests for the same content, change
of OPES policy just affects the way instructions are applied.
I don't think such notification creates a scalability
problem - number of OPES servers in a particular dataflow is
very limited. The main goal of notification is not to advertise
all available services or their classes (though this also may
be feasible in some cases) but to declare willingness of the
OPES server to disclose its presence and negotiate services
(including tracing and reporting) with the content server
or user agent.
[HKO] This extra negotiation seems to be a needless complication.
Sorry, maybe I've used a wrong word. Here by negotiations I mean
willingness to take into account OPES-related instructions/advice
from the server or user agent and ability to satisfy inquiries
like those proposed by John Morris. BTW such inquiry is a good
candidate for out-of-band communications.
Oskar