Subject: Re: interception proxies

From: Vernon Schryver <[email-masked]>
Date: Tue, 11 Apr 2000 10:12:44 -0600 (MDT)

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

> There has been a lot of discussion about the problems associated with 
> so-called "interception proxies". This discussion is very much within the 
> charter of the WREC WG. In fact, we even have a current draft whose sole 
> purpose is to document such problems.
>
> The known problems draft is at: draft-ietf-wrec-known-prob-01.txt
>
> This is the first of two very useful documents being produced by WREC; the 
> first, a taxonomy of terminology is available as: 
> draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first.

The problems draft is interesting and depressing.  All of the problems
listed are technical nits.  If you assume that "traffic redirection"
and an "interception proxy" are good things, then you might well worry
about the "lack of HTTP/1.1 compliance for proxy caches" or whether
"interception proxies break client cache directives."  You will not
question their desirability or even their long term utility in the face
of actions by users to protect their privacy or defend against censorship.
You won't even worry about what's going to hit the fan when the big
advertisers realize that their wonderful ads are being filtered and
overwritten with other people's ads by interception proxies.

I don't know whether to be depressed, encouraged, or neutral that WREC
seems to not be about port 25 traffic redirection and interception proxies,
such as AOL's effort.  That there is no mention of the problems that IP
fragmentation can cause interception proxies is depressing.

> To join WREC, use the following:
> 	mailto:[email-masked]?Subject=subscribe
>
> ...or send a note to [email-masked] with "subscribe" in the subject.
>
> I suggest we move this particular discussion to WREC.

Joining that mailing list would not be useful, prudent, or honest for
people with sentiments like mine.  Moving the question of the wisdom of
such proxies to WREC would be equivalent to moving the question of the
wisdom of wiretapping to the wiretapping working group.  At best the group
WG consensus can be predicted.  At worst, the discussion would legitimately
be considered disruptive and irrelevant.

