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

Reply via email to