Subject: Re: recommendation against publication of draft-cerpa-necp-02.txt

From: Keith Moore <[email-masked]>
Date: Fri, 7 Apr 2000 04:50:41 -0400 (EDT)

> > I am writing to request that the RFC Editor not publish 
> > draft-cerpa-necp-02.txt as an RFC in its current form,
> > for the following reasons:
>  
> > 2. A primary purpose of the NECP protocol appears to be to 
> > facilitate the operation of so-called interception proxies.  Such 
> > proxies violate the Internet Protocol in several ways: 
>  
> > 3. Aside from the technical implications of intercepting traffic,
> > redirecting it to unintended destinations, or forging traffic from
> > someone else's IP address - there are also legal, social, moral and
> > commercial implications of doing so.
> 
> You will need to be far more specific here.  I see absolutely nothing that
> is not legal, is not social, or is not moral.  

Okay, I'll offer a few specific examples, by no means the only ones:

1. an Internet service provider which deliberately intercepts traffic 
(say, an IP packet) which was intended for one address or service, 
and delivers it to another address or service (say that of an interception 
proxy) may be misrepresenting the service it provides (it's not really
providing IP datagram delivery service because IP doesn't work this way).

2. an internet service provider which deliberately forges IP datagrams
using the source address of a content provider, to make it appear
that the traffic was originated by that content provider
(interception proxies do this), may be misrepresenting that content
provider by implicitly claiming that the service conveyed to the user
by the ISP is the one provided by the content provider.

3. an internet service provider which deliberately alters IP traffic 
in transit, and deliberately makes it appear that the traffic was not 
altered (by recomputing the checksum) may be misrepresenting the 
service it provides (because IP doesn't work that way) and it may
also be violating the traffic orignator's right to make derivative 
works of its copyrighted material.  (in particular an interception 
proxy that modified the content in transit - say to convert one
data format to another - might be held to violate that right because
content conversions almost always degrade the content and thereby
degrade the expression)

now whether any of these is actually illegal would be up to a court
to decide, and different courts in different jurisdictions might rule 
differently (especially depending on the particulars of a test case)
but each of these is similar to behavior that in other communications
domains would be illegal.  and regardless of whether the grounds is
technical, legal, or moral, none of these behaviors seems like 
something that IETF should support.

> I do see commercial
> implications, but whether those are is "good" or "bad" is not a technical
> judgement.

I agree that we are safest when we can rely purely on technical arguments,
and I believe that all of the above practices are in general technically 
unsound.  Still, I don't think there is a definite boundary between 
technical judgement and moral judgement.    Technical judgements are
often based on moral sensibilities.

> > In my opinion IETF should not be lending support to such dubious
> > practices by publishing an RFC which implicitly endorses them, even
> > though the authors are employed by major research institutions and
> > hardware vendors.
> 
> I take the contrary position.  The IETF ought to be encouraging the
> documentation of *all* practices on the net.  It is far better that they
> are documented where people can find useful information when they see this
> kind of packet activity rather than have them known only to a few
> cognescenti.

Actually I share the belief that it is a good thing to document any 
widespread practice, or any idea which is believed to be useful.   
However it's also clear that publication of all such pratices in RFCs
is beyond IETF's meager resources, and would dilute the value of 
the RFC document collection. And the reality is that a protocol
documented in an RFC is often treated as if it were a standard, or 
at least, as if the practice were endorsed by IETF.    When a poor
protocol is apparently endorsed in this way it does harm to IETF's 
reputation and to its work of promoting interoperability.

> May I suggest that one treat this in its classical sense - as a Request
> for Comments and that those who have technical objections or technical
> enhancements publish those comments in an additional document rather than
> try to suppress the original one.

RFCs have not been treated in this sense for many years.  And while
such treatment may have made sense in the early days of the ARPAnet
with a community of a few hundred users, it does not make sense in 
an Internet with tens of millions of users.

The reality is that today, many documents submitted for RFCs are rejected.
I'm simply arguing that this document should be added to that set.
or at least, that it needs substantial revision before it is found 
acceptable.

> Having a document trail that shows what paths and ideas have been found
> wanting is nearly as important has having a trail that show what paths
> have been found useful.

agreed, but that doesn't mean that it's IETF's or the RFC Editor's job 
to organize and maintain the definitive collection of such documents.

Keith

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Apr 2000 11:00:02 -0400

Keith,

Without comments on other aspects of the technology in question, I 
would like to make some observations about the security aspects of 
the processing you cite as violating IP.

By now we all should know that it is a bad idea to rely on an 
unauthenticated IP address as a basis for determining the source of a 
packet. Similarly. the IP header checksum offers no security.  We 
have a variety of IETF standard protocols (e.g., IPsec and TLS) that 
provide suitable assurance for data origin authentication and 
integrity for application data sent via IP.  Thus, if anyone is 
really concerned about know with whom they are communicating, and 
whether a packet was modified in transit, they should be using these 
standards security technologies.  Many web sites for which these 
security concerns are significant already make use of SSL/TLS anyway.

Steve

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 07 Apr 2000 11:54:50 -0400

Howdy,

Stephen Kent wrote:
> Thus, if anyone is

I think the point was that this will impact many more casual 
interactions, where one wouldn't necessarily think to have to employ
authentication technologies.  

There are times when I and my ISP, or the ISPs it peers with, have 
different opinions about what is sufficiently recent/authentic
(of a copy of a resource, or even of a final destination address).
If unrelated entities in the chain each get to "assert an opinion"
about what's "good enough", for their own purposes, it is not at
all clear that I get the end-result that I deserve, or am even aware
of the fact that things have been changed midstream.

Leslie.

-- 

-------------------------------------------------------------------
"My body obeys Aristotelian laws of physics."
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Apr 2000 12:39:35 -0400

> security concerns are significant already make use of SSL/TLS anyway.

While I naturally agree that one should not use unauthenticated
IP addresses to determine the source of a packet, I think it's a 
big stretch to say that the existence of IPsec and TLS means that 
it's okay for third parties to forge source addresses.

and for different reasons, both IPsec and TLS are of fairly limited 
applicability for application-level security - we are still missing
lots of pieces.

Keith

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Apr 2000 13:04:15 -0400

Keith,

Applications can gain a lot of security by building on top of a lower 
layer secure communication substrate, such as that provided by IPsec 
or TLS.  Such substrates allow the application developer to make 
assumptions about the security of the basic communication path, and 
have these assumptions be valid.  Precisely the sorts of things you 
are citing as "bad" can be addressed in this way.  Fancier 
application security requires some level of customization, perhaps in 
an application-specific fashion, as you noted.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Apr 2000 13:07:29 -0400

Leslie,

I understand your point, but we leave ourselves open to many forms of 
attacks, or errors, by assuming that "what you receive is what was 
sent" in this era of the Internet.  Security is not black and white, 
but the gray area we're discussing does bother me.  If one cares 
about knowing where the data originated, and that it has not been 
altered, then one needs to make use of the tools provided to address 
that concern.  if one doesn't use the tools, then one does not care 
very much, and the results may be surprising :-).

Steve

---

From: [email-masked]
Date: Fri, 07 Apr 2000 13:43:15 -0400

> very much, and the results may be surprising :-).