It appears that the WREC working group is doing exactly as someone
lamented a day or two ago about working groups in general, and not
considering the question of whether the mechanisms they are working are
good ideas in the larger scheme of things.  WREC is only concerned with
making them as good as possible.  (Yes, I checked recent months of the
archives at ftp://cs.utk.edu/pub/wrec/)

It is interesting, but consistent with that observation that the problems
draft contains no mention of problems should clients use end to end
encryption or even just authentication with message authentication codes
that care about the current time or the particular client.  I don't know
what to think of the absence of the string "https" in all three drafts.
The passing, convoluted reference to encryption and SSL in section 9.2.2
of the taxonomy draft confuses me.  If I were optimistic, I would hope
that the taxonomy document is the wrong location is the reason its privacy
section is so shallow.

Vernon Schryver    [email-masked]

---

From: "Yixin Zhu" <[email-masked]>
Date: Tue, 11 Apr 2000 11:37:07 -0700

Hi ,

I am interested in the Open Settlement Protocol for VoIP. I have check the
web site for GRIC and  TransNexus, and got some information. It will be
appreciated if someone here can point to  me more places to get  info on
this topic.

Thanks,

Yixin (James) Zhu

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Apr 2000 13:55:06 -0400

wrec is supposed to be about *web* replication and caching.
which probably doesn't include email.  so I can hardly
blame them for not talking about port 25.  since other kinds
of interception proxies exist, perhaps they should clarify their 
document slightly to say it's about web interception proxies.

naturally I would encourage folks who are concerned about web
interception proxies to join the wrec group and/or to submit 
comments and corrections about their documents.  

Keith

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Apr 2000 13:03:02 -0700

Vernon Schryver wrote:
> listed are technical nits.  

This was a choice - in some larger sense, if sourcing other-owned IP
addresses or TCP connections is considered an architectural problem,
needs to come down from above, rather than up from WREC. f

> fragmentation can cause interception proxies is depressing.

The problems of IP fragmentation are not unique to web caching or
replication proxies. They affect all interception proxies. The issue of
inteception proxies was around long before WREC, and is more than just a
caching or replication issue. 

> be considered disruptive and irrelevant.

WREC is about proxies - there are plenty of 'architecturally conformant'
ways to do proxies. If the problems with transparent proxies is an
issue, WREC may be a good place (but not the only place) to solicit
input.

> archives at ftp://cs.utk.edu/pub/wrec/)

That's the property of WGs in general, by construction. These questions
sometimes get addressed in BOFs, but there is also often too much
momentum or political interest in establishing a 'standardizing
presence' in an area. By the time a WG is formed, the time for 'whether'
has often passed in favor of 'which'.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Apr 2000 16:55:25 -0700

...
> issue, WREC may be a good place (but not the only place) to solicit

Correction - slip of the keyboard. What I meant was that WREC is _NOT_
about proxies. It's about caching and replication. Proxies are one part
of the architecture, but not the only part.

Joe

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Apr 2000 19:59:45 -0400

> needs to come down from above, rather than up from WREC. 

sounds like a convenient excuse to me...
where did the wrec folks get the idea that the IP specification was obsolete?

Keith

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Apr 2000 17:09:56 -0700

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

Joe

---

From: "Dick St.Peters" <[email-masked]>
Date: Wed, 12 Apr 2000 08:59:25 -0400 (EDT)

> where did the wrec folks get the idea that the IP specification was obsolete?

Quoted from RFC791, the IP specification, in the section on loose
source routing, page 19 [emphasis added]:

   If the address in destination address field has been reached and
   the pointer is not greater than the length, the next address in
   the source route replaces the address in the destination address
   field, and the recorded route address REPLACES THE SOURCE
   ADDRESS just used, and pointer is increased by four.
   
   The recorded route address is the internet module's own internet
   address as known in the environment into which this datagram is
   being forwarded.

An end-to-end-inviolate source address is not a required part of the
IP spec.

The authors of the standard had the vision to foresee that rewriting
the source address might be desireable under some circumstances.  They
were off target about when this might be used, but they designed a
protocol flexible enough to encompass things they could not foresee.

--
Dick St.Peters, [email-masked] 
Gatekeeper, NetHeaven, Saratoga Springs, NY
Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
    Oldest Internet service based in the Adirondack-Albany region

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Apr 2000 09:50:48 -0400

> the source address might be desireable under some circumstances.

the authors of the IP standard provided for loose source routing.
this should not be interpreted as license to impersonate a host
when source routing was not requested by the source.

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 12 Apr 2000 09:41:28 -0500

> An end-to-end-inviolate source address is not a required part of the

If you look upward two paragraphs from the part you quoted, you'll
see that "source address" does not mean the first address in the
fixed part of the IP header, but the address in the "route data"
provided by the source.
______________________________________________________________________________
Matt Crawford                    [email-masked]                     Fermilab
"A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment,
thoroughly smash them with a hammer or an ax, and scatter the pieces."

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 12 Apr 2000 08:30:43 -0700 (PDT)

> protocol flexible enough to encompass things they could not foresee.

I think you have misunderstood what the RFC intended to say.  The "source
address" being replaced is the entry in the LSRR option that is being
written into the destination field, not the source address in the IP
header, which is supposed to remain constant throughout its journey.

Anyway, a source route option was intended to be something that the
originating host puts into the datagram, and so the destination address
rewriting that does happen is being done by explicit request of the
originating host.  That's quite different from what an interception
proxy does, isn't it?

C. M. Heard
[email-masked]

---

From: Salvador Vidal <[email-masked]>
Date: Wed, 12 Apr 2000 18:51:51 +0200

Hello Vernon,

>of actions by users to protect their privacy or defend against censorship.

There are also good uses for interception, I think that ONGs, churchs, and
other organizations and people will want to become Internet trusters soon,
to defend their values throught Internet, and not only values there will be
also fun aplications of trusters.

The point is that the truster must be selected by the user not by
authoritarian impositon!.

i.e. I talk about ecology.

May be the first step of a ecologist truster will be to devolop a black
list of companies that are very agresive agains nature, the people that
join this truster will be able to have censorship of this companies in
order to presure them to change their behavior.

Perhaps later they will think that to get some ecological level is not
enought, that they want to develop a ecological ranking so people can
transmit the market the message that they must compite to be the eco-leader
on their sector if they want these customers, that is to get the strenth of
compititivity aplaied to ecology.

(Companies should heritage values from their supliers, in order to avoid
the trick that a very dirty industrie uses a very clean distribuitor for
their products, so let the end customer to pull all the prodution and
ditribution chain to ecologist positions)

This respect companies privacy if you don´t want an ecological evaluation
Ok you get a cero!.

Whith ranking values people will be able to weight them from different mix
of trusters that they select.

May be, later trusters will incrise their interactivity with their
customers, things like this information is Ok if that happends, or this
information is worthy combenid with this other, I don´t have idea of
trusters future evolution but almost sure that they will be adding more
inteligence and interactivity to their system.

At 10:00 06/04/00 -0300, Marin Montenegro wrote:
>The humanity is really in front of the product of the knowledge of some
>persons and is trying to save your houses of the flood with a small glass.

As world problems are getting more and more complex we don´t need some
iluminated people, with need everybodi feedback in order to see the all
picture, and perhaps trusters will be a good way to organize the knowlege
of the people, perhaps ecological trusters were unable to stop climatic
change, but sure they will be much more usefull than TO BURN GAS-STATIONS!.

As long as doesn´t look viable that trusters send huge updated databases to
users, I think that the information interception has to be done at ISP,
anyway I think that interception must be balence with the information owner
desires, He (I don´t write the slash he/she because is obius) has the right
that his information don´t pass trusters cesorship/filters/inteligent
system or whatever, as well as the user has the right to don´t attend any
information that don´t cross his trusters, of course there are positons in
between i.e. allowing the truster to put labels but not to change the
publicity ...

At 08:15 09/04/00 JST, Masataka Ohta wrote:
> it is impossible to ...

Impossible is just a small delay on Internet, thinking on it Mas.

Salva

---

From: [email-masked]
Date: Wed, 12 Apr 2000 13:08:47 -0400

> order to presure them to change their behavior.

This is unfortunately a Nice Idea, but probably well into the NP-messy category
of things.  The problem is that eliminating a sufficient amount of what the
statisticians call "false positives" will be quite challenging, and probably
involve a large amount of natural-language processing.

Typical scenarios you need to address:

1) If you are censoring company XYZ-Example.Com because of their dumping of
nuclear wastes into the local drinking supply, you need to make sure that your
censorship doesn't accidentally censor the press release they issue stating
that they have stopped doing it, and will pay to clean the drinking supply.

