Re: interception proxies
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: interception proxies




Vernon Schryver wrote:
> 
> 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.

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. 

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

Intercepting is also done in other contexts:

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

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

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.

> ] From: Joe Touch <touch at ISI.EDU>
> 
> ] 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?)

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.

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

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

Joe




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.