Verify edge node identity

[emanuele-f]

Verify edge node identity

[Logan007]

This is probably possible only by using public key cryptography methods as the fingerprint needs to be signed by some trustworthy instance.

As far as I can see, the only way to avoid public key cryptography here is to make the supernode own a special secret key to sign, i.e. encrypt, some hash of IP/MAC for issuance in the first step and verification later with every register and letting know the other nodes - which is against the (very well thought) design of a key-free supernode, one of the main advantages of n2n as a suprenode (maybe on a vps or in the middle of elsewhere) might not be under your full control.

Did I get you correctly? Do you have something else in mind?

[emanuele-f]

There should be no need to rely on the supernode to implement this. The idea is to generate on each edge node a pair of public and private keys. When node A wants to talk to node B it encrypts packets with the B public key. B can publish its key periodically <mac_B,public_key_B> . A can remember the past mac->key associations and on first connection/when they change could notify the user (this is something to reason on) and/or block all the connections unless the provided key is in a static list stored in a txt file. This also prevents the other nodes to read the B messages by performing mitm attacks.

[Logan007]

What about broadcasts? They would need to be handled separately.

Or forwarded packets? A feature I love to use for vpn replacement :)

[emanuele-f]

Yes, all the edges can use the same key for broadcast messages, derived from the community secret key. For the forwarded messages, the destination mac address of the packet determines the key to use. For example:

Edge A wants to send a message to the ip 10.0.0.2, which is only accessible from Edge B. Edge A encrypts the message with the B public key and sends it to B (destination mac). B decrypts it, and routes it to 10.0.0.2 as plaintext because 10.0.0.2 is outside of the edge network, otherwise if the message was directed to another edge node C, it would be encrypted with the C public key.

[Logan007]

In this context, shouldn't we also ponder the scenario in which free riders use our supernode for their own (hopefully not darknet) purposes? Even if they do not know our pre-shared key, they just would need to know the address and port of the supernode (can be captured from transmitted packets) and the community name (can also be clearly read in the transmitted packets) and just use their own key. Our edges might receive a few broadcast packets that they are not able to decipher, but other than that, they would not be disturbed.

[emanuele-f]

In such case the "guest" edges should use a different community to communicate freely without interfering in order to properly segment the broadcast domain

[Logan007]

Actually, I am more concerned about malevolant guests who intentionally want to free ride on the same community name... as other community names might not be allowed by the supernode.

[emanuele-f]

For hostile environments I think we need to implement an additional layer where the whole packet between supernode and edge nodes is encrypted. This would make n2n stealth and also prevent unauthorized clients from joining. Maybe this github issue can be solved with such an approach without the need for public key crypto, thus assuming that once an edge can join the supernode than it is authorized and friendly.

[Logan007]

For hostile environments I think we need to implement an additional layer where the whole packet between supernode and edge nodes is encrypted. This would make n2n stealth and also prevent unauthorized clients from joining. Maybe this github issue can be solved with such an approach without the need for public key crypto, thus assuming that once an edge can join the supernode than it is authorized and friendly.

Do you think that -H solved this issue?

[Logan007]

Considered solved by -H (and later -J), please re-open if required.