Questions

[Adrien Lemaire]

First, thank you for the presentation, extremely easy to understand. I have a few questions regarding this protocol:

1. How long is the election term ? You talk about the election timout 150~300ms to become a candidate, but I missed the term timeframe info.
2. How do you handle attackers ? If nodes can decide themselves to become candidate, couldn't one bypass the election timeout and send out request vote messages instantly ?
3. How do you insure that the leader is fair ? Even if bypassing the election timeout isn't possible, what if I wait to become a leader then start sending whatever message I want to send (ie in a blockchain, let everyone know that some follower owns me all his coins) ?

This kind of central authority, even if for a brief term, is a bit worrying ^^' Wouldn't a number of cluster centers sharing the authority (and elected more carefully with some trust weight from past operations) be more robust ? [/me go study about the federated consensus]

[Philip O'Toole]

I can answer 2. Raft assumes behaving nodes -- it is not designed to deal with a node that is deliberately trying to circumvent the system.

[Philip O'Toole]

And if a node tries to circumvent the system that is considered a bug in the implementation, not an "attacker".

[Adrien Lemaire]

@otoolep thanks for the quick reply. Isn't assuming that all nodes are honest a bit naive ? If the project is open source, one could re-engineer a tainted version that could connect itself to the network. Even if not open source, reverse engineering exists. And if all nodes are guaranteed to be well-behaving, there's still the risk of having a man-in-the-middle usurper modifying for example Append entries messages (probably harder if messages are properly encrypted though).

Then, are there guidelines / recommendations on how to safely implement this consensus ?
Guess I'll have to find some time and dig in some implementations.

[Philip O'Toole]

It's not naive. Like any system you are responsible for running a secure deployment and network, and only standing up nodes with software you trust. If your network is so open that nodes you can't control can just connect, you may have bigger issues.

However many actual usages of Raft consensus protocol -- my own rqlite system for example -- do allow you to enable security checks, requiring nodes that wish to join to supply the right password. That way you only supply the password to the nodes you trust. The easiest way to do this is to only supply the password to nodes you launch.

[Philip O'Toole]

Specifically https://github.com/rqlite/rqlite/blob/master/DOC/SECURITY.md

But this is a feature of rqlite, not Raft itself.

[Adrien Lemaire]

I see. Thanks for the support, closing this issue !

[Philip O'Toole]

For example, if you know the IP addresses of which nodes are running your Raft system, you might be able to configure your network such that only those nodes can talk to each other, for the purposes of joining. This would prevent any other node from connecting.

This is an example of what I mean by a "secure deployment and network". AWS EC2 Security Groups, for one, allow you to do this. (https://github.com/rqlite/rqlite/blob/master/DOC/SECURITY.md#network-security)

[Adrien Lemaire]

yeah... it's a bit different for blockchain systems (no control over the network), where whitelisting IP addresses would be a terrible idea. I suppose I was too focused on this example :)