The sad part is that in this day and age, we had to publish the SANS
DDOS Roadmap, which suggested that things would be a lot better if sites
installed the patches and did ingress/egress filtering.

I suspect that there is a *very large* portion of the Internet community that
does "care very much" (or at least enough to worry a little bit), but is
too new/clueless/whatever to properly find/install/configure the tools.

I encounter a lot of sites that install spam filters and firewalls because
they ARE concerned about spam, hackers, etc.  Unfortunately, a lot of them
Get It Very Wrong, and do stuff like bounce SMTP 'MAIL FROM:<>', or Do The
Wrong Thing with NTP traffic, etc etc.

I have to conclude that there's a lot of sites that *do* care very much, but
are lacking the technical expertise to use the tools.

Remember: There's 4 million .coms.  There's not 4 million experienced sysadmins.

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 07 Apr 2000 13:44:08 -0400

A fine argument in the abstract, but reality bites. 

> very much, and the results may be surprising :-).

Who is "one", in your mind?  Mail, web, WAP client application
writers?  Or the poor end-user who gets the surprise without having
a clue what hit him?

As an end-user, I can be as aware as I like about the security issues,
but if client software doesn't support security, and/or my ISP, services
don't support it, there's nothing I can do.  

I am not saying that security isn't the answer -- but I do think you're
looking at your chalkboard, not deployed reality, when you suggest
it isn't a problem because there are technologies for authenticating
packets.

