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. 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.
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.
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.
-----Original Message-----
From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu]
Sent: Thursday, April 06, 2000 9:42 AM
To: rfc-ed(_at_)rfc-editor(_dot_)org
Cc: moore(_at_)cs(_dot_)utk(_dot_)edu; iesg(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
Subject: recommendation against publication of draft-cerpa-necp-02.txt
I am writing to request that the RFC Editor not publish
draft-cerpa-necp-02.txt as an RFC in its current form,
for the following reasons:
1. The document repeatedly, and misleadingly, refers to NECP as a
standard. I do not believe this is appropriate for a document
which is not on the IETF standards track. It also refers to
some features as "mandatory" even though it's not clear what
it means for a non-standard to have mandatory features.
2. A primary purpose of the NECP protocol appears to be to
facilitate the operation of so-called interception proxies. Such
proxies violate the Internet Protocol in several ways:
(1) they redirect traffic to a destination other than the one
specified in the IP header,
(2) they impersonate other IP hosts by using those hosts' IP addresses
as source addresses in traffic they generate,
(3) for some interception proxies, traffic which is passed on to the
destination host, is modified in transit, and any packet-level
checksums are regenerated.
IP allows for the network to delay, drop, or duplicate IP packets,
as part of a best effort to route them to their intended destination.
But it does not allow the above practices.
This document implicitly treats such behavior as legitimate even
though it violates the primary standard on which all Internet
interoperability depends.
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.
In my opinion IETF should not be lending support to such dubious
practices by publishing an RFC which implicitly endorses them,
even though the authors are employed by major research institutions
and hardware vendors.
4. Furthermore, while any of the above practice might be deemed "morally"
acceptable in limited circumstances (such as when the interception proxy
is being operated by the same party as the one which operates the host being
impersonated) in general these are very dangerous. There have been numerous
cases where network elements employing practices similar to the above have
been demonstrated to harm interoperability. (e.g. there is a widely-used
SMTP firewall product which breaks SMTP extension negotiation, and a
traffic shaping product was recently found to corrupt data in TCP streams
generated by certain kinds of hosts)
This document contains language touting the benefits of NECP but very
little language describing the danger of using the above techniques which
NECP was designed to support. Where the document does mention the
problems, it is misleading or incomplete. For example, the Introduction
says
However, it [an interception proxy] can cause problems: users
have no way to go directly to origin servers, as may be required in
some cases (e.g., servers that authenticate using a client's source
IP address). The proxy has a high-level understanding of the
application protocol; it can detect these cases and decide which
flows should be cut through to origin servers.
The latter sentence is a false assertion - even though the proxy has
a high level understanding of the protocol, the proxy is not generally
able to determine when cut-through is required. For example, the
service being impersonated by the interception proxy may have uses for
the client's source address which are outside of the protocol being
intercepted and for which the proxy cannot be knowledgable.
Such uses may be both active (in that they involve attempts to establish
other traffic between the origin server and the client, or between the
client and other hosts on the network), or passive (in which the origin
server uses the client's IP address without attempting to communicate
with it), or even deferred (in which an attempt is made to communicate
with the client's IP address at a later time). In addition, the *user*
may have a requirement for his client to talk directly to an origin server,
or the content provider may have a requirement for the origin server to
talk directly to a client, simply because they expect communications
integrity. By its very nature an interception proxy ignores the
requirements of the user and/or the content provider.
The document refers to two other documents which it says further
describe the dangers of interception proxies: "Internet Web Replication
and Caching Taxonomy" [reference 3], and "Known HTTP Proxy/Caching
Problems".
Both of these appear to be works in progress, and the latter document does
not even have a reference. Until such documents are published, or
at least until they are deemed ready for publication by their creators,
it is impossible to evaluate whether they contain sufficient and
accurate information to inform readers of the NECP document about
the dangers of interception proxies.
5. While in one sense NECP is an attempt to alleviate some of the harm done
by interception proxies, this document is clearly intended to encourage
and promote the use of such proxies by providing a uniform cross-vendor
interface between such proxies and network elements.
Given that NECP is intended to support violations of the Internet Protocol,
and that such violations are known to harm interoperability, such promotion
is a misuse of the RFC document series.
In summary, my recommendation is that the document not be published until:
- the promotional material is removed, leaving only technical justification
and specification
- the document is changed to point out that interception proxies are
nonstandard, that they violate the Internet Protocol, and that they
are known to degrade interoperability
- a disclaimer is added, which points out that interception proxies
are engaged in interception, misrepresentation, and forgery of network
traffic, that such practices are not endorsed by IETF, and that they
may be illegal in some jurisdictions.
- the documents describing the dangers of interception proxies
which are referenced by the NECP document are ready for
publication, and are deemed reasonably complete and accurate.
But I would also recommend that the document not be published at all,
as I believe that publication of this document will do far more to
degrade the interoperability of the Internet than it can do to help it.
There may indeed be value in publishing the document as a contribution
to the historic record of Internet development, as it certainly reflects
some current trends. However this goal could be accomplished by
delaying publication of the NECP document by several years, or at least,
until the publication of technically sound, standardized, solutions for
the problems that interception proxies attempt to address.
best regards,
Keith Moore
-
This message was passed through ietf+censored(_at_)alvestrand(_dot_)no, which
is a sublist of ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are passed.
Decisions on what to pass are made solely by Harald Alvestrand.