Enforce forward travel

[futurechimp]

The Loopix paper says that messages may only travel forward in the layers of the mixnet topology. This presents us with a small problem, because clients define the paths that messages must take through the system. Clients sending messages into the mixnet should define a path that goes e.g. Layer 1 => Layer 2 => Layer 3. But anyone in the world is free to construct their own client. There's nothing we can do to stop somebody sending messages over any path they want (e.g. a "wrong" path using nodes in Layer 3 => Layer 2 => Layer 1).

Clients doing stupid stuff will definitely harm their own security. If we determine that this may also harm others (e.g. by providing less cover traffic) we should enforce constraints on paths at the node connection level: dropping packets which are going in a wrong direction.

[futurechimp]

@aniampio if you can provide a rationale on this one that says we really need to enforce forward travel constraints, we'll do so. Keep in mind that the chances of someone really doing this are relatively low - if they're only hurting themselves I'd rather not put the time into enforcing forward travel as there's probably lots of other useful things we can be working on. But if there's a chance that anybody can seriously impact the system we can put the dev time into it.

[aniampio]

One important assumption about selecting a path of mix nodes which the messages should traverse is that the mix nodes do not repeat in a single path: so we don't have a path like Mix1->Mix2->Mix1, this is avoided even in topologies different than stratified.

A simple example showing how clients doing stupid stuff can impact honest clients.
Imagine an adversary observes a network defined as
Layer1: [Mix1, Mix4], Layer2: [Mix2, Mix5] , Layer3: [Mix3, Mix6].

The adversary sees that Alice and Bob are sending their messages. Alice, follows the rules of stratified topology and injects her packet to Mix1. At the same time, Bob does not follow the rules, and injects his packet to Mix6. The adversary now observes that Mix1 sends a packet to Mix2 and Mix6 sends a packet to Mix2, so technically those packets will mix. But now, the adversary sees that Mix2 sends a packet to Mix1, which next sends to Dave, and Mix2 sends another packet to Mix3, which forwards it to Eva. So, the adversary now knows that the packet going from Mix2 to Mix1 has to be Bob's packet since Alice injected her packet to Mix1 (so Mix1 was already on her path, and she wouldn't repeat that). Hence, the other packet going from Mix2 to Mix3 and then Eva must be Alice's packet. So even though Alice followed the rules, her anonymity was harmed (adversary knows that Alice sent a message to Eva).

Of course, this becomes more complicated when there is a lot of traffic, but it still decreases the anonymity set and opens an opportunity for attacks.

[aniampio]

I took a look into the literature, and one of old Claudia's papers ("Impact of Network Topology on Anonymity and overhead in Low-Latency Anonymity Networks") gives aditional argument about the anonymity in stratfied vs free routes networks (by Free Routes we define a network in which nodes are connected to each other and traffic flows in different directions)

" In Stratified networks, circuit routes going through the same node are always mixed, because the node is in the same path hop for both routes. In Free Routes, however, circuits may pass by the same node and not be mixed if the node is at a different hop in the circuit paths. Consider for example a node that is the entry node for circuit c_a and exit node for circuit c_b. Given that routes always have three hops, the adversary knows that the circuit c_a entering the network at n cannot go out of the network immediately, and thus the outgoing c_b cannot possibly be the exit of c_a – i.e., c_a and c_b are not mixed in n."

If we let people create the path as they like, then we gonna encounter a similar problem.