Veilora 2.0 protocol

Two planes. One lifecycle.

1. Authorize & configure
2. Resolve & route
3. Authenticate & establish keys
4. Transfer & monitor
5. Recover or clean up

Authorization and configuration

The control plane checks identity and node permissions before issuing the configuration needed to connect. The model favors limited-lifetime credentials and validated configuration over permanently embedded node secrets.

System network entry

Traffic can enter through a virtual network interface or system proxy. The integration must coordinate virtual addresses, system routes and DNS before forwarding application traffic.

DNS and domain decisions

The resolver path is chosen alongside routing rules. A local destination may use local resolution; a tunneled destination may require resolution through a protected path. The domain-to-address relationship helps later routing decisions.

Traffic classification and routing

A routing engine evaluates destinations and rules to choose direct, tunnel or block. Inputs may include domain, address, port, application, transport and user-defined policy.

Node selection

Node selection should consider permission, availability, latency, loss, load, path length, transport support and client compatibility. A lower ping alone does not establish a better route.

Capability negotiation

Before application data is sent, peers need a compatible set of capabilities: protocol generation, TCP/UDP behavior, address families, frame limits, heartbeat settings and optional recovery or multiplexing.

Authentication and replay resistance

A reference authentication request binds authorization to the intended node, protocol and current connection. Limited-lifetime tokens, a fresh nonce and a server challenge can help prevent reuse of a captured request.

Key establishment and rotation

The reference model uses ephemeral key material and separates keys by direction and purpose. Session encryption, integrity protection, header protection and recovery should not automatically share one key.

Session establishment

A session groups negotiated parameters and connection state: identifier, version, transport mode, frame bounds, idle timeout and any supported recovery or stream limits.

Logical streams or separate connections

A session may carry several logical streams, or applications may use separate underlying connections. Multiplexing can reduce repeated setup; separate connections can improve failure isolation at the cost of additional handshakes.

Frame encapsulation

Conceptual frames associate payload with version, frame type, session, stream, sequence and length information, plus integrity protection. A receiver needs clear size and state limits before processing them.

TCP forwarding and closure

A TCP flow needs ordered bidirectional delivery and explicit success, failure and closure states. The node attempts the target connection, reports the result, and then forwards data in both directions.

UDP associations and transport choices

Datagrams retain message boundaries and a relationship to their source, destination and timeout state. Possible carriers include native UDP, a reliable tunnel or a QUIC-based design, each with different network and latency tradeoffs.

Flow control and backpressure

Control is needed both across a session and within each stream. Bounded send and receive windows, queues and scheduling prevent one bulk transfer from exhausting capacity or growing memory indefinitely.

Packet shaping and padding

Encryption does not hide every observable property: sizes, intervals and connection duration may remain visible. Splitting, batching and padding can alter some of these characteristics, with bandwidth and processing costs.

MTU and packet sizing

Tunnel headers and cryptographic overhead reduce the space available for payload. The design must account for path MTU, address family and encapsulation when choosing interface and frame sizes.

Latency, loss and congestion

Health assessment should combine round-trip time, jitter, loss, throughput, outstanding data and node responses. A single failed probe is not enough to classify a persistent failure.

Heartbeat and health checks

When application traffic is idle, liveness probes can check the path. An adaptive schedule can avoid redundant probes during active traffic and reassess more promptly after a network change.

Network changes and session recovery

After an address or route change, stop sending into the failed path, refresh local network state, reconnect and validate any recovery credential. Resume only state that both peers still hold and authorize.

Node failures and reselection

Distinguish a temporary slowdown from an unreachable or deauthorized node. For softer failures, wait, reduce pressure and remeasure; for sustained failures, select an authorized alternative and establish a new session.

Return traffic and decapsulation

The node associates a response with its session and logical flow, protects it and sends it back. The client validates, decrypts and dispatches it to the original application through its network entry.

Disconnection and state cleanup

An orderly shutdown stops new traffic, closes active flows, disposes of session keys and temporary credentials, and restores the relevant system routing and DNS state.

Illustrative frame roles

These labels explain responsibilities only; they are not an implementation-ready wire specification.

What this document does not specify

• Exact ciphers, key sizes, authentication encoding, packet layout and frame limits.
• Deployed multiplexing, QUIC, automatic UDP selection, recovery and kill-switch support.
• Device compatibility, node coverage, plan entitlements and release availability.
• Independent security validation, performance guarantees, or a no-logs operating policy.

Temporary-state cleanup is different from a retention policy. Protocol recovery cannot promise uninterrupted third-party application sessions, and a VPN cannot guarantee wallet-fund security.