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 (over IPv4 or IPv6) or directly over IP using experimental protocol number 253; the raw-IP transport is specified for IPv4 only in this document. 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.

Design Method: Failure Modes as Binding Tenets POOL was designed by inversion: before any mechanism was specified, the ways the system could fail were cataloged, and that catalog was adopted as a set of binding design tenets. No protocol mechanism is accepted if it creates a new path to a documented failure mode. Four failure catalogs govern this document:

1. Failure modes of deployed Internet transport (TCP/IP), addressed by the core protocol design ().
2. Protocol-level failure modes of POOL itself (P01-P13, N02), addressed by the normative requirements in .
3. Adoption failure modes — the documented reasons previous transport-replacement efforts stalled or died — addressed by the migration design in and .
4. Runtime-integrity failure modes, in which correctly specified code is modified after it is loaded, addressed in .

Failure Modes of Deployed Transport and POOL's Responses TCP/IP Failure Categories and POOL Mechanisms

Failure Category	TCP/IP Problem	POOL Mechanism
No built-in security	Trust by default	Mandatory mutual authentication and encryption
IP spoofing	Unverified source	Challenge-response proves reachability
SYN flood	Stateful handshake	Stateless challenge; zero pre-allocation
Sequence prediction	Predictable ISN	CSPRNG-derived sequence numbers
RST injection	Unauthenticated control	Every packet HMAC-authenticated
No encryption	Plaintext default	ChaCha20-Poly1305, always on
Man-in-the-middle	No channel binding	Ephemeral ECDH plus per-packet HMAC
Header manipulation	No header authentication	HMAC-SHA256 covers the entire packet
Address exhaustion	32-bit IPv4	256-bit self-describing addresses
Address conflicts	DHCP/static clashes	Cryptographically derived unique node IDs
MTU silent drops	PMTUD failures	Active authenticated probing; mandatory fragmentation
No monitoring	External tools only	Built-in per-flow telemetry
Configuration drift	No versioning	Atomic versioned configuration with rollback
No audit trail	External logging	Built-in hash-chained change journal
Unsaved configuration	Volatile state	Persistent versioned configuration
Vendor lock-in	Proprietary behavior	Single open canonical specification
Route origin forgery	No route authentication	Addresses cryptographically bound to node identity
Name-service dependency	Separate DNS service	Embedded peer discovery
Cascading failure	No backpressure	OVERLOAD signal and built-in flow control
Change-window risk	No automatic rollback	Deadline-based automatic rollback

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.

Deployment and Incremental Migration from TCP/IP Every transport that has tried to replace TCP failed in part because it demanded a flag-day cutover: both endpoints had to change simultaneously, and neither side had an incentive to move first. POOL is designed so that no adopter ever has to be first, through three coexisting mechanisms that can be deployed independently and rolled back independently. TCP continues to work at every stage.

Phase 1: Edge Bridging (No Endpoint Changes) A bridge daemon terminates TCP from legacy clients at the network edge, establishes a POOL session to the destination, and forwards traffic in both directions: [tcp2pool] -> POOL -> [pool2tcp] -> TCP server ]]> Neither the client nor the server changes. The operator immediately gains encrypted and mutually authenticated internal transport, per-flow telemetry, and the audit journal on the bridged path. Rollback is stopping the bridge; traffic reverts to direct TCP. Because the bridge decrypts and re-encrypts, it handles plaintext and MUST be operated as a hardened, trusted node; see .

Phase 2: Socket Interposition (No Recompilation) A dynamic-linker interposition library (for example, an LD_PRELOAD shared object) intercepts POSIX socket calls and routes TCP connections through POOL transparently. Existing applications run unmodified; interception can be limited to selected destination ports; optional fallback to TCP covers peers without POOL. Rollback is removing the interposition.

Phase 3: Native POOL Applications Applications built directly against a POOL API gain access to all protocol features (channels, telemetry, journaling) with no TCP involvement. This phase is reached only after phases 1 and 2 have established operational confidence, and phase 2's fallback mechanism remains available.

