Re: Broadcasts and the Rendezvous Problem

-----BEGIN PGP SIGNED MESSAGE-----


Timothy C. May writes:
 > Isn't this what "alt.anonymous.messages" is all about?
 > 
 > (It's been at my Netcom site for many months now...I don't recall who
 > created it, but it seems to me it was one of us.)

Alas, it is not available at MIT.  I'll have to scrounge for a server that
carries it (volunteerings of feeds welcome!);  Though netcom is our
IP provider, I'd rather not get news from them.

 > > Folks spend a lot of time bemoaning the transience of specific instances
 > > of remailer nodes: why not turn this into an advantage by architecting
 > > a network of system that is resilient against the destruction and/or
 > > compromise of individual nodes?
 > 
 > I'm not sure what you mean by this. More remailers are always a good
 > thing, and offshore sites are especially good, but I'm not sure what
 > you mean by your last point.

(Following details of the current system might be wrong.  Please correct
 me where necessary.)

My thought is this: If we were to design and implement a system, perhaps
a two-tiered system with "fortress" and "intermediary" remailers as has
been suggested, it's desirable to build a system that will continue to
work even if a large portion of the nodes are removed (whether by Earthquake
of Sun Devil).  This is the system we'll have to build if we stop resisting
the notion that remailers regularly come and go with little warning.

The rendezvous problem is not currently addressed in a satisfactory way:
premail/remailer-ping, or its equivalent, hardwires in the location of
a known set of remailers and finds the subset that corresponds to
remailers having a common characteristic (usually just whether they're
working reliably or not).  

That's not a very good approach: a human has to add a new remailer into
the "net" by adding it to the systems polled.  Not only is the human
intervention a Bad Thing, but having a central registry of remailers
is bad infrastructure.  A more "web-of-trust"-like mechanism is desirable.

So, a dispersed view of the remailer net, both entry points and intermediary
points, is necessary.  In order to build such a system, we must solve the
rendezvous problem: how does "premail++" know where to send its mail and
how does remailer A know where to find remailer B (and B find exit point C)?

This is where my train of thought dovetails with the newsgroup question:
bringing a new remailer on line could be achieved by broadcasting a message
through a newsgroup specifying the location and type of the remailer.  If
necessary, one or more pseudonymous automatic testing agents could pick up
the message and put the remailer through a barrage of tests, broadcasting
a "remailer certification" with a certain duration.  "Premail++" and
remailers could find their next hop by examining current certifications
and choosing one with desired characteristics, scoring by trusted testing
agents and other criteria (including the passage of time since the last
certification).  If an exit-remailer is chosen early in the game, multiple
paths to the exit-remailer can be used to improve reliability (exit-
remailers would also probably have a shorter cycle of certification).

Technically, this is feasible.  I could write the code fairly easily (though
I'm not offering to do so at this time: if I do, pieces will be offered as
fait accompli).  My question is whether this strikes anybody else as a
desirable design: we would end up with a net of remailers that is fairly
resilient and not dependent upon any one list of remailers.  If a node
goes down, the net adjusts in rather short order and service is not
disrupted.  

This picture needs to be fleshed out a bit more, but I thought I'd bounce
this around before solidifying it in any particular way.
- --
Todd Masco     | "'When _I_ use a word,' Humpty-Dumpty said, in a rather
cactus@hks.net |  scornful tone, 'it means just what I choose it to mean -
cactus@bb.com  |  neither more nor less.'"   - Lewis Carroll
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLuuBmSoZzwIn1bdtAQEI9QF/fX2LPoUwzlKYJqJ1s0vb/mIX4NzT1jOo
UNHdiOYNJ+vgpPQyIZ9OQynMuKfSVgU/
=vn6H
-----END PGP SIGNATURE-----

L. Todd Masco said:
> [...]
> bringing a new remailer on line could be achieved by broadcasting a message
> through a newsgroup specifying the location and type of the remailer.  If
> necessary, one or more pseudonymous automatic testing agents could pick up
> the message and put the remailer through a barrage of tests, broadcasting
> a "remailer certification" with a certain duration.  "Premail++" and
> remailers could find their next hop by examining current certifications
> and choosing one with desired characteristics, scoring by trusted testing
> agents and other criteria (including the passage of time since the last
> certification).
> [...]
> My question is whether this strikes anybody else as a
> desirable design: we would end up with a net of remailers that is fairly
> resilient and not dependent upon any one list of remailers.  If a node
> goes down, the net adjusts in rather short order and service is not
> disrupted.  

