Connection slot exhaustion DoS mitigation

[pstratem]

Connection slots are a limited resource which can be the target of DoS attacks.

This issue was introduced in 2011 by 5a3e82f.

In mitigating this issue it is important to take steps to avoid network partitioning.

I have taken the approach of protecting connections with various properties from eviction.

Of the nodes still available for eviction the most recently connected node from the CNetAddr with the most connections is selected and evicted.

The largest class of protected connections is those which have been connected for the longest time.
The intent is to maintain the strong bias towards these connections which exists today and thus avoid any risk of network partition.

[pstratem]

This has been tested by setting up a node and then connected to it from the same source ip in a loop.

Additional testing is needed around multiple source ips.

[laanwj]

Concept ACK

This does need extensive testing in various scenarios - e.g. what happens with Tor hidden service connections, which all appear to come from one IP (localhost) address.

[pstratem]

Tested with multiple inbound connections from 128+ source ips.

Long lived connections were stable and the newer connections dropped.

[petertodd]

@pstratem How did you actually test that?

We could make good use of automated scripts to make such testing relocatable.

[pstratem]

@petertodd python script that connects to the node in a loop running on top of torify and me sitting there hitting "new identity" in vidalia a bunch until i had unique ips connecting...

not exactly an automated process

[pstratem]

@laanwj Missed the second part of your comment.

This wont ever evict localhost connections, so inbound connections to a hidden service wont ever be disconnected by this.

That's actually not optimal, but unfortunately getting info on inbound hidden service connections requires interfacing with tors control port.

That's definitely out of scope for this patch set.

[laanwj]

@pstratem Absolutely - I wasn't implying that you'd have to interact with Tor's control port in this pull, just that it's a requirement that it didn't make the current situation worse.

Needs a trivial rebase in net.cpp due to #5288.

[laanwj]

Deleting CNodes happens in the "Delete disconnected nodes" loop, which first makes sure that no one is using the node anymore. Adding a delete pnode here seems like a danger for race conditions?

[pstratem]

This is deleting the CNode which was created at 984 and which was not added to vNodes.

Not deleting it here would be a memory leak.

[laanwj]

Bah.
I wonder if we could use e.g. boost::scoped_ptr or auto_ptr to avoid this. It's too easy to get memory leaks with manual deallocation along a subset of code paths, especially when factoring in exceptions.

[pstratem]

Alternatively I could just add it to vNodes and rely on the normal cleanup logic.

[TheBlueMatt]

Spoke with @pstratem about this for a bit and we agreed this should be refactored so that the connection acceptance stuff is in a separate function. Also after this change the nWhiteConnections variable is set in init but goes unused.

[pstratem]

@TheBlueMatt I've simply removed the whiteconnections option in favor of protecting any inbound whitelisted connection. This is safe as outbound connections are never disconnected.

[Diapolo]

size_t to unsigned int is safe? You could use size_t for nMostConnections also.

[pstratem]

This is almost certainly safe because the values are heavily constrained, however it's not an issue to switch to size_t so I will

[dcousens]

@Diapolo aren't there warnings for this?

[pstratem]

@dcousens they're both unsigned, so no

[dcousens]

Concept ACK

[laanwj]

I think i'm missing a thing: how does this change make whiteconnections redundant? There is no information in the commit message.

[pstratem]

@laanwj All whitelisted connections are protected. Which makes a parameter for protecting a specific number of whitelisted connections redundant.

[TheBlueMatt]

Dont you need to increment the use count on the node here?

[sipa]

@pstratem I'm going through the commits one by one.

[pstratem]

@sipa ah ok then

[sipa]

Concept ACK. I think that calling AddRef/Release without holding cs_vNodes should not be done.

I think the biases can be improved still - for example by computing a score per node based on ping time, and then penalizing the scores of nodes from the same netgroup if there are multiple. But that can be done later.

[pstratem]

@sipa this is definitely intended mostly as a framework, the initial rules are an improvement but certainly not intended to be the final set of rules.

[laanwj]

utACK