-----Original Message-----
From: Ian Cooper [mailto:ian(_at_)the-coopers(_dot_)org]
Sent: Thursday, November 29, 2001 10:02 PM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: 'ietf-openproxy(_at_)imc(_dot_)org'
Subject: RE: Draft on Callout Protocol Requirements
--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.
Hello Ian,
Actually I was refering and acknowledging the fact that routers can run an
OPES intermediary and still meet the "this is for explicitly configured
connections between user agent and OPES intermediary".
IMO when people think of OPES they are automatically thiking about an
appliance, another self-contained physical device. Although several OPES
intermediaries will come be this way, other alternatives will appear.
There are several routers today from different vendors that run a full blown
stateful and/or proxy firewall (and btw can also do request-routing) . If
you already have the proxy intelligence and scalability to do so, the only
part missing is the "authorization" part. Add to this fact that it becomes a
one box solution, it's going to probably be software upgradable, routers are
already in path of the data and nowadays usually can handle thousands of
sessions.
Of course implementations will change. It can be in-house, built on top of
existing software or OEM/licensing. I can think of two router vendors today
where their firewall is nothing more than a general purpose PC blade running
a software from a different company. You can easily extend this model where
a router vendor makes an agreement with one of the caching/proxy appliance
vendors out there to OEM its software or just use the "technology in blade"
approach.
thanks,
Reinaldo
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.