HIGHWAY TO 4.0

[Logan007]

A Vision of n2n 4.0

This is a DRAFT document to put down some ideas, far from complete. It will further develop along the hopefully unfolding discussion. While being updated accordingly, it will become even longer and longer – you were warned! 😉

Starting Point

As discussed at several places of ntop's n2n github repository, a more p2p-like approach seems feasible. That would mean the same peer executable at all places of the network – also replacing the current supernode whose functions are

• directory of known edges
• hole-punching helper seeing external port
• ping partner to keep port open by recurring registration
• forwarding as fallback
• broadcast handling
• central authority for edge authentication
• ...

Underlying Network

Peer Hierarchy

If direct p2p does not work, packets need to be forwarded. Up to now, the supernode took care of it. If no explicit supernode is around, which one of the equal peers shall forward the packets? For example, with the once discussed Cademlia-approach, the routing happens through the "nearest" peer. It is determined by the smallest (XOR-based) difference of the peer IDs. Thus, we could see some unwanted routing via endpoint-like clients with limited bandwidth.

It is reasonable to expect the packets to be forwarded get sent through some central node which is easily accessible, maybe with public IP address. A packet whose destination is locally unknown must be forwarded to some higher level with hopefully more oversight. Just like the former supernode.

So, the peers need some hierarchy to identify ideal routing peers. Levels can be measured in number of NAT layers found between the peers. Local peers would share the same level; peers directly connected to the public internet as well. By including basically the used destination address in the packet itself, the recipient can determine if it is behind a NAT relative to the sender.

hierarchical tree image of peers

There is some RFC mentioning similar and/or additional methods, cross-check

Actually, it is a more generalized view of the edge-supernode model. We observe that each node (but the top one) has exactly one superior node – either the local master node or one node from the next level.

Routing

For now, let's assume that each level has its master node. Just one at each level, i.e. one of the home network nodes or one of the internet nodes. Also, each master node of a level is connected to some node of the next level, not necessarily the next level's master node.

In case of a locally unknown recipient or a "packet-forwarding fallback", a peer could first ask its local master node for help. If the master node does not know, it will forward to the next higher level. There, if the receiving node does not know, it will ask its master node and so on.

Hence, the hierarchy allows a super-easy routing strategy: If unknown, send it to the next higher level.

This of course implies a few requirements:

1. The hierarchy must be well structured. There must be some benefit by escalating hierachy levels.

2. The hierarchy must be knowledgeable. We expect the peers to have more knowledge the higher they rank.

This can specifically be fulfilled if every peer knows about all the peers its sub-tree, that is the sub-tree it sees downwards. Thus, the lowest common node in the hierarchy can forward packets between two nodes. But for its own relief, it can also point the packet-exchanging nodes to lower hierarchy levels or even assist in creating a p2p connection.

So, the higher the level the more important the directory and directing aspects get as opposed to actual packet handling and forwarding.

Shortcuts

To not always forward packets through the whole tree, a node finding itself forwarding a packet can inform back the previous node of where the packet for that specific destination was forwarded to. Also, the forwarded packet will carry the information, where the packet's last station was. With this information, the forwarding node can be skipped by having the previous node and the next node make acquaintance and a connection. They will take a temporary note for routing packets with that specific destination along this route.

If all nodes along the route act alike, it should play down to direct peer-to-peer (anyone interested in proving it?) – if firewall or NAT permits.

Not to spam previous nodes with "forwarded to"-notes, an upramping repetition scheme (after 1st packet, after 1, 2, 4, 8, 16 secondes) should be implemented. Same for forwarding "received from"-information in forwarded packets. If routes do not get used, they can be deleted after let's say 20 seconds.

So, the routing happening along the tree is the default or fall-back forwarding, more or less direct connections establish as they go.

Nodes need to check the "forwarded to"-notes and "received from"-information against available registration information for not being seduced to route packets to a malicious black hole node.

The Broadcast Issue

Up to n2n 3.x, broadcasts are explicitly sent to all peers through the supernode. This even happens if they reside behind same NAT router. It costs bandwidth, not only at the supernode but also at the usually more bandwidth-limited endpoint peers. Just imagine five edges behind some small-office or home router. Wouldn't it make sense to only once forward the packet to be broadcasted? It could be forwarded to the master peer with the special duty to distribute any received broadcasts from higher levels among its local peers of the same level.

Or more generally speaking, each peer has the duty to distribute incoming broadcasts from higher level to all lower ranking nodes. This requires the local master node to have its own level a little bit higher than its local peers. Locally generated broadcasts or those coming in from lower (or equally) leveled peers need to be forwarded to all lower nodes and the higher level.

image of broadcast examples

