ietf
[Top] [All Lists]

Re: interception proxies

2000-04-12 13:40:02


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(_dot_)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



<Prev in Thread] Current Thread [Next in Thread>