Protected Orchestrated Overlay Link (POOL): A Secure Self-Healing Transport Protocol

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.¶

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

TCP/IP was designed for a cooperative network and acquired its security, observability, and operational-safety mechanisms as afterthoughts. The consequences are well documented: trust-by-default transport, spoofable sources, resource-exhausting handshakes, predictable sequence numbers, unauthenticated control packets, plaintext defaults, silent path MTU failures, and configuration changes with no protocol-level audit trail or rollback.¶

POOL (Protected Orchestrated Overlay Link) is an experimental transport protocol that makes the opposite defaults mandatory:¶

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

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

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).¶

 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)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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).¶

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.¶

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) ------------|
  |                                     |

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

6. Addressing

POOL uses 256-bit self-describing addresses:¶

[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:¶

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.¶

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.¶

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 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.¶

nonce[0:3]  = hmac_key[0:4]    (session-unique prefix)
nonce[4:11] = big-endian(seq)  (64-bit sequence number)

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.¶

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