Leslie.

-- 

Leslie Daigle
[email-masked]

---

From: Peter Deutsch <[email-masked]>
Date: Fri, 07 Apr 2000 10:42:15 -0700

Keith Moore wrote:
.  .  .
> providing IP datagram delivery service because IP doesn't work this way).

Okay, I think I see the mistake you're making. You're crossing
abstraction layers and conflating two different things (the name of
a service with the end point of the connection to that service). You
are criticizing the moving of an endpoint when what you really
object to is the misrepresentation of a service. Or do you also
object to HTTP redirects, dynamic URL rewriting, CNAMEs, telephone
Call Forwarding, or post office redirecting of mail after you move? 

A while ago Fedex tried an advertizing campaign in which they
explained to people that when you send a packet from New York to
Chicago, the package is actually routed down to Tennessee (or where
ever it is) and then sent back up to the destination. They wanted
people to see how clever they were, in sending all their packets on
this round-about trip, thus getting it there *much* faster. 

The campaign apparently confused people, and made them nervous, so
they dropped it, but the point is still valid. If what you want is a
particular service (fast information delivery), don't confuse that
with the lower lever transport layer issues (packet delivery). It
may well be desireable to reroute things to get improved service at
a higher abstraction layer. I see nothing "illegal" about Fedex
sending my packet to Tennessee and I see nothing immoral about
Earthlink, MCI, Cisco and CNN all getting together to route my
packets to whichever one of Akami's caches is the most appropriate
one for me to go to today. After all, I didn't ask CNN to send me
packets, I asked CNN for today's news.

Now, misrepresenting myself as someone else may well be fraud, a
well defined crime, so someone else offering me news and pretending
it's from CNN is wrong, but that's nothing to do with IP packet
delivery. You're thinking at the wrong abstraction layer. Changing
IP addresses may *result* in fraud, depending upon why you do it,
but it doesn't constitute fraud in and of itself ("routers don't
mislead people, people mislead people..." ;-) 

Bottom line is, you seem pretty confused here. Sadly, you take this
in really strange directions (see below).

> by the ISP is the one provided by the content provider.

Keith, this is a legal issue. We don't do legal issues here. If
someone is misrepresenting themselves, and causing harm, there are
very clearly defined legal mechanisms to address that. This is *so*
far outside the purvue of the IETF that I can't figure out what
you're even trying to accomplish. Out of curiosity, do you even have
any legal training??

.  .  .
> something that IETF should support.

So because someone can pick up a router and beat someone to death
with it, we shouldn't build routers? Or do you honestly think it
appropriate that we add a "legal" section to RFCs?

.  .  .
> or at least, that it needs substantial revision before it is found

So you are arguing for explicit censorship of ideas based upon your
own moral assessment of the potential misuse of those ideas? Wow.
Now *that* is a dangerous notion indeed. I sincerely hope it is not
a widely held one within the echelons of the IETF...

				- peterd

-- 
----------------------------------------------------------------------
Peter Deutsch                     work email:  [email-masked]
Technical Leader
Content Services Business Unit       private: 
[email-masked]
Cisco Systems                           or  :  [email-masked]

         Alcohol and calculus don't mix. Never drink and derive.
----------------------------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Apr 2000 14:27:57 -0400

In my 20+ years of security experience in the Internet community, it 
has often been the arguments for the need to make do with existing 
features or to adopt quick fix solutions that have retarded the 
deployment of better security technology.  In retrospect, this 
approach has not served us well.

Steve

---

From: Dennis Glatting <[email-masked]>
Date: Fri, 07 Apr 2000 11:25:40 -0700

Leslie Daigle wrote:

