Some initial thoughts:
1. Tracing information has to be provided in-band, I see no
other way to satisfy current architecture requirements. The
OPES architecture states that:
"The OPES architecture requires that tracing be feasible
on the OPES flow per OPES processor using in-band annotation. "
This requirements is essential, it provides participants with the
ability to detect OPES in the course of normal interaction. It is
necessary to satisfy IAB. Without in-band tracing one should undertake
special query to find out if there was something done to the data.
This may be not feasible - how do you know where to look without
tracing info?
2. We have to decide on the in-band - out-of-band balance for tracing
facilities. Two extreme approaches are:
- in-band data provides only a reference to the point to the facility where
the tracing information may be obtained;
- include all information in-band.
Advantage of the first approach: a) Tracing information may be provided
in application protocol independent manner. b) Level of details is
determined by direct request, lengthy descriptions may be provided
without an impact on the application protocol efficiency.
Disadvantages: a complex identification mechanism is needed to retrieve
application message specific information (like "virus checking applied"), and
getting such simple notification will involve overhead of creating or
keeping an additional connection.
The second approach provides a kind of opposite advantages and disadvantages:
simple per-message information binding but application protocol may be
cluttered
with excess information that is not relevant to the current session (may be
due to the lack of interest of the participants).
An additional advantage of in-band approach is end-to-end coverage: tracing
information and related directives are available to all OPES flow
participants,
no topology knowledge is required.
A reasonable combination may include message-related information in band and
a reference to the session-related information. To adjust in-band information
level to the needs of session participants some trace control directives
should
be defined (as an application protocol extensions).
3.
- what has to be identified by the tracing capabilities? The
OPES processors, the callout servers, the services themselves?
All entities/services on the path between content consumer and
content provider, or only the those in the direct trust domain?
The purpose of identification (exposure) should be defined by the
intended use. Only the information points (where some participant
may call for additional information) and reference points (those that should
be identified in related request, e.g. to the center of authority) should be
exposed. If there are points that may accept directives (e.g. privacy
directives) - they should be exposed.
Also session participants should be notified about the center of
authority for the OPES server.
Any such explicitly identified point may be on the path or out of the path,
this should not be a factor. Points on the path are exposed by IP,
as according to IAB requirements connections are terminated at these points.
For security reasons we may require explicit identification included
in tracing information and signed. This will prevent man-in-the-middle attacks
and
help to enforce OPES security and tracing requirements.
Information about services should be provided in-band and should uniquely
identify the service provider and service type, but not the service point
(OPES
server). This makes service information location independent and facilitates
system reconfiguration, including failover and recovery: agreements and
parameters
may be transferred to another OPES server (within the same trust domain)
without
renegotiation with end-point.
Direct point exposure (let's say by inclusion of URL into the tracing
information)
raises a question about out-of-band protocol used to access this point.
SOAP looks like a good candidate for that.
4. Tracing information may be used by end-points to discover OPES services
and verify and/or set service properties and aslo by another OPES servises
in the flow to negotiate/adopt actions (regional ads/weather already inserted,
virus checking done and signed by trusted entity, etc.).
5. > - are there implications on the callout protocol with respect to
tracing and debugging? If no, are we sure about this? If yes,
what do we have to build into the callout protocol to make it work
(and possibly to enforce it?
As for callout servers - from the OPES flow participant view they do not
exist as an independent OPES entity. They may be exposed in-band, but
in-band exposure should not identify them as callout servers, in-band
they should identify themselves as services. This method (described above)
is well suited for service participants that are not visible by network
traffic and base application protocol.
Of cause there may be situation when callout server is exposed as
an explicit reference point for one of the reasons described above, but
this type of exposure is only indirectly determined by their role in the
message processing, this decision has more to do with the center of authority
and policy enforcement point.
Callout protocol should be able to support OPES processor actions, as
it is the OPES processor who is finally responsible for the policy
enforcement.
OPES processor should be able to request information required by the OPES
security
and privacy model. OPES processor may request/negotiate tracing info insertion
and should be able to verify the presence and correctness of such
information.
6. > - can the tracing and debugging feature be enforced? How?
An absolute enforcement is very difficult - unless all application protocol
messages are digitally signed. For now any intercepting proxy can do
anything it wants - undetected. This is further complicated by the arcitecture
requirement that "the presence of an OPES processor in the data request/
response flow SHALL NOT interfere with the operations of non-OPES
aware clients and servers".
What we can do - we can make OPES an all-or-nothing thing. Nothing means that
device that is acting as an OPES processor whould do but that does not expose
itself, puts no info in messages, violates all or any OPES rules - in fact
does not
belong to the OPES realm. Mandatory requirements for tracing mean that
OPES flow participants are given certain means of compliance control.
Enforcement remains responsibility of the OPES processor.
Debugging features may be part of the protocol requirements but I'd not use
the word "enforcement" related to debugging.
Tracing features that are used to support interaction of independent OPES
entities may be subject of interoperability testing.
Just some random thoughts.
- Oskar
-----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
Markus Hofmann
Sent: Saturday, March 29, 2003 2:04 PM
To: OPES Group
Subject: Need to look at tracing and debuggig
Hi,
with a first draft on the fundamental design of the OPES callout
protocol being distributed, allow me to remind the WG of the
importance of the tracing and debugging functionality (also given by
the IAB considerations for OPES). We've to take this very seriously!
We have to look at tracing and debugging *now* and must not assume
that it can easily be tagged onto the protocol at some later point. I
would like to see some discussion on how we actually do the tracing
and debugging, based on which the (possible) impact on the callout
protocol can be determined. Only than, we can advance with the callout
protocol!
In particular, one might ask
- what has to be identified by the tracing capabilities? The
OPES processors, the callout servers, the services themselves?
All entities/services on the path between content consumer and
content provider, or only the those in the direct trust domain?
- how are the entities identified, what's the name space? In
particular, we need to keep in mind that the IP address of an
entitiy might not work out, since it might be a non-routable one
(e.g. a callout server behind a NAT/firewall)
- how exactly is thetracing information conveyed to the end points?
In-band in the application message protocol (e.h. in HTTP
extensions?)
- what does the endpoint do with the tracing information, i.e. how
can it contact possible faulty OPES service providers etc.
- can the tracing and debugging feature be enforced? How?
- are there implications on the callout protocol with respect to
tracing and debugging? If no, are we suree about this? If yes,
what do we have to build into the callout protocol to make it work
(and possibly to enforce it?
These are just a few questions to start with. I'm sure more will pop
up and will have to be answered.
Would anyone be interested in taking a lead on the discussion of
tracing and debugging, possibly by putting together some thoughts in
text form (maybe giving a specific example on how tracing/debugging
will work)? This is *very* important for advancing our protocol work.
Thanks,
Markus