Handling unreliable remailers is even more important if you want to
encourage the "every-one-a-remailer" view. Numerous, low traffic,
remailers will not be run professionally.

I'd like to complete such a view of a remailer plan with:

1) Acknowledgements, or Bounces, or broadcast drop-ids: When a mail is
sent through a chain of remailers, it should be dealt with reliably
from the user perspective. That means either the user gets an ack that
the message got there when they do, or the user gets a bounce when they
don't. Either way he should know what to expect. You could do that with
response blocks (but they themselves can fail), or you can do that by
broadcasting the ids of messages that are dropped because the next node
in a chain is down. An id is just a large random number. Again, here
you can use a broadcast medium. This could also be achieved if the
recipient's mailer filters out duplicate copies of messages: the
sender's mailer would monitor the reviews of the remailers used in
transit, and re-issue messages that came too close to a break in the
chain. Nobody ever needs to look at all this info, it would be handled
by your personal Premail++.

2) Amateur remailers need a flow control mechanism. You cannot expect
somebody (or his internet provider) to be happy when his personal
account remailer suddenly becomes the most popular in the current
premail++ rating and gets flooded by everybody and his brother
(randomizing premail++ or not). It does not need to be a very smooth or
precise flow control, but it should be enough to prevent catastrophic
events. Current systems tend to do that by refusing the mail, or
dropping the packets on the floor, but we do not have this luck: the
personal mail of the account holder must still go through. I do not
know a good way to do that. Posting the remailer as being down when a
flood occurs is too rash and too late. One way to do that would be for
these "small" remailers to issue tickets (say 700 message tickets a
week, each valid for the transport of one message).  The remailer agent
(premail++) of a remailer-net user who expects to use the net for
around 15 messages a week would try to reserve, say, 6 tickets each
from 20 "small" remailers (for chaining, and to account for "sold-out"
remailers). In the message, with the info for each successive remailer,
it would paste in a ticket (which is then spent.) But now some ticket
distribution system is needed: ticket distribution could be done by the
remailer itself, but then we would be back to a flooding problem. So
ticket distribution is better handled by "seriously" run "ticketing
agents", just like the review process is better done by "review
agents". A "small" remailer would hand out a provision of tickets to a
small set of "ticketing agents", and would post to the broadcast medium
that it is up and that tickets can be obtained from this set of
agents.  A ticket is simply a short string of random numbers.  They can
be re-used fairly quickly by the "small" remailer (say used one week
out of 4), as we are only trying to avoid fortuitous flooding, not
criminal mail-bombing.

Finally, I'd say that a well propagated Usenet News group is a
convenient medium to do this on, but needs not be the only one
considered.  A not-so-well propagated broadcast can be reached by
anybody's premail++ through yet a third set of robot mailers,
advertised in an ad-hoc fashion, just like the remailers themselves
now.

I know this is a lot of different entities, but I firmly believe that
(soon enough :-) nobody will use chained remailers manually, Premail
is only the beginning.

Pierre.
pierre@shell.portal.com

From: "L. Todd Masco" <cactus@hks.net>

   That's not a very good approach: a human has to add a new remailer into
   the "net" by adding it to the systems polled.  Not only is the human
   intervention a Bad Thing, but having a central registry of remailers
   is bad infrastructure.  A more "web-of-trust"-like mechanism is desirable.

In terms of autopinging, certainly human intervention is not desirable.

This begs one question though, namely, "how does one gain trust in a
remailer?".  Certainly likelihood of service can be automated, but
other forms of trust cannot.  Human intervention is necessary each
time someone begins to trust a remailer.  That intervention can be for
one's own use or for someone else's, but automatically trusting new
remailers is Not Good.

The question then becomes "what is the structure of human intervention
required to change the trust in a remailer?".  Use of agency will be
desirable, certainly.

These questions of human relations need to be examined before
technical means of communication can be profitably pinned down.

Eric