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