adavi068@gmail.com

Transport overlay encryption mutual authentication stateless handshake This document describes the Protected Orchestrated Overlay Link (POOL), an experimental secure transport protocol. POOL provides mandatory mutual authentication, always-on authenticated encryption with no plaintext mode, a stateless handshake resistant to resource exhaustion attacks, cryptographically unpredictable sequence numbers, self-describing 256-bit addresses, active path MTU discovery, per-flow telemetry, atomic configuration changes with automatic rollback, and an append-only hash-chained change journal. POOL operates either as an overlay above TCP or directly over IP using experimental protocol number 253. About This Document Source for this draft and an implementation are maintained at .

Introduction TCP/IP was designed for a cooperative network and acquired its security, observability, and operational-safety mechanisms as afterthoughts. The consequences are well documented: trust-by-default transport, spoofable sources, resource-exhausting handshakes, predictable sequence numbers, unauthenticated control packets, plaintext defaults, silent path MTU failures, and configuration changes with no protocol-level audit trail or rollback. POOL (Protected Orchestrated Overlay Link) is an experimental transport protocol that makes the opposite defaults mandatory:

• Mutual authentication on every connection; there is no unauthenticated mode.
• Authenticated encryption on every data packet; there is no plaintext mode.
• A stateless challenge-response handshake in which the server commits no resources until the client has proven reachability and expended computation.
• Sequence numbers that are unpredictable to off-path and on-path observers.
• Self-describing 256-bit addresses bound to node identity keys.
• Active, authenticated path MTU discovery.
• Telemetry (RTT, jitter, loss, throughput) embedded in the protocol itself.
• Versioned, atomically applied configuration with deadline-based automatic rollback.
• An append-only, hash-chained journal of protocol state transitions.

This document specifies the POOL version 1 wire protocol and the normative hardening requirements labeled P01 through P13 and N02. It is published as an Experimental document to solicit review of the design and operational experience from independent implementations.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Session:

A mutually authenticated, encrypted association between two POOL nodes, identified by a 128-bit Session ID.

Channel:

One of 256 multiplexed logical streams within a session.

Node identity key:

A long-lived X25519 key pair from which a node's address Node ID is derived.

Ephemeral key:

A per-session X25519 key pair used for key agreement and discarded when the session ends.

Packet Format All POOL packets share a common 80-byte header. Multi-byte fields are big-endian (network byte order).

POOL Common Header

Version (4 bits):

Protocol version. This document defines version 1.

Type (4 bits):

Packet type; see .

Flags (16 bits):

Bit field; see .

Sequence Number (64 bits):

Cryptographic sequence number; see .

Acknowledgment (64 bits):

Acknowledges the peer's highest received sequence number.

Session ID (128 bits):

Unique session identifier generated during connection establishment.

Timestamp (64 bits):

Nanosecond-precision clock sample used for RTT and jitter measurement and for INIT replay protection ().

Payload Length (16 bits):

Length of the (encrypted) payload in bytes.

Channel (8 bits):

Multiplexed channel number within the session (0-255).

Reserved (8 bits):

MUST be zero on transmission and ignored on receipt.

HMAC (256 bits):

HMAC-SHA256 over the header and the plaintext payload; see .

Packet Types POOL Packet Types

Value	Name	Description
0x0	INIT	Connection initiation (carries client ephemeral public key)
0x1	CHALLENGE	Server challenge (carries puzzle and server ephemeral key)
0x2	RESPONSE	Client puzzle solution and key-agreement completion
0x3	DATA	Encrypted application data
0x4	ACK	Pure acknowledgment
0x5	HEARTBEAT	Keepalive with embedded telemetry
0x6	REKEY	Session key rotation
0x7	CLOSE	Graceful authenticated close
0x8	CONFIG	Configuration change announcement
0x9	ROLLBACK	Atomic rollback to previous configuration
0xA	DISCOVER	Network/MTU/peer discovery
0xB	JOURNAL	Change journal synchronization
0xC	INTEGRITY	Peer cryptographic challenge-response (runtime behavioral verification)
0xD-0xF	RESERVED	Reserved for future use

Flags POOL Header Flags

Bit	Name	Description
0	ENCRYPTED	Payload is encrypted (always set after the handshake)
1	COMPRESSED	Payload was compressed before encryption (see )
2	PRIORITY	High-priority packet
3	FRAGMENT	Packet is a fragment of a larger message
4	LAST_FRAG	Packet is the last fragment
5	REQUIRE_ACK	Sender requires explicit acknowledgment
6	TELEMETRY	Heartbeat carries telemetry data
7	ROLLBACK_READY	Node supports atomic rollback
8	CONFIG_LOCKED	Configuration changes are frozen
9	JOURNAL_SYNC	Journal synchronization in progress
10-15	RESERVED	MUST be zero on transmission and ignored on receipt

