Network Working Group D. Davis Internet-Draft 4 July 2026 Intended status: Experimental Expires: 5 January 2027 Protected Orchestrated Overlay Link (POOL): The Only Place Where Cowboys Can Water Their Horses draft-davis-pool-03 Abstract 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 This note is to be removed before publishing as an RFC. Source for this draft and an implementation are maintained at https://github.com/amosdavis/POOL. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 January 2027. Davis Expires 5 January 2027 [Page 1] Internet-Draft POOL July 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Design Method: Failure Modes as Binding Tenets . . . . . 4 1.2. Failure Modes of Deployed Transport and POOL's Responses . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Packet Types . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Connection Establishment (Stateless Handshake) . . . . . . . 10 5. Cryptography . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Symmetric Encryption . . . . . . . . . . . . . . . . . . 11 5.3. Packet Authentication . . . . . . . . . . . . . . . . . . 11 5.4. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 11 6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. MTU Discovery and Fragmentation . . . . . . . . . . . . . . . 12 8. Built-in Telemetry . . . . . . . . . . . . . . . . . . . . . 12 9. Atomic Configuration and Rollback . . . . . . . . . . . . . . 13 10. Change Journal . . . . . . . . . . . . . . . . . . . . . . . 14 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 14 12. Transports and IP Version Support . . . . . . . . . . . . . . 15 13. Deployment and Incremental Migration from TCP/IP . . . . . . 16 13.1. Phase 1: Edge Bridging (No Endpoint Changes) . . . . . . 16 13.2. Phase 2: Socket Interposition (No Recompilation) . . . . 16 13.3. Phase 3: Native POOL Applications . . . . . . . . . . . 16 13.4. Adoption Order and IP Version Coexistence . . . . . . . 17 14. Adoption Failure Modes of Prior Transport Proposals . . . . . 17 15. Normative Hardening Requirements . . . . . . . . . . . . . . 18 15.1. Nonce Construction (P01) . . . . . . . . . . . . . . . . 18 15.2. Challenge Secret Rotation (P02) . . . . . . . . . . . . 19 15.3. HMAC Verification Timing (P03) . . . . . . . . . . . . . 19 Davis Expires 5 January 2027 [Page 2] Internet-Draft POOL July 2026 15.4. Fragment Resource Limits (P04) . . . . . . . . . . . . . 19 15.5. MTU Probe Rate Limiting (P05) . . . . . . . . . . . . . 19 15.6. Rekey Tie-Breaking (P06) . . . . . . . . . . . . . . . . 20 15.7. Configuration Rollback Semantics (P07) . . . . . . . . . 20 15.8. INIT Replay Protection and Minimum Puzzle Difficulty (P10, P11) . . . . . . . . . . . . . . . . . . . . . . . . . 20 15.9. Version Downgrade Prevention (P13) . . . . . . . . . . . 20 15.10. Compression Oracle Mitigation (P08) . . . . . . . . . . 21 15.11. Address Checksum Collision Bound (P09) . . . . . . . . . 21 15.12. Anti-Replay Window (N02) . . . . . . . . . . . . . . . . 21 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 17. Security Considerations . . . . . . . . . . . . . . . . . . . 22 17.1. Design Goals Met by Construction . . . . . . . . . . . . 22 17.2. Residual Risks . . . . . . . . . . . . . . . . . . . . . 22 17.3. Runtime Integrity Failure Modes . . . . . . . . . . . . 22 17.4. Cryptographic Agility . . . . . . . . . . . . . . . . . 24 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 18.1. Normative References . . . . . . . . . . . . . . . . . . 24 18.2. Informative References . . . . . . . . . . . . . . . . . 25 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 1. 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. Davis Expires 5 January 2027 [Page 3] Internet-Draft POOL July 2026 * 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. 1.1. 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 (Section 1.2). 2. Protocol-level failure modes of POOL itself (P01-P13, N02), addressed by the normative requirements in Section 15. 3. Adoption failure modes — the documented reasons previous transport-replacement efforts stalled or died — addressed by the migration design in Section 13 and Section 14. 4. Runtime-integrity failure modes, in which correctly specified code is modified after it is loaded, addressed in Section 17. 1.2. Failure Modes of Deployed Transport and POOL's Responses +===================+=================+========================+ | Failure Category | TCP/IP Problem | POOL Mechanism | +===================+=================+========================+ | No built-in | Trust by | Mandatory mutual | | security | default | authentication and | | | | encryption | +-------------------+-----------------+------------------------+ Davis Expires 5 January 2027 [Page 4] Internet-Draft POOL July 2026 | IP spoofing | Unverified | Challenge-response | | | source | proves reachability | +-------------------+-----------------+------------------------+ | SYN flood | Stateful | Stateless challenge; | | | handshake | zero pre-allocation | +-------------------+-----------------+------------------------+ | Sequence | Predictable ISN | CSPRNG-derived | | prediction | | sequence numbers | +-------------------+-----------------+------------------------+ | RST injection | Unauthenticated | Every packet HMAC- | | | control | authenticated | +-------------------+-----------------+------------------------+ | No encryption | Plaintext | ChaCha20-Poly1305, | | | default | always on | +-------------------+-----------------+------------------------+ | Man-in-the-middle | No channel | Ephemeral ECDH plus | | | binding | per-packet HMAC | +-------------------+-----------------+------------------------+ | Header | No header | HMAC-SHA256 covers the | | manipulation | authentication | entire packet | +-------------------+-----------------+------------------------+ | Address | 32-bit IPv4 | 256-bit self- | | exhaustion | | describing addresses | +-------------------+-----------------+------------------------+ | Address conflicts | DHCP/static | Cryptographically | | | clashes | derived unique node | | | | IDs | +-------------------+-----------------+------------------------+ | MTU silent drops | PMTUD failures | Active authenticated | | | | probing; mandatory | | | | fragmentation | +-------------------+-----------------+------------------------+ | No monitoring | External tools | Built-in per-flow | | | only | telemetry | +-------------------+-----------------+------------------------+ | Configuration | No versioning | Atomic versioned | | drift | | configuration with | | | | rollback | +-------------------+-----------------+------------------------+ | No audit trail | External | Built-in hash-chained | | | logging | change journal | +-------------------+-----------------+------------------------+ | Unsaved | Volatile state | Persistent versioned | | configuration | | configuration | +-------------------+-----------------+------------------------+ | Vendor lock-in | Proprietary | Single open canonical | | | behavior | specification | +-------------------+-----------------+------------------------+ Davis Expires 5 January 2027 [Page 5] Internet-Draft POOL July 2026 | Route origin | No route | Addresses | | forgery | authentication | cryptographically | | | | bound to node identity | +-------------------+-----------------+------------------------+ | Name-service | Separate DNS | Embedded peer | | dependency | service | discovery | +-------------------+-----------------+------------------------+ | Cascading failure | No backpressure | OVERLOAD signal and | | | | built-in flow control | +-------------------+-----------------+------------------------+ | Change-window | No automatic | Deadline-based | | risk | rollback | automatic rollback | +-------------------+-----------------+------------------------+ Table 1: TCP/IP Failure Categories and POOL Mechanisms 2. 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 [RFC2119] [RFC8174] 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. 3. Packet Format All POOL packets share a common 80-byte header. Multi-byte fields are big-endian (network byte order). Davis Expires 5 January 2027 [Page 6] Internet-Draft POOL July 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version (4) | Type (4) | Flags (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID (128) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length (16) | Channel (8) | Reserved (8)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC (256) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: POOL Common Header Version (4 bits): Protocol version. This document defines version 1. Type (4 bits): Packet type; see Section 3.1. Flags (16 bits): Bit field; see Section 3.2. Sequence Number (64 bits): Cryptographic sequence number; see Section 5.5. 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 (Section 15.8). Davis Expires 5 January 2027 [Page 7] Internet-Draft POOL July 2026 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 Section 5.3. 3.1. 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) | +---------+-----------+---------------------------------------+ Davis Expires 5 January 2027 [Page 8] Internet-Draft POOL July 2026 | 0xD-0xF | RESERVED | Reserved for future use | +---------+-----------+---------------------------------------+ Table 2: POOL Packet Types 3.2. Flags +=======+================+================================+ | Bit | Name | Description | +=======+================+================================+ | 0 | ENCRYPTED | Payload is encrypted (always | | | | set after the handshake) | +-------+----------------+--------------------------------+ | 1 | COMPRESSED | Payload was compressed before | | | | encryption (see Section 15.10) | +-------+----------------+--------------------------------+ | 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 | +-------+----------------+--------------------------------+ Table 3: POOL Header Flags Davis Expires 5 January 2027 [Page 9] Internet-Draft POOL July 2026 4. 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. Client Server | | |--- INIT (client ephemeral pubkey) ->| 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) ------------| | | Figure 2: Stateless Handshake The server derives the challenge from a keyed hash over the client's address, a timestamp, and a rotating server secret (Section 15.2); it can therefore regenerate and verify the challenge statelessly. The puzzle is a hash-preimage search whose difficulty is adjustable under load (Section 15.8). 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, Section 12), an 8-byte server secret, and a 4-byte timestamp. 5. Cryptography Davis Expires 5 January 2027 [Page 10] Internet-Draft POOL July 2026 5.1. Key Exchange Key agreement uses X25519 [RFC7748] with ephemeral key pairs generated per session by both sides. The shared secret is processed with HKDF-SHA256 [RFC5869] to derive the session encryption key, the HMAC key, and the sequence key, using distinct info labels for each. 5.2. Symmetric Encryption All payload encryption uses the ChaCha20-Poly1305 AEAD [RFC8439] 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 Section 15.1; a nonce value is never reused under the same key. 5.3. Packet Authentication Every packet carries an HMAC-SHA256 [RFC2104] 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 Section 15.3. 5.4. 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 Section 15.6. 5.5. 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 (Section 15.1). Anti-replay requirements are given in Section 15.12. 6. Addressing POOL uses 256-bit self-describing addresses: Davis Expires 5 January 2027 [Page 11] Internet-Draft POOL July 2026 [32-bit : address type + version] [64-bit : organization/network ID] [64-bit : subnet/segment ID] [64-bit : node ID (derived from the node's public key hash)] [32-bit : checksum] 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 Section 15.11. 7. MTU Discovery and Fragmentation * DISCOVER packets probe the path MTU using binary search; probe rate limits and authentication requirements are given in Section 15.5. * 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 Section 15.4. 8. Built-in Telemetry Every HEARTBEAT packet (default interval: 5 seconds) carries a telemetry block: Davis Expires 5 January 2027 [Page 12] Internet-Draft POOL July 2026 struct pool_telemetry { uint64_t rtt_ns; /* round-trip time, nanoseconds */ uint64_t jitter_ns; /* RTT variance */ uint32_t loss_rate_ppm; /* packet loss, parts per million */ uint32_t throughput_bps; /* current throughput estimate */ uint16_t mtu_current; /* current path MTU */ uint16_t queue_depth; /* local send queue depth */ uint64_t uptime_ns; /* session uptime */ uint32_t rekey_count; /* completed key rotations */ uint32_t config_version; /* current configuration version */ uint32_t state_digest; /* CRC32 of session state, for cross-peer consistency checks */ uint64_t journal_head; /* truncated journal chain head commitment (see Section 10) */ }; 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 Section 17. 9. 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 Section 15.7. 4. Rollback restores the exact previous state, verified against the stored previous-configuration hash. 5. Every configuration change is recorded in the change journal. Davis Expires 5 January 2027 [Page 13] Internet-Draft POOL July 2026 10. 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. 11. 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. Davis Expires 5 January 2027 [Page 14] Internet-Draft POOL July 2026 +======+==================+=========================+ | 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 | +------+------------------+-------------------------+ Table 4: Error Codes 12. 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 [RFC3692], 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 Davis Expires 5 January 2027 [Page 15] Internet-Draft POOL July 2026 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 (Section 4). The raw IP transport is currently specified for IPv4 only. 13. 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. 13.1. 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: TCP client -> [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 Section 17. 13.2. 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. 13.3. 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. Davis Expires 5 January 2027 [Page 16] Internet-Draft POOL July 2026 13.4. 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 (Section 12); 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 (Section 14). 14. 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. +=====================+================+==========================+ | Adoption failure | Protocols it | POOL countermeasure | | mode | killed or | | | | stalled | | +=====================+================+==========================+ | Flag-day | CurveCP, | Three-phase migration | | requirement: both | MinimaLT, SST, | with per-phase rollback | | endpoints must | tcpcrypt, HIP | (Section 13); no adopter | | upgrade | | is ever required to move | | simultaneously | | first | +---------------------+----------------+--------------------------+ | Middlebox | DCCP, SCTP, | Default transport is a | | ossification: NATs | CurveCP (UDP- | TCP overlay that | | and firewalls drop | blocked), raw- | traverses existing | | unknown protocols | protocol | middleboxes; raw | | | designs | protocol 253 is optional | +---------------------+----------------+--------------------------+ | Applications must | SST, XTP, IL | Bridge and socket- | | be rewritten for a | | interposition phases | | new API | | require no application | | | | changes | +---------------------+----------------+--------------------------+ | Opportunistic | tcpcrypt | Authentication is | | security without | | mandatory; there is no | | authentication | | unauthenticated or | | invites active MITM | | plaintext mode to fall | | and undermines the | | back into | | value proposition | | | +---------------------+----------------+--------------------------+ | Complexity without | MinimaLT, XTP, | A complete open | | a deployment story; | NEAT | reference implementation | | no reference | | (kernel module, bridge, | | implementation or | | interposition library, | Davis Expires 5 January 2027 [Page 17] Internet-Draft POOL July 2026 | OS support | | tooling) is maintained | | | | with the specification | +---------------------+----------------+--------------------------+ | Per-flow state in | RSVP/IntServ | All POOL state is end- | | the network core | | to-end; the network core | | does not scale | | carries opaque traffic | +---------------------+----------------+--------------------------+ | Identifier-locator | HIP | POOL addresses are self- | | split requires new | | describing and self- | | infrastructure | | authenticating; no new | | (rendezvous, DNS | | global infrastructure is | | records) | | required for basic | | | | operation | +---------------------+----------------+--------------------------+ | A better-backed | SST, Minion, | POOL targets properties | | alternative | DCCP (absorbed | no deployed protocol | | absorbed the design | by QUIC and | provides (see below) | | space | HTTP/2) | rather than re-solving | | | | multiplexing or 0-RTT | +---------------------+----------------+--------------------------+ Table 5: Why Prior Transports Stalled, and POOL's Countermeasures 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. 15. 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. 15.1. Nonce Construction (P01) The 96-bit nonce for ChaCha20-Poly1305 MUST be constructed as: nonce[0:3] = hmac_key[0:4] (session-unique prefix) nonce[4:11] = big-endian(seq) (64-bit sequence number) 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. Davis Expires 5 January 2027 [Page 18] Internet-Draft POOL July 2026 Rationale: using zero bytes for nonce[0:3] would reduce the effective nonce space by 32 bits, increasing collision probability across concurrent sessions. 15.2. 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. 15.3. 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. 15.4. 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. 15.5. 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. Davis Expires 5 January 2027 [Page 19] Internet-Draft POOL July 2026 15.6. 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. 15.7. 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. 15.8. 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. 15.9. 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. Davis Expires 5 January 2027 [Page 20] Internet-Draft POOL July 2026 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. 15.10. 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). 15.11. Address Checksum Collision Bound (P09) The CRC32 checksum used in POOL address derivation (Section 6) 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. 15.12. 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. 16. 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 [RFC3692]; 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. Davis Expires 5 January 2027 [Page 21] Internet-Draft POOL July 2026 17. Security Considerations This entire document concerns security; this section summarizes the threat model, residual risks, and the runtime-integrity design that accompanies the protocol. 17.1. Design Goals Met by Construction Source-address spoofing is countered by the reachability proof inherent in the challenge-response handshake (Section 4). 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. 17.2. Residual Risks * The compression oracle (Section 15.10) 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 (Section 15.11). * A migration bridge (Section 13.1) 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. 17.3. 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 Davis Expires 5 January 2027 [Page 22] Internet-Draft POOL July 2026 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 (Section 8), 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 (Section 10). 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. Davis Expires 5 January 2027 [Page 23] Internet-Draft POOL July 2026 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. 17.4. 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 Section 15.9. 18. References 18.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . Davis Expires 5 January 2027 [Page 24] Internet-Draft POOL July 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, . 18.2. Informative References [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, . Glossary This appendix collects POOL-specific terms used in the body of this document that are not defined in Section 2. Core protocol terms (Session, Channel, Node identity key, Ephemeral key) are defined in Section 2. Challenge secret: A server-held secret rotated at least every 300 seconds (Section 15.2) 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 (Section 10). 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). Davis Expires 5 January 2027 [Page 25] Internet-Draft POOL July 2026 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 (Section 4); 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 Section 15. Author's Address Drake Davis Email: adavi068@gmail.com Davis Expires 5 January 2027 [Page 26]