[saag] Re: Call for Presentations: ZT-CPP Side Meeting ( IETF 125 Shenzhen, 16 Mar 2026)

title: "Protocol Gap Analysis for Zero Trust Control and Policy Interoperability"
abbrev: "ZTCPP Gap Analysis"
docname: draft-griffiths-ztcpp-gap-00
category: info
submissiontype: IETF
ipr: trust200902
area: Security
workgroup: "Zero Trust Control and Policy Protocols"

author:
  -
    ins: P. Griffiths
    fullname: Philip Griffiths
    organization: (NetFoundry)
    email: ([email protected] and/or [email protected]_

**Abstract**

Zero Trust deployments increasingly require interoperable **connectivity control-plane** mechanisms for authenticated-before-connect access, policy distribution, dynamic trust/context signaling, and enforcement across heterogeneous environments. Existing standards and drafts address important components of this problem, including identity credentials, attestation evidence, authorization artifacts, and gateway/resource access control mechanisms. However, significant interoperability gaps remain in the control and policy protocols between controllers and enforcement points, and in the binding of policy decisions to data-plane sessions and flows.

This document identifies key interoperability seams for Zero Trust control and policy systems, surveys protocol gaps that impede interoperability across implementations, and outlines candidate work items for standardization within the Zero Trust Control and Policy Protocols (ZTCPP) effort. The analysis is intended to be implementation-neutral and applicable to in-network, gateway-centric, and overlay/service-centric deployment models.

While authenticated-before-connect (ABC) reduces pre-auth exposure, Zero Trust architectures (e.g., NIST SP 800-207) ultimately depend on service-based, least-privilege policy and interoperable mechanisms to bind those policies to concrete sessions and flows with verifiable enforcement fidelity.

**1\. Introduction**

Traditional Internet and enterprise network architectures generally assume reachability prior to authorization: network endpoints are addressable, and security controls are often applied after an initial connection attempt. This model increases exposure to reconnaissance, automated scanning, and opportunistic exploitation, and is increasingly misaligned with Zero Trust objectives.

Multiple technology approaches have emerged to address this problem. Some provide authenticated-before-connect (ABC) and resource-hiding behavior at a gateway/resource boundary. Others provide controller-mediated policy distribution and distributed enforcement across overlay or in-network deployments. Still others focus on identity credentials, attestation, or authorization token formats. These approaches are individually useful, but interoperability across them is limited.

From a Cloud Security Alliance (CSA) perspective, Zero Trust is a security strategy and set of architectural principles spanning identity, device/workload posture, policy, enforcement, visibility, and automation \- not merely network hiding or access brokering. NIST SP 800-207 describes Zero Trust as minimizing uncertainty in enforcing accurate, least-privilege per-request decisions for resources and services, using identity plus context (including device/workload posture) as primary decision inputs.

This document therefore treats “Zero Trust control and policy protocols” as interoperability work focused on the **connectivity control plane** (how policy decisions are expressed, distributed, updated, revoked, and bound to sessions/flows with verifiable enforcement), while explicitly aligning with broader Zero Trust architecture principles. This framing is consistent with ongoing IETF discussion of applying Zero Trust philosophy within network infrastructure (e.g., [draft-li-zt-consideration](https://datatracker.ietf.org/doc/draft-li-zt-consideration/)).

While authenticated-before-connect (ABC) mechanisms reduce pre-auth exposure, Zero Trust architectures (e.g., NIST SP 800-207) ultimately depend on service-based, least-privilege policy and on interoperable mechanisms to bind those policies to concrete sessions and flows with verifiable enforcement fidelity. Interoperability at this binding layer is essential to achieving consistent least-privilege outcomes across heterogeneous implementations.

In practice, deployments frequently rely on proprietary protocols and implementation-specific semantics for:

* policy distribution from a controller to enforcement points,  
* context and posture signal propagation,  
* revocation and re-authorization triggers,  
* capability negotiation and failure behavior,  
* and binding policy decisions to sessions, flows, or channels in the data plane.

These interoperability gaps reduce portability, complicate multi-vendor deployments, and inhibit composability across deployment models.

This document identifies protocol gaps relevant to ZTCPP by organizing the problem around a small set of interoperability seams:

1. **Gateway ↔ Resource seam** (including ABC \[Authenticate-Before-Connect\]/hiding mechanisms),  
2. **Controller ↔ Enforcement Point seam** (dynamic trust and policy control),  
3. **Policy Plane ↔ Data Plane seam** (decision/session/flow binding and enforcement realization).

A core requirement is that non-human identities (NHIs) \- workloads, services, devices, sites, and autonomous agents \- are treated as foundational principals. Interoperability must support service identity and service-based authorization semantics for both human and non-human actors, since many Zero Trust deployments are dominated by machine-to-machine and workload-to-service interactions.

This document does not attempt to standardize endpoint security products (e.g., EDR/MDM implementations). However, it explicitly treats posture, attestation, and other context signals \- and their protocol interactions \- as in-scope interoperability requirements, since dynamic trust is central to operational Zero Trust (e.g., NIST SP 800-207). These interactions include: signaling or referencing posture/attestation evidence; freshness/expiry semantics; reauthorization triggers; enforcement consequences (e.g., suspend/deny/step-up); and audit/telemetry correlation across controllers, enforcement points, and data planes.

The goal of this document is not to prescribe a single Zero Trust architecture. Rather, it aims to identify which protocol elements are candidates for standardization so that multiple implementation classes can interoperate.

**1.1. Scope and Non-Goals**

This document is a gap analysis and requirements-oriented contribution. It does not define a new wire protocol. It does not require a particular trust model implementation, deployment topology, or product architecture.

This document assumes that both of the following may be in scope for ZTCPP:

* **In-network enforcement models** operating on existing IP fabrics and devices, and  
* **Overlay/service-centric models** in which the trust surface is shifted from addressability to identity/service/policy control.

**Operational and Adoption Considerations (Informative).** ZTCPP specifications should define HA/failover/degraded-mode behavior (including stale-policy and re-sync semantics) and include minimal implementable profiles with conformance tests/test vectors. Interoperability that only works in steady state is insufficient for operational Zero Trust.

This document does not attempt to redefine Zero Trust principles; rather, it focuses on protocol interoperability needed to realize those principles operationally.

**2\. Terminology**

The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and **OPTIONAL** in this document are to be interpreted as described in BCP 14 \[RFC2119\] \[RFC8174\] when, and only when, they appear in all capitals, as shown here.

**2.1. Zero Trust Controller (Controller)**

A logical component that evaluates policy intent, identity, context, and/or posture inputs and issues authorization decisions, policy updates, or enforcement instructions to one or more enforcement points.

**2.2. Enforcement Point (EP)**

A logical component that enforces access control, connectivity, routing, admission, or policy realization in the data path or at a resource boundary. An EP may be a gateway, proxy, router, agent, daemonset, sidecar, service endpoint, or network device.

**2.3. Policy Plane**

The set of control functions, data models, and exchanges used to define, distribute, update, revoke, and audit policy intent and authorization decisions.

**2.4. Data Plane**

The set of packet, session, flow, or application-channel paths over which protected traffic is transmitted and on which policy decisions are realized.

**2.5. Authenticated-Before-Connect (ABC)**

A property in which authorization and/or identity validation is performed before a protected resource is reachable or before a functional session to that resource is established.

**2.6. Resource Hiding / Discovery Minimization**

A behavior in which unauthorized requesters are prevented from learning meaningful information about protected resources (e.g., addressability, service availability, ports, domains, or protocol characteristics).

**2.7. Decision Binding**

The cryptographic and/or protocol-level association of an authorization decision with a specific session, flow, channel, or connection context such that enforcement can be verified and audited.

**2.8. Session Binding**

The association of identities, credentials, policy decisions, and/or keying material with a session or channel lifecycle, including expiration, refresh, re-authentication, and revocation handling.

**2.9. Non-Human Identity (NHI)**

An identity representing a workload, service, device, site, process, or autonomous agent, rather than an interactive human user.

**2.10. Context / Posture Signal**

A signal used as input to policy evaluation and/or enforcement, including but not limited to attestation evidence, device posture, environment metadata, location assertions, workload state, runtime conditions, or risk indicators.

**2.11. Service-Centric Model**

A connectivity and authorization model in which policy decisions are expressed primarily in terms of identities, services, and attributes rather than solely in terms of IP addresses, ports, and subnets.

**2.12. Address-Centric Model**

A connectivity and authorization model in which policy decisions are expressed primarily in terms of IP addresses, ports, VLANs, routes, and related network addressing constructs.

**3\. Deployment and Threat Model Assumptions**

This document assumes the following operational conditions are common and relevant to ZTCPP:

1. **Heterogeneous boundaries**: protected interactions occur across multiple boundary types, including enterprise data center to cloud, cloud to SaaS, edge/OT to cloud, site to site, organization to organization, and workload to workload.  
2. **First-class NHIs**: workloads, services, devices, and autonomous agents are first-class principals and require identity, authorization, re-authentication, and audit semantics comparable to or stricter than human identities.  
3. **Dynamic trust inputs**: posture, attestation, context, and runtime signals may change during an active session and can require re-evaluation and re-enforcement.  
4. **Zero inbound reachability goals**: some deployments seek to minimize or eliminate inbound reachability exposure while still enabling authorized communications.  
5. **Multiple implementation classes**: gateway-centric ABC/hiding mechanisms, in-network enforcement systems, and overlay/service-centric systems may all coexist and SHOULD be able to compose where practical.  
6. **Standards Composition Requirement:** ZTCPP protocols SHOULD support composition with existing standards-based identity, credential, attestation, and cryptographic key management systems, including deployment profiles where enforcement systems use external identity providers, HSM-backed key stores, and existing enterprise trust infrastructure.  
7. **High availability and continuity requirements**: Many deployments (including private enterprise, OT/ICS, and mission-critical environments) require high availability across both control-plane and data-plane functions. ZTCPP protocol designs MUST account for failover, degraded operation, policy staleness, and recovery semantics without undermining Zero Trust objectives.

Threats of interest include, but are not limited to:

* unauthorized discovery and reconnaissance of protected resources,  
* unauthorized session establishment,  
* stale policy or delayed revocation resulting in unauthorized continuation,  
* policy tampering or spoofed control-plane messages,  
* downgrade attacks on controller↔EP capabilities or bindings,  
* and audit ambiguity where policy decisions cannot be reliably tied to observed data-plane activity.

**4\. Interoperability Seams**

Zero Trust architectures require more than authenticated-before-connect (ABC) mechanisms or isolated control-plane signaling. They require clear separation \- and precise interaction \- between policy intent, control-plane coordination, and runtime enforcement behavior.

This document organizes interoperability gaps around three distinct seams that occur across these planes. Each seam represents a different interaction surface that must be standardized independently to ensure composability across heterogeneous implementations.

The seams are intentionally separated because eliminating network exposure (4.1), distributing policy decisions (4.2), and binding those decisions to concrete sessions and flows with verifiable enforcement fidelity (4.3) are architecturally distinct concerns. Conflating them risks standardizing connectivity plumbing without ensuring service-based least-privilege realization.

Throughout this section, “identity” includes both human and non-human principals (workloads, services, devices, sites, and agents), and “service” refers to service identity/intent rather than only DNS/IP endpoints.

\+-------------------------+  
|   POLICY PLANE      |  
|  \- Service-based intent |  
|  \- Identity (H/NH)       |  
|  \- Least-privilege         |  
\+-----------+-------------+  
|  
(4.2 Controller \<-\> EP)  
|  
\+-----------v-------------+  
| CONTROL PLANE   |  
|  \- Policy distribution   |  
|  \- Revocation / reauth |  
|  \- State sync / posture |  
\+-----------+-------------+  
|  
|  (4.3 Policy \<-\> Session/Flow Binding)  
v  
 External Requester  \====================================\>  Protected Service (Human/Non-Human)                   End-to-End Service Session                    / Resource  
              (Identity-, Service-, Context-bound)

     4.1a Ingress Gating / Hiding                          4.1b Egress Admission  
     \- No pre-auth routability                 \- Resource not directly reachable  
     \- No discovery                             \- ABC / hiding at destination

Figure 1 illustrates the relationship between the three interoperability seams and the separation between policy plane, control plane, and data plane functions.

The seams are distinct because they govern different failure modes: exposure failure (4.1), coordination failure (4.2), and enforcement fidelity failure (4.3).

**4.1. Gateway ↔ Resource Seam (ABC and Resource-Hiding)**

This seam governs exposure and reachability at the network boundary. It determines whether a protected service/resource can be discovered or connected to prior to authorization, or whether connectivity is mediated via authenticated-before-connect (ABC) or hiding mechanisms. The focus is on eliminating implicit network reachability and ensuring that a requesting identity (human or non-human) cannot establish connectivity to a protected service without prior authorization.

In gateway-centric deployments, this seam is often where “authenticate-before-connect” and resource-hiding behavior is first realized. In other deployments, similar semantics may be implemented at a proxy, service endpoint, or other EP.

**4.1.1. Interoperability Needs**

ZTCPP-relevant protocol elements at this seam may include:

* ABC handshake semantics and state transitions;  
* requester identity proof presentation and validation hooks;  
* replay resistance and key confirmation requirements;  
* resource-hiding/discovery-minimization behavior (including failure/error behavior);  
* decision conveyance from controller to gateway/EP where ABC depends on external policy;  
* session establishment outputs (e.g., session identifiers, policy identifiers, binding material);  
* composition semantics with higher-level policy and dynamic trust systems.

**4.1.2. Observations**

Mechanisms at this seam can effectively reduce pre-auth exposure and support identity-based, zero-inbound-style deployment outcomes. However, mechanisms focused on this seam alone generally do not ensure service-based least-privilege enforcement or standardize:

* controller↔EP policy distribution,  
* posture/context update propagation,  
* revocation/reauth signaling across distributed EPs,  
* or policy-to-data-plane binding across heterogeneous enforcement systems.

Accordingly, this seam is necessary but not sufficient for achieving service-based, least-privilege Zero Trust outcomes or for meeting the broader ZTCPP interoperability objective

**4.2. Controller ↔ Enforcement Point Seam (Dynamic Trust Control)**

This seam governs control-plane communication between policy decision components (e.g., controller/policy engine) and enforcement points (gateways, agents, routers, in-network devices). It defines how identity-, service-, and context-based policy decisions are distributed, updated, revoked, and acknowledged, and how lifecycle events (reauthorization, posture change, expiry) are coordinated across enforcement points.

This includes distributing and updating policy for both user identities and workload/service identities (e.g., service accounts, workload attestation identities), and maintaining lifecycle/reauth/revocation semantics for each.

This seam is central for dynamic trust operation because it carries policy intent and policy lifecycle changes to the points that enforce access and connectivity.

**4.2.1. Interoperability Needs**

Protocol gaps at this seam commonly include lack of interoperable definitions for:

* **EP registration and capability advertisement**  
  * What functions an EP supports (e.g., ABC, resource hiding, posture checks, flow telemetry, policy enforcement granularity, data-plane binding modes).  
* **Policy distribution/update operations**  
  * Push/pull mechanisms, versioning, deltas, scope, precedence, and consistency semantics.  
* **Authorization decision distribution**  
  * Conveyance of allow/deny/conditional decisions, expiry, refresh intervals, and dependent conditions.  
* **Context/posture signal propagation**  
  * Delivery or referencing of posture/attestation/context changes used to re-evaluate policy.  
* **Revocation and re-authorization triggers**  
  * Immediate withdrawal, grace periods, reauth-required signals, and behavior under EP disconnect/staleness.  
* **Failure and stale-state behavior**  
  * What EPs SHOULD do when controller connectivity is degraded, when policy is stale, or when context is unavailable.  
* **Controller↔EP trust and message protection**  
  * Mutual authentication, channel security, anti-replay, authorization of control operations, and audit integrity.

**4.2.2. Why This Seam Is a Priority for ZTCPP**

This seam is where many operational interoperability failures occur today. Deployments can often compose identity credentials and authorization tokens from existing standards, but cannot interoperate on how policy decisions are distributed, updated, withdrawn, and enforced across heterogeneous EPs.

As a result, multi-vendor Zero Trust systems frequently devolve into proprietary control adapters and vendor-specific policy semantics.

ZTCPP can provide high value by standardizing at least a minimal interoperable control-policy protocol and lifecycle model at this seam.

**4.3. Policy Plane ↔ Data Plane Seam (Decision and Session/Flow Binding)**

This seam governs how policy intent expressed in the policy plane is bound to concrete sessions, flows, or channels in the data plane. It determines whether identity-, service-, and context-based access decisions are realized precisely at the runtime level \- ensuring least-privilege at service granularity and preventing over-broad or misapplied enforcement.

In Zero Trust architectures aligned with NIST SP 800-207, it is insufficient to merely distribute policy (4.2); policy must be verifiably realized in actual traffic behavior. This seam therefore addresses binding semantics, session/flow correlation, enforcement state visibility, and the ability to confirm that runtime behavior matches policy intent.

This seam is where service-based least-privilege policy becomes real: it defines how **human and non-human identity/service intent** is bound to concrete sessions/flows and how enforcement fidelity is verified across implementations.

**4.3.1. Interoperability Needs**

ZTCPP-relevant protocol elements at this seam may include:

* identifiers for policy decisions, sessions, flows, channels, and EP instances;  
* cryptographic or protocol bindings between decisions and transport/application sessions;  
* lifetime/expiry semantics and reauth linkage;  
* data-plane realization indicators (e.g., admitted, denied, suspended, reauth pending);  
* audit and telemetry correlation identifiers linking:  
  * identity,  
  * policy decision,  
  * enforcement point,  
  * and observed traffic/session activity;  
* semantics for partial enforcement, conditional enforcement, or degraded enforcement;  
* composition across address-centric and service-centric models.

**4.3.2. Observations**

Without interoperable decision binding semantics, it is difficult to achieve:

* verifiable enforcement outcomes and consistent least privilege at service granularity,  
* portable audit pipelines,  
* consistent revocation behavior,  
* and cross-implementation policy assurance.

Example: A policy says “Identity=Payroll-App may call Service=Tax-API” (service-based least privilege). ABC/hiding may prevent unauthorized discovery, and controller↔EP may distribute the rule. But without interoperable policy-to-session binding, different enforcement systems may realize the rule as “allow traffic from subnet X” or “allow any process on host Y,” silently expanding privilege. This is the core interoperability risk that 4.3 addresses.

This seam is therefore distinct from, but dependent on, controller↔EP signaling and SHOULD be treated as a first-class ZTCPP concern.

**5\. Relationship to Existing IETF Work (Initial Mapping)**

This section provides a preliminary mapping of related IETF work to ZTCPP seam needs. It is intentionally non-exhaustive.

**5.1. Identity, Credentials, and Claims**

Existing and ongoing work on credential formats, claims, and related profiles can contribute to ZTCPP inputs and artifacts, including identities and attributes used in policy decisions. This includes work relevant to human and non-human identities and to interoperable credential expression and verification.

These efforts help define *what* identity and claim material can be conveyed, but generally do not define the full controller↔EP policy lifecycle or policy-to-data-plane binding semantics.

**5.2. Attestation and Evidence (e.g., RATS-related)**

Attestation and evidence frameworks can provide posture and runtime trust signals used as policy inputs. Such evidence is important for dynamic trust decisions and re-evaluation during session lifecycles.

However, attestation specifications do not by themselves standardize how a controller distributes updated policy decisions to EPs or how those decisions are bound to active sessions and data-plane enforcement states.

**5.3. Authorization Artifacts and Constrained Authorization Patterns (e.g., OAuth/ACE-related)**

Authorization frameworks and token formats can provide decision artifacts or delegated authorization constructs that may be consumed by controllers and/or EPs.

These mechanisms are highly relevant to ZTCPP, but additional interoperability work is needed to define:

* how authorization artifacts map to EP actions,  
* how revocation/reauth semantics are conveyed in distributed EP environments,  
* and how decisions are tied to session/flow enforcement and audit.

**5.4. ABC/Hiding Mechanisms and Gateway-Centric Access Protocols**

Protocols that provide ABC and resource-hiding semantics at gateway/resource boundaries are directly relevant to the gateway↔resource seam and may be candidates for composition profiles or interoperability requirements within ZTCPP.

At the same time, such mechanisms typically do not define the broader controller↔EP and policy↔data interoperability required for dynamic trust across heterogeneous environments.

**6\. Protocol Gap Analysis for ZTCPP**

This section identifies candidate protocol gaps for standardization consideration. The gaps are organized by interoperability seam but may require cross-seam coordination.

Implementations that exercise only the gateway↔resource seam are valuable for ABC/hiding profiles, but they are insufficient as sole reference models for ZTCPP if the WG intends to standardize controller↔EP and policy↔data-plane interoperability and to enable portable service-based least-privilege enforcement at scale.

Implementations that model connectivity and authorization in terms of identities, services, and policies across distributed enforcement points provide a more complete reference for the broader seam set identified in this document.

Unless stated otherwise, each gap applies to both human identities and non-human identities (NHIs), including workload/service identities used in machine-to-machine and workload-to-service access.

**6.1. Gap G1: Controller ↔ EP Control Protocol for Policy Lifecycle**

* **Problem:** There is no widely adopted interoperable protocol that standardizes the lifecycle of policy distribution from controller to EP, including registration, capability advertisement, policy update, revocation, refresh, and stale-state handling.  
* **Impact:** Multi-vendor environments require proprietary integrations; policy convergence and failure behavior are inconsistent; dynamic trust updates are difficult to operationalize.  
* **ZTCPP Opportunity:** Define a minimal interoperable controller↔EP control protocol and lifecycle semantics, including message classes and state transitions, including identity/service principals and workload/service identity lifecycle (issuance, rotation, revocation, reauth).

**6.2. Gap G2: Standardized Context/Posture Signal Integration into Enforcement Lifecycle**

* **Problem:** Posture/attestation/context signals may exist in standardized forms for devices and workloads/services (e.g., workload attestation state, runtime integrity signals), but there is limited interoperability for how those signals trigger policy updates, reauth requests, or enforcement changes across EPs.  
* **Impact:** Dynamic trust decisions are not portable; posture-driven re-evaluation becomes implementation-specific; inconsistent behavior under changing runtime conditions.  
* **ZTCPP Opportunity:** Define interoperable signaling and/or referencing patterns for context/posture updates and their policy/enforcement consequences.

**6.3. Gap G3: Policy Plane ↔ Data Plane Decision Binding and Service-Level Enforcement Fidelity**

* **Problem:** There is no common model for human and non-human identity/service policy decisions to sessions/flows/channels across implementations and data planes.  
* **Impact:** Auditing, revocation assurance, and enforcement verification are weak or inconsistent; policy outcomes cannot be reliably correlated with observed traffic or validated for consistent least-privilege at service granularity, particularly when policies are expressed in identity/service terms but enforced in address-centric data planes.  
* **ZTCPP Opportunity:** Define identifiers, binding semantics, and lifecycle metadata linking policy decisions to data-plane realizations.

**6.4. Gap G4: Composition of ABC/Hiding Mechanisms with Dynamic Trust Control Planes**

* **Problem:** ABC/hiding mechanisms can provide strong pre-auth exposure reduction, but composition with controller-driven policy systems is often unspecified or proprietary.  
* **Impact:** Deployments cannot easily combine gateway-centric ABC mechanisms with interoperable controller↔EP policy lifecycle management.  
* **ZTCPP Opportunity:** Define composition requirements and profiles for integrating ABC/hiding mechanisms with controller↔EP and policy↔data-plane semantics.

**6.5. Gap G5: Service-Based Policy Target Abstraction and Portability**

* **Problem:** Zero Trust architectures increasingly model authorization in terms of identities, services, workloads, agents, and devices rather than IP addresses, ports, or network zones. However, there is no interoperable abstraction for expressing and binding service-based policy targets across address-centric and service-centric enforcement systems.  
* **Impact:** Policies that are expressed at the service or workload identity level cannot be ported consistently across implementations. Service-level least privilege may be degraded into coarse address-based controls, leading to expanded privilege, inconsistent enforcement semantics, and reduced policy assurance across heterogeneous environments.  
* **ZTCPP Opportunity:** Define a minimal, interoperable abstraction for service and NHI policy targets (services, workloads, agents, sites/devices), including identifiers and binding semantics, and mapping guidance to address-based enforcement models. This should enable portable expression of service-level least privilege and consistent realization across in-network, gateway-centric, and overlay/service-centric architectures.

**6.6 Gap G6: Standards-Based Identity and Key Management Composition**

* **Problem:** There is limited interoperability guidance for how controller↔EP and policy↔data-plane protocols compose with external identity providers, enterprise PKI/HSM infrastructure, and standardized credential/token ecosystems, including workload identity ecosystems (e.g., SPIFFE-like patterns) where applicable.  
* **Impact:** Deployments frequently rely on closed, implementation-specific trust stacks, making it difficult to integrate with existing enterprise identity systems, hardware-backed key management, and federated authentication/authorization environments. This reduces portability, increases integration cost, and limits multi-vendor interoperability.  
* **ZTCPP Opportunity:** Define composition requirements and interoperability profiles for integrating controller↔EP and policy↔data-plane protocols with external identity, credential, and key management systems, including enterprise PKI, HSM-backed key stores, and standardized credential/token formats.

**6.7. Gap G7: High Availability, Failover, and Degraded-Mode Interoperability Semantics**

* **Problem:** There is no widely adopted interoperable model for controller failover, enforcement point failover, policy synchronization/re-synchronization, stale-policy handling, and degraded-mode behavior across Zero Trust control and policy systems.  
* **Impact:** Implementations define proprietary behaviors for outage handling, partition recovery, and policy continuity, leading to inconsistent security and availability outcomes. In high-availability environments (including enterprise, cloud, edge, and OT/ICS), this can cause either unacceptable downtime or unsafe fail-open behavior, and makes multi-vendor deployments difficult to operate predictably.  
* **ZTCPP Opportunity:** Define interoperable HA, failover, and degraded-mode semantics for controller↔enforcement point and policy↔data-plane interactions, including policy version/epoch handling, re-synchronization behavior, stale-policy limits, recovery signaling, and explicit fail-open/fail-closed/fail-limited operational modes.

**7\. Implementation Class Comparison (Informative)**

**Purpose:** Compare implementation classes against the interoperability seams and operational requirements identified in this document. This table is illustrative and non-exhaustive.

| Criterion  | Class A: Gateway-Centric ABC/Hiding (NHP-like) | Class B: Controller-Mediated Service-Centric Overlay (Ziti-like) | Class C: In-Network Address-Centric Policy Enforcement |
| :---- | :---- | :---- | :---- |
| **Primary architectural focus** | **Gateway ABC/hiding.** Primarily protects resource exposure at the gateway/resource seam using authenticated-before-connect and discovery minimization behavior. | **Identity/service/policy connectivity.** Primarily models access as identity-to-service policy across distributed enforcement points. | **In-network policy enforcement.** Primarily enforces policy within existing IP/network infrastructure using network devices and address-centric controls. |
| **ABC / resource hiding / zero-inbound outcomes** | **Strong.** This is typically the core design goal: hide protected resources and only expose behavior after successful authentication. | **Strong.** Often achieves similar outcomes by removing direct underlay reachability and mediating access through identity/service-based paths. | **Variable.** Can reduce exposure via filtering and segmentation, but often does not provide true resource-hiding semantics as a primary behavior. |
| **Controller↔EP control-policy lifecycle** (registration, capability, policy distribution, revocation, reauth) | **Limited / implementation-specific.** Often centered on local gateway behavior; controller lifecycle semantics are frequently proprietary or minimal. | **Strong.** Distributed enforcement generally requires explicit controller↔EP registration, policy distribution, and revocation/reauth signaling. | **Moderate to Strong.** Can be strong within a given platform, but interoperability across heterogeneous devices/vendors is often limited. |
| **Policy↔data-plane binding \+ audit correlation** | **Limited to Moderate.** Policy decisions may be enforced effectively, but session/flow binding and audit correlation are often local or implicit. | **Strong.** Identity, service, policy, and session linkage is commonly first-class, improving verification and auditability. | **Moderate.** Flow/device telemetry is often available, but correlating policy decisions across systems may be platform-specific. |
| **Dynamic trust / posture / context updates during active sessions** | **Limited / externalized.** Usually possible only by composing with additional systems; not typically the central protocol focus. | **Strong.** Commonly integrated into policy lifecycle and distributed enforcement updates during session operation. | **Variable.** Some systems support this well, but behavior and semantics differ significantly across vendors and device types. |
| **Service-centric segmentation \+ first-class NHI support** | **Limited to Moderate.** Can support non-human identities and service segmentation with add-ons, but these are often not the organizing model. | **Strong.** Identity/service/policy abstraction is typically central, making NHIs (workloads/services/agents/devices) first-class principals. | **Limited to Moderate.** Usually organized around addresses/zones first; service and NHI semantics may be layered on top. |
| **Standards composition** (external IdP/federation, enterprise PKI/HSM, token ecosystems) | **Variable.** Some implementations compose well with external identity/PKI ecosystems, but interoperability patterns are not consistently defined. | **Strong.** Mature implementations in this class commonly integrate with external identity providers, enterprise PKI, and hardware-backed key systems. | **Variable to Strong.** Often depends on platform/vendor ecosystem and whether integrations are exposed in interoperable ways. |
| **HA / failover / degraded-mode interoperability needs exposure** (control \+ data plane) | **Limited to Moderate.** HA needs exist, but distributed control/data-plane failover semantics may be less fully exercised in simpler gateway-centric deployments. | **Strong.** Distributed control and enforcement at scale typically require explicit failover, re-sync, and degraded-mode operational behavior. | **Variable to Strong.** HA can be strong within network platforms, but interoperability of failure semantics across systems is often weak. |
| **Cross-boundary applicability** (site↔site, edge↔cloud, org↔org, workload↔service) | **Moderate.** Works well for protected entry points and bounded scenarios, but broader cross-boundary use often needs additional layers. | **Strong.** Generally designed to operate across heterogeneous boundaries and multiple deployment models using identity/service abstraction. | **Moderate.** Strong inside managed network domains, but portability across heterogeneous organizations/environments can be harder. |
| **Best fit as reference for ZTCPP seam set** | **Partial.** Excellent reference for gateway↔resource ABC/hiding seam, but does not by itself cover the broader seam set. | **Strongest.** Best fit for exercising controller↔EP and policy↔data seams in addition to ABC-like outcomes across complex deployments. | **Important complementary class.** Valuable for in-network deployment profiles, especially where existing network infrastructure remains central. |

**8\. Candidate ZTCPP Work Items (Informative)**

The following are candidate work items suggested by the gap analysis:

1. **Policy Plane↔Data Plane Binding Framework**  
   * Decision/session/flow identifiers, binding semantics, audit correlation, lifecycle metadata.  
2. **Policy Target Abstraction and Portability**   
   * Service-centric and address-centric mapping guidance for interoperable policy expression.  
3. **Controller↔Enforcement Point Control Protocol Requirements**  
   * Functional requirements, state models, and security requirements.  
4. **Controller↔EP Interoperability Framework**  
   * Message classes, capability advertisement, policy lifecycle, failure semantics.  
5. **Dynamic Trust Context/Posture Signaling Profile**  
   * Integration of evidence/attestation/posture/context signals into policy and enforcement lifecycles.  
6. **ABC/Hiding Composition Profile**  
   * How gateway/resource ABC mechanisms compose with controller-mediated policy systems.

These work items are not mutually exclusive and may be staged.

**9\. Security Considerations**

This document is a gap analysis and does not define new protocol mechanisms. However, the gaps identified here have direct security implications.

Any ZTCPP protocol work in the identified seams SHOULD address, at minimum:

* mutual authentication and authorization of controller↔EP communications,  
* integrity and anti-replay protections for policy/control messages,  
* stale-policy and disconnected-controller behavior,  
* revocation and reauth race conditions,  
* downgrade attacks in capability negotiation,  
* privacy and minimization considerations for posture/context signals,  
* and audit integrity for decision↔session/flow correlation.

Failure to standardize these behaviors may result in systems that appear interoperable but diverge under failure, revocation, or dynamic trust conditions.

**10\. IANA Considerations**

This document has no IANA actions.

---

**11\. References (placeholder)**

**11.1. Normative References**

*(Likely none for \-00, or only BCP 14 references if needed.)*

**11.2. Informative References**

* BCP 14 (RFC2119, RFC8174)  
* NIST Special Publication 800-207, *Zero Trust Architecture* (2020).  
* Li, et al., *Consideration of Applying Zero Trust Philosophy in Network Infrastructure*, draft-li-zt-consideration (current version).  
* Liu, et al., *Zero Trust Standards in IETF: Use Cases and Problem Statement*, draft-liu-saag-zt-problem-statement (current version).  
* Additional informative references to RATS/ACE/OAuth/JOSE/COSE may be added as the draft matures.