Subject: recommendation against publication of draft-cerpa-necp-02.txt

From: Keith Moore <[email-masked]>
Date: Thu, 06 Apr 2000 12:41:33 -0400

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

---

From: Karl Auerbach <[email-masked]>
Date: Thu, 6 Apr 2000 21:29:40 -0700 (Pacific Daylight Time)

> someone else's IP address - there are also legal, social, moral and
> commercial implications of doing so.

You will need to be far more specific here.  I see absolutely nothing that
is not legal, is not social, or is not moral.  I do see commercial
implications, but whether those are is "good" or "bad" is not a technical
judgement.
 
> practices by publishing an RFC which implicitly endorses them, even
> though the authors are employed by major research institutions and
> hardware vendors.

I take the contrary position.  The IETF ought to be encouraging the
documentation of *all* practices on the net.  It is far better that they
are documented where people can find useful information when they see this
kind of packet activity rather than have them known only to a few
cognescenti.

May I suggest that one treat this in its classical sense - as a Request
for Comments and that those who have technical objections or technical
enhancements publish those comments in an additional document rather than
try to suppress the original one.

Having a document trail that shows what paths and ideas have been found
wanting is nearly as important has having a trail that show what paths
have been found useful.

		--karl--

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 7 Apr 2000 01:05:14 -0700

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:[email-masked]]
Sent: Thursday, April 06, 2000 9:42 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: recommendation against publication of draft-cerpa-necp-02.txt

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

and Caching Taxonomy" [reference 3], and "Known HTTP Proxy/Caching
Problems".

best regards,

Keith Moore

-
This message was passed through [email-masked], which
is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by Harald Alvestrand.

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Apr 2000 10:31:55 -0400

> 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

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.

> 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.

> 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

---

From: Matt Holdrege <[email-masked]>
Date: Sat, 08 Apr 2000 11:22:46 -0700

>So I'm not sure that this is a good model on which to base future work.

I hate to extend this long thread, but since aspersions were cast...

There were no forces in NAT attempting to mislead readers. There were 
disagreements on terminology. Extensive review fixed these terminology 
issues. Perhaps as others have said draft-cerpa-necp-02.txt suffers a bit 
from misunderstandings and will benefit now from the IETF review.

Matt - NAT WG co-chair

---

From: John Martin <[email-masked]>
Date: Mon, 10 Apr 2000 14:57:19 +0200

I have held off commenting until I saw what the IETF community at large 
would have to say. Disclosure: I work for Network Appliance, was involved 
in the very early stages (though not latterly) of NECP and fully support 
its publication as an Informational RFC. I am also co-chair of WREC.

As has happened when this document was previously discussed by the IESG, 
the discussion inevitably takes a turn towards a discussion of 
"transparent" caching (latterly renamed "interception proxies" by WREC). 
Let me be absolutely clear, NECP is about communication between server 
load-balancers (SLB) and the back-end servers they speak to. Nothing more, 
nothing less. The fact that one common use of these is for caching proxies, 
and that these are used as an example, does not mean that NECP in any way 
specifies how "transparent" or "redirection" takes place.

[In fact, the most common deployment of these type of service load 
balancers is non-transparent (i.e. where the user configures their browser 
with a proxy IP address which is, in fact, a load-balancing element talking 
to a number of back-end servers). For a discussion of "transparent" versus 
"non-transparent" proxies, please refer to draft-ietf-wrec-taxonomy-03.txt.]

However, that is by far not the only application. DNS, web servers and 
firewall load balancing are the three other main applications for SLBs.

Now, let me address each of the original concerns in turn. Note that I have 
done this privately to Keith on many occasions as well as to the IESG, IAB 
and others on the WREC WG list.

>it means for a non-standard to have mandatory features.

The document is not an IETF standard but it does describe a protocol. For 
protocols to work correctly, there must be certain "mandatory" minimal 
requirements on those implementing that protocol.

I can see one or two places where the word "standard" might be 
misinterpreted by readers if used out of context.

Section 5.2, 5.2.1, 5.2.2, 5.5.1

       "The version number of the protocol defined by this standard is 1."

       "All implementations that adhere to the standard specified in
        this document MUST set the version number to 0x1."

       "This type of payload has no structure imposed by this standard."

         "For reasons explained in Section 6.11, this standard only
        defines a single performance query type that MUST be
        implemented by all NECP nodes:"

I see no problem with changing these. In most cases, simply replacing the 
word "standard" with the word "protocol" would convey the correct meaning 
beyond any reasonable doubt.

>facilitate the operation of so-called interception proxies.

Wrong. The primary purpose of NECP is to facilitate a load-balancing 
between SLBs and the services to which they direct traffic. "so-called 
interception proxies" are just one such service.

>Such  proxies violate the Internet Protocol in several ways:

This is not about those proxies - that is a different argument.

I  don't think it is appropriate to be drawn into an argument about the 
rights and wrongs of "interception proxies" when discussing NECP. I am more 
than happy to justify their existence - with hard facts, of course - in a 
separate thread.

Regards,
John

---------------------------------------------------------------
Network Appliance           Direct / Voicemail: +31 23 567 9615
Kruisweg 799                               Fax: +31 23 567 9699
NL-2132 NG Hoofddorp               Main Office: +31 23 567 9600
---------------------------------------------------------------

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Apr 2000 10:39:32 -0700

