Re: End to end Mixminion issues, with proposed solutions

[George Danezis <gd@theory.lcs.mit.edu>]

On Tue, 24 Sep 2002, Len Sassaman wrote:
> Not all implementations need to support creation of remailer messages,
> or delivery of plaintext messages. There could be an implementation that
> is simply a "middleman" remailer, that only takes encrypted remailer
> messages, mixes them, and hands them to other remailers. Such an
> implementation would not be concerned with fragmentation or reassembly.
> 
> Any implementation that delivers messages to the end user (in plain text)
> MUST know how to reassemble them. And any implementation that creates
> remailer messages from plain text SHOULD know how to fragment the message,
> and SHOULD NOT but MAY reject oversized messages.
> 
> 
> --Len.
> 

I think I am quite happy with the statement above. Since Nick said he will 
be thinking about fragmentation and reassembly, compression and error 
correction here are my thoughts:

1) The above functions would need to be implemented on top of the standard 
mixminion interface (so we better design the interface to provide all the 
facilities we need).
2) The mixminion network middle nodes should not have any awareness about 
this layer (which follows from 1).
3) Requirements:
	- Fragmentation and reassembly allows messages (A), or streams (B) 
to be transported anonymously on the mixminion network, even when their 
size is larger than a single mixminion packet size.
	- Error correction allows messages to be reconstructed even if 
some of the mixminion packets were dropped by the network.
	- Compression can be used on the original message to minimize the 
bandwidth it would use in the network.
4) The way of archiving the above should be the same for forward path 
messages and SURB routed messages.
5) Contentious: Since many mixminion packets are notionally used to route 
a message to another user I propose we establish at the same time support 
for pseudonymous sessions. What does that mean:
	- An ID or signature is included in the message along with a 
serial number. 
	- Some SURBS can be provided that are associated with the ID and 
signature that the other side keeps as a reference to be able to reply to 
the sender.

Therefore the two communicating parties can maintain a channel open, and 
have a two way conversation. The idea popped in my mind whn I tried to 
specify the Nym Server and realized that bi-directional sessions whould be 
required by most (complex) applications.

7) I believe Rabin's Information Dispersal Algorithm with gzip should 
fulfill well the requirements in (3) but I do not know much about these 
issues, so please comment. I believe forward error correction codes are a 
better solution than retransmissions for reliability but this is just a 
gut feeling.

Please comment on the parts above.
I suggest that:
Nick - thinks about requirements in (3).
I (George) - thinks about how to do (6) and follow the discussion (or 
             flame war) about it.

Yours,

George