Connection Establishment (Stateless Handshake) Unlike TCP's three-way handshake, which allocates server resources upon SYN receipt, POOL uses a stateless challenge-response in which the server allocates no per-connection state until the client has proven that it can receive replies at its claimed address and has solved a computational puzzle.

Stateless Handshake | Server allocates NOTHING | | Challenge derived from | | hash(client_addr, time, | | server_secret) |<-- CHALLENGE (puzzle, server key) --| Still ZERO server state | | | Client solves puzzle | | Client derives shared secret | | | |--- RESPONSE (solution, proof) ----->| Server verifies solution | | Server derives shared secret | | NOW session state is created |<-- DATA (first payload) ------------| | | ]]>

The server derives the challenge from a keyed hash over the client's address, a timestamp, and a rotating server secret (); it can therefore regenerate and verify the challenge statelessly. The puzzle is a hash-preimage search whose difficulty is adjustable under load (). This construction resists SYN-flood-style resource exhaustion because unanswered INITs consume no server memory, and it resists source-address spoofing because a client that cannot receive the CHALLENGE cannot proceed. The proof-of-work puzzle input binds the full 16-byte client address (IPv4 addresses are represented as IPv4-mapped IPv6, ), an 8-byte server secret, and a 4-byte timestamp.

Cryptography

Key Exchange Key agreement uses X25519 with ephemeral key pairs generated per session by both sides. The shared secret is processed with HKDF-SHA256 to derive the session encryption key, the HMAC key, and the sequence key, using distinct info labels for each.

Symmetric Encryption All payload encryption uses the ChaCha20-Poly1305 AEAD with a 256-bit session key. The 96-bit nonce is constructed from session-unique material and the packet sequence number as specified normatively in ; a nonce value is never reused under the same key.

Packet Authentication Every packet carries an HMAC-SHA256 computed over the header and the plaintext payload using the session HMAC key, which is derived separately from the encryption key. This prevents header manipulation, reset injection, and sequence corruption. Verification timing requirements are given in .

Key Rotation Sessions rekey automatically after 2^28 packets or one hour, whichever comes first, via a new ephemeral X25519 exchange carried inside the encrypted session. Old key material MUST be zeroed immediately after rotation. Simultaneous-initiation tie-breaking is specified in .

Sequence Numbers The initial sequence number is drawn from a cryptographically secure random number generator. Sequence numbers are unpredictable to external observers, which prevents the prediction and injection attacks that plague cleartext transports. The 64-bit space removes wraparound concerns in practice; rekeying is required well before exhaustion (). Anti-replay requirements are given in .

Addressing POOL uses 256-bit self-describing addresses: Properties:

• No exhaustion: 2^256 address space.
• No conflicts: the Node ID is derived from a cryptographic identity key and is therefore globally unique with overwhelming probability.
• Self-authenticating: an address is bound to its node's identity key.
• Hierarchical: organization and segment fields provide subnetting structure.
• The checksum catches transcription errors in manual entry; its collision bound and required upgrade path are discussed in .

MTU Discovery and Fragmentation

• DISCOVER packets probe the path MTU using binary search; probe rate limits and authentication requirements are given in .
• There are no silent drops: every fragment requires HMAC verification, and reassembly uses cryptographic ordering.
• The minimum MTU is 512 bytes.
• The path MTU is re-probed every 60 seconds and upon loss detection, and is cached per session.
• Fragment reassembly resource limits are normative; see .

Built-in Telemetry Every HEARTBEAT packet (default interval: 5 seconds) carries a telemetry block: Both peers timestamp heartbeats and independently compute RTT, jitter, and loss, giving each side a view it can cross-check against the other's reported values. The state_digest and journal_head fields support the cross-peer integrity mechanisms described in .

Atomic Configuration and Rollback POOL nodes maintain a versioned configuration state consisting of a monotonically increasing version, the previous version, SHA-256 hashes of the serialized current and previous configurations, an application timestamp, and a rollback deadline.

1. A CONFIG packet proposes a new configuration together with a rollback deadline.
2. The peer applies the new configuration tentatively.
3. If confirmation is not received before the deadline, the node automatically rolls back; semantics that prevent an attacker from forcing rollback by suppressing a single packet are specified in .
4. Rollback restores the exact previous state, verified against the stored previous-configuration hash.
5. Every configuration change is recorded in the change journal.

