The Universal Zero-Port Interconnect Framework (UZPIF): An Identity-Centric Architecture for Post-Port Networking DPA R&D Ltd (https://www.dpa-cloud.co.uk)
b.fisher@dpa-cloud.co.uk https://orcid.org/0009-0004-4412-2269
zero-port networking identity-centric networking rendezvous protocols zero trust post-quantum cryptography The Universal Zero-Port Interconnect Framework (UZPIF) describes a post-port networking model in which communication is established via outbound, identity-bound sessions to Rendezvous Nodes (RNs). By removing publicly reachable listening ports at endpoints, UZPIF aims to reduce exposure to Internet-wide scanning and unsolicited ingress, and to constrain a broad class of lateral-movement vectors. This document outlines architectural motivation, a high-level security model, operational and economic considerations, a governance concept (Pantheon), and an incremental migration approach. UZPIF is intended to be read alongside companion work describing the Universal Zero-Port Transport Protocol (UZP; ) and TLS-UZP ().
Scope and Status This document is an Internet-Draft and represents work in progress. It is published to enable structured technical review, interoperability discussion, and disciplined specification development around the Universal Zero-Port Interconnect Framework (UZPIF). The material is a research artefact. It does not claim technical completeness, production readiness, or endorsement by the IETF or any other standards body, and it is not presented as a standards-track specification. It is not a universal replacement, is not mandated outside its target environment, and is designed for experimentation and profile-driven deployments. During conversion from internal research documents into IETF XML, care has been taken to:
  • preserve a clear distinction between normative and informative content;
  • use requirement language (e.g., "MUST", "SHOULD", "MAY") only where protocol behaviour is intentionally specified;
  • avoid any implication of registry finalisation, mandatory implementation, or standard-track status; and
  • maintain intellectual-property neutrality, with no implied patent grants or licensing commitments beyond the IETF Trust copyright licence applicable to Internet-Draft text.
Ongoing research, implementation, performance validation, and real-world pilot work remain outside the scope of this Internet-Draft text and may be pursued separately.
Executive Summary The Internet still commonly exposes services via publicly reachable transport ports, a legacy design choice that enables scanning and unsolicited connection attempts at global scale. Operationally, this contributes to exposure for denial-of-service attacks, credential attacks, and lateral movement within networks. UZPIF (the framework) and UZP () (its transport protocol) remove the concept of exposed ports at endpoints. Both endpoints initiate outbound, identity-anchored sessions to a Rendezvous Node (RN), which only stitches traffic when identity, context, and declared purpose align under policy issued by Pantheon, the identity and policy plane. The intent is a model where nothing is discoverable unless explicitly permitted by policy and exposed through the rendezvous fabric, and where application traffic is end-to-end authenticated and encrypted. UZP () is designed to support performance properties such as:
  • block-level reliability,
  • selective retransmission, and
  • deterministic pacing.
Legacy applications (e.g., HTTP(S), remote desktop, file sharing, and real-time media) are intended to continue to operate without modification via a Host Identity Layer (HIL) that maps traditional application expectations onto identity-centric sessions. UZPIF is intended to be evolutionary rather than revolutionary. It deliberately builds on transport, security, and identity work embodied in QUIC , TLS 1.3 , and the Host Identity Protocol , while aligning with modern zero-trust guidance (e.g., NIST SP 800-207 ) and post-quantum cryptography standardisation efforts (e.g., the NIST PQC project ).
Introduction This document provides an architectural overview of UZPIF and motivates why an identity-first, rendezvous-based model that avoids publicly reachable listeners may be desirable.
Why Now?
  • Investment in perimeter defences (e.g., DDoS mitigation and application firewalls) can yield diminishing returns as attackers automate scanning and exploit discovery at Internet scale.
  • Zero Trust Network Access (ZTNA) and SASE deployments indicate demand for identity-first networking, yet many approaches still expose TCP/UDP ingress and rely on perimeter constructs.
  • Post-quantum cryptography efforts provide a path to identity-first transport without prohibitive performance regression as key encapsulation and signature schemes mature.
What's New Versus Yet Another VPN? Conventional VPNs and overlay networks typically retain the assumption that services listen on IP:port tuples, even if those ports are only reachable within a private address space or through a gateway. QUIC , TLS 1.3 , HIP , and systems such as Tor demonstrate that identity, encryption, and rendezvous can be decoupled from raw addressing semantics, but they stop short of removing listening ports entirely.
  • No listeners at endpoints.
  • Identity-as-address via identities (e.g., canonical and ephemeral identities) rather than IP:port.
  • Block-level reliability with selective retransmission (transport-level design goal).
  • Pantheon policy plane encoding purpose, context, and validity into every session.
Terminology Requirements Language: 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 and when, and only when, they appear in all capitals. This Internet-Draft is primarily architectural; requirement language is used sparingly and only where behaviour is intentionally specified. Endpoint. A host or service that participates in UZPIF by initiating outbound sessions. Rendezvous Node. A mediator that accepts outbound sessions and stitches permitted flows. An identity, attestation, and policy plane that issues credentials and session grants. Host Identity Layer. A compatibility layer intended to support legacy applications over identity-centric sessions. Canonical Identity. A long-term cryptographic identity used to identify an EP (or a delegated sub-identity). Ephemeral Identity. A short-lived identity used for sessions, derived or issued under policy. Zero-Port Interconnect Tunnel. An end-to-end encrypted tunnel stitched via one or more RNs.
Core Architecture
High-Level Flow: EP to RN to EP In UZPIF, both peers initiate outbound sessions towards an RN. After policy evaluation and authorisation, the RN stitches the two sessions into a tunnel (ZPIT) that carries end-to-end protected application data.
High-level communication pattern (outbound-only sessions) | | | |<---- outbound| |<==== end-to-end encrypted ZPIT (stitched via RN) ====>| ]]>
This figure shows both endpoints initiating outbound sessions to the RN, which stitches them into a single ZPIT.
Pantheon Grant Verification Prior to stitching, an EP is expected to obtain a signed authorisation ("Grant") from Pantheon. Grants bind identity to purpose and validity constraints, enabling RNs to make consistent policy decisions.
Grant request and issuance flow | |<------ Signed Grant --------| | |---- Grant + CID/EID ----> RN ]]>
This figure illustrates the basic grant request and issuance exchange between an EP and Pantheon.
Flow Stitching by the RN The RN establishes a stitched tunnel only if both peers present acceptable identities and authorisations. The RN is assumed to be able to drop, delay, or reorder packets, but is not expected to learn end-to-end protected application plaintext.
Join and stitch establishment | | |<-- Stitch OK -----| | | |<-- Join Request--| | |-- Stitch OK ---->| | |<====== end-to-end encrypted ZPIT (SessionID-bound) ==========>| ]]>
This figure shows the RN joining two authorised sessions into a stitched tunnel without learning plaintext.
Multi-RN Stitching for High-Assurance Tenants UZPIF can be extended to multi-hop stitching, for example where a tenant requires multiple independently operated RNs and attestation chains. End-to-end protection is expected to remain between endpoints.
Multi-hop stitching with end-to-end authenticated encryption RN1 -> RN2 -> EP B EP A <======== end-to-end AEAD protected traffic ========> EP B ]]>
This figure depicts a multi-hop RN chain while end-to-end AEAD protection remains between endpoints.
Pantheon: Identity and Governance Model Pantheon is described here as a global identity, attestation, and policy plane. This section sketches the model at a conceptual level; future revisions may refine data structures and operational assumptions.
Identity Model Pantheon issues (or authorises issuance of):
  • long-term signing keys (forming CIDs);
  • ephemeral session keys (forming EIDs); and
  • delegated sub-identities for services or microprocesses.