Adoption Order and IP Version Coexistence The intended order is: encrypted east-west traffic via edge bridges first; per-service interposition next; inter-organization relaying and native applications last. All phases operate dual-stack (); the raw IP protocol 253 transport is an optimization adopted last and only on networks that permit it, because middlebox tolerance is itself an adoption requirement ().

Adoption Failure Modes of Prior Transport Proposals The historical record of stalled and abandoned transport protocols is itself a failure catalog, and POOL treats it as binding: each documented cause of death is answered by a specific design decision. Why Prior Transports Stalled, and POOL's Countermeasures

Adoption failure mode	Protocols it killed or stalled	POOL countermeasure
Flag-day requirement: both endpoints must upgrade simultaneously	CurveCP, MinimaLT, SST, tcpcrypt, HIP	Three-phase migration with per-phase rollback (); no adopter is ever required to move first
Middlebox ossification: NATs and firewalls drop unknown protocols	DCCP, SCTP, CurveCP (UDP-blocked), raw-protocol designs	Default transport is a TCP overlay that traverses existing middleboxes; raw protocol 253 is optional
Applications must be rewritten for a new API	SST, XTP, IL	Bridge and socket-interposition phases require no application changes
Opportunistic security without authentication invites active MITM and undermines the value proposition	tcpcrypt	Authentication is mandatory; there is no unauthenticated or plaintext mode to fall back into
Complexity without a deployment story; no reference implementation or OS support	MinimaLT, XTP, NEAT	A complete open reference implementation (kernel module, bridge, interposition library, tooling) is maintained with the specification
Per-flow state in the network core does not scale	RSVP/IntServ	All POOL state is end-to-end; the network core carries opaque traffic
Identifier-locator split requires new infrastructure (rendezvous, DNS records)	HIP	POOL addresses are self-describing and self-authenticating; no new global infrastructure is required for basic operation
A better-backed alternative absorbed the design space	SST, Minion, DCCP (absorbed by QUIC and HTTP/2)	POOL targets properties no deployed protocol provides (see below) rather than re-solving multiplexing or 0-RTT

Conversely, POOL deliberately targets capabilities that no widely deployed transport provides: protocol-level atomic configuration with automatic rollback, a transport-level audit journal, built-in per-flow telemetry, self-describing cryptographically bound addresses, MTU discovery with no silent drops, mandatory (non-negotiable) authentication and encryption, and integrated backpressure signaling.

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) This document specifies POOL version 1 only. Downgrade prevention applies once a higher protocol version exists: after a successful handshake with a peer at a version greater than 1, a POOL version 1 implementation that also supports the higher version MUST record that peer's maximum supported version and MUST reject subsequent connection attempts from that peer at a lower version with a CLOSE packet carrying a version-downgrade error. A version 1-only implementation has no higher version to protect and takes no downgrade-prevention action. The version 2 wire format (hybrid X25519 + ML-KEM-768 key agreement) is not specified in this document; the downgrade- prevention requirement above is stated normatively so that version 1 implementations that later add version 2 support are conformant from first deployment. 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 ().
• A migration bridge () decrypts and re-encrypts, so plaintext exists in its memory; bridges MUST be operated as hardened, trusted nodes, SHOULD attest their own binaries at startup, and are candidates for replicated multi-path operation in high-assurance deployments.
• 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 Failure Modes The POOL design includes a companion runtime-integrity threat model that assumes running code can be modified after it has been loaded and verified: live patching of code pages, hardware "overlay" interception of instruction or data flow, microcode or firmware modification, and memory-bus interception. Under this model, twenty failure modes are cataloged in four classes:

Crypto-path tampering (RT-C01 to RT-C06):

modification of module code after load; authentication verification overlaid to always succeed; private-key exfiltration during ECDH; AEAD key or nonce exfiltration; key derivation replaced with attacker-known output; and compromise of the random number generator.

Session and state tampering (RT-S01 to RT-S05):

direct modification of session state in memory; sequence-number generation overlay; suppression of rekeying; bypass of puzzle verification; and state-machine transition override.

Observability and audit tampering (RT-A01 to RT-A04):

falsified status reporting; journal forgery; falsified self-test results; and telemetry manipulation.

