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