Attack to Discuss

[dnwiebe]

Here's an idea for an attack from an exit Node. Discuss: How do we defend?

Some originating Node uses the exit Node--and a couple of relay Nodes--to retrieve some data from a website. The originating Node is satisfied, and the virtual TCP stream is closed, either by the browser or by the server.

The evil exit Node now continues sending data--garbage data that it makes up--over the existing stream, through the relay Nodes to the originating Node, since it has the keys with which to make the CORES packages. The relay Nodes dutifully transfer the data in good faith, and rack up charges against the originating Node, but the originating Node has discarded the StreamKey and no longer has the information necessary to pay for the unwanted data, even if it were disposed to do so. The evil exit Node keeps sending garbage, the relay Nodes keep doing what they think is good work and not getting paid for it, and eventually the originating Node is delinquency banned through no fault of its own.

Then the evil exit Node starts on other originating Nodes.

How do we defend against this attack?

1. The weakest defense I can think of is to look for more than one or two straggling packets arriving from the same exit Node, and run that exit Node's undesirability way, way up so that we never use it again. That's not going to prevent the attack, and it's not going to keep us from being banned by those two relay Nodes, but maybe it'll keep us from being banned by other relay Nodes if we were to use that evil exit Node again. However, even to mount this very weak defense, we'd need to keep the StreamKey around quite a bit longer than we do now. Inter-Node TCP connections are very long-lived, and the evil exit Node could remember our StreamKey for days and days before it started spewing garbage back at us using it. We'd have to remember every StreamKey and its associated route for at least that long if we were going to use the StreamKey of the arriving garbage to find the corresponding route and identify the exit Node. And--this just occurred to me--this wouldn't even work, because the evil exit Node could simply make up an up-to-that-moment-nonexistent StreamKey and attach it to the garbage packets. Even if the originating Node remembered StreamKeys for centuries, it wouldn't remember that one, and so it would not be able to resolve it to a route and identify the exit Node for an undesirability increase. So that's not a defense at all. Never mind.
2. Maybe the StreamKey could be moved from deep inside the CORES package to its header, and signed in some way that could be checked by the relay Nodes, so that the exit Node couldn't change it without exposing itself? Even if we could do that without exposing the identity of the originating Node (we'd have to keep more information in the relay Nodes), the originating Node would still have to remember StreamKeys and routes for a long time. Or...hm...maybe StreamKeys could carry an identifiable time to live, after which relay Nodes would know better than to relay CORES packages using them? (That would require some special handling for long-lived virtual streams--for example two-hour movies.)
3. Maybe as well as or instead of pulling the StreamKey out to the header where everybody can see it, we pull out the last_data flag? If the relay Node could somehow know that a CORES package from the exit Node was a response to a last_data = true CORES package it had passed on to that exit Node (the StreamKey might help with that), it could allow only so many such CORES packages to pass before starting to reject them.
4. Hopefully there are other defenses?

[utkarshg6]

Alright, Uncle Dan, I think we can pull this off!

Here's the idea: the originating node will send a timestamp to the relay and exit nodes, bundled up with the CORES package and tied to the stream key. This timestamp will tell everyone when the stream key expires. If the relay or exit node gets a package with an expired stream key, they’re like, “Nope, not passing this along anymore!”

Now, to keep things flexible, we don’t have to force an expiration date every time. We can make this whole expiry thing optional—only coming into play when the user decides to shut down a particular stream key.