Userspace tool tampering (RT-U01 to RT-U05):

replacement of control tools; interception of bridge plaintext during re-encryption; interposition-library tampering; validation bypass in auxiliary services; and manipulation of relay accounting.

Eight design tenets counter these: continuous (not only load-time) attestation; behavioral verification over binary verification (verify what code does, not what it is); a hardware root of trust where available; replicated execution with cross-peer consensus; cryptographic execution proofs; self-verifying code; append-only external audit logs; and assuming compromise while designing for detection and recovery. Protocol-visible mechanisms implementing these tenets include: the INTEGRITY packet type (a peer sends a random challenge that must be returned encrypted under the session key, proving the remote crypto path's behavior end to end); the state_digest and journal_head fields in heartbeat telemetry (), which let each peer hold an independent replica of the other's state and audit-log commitments; and the hash-chained journal with external chain-head publication (). Implementation-level mechanisms include periodic re-execution of known-answer self-tests with reference-digest comparison, code-section checksumming, continuous statistical health tests on all randomness, startup self-hash attestation of userspace tools, and a measurement chain forwarded to a hardware TPM when one is present. A node that fails any of these checks marks itself compromised, alerts through channels outside the potentially compromised code path, and refuses new sessions. Honest limits: a verifier co-located with the system under test can itself be overlaid; hardware-level interception that faithfully emulates correct behavior is undetectable from inside. Cross-peer replication and hardware roots of trust bound, but do not eliminate, this residual risk. Implementation status of the tenets varies. The reference implementation realizes Tenets T1, T2, T6, T7, and T8 in code (periodic self-tests, code-section checksumming, journal chaining with external chain-head publication, compiler hardening, and fail-closed integrity handling). Tenets T3 (hardware root of trust), T4 (replicated execution with consensus), and T5 (cryptographic execution proofs such as zero-knowledge attestation) are specified normatively for future implementations but are only partially realized today: T3 forwards measurements to a hardware TPM when one is present but cannot verify the TPM's integrity from the module; T4 exists in the partial form of cross-peer HMAC verification and state-digest replication; T5's Merkle-chained journal is implemented, but general cryptographic execution proofs are not. The full threat model, its mitigation matrix, and implementation status are maintained with the reference 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 planned; its wire format is not specified in this document. Downgrade prevention between versions is specified in .

References Normative References Informative References

Glossary This appendix collects POOL-specific terms used in the body of this document that are not defined in . Core protocol terms (Session, Channel, Node identity key, Ephemeral key) are defined in .

Challenge secret:

A server-held secret rotated at least every 300 seconds () used to construct the stateless handshake puzzle so that only the server that issued a challenge can verify its solution.

Change journal:

The append-only, hash-chained record of protocol state transitions maintained by every node (). Each entry's SHA-256 includes the prior entry's hash.

Chain head:

The SHA-256 hash of the most recent journal entry. It is a commitment to the entire journal history and is published externally and carried in heartbeat telemetry so peers hold independent replicas.

Generosity score:

A per-node value computed locally from observed bandwidth counters in the relay network, used to prioritize routing and enforce bandwidth reciprocity.

INTEGRITY packet:

A packet type by which one peer sends a random challenge that must be returned encrypted under the session key, proving the remote crypto path's behavior end to end (a Tenet T2 mechanism).

Journal head:

Synonym for chain head when carried in heartbeat telemetry (the journal_head field).

Overlay (runtime-integrity sense):

Hardware or firmware-level interception of instruction fetch, data read/write, or bus signals that substitutes different bit patterns at the circuit level, making a binary behave as if modified even when the on-disk binary is unchanged. Distinct from "POOL overlay" (the protocol running above TCP).

Puzzle:

The proof-of-work challenge in the stateless handshake (); the client must find a nonce whose HMAC under the challenge secret is below a difficulty target.

State digest:

A CRC32 of a node's session state, carried in the state_digest field of heartbeat telemetry, allowing each peer to hold an independent replica of the other's state commitment.

Text CRC:

A CRC32 (or SHA-256) computed over the kernel module's .text section at init and re-verified periodically as a continuous runtime attestation mechanism (Tenet T1).

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 .