n2n_v3(7)

πŸ’– n2n_v3(7) β€” background lore, bestie edition πŸ’–

Hiii okay so this is the manual page n2n_v3(7), and it's literally just the background section of the n2n saga. No options, no flags, just vibes and architecture. Come sit, I'll explain everything. 🫢


✨ NAME ✨

n2n version 3 β€” that's version 3 of the n2n decentralised peer-to-peer network overlay VPN. Periodt.


🌸 DESCRIPTION 🌸

So n2n is a peer-to-peer network overlay / VPN situation. It does layer 2 over layer 3 encapsulation, and it comes with data transform powers like encryption and compression. Slay.

This guide also walks you through how version 3 of n2n differs from version 2, because they are not the same girl and you need to know that going in. πŸ’…


πŸ¦‹ PROTOCOLS πŸ¦‹

n2n-3 basically uses the same set of messages to talk to edges and supernodes. However β€” and this is the important bit β€” because the packet format changed slightly, n2n-3 messages are not compatible with n2n-2.

There is no backward compatibility for n2n-2. None. Not even a little. It's giving clean break, and honestly? Respect. πŸ’€

πŸ” ENCRYPTION πŸ”

n2n-3 offers four different ciphers for payload encryption, plus optional header encryption. Earlier versions of n2n-2 shipped a mechanism using a key schedule β€” that's been removed in n2n-3. And a basic user authentication scheme relying on asymmetric cryptography has been added to n2n-3. Glow up. ✨

n2n-3 provides the following ciphers to chose from for payload encryption; more can be added as required:

  1. NULL β€” data is encapsulated unchanged. Useful for testing and for high-performance, low-sensitivity applications. (She said no thoughts, head empty, maximum speed. πŸ“)
  2. TF-CTS β€” Twofish AES candidate in CTS mode.
  3. AES-CTS β€” AES in CTS mode with up to 256-bit key.
  4. CHACHA20 β€” ChaCha20, a well known stream cipher developped by Daniel J. Bernstein. Iconic behaviour.
  5. SPECK-CTR β€” a fast block cipher developped by the NSA, used as a stream cipher in CTR mode.
  • Full Header Encyption β€” the optional full header encryption also encrypts packets' header, which include some administrative data. On top of that, it adds replay protection. Bestie said cover everything. πŸ‘‘
  • User Password Authentication β€” n2n-3 implements an optional user-password authentication scheme. A key generator assists in generating user's public keys to be stored at the supernode side.

😭 COPMPRESSION 😭

LZO for payload compression is an always available option at n2n-3. And if it's compiled with zstdlib support, ZSTD is at optional service as well. Two snacks on the menu, one is always in stock. πŸŽ€


🧚 EXTENSIBILITY 🧚

n2n-3 decouples the data transform system from the core of the edge operation. Why? So adding new data transform operations is easier, that's why.

n2n-3 reserves some standard transform identifiers (such as TwoFish encryption) but it also allocates transform identifiers for user-defined transforms. Which means literally anyone can add new private transforms to n2n without breaking compatibility with the standard offering. Main character energy for the community. πŸ”₯


🌈 FEDERATED SUPERNODES 🌈

n2n-3 incorporates the capability of multiple supernodes to be federated. Federation acts transparently and balances the workload evenly among the federated supernodes. Supernodes keep track of edges connected to different supernodes and forward packets as required. This feature naturally supports fail-over, and this increases redundancy and resilience. We love a resilient queen. πŸ’œ

Information on additional supernodes is propagated to all edges. In addition, the n2n-3 edge implementation allows multiple supernodes to be specified on the command line. Edges monitor the current supernode for responses to REGISTER_SUPER as well as PING messages. After three responses from current supernode are missed β€” or when a better supernode in terms of significant lower workload is found β€” the edge tries to connect to another supernode. It cycles through the list f supernodes which over and over again is sorted according to reported workload. She's always shopping around. πŸ›οΈ


πŸ’… MANAGEMENT CONSOLE πŸ’…

Edge and supernode in n2n-3 provide a UDP-based management console. Both listen on the localhost address 127.0.0.1. Commands can be sent to the programs by sending to the UDP socket. Responses are returned to the socket from which commands were issued.

This only works from the computer on which the programs are running. Local only, no long-distance relationship. πŸ™ˆ

Statistics can be retrieved and commands issued. The netcat utility is all that is required; but more sophisticated tools could be built on the interface. (iykyk β€” the interface is right there, go build something cute.)


πŸ”‘ SUPERNODE AUTHENTICATION πŸ”‘

The supernode federation name serves as private key shared between the supernodes only. The corresponding public key can be provided to the edges. Private between the supernodes, public for the edges. Boundaries, we stan. 🫢


πŸ“¨ MESSAGE SUMMARY πŸ“¨

The following message types work within n2n-3. Roll call:

  • REGISTER_SUPER β€” sent from an edge to its local supernode to register its MAC with the community. Also, federated supernodes use this packet format to register to each other.
  • REGISTER_SUPER_ACK β€” sent from a supernode to an edge to confirm registration. This also carries the definition of the edge socket as seen at the supernode, so NAT can be detected and described. Furthermore, it carries information about additional federated supernodes.
  • REGISTER_SUPER_NAK β€” supernode refusing to register an edge. (The ✨no✨ of the protocol.)
  • PACKET β€” encapsulated ethernet packets sent between edges. Supernodes forward or broadcast these, and edges send them direct in peer-to-peer mode.
  • REGISTER β€” a peer-to-peer mode registration request from one edge to another. Supernodes forward these to facilitate NAT crossing introductions.
  • REGISTER_ACK β€” complete peer-to-peer mode setup between two edges. These messages need to travel direct between edges.
  • QUERY_PEER β€” queries a supernode about another edge, especially its public socket in case of no peer-to-peer communication can be established. Additionally, it serves as PING to query supernodes about themselves.
  • PEER_INFO β€” answers the QUERY_PEER; it also covers the special case of the PING query, internally called PONG.

πŸ‘‘ AUTHORS πŸ‘‘

  • Richard Andrews andrews (at) ntop.org β€” main author of n2n-2
  • Luca Deri β€” deri (at) ntop.org β€” code inherited from n2n-1

Legends. Both of them. ✨


🌟 SEE ALSO 🌟


Okay bestie that's the whole page, you ate it. πŸ’– This was version 3, dated Sep 27, 2021 β€” go forth and overlay some networks fr fr. πŸ¦‹πŸŒΈπŸ’…

πŸ“¦ where this page comes from