Network Working Group B.A. Fisher Internet-Draft DPA R&D Ltd (https://www.dpa-cloud.co.uk) Intended status: Informational 2 January 2026 Expires: 6 July 2026 UZP: Universal Zero-Port Transport Protocol draft-dpa-uzp-transport-00 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. All application data is carried over an authenticated encryption (AEAD) channel keyed by a handshake based on modern and post-quantum-capable primitives. Reliability is expressed at the block level, rather than at the TCP segment or stream level, enabling selective retransmission and deterministic pacing. This document specifies the UZP wire format, handshake, cryptographic negotiation, exporter interface, 0-RTT rules, replay model, and RN behaviour, and its relationship to UZPIF ([UZPIF]), QUIC ([RFC9000]), HIP ([RFC7401]), and TLS 1.3 ([RFC8446]). Note to Reviewers This document is an Internet-Draft derived from internal research material solely to enable structured technical review, interoperability discussion, and disciplined specification development under the Internet-Draft process. It is a work-in- progress research artefact and does not constitute a standard, recommendation, or finished specification. The text aims to preserve a clear separation of normative and informative content. Requirement words are used only where protocol behaviour is intentionally specified. 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 not presented as a universal replacement for existing transports. Fisher Expires 6 July 2026 [Page 1] Internet-Draft UZP January 2026 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 . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Conventions and Terminology . . . . . . . . . . . . . . . 4 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Architectural Overview . . . . . . . . . . . . . . . . . . . 5 4.1. High-Level Session Flow . . . . . . . . . . . . . . . . . 5 4.2. Identity Model and CID Stability . . . . . . . . . . . . 6 5. Handshake Overview . . . . . . . . . . . . . . . . . . . . . 6 5.1. Flight Diagram . . . . . . . . . . . . . . . . . . . . . 7 6. Cryptographic Negotiation and AEAD Tag Length . . . . . . . . 7 6.1. AEAD Tag Length . . . . . . . . . . . . . . . . . . . . . 8 7. Blocks, Frames, and Reliability . . . . . . . . . . . . . . . 8 8. Exporters . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. 0-RTT Data and Replay Handling . . . . . . . . . . . . . . . 9 10. Post-Quantum Profiles and Crypto Agility . . . . . . . . . . 10 Fisher Expires 6 July 2026 [Page 2] Internet-Draft UZP January 2026 11. Rendezvous Node Behaviour . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 14. Normative References . . . . . . . . . . . . . . . . . . . . 12 15. Informative References . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 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]. Fisher Expires 6 July 2026 [Page 3] Internet-Draft UZP January 2026 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 node that accepts outbound connections from EPs, validates Pantheon-issued Grants, and stitches identity-bound flows. * Pantheon: The global identity, attestation, and policy plane used by UZPIF ([UZPIF]) and UZP. * 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 unit of reliability (acknowledgement / retransmission) in UZP. * Frame: The unit of application payload mapping inside a block. 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]. Fisher Expires 6 July 2026 [Page 4] Internet-Draft UZP January 2026 * 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. 4.1. High-Level Session Flow Fisher Expires 6 July 2026 [Page 5] Internet-Draft UZP January 2026 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. Identity Model and CID Stability Pantheon issues long-term signing keys to principals; the canonical identity CID is defined as a hash (e.g., BLAKE3) of the 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. Each transport session also has an Ephemeral Identity (EID), derived from short-lived key material. EIDs are bound to CIDs via Pantheon- issued credentials 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. Fisher Expires 6 July 2026 [Page 6] Internet-Draft UZP January 2026 5.1. Flight Diagram Figure Figure 2 sketches a representative two-party handshake mediated by an RN. Exact messages and encoding are defined in the wire-format section (not reproduced in full here). 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; exact message contents are defined in the wire specification. 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) 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). Fisher Expires 6 July 2026 [Page 7] Internet-Draft UZP January 2026 * 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 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. Fisher Expires 6 July 2026 [Page 8] Internet-Draft UZP January 2026 * 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. Fisher Expires 6 July 2026 [Page 9] Internet-Draft UZP January 2026 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. Fisher Expires 6 July 2026 [Page 10] Internet-Draft UZP January 2026 * 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. Fisher Expires 6 July 2026 [Page 11] Internet-Draft UZP January 2026 * A registry for exporter labels used by UZP and UZPIF ([UZPIF]). 14. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 15. 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, . [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, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [UZPIF] Fisher, B. A., "Universal Zero-Port Interconnect Framework (UZPIF)", Work in Progress, Internet-Draft, draft-dpa- uzpif-framework, . [NIST-SP800-207] Rose, S., Borchert, O., Mitchell, S., and S. Connelly, "Zero Trust Architecture", NIST SP 800-207, 2019, . [NIST-PQC] Technology, N. I. O. S. A., "NIST Post-Quantum Cryptography Standardization: Fourth Round Candidate Algorithms", 2022, . [TOR2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The Second-Generation Onion Router", USENIX Security Symposium, 2004. Fisher Expires 6 July 2026 [Page 12] Internet-Draft UZP January 2026 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 6 July 2026 [Page 13]