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

From: Vernon Schryver <[email-masked]>
Date: Fri, 7 Apr 2000 13:17:10 -0600 (MDT)

> From: [email-masked]

> ...
> > If your skin doesn't crawl at the thought of a third party adding headers
> > to your SMTP messages, you need to take some time out to think about things.
>
> You mean *other* than the required RFC822 Received: headers, and/or the
> RFC2476-approved re-writing?  Gaak if so.

Consider the following:

] From: [email-masked] (Jay Levitt)
] Newsgroups: news.admin.net-abuse.email
] Subject: Re: AOL Spammer online now, now what?
] Date: 30 Mar 2000 05:18:23 GMT
] Message-ID: <[email-masked]>

] ...
] rly-ip* are the new hosts that will catch all port 25 connections from
] *.ipt.aol.com and attempt to filter spam.  They will also add the
] X-Apparently-From: header with the real AOL/CS/whatever screen name. ...

That all sounds fine, if you worry only about reducing spam in the
cheapest way possible.  I think their modifications would be compliant
if they the were done by a host that legitimately answers the IP address
to which the SMTP sender thinks it is connection.  As it stands, how
can these redirectors comply with the postmaster mailbox requirement?
Assuming you figure out what's been done to your SMTP stream, how would
you contact postmaster at the stealthy redirector/filter.

I think it's certifiably crazy to assume that all TCP connections to a
distant port 25 involve SMTP.  Assigned numbers doesn't say you can run
only SMTP on port 25.

It's even crazier to not consider the inevitable next step, stealth SMTP
and HTTP redirector/filters to deal with dirty words or taboo subjects,
and not just sex but politics.

And that's based on the best possible, content-neutral interpretation of
Mr. Levitt's words "filter spam."   I hope AOL would not look for telltale
spam keywords and only do connection rate limiting, if only because I hope
AOL knows that reports of spam would trigger content filters.  I'm even
less confident about other outfits.  

Think about port 25 redirecting used for other kinds of filtering
at certain national borders.

On the other hand, if this doesn't get IPSEC as well as application
layer encryption going, nothing will.

Vernon Schryver    [email-masked]

---

From: Ian King <[email-masked]>
Date: Fri, 7 Apr 2000 17:50:17 -0700

I have a hammer.  

It's been driving nails just fine for twenty years.  It's a first rate
hammer, for which I paid top dollar.  It's a really useful tool.  But when I
try to open beer bottles with it, I end up with glass splinters in my beer.
What gives?  

As has been pointed out many times in many ways, the Internet was not
originally designed as a secure network, nor for many of the other tasks we
now wish it to perform.  Should we have implemented something in another
way?  Moot question, we have what we have.  Should we learn from our
mistakes, and when we can see something that appears to be yet another
mistake (no matter how appealing it is as a "quick fix"), avoid making that
mistake?  

We clever, clever engineers have come up with a number of interesting
"solutions" (workarounds?) for the limitations of the network we have
created.  Some of them are, in the long run, not good ideas, although they
are useful as interim solutions.  Some of them are just too violent to the
rules of the game as they are defined (by us!), and/or establish technical
or process precedents that are too dangerous to be allowed.  

-- Ian King

-----Original Message-----
From: Paul Francis [mailto:[email-masked]]
Sent: Friday, April 07, 2000 12:13 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: recommendation against publication of
draft-cerpa-necp-02.txt

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

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: Pyda Srisuresh <[email-masked]>
Date: Sat, 8 Apr 2000 14:10:40 -0700 (PDT)

--- Keith Moore <[email-masked]> wrote:
> > Sorry.. Your conclusion is based on a wrong premise. 
> 
> The NAT group's draft documents speak for themselves.
> 
My point exactly.

regards,
suresh

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 8 Apr 2000 21:52:43 -0600 (MDT)

Why isn't the technical notion of stealth SMTP proxies intended and
currently used by third parties to "filter" objectionable email at least
as much anathema in the IETF as the technical notion of modifying voice/IP
protocols to someday facilitate "monitoring" of "criminal" voice traffic?

