Subject: Re: interception proxies

From: Vernon Schryver <[email-masked]>
Date: Tue, 11 Apr 2000 23:04:26 -0600 (MDT)

> From: Keith Moore <[email-masked]>

> ...
> agree entirely.  but for this to work there have to be folks within
> the WG who are willing to raise a fuss.  

That's a good point, but there is another question that must always be
asked.  When there is no hope of influencing something, then it can be
important to not participate.  Participation even in opposition inevitably
supports the official position.  30 years ago the word "co-opted" was used
to describe the problem.

My impression from the two WG documents is that in the WG consensus is
that HTTP interception proxies are at least tolerable and often necessary
and good, and by extension probably also for SMTP and everything else.

Yes, I noticed that "W" in "WREC" doesn't stand for "mail".  It's also
clear that intercepting or proxying are at most aspects of the "RE" and
the "C", although I don't see how that is relevant to whether the WG is
committed to interception proxies.  Draft-cerpa-necp-02.txt must be read
as advocating them, and not only for HTTP or whatever is meant by "Web."
Yes, I realize that draft wasn't a product of the WREC WG.  The two WREC
documents cannot be read as deprecating interception proxies and can be
read as advocating them by what they fail to say.

    ....

] From: Joe Touch <[email-masked]>

] FWIW, there _was_ discussion in WREC of the hazards of transparent web
] caching. I dug up an old e-mail, describing the hazards of transparent
] web caching which I summarized at the time, when WREC was forming.
]
] A copy of the note, admittedly very rough (just an outline, and a very
] rough one at that) is at:
]
] 	http://www.isi.edu/touch/pubs/hazards-outline.txt

I really like "in effect, it is a use of IP spoofing to do replay attacks."

(Why a 3rd document instead of added to Problems?)

] I would be glad to host further discussion on the WREC maillist as to
] how to augment the list and flesh it out to a full I-D before the next
] IETF, if there is sufficient interest.

Do you two think that either the IETF or the WREC working group might
agree with the thrust of that outline?  It sounds as if your answer is
"yes" and that my sense of WREC, IETF, and maybe industry sentiment is
wrong.

Vernon Schryver    [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Apr 2000 08:26:39 -0400

> important to not participate.  

My experience is that it's usually possible for an active participate
in an IETF group to influence it in a favorable way.  Despite my pessimism
about wrec, I think it may still be possible for it to produce useful
things.  If that's found to not be the case, one can ask the ADs to shut 
down the group - but the only fair thing to do is to try first.

> Participation even in opposition inevitably supports the official position.  
> 30 years ago the word "co-opted" was used to describe the problem.

at some point you need to decide whether you will go along with the
rest of the group or whether you will dissent.  but I would argue that
failure to participate in the discussion does more to support the
"official" [your word, not mine] position than participation in the
discussion.

> and good, and by extension probably also for SMTP and everything else.

the documents aren't published yet.  this can serve as a heads-up.

I will note that the wrec list has several new subscribers in the last
day or two.

> as advocating them, and not only for HTTP or whatever is meant by "Web."

perhaps that is something else that should be fixed...
(or another argument against publication)

> read as advocating them by what they fail to say.

yep, and this should be fixed also.

Keith

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Apr 2000 13:36:27 -0700

> and good, and by extension probably also for SMTP and everything else.

The arch document defines, it doesn't condone or condemn.

As to the known-probs doc, that focuses on problems of the sort that
TCPIMPL did - errors in the implementation, not deliberately changing
specs. 

> committed to interception proxies.  

Intercepting is also done in other contexts:

	- DNS
	- email
	- TCP for relay over subnets
		e.g., over wireless or intermittently-connected links

> read as advocating them by what they fail to say.

I do not agree with this statement. Failing to condemn cannot be taken
as an endorsement. It means only that the documents define, rather than
compare or advocate, architectural components.

> (Why a 3rd document instead of added to Problems?)

Because problems focuses on errors of implementation, not of
architectural design.
I would advocate that there is the need for a separate statement on
design in this case.

> "yes" and that my sense of WREC, IETF, and maybe industry sentiment is

I'll take that over to WREC, and we can have that discussion there
first.

Joe

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Apr 2000 17:12:14 -0400

> TCPIMPL did - errors in the implementation, not deliberately changing

yes, but given that there are no specs for interception proxies,
how do you judge what is and is not an error in the implementation?
or given that all interception proxies violate the IP specifications,
isn't an interception proxy by its very nature an implementation error?

Keith

---

From: Joe Touch <[email-masked]>
Date: Wed, 12 Apr 2000 15:08:18 -0700

> isn't an interception proxy by its very nature an implementation error?

This is related to TCPIMPL - new modifications to TCP are not considered
in the known-problems doc. Even if there are problems in the design of
the modification.

Joe