> don't support it, there's nothing I can do.

Huh? You have a choice: (a) obtain a client that does support
security; and (b) get a new ISP. Both are plentiful.

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Apr 2000 14:35:36 -0400

> an application-specific fashion, as you noted.

I beg to differ.  Few applications can use IPsec or TLS authentication 
as-is.   A few more can get away with using username/password schemes
on top of IPsec or TLS privacy.  But neither IPsec nor TLS is anything
resembling a generally applicable authentication solution.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Apr 2000 14:36:52 -0400

Stephen,

perhaps the reason that the tools are not used is that they are not
adequate for the task.  but it certainly does not follow that "if 
one doesn't use the tools, then one does not care very much".

Keith

> If one cares

---

From: [email-masked]
Date: Fri, 07 Apr 2000 14:56:34 -0400

> security; and (b) get a new ISP. Both are plentiful.

Only if a client supporting security is available for your software
(which might be be something other than Netscape/IE - the Web and the
Internet are not the same thing.  There are platforms that (for instance)
have a telnet client, but no ssh client.

Only if a client supporting security is available in your country.  Some
countries still have issues regarding cryptography.

Only if a new ISP is available in *your area*.  In many parts of the country,
if you require ISDN, DSL, cable modem, or anything else that's faster than
a 56K-over-POTS, your choices are severely limited, and may in fact be zero
for some technologies.

---

From: Daniel Senie <[email-masked]>
Date: Fri, 07 Apr 2000 15:00:22 -0400

> security; and (b) get a new ISP. Both are plentiful.

Ah, no. In the real world of the Internet today, we have LOTS of folks
who get their Internet connectivity via cable modems and DSL. Many
vendors of such services, in order to help preserve IP address space,
give out only a single IP address to each customer. Since this is
incompatible with the way people use the Internet in many cases (e.g.
MANY homes have more than one computer), Network Address Translation is
used.

NAT is the reality of the Internet today. IPSec was developed for an
Internet that existed some years back, before address allocation
policies forced NAT to become commonplace. We now are in need of
security solutions which can survive such an environment. SSL is one
such example.

NAT presents a lot of problems to the Internet architecture. It's ugly
architecturally. We all know that. We can't make it go away by
complaining about it. We could fix IPSec to survive in the current
environment, or find ways to get more people interested in IPv6, do
both, or find alternate forms of security.

Getting a new ISP, however, is NOT necessarily an option. You'd argue I
give up a cable modem for a dialup ISP? I don't think so. Application
level security (SSL, TLS, SSH) work fine for my needs and transit the
equipment I must use to exist on a cable modem.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.                    http://www.amaranth.com

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Apr 2000 14:59:31 -0400

Keith,

>one doesn't use the tools, then one does not care very much".

or perhaps, one does not care enough ...

Steve

---

From: Paul Francis <[email-masked]>
Date: Fri, 7 Apr 2000 12:12:30 -0700 (PDT)

>  approach has not served us well.

I have a time machine.

I just went back 20 years in time, convinced everybody that it
was always more important to implement proper security than to
make do with existing features and quick fix solutions.  Having
thus changed the future, I went back forward in time.
Guess what---there was no internet!

PF

---

From: Dennis Glatting <[email-masked]>
Date: Fri, 07 Apr 2000 12:15:51 -0700

> equipment I must use to exist on a cable modem.

You have made the choice to have no choice but you do have a choice.

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Apr 2000 15:15:57 -0400

> Call Forwarding, or post office redirecting of mail after you move? 

I don't object to redirects at all, as long as they are carefully 
designed.   I do object to misrepresenting the service.    As I've 
said elsewhere, if the service wants to set up an interception proxy 
on its own network to help make its service more scalable, I have 
no problem with that.  I do have a problem with unauthorized third 
parties setting up interception proxies.  (which is according to
my understanding all the most common application of such devices)

> It may well be desireable to reroute things to get improved service at
> a higher abstraction layer. 

the problem is that one person's idea of improved service may be
another person's idea of degraded service.  getting stale data
to me faster may not be much help.  I would argue that it
is up to the producer and consumer, not the ISP, to decide what
level of service is appropriate.

> I see nothing "illegal" about Fedex

If CNN is okay with this, I have no problem with it.  They get to
decide what content delivery mechanisms are appropriate for their
content.  Other content providers might make different decisions.
Where I have a problem is when J. Random ISP unilaterally decides 
that some content delivery mechanism other than standard IP routing
is appropriate for CNN's data (or my data).  

And on some level, yes, you did ask CNN to send you packets.  Or you
sent packets to CNN and the network sent you some packets back purporting
to be from CNN.  You and your web client presumably knew what you were
asking for, and CNN's web server (if it was even in the loop) presumably
knew what kind of response to give.  But the network in the middle does
not know for sure how to interpret your request and CNN's response.
Just because you are sending port 80 does not even mean that you are 
using HTTP, and it certanily doesn't mean that you're using the same
version of HTTP that the interception proxy just happens to support,
and it certainly doesn't mean that you're willing to tolerate whatever
data corruption the interception proxy (whether by design or by accident)
happens to introduce.

> mislead people, people mislead people..." ;-) 

You seem to be saying that because we have a higher service layered 
on top of IP that we can disregard the IP service model.  I disagree.
There are two separate problems here:

1. An interception proxy, unless it is acting with authorization 
of the content provider, is misrepresenting itself as the content 
provider.  IP address spoofing as just one particular mechanism 
by which this can be done, but regardless of the mechanism, it's 
wrong to misrepresent yourself as someone else.

2. At a different level, IP networks that don't behave like IP 
networks are supposed to behave violate the assumptions on which 
higher level protocols are based.  This degrades interoperability
and increases the complexity of higher level protocols as they
try to work around the damage done when clean layering is destroyed.
(for example of increased complexity consider the suggestions to
solve the problem by having everyone use IPsec or TLS)

(as a friend of mine said many years ago, the problem with intelligent
networks is that the network has to be smarter than the applications.)

now it happens that both of these problems are caused by interception
proxies, which is why I choose to mention both of them in the same
discussion.
 
> Bottom line is, you seem pretty confused here. 

only if you think that discussing several related topics in a single
mail message is a sign of confusion.

> Keith, this is a legal issue. We don't do legal issues here. 

that's BS.  IETF has every reason to be concerned about publishing
documents that promote illegal or clearly immoral behavior.  While it 
is true that it is not for us to judge fine points of law, it's also 
true that promoting illegal or clearly immoral behavior reflects poorly 
on IETF as an institution and would impair IETF's ability to do its work.
It is not useful to direct IETF's energies in these directions.

The alternative  - to pretend that there are no social implications
to what we are doing in IETF - strikes me as dangerous and irresponsible.

> with it, we shouldn't build routers? 

no, if someone designed a router whose primary purpose were to beat
someone to death, we shouldn't endorse such a product.

> a widely held one within the echelons of the IETF...

Your use of the word "censorship" is incorrect.  I'm not arguing that 
IETF should try to prevent anybody from publishing their own ideas 
in any forum willing to support them.  Instead I'm arguing that IETF 
and the RFC Editor should not serve as that forum.  I belive that to 
do so would do harm to and the Internet and that IETF's and the RFC 
Editor's meager resources are better spent on more socially useful endeavors.

And absolutely I am making an argument based on my own assessment of 
both the morality of the practice and the technical issues associated
with that practice.  Why should it be dangerous or wrong to argue for 
what one believes is right?

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 07 Apr 2000 15:21:00 -0400

> or perhaps, one does not care enough ...

or perhaps, that building tools that actually solve these problems
as opposed to chipping away at the edges is (a) fundamentally difficult
(b) requires many kinds of expertise, most of them scarce, (c) has 
been frustrated by governments and patent holders who were bent 
on trying to control things, and (d) has not kept pace with the
development of the 'net.

Keith

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Apr 2000 15:21:24 -0400

Paul,

>Guess what---there was no internet!

You need a better time machine, or you need to stop complaining. 
either will work for me.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Apr 2000 15:38:34 -0400

Keith,
>on trying to control things, and (d) has not kept pace with the

OK, I'll call it quits now, before we begin to explore who has 
contributed to addressing these problems in any visible fashion, and 
what the relative levels of security expertise are among the folks 
sending these messages.

Steve

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Fri, 7 Apr 2000 16:21:22 -0400

Date: Fri, 07 Apr 2000 15:00:22 -0400
   From: Daniel Senie <[email-masked]>

Actually, there are other solutions to this problem --- in fact, one in
which IPSEC plays a starring role.  I've been hearing more and more
people who are using IPSEC to tunnel from their cable modem to some site
which has (a) plenty of addresses, and (b) is well connected to the
internet.  They can thus get a /28, /27, or sometimes even a /24 block
of addresses, even though their cable modem or DSL provider either won't
provide that service, or would force the customer to pay through the
nose for the block of the addresses.  One advantage of using IPSEC to
solve this problem is that the ISP can't peer inside the packets to
figure out this is what's going on, so won't know that the customer is
using mutliple computers through what they thought was the single
computer rate.

The downside is that your packets may take a longer than normal routing
to get to their destination, but that's happening already even without
this hack.  For example, until I changed my DSL provider out of sheer
disgust and appallingly bad service, my packets from my home in Medford,
Massachusetts, to MIT in Cambridge, Massachusetts were going by way of
Washington, D.C. and MAE-East.

							- Ted

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Fri, 7 Apr 2000 17:07:23 -0400

From: Keith Moore <[email-masked]>
   Date: Fri, 07 Apr 2000 15:15:57 -0400

Speaking of which, in Adelaide, at the IETF terminal room, there were
http "transparent" proxies running.  It turns out that if you bypassed
them, you got faster service than if you used the transparent proxy
servers provided expressly for the IETF terminal room.

I'm told it saved 15% of the overall bandwidth consumed by the IETF, and
given the limited bandwidth in and out of Australia, I'm somewhat
sympathetic to why it was installed.  However, it's still much more
polite ask people to use a proxy server than to just try to sneak in a
"transparent" proxy.

If they had asked nicely, I might have decided to use it.  As it was, I
was annoyed enough to simply bypass the proxy server, and gain for
myself faster web access.

						- Ted

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 07 Apr 2000 15:20:56 -0400

The objections I've seen so far to this draft specifically cite
problems from systems such as "transparent web proxies" (which are, in
my experience, usually far from transparent) in the network which
intercept all traffic, regardless of destination address, sent to
specific well-known ports.

A quick read through draft-cerpa-necp-02.txt suggests that it's
primarily targeted at forms of redirection which occur at the request
of service operators.  Such systems are best thought of as a funny
kind of application-layer proxy, and are far less damaging to the
end-to-end internet model than the transparent proxies cited above.

I think it's important to carefully distinguish between these sorts of
redirection.  Some clarifying text in the draft to this effect would
be helpful.

					- Bill

---

From: Peter Deutsch <[email-masked]>
Date: Fri, 07 Apr 2000 17:41:30 -0700

Keith Moore wrote:
.  .  .
> on top of IP that we can disregard the IP service model.  I disagree.

No, I'm saying you purported to be offended by IP address
redirection when what you really objected to was unauthorized
spoofing of services and the delivery of something other than what
the user and/or information provider would have expected. That in
turn resulted in your calling for a ban on publication of a
technical document describing a technique which you admit has quite
legitimate applications (e.g. when CNN knows that such IP
interception is going on) because it *could* be used in a manner you
judge to be immoral (i.e. in a case when neither client nor server
knew).

> wrong to misrepresent yourself as someone else.

So write an RFC Draft and call it "IP Address Spoofing Considered
Harmful". Argue eloquently. Convince everyone and you will be famous
to generations of students to come as the person who saved us from
this pernicious practice, right up there with Djkstra and GOTOs.
Fight ideas with ideas. But banning mention of the technique because
it can be misused? Puuleeze.

> solve the problem by having everyone use IPsec or TLS)

