"Participation" includes "authorization" and is part of the security
model. The notions of integrity and authorization are obligatory
in the WG documents.
Other WG's are concentrating on the network and transport layer
intermediaries. We've got HTTP and possibly RTP.
We have no control over whether or not functional layer
separation is abandoned. It had seemed a personal matter.
The detailed wording of the charter comes from Area Directors;
I don't like the connotations of "arbitrary" and can see no reason
for using it. However, it is scary to imagine the depth of the
paranoia that jumps from there to the end of the Internet
architecture.
The architecture is motivated by notions of dynamic content
and the notion of distributed semantic evaluation. It is a logical
general of caching.
The technical issue of whether or not the IP addresses are honored
is outside the scope of the charter and the technology developed
therein. If they aren't honored, OPES would not know, nor can
OPES force them to be honored, no more than it could prevent NAT
or Carnivore or a missile shield.
The OPES architecture and protocols go a long way towards building
an application friendly Internet by developing standards for a coherent
substrate for scalable application deployment. This allows caches and
gateways to provide the services needed for rich content.
Hilarie Orman
>>> "Michael W. Condry" <condry(_at_)intel(_dot_)com> 06/15/01 01:51PM >>>
Keith-
We have no focus, interest, support, love for, etc. with interception proxies.
Of course we cannot control the ISV market and if they do/do not use them.
The intermediary service are at an application level not the network
level (NAT, etc.) and in some sense are an "end" in the "middle".
This space is short of clarifying terms and we hope to help that
shortly (a result of the last workshop). Certainly this is not
looking at the problems in the MidCom area.
This does not answer all your confusions, more later.
At 02:01 PM 6/15/2001 -0400, Keith Moore wrote:
>I have several concerns about this charter.
>
>I cannot tell whether those concerns are merely due to ambiguities in
>the charter. I hope this is the case, and that the proponents of
>the group will be willing to clarify the charter to narrow the apparent
>scope of this proposed group.
>
>
> > The Open Plugable Edge Service (OPES) WG primary task is to define a
> > protocol to be used to extend participating transit intermediaries to
> > incorporate services executed on application data transported by HTTP.
>
>What are "participating transit intermediaries"?
>
>To me, an intermediary is anything that handles network traffic and
>which is not an endpoint, regardless of what layer of the stack it
>operates on, or on whose behalf it is operating.
>
>Do the charter authors intend that this group's purview include bridges,
>routers, NATs, proxies, firewalls, gateways, etc? how about things
>that operate on multiple layers ?
>
>(If this group is approved are we abandoning the idea of functional
>separation between layers in the internet architecture? )
>
>Are "intermediaries" intended to include interception proxies?
>
>Does it matter whether the intermediary is operating on the client's
>behalf, on the content-provider's behalf, or on behalf of some
>communications provider?
>
>Re: "application data transported by HTTP" -
>
>Does this mean that this group's purview is limited to things that use
>the HTTP protocol?
>
>Are we now trying to encourage people to layer applications over HTTP,
>in spite of the concerns outlined in draft-moore-using-http-01.txt ?
>
> > The protocol provides a framework for integrating arbitrary services
> > into arbitrary intermediaries.
>
>The word "arbitrary" here is scary. Is this group really being given
>a charter to allow it to entirely discard the internet architecture?
>
>In other words, is this group going to define standard ways to say
>
>- "yes, it's okay if you ignore the destination IP address for this
> packet, and route it to some other location?"
>
>- "yes, it's okay if you break end-to-end transparency of the packet,
> not just for the packet header, but also for the payload?"
>
> (or similarly for end-to-end transparency of the transport protocol
> stream)
>
>And who is allowed to consent to such deviations? One of the
>endpoints or someone carrying the traffic?
>
> > Intermediaries may employ either local
> > or remote ("callout") servers to perform a service, and as a result,
> > the data may be diverted temporarily over a closed loop pathway
> > different from the transit pathway. Intermediary services provided in
> > this way are not transparent: Either the content requestor or provider
> > will be aware that a tranformation has been performed.
>
>Why is it (apparently) sufficient that one of the end points "be aware"
>that the data path is not transparent, rather than "consent"?
>
>Is this group really going to legitimize arbitrary corruption of the
>data stream by intermediaries which the endpoints do not control,
>just so long as one of the end points is "aware" of the corruption?
>
> > As part of the development of this protocol the WG will produce an
> > analysis of the security impliciations of this architecture.
>
>Why is security the only concern that the group is expected to analyze?
>It seems like reliability, predictability, ability to distinguish errors
>from normal operation, ability to diagnose and problems, user privacy, and
>intellectual property rights, are all at least as important as security.
>
>It also seems like there should be strict constraints on when this technology
>should be used. If we do this work, will we be saying that it's legitimate
>for ISPs to rewrite HTTP requests or responses for better traffic
>utilization?
>How about to insert or delete advertisements, or to hide content that the ISP
>doesn't want the user to transmit or receive?
>
> > A secondary task for this WG is to enumerate the requirements for
> > management policies and associated administrative protocols that allow
> > these services to be specified and deployed.
> >
> > The advantage of standardizing a protocol for this is that services can
> > be re-used across vendor products without modifying the transit
> > intermediaries or services.
>
>Something very important seems to be missing from this charter, namely:
>
>Why is this activity beneficial for the Internet user community?
>
>Or to put it another way (and if my understanding is correct), how is this
>protocol so valuable for the Internet community that it is worth destroying
>the Internet architecture ?
>
>(Or am I missing some implied constraints on the WG's charter that would
>make it reasonable?)
>
>
>
>This charter seems either dangerous, or dangerously ambiguous.
>I am hoping that it is the latter, and that the charter's intent
>is to do something reasonable and useful. But I cannot tell from
>reading the charter what is reasonable and useful about what this
>group proposes to do.
>
>
>Keith
Michael W. Condry
Director, Network Edge Technology