CDR: Re: PipeNet protocol

[Adam Back]

Wei wrote:
> > 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.
> 
> That is all true. I guess what you meant by "insufficient" is in terms
> of performance and defense against DoS attacks, not defense against
> traffic analysis.

Adam Shostack made the comment about insufficiency of padding in
PipeNet you're referring to.

I discussed insufficiency of padding in the _freedom network_ as a
traffic analysis countermeasure in email with some folks who can speak
up if they wish.  This is because freedom does not use the synchronous
approach for performance reasons and hence some active attacks remain
even if you had end-to-end padding between client and exit node.

End-to-end padding in the PipeNet synchronous mix-net does appear to
be sufficient to provide good security against traffic analysis, but
it has the DoS vulnerability and performance problems we discussed in
the last pair of posts.

> There is a hope, however, that the performance and DoS problems of
> PipeNet could be solved in the future through other means. The
> performance issue is easier, since it just requires the underlying
> network to have better reliability and guarantee of service. The DoS
> problem could be solved if the underlying network is protected
> against DoS. Then we can require each user to place a large deposit
> on each node, which would be used to compensate everyone else for
> any delay caused by that user.

It seems to me that with the current internet TCP properties you would
have to distinguish network congestion from DoS attempts, which is not
generally possible.  Even if the Quality of Service (QoS) protocols
were implemented and widely deployed, people still put backhoes
through cables or have catastrophic equipment failures now and then.

I suppose you could have compensation or insurance from the QoS
enabled service provider and use that compensation to compensate you
for the loss of the anonymity network good behavior bond.

> I think a protocol that has good performance, defense against DoS
> attacks, and defense against traffic analysis may not exist. There
> may not even be a viable protocol that trades off between these
> properties.

Well if we look at the problem there are three properties we desire
the system to have:

1. high security (idealised resistance to traffic analysis)

2. performance (reasonable performance which doesn't degrade as the
   network grows)

3. DoS resistance (reasonable resistance to DoS -- DoS or network
   outages should be local and not take out the entire network)

It seems to me that we can have at most 2 of those.

PipeNet provides 1, but not 2 or 3.  Freedom provides 2 and 3, but is
vulnerable to some active atacks even with end-to-end link padding.

The other thing we could do is move content inside the network -- much
of the traffic analysis material comes from the fact the exit traffic
is in the clear.  For example 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.  Then you package this thing as
an accompanying apache server and encourage lots of people to run it.

Obfuscation writes:
> What if you eliminated the anonymity of caller to receiver, and only
> tried to achieve traffic analysis resistance.  That is, a receiver
> can find out who is calling him, but if the caller and receiver are
> honest and desire privacy, a third party cannot find out they are
> communicating.
> 
> Does this allow for a more efficient design?  Can the intermediate
> switch nodes now handle delays by inserting dummy traffic, which can
> only be recognized as such by the other end (caller or receiver)?

That coincidentally sounds quite similar to what I described above.
However it doesn't seem you gain much from the recipient knowing who
the sender is, beyond the change in definition allowing you to define
that the class of attacks that require compromise of the recipient
moot.  The main difference which appears to help is that the recipient
is part of the network, and can be relied upon to run software.

Adam