--On Thursday, November 29, 2001 20:58 -0800 Reinaldo Penno
<reinaldo_penno(_at_)nortelnetworks(_dot_)com> wrote:
-----Original Message-----
From: Maciocco, Christian [mailto:christian(_dot_)maciocco(_at_)intel(_dot_)com]
Sent: Wednesday, November 28, 2001 2:22 PM
To: 'Ian Cooper'; ietf-openproxy(_at_)imc(_dot_)org
Cc: Phil Rzewski; Penno, Reinaldo [SC9:T327:EXCH]
Subject: RE: Draft on Callout Protocol Requirements
I agree with Ian. An OPES service needs to be explicitely
requested and must
not brake the end-to-end connection. The place to do this is
on proxies the
client connects to, where the connections are terminated.
I don't see OPES services working out of an L3 sniffer kind of device.
Right, but that doesn't mean some vendor will not do it. OPES is a
logical entity, it can run in an appliance or in a router. It can run in
a edge/access router (or even in a DSL Router in somebody's home) and
still meet all the requirements.
Quite, and this is the big Pandora's Box that many folks are really worried
about.
The working group and others can say "this is for explicitly configured
connections between user agent and OPES intermediary" until they're blue in
the face, but there's nothing (at the moment) to stop someone using the
technology in an intercepted ("transparent") manner.
One of the key things I think folks should be thinking about here is
whether there's anything in the architecture and the protocols being
considered (e.g. HTTP) that could help the end-user(s) know if an
intercepting OPES session is taking place. (I suspect that outside
end-to-end encryption/signing there isn't a lot that can really be done; a
skim of the draft you've co-authored suggests you might be suggesting some
of this stuff.)
As an aside, I'd suggest that the bullets 4.1 and 4.3 in the revised agenda
run next to each other.