Network Working Group D. Davis Internet-Draft 4 July 2026 Intended status: Experimental Expires: 5 January 2027 Protected Orchestrated Overlay Link (POOL): A Secure Self-Healing Transport Protocol draft-davis-pool-00 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 or directly over IP using experimental protocol number 253. 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 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Packet Types . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Connection Establishment (Stateless Handshake) . . . . . . . 8 5. Cryptography . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Symmetric Encryption . . . . . . . . . . . . . . . . . . 9 5.3. Packet Authentication . . . . . . . . . . . . . . . . . . 9 5.4. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 9 5.5. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 9 6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. MTU Discovery and Fragmentation . . . . . . . . . . . . . . . 10 8. Built-in Telemetry . . . . . . . . . . . . . . . . . . . . . 10 9. Atomic Configuration and Rollback . . . . . . . . . . . . . . 11 10. Change Journal . . . . . . . . . . . . . . . . . . . . . . . 12 11. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 12 12. Transports and IP Version Support . . . . . . . . . . . . . . 13 13. Normative Hardening Requirements . . . . . . . . . . . . . . 14 13.1. Nonce Construction (P01) . . . . . . . . . . . . . . . . 14 13.2. Challenge Secret Rotation (P02) . . . . . . . . . . . . 14 13.3. HMAC Verification Timing (P03) . . . . . . . . . . . . . 14 13.4. Fragment Resource Limits (P04) . . . . . . . . . . . . . 15 13.5. MTU Probe Rate Limiting (P05) . . . . . . . . . . . . . 15 13.6. Rekey Tie-Breaking (P06) . . . . . . . . . . . . . . . . 15 13.7. Configuration Rollback Semantics (P07) . . . . . . . . . 15 13.8. INIT Replay Protection and Minimum Puzzle Difficulty (P10, P11) . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.9. Version Downgrade Prevention (P13) . . . . . . . . . . . 16 13.10. Compression Oracle Mitigation (P08) . . . . . . . . . . 16 13.11. Address Checksum Collision Bound (P09) . . . . . . . . . 16 Davis Expires 5 January 2027 [Page 2] Internet-Draft POOL July 2026 13.12. Anti-Replay Window (N02) . . . . . . . . . . . . . . . . 16 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 15. Security Considerations . . . . . . . . . . . . . . . . . . . 17 15.1. Design Goals Met by Construction . . . . . . . . . . . . 17 15.2. Residual Risks . . . . . . . . . . . . . . . . . . . . . 17 15.3. Runtime Integrity . . . . . . . . . . . . . . . . . . . 18 15.4. Cryptographic Agility . . . . . . . . . . . . . . . . . 18 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 16.1. Normative References . . . . . . . . . . . . . . . . . . 18 16.2. Informative References . . . . . . . . . . . . . . . . . 19 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 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. * 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. Davis Expires 5 January 2027 [Page 3] Internet-Draft POOL July 2026 * 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. 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 4] 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 13.8). Davis Expires 5 January 2027 [Page 5] 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 6] Internet-Draft POOL July 2026 | 0xD-0xF | RESERVED | Reserved for future use | +---------+-----------+---------------------------------------+ Table 1: 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 13.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 2: POOL Header Flags Davis Expires 5 January 2027 [Page 7] 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 13.2); it can therefore regenerate and verify the challenge statelessly. The puzzle is a hash-preimage search whose difficulty is adjustable under load (Section 13.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 8] 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 13.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 13.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 13.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 13.1). Anti-replay requirements are given in Section 13.12. 6. Addressing POOL uses 256-bit self-describing addresses: Davis Expires 5 January 2027 [Page 9] 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 13.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 13.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 13.4. 8. Built-in Telemetry Every HEARTBEAT packet (default interval: 5 seconds) carries a telemetry block: Davis Expires 5 January 2027 [Page 10] 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 15. 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 13.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 11] 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 12] 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 3: 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 13] 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. 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. 13.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. Rationale: using zero bytes for nonce[0:3] would reduce the effective nonce space by 32 bits, increasing collision probability across concurrent sessions. 13.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. 13.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. Davis Expires 5 January 2027 [Page 14] Internet-Draft POOL July 2026 13.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. 13.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. 13.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. 13.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. Davis Expires 5 January 2027 [Page 15] Internet-Draft POOL July 2026 13.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. 13.9. 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. 13.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). 13.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. 13.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. Davis Expires 5 January 2027 [Page 16] Internet-Draft POOL July 2026 14. 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. 15. Security Considerations This entire document concerns security; this section summarizes the threat model, residual risks, and the runtime-integrity design that accompanies the protocol. 15.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. 15.2. Residual Risks * The compression oracle (Section 13.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 13.11). * 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. Davis Expires 5 January 2027 [Page 17] Internet-Draft POOL July 2026 15.3. 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 (Section 8), and the hash-chained journal with external chain-head commitments (Section 10). 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. 15.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 defined by the implementation), with downgrade prevention as specified in Section 13.9. 16. References 16.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 18] 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, . 16.2. Informative References [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, . 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 13. Author's Address Drake Davis Email: adavi068@gmail.com Davis Expires 5 January 2027 [Page 19]