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