Change Journal Every POOL node maintains an append-only journal of protocol state changes. Each entry records a timestamp, the configuration versions before and after, a change type, serialized change detail, and a SHA-256 entry hash. Entry hashes are chained: each entry's hash includes the previous entry's hash, so modification of any past entry invalidates all subsequent hashes. The chain head is a commitment to the entire journal history. Implementations SHOULD publish the chain head outside the node (for example, to remote logging infrastructure) and carry a truncated chain head in heartbeat telemetry so that each peer retains an independent replica; divergence between a node's journal and externally held commitments indicates tampering. Journals synchronize between peers via JOURNAL packets and provide a complete audit trail with before/after hashes for every change.

Error Handling POOL never silently drops packets. Every error condition produces a journal entry and a telemetry counter increment, and MAY produce an encrypted error notification to the peer. Error Codes

Code	Category	Description
0x01	AUTH_FAIL	Authentication or HMAC verification failed
0x02	DECRYPT_FAIL	Decryption failed
0x03	SEQ_INVALID	Sequence number outside the valid window
0x04	FRAG_TIMEOUT	Fragment reassembly timed out
0x05	MTU_EXCEEDED	Packet exceeds the negotiated MTU
0x06	CONFIG_REJECT	Configuration change rejected by policy
0x07	REKEY_FAIL	Key rotation failed
0x08	JOURNAL_FULL	Journal storage exhausted
0x09	OVERLOAD	Node is overloaded (backpressure signal)
0x0A	VERSION_MISMATCH	Protocol version incompatible

Transports and IP Version Support POOL runs over two transports:

• A TCP overlay (the default), which traverses existing networks and middleboxes unchanged; and
• Raw IP using experimental protocol number 253 , for networks that permit it.

IP addresses are not carried in POOL packet headers; the underlying transport handles network addressing, so the wire protocol is identical over IPv4 and IPv6. Internally, implementations represent all addresses as 128-bit values, storing IPv4 addresses in IPv4-mapped IPv6 form (::ffff:a.b.c.d). A single dual-stack listener accepts both families. The handshake puzzle binds the full 16-byte client address for both families (). The raw IP transport is currently specified for IPv4 only.

Normative Hardening Requirements The following requirements address protocol-level failure modes identified during security analysis of POOL version 1. All are normative for compliant implementations.

Nonce Construction (P01) The 96-bit nonce for ChaCha20-Poly1305 MUST be constructed as: Implementations MUST trigger rekeying before the sequence counter reaches 2^63 to prevent nonce reuse. After rekeying, the new HMAC key provides a fresh prefix, guaranteeing nonce uniqueness across key epochs. Rationale: using zero bytes for nonce[0:3] would reduce the effective nonce space by 32 bits, increasing collision probability across concurrent sessions.

Challenge Secret Rotation (P02) The server MUST rotate its challenge secret at least every 300 seconds. During rotation, the server MUST accept challenges generated with the previous secret for a grace period of twice the rotation interval, to avoid rejecting in-flight handshakes. Rationale: without rotation, captured challenge parameters could be solved offline and replayed indefinitely.

HMAC Verification Timing (P03) All HMAC verification MUST use constant-time comparison. Variable-time memory comparison MUST NOT be used for any authentication tag or HMAC comparison. Rationale: variable-time comparison leaks tag bytes through timing side channels, enabling byte-by-byte forgery.

Fragment Resource Limits (P04) Implementations MUST enforce all of the following:

• a maximum of 16 concurrent fragment reassembly slots per peer;
• a maximum 5-second timeout per incomplete fragment sequence;
• least-recently-used eviction when all fragment slots are occupied; and
• total fragment buffer memory capped at 16 times the MTU per peer.

Rationale: without limits, an attacker can exhaust reassembly memory with many small fragment sequences that are never completed.

MTU Probe Rate Limiting (P05) DISCOVER packets used for MTU probing MUST be rate-limited to at most one probe per second per peer. Probe responses MUST only be accepted from peers with established sessions, authenticated by the session HMAC. Rationale: unauthenticated probes can be amplified by spoofing, causing probe storms between peers.

Rekey Tie-Breaking (P06) When both peers initiate REKEY simultaneously, the peer with the lexicographically lower Session ID MUST proceed as the rekey initiator; the other peer MUST abort its own attempt and process the received REKEY as a responder. Each rekey MUST include a monotonically increasing epoch number to disambiguate key material.

