| Internet-Draft | ZTSL Protocol | August 2026 |
| Rama Hebbar | Expires 6 February 2027 | [Page] |
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.¶
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 February 2027.¶
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.¶
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:¶
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:¶
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.¶
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) |
+----------------+ +----------------+
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.¶
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.¶
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.¶
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.¶
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.¶
Generated artifacts MUST be distributed over a secure out-of-band channel employing mutual authentication and end-to-end encryption independent of ZTSL.¶
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.¶
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:¶
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.¶
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.¶
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).¶
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.¶
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.¶
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:¶
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.¶
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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.¶
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).¶
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().¶
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.¶
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.¶
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.¶
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.¶
When the Trust Engine determines that trust context can be re-established, the Recovery Engine initiates Adaptive Recovery in six steps:¶
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.¶
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.¶
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.¶
A Zession is a continuously verified trust context superseding the conventional concept of a network session. Its five key distinguishing properties are:¶
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.¶
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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).¶
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).¶
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).¶
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).¶
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.¶
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).¶
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.¶
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).¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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
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"
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)]
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
The ABL is the transparent integration point between application-level socket operations and the ZTSL Opcode Framework.¶
/* 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.¶
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.¶
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), 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).¶
The Trust Mesh is the centralized architecture through which the ZTSL Server maintains and arbitrates all inter-client trust relationships. Key properties:¶
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¶
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
¶
The inclusion of the 24-bit opcode in the Triple Signature computation constitutes a novel security primitive termed Opcode Binding. It provides:¶
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.¶
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.¶
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.¶
Implementations MUST use constant-time comparison for all cryptographic operations. Cryptographic operations SHOULD be performed in hardware-isolated environments (HSM, TPM, TEE) where available.¶
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.¶
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.¶
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 (Trust Score changes below threshold).¶
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.¶
Implementations SHOULD deploy anomaly detection monitoring for unusual communication patterns. Anomaly detection events MUST be emitted as AU_EVENT_SECURITY frames.¶
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.¶
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.¶
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.¶
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.¶
This document requests that IANA create a new "ZTSL Protocol Parameters" registry group containing the following registries.¶
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.¶
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).¶
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.¶
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.¶
A well-known TCP/UDP/SCTP/QUIC port for the ZTSL control channel is requested. Specific value TBD pending IANA assignment.¶
An ALPN identifier of "ztsl/1" is requested for use in TLS [RFC8446] and QUIC [RFC9000] negotiation contexts.¶
+------------------+-----------------------+---------------------+ | 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 | | 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 | | 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 | +------------------+-----------------------+---------------------+¶