From: jrochkin@cs.oberlin.edu (Jonathan Rochkind)
Date: Wed, 1 Feb 95 18:19:09 PST
To: cypherpunks@toad.com
Subject: Frothing remailers, the advertising and pinging problems
Message-ID: <ab55e6d7010210043e93@[132.162.201.201]>
MIME-Version: 1.0
Content-Type: text/plain


At 5:50 PM 02/01/95, kevin@elvis.wicat.com wrote:
>I am not happy with my proposed advertising methods, and was quietly
>hoping for some guidance from internet gurus in this point (the irc
>suggestion in particular is a pretty shaky straw man). However, see my
>earlier message (on some other thread) about Usenet propagation times.
>Propagation times in days do not seem to be rare (post to misc.test and
>see when the last reply comes back). While this is better than
>word-of-mouth propagation, it does not offer the very low latency I was
>looking for.

I tried to discuss this very issue a few months ago, with little interest.
But I'm glad there's someone to discuss it with now. (read, someone who
will listen when I spout volumes to the list :)   )

Here follows my treatise. :)


We already have a solution, actually.  Raph's remailer list.  If you know
your remailer is going down, tell Raph about it, and he'll remove you from
the list.  [Better would be an automatic way of removing remailers from the
list upon receiving a PGP-signed message from the op, without Raph's
intervention].  Presumably, if your remailer never returns his ping, it
will move to the bottom of his list.  So applications like his "premail",
which use this list, won't send to those remailers.

This is really an excellent solution, and what it doesn't do, could easily
be added to it.  The problem is that it's too centralized. We like
decentralized things hereabouts, and Raph's list requires you to trust Raph
not to lie to you, or withhold information to you. And of course a
centralized solution is more subject to attack too; if someone mangaged to
subvert Raph's list (either by subverting his data collection methods, or
the report he generates), then an increasingly large portion of the
remailer-using-public is up shit creek.   Single point of failure.

A partial solution is for lots of people to run remailer pinging and
reporting services like Raph's.  Then you could use which ever one you
want, or even write a script to get info from them all and average em
together (throwing out extremely oddball scores, using some sort of
statistical method).  A better solution to the centralization problem would
be for _everyone_ to run their own remailer pinging service.  This solves
the centralization problem, but now when a remailer op knows his remailer
is going down, he can't simply tell Raph, he's got to tell _everyone_,
which is the same problem he had originally.  Also, this is somewhat
realistic.  People have been saying for ages that the remailer net is much
more secure when every user runs their own remailer, but it still hasn't
happened. For obvious reasons.

So we've still got the problem of how users are to tell when remailers go
down.  That's what I see as the basic problem here.   It really divides
into two problems: the "advertising" problem, and the "pinging" problem.
Which actually aren't at all completely seperate.

*THE ADVERTISING PROBLEM*

The advertising problem consists of how remailers are to get info out to
the Remailer-Net-At-Large.  I run a remailer, and I know my remailer is
going out of business soon (temporarily, or permanently), and I want to
tell people.  Or, my remailer has returned (or just started started
business for the first time), and I want to tell people.

        ++Usenet. Non-IP, but slow. ++
Usenet is an obvious solution, but the latency is too low.   But usenet
does work really nicely, aside from the latency problem. Remailers post
messages to alt.remailer.auto-announce, giving one of a number of
standardized machine-readable messages.  For instance FriendlyRemailer
might post that it's going down, and expects to be down for about 24 hours.
Clients, which could be other remailers, or chaining applications like
premail, would periodically check this newsgroup and keep track of info.
My client software might decide to stop routing through FriendlyRemailer,
and completely ignore the "for 24 hours" thing, and start sending through
there again when it gets an "I'm back" message over the usenet.  Or it
might decide to record the "for 24 hours" thing somewhere for human
reading.  If a new remailer appears and broadcasts "I'm here", it might add
it to the list of useable remailers, or it might ignore it, or it might ask
for human approval of adding it to the list. Whatever the user wants it to
do.

        ++Direct TCP.  IP-required, complicated, but fast.++
