On Sat, 08 Apr 2000 15:28:12 EDT, Keith Moore said:
The simple fact is that I believe that the idea of interception proxies
does not have sufficient technical merit to be published by IETF, and
that IETF's publication of a document that tends to promote the use
of such devices would actually be harmful to Internet operation and
its ability to support applications. Reasonable people can disagree
Keith: I think that there's been sufficient commentary here that
interception proxies *do* have a place, both at the "server" end (for
load-balancing server, etc), and at the "client" end.
I certainly agree that interception proxies at the server end are very useful,
and also note that as they are necessarily under the same administrative
control as the servers themselves, the various issues regarding content
alteration do not arise. In addition, since all users are likely to be
subjected to the sae proxy experience, it doesn't cause unecessary user
surprise. Indeed, this sort of thing seems to be an essential ingredient in
building really large "virtual servers", and having specifications that
facilitate doing this correctly would be a very good thing.
I also agree that interception proxies at the client end have their place,
although in such a case I don't think NECP is going to be applicable.
However, I am
fully in agreement that interception proxies imposed anyplace other
than either endpoint of the connection is a Bad Idea, because a third
party can't be sure of the connection. I'm willing to do something at
my end, because I know that I wanted to connect to foobar.sprocket.com,
and what semantics that involves. foobar.sprocket.com can make
decisions, based on its knowledge that any packet on port 7952 is
either for their monkey-widget server, or invalid. But my transit
providers don't have any basis for making such decisions.
Exactly. And after having read this specification, I also think these issues
are glossed over.
I'd have to vote against progressing it without language making this
distinction as clear as possible.
Agreed. I think the right thing to do at this point is to revise the
specification. One possible approach, and the one I'd prefer, is to simply call
for NECP to only be used on the server side. Alternately, the distinction of
the location of the service could be made clearer and the perils of arbitrary
intermediate use spelled out.
I also see some technical issues in the protocol itself. For example, the
performance metric set seems inadequate, at least based on my past experience
with other load balancing systems. OTOH, the set is extensible, so this
could be corrected fairly easily.
I also don't see a way for servers to pass information about what security
options to use when a proxy routes a connection back to that server. This sort
of thing has proved to be quite useful in practice. Even worse, doing this
properly would require an encryption option; as far as I can see the present
protocol only allows for integrity checks. I'm also not entirely comfortable
with how integrity checking gets turned on to begin with -- it seems to me that
there are some loopholes that would allow unauthorized interceptions under
some allowed circumstances.
Finally, the mechansisms for controlling which connection get routed
where seem inadequate. In practice it is common to have a need for
proxies to do authentication and based on the authentication they do,
route the connection to a particular server. Some hooks for specifying
this sort of thing as the server comes online will be essential in many
applications.
However, I don't see any of these technical issues as impediments to
publication as informational or experimental.
Ned