You know, I've been pretty uncomfortable over the past few years at
what I perceive as a growing hostility in some quarters towards
innovation in the name of purity and stability. I agree the Internet
is "important", and we must consider the consequences of our
actions, but personally I think you've gone way over a line here...

> proxies, which is why I choose to mention both of them in the same

Actually, you mistyped "both problems are caused by the *misuse* of
interception proxies". And you advocate that the IETF prevent
discussion of the very technique because it can be misused. The bad
guys have proved pretty adept at misusing whatever technologies we
create, but the fact that search engines *can* be misused to leak
information wouldn't have been a reason to ban discussion of Archie
10 years ago, and the fact that the Web can carry porn wasn't a
reason to ban the publishing of an RFC on HTTP five years ago. The
final line of the argument is left as an exercise for the reader...

We need to build publishing and distribution services that can scale
to millions, if not billions, of users, and we need them now.
Address interception is a perfectly legitimate technique in our
arsenal of ideas for this task, with some dangers. So document the
dangers, but if you seek to ban the ideas themselves, I will tap my
head, stick out my tongue and speak in a terrible French accent in
your general direction.

> mail message is a sign of confusion.

Sorry, you're not convincing me you understand my point. You
acknowledge that it's okay to intercept if CNN knows you're doing
it. So why don't we document how to do that? Oh, you say - that's
because the idea can be misused. "Let these dangerous kooks publish
their innovations elsewhere, so we don't sully the IETF brand".
Fine, if we do that, I guarantee that new ideas will simply migrate
out of this forum. Be careful what you ask for, as you're liable to
get it...

