1994-08-10 - Re: RemailerNet v0.2

Header Data

From: jdd@aiki.demon.co.uk (Jim Dixon)
To: hfinney@shell.portal.com
Message Hash: 8fe843f855d731d0b95ae89a467c961a00b4946f9b3c04cb8ab5161f02b76607
Message ID: <4905@aiki.demon.co.uk>
Reply To: N/A
UTC Datetime: 1994-08-10 17:45:26 UTC
Raw Date: Wed, 10 Aug 94 10:45:26 PDT

Raw message

From: jdd@aiki.demon.co.uk (Jim Dixon)
Date: Wed, 10 Aug 94 10:45:26 PDT
To: hfinney@shell.portal.com
Subject: Re: RemailerNet v0.2
Message-ID: <4905@aiki.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


In message <199408090347.UAA24150@jobe.shell.portal.com> Hal writes:

> What is the goal of the RN as far as defeating traffic analysis?  Is it
> just to get messages from one "gateway" to another?  Or is there also
> a desire to prevent traffic analysis from one non-gateway end user to
> another?

The goal is to completely defeat traffic analysis, while allowing the
user the freedom to make use of the system through ordinary email.  If
email is used, the risk taken by that user goes up, but without
reducing the security of other users.

> What are the allowed capabilities of the opponent?  Can he watch all of
> the links?  Can he subvert some gateways?

In the real world, it would be very difficult to watch all of the links
but fairly easy to subvery some gateways to some extent.

However, as I have argued elsewhere, I think that all of the central
gateways could be compromised and it would make no difference, so long
as the number of users was reasonably large and so long as all of the
users used gateways.  From the opponent's point of view, the problem is
that he cannot tell whether there is any traffic at all.  Everyone
could be whiling away a hot summer afternoon sending noise.

The only attack would be to destroy or modify the incoming traffic.
If there are any gateways functioning correctly, RN software should
detect the damaged packets and route around the gateways that don't
work right.  This is exactly what the Internet does.

> Does every user expose the source and destination information of his
> messages to the initial gateway?  What other information is sent by the
> user to the RN?

A user sending encrypted messages via email reveals his source address.
He should encrypt his message.	The message can be to a 'far' gateway
which then remails it; in this case the 'near' gateway does not know
the destination address.  Messages can be nested to an arbitrary depth.

If a user is using a gateway, the other gateways know that the message
originated at the gateway, but they cannot tell whether that is the
true source of the message.  If the destination is another gateway,
the other gateways do not know whether that is the true destination.

> Are there any limitations on the information which spreads through the
> RN?  E.g. are gateways allowed to send source/dest information
> along with the messages?

If the message is to be acknowledged back to the source, the source
gateway must be able to receive the acknowledgement.  This creates a
trail of pointers through the network back to the source.

Only the final gateway, which reassembles the message, knows the
ultimate destination.

> Here are some questions related to Jim's specific points:
> 
> >1.6 the order of dispatch of packets is randomized
> For 1.5 you defined what randomized means.  What does it mean here?

Each gateway must dispatch a certain number of packets.  There are
a certain number of slots to be filled and a certain number of packets
queued for dispatch.  Packets are assigned an output slot (that is,
they are delayed for a certain amount of "time") according to some
sort of probabilistic distribution function.  Empty slots are filled
with noise packets.  Inter-gateway administrative traffic is queued
just like any other packet.

If a gateway is always connected to the internet, packets can be
dispatched at more or less equal intervals (measured in seconds) or
they can be batched.

> >1.7 on average, all gateways are required to send and receive the same
> >    number of packets per unit of chronological time
> Do you mean that all gateways send the same number of packets per time
> all the time?  E.g. all gateways send 100 packets per hour all the time

Yes, on average, as qualified by 1.8 and 1.9.

> >1.8 the dispatch randomization function adjusts the average latency
> >    and the distribution of latencies so that the preceding commitment
> >    is met, introducing noise packets as required
> This could be accomplished by adding no latency at all during times when
> the incoming traffic load happens to equal the desired internal traffic
> level.  But presumably some latency is actually used to provide reordering.
> What rule would determine how much latency would be used in that case?

Assume that there are only two links, one in and one out.  Packets will
be coming in at a more or less fixed rate.  Some will be consumed
locally, either because they are being used to build messages or because
they are noise.  So per unit time N come in and C are consumed, on average.

The remaining (N-C) packets are available for dispatch.  In the same
time interval, G packets are generated locally.  So a total of N-C+G
packets are to be dispatched.  The system uses a random number generator
to assign a packet a dispatch time slot when it becomes ready.	When
the clock ticks, the next packet in the queue is dispatched.  If there
is no next packet, a noise packet is dispatched.

The system knows how long the output queue is.	If the length of the
queue is increasing, the rate at which packets are dispatched will be
increased.

[I have used the term "latency" here to be provocative.]

> >1.10 gateways are required to exchange the same number of packets in
> >     any session
> What is a session?  Do you mean, during every session exactly (say) 1000
> packets will be exchanged, or do you mean, during any session the
> number of packets exchanged by each gateway will equal the number ex-
> changed by every other gateway (but this number may vary from session to
> session)?

If your gateway connects by dial-up, then the length of time that you
are connected to RN is the session time.  There must be some handshaking
at the beginning of the session and at the end.  For machines that are
always on line, a session lasts from one breakdown in inter-machine
connections to the next.

If two machines A and B are connected, then if A sends B 100 packets
per unit time, B must send A 100 packets.

> >2.4 message delivery is reliable, in the sense that the destination
> >    gateway will report delivery of incomplete or damaged messages
> >    to the gateway
> To which gateway?  The source gateway?

To the gateway which packetized the message, the source gateway.  Assuming
that 'MIRVing' of messages is permitted, the second message in a group
could be an acknowledgement back to the originator.

> >4.2 where gateways are operated by users, the requirement that gateways
> >    should exchange the same number of packets per unit time would be
> >    weakened in some as yet unspecified way
> Why do this?

I think that you must allow for the possibility that the gateways carry
very heavy traffic, say a T1 load (about 1.5Mbit/s).  Then if a user's
machine was talking down a 14.4Kb/s line, allowing the user to connect
would effectively stop the network.  There must be some provision for
inequality in traffic rates along different links.

> >5.1 in either case, users may have accounts with gateways and may be
> >    charged for usage
> What gateways would be in a position to charge users?  Only the source
> gateway?  The destination gateway?  Others in between?

I assume that in a commercial network, the gateways have accounts with
one another that are settled periodically.  Essentially they charge
each other for non-noise incoming packets at some agreed rate and then
pay the accumulated difference every so often.

Users should pay the gateway which fragments a message.  The charge
should be proportional to the size of the message in packets.  If
messages are nested, you need to include postage.  This requires
anonymous ecash.

> >6.0 RN gateway software should be available only from trusted sites by FTP
> What are you trying to prevent by this, and what would happen if someone
> wrote his own version of the RN software?

I am trying to prevent the inevitable.

Weaken this requirement, eliminating the word 'only'.  Publish the specs
as well, and then say "RN gateway specs should also be available from
trusted sites..."

> >7.1 established gateways would be encouraged to rate new gateways
> What kind of information would be available to them to create the ratings?

Gossip, rumors, route announcements and 'hello, here I am' messages from
the operators of the new gateways, experience in RN data communications
with them, reports from commercial credit agencies, ... whatever
information they could lay their hands on.

The technical information would be published in some standard format,
for example a matrix of claimed lost message rates.

--
Jim Dixon





Thread