Subject: Re: interception proxies

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

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 <[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?)

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

---

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

"Dick St.Peters" wrote:
> 
> Would you settle for "The IP spec authors didn't have enough foresight
> to foresee a need to rewrite source addresses" ? :)
> 
> Whatever anyone thinks of it, people are doing it.  On the right are
> people saying it is immoral, evil, and dangerous, not to mention
> prohibited by the gods, and they refuse to talk about it.  On the left
> are people doing it, each their own way because there is no standard
> and not even any public discussion.

Intercepting connections and sourcing packets with addresses not owned
by you (or within your stub subnet) violates one of the few standards we
have (STD003 - the combination of RFCs 1122 and 1123).

Intercepting connections by rewriting IP headers in a gateway violates a
proposed staandard (RFC 1812).

It is not immoral, evil or dangerous; there are standards (existing and
proposed), and they are being violated.

Joe

---

From: John Martin <[email-masked]>
Date: Thu, 13 Apr 2000 12:07:39 +0200

Vernon,

At 04:47 PM 11/04/00 -0600, Vernon Schryver wrote:
>Call me a non-team playing scab, but I refuse to the honor the old guild
>work rule that limits the questions I can consider.  If sourcing
>other-owned etc. or anything else is an architectural or other problem,
>then professional pride ought to force one to raise the issue insetad of
>waiting for the AD, IESG, IAB, or a plenary to redirect things.  But I
>realize that's a minority view, and not just in IETF working groups or
>even the IETF.

When WREC was originally proposed to the IESG, its scope was much 
broader.     Since the area was, at the time, the subject of much 
confusion, our charter was changed by the IESG to begin with a taxonomy and 
a list of known problems with caching and replication as is done today. At 
the time, I disagreed but complied. With hindsight - and given recent 
discussions - I think that their decision was correct. (If for no other 
reason that we now know what to call these "interception proxy" things).

Most of us who started WREC have indeed an interest in caching and 
replication but not necessarily "interceptions proxies". This type of proxy 
is only one way to do caching / replication - and certainly by no means the 
most common. (The most common - by far - are actually standard, 
run-of-the-mill proxies configured explicitly in users' browsers).

Rgds,
John (WREC co-chair)
---------------------------------------------------------------
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: "Gary Tomlinson" <[email-masked]>
Date: Tue, 18 Apr 2000 09:08:24 -0600

Known HTTP Proxy/Caching Problems
                   draft-ietf-wrec-known-prob-01.txt

>>> John Martin <[email-masked]> 04/18/00 02:09AM >>>
>At 05:05 PM 17/04/00 -0600, Vernon Schryver wrote:
>>Is that a sign of good things happening to the document?
>>I've been hoping to see some activity in the WREC list about either
>>hijacking--uh--redirecting proxy hazards documement or the document
>>NECP Is something happening behind the scenes?  If so, please forget
>>I asked.
>
>NECP is not within the scope of WREC's current charter. NECP is being 
>revised, however, and we can expect a new version within the next few weeks 
>or so.
>
>With respect to interception proxies, I would very much like to see these 
>discussed further on WREC. Our issues document could probably do with wider 
>review than just WREC.
>

Much of the discussion that is occurring with interception proxies could be addressed
in the Known HTTP Proxy/Caching Problems <draft-ietf-wrec-known-prob-01.txt> draft.
This draft has some of the know interception proxy issues discussed, but could be greatly
expanded to include the discussions that have occured over the past four months.

>But one very common mis-conception I have noticed is about the point at 
>which redirection occurs. In my experience, the redirection takes place 
>only at either source or destination, or more specifically, at a point 
>which is under the same administrative control as the end-user or (e.g.) 
>the web server itself.
>
>A lot of the recent discussion on the IETF list seemed to assume that this 
>happened "somewhere in the middle". I'm not saying this is not possible, 
>just that it is not happening today (to my knowledge). In the future, I 
>think that it will get more, not less difficult to do this too - e.g. when 
>traffic is already tagged / labelled it will be more difficult to intercept 
>in the middle of its path.
>
>In the meantime, there are many other ways to redirect clients to the 
>closest proxy. One common way is to simply use the DNS to give a response 
>dependant on the client's source IP address (for either the proxy or the 
>destination web server); many corporates do this today already - Akamai 
>have built a whole business out of it.
>

The whole issue and associated problems with proxy service discovery IHMO is another
excellent topic for discussion and inclusion in the Known HTTP Proxy/Caching Problems
draft as well.  I for one would like to see this draft have broader review and participation.
Its clear to me that once this draft embodies a consensus of the known problems, it will 
serve as an excellent set of requirements for a rechartered WREC to develop a architecture
for this domain.

>John

Gary

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 18 Apr 2000 08:34:09 -0700 (PDT)

