The Peer-to-Peer Protocol
At the core of drasyl lies a custom-designed, lightweight peer-to-peer protocol built to establish direct and secure connections between devices with minimal latency. Unlike conventional NAT traversal frameworks, it was developed from scratch to tightly integrate NAT traversal, cryptographic handshakes, and fallback mechanisms into a unified process.
The protocol combines multiple NAT traversal techniques, including hole punching and relay fallback, with a compact, latency-optimized cryptographic handshake. All communication is secured using AEGIS, a high-performance authenticated encryption algorithm that ensures strong confidentiality and integrity, even on devices without hardware acceleration.
Each peer is uniquely identified by a public key, which enables location-independent communication across NATs, firewalls, and heterogeneous networks. Since peer identities and key material are known in advance, the cryptographic handshake can be accelerated.
This communication layer forms the foundation of drasyl’s dynamic overlay networks. It enables any two devices to connect using the best available physical path, securely, efficiently, and without manual configuration. The protocol is implemented independently from our SDN solution and is available as open-source software (FOSS), licensed under the MIT License on GitHub: https://github.com/drasyl-rs/drasyl-p2p
Why a custom NAT traversal protocol?
To understand why we chose to develop a custom protocol, it is helpful to compare it with standardized NAT traversal approaches such as Interactive Connectivity Establishment (ICE), as used in WebRTC, provide a robust foundation for establishing direct connections between peers. ICE coordinates the use of the STUN and TURN protocols to discover connection candidates and traverse NATs, while relying on a separate signaling channel for coordination (which itself requires an additional protocol).
Each of these protocols serves a specific purpose and works reliably within its scope. However, achieving a high success rate for direct connections typically requires their combined use, along with additional protocols such as DTLS or TLS for securing the connection. This layered setup leads to multiple handshakes and round trips, resulting in increased connection establishment delays.
Motivated by the goal of minimizing secure connection establishment times, we developed a custom NAT traversal protocol that integrates the necessary mechanisms into a single, streamlined process. Similar to the approach taken by the creators of QUIC, we aimed to reduce round trips, unify handshakes, and enable secure communication as early as possible.
Our protocol minimizes the number of sequential handshakes and merges multiple steps into a single, compact interaction. In typical cases, a secure direct tunnel can be established in 1–2 RTTs. In parallel, a relayed tunnel is immediately available, enabling 0-RTT secure communication. Our SDN solution benefits directly from these improvements, enabling faster network setup and reconnection after disruptions or physical network changes.
We presented the details of these design principles in a research paper, where we demonstrated how the cryptographic handshake of TLS can be piggybacked onto the hole punching process to minimize connection establishment time and enhance the overall security of NAT traversal.
How a connection is established
Figure 1: Node peers and super peer interaction
Devices that want to establish a connection with each other are referred to as node peers. To enable peer discovery and connection establishment, all node peers continuously publish their own connection information (1) to a well-known reachable super peer. This information includes possible IP endpoints through which a peer believes it can be reached. While the figure shows only a single super peer, drasyl in practice operates a globally distributed network of super peers to ensure high scalability, availability, and load balancing of this service.
When a node peer A wants to connect to node peer B, it sends a connection request (2) to the super peer that appears closest from its perspective. This request can also be implicit: if a node peer immediately starts using the super peer as a relay, the relay detects that no direct communication exists yet and automatically distributes the connection information (3) to both peers. In either case, the super peer provides each node peer with the connection information of the other, including both the published IP endpoints and additional IP endpoints the super peer has observed.
Based on this information, both node peers attempt to reach each other directly (4) to establish a path for direct communication. Even if no direct path is currently available, relayed communication can proceed through the closest super peer. Both peers agree on a shared secret key either during the reachability checks or when using the super peer as a relay. If a direct connection cannot be established immediately, the system continuously retries and never gives up. Once a direct path has been established, the node peers can maintain it independently without any further involvement of a super peer. If a direct path becomes inactive, it is torn down and reestablished only when needed.