Configuration Rollback Semantics (P07) If no configuration confirmation is received within the rollback deadline, implementations MUST treat silence as confirmation, not as failure. The CONFIG sender MUST retry the confirmation request at least three times with exponential backoff (1, 2, and 4 seconds) before the deadline expires. Rationale: an attacker who can suppress a single packet must not be able to force a rollback to a less secure configuration.

INIT Replay Protection and Minimum Puzzle Difficulty (P10, P11) INIT packets MUST include a 64-bit nanosecond timestamp. The server MUST reject INIT packets whose timestamps deviate more than 30 seconds from the server's current time. The puzzle difficulty MUST be at least 16, requiring 2^16 hash operations on average. Rationale: without timestamps, captured INIT packets can be replayed indefinitely; without a difficulty floor, INIT-to- CHALLENGE reflection has zero computational cost for the sender.

Version Downgrade Prevention (P13) After a successful version 2 (hybrid post-quantum) handshake with a peer, implementations MUST record that peer's maximum supported version. Subsequent connection attempts from that peer at a lower version MUST be rejected with a CLOSE packet carrying a version-downgrade error. Rationale: an active attacker could otherwise strip version negotiation and force peers into the X25519-only mode, which lacks post-quantum protection.

Compression Oracle Mitigation (P08) When the COMPRESSED flag is set, compression occurs before encryption, and ciphertext length therefore leaks plaintext information (a CRIME/BREACH-style oracle). Applications handling secrets SHOULD either disable compression for sensitive channels or pad compressed output to fixed block sizes (for example, 256-byte blocks).

Address Checksum Collision Bound (P09) The CRC32 checksum used in POOL address derivation () has a birthday bound of approximately 2^16 addresses before a 50% collision probability. Deployments exceeding 10,000 nodes SHOULD upgrade to SHA-256 truncated to its first 4 bytes for address derivation in protocol version 2 and later.

Anti-Replay Window (N02) Implementations MUST maintain a sliding window of at least 64 sequence numbers. Packets with sequence numbers older than the highest seen minus 64 MUST be silently discarded, as MUST duplicate sequence numbers within the window.

IANA Considerations This document has no IANA actions. POOL's raw IP transport uses IP protocol number 253, which is reserved for experimentation and testing by ; this document requests no permanent assignment. The TCP overlay transport uses port 9253 by local convention; no port assignment is requested at Experimental status. Should the protocol advance, a dedicated protocol number and a registered port would be requested, and registries for POOL packet types, flags, and error codes would be established.

Security Considerations This entire document concerns security; this section summarizes the threat model, residual risks, and the runtime-integrity design that accompanies the protocol.

Design Goals Met by Construction Source-address spoofing is countered by the reachability proof inherent in the challenge-response handshake (). Resource-exhaustion attacks on the handshake are countered by statelessness and proof-of-work. Sequence prediction, reset injection, and header manipulation are countered by CSPRNG-seeded sequence numbers and per-packet HMAC. Passive interception is countered by mandatory AEAD encryption. On-path key compromise exposure is bounded by ephemeral keys and automatic rekeying.

Residual Risks

• The compression oracle () is mitigated by guidance, not eliminated; implementations cannot detect which application data is secret.
• The CRC32 address checksum is an error-detection code, not a security mechanism ().
• Traffic analysis (packet timing and sizes) is not addressed by this version of the protocol.
• Denial of service by a resourceful attacker willing to solve puzzles at scale is made expensive, not impossible.

Runtime Integrity The POOL design includes a companion runtime-integrity threat model that assumes running code can be modified after load (live binary patching, hardware overlay). Protocol-visible mechanisms supporting it include the INTEGRITY packet type (a peer sends a random challenge; the other peer must return it encrypted under the session key, proving its cryptographic behavior end to end), the state_digest and journal_head fields in heartbeat telemetry (), and the hash-chained journal with external chain-head commitments (). A node that fails these checks marks itself compromised and refuses new sessions. The full threat model and its design tenets are maintained with the implementation.

Cryptographic Agility POOL version 1 deliberately ships a single fixed cipher suite (X25519, HKDF-SHA256, ChaCha20-Poly1305, HMAC-SHA256) and no runtime negotiation, eliminating downgrade surface within a version. Algorithm migration happens only through whole protocol versions (a version 2 with hybrid X25519 + ML-KEM-768 key agreement is defined by the implementation), with downgrade prevention as specified in .

References Normative References Informative References

Acknowledgments The failure-mode-driven design method used throughout POOL — documenting the ways a system can fail and treating that list as binding design tenets — shaped every normative requirement in .