> It is not useful to direct IETF's energies in these directions.

If we're going to be foul-mouthed about it, then to quote Saturday
Night Live - 
"Jane, you ignorant slut".

Publishing of a technical document is not promoting "illegal or
clearly immoral behaviour", any more than publishing instructions on
driving a car is promoting carjacking. *That's* the conflation of
ideas I charged you with, not simply carrying two ideas in a single
posting.

> someone to death, we shouldn't endorse such a product.

Okay, I'll see your moral indignation and raise you a moral outrage.
Since when is the publishing of technical information for the
education of the IETF community endorsement of anything other than
the free exchange of ideas? Frankly *I'm* morally offended at that
notion as I think it strikes at the very heart of the IETF and what
made it a successfully organization worthy of my support. If this
were to become the way this organization actually does work in the
future, I would predict its speedy demise as a useful place for the
free interchange of ideas.
 
.  .  .
> and the RFC Editor should not serve as that forum.

Fortunately, I don't think your view really reflects the spirit of
the majority, but I will say again I find it dangerous and offensive
in the extreme. You are advocating that the IETF censor ideas, for
what you claim are the best of reasons. Frankly, I think you value
the IETF brand too much, and the free exchange of ideas too little.

.  .  .
> what one believes is right?

Because nobody died and made you king and TWIAVBP. I'm offended at
the notion that a former Area Director of the IETF would advocate
censoring what others can publish in the Internet's premier
technical exchange forum based not on the quality of the technical
information, but on how that information may be misused. Heck, I'm
also offended that you've dropped the 'the" in front of the term
"the IETF", as it always makes me think of the old "Royal We" that
the Queen of England allegedly uses and I don't want to be thinking
of the Queen of England every time I read one of your postings. Why
can't I demand the IETF forbid any mail posted from you without the
leading "the"?

