CDR: Re: PipeNet protocol

[Adam Back]

Wei writes:
> > [...] if many web servers supported
> > connections from the freedom cloud using freedom protocol, and nodes
> > in the network did per hop padding using a modified PipeNet scheduling
> > algorithm where you would try to use PipeNet scheduling, but instead
> > of delaying, if a packet didn't arrive in time, you would send some
> > cover instead on a hop by hop basis.  [...]
> 
> I don't think that works very well. When you send some hop by hop
> padding, every node downstream would be able to tell that some delay
> occured somewhere upstream in the connection. 

I think I phrased that badly.  The hop that didn't receive enough
packets on a link would create padding, but the padding would be
end-to-end between that hop and the end hop (the recipient node, be
that client or freedom enabled web server).

Clearly if you compromise enough exit nodes, you can then selectively
DoS links and observe the padding as the exit node must see it.

With freedom and to some extent with the freedom on servers variant
(my earlier comment quoted above) I think 3 hops is roughly the
maximum useful number of hops.  This is because it's a real-time
protocol and it's not end-to-end padded.

In the case of freedom it's simply not end-to-end padded, with the
servers variant it could be end-to-end padded, but the attacker could
compromise other nodes, induce delay and therefore persuade the node
to pad and then correlate the padding with the compromised exit node.
Hence in either case two compromised nodes gives you a lot of info.

With PipeNet's synchronous mix-net you don't have this problem, but
you have the performance and DoS problems.

> So if either the receiver (the last node) or the next to last node
> is compromised, the attacker would be able to trace the caller by
> correlating between delays in the network and where hop by hop
> padding occurs.

I agree with this conclusion despite the ambiguous explanation -- the
attack is a little more active, and requires more compromises, but
still holds I think.  So this type of network is not secure against
too many node compromises, where-as PipeNet's synchronous mix-net has
more mix-net like properties.  However it offers reasonable security,
it should have reasonable performance, be resistant to widespread DoS
and have similar bandwidth overhead to PipeNet.

You could use traffic shaping (in any of the networks we discussed) to
reduce the bandwidth consumption in quiet periods as Lucky described
in the past based on slowly moving average, typical period
fluctuations etc.

There is another parameter in the previous comparison I missed off:

4. Bandwidth Cost

With the server variant of freedom you could also mix different
classes of traffic -- some with end-to-end padding and some with no
padding.  The padding is fairly expensive in bandwidth.  Also one
could have different route create and destroy rules -- PipeNet create
and destroy mixing will make route setup quite slow.  In this way you
could build a network which supports different performance, cost, DoS
resistance and security trade-offs.  You could presumably allow
PipeNet in the same network also.

There is some advantage to having more people using the same protocol,
because there will be limits to the cover provided to each other of
different traffic classes.  Weaker things could be eliminated from the
picture for example with higher level threat models, if the threshold
of compromised nodes or capability of attacker is above the weaker
higher performance routing protocol, but below that required to
compromise the high security protocol.

Adam