Zero Trust Secure Layer (ZTSL) Protocol Specification with Opcode Framework and Application Binding Layer
draft-ztsl-secdispatch-protocol-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | sripad karthik | ||
| Last updated | 2026-08-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ztsl-secdispatch-protocol-00
Internet Engineering Task Force S. Rama Hebbar
Internet-Draft Independent
Intended status: Standards Track 5 August 2026
Expires: 6 February 2027
Zero Trust Secure Layer (ZTSL) Protocol Specification with Opcode
Framework and Application Binding Layer
draft-ztsl-secdispatch-protocol-00
Abstract
This document specifies the Zero Trust Secure Layer (ZTSL) protocol,
a transport-layer security framework that enforces Zero Trust
principles at the protocol level by embedding continuous identity
verification, device trust validation, policy-driven communication,
and cryptographic session management into every protocol message.
ZTSL introduces the First Authentication Needed (FAN) mechanism,
Zessions (Zero Trust Sessions), the Device Trust Flag (DTF), the
Client Security Routing Profile (CSRP), the Triple Signature Model,
the Trust Triangle, Adaptive Protocol Negotiation, and Heartbeat
Fingerprint (HBF) synchronization.
This document also specifies the ZTSL Opcode Framework, a structured,
extensible opcode namespace that encodes every protocol operation as
a precisely identified, versioned, and trust-contextualized
instruction. Every FAN exchange, Zession state transition, socket
operation, signing step, routing decision, heartbeat synchronization,
threat event, and recovery action is assigned a unique opcode and
transmitted as an opcode-bearing ZTSL frame.
The document further specifies the Application Binding Layer (ABL),
the transparent shim through which any application interacts with
ZTSL via a familiar socket-like API, completely insulated from the
underlying trust machinery.
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/.
Rama Hebbar Expires 6 February 2027 [Page 1]
Internet-Draft ZTSL Protocol August 2026
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 February 2027.
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
2.1. Protocol Terms . . . . . . . . . . . . . . . . . . . . . 6
2.2. Opcode Framework Terms . . . . . . . . . . . . . . . . . 7
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
4. End-to-End Communication Flow . . . . . . . . . . . . . . . . 9
4.1. Phase 1 -- Policy Definition . . . . . . . . . . . . . . 9
4.2. Phase 2 -- Server Initialization . . . . . . . . . . . . 9
4.3. Phase 3 -- Managed Client Generation . . . . . . . . . . 9
4.4. Phase 4 -- Client Installation and Device Registration . 10
4.5. Phase 5 -- First Authentication Needed (FAN) . . . . . . 10
4.6. Phase 6 -- Adaptive Protocol Negotiation . . . . . . . . 11
4.7. Phase 7 -- Zession Creation . . . . . . . . . . . . . . . 11
4.8. Phase 8 -- Secure Socket Creation . . . . . . . . . . . . 12
4.9. Phase 9 -- Trust Triangle Establishment . . . . . . . . . 12
4.10. Phase 10 -- Message Preparation and Metadata . . . . . . 12
4.11. Phase 11 -- Triple Signature Generation . . . . . . . . . 12
4.12. Phase 12 -- ZTSL Packet Construction . . . . . . . . . . 13
4.13. Phase 13 -- Server-Side Packet Validation . . . . . . . . 14
4.14. Phase 14 -- Trust-Aware Routing . . . . . . . . . . . . . 14
4.15. Phase 15 -- Receiver-Side Validation . . . . . . . . . . 14
4.16. Phase 16 -- Heartbeat Synchronization . . . . . . . . . . 14
4.17. Phase 17 -- Continuous Trust Evaluation . . . . . . . . . 15
4.18. Phase 18 -- Threat Detection . . . . . . . . . . . . . . 15
4.19. Phase 19 -- Adaptive Recovery . . . . . . . . . . . . . . 15
Rama Hebbar Expires 6 February 2027 [Page 2]
Internet-Draft ZTSL Protocol August 2026
4.20. Phase 20 -- Secure Session Termination . . . . . . . . . 16
5. FAN Architecture . . . . . . . . . . . . . . . . . . . . . . 16
6. Zession Specification . . . . . . . . . . . . . . . . . . . . 17
7. ZTSL Opcode Framework . . . . . . . . . . . . . . . . . . . . 17
7.1. Opcode Namespace Structure . . . . . . . . . . . . . . . 17
7.2. Opcode Encoding . . . . . . . . . . . . . . . . . . . . . 17
7.3. Class 0x00 -- Control Plane (CP) . . . . . . . . . . . . 18
7.4. Class 0x01 -- FAN Operations . . . . . . . . . . . . . . 18
7.5. Class 0x02 -- Zession Management . . . . . . . . . . . . 18
7.6. Class 0x03 -- Socket Operations . . . . . . . . . . . . . 18
7.7. Class 0x04 -- Data Plane (DP) . . . . . . . . . . . . . . 19
7.8. Class 0x05 -- Trust Operations . . . . . . . . . . . . . 19
7.9. Class 0x06 -- Recovery Operations . . . . . . . . . . . . 19
7.10. Class 0x07 -- Audit and Telemetry . . . . . . . . . . . . 20
8. ZTSL Opcode State Machine . . . . . . . . . . . . . . . . . . 20
8.1. State: PRE_FAN . . . . . . . . . . . . . . . . . . . . . 20
8.2. State: FAN_NEGOTIATION . . . . . . . . . . . . . . . . . 20
8.3. State: ZESSION_ACTIVE . . . . . . . . . . . . . . . . . . 20
8.4. State: TRUST_DEGRADED . . . . . . . . . . . . . . . . . . 20
8.5. State: RECOVERY . . . . . . . . . . . . . . . . . . . . . 21
8.6. State: TERMINATION . . . . . . . . . . . . . . . . . . . 21
9. Protocol Phase Opcode Encoding Reference . . . . . . . . . . 21
9.1. FAN Exchange . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Data-Plane Message Flow . . . . . . . . . . . . . . . . . 21
9.3. Heartbeat Synchronization . . . . . . . . . . . . . . . . 22
9.4. Threat Detection and Recovery . . . . . . . . . . . . . . 23
10. Application Binding Layer (ABL) . . . . . . . . . . . . . . . 23
10.1. ABL Socket API . . . . . . . . . . . . . . . . . . . . . 23
10.2. ABL Dispatch Table . . . . . . . . . . . . . . . . . . . 24
11. ZTSL Packet Structure . . . . . . . . . . . . . . . . . . . . 24
12. Trust Mesh Architecture . . . . . . . . . . . . . . . . . . . 25
13. Wire Format Examples . . . . . . . . . . . . . . . . . . . . 25
13.1. FAN_REQ_INITIAL First Bytes . . . . . . . . . . . . . . 25
13.2. DP_DATA_NORMAL First Bytes . . . . . . . . . . . . . . . 26
14. Security Considerations . . . . . . . . . . . . . . . . . . . 26
14.1. Opcode Binding as a Novel Security Primitive . . . . . . 26
14.2. Cryptographic Agility . . . . . . . . . . . . . . . . . 26
14.3. Replay Attack Prevention . . . . . . . . . . . . . . . . 27
14.4. Denial of Service Mitigation . . . . . . . . . . . . . . 27
14.5. Side-Channel Resistance . . . . . . . . . . . . . . . . 27
14.6. Key Management and Perfect Forward Secrecy . . . . . . . 27
14.7. Post-Quantum Readiness . . . . . . . . . . . . . . . . . 27
14.8. Audit and Non-Repudiation . . . . . . . . . . . . . . . 27
14.9. Trust Score Manipulation . . . . . . . . . . . . . . . . 28
14.10. Insider Threat . . . . . . . . . . . . . . . . . . . . . 28
14.11. Physical Security . . . . . . . . . . . . . . . . . . . 28
14.12. Opcode Namespace Exhaustion . . . . . . . . . . . . . . 28
14.13. State Machine Enforcement . . . . . . . . . . . . . . . 28
Rama Hebbar Expires 6 February 2027 [Page 3]
Internet-Draft ZTSL Protocol August 2026
14.14. ABL Buffer Security . . . . . . . . . . . . . . . . . . 28
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
15.1. ZTSL Primary Opcode Class Registry . . . . . . . . . . . 29
15.2. ZTSL Operation Code Sub-Registries . . . . . . . . . . . 29
15.3. ZTSL Frame Flags Registry . . . . . . . . . . . . . . . 29
15.4. ZTSL Adaptive Protocol Identifier Registry . . . . . . . 29
15.5. Well-Known Port Number . . . . . . . . . . . . . . . . . 29
15.6. ALPN Identifier . . . . . . . . . . . . . . . . . . . . 29
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
16.1. Normative References . . . . . . . . . . . . . . . . . . 29
16.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A: Key Term Summary . . . . . . . . . . . . . . . . . . 31
Appendix B: High-Level Communication Flow Summary . . . . . . . . 32
Appendix C: Complete Opcode Reference Table (84 opcodes) . . . . 33
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction
Modern network security has historically relied on perimeter-based
models in which a device or user, once authenticated at the boundary,
is granted implicit trust within the interior network. This approach
has proven fundamentally inadequate in the face of insider threats,
compromised endpoints, lateral movement attacks, and increasingly
distributed application architectures.
The Zero Trust security model [NIST.SP.800-207] mandates that trust
is never implicitly granted and MUST be continuously verified for
every access request, every device, every session, and every network
interaction. While numerous higher-layer protocols have begun
adopting Zero Trust principles, the transport layer has remained
largely unchanged, relying on connection-oriented trust established
once at session initiation and maintained statically thereafter.
The Zero Trust Secure Layer (ZTSL) protocol addresses this gap by
introducing a transport-layer framework that enforces Zero Trust
principles at the protocol level. ZTSL provides:
* A mandatory multi-dimensional trust establishment phase (FAN) that
MUST complete before any data transport begins.
* Continuously verified sessions (Zessions) carrying an auditable,
cryptographically linked hash chain reflecting evolving trust
state.
* Per-packet device validation via the Device Trust Flag (DTF).
* A Triple Signature Model binding every message to its originating
socket, device, and plaintext content hash.
Rama Hebbar Expires 6 February 2027 [Page 4]
Internet-Draft ZTSL Protocol August 2026
* A Trust Triangle Model ensuring sender, server, and receiver
maintain synchronized trust contexts at all times.
* Adaptive Protocol Negotiation allowing the transport substrate to
be selected dynamically based on trust score, network conditions,
and administrator policy.
* Heartbeat Fingerprint (HBF) messages that propagate trust state
rather than merely signaling liveness.
* Adaptive Recovery mechanisms allowing the protocol to survive
partial compromise without requiring application restart.
* A formal Opcode Framework assigning a hierarchical, three-tier
opcode identifier to every protocol operation, enabling
deterministic parsing, state machine enforcement, conformance
testing, and clean extension.
* An Application Binding Layer (ABL) that maps application-level
socket calls to ZTSL opcode sequences transparently, requiring
zero application code modification.
ZTSL operates above the transport layer (TCP, QUIC, SCTP, DCCP) and
below the application layer, serving as a secure transport
abstraction analogous in position - but far richer in trust semantics
- to TLS.
The novel technical contributions of this specification are:
1. A formally specified, hierarchical 24-bit opcode namespace for a
Zero Trust transport protocol, enabling machine-parseable
operation encoding with 16,777,216 addressable opcodes.
2. Opcode Binding: the inclusion of each frame's 24-bit opcode in
the Triple Signature computation, preventing opcode forgery,
cross-opcode replay, and protocol confusion attacks.
3. An opcode-annotated Zession hash chain, embedding a tamper-
evident causal audit trail directly in the cryptographic session
state.
4. An Application Binding Layer specification with a formal Dispatch
Table mapping every standard socket call to an explicit, ordered
ZTSL opcode sequence.
Rama Hebbar Expires 6 February 2027 [Page 5]
Internet-Draft ZTSL Protocol August 2026
2. Terminology and Conventions
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals.
2.1. Protocol Terms
ZTSL Zero Trust Secure Layer - the transport-layer protocol defined
in this document.
Zession A Zero Trust Session: a continuously verified trust context
with a cryptographically linked hash chain reflecting evolving
trust state. Every Zession transition is signed and auditable.
FAN First Authentication Needed - the mandatory multi-dimensional
trust establishment phase that MUST complete before a Zession is
created and data transport begins.
DTF Device Trust Flag - a cryptographic token derived from trusted
device measurements (TPM attestation, Secure Enclave, certificate
fingerprint) carried in every ZTSL packet for per-packet device
validation.
CSRP Client Security Routing Profile - a structured, signed,
versioned profile generated by the ZTSL Server encoding identity,
policies, routing, protocol preferences, and trust thresholds.
Trust Score A numeric value computed by the Trust Engine
representing the current aggregate trust level of a device,
session, or channel.
Socket Fingerprint A cryptographic identifier uniquely bound to a
ZTSL socket and its trust policies and permitted capabilities.
Connection Fingerprint A cryptographic identifier representing a
specific client-to-client communication context established
through the Trust Triangle.
Adaptive Protocol Fingerprint A cryptographic identifier tied to the
negotiated transport protocol and its governing policies.
HBF Heartbeat Fingerprint - a cryptographic structure in Heartbeat
frames synchronizing trust state between all parties in the Trust
Triangle.
Rama Hebbar Expires 6 February 2027 [Page 6]
Internet-Draft ZTSL Protocol August 2026
Trust Triangle The three-way trust relationship among sender, ZTSL
Server, and receiver, in which the server continuously validates
and mediates trust.
Trust Mesh The centralized architecture in which the ZTSL Server
maintains and arbitrates all inter-client trust relationships.
Triple Signature The combination of Socket Signature, Device
Signature, and Message Signature applied to every ZTSL data
message, each with Opcode Binding.
Adaptive Recovery The protocol mechanism by which compromised
cryptographic material, DTFs, Zessions, and CSRPs are regenerated
without requiring application restart.
URG Flag An urgency flag (FrameFlags bit 7) set by the Trust Engine
to signal an immediate trust event; recipient MUST suspend data
forwarding.
2.2. Opcode Framework Terms
Opcode A 24-bit hierarchical identifier (Class.Op.Sub) assigned to
every ZTSL protocol operation.
ZTSL Frame The fundamental encoding unit of the ZTSL protocol - a
TLV structure prefixed with a 24-bit opcode.
Primary Class The high-order 8 bits of the opcode identifying the
broad category of operation.
Operation Code (Op) The middle 8 bits identifying the specific
operation within a Primary Class.
Sub-Code The low-order 8 bits identifying a variant or sub-operation
within an operation.
ABL Application Binding Layer - the transparent shim between
application socket calls and ZTSL opcode sequences.
Opcode State Machine The finite-state automaton governing which
opcodes are legal in each ZTSL protocol state.
Opcode Binding The inclusion of the 24-bit opcode in the Triple
Signature computation, preventing opcode forgery or replay.
Dispatch Table The ABL mapping from application socket call to ZTSL
opcode sequence.
Rama Hebbar Expires 6 February 2027 [Page 7]
Internet-Draft ZTSL Protocol August 2026
3. Architectural Overview
The ZTSL architecture is organized around a central ZTSL Server that
functions as the trust authority for all client communications. No
direct client-to-client communication occurs without server
mediation. All communication follows the Trust Triangle model.
+----------------------------------------------------+
| ZTSL Server |
| |
| +------------------+ +---------------------+ |
| | Policy Engine | | Identity Manager | |
| +------------------+ +---------------------+ |
| +------------------+ +---------------------+ |
| | Trust Engine | | Zession Manager | |
| +------------------+ +---------------------+ |
| +------------------+ +---------------------+ |
| | Routing Engine | | Recovery Engine | |
| +------------------+ +---------------------+ |
| +------------------+ +---------------------+ |
| | FAN Engine | | Adaptive Protocol | |
| +------------------+ | Engine | |
| +------------------+ +---------------------+ |
| | Heartbeat Engine | | Audit Engine | |
| +------------------+ +---------------------+ |
+----------------------------------------------------+
^ ^
| Trust Triangle |
+-------+--------+ +---------+------+
| Client A | | Client B |
| (ZTSL Agent) | | (ZTSL Agent) |
+----------------+ +----------------+
Figure 1: ZTSL Architecture
The client communication model is strictly server-mediated:
Client A --> ZTSL Server --> Client B
The ZTSL Server comprises twelve internal engine components, all of
which MUST be operational before client communication is permitted.
The ZTSL Agent runs on each client endpoint as a transparent system
service, implementing the ABL that intercepts standard socket calls
and translates them into ZTSL opcode sequences without any
application code modification.
Rama Hebbar Expires 6 February 2027 [Page 8]
Internet-Draft ZTSL Protocol August 2026
4. End-to-End Communication Flow
The ZTSL communication lifecycle consists of twenty sequential
phases. Each phase MUST complete successfully before the next
begins. Failure in any phase MUST result in termination of the
current attempt and, depending on the phase, MUST trigger Adaptive
Recovery or audit logging.
4.1. Phase 1 -- Policy Definition
All ZTSL communication originates from administrator-defined
policies. Policies constitute the root of trust for the entire ZTSL
environment and MUST be defined before any server is initialized.
Policies MUST specify, at minimum, the following domains: Device
Trust, User Identity, Application Trust, Network Trust, Communication
Methods, Encryption, Routing, Adaptive Protocol, Heartbeat, Trust
Thresholds, Recovery, and Audit.
Policies MUST be versioned. Any policy update MUST increment the
Policy Version and MUST be propagated to all active Zessions and CSRP
profiles.
4.2. Phase 2 -- Server Initialization
The administrator initializes the ZTSL Server. The server MUST load
and activate the following components in this order: (1) Policy
Engine, (2) Identity Manager, (3) Certificate Manager, (4) Client
Generator, (5) FAN Engine, (6) Trust Engine, (7) Routing Engine, (8)
Adaptive Protocol Engine, (9) Heartbeat Engine, (10) Zession Manager,
(11) Recovery Engine, (12) Audit Engine.
Upon successful initialization, the server becomes the central trust
authority. No client communication MAY occur before initialization
is complete.
4.3. Phase 3 -- Managed Client Generation
The ZTSL Server generates every client artifact, ensuring all clients
operate within administrator-defined trust boundaries from
installation. For each endpoint, the server MUST generate and
securely distribute: Client Certificate, Client Private Key, Identity
Manager ID, Device Trust Flag (DTF), Socket Profiles, Communication
Policies, Adaptive Protocol Configuration, Routing Policies, Trust
Thresholds, Heartbeat Configuration, Initial Zession Template, and
CSRP.
Rama Hebbar Expires 6 February 2027 [Page 9]
Internet-Draft ZTSL Protocol August 2026
Generated artifacts MUST be distributed over a secure out-of-band
channel employing mutual authentication and end-to-end encryption
independent of ZTSL.
4.4. Phase 4 -- Client Installation and Device Registration
Upon receiving generated artifacts, the client software is installed
on the endpoint. During installation, the client collects trusted
device measurements: Device Certificate Fingerprint (SHA-256),
Platform Attestation (TPM 2.0 or Secure Enclave), OS Information,
Application Fingerprint, Hardware Characteristics, Network
Characteristics, and Identity Manager ID.
The server MUST validate the registration before acknowledging it.
An endpoint failing to provide valid measurements MUST NOT be
permitted to proceed to the FAN phase.
4.5. Phase 5 -- First Authentication Needed (FAN)
A registered client MUST NOT initiate any ZTSL Zession without first
completing a successful FAN exchange. FAN establishes the initial
multi-dimensional trust context.
The FAN Request (Opcode: 0x01.0x01.0x01 FAN_REQ_INITIAL) MUST
contain: identity_manager_id (128 bits), device_trust_flag (DTF
Structure), certificate_fingerprint (SHA-256, 256 bits),
application_fingerprint (SHA-256, 256 bits), device_measurements
(Attestation Report), network_measurements (Network Evidence),
policy_version (32 bits), nonce (256 bits random), timestamp (64-bit
Unix nanoseconds), and client_signature (Ed25519 or ECDSA P-384).
The server MUST validate through six stages in order: (1) Device
Trust Validation, (2) Application Trust Validation, (3) Identity
Trust Validation, (4) Certificate Trust Validation, (5) Policy Trust
Validation, (6) Network Trust Validation. Failure at any stage MUST
cause rejection with the appropriate FAN_REJECT_* opcode.
Security requirements:
* FAN requests MUST be signed by the client's private key.
* The server MUST verify the nonce has not been seen before within
the validity window.
* FAN requests with timestamp outside 60-second window MUST be
rejected with 0x01.0x05.0x08 (FAN_REJECT_SKEW).
Rama Hebbar Expires 6 February 2027 [Page 10]
Internet-Draft ZTSL Protocol August 2026
* Failed FAN requests MUST be logged by the Audit Engine with full
diagnostic context.
* Configurable exponential backoff and account lockout SHOULD be
enforced after repeated FAN failures.
4.6. Phase 6 -- Adaptive Protocol Negotiation
Following a successful FAN, the Adaptive Protocol Engine selects the
optimal transport substrate for the Zession based on: Network
Latency, Packet Loss Rate, Security Policy, Trust Score,
Communication Type, and Device Capability.
Permitted transport substrates: (1) QUIC [RFC9000] - preferred for
low-latency, high-security; (2) TCP [RFC793] - preferred for
compatibility; (3) SCTP [RFC4960] - for multi-homing; (4) DCCP
[RFC4340] - datagram with congestion control; (5) HTTP/HTTPS Tunnel -
last-resort fallback.
4.7. Phase 7 -- Zession Creation
A Zession is fundamentally distinct from a conventional session.
Where a conventional session represents connection state, a Zession
represents a continuously verified trust context with an auditable
cryptographic history.
A Zession contains: zession_id (128-bit UUID), previous_hash (SHA-
256, 256 bits), current_hash (SHA-256, 256 bits), trust_score (32
bits), device_trust_flag (DTF), socket_fingerprint (SHA-256),
adaptive_protocol_fp (SHA-256), connection_fingerprint (SHA-256),
heartbeat_fingerprint (HBF), policy_version (32 bits),
cryptographic_state (opaque), creation_timestamp (64 bits),
last_updated (64 bits).
Both the server and the client MUST maintain identical, synchronized
copies of the Zession. Any discrepancy MUST be treated as a trust
anomaly and MUST trigger Threat Detection (Section 4.18).
The Zession Hash Chain Extension Rule: at each state transition, the
hash chain MUST be extended as follows:
new_hash = SHA-256(prev_hash || event_opcode_24bit
|| trust_score || timestamp || dtf)
The event_opcode_24bit is the 24-bit opcode of the frame that
triggered the transition, embedding a tamper-evident, opcode-
annotated audit trail in the cryptographic session state.
Rama Hebbar Expires 6 February 2027 [Page 11]
Internet-Draft ZTSL Protocol August 2026
4.8. Phase 8 -- Secure Socket Creation
When an application requests communication, it MUST request a ZTSL
Socket rather than a conventional transport socket. Each ZTSL Socket
carries: socket_id (UUID, 128 bits), socket_fingerprint,
allowed_protocols, allowed_data_size, allowed_message_types, and
allowed_policies.
A socket MUST NOT carry traffic outside its authorized parameters.
Any attempt MUST trigger 0x05.0x03.0x06 (TR_THREAT_POLICY_VIOL).
4.9. Phase 9 -- Trust Triangle Establishment
Before any application-level communication may proceed between Client
A and Client B, the server MUST establish the Trust Triangle,
binding: Sender <-> Server (server validates A's Zession, DTF, Socket
Fingerprint), Server <-> Receiver (server validates B's Zession, DTF,
Socket Fingerprint), and Sender <-> Receiver (server maintains
Connection Fingerprint binding A and B).
Trust Triangle establishment is initiated by 0x03.0x03.0x00
(SK_CONNECT) and confirmed by 0x03.0x03.0x01 (SK_CONNECT_ACK)
carrying the assigned Connection Fingerprint.
4.10. Phase 10 -- Message Preparation and Metadata
Before a message payload is transmitted, the sending client MUST
prepare message metadata including: message_id (UUID, 128 bits),
sender_id (128 bits), receiver_id (128 bits), timestamp (64-bit Unix
nanoseconds), priority (8 bits: 1=CRITICAL, 2=HIGH, 3=NORMAL, 4=LOW,
5=BACKGROUND), message_type (8 bits), routing_class (8 bits),
policy_id (64 bits), content_length (32 bits).
Payload encryption MUST occur after the Triple Signature is computed.
4.11. Phase 11 -- Triple Signature Generation
Every ZTSL data message MUST carry three independent cryptographic
signatures. The 24-bit opcode is included in every signature's
signed input - this constitutes Opcode Binding (Section 14.1).
The correct signing order MUST be followed:
1. H = SHA-256(plaintext payload)
2. SockSig = Sign(sk_socket, opcode || SockFP || metadata)
Rama Hebbar Expires 6 February 2027 [Page 12]
Internet-Draft ZTSL Protocol August 2026
3. DevSig = Sign(sk_device, opcode || DTF || Cert || MsgID ||
timestamp)
4. MsgSig = Sign(sk_client, opcode || SockSig || DevSig ||
metadata || H)
5. EncPayload = AEAD(plaintext, session_key)
6. Assemble ZTSL frame with EncPayload and all three signatures.
Both server and receiver MUST independently verify all three
signatures. Failure to verify any MUST result in packet rejection
and a TR_THREAT_* opcode being raised.
4.12. Phase 12 -- ZTSL Packet Construction
Every ZTSL packet carries its full trust context, ensuring each
packet is independently verifiable.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode[Cl] | Opcode[Op] | Opcode[Sub] | FrameFlags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Length (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zession ID (128 bits) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trust Context Hash (256 bits) |
| SHA-256( ZessionStateHash XOR DTF ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Signature (variable) |
| Covers: Opcode || Flags || Length || ZessionID || |
| SeqNum || TrustContextHash || Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Payload (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ZTSL Frame Wire Format
Rama Hebbar Expires 6 February 2027 [Page 13]
Internet-Draft ZTSL Protocol August 2026
Frame Flags Bitmask (8 bits): Bit 7 (URG) - urgent trust event,
suspend forwarding; Bit 6 (ACK) - acknowledges previous frame; Bit 5
(EXT) - extension fields present; Bit 4 (ENC) - payload encrypted
(AEAD); Bit 3 (SIG) - Frame Signature present, MUST always be 1; Bit
2 (FIN) - final frame in multi-frame sequence; Bit 1 (FRG) - fragment
of larger message; Bit 0 (RES) - reserved, MUST be zero.
Every frame MUST have bit 3 (SIG) set. Frames with SIG=0 MUST be
rejected.
4.13. Phase 13 -- Server-Side Packet Validation
Upon receiving a ZTSL packet, the server MUST validate it through ten
ordered steps: (1) Packet Integrity, (2) Replay Protection (anti-
replay window MUST cover at least 64 sequence numbers), (3) Timestamp
Validation (60-second window), (4) Socket Signature Verification with
Opcode Binding, (5) Device Trust Flag Validation, (6) Message
Signature Verification, (7) Policy Validation, (8) Trust Score
Evaluation, (9) Zession Hash Validation, (10) Routing Validation.
Failure at any step MUST cause immediate packet rejection, Audit
Engine notification, and Trust Engine notification.
4.14. Phase 14 -- Trust-Aware Routing
The Routing Engine performs trust-aware forwarding. A packet MUST
NOT be forwarded if the receiver's Zession is invalid, DTF has
failed, or Trust Score is below minimum. Such packets MUST be
quarantined and Trust Engine notified with 0x04.0x06.0x01
(DP_ROUTE_REJECT).
4.15. Phase 15 -- Receiver-Side Validation
The receiving client independently validates every packet through
eight ordered steps: (1) Connection Fingerprint Validation, (2)
Socket Fingerprint Validation, (3) Device Trust Validation, (4)
Triple Signature Verification with Opcode Binding confirmation, (5)
Policy Verification, (6) Replay Protection, (7) Payload Decryption
(AES-256-GCM or ChaCha20-Poly1305), (8) Deliver to Application via
ABL recv().
4.16. Phase 16 -- Heartbeat Synchronization
ZTSL Heartbeat frames (0x05.0x01.0x00, TR_HEARTBEAT) are exchanged at
the configured interval. Unlike TCP keep-alive, Heartbeat frames
carry an HBF synchronizing trust state between all Trust Triangle
parties.
Rama Hebbar Expires 6 February 2027 [Page 14]
Internet-Draft ZTSL Protocol August 2026
The Zession hash chain is extended at each heartbeat:
new_hash = SHA-256(prev_hash || 0x05.0x01.0x00
|| trust_score || timestamp || dtf)
If a client misses a Heartbeat within the tolerance window, the
server MUST: (1) Emit 0x05.0x01.0x02 (TR_HEARTBEAT_MISS) and
decrement Trust Score; (2) Emit 0x05.0x02.0x01 (TR_SCORE_BELOW_MIN)
if threshold crossed; (3) Emit 0x02.0x05.0x02 (ZS_CLOSE_FORCED) if
max misses reached.
4.17. Phase 17 -- Continuous Trust Evaluation
Throughout the lifetime of a Zession, the Trust Engine continuously
evaluates trust state across seven dimensions: Device State,
Application Integrity, Policy Updates, Trust Score Trend, Network
State, Heartbeat Consistency, and Zession Hash Chain.
4.18. Phase 18 -- Threat Detection
The Trust Engine monitors for threat indicators including:
application binary modification (CRITICAL, TR_THREAT_APP_MOD), device
measurement mismatch (CRITICAL, TR_THREAT_DTF_FAIL), Zession hash
chain broken (CRITICAL, TR_THREAT_HASH_BREAK), replay attack
(CRITICAL, TR_THREAT_REPLAY), fingerprint mismatch (HIGH,
TR_THREAT_FP_MISMATCH), policy violation (HIGH,
TR_THREAT_POLICY_VIOL), critical trust score (HIGH,
TR_SCORE_CRITICAL), clock skew (MEDIUM, TR_THREAT_SKEW), and
heartbeat gap (MEDIUM, TR_HEARTBEAT_MISS).
Upon detecting a threat, the Trust Engine MUST: (1) Mark the Zession
as COMPROMISED; (2) Emit TR_URG with URG flag set; (3) Emit
TR_URG_SUSPEND, ceasing forwarding; (4) Notify Audit Engine with
AU_EVENT_SECURITY; (5) Initiate Adaptive Recovery if recoverable,
otherwise emit ZS_CLOSE_FORCED.
The protocol MUST NOT silently continue communication when trust
context has been lost.
4.19. Phase 19 -- Adaptive Recovery
When the Trust Engine determines that trust context can be re-
established, the Recovery Engine initiates Adaptive Recovery in six
steps:
1. New Cryptographic Keys: REC_KEY_EXCHANGE (X25519 or ECDH P-384),
REC_KEY_CONFIRM.
Rama Hebbar Expires 6 February 2027 [Page 15]
Internet-Draft ZTSL Protocol August 2026
2. Fresh Device Attestation: REC_DTF_REQUEST, REC_DTF_RESPONSE,
REC_DTF_ACCEPT (or REC_DTF_REJECT leading to REC_FAILED).
3. New Fingerprints: REC_FP_UPDATE.
4. New Zession: REC_ZESSION_NEW (genesis links Recovery ID),
REC_ZESSION_SYNC.
5. Updated CSRP: REC_CSRP_UPDATE, REC_CSRP_ACK.
6. Audit and Resume: AU_RECOVERY_LOG, REC_RESUME, TR_URG_RESUME.
Adaptive Recovery MUST be transparent to the application. The ABL
MUST buffer application send() calls during Recovery and MUST replay
them after REC_RESUME. If recovery fails after the maximum
configured attempts, the server MUST emit REC_FAILED followed by
REC_TERMINATE_ZESSION, and a new FAN exchange MUST be required.
4.20. Phase 20 -- Secure Session Termination
Termination opcode sequence: (1) ZS_CLOSE - initiator requests close;
(2) ZS_CLOSE_ACK - mutual signed ACK; (3) AU_ZESSION_CLOSE - final
audit committed (Final Trust Score, Final Zession Hash, Session
Metrics, Security Events); (4) SK_CLOSE; (5) SK_CLOSE_ACK; (6) All
session keys, IVs, and DTF-derived material MUST be securely erased.
Hardware-protected keys MUST be revoked. (7) Zession marked CLOSED.
(8) Transport connection terminated.
A new FAN exchange MUST be completed before a new Zession can be
created.
5. FAN Architecture
FAN is the mandatory multi-dimensional trust establishment gateway.
No Zession MAY be created without a successful FAN exchange. The six
validation dimensions are: Device Trust, Application Trust, Identity
Trust, Certificate Trust, Policy Trust, and Network Trust. Each
dimension MUST pass for FAN_ACCEPT to be issued.
FAN rejection opcodes range from 0x01.0x05.0x01 (FAN_REJECT_DTF)
through 0x01.0x05.0x08 (FAN_REJECT_SKEW), covering all specific
rejection reasons. The specific opcode MUST be returned to permit
the client to diagnose the failure without exposing unnecessary
server state.
Rama Hebbar Expires 6 February 2027 [Page 16]
Internet-Draft ZTSL Protocol August 2026
6. Zession Specification
A Zession is a continuously verified trust context superseding the
conventional concept of a network session. Its five key
distinguishing properties are:
1. Hash Chain Integrity: Every Zession state transition produces a
new hash linked to its predecessor using the triggering opcode.
Breaks MUST trigger TR_THREAT_HASH_BREAK.
2. Per-Heartbeat Synchronization: Zession state is synchronized at
every Heartbeat interval, not merely at session initiation.
3. Trust Score Integration: The Zession carries the current Trust
Score, reflecting real-time trust evaluation.
4. Adaptive Recovery Continuity: When Adaptive Recovery occurs, the
new Zession genesis block MUST reference the Recovery ID,
maintaining full auditability.
5. Secure Termination Record: Upon Zession closure, all terminal
state is committed to the Audit Engine before cryptographic
material is retired.
7. ZTSL Opcode Framework
7.1. Opcode Namespace Structure
The 24-bit opcode is structured as three 8-bit fields: Bits 23-16
(Primary Class), Bits 15-8 (Operation Code), Bits 7-0 (Sub-Code).
This provides a namespace capacity of 2^24 = 16,777,216 distinct
opcodes.
Opcode notation: CLASS.OP.SUB in hexadecimal. For example,
0x01.0x05.0x07 = Class FAN, Op REJECT, Sub REPLAY.
7.2. Opcode Encoding
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Class | Operation Code | Sub-Code |
| (8 bits) | (8 bits) | (8 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Opcode Encoding (3-byte, big-endian)
Rama Hebbar Expires 6 February 2027 [Page 17]
Internet-Draft ZTSL Protocol August 2026
The opcode MUST be the first three bytes of every ZTSL Frame.
Implementations MUST reject frames whose opcode is not in the IANA
ZTSL Opcode Registry.
7.3. Class 0x00 -- Control Plane (CP)
Control Plane opcodes include: CP_VERSION_HELLO (0x00.0x00.0x00),
CP_VERSION_ACCEPT (0x00.0x00.0x01), CP_VERSION_REJECT
(0x00.0x00.0x02), CP_ERROR (0x00.0x01.0x00), CP_ERROR_FATAL
(0x00.0x01.0x01), CP_ERROR_WARN (0x00.0x01.0x02), CP_POLICY_UPDATE
(0x00.0x02.0x00), CP_POLICY_ACK (0x00.0x02.0x01), CP_KEEPALIVE
(0x00.0x03.0x00).
7.4. Class 0x01 -- FAN Operations
FAN opcodes include: FAN_REQ_INITIAL (0x01.0x01.0x01), FAN_REQ_REAUTH
(0x01.0x01.0x02), FAN_REQ_RECOVERY (0x01.0x01.0x03), FAN_CHALLENGE
(0x01.0x02.0x00), FAN_CHALLENGE_DTF (0x01.0x02.0x01),
FAN_CHALLENGE_NONCE (0x01.0x02.0x02), FAN_RESPONSE (0x01.0x03.0x00),
FAN_ACCEPT (0x01.0x04.0x00), FAN_ACCEPT_DEGRADED (0x01.0x04.0x01),
FAN_REJECT_DTF (0x01.0x05.0x01) through FAN_REJECT_SKEW
(0x01.0x05.0x08), FAN_BACKOFF (0x01.0x06.0x00).
7.5. Class 0x02 -- Zession Management
Zession Management opcodes include: ZS_CREATE (0x02.0x01.0x00),
ZS_CREATE_ACK (0x02.0x01.0x01), ZS_UPDATE (0x02.0x02.0x00),
ZS_UPDATE_TRUST (0x02.0x02.0x01), ZS_UPDATE_POLICY (0x02.0x02.0x02),
ZS_UPDATE_PROTOCOL (0x02.0x02.0x03), ZS_SYNC (0x02.0x03.0x00),
ZS_SYNC_ACK (0x02.0x03.0x01), ZS_SYNC_MISMATCH (0x02.0x03.0x02),
ZS_DEGRADE (0x02.0x04.0x00), ZS_DEGRADE_RECOVER (0x02.0x04.0x01),
ZS_CLOSE (0x02.0x05.0x00), ZS_CLOSE_ACK (0x02.0x05.0x01),
ZS_CLOSE_FORCED (0x02.0x05.0x02).
7.6. Class 0x03 -- Socket Operations
Socket opcodes include: SK_CREATE (0x03.0x01.0x00), SK_CREATE_ACK
(0x03.0x01.0x01), SK_CREATE_REJECT (0x03.0x01.0x02), SK_BIND
(0x03.0x02.0x00), SK_BIND_ACK (0x03.0x02.0x01), SK_CONNECT
(0x03.0x03.0x00), SK_CONNECT_ACK (0x03.0x03.0x01), SK_CONNECT_REJECT
(0x03.0x03.0x02), SK_CLOSE (0x03.0x04.0x00), SK_CLOSE_ACK
(0x03.0x04.0x01), SK_PROFILE (0x03.0x05.0x00), SK_PROFILE_UPDATE
(0x03.0x05.0x01).
Rama Hebbar Expires 6 February 2027 [Page 18]
Internet-Draft ZTSL Protocol August 2026
7.7. Class 0x04 -- Data Plane (DP)
Data Plane opcodes include: DP_DATA_CRITICAL (0x04.0x01.0x01),
DP_DATA_HIGH (0x04.0x01.0x02), DP_DATA_NORMAL (0x04.0x01.0x03),
DP_DATA_LOW (0x04.0x01.0x04), DP_DATA_BACKGROUND (0x04.0x01.0x05),
DP_DATA_ACK (0x04.0x02.0x00), DP_DATA_NACK (0x04.0x02.0x01),
DP_META_ONLY (0x04.0x03.0x00), DP_FRAGMENT (0x04.0x04.0x00),
DP_FRAGMENT_LAST (0x04.0x04.0x01), DP_SIGN_SOCKET (0x04.0x05.0x00),
DP_SIGN_DEVICE (0x04.0x05.0x01), DP_SIGN_MESSAGE (0x04.0x05.0x02),
DP_ROUTE_ANNOUNCE (0x04.0x06.0x00), DP_ROUTE_REJECT (0x04.0x06.0x01).
All three signatures in DP_DATA_* frames include the 24-bit opcode in
their signed input - this is Opcode Binding (Section 14.1).
Substituting any opcode value in a captured frame immediately
invalidates the frame signature.
7.8. Class 0x05 -- Trust Operations
Trust opcodes include: TR_HEARTBEAT (0x05.0x01.0x00),
TR_HEARTBEAT_ACK (0x05.0x01.0x01), TR_HEARTBEAT_MISS
(0x05.0x01.0x02), TR_SCORE_UPDATE (0x05.0x02.0x00),
TR_SCORE_BELOW_MIN (0x05.0x02.0x01), TR_SCORE_CRITICAL
(0x05.0x02.0x02), TR_THREAT_DETECT (0x05.0x03.0x00),
TR_THREAT_DTF_FAIL (0x05.0x03.0x01), TR_THREAT_APP_MOD
(0x05.0x03.0x02), TR_THREAT_HASH_BREAK (0x05.0x03.0x03),
TR_THREAT_REPLAY (0x05.0x03.0x04), TR_THREAT_FP_MISMATCH
(0x05.0x03.0x05), TR_THREAT_POLICY_VIOL (0x05.0x03.0x06),
TR_THREAT_SKEW (0x05.0x03.0x07), TR_URG (0x05.0x04.0x00),
TR_URG_SUSPEND (0x05.0x04.0x01), TR_URG_RESUME (0x05.0x04.0x02).
7.9. Class 0x06 -- Recovery Operations
Recovery opcodes include: REC_INITIATE (0x06.0x01.0x00),
REC_INITIATE_CLIENT (0x06.0x01.0x01), REC_KEY_EXCHANGE
(0x06.0x02.0x00), REC_KEY_CONFIRM (0x06.0x02.0x01), REC_DTF_REQUEST
(0x06.0x03.0x00), REC_DTF_RESPONSE (0x06.0x03.0x01), REC_DTF_ACCEPT
(0x06.0x03.0x02), REC_DTF_REJECT (0x06.0x03.0x03), REC_FP_UPDATE
(0x06.0x04.0x00), REC_ZESSION_NEW (0x06.0x05.0x00), REC_ZESSION_SYNC
(0x06.0x05.0x01), REC_CSRP_UPDATE (0x06.0x06.0x00), REC_CSRP_ACK
(0x06.0x06.0x01), REC_RESUME (0x06.0x07.0x00), REC_FAILED
(0x06.0x07.0x01), REC_TERMINATE_ZESSION (0x06.0x08.0x00).
The REC_INITIATE frame MUST include the Recovery Trigger Opcode field
- the exact TR_THREAT_* opcode that caused the recovery - as a signed
field. Clients MUST verify this field matches the most recently
received TR_THREAT_* opcode. A mismatch MUST be treated as
CP_ERROR_FATAL.
Rama Hebbar Expires 6 February 2027 [Page 19]
Internet-Draft ZTSL Protocol August 2026
7.10. Class 0x07 -- Audit and Telemetry
Audit opcodes include: AU_EVENT (0x07.0x01.0x00), AU_EVENT_SECURITY
(0x07.0x01.0x01), AU_EVENT_TRUST (0x07.0x01.0x02), AU_EVENT_POLICY
(0x07.0x01.0x03), AU_ZESSION_OPEN (0x07.0x02.0x00), AU_ZESSION_CLOSE
(0x07.0x02.0x01), AU_METRICS (0x07.0x03.0x00), AU_NONREPUDIATION
(0x07.0x04.0x00), AU_RECOVERY_LOG (0x07.0x05.0x00).
8. ZTSL Opcode State Machine
The ZTSL Opcode State Machine defines six states. Any opcode
received in a state where it is not listed MUST be treated as a
CP_ERROR_FATAL event, and the Zession MUST be terminated.
8.1. State: PRE_FAN
Legal opcodes: CP_VERSION_HELLO, CP_VERSION_ACCEPT,
CP_VERSION_REJECT, CP_ERROR, CP_ERROR_FATAL, FAN_REQ_INITIAL,
FAN_CHALLENGE_* (0x01.0x02.*), FAN_RESPONSE, FAN_REJECT_*
(0x01.0x05.*), FAN_BACKOFF. All other opcodes result in
CP_ERROR_FATAL.
8.2. State: FAN_NEGOTIATION
Legal opcodes: All PRE_FAN opcodes, plus FAN_ACCEPT,
FAN_ACCEPT_DEGRADED, FAN_REQ_REAUTH. Transitions to ZESSION_ACTIVE
on FAN_ACCEPT or FAN_ACCEPT_DEGRADED; returns to PRE_FAN on
FAN_REJECT_* or FAN_BACKOFF.
8.3. State: ZESSION_ACTIVE
Legal opcodes: All Control Plane (except CP_VERSION_HELLO),
ZS_UPDATE_*, ZS_SYNC_*, ZS_DEGRADE (-> TRUST_DEGRADED), ZS_CLOSE, all
Socket Operations (0x03.*.*), all Data Plane (0x04.*.*),
TR_HEARTBEAT_*, TR_SCORE_*, TR_THREAT_* (-> TRUST_DEGRADED or
RECOVERY), TR_URG, all Audit (0x07.*.*). Recovery opcodes (0x06.*.*)
and FAN opcodes (except FAN_REQ_REAUTH) are illegal and MUST result
in CP_ERROR_FATAL.
8.4. State: TRUST_DEGRADED
Legal opcodes: Control Plane, ZS_UPDATE_*, ZS_SYNC_*,
ZS_DEGRADE_RECOVER (-> RECOVERY), ZS_CLOSE_*, TR_HEARTBEAT_*,
TR_SCORE_*, TR_THREAT_*, TR_URG_*, Audit. Data Plane opcodes
(0x04.*.*) SHOULD be suspended; ABL MUST buffer application sends.
Rama Hebbar Expires 6 February 2027 [Page 20]
Internet-Draft ZTSL Protocol August 2026
8.5. State: RECOVERY
Legal opcodes: CP_ERROR_*, TR_URG_SUSPEND, all Recovery (0x06.*.*),
all Audit (0x07.*.*), FAN_REQ_RECOVERY (if policy requires re-FAN),
ZS_CREATE, ZS_CREATE_ACK. Data Plane opcodes MUST be rejected with
CP_ERROR_FATAL. Transitions to ZESSION_ACTIVE on REC_RESUME; to
TERMINATION on REC_FAILED or REC_TERMINATE_ZESSION.
8.6. State: TERMINATION
Legal opcodes: ZS_CLOSE_*, CP_ERROR_*, SK_CLOSE, SK_CLOSE_ACK, all
Audit. All other opcodes are silently discarded. Connection MUST be
torn down after SK_CLOSE_ACK.
9. Protocol Phase Opcode Encoding Reference
9.1. FAN Exchange
Client Server
| |
|--- 0x00.0x00.0x00 CP_VERSION_HELLO ----> |
|<-- 0x00.0x00.0x01 CP_VERSION_ACCEPT ---- |
| |
|--- 0x01.0x01.0x01 FAN_REQ_INITIAL -----> |
| [IM_ID, CertFP, AppFP, DTF, |
| Attestation, NetFP, PolicyVer, |
| Nonce, Timestamp, ClientSig] |
| |
| [Server evaluates 6 FAN dimensions] |
| |
|<-- 0x01.0x04.0x00 FAN_ACCEPT ----------- |
| [ZessionID, TrustScore:95, |
| GenesisHash, Transport:QUIC, |
| APFingerprint, PolicyVer, |
| HBInterval:5000ms, ServerSig] |
| |
|--- 0x02.0x01.0x01 ZS_CREATE_ACK -------> |
State: PRE_FAN -> ZESSION_ACTIVE
Figure 4: FAN Exchange Opcode Sequence
9.2. Data-Plane Message Flow
Rama Hebbar Expires 6 February 2027 [Page 21]
Internet-Draft ZTSL Protocol August 2026
APPLICATION: mySocket.send("Hello Bob")
[1] 0x03.0x01.0x00 SK_CREATE
[2] 0x03.0x01.0x01 SK_CREATE_ACK SocketID + SockFP
[3] 0x03.0x03.0x00 SK_CONNECT Trust Triangle A->B
[4] 0x03.0x03.0x01 SK_CONNECT_ACK ConnFP assigned
[5] Opcode Binding -- Triple Signature:
SockSig = Sign(sk_socket,
0x04.0x01.0x03 || SocketFP || MsgMeta)
DevSig = Sign(sk_device,
0x04.0x01.0x03 || DTF || DevCert
|| MsgID || Ts)
H = SHA-256("Hello Bob")
MsgSig = Sign(sk_client,
0x04.0x01.0x03 || SockSig || DevSig
|| MsgMeta || H)
Enc = AES-256-GCM("Hello Bob", session_key)
[6] 0x04.0x01.0x03 DP_DATA_NORMAL (-> Server)
[SERVER: 10-step validation -- all pass]
[7] 0x04.0x01.0x03 DP_DATA_NORMAL (-> Bob)
[RECEIVER: 8-step validation, decrypt -> "Hello Bob"]
[8] 0x04.0x02.0x00 DP_DATA_ACK
APPLICATION: data = mySocket.recv() -> "Hello Bob"
Figure 5: Data-Plane Opcode Sequence with Opcode Binding
9.3. Heartbeat Synchronization
Client Server
| |
|--- 0x05.0x01.0x00 TR_HEARTBEAT -------> |
| [ZessionID, CurrHash, PrevHash, |
| TrustScore, DTF, SockFP, ConnFP, |
| APFP, HBF_Counter++, SessionState, |
| PolicyVer, Timestamp, HBFSig] |
| |
|<-- 0x05.0x01.0x01 TR_HEARTBEAT_ACK ----- |
| [ZessionID, UpdatedHash, ServerSig] |
| |
[Both extend Zession hash chain:
new_hash = SHA-256(prev || 0x05.0x01.0x00
|| score || ts || dtf)]
Figure 6: Heartbeat Opcode Sequence
Rama Hebbar Expires 6 February 2027 [Page 22]
Internet-Draft ZTSL Protocol August 2026
9.4. Threat Detection and Recovery
0x05.0x03.0x02 TR_THREAT_APP_MOD
0x05.0x04.0x00 TR_URG (URG flag = 1)
0x05.0x04.0x01 TR_URG_SUSPEND (forwarding SUSPENDED)
0x07.0x01.0x01 AU_EVENT_SECURITY
0x06.0x01.0x00 REC_INITIATE (TriggerOpcode=0x05.0x03.0x02)
0x06.0x02.0x00 REC_KEY_EXCHANGE
0x06.0x02.0x01 REC_KEY_CONFIRM
0x06.0x03.0x00 REC_DTF_REQUEST
0x06.0x03.0x01 REC_DTF_RESPONSE
0x06.0x03.0x02 REC_DTF_ACCEPT
0x06.0x04.0x00 REC_FP_UPDATE
0x06.0x05.0x00 REC_ZESSION_NEW
0x06.0x05.0x01 REC_ZESSION_SYNC
0x06.0x06.0x00 REC_CSRP_UPDATE
0x06.0x06.0x01 REC_CSRP_ACK
0x07.0x05.0x00 AU_RECOVERY_LOG
0x06.0x07.0x00 REC_RESUME
0x05.0x04.0x02 TR_URG_RESUME
State: RECOVERY -> ZESSION_ACTIVE
Application: unaware; buffered sends replayed
Figure 7: Recovery Opcode Sequence
10. Application Binding Layer (ABL)
The ABL is the transparent integration point between application-
level socket operations and the ZTSL Opcode Framework.
10.1. ABL Socket API
Rama Hebbar Expires 6 February 2027 [Page 23]
Internet-Draft ZTSL Protocol August 2026
/* Socket Creation */
ztsl_socket_t ztsl_socket(int domain, int type, int protocol);
/* Connection */
int ztsl_connect(ztsl_socket_t sock,
const ztsl_addr_t *addr,
socklen_t addrlen);
/* Data Transfer */
ssize_t ztsl_send(ztsl_socket_t sock, const void *buf,
size_t len, int flags);
ssize_t ztsl_recv(ztsl_socket_t sock, void *buf,
size_t len, int flags);
/* Closing */
int ztsl_close(ztsl_socket_t sock);
/* Trust Query (optional) */
int ztsl_trust_score(ztsl_socket_t sock, uint32_t *score_out);
int ztsl_zession_state(ztsl_socket_t sock,
ztsl_zession_state_t *state_out);
Applications MUST NOT configure TLS or encryption parameters
directly. The ABL handles all security, key management, and trust
machinery.
10.2. ABL Dispatch Table
The ABL Dispatch Table maps application API calls to ZTSL opcode
sequences: ztsl_socket() emits CP_VERSION_HELLO, CP_VERSION_ACCEPT,
SK_CREATE, SK_CREATE_ACK; ztsl_connect() emits FAN_REQ_INITIAL
through ZS_CREATE_ACK through SK_CONNECT_ACK; ztsl_send() emits
Triple Signature computation followed by DP_DATA_*; ztsl_recv()
validates incoming frame and emits DP_DATA_ACK; ztsl_close() emits
ZS_CLOSE through SK_CLOSE_ACK. Internal heartbeat, threat, and
recovery sequences are invisible to the application.
11. ZTSL Packet Structure
The ZTSL packet carries: Opcode (24 bits), FrameFlags (8 bits), Frame
Length (32 bits, big-endian), Zession ID (128 bits, UUID RFC 4122),
Sequence Number (64 bits, big- endian, monotonic, wraps at 2^64-1),
Trust Context Hash (256 bits, SHA-256(ZessionStateHash XOR DTF)),
Frame Signature (variable, Ed25519 64 bytes or ECDSA P-384 96 bytes),
and Frame Payload (variable, opcode-specific). For DP frames
additionally: Message ID (128-bit UUID), Sender ID (128-bit UUID),
Receiver ID (128-bit UUID), Message Timestamp (64-bit Unix
nanoseconds), Priority (8-bit enum), Message Type (8-bit enum),
Rama Hebbar Expires 6 February 2027 [Page 24]
Internet-Draft ZTSL Protocol August 2026
Routing Class (8-bit enum), Policy ID (64 bits), Content Length (32
bits), Socket Fingerprint (SHA-256), Connection Fingerprint (SHA-
256), Adaptive Protocol Fingerprint (SHA-256), DTF (variable), Socket
Signature (min 64 bytes), Device Signature (min 64 bytes), Message
Signature (min 64 bytes), Encrypted Payload (AES-256-GCM or
ChaCha20-Poly1305), AEAD Auth Tag (128 bits).
12. Trust Mesh Architecture
The Trust Mesh is the centralized architecture through which the ZTSL
Server maintains and arbitrates all inter-client trust relationships.
Key properties:
* Centralized Mediation: All communication passes through the ZTSL
Server.
* Pairwise Connection Fingerprints: Each client-to-client pair has a
unique Connection Fingerprint.
* Trust Score Propagation: Changes in one client's trust score
immediately affect all connections involving that client.
* Dynamic Policy Enforcement: Policy updates propagated to all
active Zessions via CP_POLICY_UPDATE.
* Comprehensive Audit Trail: Every trust event recorded with opcode
annotations.
* Lateral Movement Prevention: A compromised client's connections
MUST be immediately quarantined (ZS_CLOSE_FORCED) without
disrupting other mesh participants.
13. Wire Format Examples
13.1. FAN_REQ_INITIAL First Bytes
Offset Value (hex) Field
------ ----------- -----
0x00 01 Opcode[Class] = 0x01 (FAN Operations)
0x01 01 Opcode[Op] = 0x01 (FAN_REQ)
0x02 01 Opcode[Sub] = 0x01 (INITIAL)
0x03 08 FrameFlags: SIG=1
0x04 00 02 14 00 Frame Length = 532 bytes (example)
0x08 00 * 16 Zession ID = all-zeros (pre-FAN)
0x18 00..01 (8B) Sequence No. = 1
0x20 00 * 32 Trust Context = all-zeros (pre-FAN)
0x40 [64 bytes] Ed25519 Frame Signature
Rama Hebbar Expires 6 February 2027 [Page 25]
Internet-Draft ZTSL Protocol August 2026
13.2. DP_DATA_NORMAL First Bytes
Offset Value (hex) Field
------ ----------- -----
0x00 04 Opcode[Class] = 0x04 (Data Plane)
0x01 01 Opcode[Op] = 0x01 (DATA_SEND)
0x02 03 Opcode[Sub] = 0x03 (NORMAL priority)
0x03 18 FrameFlags: SIG=1, ENC=1
0x04 [length] Frame Length
0x08 [ZessionID] 128-bit Zession ID
0x40 [FrameSig] Ed25519 Frame Signature (64 bytes)
0x80 [payload] MsgID,SrcID,DstID,Ts,Priority,
MsgType,RoutingClass,PolicyID,
ContentLen,SockFP,ConnFP,DTF,
SockSig,DevSig,MsgSig,
AES-256-GCM EncPayload, AEAD Auth Tag
14. Security Considerations
14.1. Opcode Binding as a Novel Security Primitive
The inclusion of the 24-bit opcode in the Triple Signature
computation constitutes a novel security primitive termed Opcode
Binding. It provides:
1. Opcode Forgery Prevention: Substituting one opcode value for
another in a captured frame immediately invalidates the Ed25519
or ECDSA P-384 signature.
2. Cross-Opcode Replay Prevention: A valid frame for 0x04.0x01.0x01
(CRITICAL) cannot be replayed as 0x04.0x01.0x03 (NORMAL) to
downgrade message handling.
3. Protocol Confusion Prevention: A recovery opcode cannot be forged
during ZESSION_ACTIVE state - the state machine blocks it and
Opcode Binding prevents it.
4. Causal Audit Chain: The Recovery Trigger Opcode in REC_INITIATE
creates a verifiable, signed causal link between threat detection
and recovery.
14.2. Cryptographic Agility
Implementations MUST support algorithm negotiation. Required: AES-
256-GCM (symmetric encryption), Ed25519 (signatures), SHA-256 (hash),
X25519 (key exchange), HKDF-SHA-256 [RFC5869] (DTF derivation).
Alternatives: ChaCha20-Poly1305, ECDSA P-384, SHA-384 or SHA-512,
ECDH P-384.
Rama Hebbar Expires 6 February 2027 [Page 26]
Internet-Draft ZTSL Protocol August 2026
14.3. Replay Attack Prevention
ZTSL employs multiple overlapping anti-replay mechanisms: sequence
numbers with an anti-replay window of at least 64 entries; unique
256-bit nonces in FAN requests; 60- second timestamp validation
window; Zession hash chain validation; Zession ID binding (frames
from prior Zession MUST be rejected even if signatures are valid);
and opcode sequence binding.
14.4. Denial of Service Mitigation
FAN requests MUST be rate-limited per source address and per Identity
Manager ID. Repeated failures MUST trigger exponential backoff
carried in FAN_BACKOFF. After a configurable number of consecutive
failures, the client's Identity Manager ID MUST be temporarily
locked. Unknown opcode frames MUST be silently discarded (not
rejected) to prevent opcode flooding DoS.
14.5. Side-Channel Resistance
Implementations MUST use constant-time comparison for all
cryptographic operations. Cryptographic operations SHOULD be
performed in hardware-isolated environments (HSM, TPM, TEE) where
available.
14.6. Key Management and Perfect Forward Secrecy
All session keys MUST be ephemeral. PFS MUST be achieved via
ephemeral key exchange (X25519 or ECDH P-384) at Zession creation and
at every Adaptive Recovery. Upon Zession termination, all session
key material MUST be securely erased. Hardware-protected keys MUST
be revoked through the hardware interface.
14.7. Post-Quantum Readiness
ZTSL implementations SHOULD incorporate NIST-standardized post-
quantum algorithms - ML-KEM [NIST.FIPS.203] for key encapsulation and
ML-DSA [NIST.FIPS.204] for signatures - in hybrid mode alongside
classical algorithms.
14.8. Audit and Non-Repudiation
The Audit Engine MUST record sufficient information to support non-
repudiation. Audit records MUST be integrity- protected and SHOULD
be stored in a write-once or append- only log. Required events:
AU_ZESSION_OPEN (all FAN outcomes), AU_ZESSION_CLOSE (final hash and
metrics), AU_EVENT_SECURITY (all threat events), AU_RECOVERY_LOG
(recovery events), AU_EVENT_POLICY (policy updates), AU_EVENT_TRUST
Rama Hebbar Expires 6 February 2027 [Page 27]
Internet-Draft ZTSL Protocol August 2026
(Trust Score changes below threshold).
14.9. Trust Score Manipulation
Trust Score computation MUST rely exclusively on verifiable,
hardware-attested measurements where available. Trust Score inputs
MUST NOT be modifiable by the client. The algorithm MUST be defined
in administrator policy and MUST be versioned.
14.10. Insider Threat
Implementations SHOULD deploy anomaly detection monitoring for
unusual communication patterns. Anomaly detection events MUST be
emitted as AU_EVENT_SECURITY frames.
14.11. Physical Security
Device Trust Flags SHOULD be derived from hardware-rooted trust
mechanisms (TPM 2.0 [TPM2.0], Apple Secure Enclave, or equivalent).
Implementations MUST clearly document the security properties of DTF
derivation for both hardware and software attestation paths.
14.12. Opcode Namespace Exhaustion
Implementations MUST maintain a local opcode allowlist from the IANA
ZTSL Opcode Registry. Frames with opcodes not in the allowlist MUST
be silently discarded and logged as AU_EVENT_SECURITY.
14.13. State Machine Enforcement
Implementations MUST enforce the opcode state machine (Section 8).
Acceptance of an out-of- state opcode MUST be treated as
CP_ERROR_FATAL and MUST trigger Zession termination. This prevents
protocol confusion attacks.
14.14. ABL Buffer Security
The ABL application send buffer MUST be stored in memory protected
against swapping to persistent storage. The buffer MUST be securely
cleared after recovery completes or fails. Buffer size MUST be
bounded by a configurable maximum to prevent memory exhaustion.
15. IANA Considerations
This document requests that IANA create a new "ZTSL Protocol
Parameters" registry group containing the following registries.
Rama Hebbar Expires 6 February 2027 [Page 28]
Internet-Draft ZTSL Protocol August 2026
15.1. ZTSL Primary Opcode Class Registry
Registration policy: Standards Action (0x00-0x3F), IETF Review
(0x40-0x7F), First Come First Served (0x80-0xBF).
Initial values: 0x00 Control Plane, 0x01 FAN Operations, 0x02 Zession
Management, 0x03 Socket Operations, 0x04 Data Plane, 0x05 Trust
Operations, 0x06 Recovery Operations, 0x07 Audit and Telemetry (all
referencing this document). 0x08-0x3F IETF-Reserved (Standards
Action); 0x40-0x7F IETF-Assignable (IETF Review); 0x80-0xBF Private
Use; 0xC0-0xFE Future Extension; 0xFF RESERVED.
15.2. ZTSL Operation Code Sub-Registries
IANA is requested to create a sub-registry per Primary Opcode Class
titled "ZTSL [ClassName] Operation Codes", with initial values as
defined in Section 7. Registration policy: Standards Action
(0x00-0x3F), IETF Review (0x40-0x7F).
15.3. ZTSL Frame Flags Registry
IANA is requested to create a registry titled "ZTSL Frame Flags" with
8 single-bit entries (Bits 0-7) as defined in Section 4.12.
15.4. ZTSL Adaptive Protocol Identifier Registry
Initial values: 0x0001 TCP (RFC 793), 0x0002 QUIC (RFC 9000), 0x0003
SCTP (RFC 4960), 0x0004 DCCP (RFC 4340), 0x0005 HTTP/HTTPS Tunnel;
0x0006-0x7FFF IETF-Assignable; 0x8000-0xFFFE Private Use; 0xFFFF
RESERVED.
15.5. Well-Known Port Number
A well-known TCP/UDP/SCTP/QUIC port for the ZTSL control channel is
requested. Specific value TBD pending IANA assignment.
15.6. ALPN Identifier
An ALPN identifier of "ztsl/1" is requested for use in TLS [RFC8446]
and QUIC [RFC9000] negotiation contexts.
16. References
16.1. Normative References
[RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
September 1981, <https://www.rfc-editor.org/rfc/rfc793>.
Rama Hebbar Expires 6 February 2027 [Page 29]
Internet-Draft ZTSL Protocol August 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005, <https://www.rfc-editor.org/rfc/rfc4122>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006,
<https://www.rfc-editor.org/rfc/rfc4340>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007,
<https://www.rfc-editor.org/rfc/rfc4960>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
16.2. Informative References
[NIST.FIPS.203]
National Institute of Standards and Technology, "Module-
Lattice-Based Key-Encapsulation Mechanism Standard", NIST
FIPS 203, August 2024,
<https://doi.org/10.6028/NIST.FIPS.203>.
[NIST.FIPS.204]
National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard", NIST FIPS 204,
August 2024, <https://doi.org/10.6028/NIST.FIPS.204>.
Rama Hebbar Expires 6 February 2027 [Page 30]
Internet-Draft ZTSL Protocol August 2026
[NIST.SP.800-207]
Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
"Zero Trust Architecture", NIST Special
Publication 800-207, August 2020,
<https://doi.org/10.6028/NIST.SP.800-207>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[TPM2.0] Trusted Computing Group, "Trusted Platform Module Library
Specification, Family 2.0", 2019,
<https://trustedcomputinggroup.org/resource/tpm-library-
specification/>.
Appendix A: Key Term Summary
FAN Mandatory 6-dimension trust establishment gateway before any
Zession.
Zession Continuously verified trust context with opcode-annotated
hash chain history.
DTF Per-packet cryptographic device validation token.
CSRP Signed versioned client trust and routing profile.
HBF Trust-carrying heartbeat structure.
Triple Signature Socket + Device + Message signatures, each with
Opcode Binding.
Trust Triangle Sender <-> Server <-> Receiver three-way trust model.
Trust Mesh Centralized inter-client trust management architecture.
Adaptive Recovery Application-transparent cryptographic regeneration
on compromise.
Opcode Binding Opcode included in Triple Signature; prevents forgery
or substitution.
ABL Transparent shim mapping socket API calls to ZTSL opcode
sequences.
Opcode State Machine FSA defining which opcodes are legal in each
ZTSL state.
Rama Hebbar Expires 6 February 2027 [Page 31]
Internet-Draft ZTSL Protocol August 2026
Appendix B: High-Level Communication Flow Summary
1. Administrator defines policies (root of trust).
2. Initialize ZTSL Server (12 engine components).
3. Generate Managed Clients (CSRP, Certs, DTF seeds).
4. Install Client, Register Device (DTF computed from hardware
measurements).
5. FAN: CP_VERSION_HELLO -> FAN_REQ_INITIAL -> FAN_ACCEPT. 6
dimensions validated, TrustScore computed.
6. Adaptive Protocol Negotiation embedded in FAN_ACCEPT.
APFingerprint assigned.
7. Zession Creation: ZS_CREATE -> ZS_CREATE_ACK -> AU_ZESSION_OPEN.
Hash-chained Zession active.
8. Secure Socket Creation: SK_CREATE -> SK_CREATE_ACK. SockFP
assigned.
9. Trust Triangle: SK_CONNECT -> SK_CONNECT_ACK. ConnFP assigned.
10. Message Preparation: MsgID, Priority, RoutingClass, PolicyID
prepared.
11. Triple Signature with Opcode Binding: SockSig, DevSig, MsgSig
computed.
12. ZTSL Packet Construction: DP_DATA_* with full trust context.
13. Server-Side Validation: 10 ordered steps.
14. Trust-Aware Routing: Trust Score + QoS + Policy.
15. Receiver-Side Validation: 8 ordered steps with Opcode Binding
confirmation.
16. Encrypted Delivery to Application via ABL recv().
17. Heartbeat Synchronization (every HBInterval): TR_HEARTBEAT ->
TR_HEARTBEAT_ACK -> ZS_SYNC -> ZS_SYNC_ACK.
18. Continuous Trust Evaluation (7-dimension ongoing).
19. Threat Detection: TR_THREAT_* -> TR_URG -> TR_URG_SUSPEND.
Rama Hebbar Expires 6 February 2027 [Page 32]
Internet-Draft ZTSL Protocol August 2026
20. Adaptive Recovery (6-step): REC_INITIATE through REC_RESUME.
Application unaware.
21. Secure Termination: ZS_CLOSE -> ZS_CLOSE_ACK -> AU_ZESSION_CLOSE
-> SK_CLOSE -> SK_CLOSE_ACK. Keys erased.
Appendix C: Complete Opcode Reference Table (84 opcodes)
+------------------+-----------------------+---------------------+
| Opcode | Symbolic Name | Legal States |
+------------------+-----------------------+---------------------+
| 0x00.0x00.0x00 | CP_VERSION_HELLO | PRE_FAN |
| 0x00.0x00.0x01 | CP_VERSION_ACCEPT | PRE_FAN |
| 0x00.0x00.0x02 | CP_VERSION_REJECT | PRE_FAN |
| 0x00.0x01.0x00 | CP_ERROR | ALL |
| 0x00.0x01.0x01 | CP_ERROR_FATAL | ALL |
| 0x00.0x01.0x02 | CP_ERROR_WARN | ALL |
| 0x00.0x02.0x00 | CP_POLICY_UPDATE | ZESSION_ACTIVE |
| 0x00.0x02.0x01 | CP_POLICY_ACK | ZESSION_ACTIVE |
| 0x00.0x03.0x00 | CP_KEEPALIVE | ZESSION_ACTIVE |
| 0x01.0x01.0x01 | FAN_REQ_INITIAL | PRE_FAN |
| 0x01.0x01.0x02 | FAN_REQ_REAUTH | FAN_NEGOTIATION |
| 0x01.0x01.0x03 | FAN_REQ_RECOVERY | RECOVERY |
| 0x01.0x02.0x00 | FAN_CHALLENGE | FAN_NEGOTIATION |
| 0x01.0x02.0x01 | FAN_CHALLENGE_DTF | FAN_NEGOTIATION |
| 0x01.0x02.0x02 | FAN_CHALLENGE_NONCE | FAN_NEGOTIATION |
| 0x01.0x03.0x00 | FAN_RESPONSE | FAN_NEGOTIATION |
| 0x01.0x04.0x00 | FAN_ACCEPT | FAN_NEGOTIATION |
| 0x01.0x04.0x01 | FAN_ACCEPT_DEGRADED | FAN_NEGOTIATION |
| 0x01.0x05.0x01 | FAN_REJECT_DTF | FAN_NEGOTIATION |
| 0x01.0x05.0x02 | FAN_REJECT_CERT | FAN_NEGOTIATION |
| 0x01.0x05.0x03 | FAN_REJECT_POLICY | FAN_NEGOTIATION |
| 0x01.0x05.0x04 | FAN_REJECT_IDENTITY | FAN_NEGOTIATION |
| 0x01.0x05.0x05 | FAN_REJECT_APP | FAN_NEGOTIATION |
| 0x01.0x05.0x06 | FAN_REJECT_NETWORK | FAN_NEGOTIATION |
| 0x01.0x05.0x07 | FAN_REJECT_REPLAY | FAN_NEGOTIATION |
| 0x01.0x05.0x08 | FAN_REJECT_SKEW | FAN_NEGOTIATION |
| 0x01.0x06.0x00 | FAN_BACKOFF | FAN_NEGOTIATION |
| 0x02.0x01.0x00 | ZS_CREATE | FAN_NEG, RECOVERY |
| 0x02.0x01.0x01 | ZS_CREATE_ACK | FAN_NEG, RECOVERY |
| 0x02.0x02.0x00 | ZS_UPDATE | ZESSION_ACTIVE |
| 0x02.0x02.0x01 | ZS_UPDATE_TRUST | ZESSION_ACTIVE |
| 0x02.0x02.0x02 | ZS_UPDATE_POLICY | ZESSION_ACTIVE |
| 0x02.0x02.0x03 | ZS_UPDATE_PROTOCOL | ZESSION_ACTIVE |
| 0x02.0x03.0x00 | ZS_SYNC | ZESSION_ACTIVE |
| 0x02.0x03.0x01 | ZS_SYNC_ACK | ZESSION_ACTIVE |
| 0x02.0x03.0x02 | ZS_SYNC_MISMATCH | ZESSION_ACTIVE |
| 0x02.0x04.0x00 | ZS_DEGRADE | ZESSION_ACTIVE |
Rama Hebbar Expires 6 February 2027 [Page 33]
Internet-Draft ZTSL Protocol August 2026
| 0x02.0x04.0x01 | ZS_DEGRADE_RECOVER | TRUST_DEGRADED |
| 0x02.0x05.0x00 | ZS_CLOSE | ALL |
| 0x02.0x05.0x01 | ZS_CLOSE_ACK | TERMINATION |
| 0x02.0x05.0x02 | ZS_CLOSE_FORCED | ALL |
| 0x03.0x01.0x00 | SK_CREATE | ZESSION_ACTIVE |
| 0x03.0x01.0x01 | SK_CREATE_ACK | ZESSION_ACTIVE |
| 0x03.0x01.0x02 | SK_CREATE_REJECT | ZESSION_ACTIVE |
| 0x03.0x02.0x00 | SK_BIND | ZESSION_ACTIVE |
| 0x03.0x02.0x01 | SK_BIND_ACK | ZESSION_ACTIVE |
| 0x03.0x03.0x00 | SK_CONNECT | ZESSION_ACTIVE |
| 0x03.0x03.0x01 | SK_CONNECT_ACK | ZESSION_ACTIVE |
| 0x03.0x03.0x02 | SK_CONNECT_REJECT | ZESSION_ACTIVE |
| 0x03.0x04.0x00 | SK_CLOSE | TERMINATION |
| 0x03.0x04.0x01 | SK_CLOSE_ACK | TERMINATION |
| 0x03.0x05.0x00 | SK_PROFILE | ZESSION_ACTIVE |
| 0x03.0x05.0x01 | SK_PROFILE_UPDATE | ZESSION_ACTIVE |
| 0x04.0x01.0x01 | DP_DATA_CRITICAL | ZESSION_ACTIVE |
| 0x04.0x01.0x02 | DP_DATA_HIGH | ZESSION_ACTIVE |
| 0x04.0x01.0x03 | DP_DATA_NORMAL | ZESSION_ACTIVE |
| 0x04.0x01.0x04 | DP_DATA_LOW | ZESSION_ACTIVE |
| 0x04.0x01.0x05 | DP_DATA_BACKGROUND | ZESSION_ACTIVE |
| 0x04.0x02.0x00 | DP_DATA_ACK | ZESSION_ACTIVE |
| 0x04.0x02.0x01 | DP_DATA_NACK | ZESSION_ACTIVE |
| 0x04.0x03.0x00 | DP_META_ONLY | ZESSION_ACTIVE |
| 0x04.0x04.0x00 | DP_FRAGMENT | ZESSION_ACTIVE |
| 0x04.0x04.0x01 | DP_FRAGMENT_LAST | ZESSION_ACTIVE |
| 0x04.0x05.0x00 | DP_SIGN_SOCKET | ZESSION_ACTIVE |
| 0x04.0x05.0x01 | DP_SIGN_DEVICE | ZESSION_ACTIVE |
| 0x04.0x05.0x02 | DP_SIGN_MESSAGE | ZESSION_ACTIVE |
| 0x04.0x06.0x00 | DP_ROUTE_ANNOUNCE | ZESSION_ACTIVE |
| 0x04.0x06.0x01 | DP_ROUTE_REJECT | ZESSION_ACTIVE |
| 0x05.0x01.0x00 | TR_HEARTBEAT | ACTIVE, DEGRADED |
| 0x05.0x01.0x01 | TR_HEARTBEAT_ACK | ACTIVE, DEGRADED |
| 0x05.0x01.0x02 | TR_HEARTBEAT_MISS | ACTIVE, DEGRADED |
| 0x05.0x02.0x00 | TR_SCORE_UPDATE | ACTIVE, DEGRADED |
| 0x05.0x02.0x01 | TR_SCORE_BELOW_MIN | ACTIVE, DEGRADED |
| 0x05.0x02.0x02 | TR_SCORE_CRITICAL | ACTIVE, DEGRADED |
| 0x05.0x03.0x00 | TR_THREAT_DETECT | ZESSION_ACTIVE |
| 0x05.0x03.0x01 | TR_THREAT_DTF_FAIL | ZESSION_ACTIVE |
| 0x05.0x03.0x02 | TR_THREAT_APP_MOD | ZESSION_ACTIVE |
| 0x05.0x03.0x03 | TR_THREAT_HASH_BREAK | ZESSION_ACTIVE |
| 0x05.0x03.0x04 | TR_THREAT_REPLAY | ZESSION_ACTIVE |
| 0x05.0x03.0x05 | TR_THREAT_FP_MISMATCH | ZESSION_ACTIVE |
| 0x05.0x03.0x06 | TR_THREAT_POLICY_VIOL | ZESSION_ACTIVE |
| 0x05.0x03.0x07 | TR_THREAT_SKEW | ZESSION_ACTIVE |
| 0x05.0x04.0x00 | TR_URG | ALL |
| 0x05.0x04.0x01 | TR_URG_SUSPEND | ALL |
| 0x05.0x04.0x02 | TR_URG_RESUME | RECOVERY |
Rama Hebbar Expires 6 February 2027 [Page 34]
Internet-Draft ZTSL Protocol August 2026
| 0x06.0x01.0x00 | REC_INITIATE | DEGRADED, RECOVERY |
| 0x06.0x01.0x01 | REC_INITIATE_CLIENT | TRUST_DEGRADED |
| 0x06.0x02.0x00 | REC_KEY_EXCHANGE | RECOVERY |
| 0x06.0x02.0x01 | REC_KEY_CONFIRM | RECOVERY |
| 0x06.0x03.0x00 | REC_DTF_REQUEST | RECOVERY |
| 0x06.0x03.0x01 | REC_DTF_RESPONSE | RECOVERY |
| 0x06.0x03.0x02 | REC_DTF_ACCEPT | RECOVERY |
| 0x06.0x03.0x03 | REC_DTF_REJECT | RECOVERY |
| 0x06.0x04.0x00 | REC_FP_UPDATE | RECOVERY |
| 0x06.0x05.0x00 | REC_ZESSION_NEW | RECOVERY |
| 0x06.0x05.0x01 | REC_ZESSION_SYNC | RECOVERY |
| 0x06.0x06.0x00 | REC_CSRP_UPDATE | RECOVERY |
| 0x06.0x06.0x01 | REC_CSRP_ACK | RECOVERY |
| 0x06.0x07.0x00 | REC_RESUME | RECOVERY |
| 0x06.0x07.0x01 | REC_FAILED | RECOVERY |
| 0x06.0x08.0x00 | REC_TERMINATE_ZESSION | RECOVERY |
| 0x07.0x01.0x00 | AU_EVENT | ALL |
| 0x07.0x01.0x01 | AU_EVENT_SECURITY | ALL |
| 0x07.0x01.0x02 | AU_EVENT_TRUST | ALL |
| 0x07.0x01.0x03 | AU_EVENT_POLICY | ALL |
| 0x07.0x02.0x00 | AU_ZESSION_OPEN | ZESSION_ACTIVE |
| 0x07.0x02.0x01 | AU_ZESSION_CLOSE | TERMINATION |
| 0x07.0x03.0x00 | AU_METRICS | ACTIVE, TERMINATION |
| 0x07.0x04.0x00 | AU_NONREPUDIATION | ALL |
| 0x07.0x05.0x00 | AU_RECOVERY_LOG | RECOVERY |
+------------------+-----------------------+---------------------+
Author's Address
Sripad Rama Hebbar
Independent
Bangalore
India
Email: sripadkarthik@gmail.com
Rama Hebbar Expires 6 February 2027 [Page 35]