Okay, it's Friday and I'm being silly, but the underlying concept
here is most definitely censorship of ideas in a most pernicious
form. It's the censorship of ideas based upon how those ideas may be
misused. That always the first step justification used by those who
would protect us from ourselves. Shame on you...

					- peterd

---

From: Keith Moore <[email-masked]>
Date: Sat, 08 Apr 2000 00:29:46 -0400

> the user and/or information provider would have expected. 

Actually I have objections to both - though the objections
to the former are purely technical and mostly in response
to folks who claim that such redirection is deserving of
standardization, or in general is anything more than a crude
short-term hack.  The objections to the latter are both moral
and technical.

> That in

I did not call for a ban on publication of any document.  I suggested
that the RFC Editor consider not devoting its energies to publishing
the document - and I only suggested this after I suggested several
things that could be done to "fix" the document.  Clearly the document 
can be published by other means, nor would I try to prevent such publication.

What you may not realize is that fixing the bugs in documents such
as this one - which at best are on the margin of IETF's mission -
tends to consume inordinate amounts of effort on the part of IESG 
and/or the RFC Editor, who already have lots of work on their plates.  
Their effort, I believe, is better spent on getting more deserving
documents out the door.  

(Such waste of resources is especially annoying when the motivation for 
having the document published appears to be lend IETF's imprimatur 
to an approach by having it published as an RFC - and therefore, 
can be cited as if it were a standard - language in the RFC preamble
to the contrary notwithstanding.)  

