Keith Moore wrote:
> > . . .
> > > > > 3. Aside from the technical implications of intercepting traffic,
> > > > > redirecting it to unintended destinations, or forging traffic from
> > > > > someone else's IP address - there are also legal, social, moral and
> > > > > commercial implications of doing so.
> > > >
> > > > You will need to be far more specific here. I see absolutely nothing that
> > > > is not legal, is not social, or is not moral.
> > >
> > > Okay, I'll offer a few specific examples, by no means the only ones:
> > >
> > > 1. an Internet service provider which deliberately intercepts traffic
> > > (say, an IP packet) which was intended for one address or service,
> > > and delivers it to another address or service (say that of an interception
> > > proxy) may be misrepresenting the service it provides (it's not really
> > > providing IP datagram delivery service because IP doesn't work this way).
> >
> > Okay, I think I see the mistake you're making. You're crossing
> > abstraction layers and conflating two different things (the name of
> > a service with the end point of the connection to that service). You
> > are criticizing the moving of an endpoint when what you really
> > object to is the misrepresentation of a service. Or do you also
> > object to HTTP redirects, dynamic URL rewriting, CNAMEs, telephone
> > Call Forwarding, or post office redirecting of mail after you move?
>
> I don't object to redirects at all, as long as they are carefully
> designed. I do object to misrepresenting the service. As I've
> said elsewhere, if the service wants to set up an interception proxy
> on its own network to help make its service more scalable, I have
> no problem with that. I do have a problem with unauthorized third
> parties setting up interception proxies. (which is according to
> my understanding all the most common application of such devices)
I, too, have been watching this conversation from the sidelines, primarily to see the general opinions of the IETF on this topic. However, as one who is considering deploying such devices both topologically close to servers (so-called "Web accelerators") and topologically close to clients of the servers (as an owner of the servers -- so-called "content distribution"), this is of vital interest to me. In both cases that we are considering, the devices are within the same administrative domain as the servers (effectively administered by the content owner). This is, as a number of people mentioned, a key differentiator in this discussion.
For Internet network-based applications such as streaming media and rich content, both of these technique provide significant advantages for the administrators of the delivery, hence the intent of NECP is important.
And, as Bill Sommerfeld wrote:
> A quick read through draft-cerpa-necp-02.txt suggests that it's
> primarily targeted at forms of redirection which occur at the request
> of service operators. Such systems are best thought of as a funny
> kind of application-layer proxy, and are far less damaging to the
> end-to-end internet model than the transparent proxies cited above.
>
> I think it's important to carefully distinguish between these sorts of
> redirection. Some clarifying text in the draft to this effect would
> be helpful.
I agree that this is important, as well.
Patrik Fältström said
> I have no problem whatsoever to have proxies being part of the
> web-model, but I am strongly opposing someone in the middle of the
> communication path intercepting and redirecting IP-packages, as the
> client will not communicate with whoever he wanted.
With which I also agree.
However, I do not see an appropriate documentation of NECP as incompatible with those two views.
ssh
--
Steve Hultquist
VP Ops
Accumedia, Boulder, CO USA
