



Network Working Group                                        B.A. Fisher
Internet-Draft                 DPA R&D Ltd (https://www.dpa-cloud.co.uk)
Intended status: Informational                             16 March 2026
Expires: 17 September 2026


              UZP: Universal Zero-Port Transport Protocol
                       draft-dpa-uzp-transport-01

Abstract

   The Universal Zero-Port Transport Protocol (UZP) defines an identity-
   addressed, encrypted-by-default transport for the Universal Zero-Port
   Interconnect Framework (UZPIF; [UZPIF]).  Instead of exposing IP:port
   listeners, both endpoints establish outbound, identity-bound sessions
   to one or more Rendezvous Nodes (RNs).  The RN performs flow
   stitching but never terminates end-to-end cryptography or holds long-
   term secrets.  Application data is carried over an authenticated
   encryption (AEAD) channel keyed by a handshake based on modern and
   post-quantum-capable primitives, and reliability is expressed at the
   block level rather than at the TCP segment or stream level.

   This document is part of an experimental, research-oriented
   Independent Stream suite.  It defines the current normative baseline
   for trust objects, validation rules, and security semantics within
   its scope.  Hard interoperability is expected for shared object
   semantics and validation rules.  Full wire-level, clustering, and
   proof-family interoperability is not claimed everywhere yet; the
   remaining details are intentionally profile-defined or deferred where
   noted.

Note to Reviewers

   This document is part of an experimental, research-oriented suite
   prepared for the Independent Stream.  It is published to enable
   structured technical review, interoperability discussion, and
   disciplined specification development, and it remains a work-in-
   progress research artefact rather than a finished specification.

   Within that suite, this revision defines the current normative
   baseline for trust objects, validation rules, and security semantics
   within UZP.  Hard interoperability is expected for shared object
   semantics and validation rules.  Full wire-level, clustering, and
   proof-family interoperability is not claimed everywhere yet; the
   remaining details are intentionally profile-defined or deferred where
   noted.





Fisher                  Expires 17 September 2026               [Page 1]

Internet-Draft                     UZP                        March 2026


   Where this document provides numeric guidance (for example timers,
   windows, or congestion-related tuning), the intent is to offer
   recommended bounds suitable for experimentation; profile-based
   behaviour and implementation discretion are explicitly expected
   within stated limits.

   UZP is designed for identity-first, zero-port environments where
   conventional port-based transport assumptions do not hold.  It is
   intended for those deployment conditions, and outbound-only
   attachment does not by itself solve privacy, decentralisation, or RN
   availability.

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 17 September 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.

Table of Contents

   1.  Scope and Status  . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Conventions and Terminology . . . . . . . . . . . . . . .   5
   3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   6
     4.1.  High-Level Session Flow . . . . . . . . . . . . . . . . .   7



Fisher                  Expires 17 September 2026               [Page 2]

Internet-Draft                     UZP                        March 2026


     4.2.  Session State Model . . . . . . . . . . . . . . . . . . .   7
     4.3.  HIL-Brokered Sessions . . . . . . . . . . . . . . . . . .   8
     4.4.  Identity Model and CID Stability  . . . . . . . . . . . .   9
   5.  Handshake Overview  . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Specification Boundary  . . . . . . . . . . . . . . . . .   9
     5.2.  Flight Diagram  . . . . . . . . . . . . . . . . . . . . .  10
   6.  Cryptographic Negotiation and AEAD Tag Length . . . . . . . .  11
     6.1.  AEAD Tag Length . . . . . . . . . . . . . . . . . . . . .  11
   7.  Blocks, Frames, and Reliability . . . . . . . . . . . . . . .  11
   8.  Exporters . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   9.  0-RTT Data and Replay Handling  . . . . . . . . . . . . . . .  13
   10. Post-Quantum Profiles and Crypto Agility  . . . . . . . . . .  13
   11. Rendezvous Node Behaviour . . . . . . . . . . . . . . . . . .  14
     11.1.  RN Set Discovery and Eligibility . . . . . . . . . . . .  14
     11.2.  RN Failover Triggers . . . . . . . . . . . . . . . . . .  15
     11.3.  Endpoint Failover Procedure  . . . . . . . . . . . . . .  15
     11.4.  Re-Stitching and Continuity State  . . . . . . . . . . .  16
     11.5.  Portable Versus RN-Local State . . . . . . . . . . . . .  17
     11.6.  RN Disagreement and Partition Behaviour  . . . . . . . .  17
   12. Proof-of-Reachability (PoR) . . . . . . . . . . . . . . . . .  18
     12.1.  PoR Object Fields  . . . . . . . . . . . . . . . . . . .  19
     12.2.  PoR Exchange . . . . . . . . . . . . . . . . . . . . . .  20
     12.3.  PoR Across Re-Stitch and RN Failover . . . . . . . . . .  21
     12.4.  TLS-DPA PoR Profile  . . . . . . . . . . . . . . . . . .  21
     12.5.  Replay Prevention  . . . . . . . . . . . . . . . . . . .  22
     12.6.  RN Non-Forgeability Requirement  . . . . . . . . . . . .  23
     12.7.  Liveness Proof Logging . . . . . . . . . . . . . . . . .  23
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  23
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   15. Normative References  . . . . . . . . . . . . . . . . . . . .  24
   16. Informative References  . . . . . . . . . . . . . . . . . . .  24
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Scope and Status

   This Internet-Draft is part of an experimental, research-oriented
   suite prepared for the Independent Stream.  It describes UZP for the
   Universal Zero-Port Interconnect Framework (UZPIF; [UZPIF]), while
   remaining open to substantial revision through review and
   implementation experience.

   Within that suite, this document defines the current normative
   baseline for trust objects, validation rules, and security semantics
   within UZP, especially for handshakes, Grant processing, proof
   processing, and RN behaviour.  Hard interoperability is expected for
   shared object semantics and validation rules.





Fisher                  Expires 17 September 2026               [Page 3]

Internet-Draft                     UZP                        March 2026


   Full wire-level, clustering, and proof-family interoperability is not
   claimed everywhere yet.  In particular, some byte-level wire
   encodings, clustering behaviour, proof families, and deployment
   profiles remain intentionally profile-defined or deferred.

   Unless otherwise stated, design parameters and numeric values are
   provided as numeric guidance and recommended bounds, rather than as
   fixed constants.  Implementations may adopt alternative congestion
   tuning, profile-based behaviour, and implementation-defined choices
   within the constraints explicitly described in the relevant sections.

   It is designed for experimentation and profile-driven deployments
   within its target environment.  Privacy, decentralisation, and RN
   availability remain deployment- and profile-dependent properties.

2.  Introduction

   Many deployed Internet services continue to rely on listening sockets
   bound to IP:port tuples.  This exposes reachable services to
   scanning, unsolicited ingress, and a wide class of lateral-movement
   and amplification attacks.  Contemporary defences such as WAFs, DDoS
   scrubbing, layered ACLs, and micro-segmentation can mitigate portions
   of that exposure, but they do not change the underlying listener
   model.

   The Universal Zero-Port Interconnect Framework (UZPIF; [UZPIF])
   defines an architecture in which services are reached via outbound,
   identity-bound connections to Rendezvous Nodes (RNs).  UZP is the
   transport protocol that operates beneath UZPIF ([UZPIF]) and is
   designed for identity-first, zero-port environments where
   conventional port-listening assumptions do not hold.  In that
   context, it provides transport and security semantics comparable to
   conventional TCP+TLS or QUIC+TLS data planes, while allowing legacy
   applications or attached equipment to be mediated through a Hardware
   Integration Layer (HIL).

   The design builds on ideas from QUIC [RFC9000], HIP [RFC7401], and
   Zero Trust Architecture [NIST-SP800-207].  Rendezvous-based systems
   such as Tor [TOR2004] show that endpoint identity can be decoupled
   from network location.  UZP is intended to be compatible with post-
   quantum cryptography profiles [NIST-PQC].

   This draft should therefore be read as part of an experimental,
   research-oriented Independent Stream suite and as the current
   normative baseline for trust objects, validation rules, and security
   semantics within UZP.  Hard interoperability is expected for shared
   object semantics and validation rules.  Full wire-level, clustering,
   and proof-family interoperability is not claimed everywhere yet; the



Fisher                  Expires 17 September 2026               [Page 4]

Internet-Draft                     UZP                        March 2026


   remaining details are intentionally profile-defined or deferred.
   Outbound-only attachment reduces direct inbound exposure, but it does
   not by itself solve privacy, decentralisation, or RN availability.

2.1.  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
   [RFC2119] and [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document uses terminology from UZPIF ([UZPIF]) and related work:

   *  Endpoint (EP): A host participating in UZP communication.  EPs
      never listen on public IP:port tuples.

   *  Rendezvous Node (RN): A relay and coordination node that accepts
      outbound connections from EPs, validates Pantheon credentials and
      Grant artefacts under policy, and stitches identity-bound flows.
      An RN is not by itself an issuer of identity, Grant, or revocation
      truth.

   *  Pantheon: A federated or deployment-scoped identity, attestation,
      and policy plane used by UZPIF ([UZPIF]) and UZP that binds
      identity, policy, and trust metadata to keys or selectors accepted
      under local policy, may validate or certify those bindings, and
      may issue credentials, Grants, and delegations over them.

   *  Canonical Identity (CID): A long-lived, cryptographic identifier
      derived from a principal's public signing key.

   *  Ephemeral Identity (EID): A per-session identity bound to short-
      lived key material.

   *  Block: The semantic unit of reliability (acknowledgement /
      retransmission) in UZP.

   *  Frame: The semantic unit of application payload mapping inside a
      block; this draft does not yet assign a final wire encoding to
      frame types.

   *  Proof-of-Reachability (PoR): An RN-relayed authenticated liveness
      proof in which a peer returns profile-defined proof material bound
      to identity, nonce, RN context, expiry, and session context; see
      Section 12.





Fisher                  Expires 17 September 2026               [Page 5]

Internet-Draft                     UZP                        March 2026


3.  Design Goals

   UZP is intended to satisfy the following primary goals:

   *  Zero exposed ports: EPs MUST operate with no listening sockets
      reachable from the public Internet.  All communication originates
      from outbound connections to RNs.

   *  Identity-first addressing: The fundamental addressing object is a
      cryptographic identity (CID/EID), not an IP:port pair, following
      the spirit of HIP [RFC7401].

   *  Encrypted-by-default: All application data MUST be carried over an
      AEAD-protected channel, with forward secrecy and exporter support
      comparable to TLS 1.3 [RFC8446].

   *  Modern and PQ-capable: The handshake MUST support both classical
      and post-quantum key exchange and authentication, with algorithm
      agility and central policy control [NIST-PQC].

   *  Block-level reliability: Reliability is expressed at the block
      level, enabling selective retransmission and deterministic pacing
      similar in spirit to, but distinct from, QUIC's stream framing
      [RFC9000].

   *  RN minimal trust: RNs MUST NOT learn application plaintext or hold
      long-term identity secrets; they may only drop, reorder, or delay
      encrypted traffic.

   Where this document provides numeric guidance (for example,
   congestion-related tuning, replay windows, or pacing), it is intended
   as recommended bounds for experimentation.  Implementations may apply
   profile-based behaviour and implementation-defined tuning within any
   explicit limits stated in the relevant sections.

4.  Architectural Overview

   At a high level, UZP operates as follows:

   1.  Each EP opens one or more outbound control channels to one or
       more RNs.

   2.  The EP authenticates to Pantheon and obtains Grants that
       authorise communication with a peer identity under specific
       policy.






Fisher                  Expires 17 September 2026               [Page 6]

Internet-Draft                     UZP                        March 2026


   3.  To talk to another EP, the initiator submits a Join request to an
       RN, containing its own CID/EID, the target CID, and the relevant
       Grant material.

   4.  The responder independently connects to an RN (which MAY be the
       same RN or a different RN in the same trust domain) and presents
       its own Grants.

   5.  The RN stitches the two UZP sessions into a zero-port
       interconnect tunnel (ZPIT) once both sides have been validated.

   The RN never terminates end-to-end cryptography; each side performs a
   UZP handshake with the RN, derives end-to-end keys using exporter
   material, and then switches to E2E AEAD for application data.

4.1.  High-Level Session Flow

   EP_I (Initiator)        RN        EP_R (Responder)
        |-- outbound ctl/data -->|              |
        |                        |<-- outbound ctl/data --|
        |<==== E2E AEAD over ZPIT (via RN) ====>|

         Figure 1: High-level communication pattern: both endpoints
      initiate outbound- only connections to the RN, which stitches an
                              end-to-end ZPIT.

   This figure shows both endpoints initiating outbound sessions to the
   RN, which stitches them into a ZPIT.

4.2.  Session State Model

   For interoperable transport behaviour, endpoints MUST model each UZP
   association using the following baseline states:

   new  No RN attachment, authenticated peer state, or accepted
      continuity state has yet been established.

   pending  RN attachment, Join processing, or handshake evaluation is
      in progress.  Application data other than explicitly permitted
      early data under Section 9 MUST NOT be released in this state.

   authenticated  Peer identity, Grant state, and handshake bindings
      have been accepted, but the association is not yet in normal
      stitched data transfer.

   stitched  The RN has completed the authorised stitch and the
      endpoints may exchange normal AEAD-protected application traffic
      within the accepted Grant scope.



Fisher                  Expires 17 September 2026               [Page 7]

Internet-Draft                     UZP                        March 2026


   failover / rebind  Continuity is being re-established at the same RN
      or at an alternate eligible RN.  Endpoints MAY use bounded
      continuity state only as allowed by the failover rules in this
      document; any authority expansion requires fresh validation, and
      no RN-local claim alone is sufficient to return the association to
      "stitched".

   closed  The association is terminated or abandoned.  Further traffic
      under that session context MUST be rejected unless a separate
      resumption or re-enrolment mechanism explicitly authorises a new
      session.

   Endpoints MUST begin in "new", MUST pass through "pending" before
   accepting authenticated state, MUST NOT treat "stitched" continuity
   as proof of continuing authorisation without the checks required by
   this document, and MUST treat transition into "failover / rebind" as
   an availability event rather than as automatic trust continuity.
   Loss of RN attachment changes rendezvous state; it does not by itself
   revoke externally verifiable identity, Grant, or revocation truth.

4.3.  HIL-Brokered Sessions

   Where legacy applications or non-native hardware cannot participate
   directly in UZP, a Hardware Integration Layer (HIL) as described by
   UZPIF ([UZPIF]) MAY establish or broker the UZP session on their
   behalf.  In such cases, the HIL is the policy-bound compatibility
   boundary and the attached legacy system is not automatically a native
   UZP endpoint.

   A HIL-brokered session MUST bind transport accountability to the
   authenticated HIL identity and MAY also carry an auditable device,
   slot, or port identifier for the attached legacy system when
   deployment policy requires that distinction.  Grants and any
   translated session context MUST be scoped so that the HIL cannot
   silently generalise the authority of the attached system beyond the
   mediation policy under which it operates.

   RN participation in a UZP session, whether native or HIL-brokered,
   MUST NOT be treated as RN authority over end-to-end identity or
   authentication truth.  The RN may relay flights, validate locally
   relevant Grant constraints, and enforce forwarding policy, but the
   authenticated truth of the session remains bound to the cryptographic
   endpoint or designated HIL endpoint, the handshake transcript, and
   the applicable Grant state rather than to RN observation of traffic
   or path position.






Fisher                  Expires 17 September 2026               [Page 8]

Internet-Draft                     UZP                        March 2026


4.4.  Identity Model and CID Stability

   Pantheon authorities bind a principal's long-term public signing key
   to identity, policy, and trust metadata; the canonical identity CID
   is defined as a hash (e.g., BLAKE3) of that public signing key.  CIDs
   are intended to be stable over multi-year time scales and across
   multiple devices in the same administrative entity, and SHOULD only
   change when the underlying key is rotated or revoked due to
   compromise.

   Deployments MAY use locally generated or externally attested keys if
   Pantheon policy allows; Pantheon authorities validate or certify
   those bindings and are not required to generate or custody the
   corresponding private keys.

   Each transport session also has an Ephemeral Identity (EID), derived
   from short-lived key material.  EIDs are bound to CIDs via Pantheon
   credentials over that ephemeral key material and are used within the
   UZP handshake and record layer.

   This separation mirrors the long-term vs. ephemeral key split in both
   HIP [RFC7401] and TLS 1.3 [RFC8446].

5.  Handshake Overview

   The UZP handshake provides:

   *  Mutual (or unilateral) authentication bound to CIDs and EIDs.

   *  Negotiation of cipher suites and AEAD algorithms.

   *  Derivation of exporter keys for UZPIF ([UZPIF]) and higher layers.

   *  Integration of Pantheon Grants, including replay protection and
      policy binding.

   The RN forwards handshake messages but does not terminate the
   cryptographic handshake itself.  Instead, both EPs derive end-to-end
   secrets using exporter material bound to the identities and Grants,
   and then switch to direct AEAD protection across the ZPIT.

5.1.  Specification Boundary

   This revision defines UZP message semantics, session-state logic,
   handshake roles, cryptographic bindings, replay constraints, PoR
   semantics, RN behaviour, and related transport security semantics
   needed for semantic interoperability.




Fisher                  Expires 17 September 2026               [Page 9]

Internet-Draft                     UZP                        March 2026


   Exact byte-level encoding is not yet fixed in this revision.  Packet
   layouts, message serialisations, some transport profiling, registry
   completeness, retransmission and congestion profiles, PMTU or
   fragmentation handling, and related deployment-specific choices
   remain deferred or profile-defined.

   Figures and message labels in this document are therefore
   illustrative.  They describe message purpose and sequencing, not a
   completed interoperable wire format.

5.2.  Flight Diagram

   Figure Figure 2 sketches a representative two-party handshake
   mediated by an RN.  The message labels are illustrative and show role
   and sequencing rather than a final byte-level wire format.

   EP_I (Init)           RN                EP_R (Resp)
    |--[1] CH1: CH_I, EID_I, Grant ------->|                    |
    |                 |--[2] CH1' (fwd) --->|                   |
    |                 |<--[3] SH, EE, CERT_R, FIN_R ------------|
    |<--[4] SH', EE', CERT'_R, FIN'_R ------|                   |
    |--[5] Finished_I --------------------->|                   |
    |                 |--[6] Finished'_I --->|                  |

        Figure 2: Example UZP handshake flights via an RN.  Message
          indices [1]-[6] are explained in the legend.  Labels are
                     illustrative and profile- neutral.

   This figure summarizes the RN-relayed handshake flights and where
   forwarding occurs.

   Legend:

   [1]  CH1: ClientHello_I, EID_I, Grant

   [2]  CH1': Forwarded ClientHello_I

   [3]  SH, EE, CERT_R, FIN_R

   [4]  SH', EE', CERT'_R, FIN'_R

   [5]  Finished_I (initiator final confirm towards RN)

   [6]  Finished'_I (forwarded initiator confirm towards responder)







Fisher                  Expires 17 September 2026              [Page 10]

Internet-Draft                     UZP                        March 2026


6.  Cryptographic Negotiation and AEAD Tag Length

   UZP requires negotiation over a cipher-suite identifier space.  In
   this revision, each suite selection binds:

   *  A key exchange mechanism (e.g., X25519, or a PQ KEM candidate).

   *  A signature algorithm for authentication.

   *  An AEAD algorithm for record protection (e.g., AES-GCM-128,
      ChaCha20-Poly1305).

   *  A KDF (e.g., HKDF-SHA256 or a BLAKE3-based KDF).

6.1.  AEAD Tag Length

   The AEAD tag length is algorithm-dependent but subject to the
   following constraints:

   *  Implementations MUST use a tag length of at least 96 bits for all
      UZP application data records.

   *  When an AEAD algorithm allows variable tag lengths, endpoints
      SHOULD use the algorithm's full tag length (typically 128 bits for
      AES-GCM) and MUST NOT negotiate a tag length below 96 bits.

   *  The tag length used for a session is fixed for the lifetime of
      that session and is implied by the negotiated cipher suite.

   This requirement follows common practice in modern protocols, which
   treat 96 bits as a practical lower bound on AEAD authentication tags
   for wide-area deployments, while allowing future AEADs with different
   native tag lengths.

7.  Blocks, Frames, and Reliability

   UZP defines a block-oriented reliability model and associated
   transport semantics:

   *  A block is the unit of transmission and acknowledgement semantics.

   *  Each block contains one or more frames, which carry application
      data or control information.

   *  Blocks carry monotonically increasing block numbers, and
      acknowledgement signalling references blocks rather than
      individual bytes.




Fisher                  Expires 17 September 2026              [Page 11]

Internet-Draft                     UZP                        March 2026


   This block-level model requires selective retransmission and
   deterministic pacing semantics:

   *  EPs can detect loss patterns and retransmit only affected blocks.

   *  Congestion control and pacing, when used, operate over block
      units, similarly in spirit to how QUIC applies logic over packet
      and frame boundaries [RFC9000].

   This draft does not yet standardise exact retransmission timers,
   acknowledgement encodings, PMTU discovery, fragmentation policy,
   congestion algorithm choice, or error-signalling registries.  Later
   revisions or deployment profiles may fix those wire- and policy-level
   details while preserving the block-oriented semantics defined here.

   Blocks are encrypted and authenticated with the negotiated AEAD.  The
   associated data includes:

   *  CID and EID for both parties.

   *  Direction and block number.

   *  A context-specific label (e.g., "uzp-application" or "uzp-
      handshake").

8.  Exporters

   UZP defines an exporter interface analogous to TLS exporters
   [RFC8446].  Exporters derive context-specific keys from the main
   handshake secrets, using labels and context values that MUST be bound
   to identities and transport parameters.

   An exporter input consists of:

   *  A label (e.g., "uzpif-zpit-key").

   *  A context value (which may include CIDs, EIDs, RN identifiers, and
      Grant nonces).

   *  An output length.

   Exported keys are used by:

   *  UZPIF ([UZPIF]) to derive per-ZPIT keys for monitoring or
      additional encapsulation.

   *  Higher-layer protocols wishing to bind application security
      directly to UZP session properties.



Fisher                  Expires 17 September 2026              [Page 12]

Internet-Draft                     UZP                        March 2026


   Exporters MUST incorporate both CIDs and the negotiated transport
   parameters so that re-use of exporters across sessions is
   cryptographically separated.

9.  0-RTT Data and Replay Handling

   UZP allows, but tightly constrains, 0-RTT (early) data:

   *  Early data MAY be sent by a client that possesses a valid, non-
      expired session resumption token and a Pantheon Grant that
      explicitly permits early data.

   *  Early data MUST be cryptographically distinct from 1-RTT data and
      MUST be bound to a monotonically increasing Grant nonce.

   *  RNs MUST treat 0-RTT flows as replayable at the transport level
      and MUST NOT rely on transport-layer properties for replay
      prevention.

   Replay prevention is handled jointly by:

   *  Pantheon Grants, which include a Grant nonce and time window;
      replayed Grants outside their window MUST be rejected.

   *  Endpoints, which track nonces and session tickets, and MUST refuse
      to process 0-RTT requests that would not be safe to replay at the
      application level.

   Authenticity alone is insufficient for transport-authorising
   artefacts.  A well-signed Grant, resumption token, or related control
   artefact MUST also be evaluated for freshness, scope, nonce or
   sequence state, and current policy eligibility before the endpoint or
   RN relies on it.

   If Pantheon policy specifies "no-replay" for a given Grant, endpoints
   MUST NOT use 0-RTT for any traffic under that Grant, and RNs MUST
   drop any early data tagged with that policy.

10.  Post-Quantum Profiles and Crypto Agility

   Given the long-term horizon of identity-centric networking, UZP is
   designed to support post-quantum (PQ) algorithms:

   *  Cipher suites define both classical and PQ-capable KEMs and
      signature schemes.

   *  Pantheon policy can enforce that certain tenants or epochs require
      PQ-only or hybrid key exchange.



Fisher                  Expires 17 September 2026              [Page 13]

Internet-Draft                     UZP                        March 2026


   *  The handshake format allows negotiation of PQ suites in parallel
      with classical ones, similar to ongoing PQ-TLS efforts [NIST-PQC].

   Transport endpoints SHOULD support at least one PQ KEM and one PQ-
   capable signature algorithm as they become standardised.

11.  Rendezvous Node Behaviour

   RNs are designed to be minimally trusted intermediaries.  An RN:

   *  Accepts outbound connections from EPs and validates their
      Pantheon-issued credentials and Grants.

   *  Matches Join requests between EPs and stitches them into ZPITs
      according to policy.

   *  Relays encrypted blocks between stitched endpoints, potentially
      applying rate limits, traffic shaping, and policy enforcement on
      encrypted metadata.

   Importantly, an RN:

   *  MUST NOT terminate end-to-end UZP AEAD protection.

   *  MUST NOT hold long-term secrets for EP identities.

   *  MAY observe and act on limited metadata (e.g., CIDs, block counts,
      timing) comparable to the exposure in QUIC's on-path model
      [RFC9000].

   An RN is therefore a relay and policy-constrained coordination point,
   not a sovereign source of identity, Grant, revocation, or other
   authorisation truth.

   For high-assurance deployments, multi-RN topologies similar to onion
   routing may be used [TOR2004], with attestation chains that prove
   that each RN conforms to specified software and configuration
   baselines.

11.1.  RN Set Discovery and Eligibility

   UZP endpoints that require resilient rendezvous SHOULD maintain one
   or more currently valid RN Set Statements, or an equivalent accepted
   RN set carried by bootstrap or recovery artefacts, as defined by
   UZPIF ([UZPIF]).  RN referral by a currently attached RN MAY be used
   as a hint, but it is not sufficient by itself to make an alternate RN
   eligible for authorisation-relevant use.




Fisher                  Expires 17 September 2026              [Page 14]

Internet-Draft                     UZP                        March 2026


   At baseline, before first use or failover use, the endpoint MUST
   validate the RN Set Statement's signature set, scope, validity
   interval, and epoch or sequence state under the UZPIF common envelope
   rules and prefer the highest eligible non-conflicting statement for
   the relevant scope.  Where policy permits, endpoints SHOULD keep
   multiple eligible alternate RNs rather than a single spare path.

   An endpoint MAY attempt failover only to an alternate RN that is
   currently policy-eligible for the relevant transport role, trust-
   domain scope, and session class.  Eligibility MUST be derived from
   externally verifiable artefacts rather than from one RN's private
   control view.

   A previously successful RN does not remain eligible merely because it
   stitched earlier traffic.  The endpoint MUST re-evaluate alternate-RN
   eligibility at failover time against current RN Set Statements,
   current policy scope, and current distrust or revocation state.

11.2.  RN Failover Triggers

   Endpoints SHOULD treat at least the following conditions as baseline
   failover triggers:

   *  loss of RN reachability, handshake timeout, or repeated Join
      failure;

   *  authenticated or otherwise policy-accepted overload, maintenance,
      or capacity-exhaustion signalling;

   *  signed or otherwise locally accepted evidence of RN misbehaviour;

   *  detected inconsistency between the RN's control claims and the
      endpoint's currently accepted RN Set Statement, Grant state, or
      transparency evidence; and

   *  suspected RN partition or divergence that prevents safe
      continuation of authorisation-relevant operation.

   Triggering failover changes path selection and rendezvous handling;
   it does not, by itself, revoke identity, Grants, or other externally
   verifiable authority.  RN loss is an availability event, not an
   authorisation event.

11.3.  Endpoint Failover Procedure

   When a baseline failover trigger occurs, the endpoint MUST at least:





Fisher                  Expires 17 September 2026              [Page 15]

Internet-Draft                     UZP                        March 2026


   1.  transition the association into "failover / rebind" or "closed"
       and stop treating RN-local control state as authorisation truth;

   2.  freeze new authorisation-expanding actions until required
       revalidation succeeds;

   3.  retain only the portable state allowed by Section 11.5;

   4.  select an alternate RN only from a currently accepted RN Set
       Statement or equally trusted bootstrap or recovery artefact;

   5.  establish a new RN attachment and perform a new Join evaluation
       at the alternate RN;

   6.  present current authorisation artefacts by default, or bounded
       continuity state only when non-expanding continuity is permitted
       by policy; and

   7.  return to "stitched" only after alternate-RN eligibility and
       required revalidation checks succeed; otherwise remain
       unavailable or terminate cleanly.

   If no eligible alternate RN can be validated, the association remains
   unavailable.  That is an availability outcome, not an implicit
   revocation of externally verifiable authority.

11.4.  Re-Stitching and Continuity State

   Re-stitching at an alternate RN requires a new RN attachment and Join
   evaluation.  Fresh presentation of current authorisation artefacts is
   the default baseline.  An alternate RN MAY accept bounded continuity
   state instead of a fully fresh authorisation presentation only for
   non-expanding continuity when local policy permits it.

   Bounded continuity state in UZP MUST be endpoint-presented and
   cryptographically bound to the authenticated peer identities, the
   still-valid Grant object identifiers or digests, the accepted RN set,
   the relevant session or resumption context, and a short expiry.  It
   MUST NOT be an opaque RN-issued assertion that another RN is required
   to trust blindly.

   An alternate RN MAY reuse bounded continuity state only when the
   resulting session scope is unchanged or narrower, the referenced
   Grant and revocation state remain valid, freshness and replay checks
   succeed, and no unresolved RN disagreement would make the continuity
   claim ambiguous.  Otherwise the endpoint MUST perform a fresh
   authorised re-stitch.




Fisher                  Expires 17 September 2026              [Page 16]

Internet-Draft                     UZP                        March 2026


   Before moving from "failover / rebind" back to "stitched", the
   endpoint and alternate RN MUST revalidate at least the alternate RN's
   eligibility for the requested role and scope, the currently accepted
   RN Set Statement or equally trusted bootstrap or recovery artefact,
   peer identity binding and current Grant or equivalent authorisation
   state, current revocation or transparency state relevant to the
   requested action, and the binding, freshness, replay constraints, and
   expiry of any continuity state presented.

11.5.  Portable Versus RN-Local State

   The baseline portability rule for UZP failover is:

   *  resumable or re-usable state MAY include peer identity bindings,
      current Grant references, accepted RN Set Statement identifiers,
      validated revocation or transparency checkpoints, and bounded
      continuity state accepted under policy;

   *  endpoint-local continuity markers MAY include application mapping
      state or block-delivery checkpoints only when they remain bound to
      the same peer identities, Grant scope, and continuity window; and

   *  RN-local state such as stitch handles, relay queue placement,
      pacing and congestion state, per-RN replay allocations, path
      observations, and unverified relay buffers MUST be treated as non-
      portable and MUST be renegotiated or conservatively rebuilt.

   Session continuity therefore does not imply trust continuity.  A
   resumed or re-stitched transport path MUST still revalidate the
   authorisation artefacts relevant to the new RN attachment.

   The fact that some state is portable does not remove the need to
   revalidate it.  Portable state MAY be resumed only after its
   bindings, scope, freshness, and policy eligibility are rechecked for
   the new RN attachment.

11.6.  RN Disagreement and Partition Behaviour

   If a currently attached RN and an alternate RN present conflicting
   control views for the same session, scope, or Grant state, endpoints
   MUST treat the conflict as an availability or continuity issue rather
   than as proof that either RN is the mandatory truth source.

   Under RN disagreement or suspected partition, endpoints MUST suspend
   new authorisation-expanding actions such as new peer scopes, broader
   Grants, QoS expansion, or 0-RTT resumption that depends on disputed
   state until externally verifiable artefacts are revalidated.
   Endpoints MAY continue narrowly scoped, already-established non-



Fisher                  Expires 17 September 2026              [Page 17]

Internet-Draft                     UZP                        March 2026


   expanding traffic only within an explicit continuity window allowed
   by local policy and MUST cease or cleanly terminate once that window
   expires or required revalidation fails.

   When disagreement cannot be resolved safely, implementations SHOULD
   prefer clean session termination or fresh re-stitching over silent
   failover that preserves apparent continuity without revalidation.

   If only one RN remains reachable during disagreement or partition,
   endpoints MUST still treat that RN as a relay path rather than as a
   truth anchor.  They MUST ignore RN-local claims that would expand
   authority unless those claims are independently supported by
   externally verifiable artefacts.

12.  Proof-of-Reachability (PoR)

   Informal Ping or heartbeat semantics are replaced by Proof-of-
   Reachability (PoR) for transport liveness validation.

   When PoR challenges, responses, or derived liveness evidence are
   retained beyond the immediate exchange, they MUST be represented as
   common signed artefacts using the envelope defined by UZPIF ([UZPIF])
   with "object_type" set to "por-evidence" when interoperable
   verification or audit is required.  That object type inherits the
   UZPIF common envelope unchanged, including canonical serialisation,
   exact signature coverage, object_id derivation, unknown-extension
   handling, signature ordering, algorithm identifier matching, epoch-
   versus-sequence precedence, and the rule that detached signatures are
   not part of baseline interoperability.

   Base UZP defines PoR as an authenticated reachability proof bound to
   the peer identity, a fresh nonce, the RN identifier, an expiry
   condition, and session context.  The proof is produced by a profile-
   defined authenticated responder and MUST be verifiable by the client
   without trusting RN assertions.

   Base UZP does not require a single proof primitive for PoR.  A
   profile may define the responder proof value as a signature, MAC,
   exporter-derived authenticator, or equivalent cryptographic proof,
   but the verifier MUST be able to determine exactly which bytes were
   authenticated and which authenticated responder construction was used
   for the challenged context.

   A PoR succeeds only when the verifier accepts cryptographic proof
   material emitted by the endpoint-side authenticated responder for the
   challenged context.  RN observation of relay traffic, queue activity,
   timing, packet return, or successful forwarding is not equivalent to
   endpoint liveness proof and MUST NOT be treated as such.



Fisher                  Expires 17 September 2026              [Page 18]

Internet-Draft                     UZP                        March 2026


12.1.  PoR Object Fields

   When a PoR challenge, response, or retained liveness artefact is
   represented as an object, it MUST use the common signed artefact
   envelope defined by UZPIF ([UZPIF]) with "object_type" set to "por-
   evidence".  In addition to the common envelope, a minimal PoR object
   MUST carry:

   *  the challenger identity, typically mapped to "audience_id" or an
      equivalent field;

   *  the responder identity, typically mapped to "subject_id" or an
      equivalent field;

   *  the RN identifier;

   *  session context sufficient to prevent replay across unrelated
      sessions, tunnels, or transport bindings;

   *  the PoR nonce;

   *  an issuance time and an expiry time;

   *  a proof-profile identifier indicating which authenticated
      responder construction was used;

   *  the responder proof value;

   *  a responder key identifier or exporter-label reference when needed
      for verification; and

   *  optional grant, transport-binding, or transparency references when
      the deployment needs them for audit or replay tracking.

   These fields populate the PoR-specific body only.  UZP inherits the
   UZPIF common envelope unchanged, including canonical serialisation,
   exact signature coverage, object identifiers, unknown extension
   handling, signature ordering, algorithm identifier matching, epoch-
   versus-sequence precedence, and the rule that detached signatures are
   not part of baseline interoperability.

   When a PoR artefact is retained as a common signed object, the
   envelope signature set authenticates the retained artefact
   representation for exchange or audit.  It does not replace the
   responder proof value as the liveness proof itself.  Current
   reachability still depends on validating the responder proof against
   the profile-defined authenticated responder for the challenged
   context.



Fisher                  Expires 17 September 2026              [Page 19]

Internet-Draft                     UZP                        March 2026


   The responder proof value MUST authenticate the exact PoR input used
   by the selected proof profile.  At a minimum, that authenticated
   input MUST cover the responder identity, the challenger identity or
   equivalent audience restriction, the RN identifier, the session
   context, the PoR nonce, the issuance and expiry values, the proof-
   profile identifier, and any grant, transport-binding, or transcript-
   binding values that the verifier is expected to enforce.  If a
   profile authenticates a derived challenge representation rather than
   the retained PoR object verbatim, the verifier MUST still be able to
   determine exactly which PoR fields were authenticated.

12.2.  PoR Exchange

   A PoR exchange is defined as follows:

   1.  The client generates a fresh nonce for a specific PoR
       transaction.  The nonce MUST be unique within the verifier's
       active replay window for the relevant responder, RN context, and
       session class.

   2.  The PoR challenge MUST bind: the peer identity being tested, a
       fresh nonce, an RN identifier, an explicit expiry window, and
       session context sufficient to prevent replay across unrelated
       sessions or tunnels.

   3.  The RN relays the nonce to the target peer without modification.

   4.  The peer produces proof material using the profile-defined
       authenticated responder for the current session, covering the
       bound challenge fields and the authenticated session or transport
       context required by that profile.

   5.  The RN returns the responder proof to the client.

   6.  The client validates the returned proof against the exact
       challenged context, including nonce freshness, expiry, session-
       context binding, proof-profile identifier, and peer identity
       match, before accepting liveness.

   Freshness evaluation MUST reject a PoR response if the nonce was not
   generated for the claimed transaction, if that nonce has already been
   accepted for the same responder or context, if the issuance or expiry
   values fall outside the verifier's acceptance window, or if the
   authenticated session, resumption, or transport context is no longer
   current.






Fisher                  Expires 17 September 2026              [Page 20]

Internet-Draft                     UZP                        March 2026


   A verifier MUST also reject a response if the challenge expiry has
   elapsed before proof validation completes, if the authenticated RN
   identifier does not match the RN attachment under evaluation, or if
   the proof binds to an older session, resumption context, or
   continuity window than the one for which present reachability is
   being claimed.

12.3.  PoR Across Re-Stitch and RN Failover

   PoR evidence is path- and context-bound.  A PoR response accepted
   under one RN attachment, session context, or continuity window MUST
   NOT by itself be treated as fresh liveness proof for a different RN
   attachment or re-stitched transport path.

   After re-stitch or RN failover, endpoints MUST obtain a new PoR
   response bound to the new RN identifier and the currently
   authenticated session or continuity context before relying on PoR for
   current reachability on that path.  Earlier PoR artefacts MAY be
   retained for audit, replay tracking, or continuity diagnostics, but
   they do not satisfy current liveness verification for the new
   attachment.

   A previous PoR response MUST NOT be reinterpreted as current liveness
   merely because the same peer identities, Grant references, or
   application flow continue across failover.  The verifier MUST obtain
   a fresh proof bound to the new RN attachment and current session or
   continuity context before treating the peer as presently reachable on
   that path.

   A bounded continuity decision under Section 11.4 MAY allow traffic to
   continue briefly while revalidation proceeds, but it does not convert
   an older PoR bound to a previous RN or session into proof of present
   reachability.

12.4.  TLS-DPA PoR Profile

   The TLS-DPA profile instantiates the authenticated responder using
   TLS-DPA-authenticated identity material [TLS-DPA].  A deployment MAY
   use either:

   *  a dedicated PoR responder key derived from exporter material bound
      to the authenticated TLS-DPA or UZP session; or

   *  a proof directly generated with TLS-DPA-authenticated identity key
      material.






Fisher                  Expires 17 September 2026              [Page 21]

Internet-Draft                     UZP                        March 2026


   The TLS-DPA profile SHOULD prefer an exporter-derived PoR responder
   key for steady-state or frequent liveness checks because it reduces
   operational dependence on repeated use of long-term identity keys
   while preserving RN non-forgeability.  Direct long-term identity-key
   signing MAY be used where policy explicitly requires identity-key
   participation or where exporter-derived responder material is
   unavailable.

   In the TLS-DPA profile, exporter-derived responder material is the
   preferred baseline for ordinary PoR use.  Long-term identity-key
   signatures are an exception path for deployments that explicitly
   require them, for recovery of exporter state, or for other policy-
   defined cases where exporter-derived proof material cannot be used.

   Regardless of which method is used, the client MUST validate that the
   responder proof is cryptographically bound to a TLS-DPA-authenticated
   peer identity and to the relevant session context.  The authenticated
   input MUST cover the PoR nonce, the asserted identities, the RN
   identifier, validity bounds, and the session or exporter binding
   required by the selected mode.

   This draft intentionally does not define a byte-level PoR wire
   encoding for the TLS-DPA profile.  Profile documents or future
   revisions may define concrete serialisations for PoR challenges, PoR
   responses, and retained PoR artefacts while preserving the object
   fields and validation rules specified here.

12.5.  Replay Prevention

   Replay prevention requirements for PoR are:

   *  Peers and verifiers MUST reject expired nonce values or challenges
      whose validity window has elapsed.

   *  Verifiers MUST accept a PoR response at most once for a given
      responder identity, RN identifier, nonce, and session-context
      tuple.

   *  RNs MUST NOT treat replayed forwarding, repeated observation, or
      cached PoR responses as fresh liveness, and MUST NOT cache PoR
      responses beyond their expiry window.

   Replay prevention for PoR is therefore based on nonce uniqueness,
   bounded validity, exact context binding, and verifier-side single-
   acceptance tracking rather than on RN observation of traffic.






Fisher                  Expires 17 September 2026              [Page 22]

Internet-Draft                     UZP                        March 2026


12.6.  RN Non-Forgeability Requirement

   The transport liveness model MUST ensure an RN cannot fabricate peer
   reachability.

   *  The peer PoR proof MUST cover the original nonce, peer identity,
      RN identifier, expiry condition, and session context.

   *  The client MUST validate the proof against the profile-defined
      authenticated responder associated with the peer identity, and
      MUST NOT rely on RN assertions alone for liveness.

   *  RNs MUST NOT generate synthetic PoR acknowledgements that are not
      produced by the authenticated responder bound to the peer identity
      and session context.

   *  RN-local evidence such as successful forwarding, packet
      observation, queue drain, or timing correlation MUST NOT be
      substituted for endpoint-generated PoR proof.

12.7.  Liveness Proof Logging

   RNs MAY publish aggregated PoR statistics in transparency logs.
   Publication is OPTIONAL but RECOMMENDED for deployments that use
   merit-based scoring or external audit signals.

   Where PoR-related transparency artefacts are published for
   interoperable audit, they MUST use the common signed artefact
   envelope defined by UZPIF ([UZPIF]), with sequence or log linkage
   sufficient for independent audit.

13.  Security Considerations

   UZP's security properties derive from:

   *  The zero-port architecture of UZPIF ([UZPIF]) (no open listeners).

   *  The use of modern AEAD algorithms with at least 96-bit tags.

   *  Identity-first addressing via CIDs and EIDs, influenced by HIP
      [RFC7401].

   *  Exporters that bind higher-layer security directly to transport
      identities and parameters.

   *  Strong replay controls via Grants and endpoint tracking of nonces
      and tickets.




Fisher                  Expires 17 September 2026              [Page 23]

Internet-Draft                     UZP                        March 2026


   *  PoR liveness verification with profile-authenticated nonce
      evidence that limits RN forgery.

   Residual risks include traffic analysis, RN compromise (drop/delay
   behaviour), and application-layer weaknesses.  These are mitigated
   through:

   *  Multi-RN topologies and attestation.

   *  Pantheon policy that can revoke identities and Grants quickly.

   *  Integration with Zero Trust principles [NIST-SP800-207].

14.  IANA Considerations

   This document makes no requests of IANA at this time because it does
   not yet define final wire encodings or complete registries.  Future
   revisions of UZP may define registries for protocol parameters (for
   example cipher suites, frame types, and exporter labels), but such
   actions are out of scope for this transport-semantics revision.

   *  A registry for UZP cipher suites and AEAD algorithms.

   *  A registry for frame and block types.

   *  A registry for exporter labels used by UZP and UZPIF ([UZPIF]).

15.  Normative References

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

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

16.  Informative References

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.







Fisher                  Expires 17 September 2026              [Page 24]

Internet-Draft                     UZP                        March 2026


   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
              RFC 7401, DOI 10.17487/RFC7401, April 2015,
              <https://www.rfc-editor.org/info/rfc7401>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [UZPIF]    Fisher, B. A., "Universal Zero-Port Interconnect Framework
              (UZPIF)", Work in Progress, Internet-Draft, draft-dpa-
              uzpif-framework, <https://datatracker.ietf.org/doc/html/
              draft-dpa-uzpif-framework>.

   [TLS-DPA]  Fisher, B. A., "TLS-DPA: An Identity-Bound Security
              Protocol for Traditional, Overlay, and Zero-Port
              Transports", Work in Progress, Internet-Draft, draft-dpa-
              tls-dpa,
              <https://datatracker.ietf.org/doc/html/draft-dpa-tls-dpa>.

   [NIST-SP800-207]
              Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
              "Zero Trust Architecture", NIST SP 800-207, 2019,
              <https://doi.org/10.6028/NIST.SP.800-207>.

   [NIST-PQC] Technology, N. I. O. S. A., "NIST Post-Quantum
              Cryptography Standardization: Fourth Round Candidate
              Algorithms", 2022, <https://csrc.nist.gov/Projects/post-
              quantum-cryptography>.

   [TOR2004]  Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
              Second-Generation Onion Router", USENIX Security
              Symposium, 2004.

Acknowledgements

   The author thanks colleagues and early reviewers for discussions on
   identity-centric networking, rendezvous transports, and post-quantum
   transition considerations.  Any errors or omissions remain the
   author's responsibility.

Author's Address

   Benjamin Anthony Fisher
   DPA R&D Ltd (https://www.dpa-cloud.co.uk)
   Email: b.fisher@dpa-cloud.co.uk
   URI:   https://orcid.org/0009-0004-4412-2269




Fisher                  Expires 17 September 2026              [Page 25]