But there's still a latency problem.  The only way I can think of to solve
that is with direct TCP connections of some kind.  IRC would be one way.
Remailers could broadcast "I'm here" every 20 seconds on an IRC channel,
and clients could keep an eye on this IRC channel to see what's up.  Of
course, then a client would need to wait up to 20 seconds before sending a
piece of mail, which is kind of a pain. So, instead, you might have a
background program running always, and tabulating data, so it's got data
stored and doesn't need to wait at all. (If the remailer said "I'm here" a
minute ago, that's good enough, dont' need to wait another minute for the
next "I'm here").  And then remailers wouldn't need to broadcast as often
as 20 seconds; something like 5 minutes would probably do.  So bandwith is
more reasonable.  If a remailer goes down, and you send a message to it
within 5 minutes, you are shit out of luck, unfortuantely.   The problem
with this solution is that everyone using it needs to be on the internet.
People haven't wanted to exclude UUCP connections and such from
participating in the remailernet (as remailer or client) in the past, and I
think they're probably right.  And IRC might not be that reliable, I don't
know.  And it requires a lot of proccessing power; remailers have got to be
constantly sending out "I'm here", client programs have to be constantly
running and scanning for this info.  Might not be that scalable either,
when you have 100 remailers broadcasting, and 20,000 users listening. Or
more.

*THE PINGING PROBLEM*

The pinging problem consists of how clients (which could be other
remailers) can querry remailers about whether they are up or not. (and what
features the particular remailers support, which is also something that
might be advertised above, incidentally.)  The user is taking the
initiative, as opposed to the remailer.  Because maybe someone subverted
your usenet or IRC or other broadcasting medium, so you don't want to place
too much trust on it, and you want to check it yourself.   And maybe the
"advertising" medium is slow usenet, so you the last "I'm here" you got
from a remailer was a dated day ago. Is it still there? You'd like a quick
way of pinging it to see.

Again, we have two solutions: Slower simpler, being-on-the-net unneccesary,
pinging with mail; and Faster, More Complicated, need-to-be-on-the-net TCP.


        ++Mail ping. Non-IP, simple, slow. ++
 A mail ping simply consists of sending a message to a remailer with a
Request-Resending-To: yourself.  When you get it back, you know the
remailer is alive.  This has the advantage that it's hard for the remailer
to trick you, even if it is an evil NSA remailer that wants you to believe
it is alive, even though it really throws messages in the trash.   It can't
differentuate between your "ping" (to be returned), and a normal message
(to be thrown in the trash).  And you can do it with a UUCP connection, or
some other kind of store-and-forward non-IP connection.  The problem is
that it's slow.  Especially with the latency that secure remailers have to
put into the mix.  This could be solved if you could tell the remailer
somehow that this is a ping message which should be sent relatively quickly
and not re-ordered and latency-added like a normal message. Of course, then
you lose the advantage that the remailer can't tell the difference between
a ping and a normal message.

The way to deal with the high latency, would again be to have each client
have a background process running and pinging periodically, and storing
data.  Again, if it's gone down since your last ping, you are out of luck.
And this is kind of complicated, and high-bandwith.

        ++TCP transaction ping. IP required, complicated, but fast.++
Again, the other alternative is a direct TCP connection. Connect to a
certain port, say "are you there", get an answer.  I believe mixmaster will
soon support direct TCP traffic transactions, it would probably be trivial
to add a "pinging" feature too. Although really unneccesary. If you contact
the host directly, and it answers, you know it's there, you don't need to
ping.  The disadvantage is again that IP is required.


**CONCLUSION**

Advertising and pinging methods are needed.   There should be a way for a
new remailer to announce itself to the net (might not be trusted or used by
software, but it's up to the user), and a way for existing remailers to
announce that they are going down (and announce when they come back up).
There also needs to be a way for a user to "querry" a remailer
individually, instead of relying on advertising, _especially_ if the
advertising method is high-latency.

Both the slower store-and-forward (mail, news) techniques, and the faster
direct-socket-connection techniques both have advantages and disadvantages.
Ideally, _all_ of them would be exist.  Some remailers might only support
or deal with some of them (out of choice or lack of IP connectivity or
bandwith), but client software could gather info from all or some of the
pinging and advertising mediums, and make choices about whether to use
remailers, based on how much info it has, and what the info says.

And the issue not even discussed here, is that of having a succesful way to
bounce messages.  If all of your advertisment-gathering and pinging fail
anyhow, you should be notified that your message didn't make it through. It
actually seems possible that a succesful bounce method would remove the
need for advertising and/or pinging completely.  But a succesful bounce
method seems even more remote then succesful pinging/advertising methods.