One other item:

	Neither this, nor many NAT I-D's, address the particular
	issue of sourcing IP addresses not assigned or owned by 
	the host/gateway, e.g., as they affect the standards
	of RFCs 1122, 1123, and 1812.

	If a device creates (rewrites) IP source addresses with
	addresses not its own, it would be useful to see a section
	specifically addressing the resulting implications.

Joe

---

From: "Eliot Lear" <[email-masked]>
Date: Tue, 11 Apr 2000 16:45:45 -0700

This whole thread is perhaps the best reason to have protocols go through
working groups, so that concerns can be raised and documented, and so that
the IESG can weigh in on correctness, risks, and yes, to a certain extent
morality.

I wonder if any of the authors has explored the risks of modifying data in
flight.  How could this be abused by interlopers and evil doers?  If I
could hack into a router implementing NECP, what damage could I do?  Could
I start a nasty little JavaScript/Java/Shockwave/... applet in an
advertisement?
And who would know it was me?

Quoth John Martin:
> [...]
> load-balancers (SLB) and the back-end servers they speak to.

Were this so clear in your document my mailbox wouldn't be full of this
stuff.

> requirements on those implementing that protocol.

If it looks like a duck and quacks like a duck, but it's not supposed to be
a duck, the IESG ought to point out that it's a turkey by so indicating at
the top of the document.  Also, I'd like to understand why you're not going
experimental, where it would be expected that you'll correct your mistakes.
Your choice of "informational" seems unfortunate at best and as
disingenuous marketing at worst.  I can't tell which.

> misinterpreted by readers if used out of context.

You somehow missed Section 1:

...  NECP provides a standard method for this signaling.

> interception proxies" are just one such service.

The document says:

   NECP now provides a
   standard server-to-network signalling interface.  This allows
   network elements in heterogenous environments to perform load
   balancing across a server farm, redirection to interception
   proxies, and cut-through of flows that can not be served by the
   farm.

The fact that you mention interception proxies in the introduction has led
to this flame war.  Having used the words, you've mentioned none of the
risks associated with such services both from the server side and the
client side.

> than happy to justify their existence - with hard facts, of course - in a

In whatever thread, the document fails to mention the legitimate security
concerns of those people who are concerned about interception.  I would
argue that our other flame war on wire tapping is (unfortunately) relevant.

Eliot Lear
Cisco Systems

---

From: John Martin <[email-masked]>
Date: Thu, 13 Apr 2000 14:20:44 +0200

>And who would know it was me?

Do you mean the authors of NECP? If so, then I'm confused because NECP is 
not about "modifying data in flight" - it is about load balancing multiple 
services which sit behind e.g. a single IP address. (i.e. DNS server farms, 
firewalls, proxies). As I have said repeatedly, "interception proxies" is 
only one of these applications and by no means the most widely used.

Are you confusing this with WCCP (which *only* works with "interception 
proxies").

>Were this so clear in your document my mailbox wouldn't be full of this

The very first sentance says:

    "This document describes "NECP", a lightweight protocol for
    signalling between servers and the network elements that forward
    traffic to them.  It is intended for use in a wide variety of
    server applications, including for origin servers, proxies, and
    interception proxies."

Despite the fact that "interception proxies" are listed last, they are the 
only service people are talking about.

But, you are right in general: if this is how people read the document, 
we  need to fix the document.

>disingenuous marketing at worst.  I can't tell which.

We used "informational" because we saw that this is what was used for 
HTTP/0.9 with which there are parallels: NECP has existed for some time 
already in slightly differing implementations and this is a codification of 
existing practice. There was no magic of deceit intended. If the IESG 
thinks we should instead go for experimental, I'd be more than happy to 
pursue that instead and bring this into WREC. However, development is not 
within the current WREC charter so we are stuck, I think?

>risks associated with such services both from the server side and the

OK - we can fix that. It is not the goal of NECP to describe "interception 
proxies" or their deficiencies. There is, however, a working group which 
has a document aimed at exactly that (amongst other things) - WREC.

---

From: "Eliot Lear" <[email-masked]>
Date: Thu, 13 Apr 2000 10:49:18 -0700

Part of the problem here is that a knife may be used as a food utensil or a
weapon.  Safe handling, however, is always required, and should be
documented.

I would add two other comments.  I tried to locate the RFC for HTTP/0.9,
but the best I could find was a reference to a CERN ftp site for the
protocol.  In any case, by the time HTTP got to the IETF it was deployed
over a vast number of end stations, and comparisons to it are probably not
apt.

Finally, rechartering is precisely what you ought to have done, and should
do, IMHO.

---

From: John Martin <[email-masked]>
Date: Thu, 13 Apr 2000 23:09:00 +0200

>weapon.  Safe handling, however, is always required, and should be

Granted.

>protocol.

Ooops. s/0.9/1.0 - rfc1945.

>   In any case, by the time HTTP got to the IETF it was deployed

NECP is a super-set of various load-balancing technologies already deployed 
at thousands of sites.

>Finally, rechartering is precisely what you ought to have done, and should

For the record: this is exactly what we are doing. (We were waiting for the 
two starter documents to be published or at least start their path via the 
IESG).

Rgds,
John