This identity approach is conceptually aligned with HIP's separation of endpoint identities from locators , but elevated to a policy plane.
Certificate Format Pantheon Certificates (PCerts) may include the following conceptual elements:
  • a CID and public signing key (and optionally a post-quantum key encapsulation key);
  • purpose tags (e.g., service, role, tenant);
  • validity bounds (time or epoch); and
  • optional attestation claims (e.g., hardware trust or enclave measurement).
Grant Structure A Grant is described as a signed assertion binding:
  • the CID/EID of the requester;
  • the requested peer identity;
  • purpose and action;
  • a time window and replay nonce; and
  • an authorised quality-of-service (QoS) class.
Attestation Model RNs and endpoints may publish attestations such as:
  • hardware and software measurements;
  • configuration hashes; and
  • policy compliance data.
Pantheon is expected to store these in transparency logs, mirroring transparency and verifiability goals in broader zero-trust guidance.
Caching Rules Endpoints may cache:
  • PCerts for 24 hours;
  • Grants for the shorter of their validity window or session lifetime; and
  • attestation proofs for the duration of RN handshake paths.
Benefits and Trade-offs UZPIF and UZP () intentionally reuse established transport and cryptographic primitives, but change where and how they are bound to identity, policy, and reachability. In particular, QUIC and TLS 1.3 demonstrate encrypted transports with modern handshake properties, while UZPIF shifts the reachability model away from listening endpoints. Comparison of transport architectures
Dimension UZPIF/UZP () Traditional TCP/TLS QUIC/TLS
Exposure No open ports (endpoints are not publicly listening) Open ports and/or proxies Open ports at network edge
Identity Mandatory cryptographic identity Typically TLS-level identity only TLS-level identity
Reliability Block-level (design goal) Segment-level Stream-level
RN trust Drop/delay only (no end-to-end plaintext visibility expected) N/A N/A
Latency control Deterministic pacing (design goal) Congestion control variants (e.g., Reno/CUBIC) Congestion control variants (e.g., BBR/CUBIC)
Legacy applications Supported via HIL (intended) Native Often requires gateways or adaptation
Post-quantum readiness Designed for cryptographic agility Inconsistent deployment Emerging
Threat Model This section sketches attacker classes and example controls. It is not a complete security analysis and will evolve with implementation experience. Attacker classes include:
  • Internet-wide scanners;
  • botnets seeking command-and-control beacons;
  • malicious RNs (assumed capable of drop/delay/reorder);
  • insiders with credentials; and
  • traffic analysts performing correlation.
