| Internet-Draft | UZPIF | January 2026 |
| Fisher | Expires 10 July 2026 | [Page] |
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; [UZP]) and TLS-UZP ([TLS-DPA]).¶
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 10 July 2026.¶
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.¶
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.¶
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 ([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 ([UZP]) is designed to support performance properties such as:¶
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 [RFC9000], TLS 1.3 [RFC8446], and the Host Identity Protocol [RFC7401], while aligning with modern zero-trust guidance (e.g., NIST SP 800-207 [NIST-SP800-207]) and post-quantum cryptography standardisation efforts (e.g., the NIST PQC project [NIST-PQC]).¶
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.¶
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. [NIST-SP800-207]¶
Post-quantum cryptography efforts provide a path to identity-first transport without prohibitive performance regression as key encapsulation and signature schemes mature. [NIST-PQC]¶
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 [RFC9000], TLS 1.3 [RFC8446], HIP [RFC7401], and systems such as Tor [Tor] demonstrate that identity, encryption, and rendezvous can be decoupled from raw addressing semantics, but they stop short of removing listening ports entirely.¶
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 [RFC2119] and [RFC8174] 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.¶
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.¶
EP A (Initiator) RN EP B (Responder)
|---- outbound ----->| |
| |<---- 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.¶
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.¶
EP Pantheon |------ Grant Request ------->| |<------ Signed Grant --------| | |---- Grant + CID/EID ----> RN
This figure illustrates the basic grant request and issuance exchange between an EP and Pantheon.¶
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.¶
EP A RN EP B |-- Join Request -->| | |<-- 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.¶
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.¶
EP A -> 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 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.¶
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 [RFC7401], but elevated to a policy plane.¶
Pantheon Certificates (PCerts) may include the following conceptual elements:¶
A Grant is described as a signed assertion binding:¶
RNs and endpoints may publish attestations such as:¶
Pantheon is expected to store these in transparency logs, mirroring transparency and verifiability goals in broader zero-trust guidance. [NIST-SP800-207]¶
UZPIF and UZP ([UZP]) intentionally reuse established transport and cryptographic primitives, but change where and how they are bound to identity, policy, and reachability. In particular, QUIC [RFC9000] and TLS 1.3 [RFC8446] demonstrate encrypted transports with modern handshake properties, while UZPIF shifts the reachability model away from listening endpoints.¶
| Dimension | UZPIF/UZP ([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 |
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 [Tor]) and NAT traversal mechanisms based on STUN [RFC5389] and TURN [RFC5766] 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:¶
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.¶
UZPIF is intended for incremental deployment alongside existing TCP/TLS and QUIC-based stacks [RFC8446] and [RFC9000].¶
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 Section 8 discusses attacker classes and candidate controls. Future revisions of this document (and the companion UZP ([UZP]) and TLS-UZP ([TLS-DPA]) documents) are expected to provide a more systematic analysis, including key management, revocation, attestation trust, and traffic analysis resistance.¶
This document has no IANA actions.¶
UZPIF is an architectural framework and does not define protocol parameters requiring registries.¶
UZP ([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.¶