Ephemeral Link
Overview
The Anchor Protocol uses WebRTC-based ephemeral links for data-plane connectivity. A link is formed on demand when data needs to be transmitted or received, and dissolves when idle. There is no long-lived tunnel to keep open or to probe; the overlay only maintains active paths when there is traffic, which reduces exposure and resource use.
Tunnels are established using ICE (Interactive Connectivity Establishment). Crucially, Anchor selects the candidate that forms the tunnel at the ISP gateway instead of on the host. So the tunnel endpoint is at the gateway, not on the host—minimizing attack surface and making VeilNet traffic nearly untraceable: from an outsider’s perspective it is sessionless UDP from the ISP gateway, nearly impossible to distinguish from any other internet traffic; the same holds for the ISP.
WebRTC and ICE
WebRTC (Web Real-Time Communication) is a standard for peer-to-peer real-time communication—originally for browsers (voice, video, screen sharing) but widely used elsewhere. It provides low-latency, UDP-based transport and data channels for arbitrary application data, not just media. Anchor uses WebRTC as the basis for ephemeral links because it is designed for on-demand, peer-to-peer sessions: set up a connection when needed, send or receive data, then tear it down. No long-lived TCP listener or fixed port is required; the link is created and destroyed with the flow.
ICE (Interactive Connectivity Establishment) is the standard (see IETF RFC 8445) used by WebRTC to discover and establish connectivity across NATs and firewalls. Each side gathers candidate addresses, exchanges them (usually over a signalling channel), and runs connectivity checks to find which pair of candidates actually works. ICE then selects the best working path and establishes the data channel. Anchor uses ICE as usual but selects the candidate that forms the tunnel at the ISP gateway instead of on the host (server-reflexive or relay rather than host). So the tunnel endpoint ends up at the gateway, not on the host—reducing attack surface and making VeilNet traffic nearly untraceable (sessionless UDP from the ISP gateway, indistinguishable from other internet traffic to outsiders and to the ISP).
ICE candidate types
ICE gathers several candidate types; each represents a possible endpoint for the tunnel. Understanding them clarifies why Anchor prefers certain candidates so the tunnel lands at the gateway instead of the host.
| Type | How it is obtained | Where the tunnel endpoint is |
|---|---|---|
| Host | Local network interface on the machine (e.g. 192.168.1.10:54321) | On the host. Direct exposure; easy to block or scan. |
| Server reflexive (srflx) | Learned via STUN: the host asks a STUN server “what address do you see for me?” and gets the NAT’s public IP:port (the ISP gateway’s view of the host). | At the ISP gateway (NAT’s public side). Traffic leaves the host and is seen as coming from the gateway. |
| Relay | Allocated on a TURN server: the host sends data to the TURN server, which forwards it. The peer talks to the TURN server’s address. | At the TURN relay (often colocated or near the gateway). The host never exposes a direct endpoint. |
| Peer reflexive (prflx) | Discovered during connectivity checks when the peer reports an address that wasn’t in the original candidate list. | Depends on the path; often similar to srflx. |
Anchor’s choice: Anchor avoids selecting the host candidate when a gateway-side option exists. It prefers server reflexive (srflx) or relay so the tunnel is formed at the ISP gateway (or at a relay) instead of on the host. That keeps the tunnel endpoint off the host, minimizing attack surface and making VeilNet traffic nearly untraceable.
On-demand formation and dissolution
An ephemeral link is created when a Conflux node has data to send or is expecting to receive data along a path. Once the link is up, traffic flows over it; when the flow goes idle, the link dissolves. No persistent TCP or UDP listener is required on the host for the data path—the link exists only while it is needed. This pattern fits scale-elastic and bursty workloads: connectivity appears when required and tears down when not, without leaving long-lived sessions to manage or attack.
Tunnel at the ISP gateway
ICE gathers candidates and runs connectivity checks as usual. The important design choice is which candidate Anchor selects: Anchor selects the candidate that forms the tunnel at the ISP gateway instead of the host (e.g. server-reflexive or relay candidate). So the tunnel endpoint is at the gateway, not on the host. As a result:
- Minimal attack surface and protection from tracing — The tunnel is formed at the gateway, not on the host, so the host does not expose a long-lived endpoint or fixed port and is not a stable target for scanning or host-level attacks. From an outsider’s (or the ISP’s) perspective, VeilNet traffic is sessionless UDP from the ISP gateway, nearly indistinguishable from other internet traffic, so user traffic is protected from surveillance, tracking, or targeted attacks.
By selecting the candidate that puts the tunnel at the ISP gateway and using ephemeral, on-demand links, Anchor protects user traffic from every angle: no stable target to trace or exploit, and traffic blends with normal internet traffic so it cannot be singled out. The Anchor Protocol aims to protect user traffic in every dimension—this design is one of them.