CDR: PipeNet protocol

Adam Back adam at cypherspace.org
Sun Nov 5 19:11:54 PST 2000


Wei Dai wrote:
> On Thu, Nov 02, 2000 at 10:14:24AM -0500, Adam Shostack wrote:
> > 	Actually, I'm unconvinced that even pipenet style padding is
> > sufficient.  Looking at the work on traffic analysis thats been done,
> > we're in about 1970.  We have one time pads (dc-nets), and some other
> > stuff, but we don't have a DES to analyze.  We have an adversary who
> > has spent a long time learning how to do this well.
> 
> I'd prefer if people talked about PipeNet style traffic scheduling
> instead of PipeNet style traffic padding. What's really important to
> PipeNet security is that the timing of packets don't leak information,
> and padding is just a part of what's necessary to achieve that kind
> of timing. So I'd agree with you that padding by itself isn't sufficient,
> but I'd be interested in hearing more if you think PipeNet as a whole
> isn't sufficient.

For those that don't know about PipeNet Wei has a description here
[1].  PipeNet is a synchronous mix-net where users stay connected and
consume bandwidth 24x365 to avoid revealing when they are using it.

PipeNet's synchronous behavior would be implemented on top of TCP with
it's best-effort service by using the following scheduling algorithm
(from [1]):

| Each node expects one packet from each link id in each time unit.
| Extra packets are queued for processing in later time units.
| However, if a node does not receive a packet for a link id in a
| particular time unit, it stops normal processing of packets for that
| time unit and queues all packets.  This ensures that any delay is
| propagated through the entire network and cannot be used to trace a
| particular connection.

This is to defend against active attacks delaying packets to observe
the effect on the network and hence trace routes.

However I think this scheduling algorithm would have the side effect
of making this variant of PipeNet very vulnerable to DoS attacks.  Any
user can arbitrarily delay packet delivery for the entire network by
ceasing to send packets.

It would also seem that performance would degrade badly to effectively
the performance of the worst ping time link.

(PipeNet uses mixing at each node.)

Perhaps there are some engineering trade-offs you could make if you
were to try to practically implement PipeNet.

Adam

[1] http://www.eskimo.com/~weidai/pipenet.txt






More information about the cypherpunks-legacy mailing list