UZP: Universal Zero-Port 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 6 July 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Scope and Status

This Internet-Draft describes UZP as an experimental transport protocol for the Universal Zero-Port Interconnect Framework (UZPIF; [UZPIF]). The intent is to support early peer review and implementation experiments; substantial revision is expected.¶

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 not a universal replacement, is not mandated outside its target environment, and is designed for experimentation and profile-driven deployments.¶

2. Introduction

The deployed Internet largely continues to rely on listening sockets bound to IP:port tuples. This design, inherited from the 1980s, exposes every reachable service 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 treat the symptom, not the cause.¶

The Universal Zero-Port Interconnect Framework (UZPIF; [UZPIF]) proposes a post-port architecture in which services are reached only 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 keeping legacy applications unmodified above a Host Identity 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] demonstrate the value of decoupling endpoint identity from network location. UZP is intended to be compatible with post-quantum cryptography profiles [NIST-PQC].¶

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

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

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

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

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

6. Cryptographic Negotiation and AEAD Tag Length

UZP supports an extensible cipher-suite registry. A cipher suite includes:¶

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

7. Blocks, Frames, and Reliability

UZP uses a block-oriented reliability model:¶

• A block is a unit of transmission and acknowledgement.¶

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

• Blocks carry monotonically increasing block numbers, and ACK frames reference blocks, not individual bytes.¶

This block-level model enables selective retransmission and deterministic pacing:¶

• EPs can rapidly detect loss patterns and retransmit only affected blocks.¶

• Congestion control and pacing can be applied over well-defined block units, similarly to how QUIC applies logic over packet and frame boundaries [RFC9000].¶

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

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

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

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

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

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

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

13. IANA Considerations

This document makes no requests of IANA at this time. 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 introductory specification.¶

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

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