Existing rendezvous and overlay systems (e.g., Tor ) and NAT traversal mechanisms based on STUN and TURN demonstrate the power of indirection, but they still assume exposed or discoverable listeners somewhere in the path. UZPIF's design intent is to remove those listeners from the endpoint security model. Example controls discussed for UZPIF include:
  • end-to-end authenticated encryption (AEAD);
  • RN and endpoint attestation;
  • puzzles and identity-bound rate limits;
  • multi-RN stitching for higher assurance; and
  • post-quantum readiness and cryptographic agility (see ).
Economics
  • Capital expenditure reduction: reduced reliance on perimeter appliances and complex DMZ designs.
  • Operational expenditure reduction: fewer ACL/NAT rule changes and less inbound exposure management.
  • Risk reduction: reduced externally visible attack surface.
  • Potential service models: governance and RN validation as managed components.
Migration Plan for Organisations UZPIF is intended for incremental deployment alongside existing TCP/TLS and QUIC-based stacks and .
  1. Deploy an RN: Introduce an outbound-only rendezvous node.
  2. Deploy the HIL: Install the Host Identity Layer on endpoints.
  3. Dual-stack operation: Run UZP () alongside existing TCP/TLS.
  4. Cutover: Migrate services gradually to zero-port operation.
Security Considerations UZPIF's central security claim is that avoiding publicly reachable listeners at endpoints reduces exposure to scanning and unsolicited ingress. However, the framework introduces reliance on identity, authorisation, and policy evaluation components (e.g., Pantheon and RNs) whose compromise or misconfiguration could impact availability and authorisation correctness. The threat model in discusses attacker classes and candidate controls. Future revisions of this document (and the companion UZP () and TLS-UZP () documents) are expected to provide a more systematic analysis, including key management, revocation, attestation trust, and traffic analysis resistance.
IANA Considerations This document has no IANA actions. UZPIF is an architectural framework and does not define protocol parameters requiring registries.
Normative References Informative References UZP: Universal Zero-Port Transport Protocol TLS-DPA: An Identity-Bound Security Protocol for Traditional, Overlay, and Zero-Port Transports NIST Post-Quantum Cryptography Standardization Project National Institute of Standards and Technology Zero Trust Architecture Tor: The Second-Generation Onion Router
Appendix A: Technical Specification (Excerpt)
Abstract UZP () defines an identity-addressed, encrypted-by-default transport protocol for zero-port networking. Endpoints do not listen on IP/port tuples; both create outbound sessions to an RN.
Terminology
  • EP - endpoint.
  • RN - rendezvous node.
  • Pantheon - identity/policy authority.
  • HIL - Host Identity Layer.
  • CID - canonical identity.
  • EID - ephemeral identity.
  • ZPIT - stitched tunnel.
  • Block - reliability unit.
  • Frame - payload unit.
Architectural Overview
  1. EP opens a control channel to an RN.
  2. EP authenticates with Pantheon.
  3. EP requests a Join for a peer CID.
  4. RN validates authorisation and stitches a ZPIT.
  5. Data flows with deterministic pacing (transport design goal).