n2n_v2(7)

📦 version 2.1.0, in fedora 43

💖 n2n_v2(7) 💖

okay so this is the n2n_v2 manual page, section 7, filed under Background — and bestie, it's the glow-up era of n2n and I'm obsessed 💅

✨ NAME ✨

N2n Version 2 — version 2 of the n2n decentralised peer-to-peer network overlay VPN. that's it, that's the vibe 🦋

🌈 DESCRIPTION 🌈

N2n is a peer-to-peer network overlay, aka a VPN system, and it does layer 2 over layer 3 encapsulation with data transform capabilities like encryption and compression. literally iconic.

This guide is here to walk you through the differences of version 2 (aka n2n) versus version 1. no cap, there are some real ones in here 👑

🦋 PROTOCOLS 🦋

N2n-2 uses a whole different set of messages to talk to edges and supernodes. the n2n-2 messages are not compatible with n2n-1. there is no backward compatibility for n2n-1. periodt 💀

🔐 ENCRYPTION 🔐

N2n-2 serves up a brand-new way of handling encryption compared to n2n-1. n2n-1 gave you a single community password with no expiration. in n2n-2 that method is preserved, but a new mechanism got added on top using a key schedule file. two options, both slay ✨

🔑 Key Schedule 🔑

A key schedule file lists a number of keys, and for each one it has:

  • the period for which that key is valid
  • the encryption type identifier
  • the actual key value

this lets you define up to 32 keys in advance, with a pre-set time at which the keys will change. and the key schedule file can be reloaded while the edge is running, so you can load in new keys and expunge the unused ones. main character energy fr fr 🎀

⏰ Timing Requirements ⏰

When a key rolls over to the next one in the schedule, the new key is used for all transmitted packets. but — and this is the good part — any packets received using an older key can still be decoded, because the keys from the key schedule are still known. so edges do not need accurate time synchronisation. how much synchronisation you actually need depends to a large degree on the key schedule itself: rapid key roll-overs require more accurate time synchronisation. iykyk 🕰️

N2n-2 provides the following encryption ciphers, and more can be added as required:

  1. NULL — data is encapsulated unchanged. useful for testing and for high-performance, low sensitivity applications.
  2. TF — Twofish AES candidate.
  3. AES-CBC — AES in CBC mode with 256-bit key.
  4. LZO — LZO compression of data (no encryption).
  5. TF-LZO — TF cipher with LZO compression of data prior to encryption.
  6. AES-CBC-LZO — AES-CBC cipher with LZO compression of data prior to encryption.
🚨 heads up bestie: ciphers (3) AES-CBC, (4) LZO, (5) TF-LZO and (6) AES-CBC-LZO are specified but not yet implemented. they're on the mood board, not in the closet 🙈

🌸 EXTENSIBILITY 🌸

N2n-2 decouples the data transform system from the core of the edge operation, which makes adding new data transform operations way easier. it reserves 64 standard transform identifiers (things like TwoFish encryption), but it allocates transform identifiers 64 - 65536 for user-defined transforms. so literally anyone can add new private transforms to n2n without breaking compatibility with the standard offering. that's the dream 💖

👑 MULTIPLE SUPERNODES 👑

N2n-2 introduces the capability of multiple supernodes being used by an edge. and it offers supernode in several flavours:

  • Stand-alone supernode — same concept as from n2n-1. the supernode is a small, efficient C program which operates in isolation.
  • Federated supernodes — a cluster of supernodes which share information. edges registered to any of the cooperating supernodes can relay packets through the supernode federation and switch supernodes if required. supernodes can send PACKET or REGISTER messages to other supernodes to try and find the destination edge.

The n2n-2 edge implementation lets you specify multiple supernodes on the command line. edges monitor the current supernode for responses to REGISTER_SUPER messages. if 3 responses are missed, then the edge starts looking for a new supernode. it cycles through the list of supernodes you specified until it finds a working one. resilient queen 🌈

🍓 EFFICIENCY 🍓

The n2n-2 message formats have been made more efficient. the amount of data overhead has been reduced by making sure the messages contain only the data fields required. some optional fields don't consume data at all if they're not present. skinny legend ✨

🧚 DAEMON OPERATION 🧚

The supernode and edge use daemon mode of operation by default. and yes, this sense is inverted from n2n-1, where they ran in the foreground by default. they can be made to run in the foreground so tools such as DJB's daemontools can work with them. see the -f option 💅

💜 MANAGEMENT CONSOLE 💜

Edge and supernode in n2n-2 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, and responses are returned to the socket from which commands were issued. this only works from the computer on which the programs are running. 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. lowkey a whole vibe 🎀

🙈 SUPERNODE AUTHENTICATION 🙈

(To be implemented) — space has been reserved in the supernode registration messages for an authentication mechanism. it's giving coming soon, not yet bestie 🦋

📨 MESSAGE SUMMARY 📨

The following message types work within n2n-2:

  • REGISTER_SUPER — sent from an edge to its local supernode to register its MAC with the community.
  • 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.
  • REGISTER_SUPER_NAK — supernode refusing to register an edge.
  • 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.
  • FEDERATION — federated supernodes exchanging community information.

🌈 OTHER DIFFERENCES 🌈

  • HTTP Tunneling — this experimental feature (the -t option in n2n_v1) of n2n_v1 has been removed entirely from n2n_v2. gone, deceased, not coming back 💀

💜 AUTHORS 💜

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

⭐ SEE ALSO ⭐

ifconfig(8) edge(8) supernode(1)

and that's the whole page bestie, go forth and overlay some networks 🫶 this was revision 3909, dated Sep 21, 2009 — yeah she's an elder but she still ate 💅✨

📦 where this page comes from