Am I weird in worrying even more about not being able to speak than about
the privacy of my words?

P.S. if you aren't bothered by the notion of third parties imposing what
 they consider "proxies" for your HTTP, SMTP, or other traffic, then the
 draft looks interesting.  As with the wiretapping controversy, the issue
 has nothing to do with the technical quality of the draft.

P.P.S. I don't like spam and have done more than many people to combat it,
  including having built and operated automated filters that rejected (and
  might still be rejecting) 1000's of messages per day from the network
  of a large corporation.  That filtering was not by a stealth proxy or
  by a third party and so was ok by my lights, but I'm beginning to wonder
  if it was such a good precedent.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 10 Apr 2000 12:42:00 -0600 (MDT)

> From: Randy Bush <[email-masked]>

> ...
> > That's an interesting idea.  People might eventually finally start
> > using end2end crpyto not for privacy or authnetication where they
> > really care about either, but for performance and correctness, to
> > defend against the ISP's who find it cheaper to give you the front
> > page of last week's newspaper instead of today's.
>
> and, since we're into exaggeration and hyperbole, i imagine you won't
> complain about paying seven times as much for connectivity.

Most of the exaggeration and hyperbole comes from the caching sales
people.  They'd have you believe that caches never miss, or that
cache filling is free.

The news services I watch have front pages with significant (e.g. editorial
and not just DJI numbers) changes every hour or so.

> all these oh so brilliant folk on the anti-cacheing crusade should be
> sentenced to live in a significantly less privileged country for a year,
> where dialup ppp costs per megabyte of international traffic and an
> engineer's salary is $100-200 per month.  we are spoiled brats.

Cachine won't increase those low salaries.

Many people think we should pay for the bandwidth we use, although not
all favor accounting for each bit.  That one now talks about paying per
MByte instead of Kbit of traffic is a radical change due in part to
using instead of conserving.  Undersea fiber isn't paid for by caching.

The primary waste (and perhaps use) of bandwidth is advertising that
almost no one sees, unless you think single-digit response rates amount
to more than almost no one.  Check the source of the next dozen web
pages you fetch.  Even if you use junk filters, chances are that more
of the bits are advertising than content.  Caching that drivel sounds
good, but its providers are already doing things that merely start with
caching to get it to you faster and cheaper.

Caching and proxying with the cooperation of the content provider
can help the costs of long pipes.  No one has said anything bad
about that kind of caching, when done competently.

"Transparent" caching and proxying without the permission of the content
provider will soon be used for political censorship, if not already, and
likely against your $100/month engineers.  How much "transparent proxy"
hardware and software has already been sold to authoritarian governments?

Yes, it's quixotic to worry about that last.  Everyone who feels
comfortable with the IETF's fine words about wiretapping should stop to
think about reality, and do their part in the real battle by putting
end2end encryption into everything they code, specify, or install.

---

From: Steve Hultquist <[email-masked]>
Date: Fri, 14 Apr 2000 14:35:07 -0400

Keith Moore wrote:
> > .  .  .
> > > > > 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).
> > 
> > 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? 
>
> 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)

I, too, have been watching this conversation from the sidelines, primarily
to see the general opinions of the IETF on this topic. However, as one who
is considering deploying such devices both topologically close to servers
(so-called "Web accelerators") and topologically close to clients of the
servers (as an owner of the servers -- so-called "content distribution"),
this is of vital interest to me. In both cases that we are considering, the
devices are within the same administrative domain as the servers
(effectively administered by the content owner). This is, as a number of
people mentioned, a key differentiator in this discussion. 

For Internet network-based applications such as streaming media and rich
content, both of these technique provide significant advantages for the
administrators of the delivery, hence the intent of NECP is important.

And, as Bill Sommerfeld wrote:
> 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.

I agree that this is important, as well.

Patrik Fältström said
> 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.

With which I also agree.

However, I do not see an appropriate documentation of NECP as incompatible
with those two views.

ssh
--
Steve Hultquist
VP Ops
Accumedia, Boulder, CO USA