Finally (TLDR), an even more general view would be to just forward any incoming broadcast to all other connected nodes without regards of rank. The tree structure guarantees no loops. The additional, short-cutting routing rules are not applied to broadcasts.

The equal-level case could happen by some local UDP multicast and needs special care as it could already include the local master peer though.

Equal Peers with Special Roles?

Anything that makes a peer special would complicate the code. Do the broadcast forwards really need a special role?

reflect on local master peer including registration traffic and 'highest-level-seen' pings

...

Cryptography – Part I

For use with asymmetric elliptic curve (EC) public key cryptography, every node creates its 256-bit random private key and derives the public key from it at startup. To allow for authentication, this key will be signed. In a simple setup, this key is signed by a default key burned into every node, e.g. "n2n". A more sophisticated setup will allow to provide custom key pairs to found a separate domain.

Nodes exchange their public keys, check their signatures and use the shared secret key found from the Diffie-Hellman (ECDH) key exchange scheme for further communication between them. This way, every node-to-node combination has its own shared secret for encryption, no other node joining the network can decipher the communication between any two other nodes. This will (at least) replace the header encryption used up to version 3.x which used the to-be-kept-secret community-name as shared secret key.

On the one hand, the proposed scheme offers better protection against eavesdropping as every node-to-node connection is protected by its own secret key. On first glance, it however does not allow for access control (knowledge of the commonly shared secret community name used as key). This will be achieved by a modified community handling described further below.

The option to rely on user-provided public keys for certification allows to create own networks with access for nodes with a properly certified key only. This is a very wide access control, not as fine-granular as the well-known communities. So, the certificate key's domain best compares to the 3.x concept of a federation. Support for revocation mechanisms might be considered in conjunction with user-provided certificates, e.g. via broadcasts and local safe storage.

qDSA for key's digital signature might best match the curve25519 already used in version 3.x as it allows to use the same key pairs without transformation.

Link Handling

Communities

As with the versions before, communities shall form the actual virtual networks. Every virtual network outlet, i.e. every TAP device, belongs to exactly one community. Apart from this, every node in the network shall forward packets for every community by default. Restrictions to certain communities shall apply if the node's operator wishes so – this would correspond to the locked communities at supernode level of previous n2n versions.

How to prevent that malicious intermediate forwarding nodes can impersonate a community node? If we treat the community name as private key, we can send the public key (or a hash thereof) along with the packet to identify the community. This way, the community name remains secret but intermediate nodes can still check if they are allowed to forward packets from this community. We would need to sign the packet with a key only known to community members which could be the related private key or an ECDH shared secret (p² * 9 of same private key p with p * 9 being the public key). At the receiving end, we can verify the community name and the fact, that the sender knows it too without sharing it with intermediate nodes. Instead of a computationally intense public/private key signature, we shall use an encrypted packet hash with that shared secret as key.

Compared to the 3.x series, this approach has the advantage of bringing more flexibility back to n2n. Community names now can serve as access token without the need of having to reveal it to intermediate nodes – as opposed to former header encryption which required the community names to be known to the supernodes as well.

Community names defined by regular expressions will not be possible anymore though.

Entries on the optional list of locked communities should either be filled with community name or the corresponding public key (to not reveal the actual name). To prevent holes in common n2n infrastructure, community restrictions shall only be working in custom domains where the operators are expected to know exactly what they are doing.

Message Format – Part I

Hole Punching

Cryptography – Part II

Message Format – Part II

Overlay Network

Layer 2 or Layer 3

Windows

MacOS

[Logan007]

– reserved –

Idea Scratchpad

maybe complement current replay protection scheme with packet counter to help packet loss detection

[Logan007]

– reserved –

[sweihub]

If we mimic the N2N VPN at OSI layer 2/3, the routing would be the job of existing IP protocol? We build a virtual hardware connected network on top of Internet?

[Logan007]

The n2n VPN does not consist of edge nodes only but always will require extra nodes ("supernodes") – think of establishing the connection and packet forwarding in case of no p2p possible.

"Routing" refers to routing the packets through this network of nodes. The simplest mode in n2n 3.x are edge--edge or edge--supernode--edge. Simple, but still routes. With federated supernodes, it would be edge--supernode--supernode--edge. Somehow, the n2n instances needs to know where to forward packets to.

The existing IP protocol is used to forward the packets to the right "real" address of the edge or supernode. But we cannot simply rely on it because some edges are not accessible through the router from the outside and they have local addresses.

We build a virtual hardware connected network on top of Internet?

That's what virtual networks do. 😉

[huddhudd]

this is web3 ?

[Fhokud]

Delete unnecessary symmetric encryption methods, and only keep 2~3 safe (adaptive or negotiated or configuration file specified) symmetric encryption methods such as chacha20-poly1305 and aes256-cwc/gcm