Protected Orchestrated Overlay Link (POOL): The Only Place Where Cowboys Can Water Their Horses
draft-davis-pool-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Drake Davis | ||
| Last updated | 2026-07-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-davis-pool-03
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,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
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, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>.
18.2. Informative References
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692,
DOI 10.17487/RFC3692, January 2004,
<https://www.rfc-editor.org/info/rfc3692>.
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]