--- Vernon Schryver <[email-masked]> wrote:
> > From: Joe Touch <[email-masked]>
> 
> > ...
> > The only question is whether there is something similar between NATs and
> > transparent proxies. Maybe "modifying IP packets considered harmful".
> > The issue with NATs may best be added under "even within the same AD,
> > transparent proxies are dangerous because..." including the IP ID and
> > TCP port and sequence number issues there seems on-topic. (?)
> 
> Agreed, NAT's and redirecting proxies are technically similar. 
> 
> (However, I'm not sure that 'a "transparent proxy" is a proxy that does
> not modify the request or response beyond what is required for proxy
> authentication and identification' is similar to a NAT box or a redirecting
> proxy.)
> 
> Is there an RFC that includes the many complaints that have been made about
> NAT boxes in the main IETF list?
> 

Not an RFC. But, a draft addressing precisely this. 
It is titled "Protocol Complications with the IP Network Address Translator".
<draft-ietf-nat-protocol-complications-02.txt>. The draft should be going
out for an IETF-wide last call shortly(It's in Steve Coya's list of things to
do). Any comments and input are most  welcome. Thanks.

> vjs

cheers,
suresh

=====

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

---

From: "John Waterson, ITS, SENM" <[email-masked]>
Date: Tue, 18 Apr 2000 18:41:37 +0100

Hope I'm not intruding here as I'm not affiliated in any way, but as a
network bod whose job is currently affected by these issues, I've been
following the discussion with interest.

John Martin wrote:

> >In both cases the ISP must be viewed as a third party, and in
> >security terms, a man in the middle.
> 
> OK. That is the confusion. I was viewing the ISP as being in the same 
> administrative domain, at least that is true for most dialup ISPs.
> In this case, the customer has a choice to change ISP if they don't 
> like their policies.

I have to agree with Vernon on this one - the ISP *is* a third party, and
the "change your provider" argument isn't always appropriate.

Case in point: we offer a variety of HTTP-based services to our customers,
several of which require the assistance of some hand-made redirection hacks
to function properly. For certain of our customers - all of whom use the
same dialup ISP - these hacks consistently but mysteriously break. After
much scratching of heads over this, and having eliminated most other
Firewall-y/explicit client-side proxying issues, it's now looking
suspiciously like the problem stems from an interception-style proxy used by
the ISP in question (exact reason as yet unknown).

Now ideally, we'd like to get rid of our internal redirect hacking anyway,
but that isn't straightforward for other reasons. In the meantime, what are
we meant to do: tell our customers that it's a problem with their ISP, and
insist that they switch?

Doesn't really wash from a customer care perspective, does it?

J.

________________________________________________________________________

This message is sent in confidence for the addressee only.
It may contain legally privileged information. The contents are not to
be disclosed to anyone other than the addressee. Unauthorised recipients
are requested to preserve this confidentiality and to advise the sender
immediately of any error in transmission.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 18 Apr 2000 12:52:24 -0600 (MDT)

> From: John Martin <[email-masked]>

> ...
> I don't think I'm mistaken - perhaps I wasn't clear. What I mean is that 
> ISPs do this for their own customers only. Isn't that what you are saying 
> AOL does?

I don't think it makes sense to say that hosts of customers of an ISP
are under the administrative control of the ISP.  That idea would have
the hosts of some outfits under the administrative control of their
direct competitors.

> administrative domain, at least that is true for most dialup ISPs. In this 
> case, the customer has a choice to change ISP if they don't like their 
> policies.

Thank you very much, but that I use ISDN does not put my computers in
anyone else's administrative domain.  And neither would the use of DSL,
cable modems, ATM or FR PVC's or SVC's, or old fashioned leased lines.

What does customer choice have to do with anything?  As much as I'm shocked
and horrified by third party redirection proxies, I don't like the idea
of government rules on them.  The topic at hand concerns the technical
problems of redirection proxies, perhaps especially redirection proxies
in administrative domains that differ from the domains of both the client
and the server.

> ...
> I suspect that those techniques will ultimately lead to a deprecation in 
> the use of interception proxies at source (for web traffic). But that is a 
> few years away and we still have the problem of 100 or so Akamai-like 
> companies - how does the user determine the closest / best proxy?

Why not the same way the the best ISP is determined?

Note also that there "closest/best proxy" is not a simple metric.  Is it
fastest, most accurate, least likely to drop TCP connections, or best ad
filtering? 
And never mind about the many ways to define "best ad filtering."
What is best by any of those metrics for the person running an HTTP client
is often not best for the people running the HTTP server.  The many parties
running the wires in between have their own, differing ways to determine
"closest/best"

> I still believe the key is in proxy discovery. Or rather, replica discovery 
> - since the content will be controlled by the content provider, even if is 
> distributed by a third party. This will lead to a brokerage system similar 
> to the peering and transit relationships we have already between ISPs... 
> but what is still missing is how the user gets told where to look. DNS is 
> one answer but may not be the best. E.g. I may not want the fastest / 
> closest but rather the cheapest.

Maybe so, although for both technical and non-technical reasons, I 
have doubts.  but never mind.

> This is what I hope we can start to work on in WREC. But first, we need to 
> get our current documents rock solid, get some wider review (particularly 
> of the known problems) and get them published and discussed widely.

yes.

Vernon Schryver    [email-masked]