The use of "load balancing" technologies is growing rapidly
because these devices provide useful functionality. These
devices utilize many different techniques, only some of which
can be characterized as "interception proxies" or "reverse
network address translation." For example, using MAC address
translation (MAT) it is possible to provide load balancing
and failover without breaking IPSEC or violating other
basic principles.
Thus it strikes me that this is a legitimate topic for
inquiry and that cannot be so easily dismissed as "morally"
unacceptable.
I agree that this is a legitimate topic for inquiry. the thing
I want to avoid is having IETF encourage deployment of
interception proxies by publishing this or similar RFCs that
(implicitly or explicitly) support the concept - at least,
until we have community consensus on which such practices are
harmful to the Internet and when they are mostly harmless.
load balancing technologies, at least as I've seen them used,
don't bother me. if you front-end your own servers with a
load-balancing box, you are presumably in a position to determine
whether the box actually suits your needs for the service you
are providing from those servers. if it doesn't suit your needs,
switch to something else. and the fact that they "forge" source
IP addresses doesn't bother me as long as the only addresses
that they are forging belong to the same people as those who
are operating the load-balancing box. to the extent that such
boxes are doing harm they're probably only hurting those who
operate them.
again, this doesn't mean that IETF should standardize such
practices (since they're a local matter). but I don't see this
as a moral issue. my real concern is about boxes are intended
to affect third-party traffic.
As we have done with the NAT WG, it is
often useful to accurately document the drawbacks of a
common practice as well as to encourage exploration of
alternatives.
From my point of view there were significant forces within the
NAT group attempting to keep the extent of these drawbacks from
being accurately documented and to mislead the readers of those
documents into thinking that NATs worked better than they do -
for instance, the repeated assertions that NATs are "transparent".
So I'm not sure that this is a good model on which to base future work.
If seen within this context, it is conceivable that we
might well want to publish draft-cerpa-necp-0x.txt at
some future date as a documentation of existing practice
with the correct caveats and references. While there are
clearly elements of the document which are misleading,
overall it does not seem unredeemable to me.
I also suspect that the document is redeemable, but that it
needs significant modification. As currently written it
does not seem intended to document current practice, but rather,
to encourage deployment of certain kinds of products, some
of which are arguably harmful.
My recommendation would be to explore formation of a WG to
deal with the issues in this area, and to remand
draft-cerpa-necp-02.txt to that WG if and when it is formed.
wrec already exists, and the intention was that it would eventually
define technically sounds mechanisms for web replication and caching.
while the technology in necp may have other uses besides web replication,
I really wonder if IETF should put its energies into defining
how to violate the Internet Protocol - especially when it seems to
me that legitmiate violations of IP (i.e. when it only affects your
own services) are likely to be "local matters" and therefore not
really candidates for internet standardization.
And as a practical matter I think it would be really difficult to
attract a balanced constituency to the working group.
But I agree that a dialog of some form is needed, which is why I
cc'ed the IETF list on my note to the RFC Editor in the first place.
Keith