> 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