> it can be misused? Puuleeze.

again, you're using "ban" incorrectly.

> actions, but personally I think you've gone way over a line here...

I do take a hostile attitude toward so-called innovations which impair
the flexibility and reliability of the Internet and Internet applications,
and I make no apology for it.

> interception proxies". 

tell that to the marketing departments of companaies who are selling
interception proxies to ISPs and as local web caches.  such applications 
of interception proxies *do* cause harm, and yet most of the companies
selling such products would claim that these are legitimate uses.

> And you advocate that the IETF prevent
> discussion of the very technique because it can be misused. 

nope, not prevent discussion - clearly we are discussing it here -
I'm advocating that IETF not spend resources publishing a biased
description of this technique.

> arsenal of ideas for this task, with some dangers. 

I will agree that legitimate uses of the technique exist, but given 
the widespred misuse of this technique (there seems to be a great
deal more misuse than appropriate use) "perfectly legitimate" 
seems like an oversimplificatiaon.

> it. 

not quite. I said "if it's okay with CNN".  Knowledge != explicit consent.

> So why don't we document how to do that? Oh, you say - that's

sometimes it's useful if new ideas migrate elsewhere. in certain
circles this is known as the Golgafrinchian Ark B principle.

> driving a car is promoting carjacking. 

I would argue that publication of this document, regardless of the 
*intent* in doing so, is likely to have the *effect* of promoting 
illegal and/or immoral behavior.  If the decision is made to publish 
the document in some form, the question becomes one of how to minimize 
this negative effect.

> the free exchange of ideas? 

and those who cite such documents as if they were standards, in order
to mislead their customers - they're also contributing to the free 
exchange of ideas?  

it mystifies me how it's quite legitimate to promote dubious and clearly
harmful technical practices (this is defended as the free exchange of 
ideas) but to suggest that such publication is likely to cause harm and 
to consume precious energies which are better spent elsewhere is not 
part of the free exchange of ideas - it is branded as censorship.
I suppose calling it censorship is also part of the free exhcnage of
ideas, but it's not exactly persuasive.

> Frankly *I'm* morally offended at that

Get over it.  The RFC has been exercising editorial discretion - or if 
you prefer - rejecting ideas for RFCs, for many years now.  

> information, but on how that information may be misused. 

as far as I can tell, you think that my having served on the IESG 
means that I have given up the right to speak out against dangerous 
and harmful practices and against poor uses of the IESG's and RFC
Editor's energies.  

IMHO, that's not merely naive, that's delusional.

Keith

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 8 Apr 2000 08:58:00 +0930

>redirection.  Some clarifying text in the draft to this effect would

That is what I have asked the authors to do.

The problems with "intercepting proxies" are that:

(1) It breaks the model we use for IP transport. I.e. an IP package 
with a specific destination address doesn't reach that destination. 
As Christian says,that means among other things that IPSEC will not 
work.

(2) On application layer (as Peter Deutch talks about) the user 
through the browser want to contact the service according to a 
specific URL given. I.e. the user asks to communicate with that 
service. That is not what is happening -- and this with neither 
client nor server knowing about it or being informed.

As Ted said, if it is the case that an ISP or whatever wants to have 
a web-proxy or proxy/cacheing mechanism for some reasons, then that 
have to be communicated to the users so they understand why it is 
better for them (faster, cheaper, whatever) to use that proxy instead 
of talking with services directly.

I have no problem whatsoever to have proxies being part of the 
web-model, but I am strongly opposing someone in the middle of the 
communication path intercepting and redirecting IP-packages, as the 
client will not communicate with whoever he wanted.

     Patrik