2) If you are censoring company ABC-Example.Com because of their CEO's viewpoint
on <insert touchy social topic here>, you want to be careful not to accidentally
censor a message from their chief networking manager that contains the technical
information that you asked for on a mailing list....

It would be a shame if you failed to get my commentary on your ideas because
you were censoring my employer because of their failure to rename a dormitory
currently named for a famous and illustrious person who has been alledged to
have been a racist at one time...

Remember - I may work for the University, but I'm almost always stating my OWN
opinions unless I specifically flag something as being "The Party Line".

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

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

> where did the wrec folks get the idea that the IP specification was obsolete?

(speaking not for the entire WREC, but my impression of the meetings) I
did get the impression (mistakenly or not) that addressing the whole of
the IP spec was not particularly in scope (e.g., from our area director,
who discussed scope at nearly every meeting).

Joe

---

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

> who discussed scope at nearly every meeting).

I would agree on that point ... but as long as wrec recognizes (correctly)
that revising IP is not within its purview then it also seems reasonable 
for wrec to assume that things that violate IP are of dubious value.

Keith

---

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

Keith,

>where did the wrec folks get the idea that the IP specification was obsolete?

I'm not sure what you are trying to say here but as co-chair of WREC, I can 
tell you that such a concept was never discussed. We stuck pretty rigidly 
to our charter, in fact.

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: Erik Nordmark <[email-masked]>
Date: Fri, 14 Apr 2000 21:19:59 -0700 (PDT)

> 	http://www.isi.edu/touch/pubs/hazards-outline.txt

This doesn't list what I thought was an obvious issue.
If multiple nodes are originating packets with the same source
IP address it will be rather hard for them to ensure the required
uniqueness on the IP ID field (unique for the combination
of source IP, destination IP and protocol).

I suspect that most of boxes that play these games don't worry about
IP ID which might cause garbage reassembly should the same
IP ID be used when multiple such boxes are sending to the same IP address.

  Erik

---

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2000 15:43:43 -0700

> IP ID be used when multiple such boxes are sending to the same IP address.

Good point.

I suspect they ignore the issue because of how they demux to multiple
boxes;
if the demux is by a hash of source IP address, then there's no need for
coordination thereafter.

I'll certainly add that to the list. There's a corrolary at the TCP
level, of port reuse, etc.

Thanks,

Joe