| Internet-Draft | SHNM - PCS | July 2026 |
| OIWA, et al. | Expires 7 January 2027 | [Page] |
"Secure hybrid network monitoring – Problem statement" [I-D.oiwa-secure-hybrid-network] identifies challenges in securing and monitoring networks deployed across hybrid and mixed cloud environments. This document introduces the Path Characteristics Service (PCS), a service that enables applications and operators to verify whether a given network path conforms to their declared requirements ("intent") regarding security, compliance, and operational properties. Unlike traditional network monitoring, PCS does not expose raw network state; instead, it evaluates the user's intent against the actual path characteristics and returns a conformance result (match or no-match). This intent matching approach allows multi-stakeholder environments to verify path properties without disclosing sensitive internal infrastructure details. This document describes an architecture and interfaces for PCS; it expresses recommended behaviors and constraints using the normative keywords of BCP 14, but does not specify a wire protocol or its encoding.¶
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 7 January 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.¶
Virtualized resources such as cloud computing infrastructure are rapidly replacing traditional network and computing environments, including on-premises servers and locally managed clusters. In hybrid and multi-cloud deployments [ISO-IEC-5140], the physical characteristics of resources — e.g., server location, local network topology, or the operators of network devices — are typically hidden from users in exchange for flexibility, redundancy, and cost benefits. At the same time, cryptographic protection mechanisms such as TLS or IPsec are widely used to secure communications into and out of these systems.¶
However, as identified in [I-D.oiwa-secure-hybrid-network], there remain many cases where application-level security depends not only on encrypted communication channels but also on specific properties of the underlying network and intermediate nodes. Examples include:¶
Sensitivity to traffic analysis, where encrypted flows may still leak metadata;¶
Legal or regulatory requirements mandating that certain properties (e.g., jurisdiction, physical location, or operational control) be verifiable;¶
Threats such as Denial-of-Service (DoS) attacks, which cannot be prevented solely through encryption.¶
In non-virtualized, self-managed networks, operators can use existing mechanisms (e.g., NETCONF, path validation) to obtain status and operational information about network components. These mechanisms are not sufficient in modern hybrid or multi-cloud settings, where visibility into the underlying infrastructure is significantly limited.¶
To address these gaps, this document introduces the Path Characteristics Service (PCS) as a technical approach for continuously verifying that the network paths used in complex environments such as hybrid or multi-cloud deployments conform to the user’s declared requirements (intent). PCS is intended to provide a common framework for securely evaluating path-level conformance, thereby enabling high-security applications to maintain trust in the network even in the presence of virtualization and limited direct control.¶
This document builds upon the problem statement and gap analysis presented in [I-D.oiwa-secure-hybrid-network], and outlines a potential PCS architecture and its role in addressing the identified challenges.¶
PCS is a service for verifying whether the characteristics of network paths used by an application or tenant conform to the user’s declared intent. In this document, “path characteristics” include properties that can affect security or compliance (e.g., jurisdictional residency, operator identity along the path, path segments and facilities traversed, transport security properties, or exposure to known risks). “Intent” refers to the set of declarative requirements that a PCS Client submits, describing the desired or required properties of a network path. PCS defines:¶
(1) a data model and processing model for using path-related evidence already produced by existing telemetry mechanisms (e.g., IPFIX, NETCONF, gNMI, BGP-LS, SNMP),¶
(2) methods to reconstruct a coherent view of the path and its attributes from such evidence,¶
(3) an intent matching mechanism that evaluates whether a given path conforms to the user’s declared intent and returns a conformance result (match or no-match).¶
A key design principle of PCS is that it does not return raw network state to the requesting client. Instead, it returns the result of evaluating the user’s intent against the actual path characteristics. This approach prevents the disclosure of sensitive internal network details (e.g., ISP topology, internal routing structure) while still providing actionable conformance information.¶
PCS does not mandate a specific transport or routing technology, is not itself a traffic-measurement protocol, and does not replace existing routing- or control-plane security mechanisms. The acquisition of raw telemetry from network elements is performed by existing telemetry mechanisms and is outside the scope of PCS; PCS only gathers already-acquired telemetry into a form usable for intent evaluation. PCS provides a verifiable interface and data model that higher-layer systems can use to reason about path trust and to trigger operational actions.¶
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.¶
Normative keywords in this document apply to PCS architectural behavior and to its security and privacy properties; they do not define a specific wire protocol binding or encoding.¶
The following terms are used throughout this document:¶
A declarative set of requirements submitted by a PCS Client, describing the desired or required properties of a network path (e.g., jurisdictional constraints, operator restrictions, latency thresholds). Note: PCS uses "intent" in a narrower, query-scoped sense compared to the broader lifecycle-oriented definition in Intent-Based Networking [RFC9315]. In PCS, an intent is a single declarative query evaluated against current path characteristics, rather than a persistent network-wide policy objective.¶
The process by which a PCS Server evaluates whether the actual characteristics of a network path conform to the client's declared intent, returning a conformance result (match or no-match) rather than raw network state.¶
The predefined set of intent types and path properties that a PCS Server is authorized and configured to evaluate, as agreed upon between the PCS operator and its clients.¶
The extraction of raw telemetry from network elements, performed by existing telemetry mechanisms (e.g., IPFIX, NETCONF, gNMI, BGP-LS, SNMP) using their own push (export or streaming) or pull (query or polling) models. Telemetry acquisition — including specific styles sometimes called telemetry fetch (pull) or telemetry capture (observation) — is outside the scope of PCS. PCS does not define how telemetry is acquired.¶
The PCS Server's internal process of aggregating and normalizing already-acquired telemetry into a form usable for intent evaluation (a PathView). Gathering is performed within the scope of PCS; it consumes telemetry produced by existing mechanisms and does not itself acquire telemetry from the network. In short, PCS gathers already-acquired telemetry into a form usable for judgment; it does not acquire telemetry from the network.¶
An internal data structure assembled by the PCS Server that represents the reconstructed end-to-end path and its per-segment attributes (e.g., operator identity, geolocation, security properties, metrics). A PathView is built from per-hop telemetry evidence made available by operator-controlled telemetry mechanisms in the operator's domain (e.g., IPFIX, gNMI, BGP-LS) and gathered by the PCS Server and, where recursive composition is used, from conformance results received from other PCS Servers. The PathView serves as the input to the PCS Server's intent matching engine. By default, the PathView is not disclosed to PCS Clients; it may be included in a response only when the service scope permits and the return_pathview option is enabled.¶
The core design principle of PCS is the intent matching model: PCS does not return raw network state or detailed internal topology to the requesting client. Instead, the client declares its requirements (intent) — such as jurisdictional constraints, approved operators, or latency thresholds — and PCS evaluates whether the actual path characteristics satisfy that intent. The result is a conformance decision (match or no-match), optionally accompanied by a verification level and provenance metadata.¶
This model provides two key benefits:¶
By returning only conformance results rather than detailed network state, PCS prevents the disclosure of sensitive internal infrastructure information (e.g., ISP topology, internal AS structure, router-level details) to external parties.¶
In multi-stakeholder environments, each operator can participate in PCS without being forced to reveal proprietary network details. Operators respond to intent queries within their pre-agreed service scope, maintaining operational independence while enabling end-to-end path verification.¶
To address the gaps identified above, this document describes a distributed architecture for assuring the network operation integrity for mixed and hybrid cloud applications. Such a system should:¶
Have a modeling of the network infrastructure in two dimensions: one axis in parallel to the network paths and forwarding directions, and the other axis for the layers of protocols.¶
Have enough knowledge on the complex dependency of software and protocols; not only the network packet-forwarding technologies but also surrounding areas such as addressing and DNS must be covered.¶
Have explicit handling of tunneling and virtualization aspects, both at the protocol level (e.g., VPNs, IP-IP, IPsec) and at the infrastructure level (IaC, Network-as-a-Service, Wavelength Division Multiplexing, etc.)¶
Consolidate operation information at each operator's level and consider their pre-determined operation principles for evaluating integrity.¶
Address management-oriented risks of infrastructure management, including non-network aspects.¶
A possible implementation of such a system could leverage distributed network security coordination between operators and users of cloud and network infrastructure. Rather than adopting a "disclose all" approach, this design would maintain both flexibility and efficiency for multi-cloud applications.¶
In particular, PCS can clarify the status of monitored communications by employing standardized telemetry mechanisms as defined in [RFC9232]. By adopting these mechanisms, it becomes possible to gather, aggregate, and share relevant operational data about network paths and security status without extending the specifications of existing networks or exposing sensitive internal details. This approach enables stakeholders to verify the integrity and security of communications across hybrid and multi-cloud environments, while respecting the confidentiality requirements of each operator.¶
As a component of the Secure Hybrid Network Monitoring framework [I-D.oiwa-secure-hybrid-network], the Path Characteristics Service (PCS) SHOULD:¶
Have the ability to declare intent (a set of required path properties) from an infrastructure user to infrastructure providers. In a hybrid cloud or layered systems, it will include communications between operators of infrastructure/cloud systems.¶
Have the ability to return a conformance result (match/no-match) for the current path status against the declared intent.¶
Provide some choices on the transparency levels about the internals of the cloud service infrastructure, consistent with the intent matching model.¶
Have some traceability provisions for troubleshooting, if there are opacities in intent matching replies.¶
Have enough consideration for various tunneling and virtualization technologies.¶
Have a bidirectional interface to system-level security management systems, such as Continuous Diagnostics and Mitigations (CDM) dashboards.¶
The PCS architecture is organized into three conceptual layers, shown in Figure 1:¶
Hosts PCS Servers and Clients, which exchange intent-based queries and conformance responses. A PCS Client submits its intent (declarative requirements) to a PCS Server. Internally, a PCS Server gathers per-hop telemetry evidence made available by operator-controlled telemetry mechanisms, reconstructs PathViews, and feeds them into the intent matching engine. PCS instances may also recursively query other PCS instances in adjacent administrative domains to obtain a broader or deeper view of the path.¶
Comprises the existing telemetry mechanisms (e.g., IPFIX [RFC7011], gNMI, BGP-LS, SNMP, NETCONF) that convey per-element network attributes from the Network Layer to the PCS Server. PCS does not define a new telemetry-collection protocol; the choice of mechanism is an operator-internal concern and is outside the scope of PCS. This layer may also include local caches and topology databases that assist in normalization.¶
Comprises the physical and virtual network elements such as routers, switches, links, VPN endpoints, and SDN-controlled domains. These elements generate raw operational data (e.g., IPFIX flow records, BGP updates, interface statistics), which existing telemetry mechanisms convey to the PCS Server as per-hop evidence.¶
+-----------------------------------------------------------+
| PCS Layer |
| [PCS Client] <--> [PCS Server] <--> [PCS Server] |
| (gather + reconstruct + |
| intent matching + PCS-to-PCS) |
+----------------------------^------------------------------+
| telemetry evidence
+----------------------------|------------------------------+
| Telemetry Layer (outside PCS scope) |
| existing mechanisms: [IPFIX] [gNMI] [BGP-LS] [SNMP] |
| [NETCONF] [Cache] [Topology DB] |
+----------------------------^------------------------------+
| observed data
+----------------------------|------------------------------+
| Network Layer |
| [Routers/Switches] [Links] [VPNs] [SDN Domains] |
+-----------------------------------------------------------+
In environments that include VPN tunnels, IP-IP tunnels, or other encapsulation mechanisms, a single end-to-end communication may traverse multiple layers of network infrastructure simultaneously. PCS recognizes that the same physical communication may present different path characteristics depending on the layer at which it is observed:¶
The path as seen at the tunnel or virtual network level. From this perspective, a VPN tunnel appears as a single hop between its endpoints, regardless of the number of physical devices traversed underneath.¶
The path as seen at the physical network level. This view reflects the actual intermediate routers, switches, and links that carry the encapsulated traffic.¶
PCS evaluates intent against the appropriate layer based on the query context. For example, a jurisdictional compliance intent may need to be evaluated at the underlay level (to verify physical locations of all intermediate nodes), while an operator validation intent may be satisfied at the overlay level (verifying only the VPN provider). The relationship between overlay and underlay views is inherently recursive and aligns with the nested path property model described for network tunnels and software-defined networks in this document.¶
PCS also supports recursive composition across administrative boundaries, enabling coherent path evaluation even in deeply nested environments. The recursive composition mechanism is described in Section 4.¶
PCS supports recursive composition, whereby a PCS Server MAY act as a client of other PCS Servers to obtain path-segment information across administrative boundaries. This enables path characteristics to be gathered at multiple granularities: point-level (e.g., device, hop, facility) and administrative-domain-level (e.g., segment, administrative domain, cloud region). A recursive PCS deployment can therefore provide a coherent PathView even in deeply nested environments (e.g., VPN-over-VPN, SDN slices over WAN, multi-cloud overlays).¶
A PCS Server responds to intent queries only within the bounds of a pre-agreed service scope (also referred to as a service menu). The service scope defines the set of intent types, path properties, and geographic/topological ranges that a given PCS Server is authorized and configured to evaluate.¶
A PCS Server MUST NOT respond to queries that fall outside its service scope. For such queries, the server SHOULD return an error indicating that the requested evaluation is outside the agreed service scope (e.g., HTTP 403 or an equivalent PCS-level error code).¶
The PCS protocol itself is generic and does not constrain the set of possible intents. However, each PCS deployment operates within a service-specific profile defined by the contractual relationship (e.g., SLA, connectivity agreement) between the PCS operator and its clients.¶
This design prevents probing attacks, where an attacker might submit crafted queries to infer the internal structure of a network by observing which queries succeed and which fail.¶
When a PCS Server receives a federated (PCS-to-PCS) sub-query, the responding server likewise evaluates the sub-query against its own service scope. The responding server is an ISP or connectivity provider that answers PCS requests based on its SLA and contractual obligations with the requesting party.¶
At a high level, a PCS Server receiving a client query proceeds as follows. This description is illustrative and does not define protocol requirements.¶
Scope decomposition: Partition the end-to-end path into one or more sub-scopes (e.g., by AS / administrative domain, tunnel boundary, cloud region).¶
Local evidence collection: For sub-scopes under local administration, gather telemetry evidence made available by operator-controlled mechanisms in the operator's domain and reconstruct local PathView fragments.¶
Intent analysis and transformation: The PCS Server analyzes the client's intent in the context of its own network architecture and contractual relationships. When delegating to downstream PCS Servers, it MAY transform (rewrite) the intent to match the downstream server's service scope and network context. For example, a jurisdiction constraint expressed as a country-level requirement may be decomposed into AS-level sub-intents when delegated to transit providers.¶
Federated queries: For external sub-scopes, issue PCS-to-PCS sub-queries to authoritative PCS Servers for those domains, including the (possibly transformed) intent, freshness, and privacy constraints.¶
Composition: Merge local and federated intent matching results into a single conformance decision, preserving provenance and confidence metadata.¶
Intent evaluation: Return the composed conformance result (match or no-match) to the client, along with applicable verification level and provenance chain.¶
The following is a simplified message sketch for illustrative purposes:¶
Client -> PCS(Server-G): IntentQuery{target, intent, freshness}
PCS(Server-G): analyze intent, decompose scope
PCS(Server-G) -> PCS(Server-A): SubIntentQuery{scope=A, intent'=transform(intent), trail}
PCS(Server-A): gather telemetry evidence, evaluate intent' against local PathView
PCS(Server-G) <- PCS(Server-A): IntentResult{A, match|no-match, verification, provenance}
PCS(Server-G) -> PCS(Server-B): SubIntentQuery{scope=B, intent'', trail}
PCS(Server-G) <- PCS(Server-B): IntentResult{B, match|no-match, ...}
PCS(Server-G): compose results
Client <- PCS(Server-G): Result{overall=match|no-match, verification, provenance_chain}
¶
To avoid unbounded recursion, a PCS Server MUST implement explicit stop conditions and loop prevention. The following mechanisms are RECOMMENDED:¶
A request header "recursion_limit" (non-negative integer). Each PCS Server decrements it when forwarding sub-queries. If it reaches zero, further delegation MUST NOT occur; the server returns "incomplete=true" for unexplored scopes.¶
Each sub-query SHOULD carry an ordered "trail" including {request_id, caller_domain, scope}. A PCS Server MUST detect a cycle when its own administrative domain/scope appears again and terminate delegation for that branch.¶
A PCS Server SHOULD only delegate the minimal missing scope. Overlapping or redundant sub-queries SHOULD be coalesced to reduce fan-out.¶
Sub-query results MAY be cached with explicit "issued_at"/"exp" (or "fresh-until") metadata. Reuse is allowed only if freshness requirements are met.¶
When a sub-scope cannot be explored (timeout, policy denial, or recursion limit), the composed PathView MUST mark the segment as "opaque" and set "completeness=partial".¶
PCS-to-PCS exchanges MUST be mutually authenticated (e.g., mTLS or equivalent).¶
Responding servers MAY honor privacy constraints (e.g., return administrative-domain-level summaries instead of point-level details) while still signing the returned assertions.¶
Each returned fragment SHOULD include a signed provenance block (issuer, scope, time, signature). When composing, the caller MUST preserve the chain of provenance for third-party verification.¶
A PCS Server MUST NOT act as an open relay. Rate limits and request shaping SHOULD apply to delegated queries.¶
When multiple fragments overlap or disagree:¶
Prefer fragments issued by the authoritative administrative domain for that scope. Otherwise, prefer newer and higher-confidence evidence.¶
If conflicts remain, the composed PathView MUST annotate the affected elements with "conflict=true" and lower "confidence".¶
Administrative-domain-level evidence MAY satisfy policies that require only aggregate properties; point-level evidence is required when policies demand specific node attributes.¶
The following examples are illustrative. A sub-query may include:¶
{
"scope": {
"domain": "AS65001",
"segment": "vpn:1234"
},
"intent": {
"requirements": [
{
"property": "geo.country",
"op": "in",
"values": ["XX"]
},
{
"property": "operator",
"op": "in",
"values": ["AS65001", "AS65003"]
}
]
},
"freshness": {
"max_age": "300s"
},
"privacy": {
"granularity": "domain"
},
"trail": [
{
"domain": "example.net",
"req": "abc123"
}
]
}
¶
A sub-query response may include:¶
{
"scope": {
"domain": "AS65001"
},
"sub_result": "match",
"verification": "TRACED_PRESENT",
"provenance": {
"issuer": "pcs.as65001.net",
"issued_at": "2025-08-15T02:10Z",
"sig": "..."
},
"completeness": "full",
"confidence": 0.95
}
¶
Recursive PCS does not attempt to:¶
control routing or steer traffic;¶
force disclosure of internal topology beyond the responder’s policy;¶
guarantee global completeness in the presence of non-cooperating domains.¶
Note: Recursive PCS enables operators to obtain point-level evidence where permitted, while still producing administrative-domain-level assertions when detailed disclosure is not available, thus delivering useful intent matching decisions even in deeply nested hybrid environments.¶
This section defines the main roles in a PCS-enabled environment. The roles align with the three-layer model described in Figure 1.¶
Responsible for the physical and virtual network infrastructure. They control the disclosure policy for topology and telemetry data, and operate the telemetry mechanisms (e.g., IPFIX, gNMI) that expose network-element attributes within their administrative domain; the specific mechanisms used are outside the scope of PCS. They are the authoritative source of truth for the properties of network elements within their administrative domain. They define the service scope (see the Recursive Composition section) within which their PCS Server will respond to intent queries.¶
Gathers per-hop telemetry evidence from existing mechanisms in the operator's domain, reconstructs PathViews (hop-list construction, conflict resolution, and gap-filling), and hosts the intent matching engine. The PCS Server exposes the service interface to PCS Clients, handles authentication and authorization, and returns conformance results. A PCS Server may recursively query other PCS Servers in adjacent domains, issuing and managing these PCS-to-PCS sub-queries itself. Each PCS Server operates within its defined service scope (see the Recursive Composition section).¶
An application or system component that submits intent (declarative path requirements) to a PCS Server and receives a conformance result (match or no-match). Clients may use this information to make operational or security decisions, such as accepting a compliant path or triggering an alert when intent is not satisfied.¶
This section defines what PCS does: the three conceptual processing stages that transform a client's intent into a conformance result. The operational mechanisms for accessing and interacting with PCS (authentication, subscription, etc.) are described separately in the next section.¶
The PCS Server provides three main functional stages when processing an intent query:¶
The PCS Server gathers per-hop telemetry evidence for the target path, as made available by operator-controlled telemetry mechanisms in the operator's domain (such as IPFIX, gNMI, BGP-LS, SNMP, or NETCONF), and correlates it. The specific telemetry mechanisms and their transport are operator-internal concerns and are outside the scope of this specification. Where recursive composition is needed, the PCS Server also issues PCS-to-PCS sub-queries to neighboring PCS Servers to obtain conformance results for segments outside the local administrative domain. The per-hop evidence representation is described in Section 6.1.¶
The PCS Server builds an end-to-end "PathView" from the gathered per-hop evidence. Reconstruction may operate at different levels of abstraction. Point-level view provides characteristics for each individual network element (e.g., router, link). Administrative-domain-level view provides aggregated characteristics for an entire administrative domain or SDN segment; AS / administrative-domain-level information is the minimum required granularity, while individual router-level details are optional and depend on the service profile and privacy policy of the responding operator. The reconstruction process resolves conflicts, fills gaps using partial data, and ensures that the resulting PathView is internally consistent.¶
Evaluates the reconstructed PathView against the client's declared intent and returns a conformance result (match, no-match, or unknown), optionally with a verification level and annotations explaining non-conformance or uncertainty. The intent matching model is defined in the Design Principles section. The PathView is an internal processing artifact of the PCS Server; by default, only the conformance result and its supporting metadata are returned to the client. When the service scope permits and the return_pathview option is enabled, a summary or detailed PathView MAY be included in the response (see PCS Query options).¶
This section is informative.¶
Per-hop evidence is the structured per-element telemetry made available by operator-controlled telemetry mechanisms and gathered by the PCS Server. The PCS Server transforms this per-hop evidence into PathView segments by carrying forward the common attribute fields (hop identifier, operator, geo, metrics, security) and adding server-produced metadata (verification, provenance, confidence). The "observed_at" and "evidence_sources" fields record when, and by which mechanism, the underlying telemetry was observed; they serve as inputs for provenance construction and do not appear in the resulting PathView segments. Provenance metadata (issuer, signature, timestamp) is attached by the PCS Server when it assembles per-hop evidence into a PathView, because the PCS Server is the entity that asserts the trustworthiness of the composed path information to external parties.¶
Operators may configure their telemetry mechanisms to include element-level provenance information where local policy requires per-element traceability (e.g., for internal audit or regulatory compliance). This is a local operational decision and does not affect the PCS-to-PCS or PCS-to-Client interfaces.¶
The following JSON example illustrates the per-hop evidence for a single router within AS 65001, as gathered by the PCS Server:¶
{
"hop": "R1",
"operator": "AS65001",
"geo": {
"country": "XX",
"confidence_geo": 0.99
},
"metrics": {
"latency": {"p99": 1.2}
},
"security": {
"encryption": "IPsec",
"integrity": "AES-256-GCM"
},
"observed_at": "2025-10-21T01:00:00Z",
"evidence_sources": ["ipfix", "gnmi"]
}
¶
The "evidence_sources" field indicates which telemetry mechanisms and data sources contributed to this per-hop evidence. At the per-hop level these are typically telemetry protocols, including but not limited to IPFIX [RFC7011], gNMI, BGP-LS, SNMP, and NETCONF, ranging from primitive flow-export mechanisms to full configuration- and state-streaming protocols; at the response level (see the "evidence_sources" field in "metadata") they may also include auxiliary data sources such as geolocation databases or RPKI. The per-hop evidence for a single element may combine data from multiple sources when the PCS Server correlates observations from different telemetry feeds for the same network element.¶
The previous section defined the conceptual processing stages of PCS (Gathering, Reconstruction, Intent Matching). This section describes the operational mechanisms through which clients access PCS: authentication, authorization, and subscription for ongoing conformance monitoring.¶
PCS endpoints MUST be access-controlled and confidentiality-protected using secure protocols (e.g., TLS 1.3 or later).¶
Clients MUST be strongly authenticated, for example via OAuth 2.1, mutual TLS (mTLS), or OpenID Connect.¶
Authentication credentials SHOULD be bound to a specific connectivity channel, such as:¶
If multiple connectivity channels exist under a single business contract, multiple identifiers may be associated with a single authentication session. The binding policy between identifiers and connectivity channels is a local operational matter and is outside the scope of this document.¶
PCS protocols SHOULD support both:¶
Clients subscribe to an intent query and receive updates when the conformance status changes (e.g., a previously matching path becomes non-conforming).¶
Clients periodically re-evaluate intent conformance, with configurable intervals.¶
Subscription parameters (e.g., polling interval, event triggers, maximum update rate) SHOULD be negotiable between the PCS Client and PCS Server.¶
A PCS Query is the primary mechanism by which a PCS Client submits its intent to a PCS Server for evaluation against the actual characteristics of a network path.¶
A query typically includes:¶
The path or set of candidate paths to be evaluated, identified by endpoints, AS-paths, or other topology identifiers.¶
A declarative set of requirements describing the desired path properties (e.g., jurisdiction constraints, approved operators, latency thresholds). The intent is the core of the query and defines what the PCS Server evaluates.¶
Optional parameters such as maximum acceptable data age or partial data acceptance.¶
The PCS Server processes the query by: 1. Gathering per-hop telemetry evidence from existing mechanisms in the operator's domain and, if necessary, obtaining conformance results from other PCS Servers via recursive sub-queries. 2. Reconstructing the PathView from the gathered evidence. 3. Performing Intent Matching: evaluating whether the reconstructed PathView conforms to the client's declared intent.¶
The server returns a PCS Response that contains:¶
A conformance result (match, no-match, unknown, or partial for multi-candidate queries) for the overall query and for each intent requirement.¶
A verification level indicating the confidence and verifiability of the result.¶
Metadata such as data age, provenance chain, and completeness.¶
Optionally, when the return_pathview option is enabled and permitted by service scope, a summary or detailed PathView.¶
Depending on deployment and query complexity, PCS queries may be handled synchronously or asynchronously. In the asynchronous case, the initial response includes a job identifier that can be used to retrieve results later.¶
Access to PCS Query endpoints MUST be subject to authentication and authorization controls. Queries that fall outside the PCS Server's service scope MUST be rejected with an appropriate error response.¶
This section is informative. The terms REQUIRED and OPTIONAL below describe the structure of the data model for interoperability guidance, not protocol-level requirements.¶
A PCS Query is a structured request sent by a PCS Client to a PCS Server, containing the client's intent (declarative path requirements) for evaluation against actual path characteristics. This section defines the JSON-based data structure for queries.¶
A PCS Query object contains the following fields:¶
This field is REQUIRED. It identifies the source and destination of the path being queried.¶
{
"endpoints": {
"from": {"type": "ip", "value": "10.1.1.10"},
"to": {"type": "ip", "value": "10.2.2.10"}
}
}
¶
Supported endpoint types:¶
This field is REQUIRED. It declares the client's requirements for the network path. PCS evaluates whether the path conforms to this intent.¶
{
"intent": {
"requirements": [
{"id": "xx-only", "property": "geo.country", "op": "in", "values": ["XX"]},
{"id": "latency-ok", "property": "latency.p99", "op": "lte", "value": 20}
],
"freshness": {"max_age": "60s"},
"privacy": {"granularity": "domain"}
}
}
¶
"requirements": Array of declarative intent expressions. Each requirement specifies a property and a condition to be satisfied. Geographic constraints use a whitelist (inclusion) approach (e.g., "op": "in") rather than a blacklist (exclusion) approach; this is a normative requirement specified in the Geographic Constraint Design Rationale (see Security Considerations), motivated by the fact that blacklist-based specifications risk omitting jurisdictions and thus failing to prevent unintended transit. Country codes are expected to follow ISO 3166-1. Country codes used in examples in this document (XX, XY, ZZ) are drawn from the ISO 3166-1 user-assigned range (AA, QM–QZ, XA–XZ, ZZ) and do not represent actual countries. Properties applicable to network nodes include, but are not limited to: operator, geo-location, supplier, model, hardware identifier, software name and version, and security status. Properties applicable to network edges vary by category: physical edges may specify protocol type and operator; tunnels may additionally specify tunnel identification, protocol type, integrity/confidentiality protection strength, and nested path property requests for the underlying network; software-defined networks may specify the controlling software and its security status. The full property namespace is extensible.¶
The structured form shown above (a property, an operator, and a set of values) is the interchange representation of an intent requirement and is what the PCS Server evaluates against the PathView. For simple comparisons this structured form is self-contained: a fixed set of operators (e.g., in, eq, lte) over an agreed property namespace yields an evaluator-independent, interoperable result.¶
Richer intents, however, require conditions beyond flat comparisons -- for example, Boolean composition (AND/OR/NOT), set operations, and quantification over path segments (e.g., "every hop is in XX", "no hop is in ZZ"). For such conditions, interoperability depends on the constraint expression language used to express and evaluate them: two implementations using different evaluators may reach different results for the same intent. A standardized, vendor-independent constraint expression language is therefore needed for full interoperability, and specifying it is an open standardization item that must be resolved before this specification can be finalized.¶
[TODO: Define a vendor-independent, interoperable constraint expression language for intent conditions (either by profiling an existing language or by specifying a minimal standard one). Until it is defined, the vendor dependency described below remains an unresolved gap toward standardization.]¶
As an interim measure, this revision uses Google's Common Expression Language (CEL) [CEL] as the constraint expression language for conditions that exceed the structured form above; implementations of this revision currently interoperate by evaluating such conditions with CEL. This is a deliberate interim commitment to a single language, not a statement that any evaluator is acceptable. The authors recognize that relying on CEL introduces a dependency on a single vendor-originated specification whose long-term stability and backward compatibility are not guaranteed under a recognized standards process. This vendor dependency is a known issue that the authors intend to remove before standardization, as noted in the TODO above; CEL is used here because it is what the current implementation employs, not because the authors consider it the final choice. The precise CEL evaluation profile -- how PathView attributes map to CEL variables, which language features are permitted, and how evaluation errors map to conformance results -- is not yet specified and is deferred to the standardization work called for above.¶
The authors actively solicit input on candidate constraint/query expression languages -- in particular a stable, standards-based language able to express at least equality/inequality, set membership, Boolean combination, and quantification over path segments -- and intend to raise this as an open question in relevant venues (e.g., IETF hackathons and the OPS area). - "freshness": Maximum age of acceptable telemetry data. - "privacy.granularity": - "point": per-hop disclosure (if permitted by service scope) - "domain": aggregated administrative-domain-level disclosure - "none": minimal disclosure (conformance result only)¶
This field is OPTIONAL. It controls execution behavior.¶
{
"options": {
"recursion_limit": 0,
"explain": true,
"return_pathview": "full"
}
}
¶
Allowed values:¶
recursion_limit: integer ≥ 0. Note: this field is provided for advanced use cases but carries security implications. Varying recursion limit values across queries may allow a client to infer properties of the internal network structure (e.g., number of intermediate ASes or network hierarchy depth). PCS Servers are expected to apply local policy to override or cap the client-specified value and not to expose the actual recursion depth used in the response metadata; these requirements are specified normatively in the Recursion Depth Information Leakage section (see Security Considerations).¶
explain: boolean. When true, non-conforming requirements include explanatory annotations.¶
return_pathview: one of "none", "summary", or "full". Controls whether a PathView is included in the response, subject to privacy and service scope constraints. The combination of explain and return_pathview effectively determines the evaluation mode, controlling the level of detail returned beyond the basic conformance result.¶
This field is OPTIONAL. It provides client guidance for expected/desired routing paths.¶
{
"path_hints": {
"as_path": [65001, 65003, 65002]
}
}
¶
This field is OPTIONAL. It allows bulk evaluation of multiple candidate paths within a single request.¶
{
"path_candidates": [
{"id": "primary", "path_hints": {"as_path": [65001,65003,65002]}},
{"id": "backup", "path_hints": {"as_path": [65001,65004,65002]}}
]
}
¶
POST /v1/pcs/queries:run¶
{
"endpoints": {
"from": {"type": "ip", "value": "10.1.1.10"},
"to": {"type": "ip", "value": "10.2.2.10"}
},
"intent": {
"requirements": [
{"id": "xx-only", "property": "geo.country", "op": "in", "values": ["XX"]},
{"id": "latency-ok", "property": "latency.p99", "op": "lte", "value": 20}
],
"freshness": {"max_age": "60s"},
"privacy": {"granularity": "domain"}
},
"options": {
"recursion_limit": 0,
"explain": true,
"return_pathview": "full"
}
}
¶
{
"endpoints": {
"from": {"type":"ip", "value":"10.1.1.10"},
"to": {"type":"ip", "value":"10.2.2.10"}
},
"intent": {
"requirements": [
{"id": "xx-only", "property": "geo.country", "op": "in", "values": ["XX"]}
],
"freshness": {"max_age":"60s"}
},
"path_candidates": [
{"id":"primary", "path_hints":{"as_path":[65001,65003,65002]}},
{"id":"backup", "path_hints":{"as_path":[65001,65004,65002]}}
],
"options": {"explain": true, "return_pathview": "summary"}
}
¶
This section is informative. The terms REQUIRED and OPTIONAL below describe the structure of the data model for interoperability guidance, not protocol-level requirements.¶
A PCS Response contains the result of intent matching: whether the actual path characteristics conform to the client's declared intent. This section defines the JSON-based data model for responses including synchronous queries, asynchronous jobs, and streaming notifications.¶
A PCS Response object contains the following fields:¶
"query_id" (string, REQUIRED)¶
"intent_results" (array, REQUIRED)¶
"pathview" (object, OPTIONAL)¶
"candidates" (array, OPTIONAL)¶
"overall" (string, REQUIRED)¶
"cache" (object, OPTIONAL)¶
"verification" (string, OPTIONAL)¶
"constructed_at" (timestamp, OPTIONAL)¶
"metadata" (object, OPTIONAL)¶
"message" (string, OPTIONAL)¶
For single-path queries, "intent_results" and optionally "pathview" are present. For multi-candidate queries, "candidates" is used instead, each containing its own "intent_results".¶
This field is OPTIONAL. It represents the reconstructed end-to-end path and its attributes.¶
Structure:
{
"pathview": {
"summary": {
"completeness": "full | partial",
"latency": {"p99": 8.7},
"geo": {
"countries": ["XX","XY"],
"opaque_segments": 1
}
},
"segments": [
{
"hop": "R1",
"operator": "AS65001",
"geo": {"country": "XX", "confidence_geo": 0.99},
"metrics": {"latency": {"p99": 1.2}},
"security": {"encryption": "IPsec", "integrity": "AES-256-GCM"},
"verification": "TRACED_PRESENT",
"provenance": {
"issuer": "pcs.as65001.net",
"issued_at": "2025-10-21T01:00:00Z"
},
"confidence": 0.95
}
],
"completeness": "full | partial",
"constructed_at": "2025-10-21T01:00:03Z"
}
}
¶
Descriptions:¶
"segments": hop-level or segment-level information. Each segment includes a "verification" field indicating the verification level of the evidence for that specific segment. The response top-level "verification" is derived as the lowest (weakest) verification level across all segments.¶
"verification" (per-segment): indicates the verification level for the evidence backing this segment. Completeness is a binary property (full/partial) aggregated at the pathview level, whereas verification is a multi-level property that varies per segment and is therefore attached to individual segments.¶
"provenance": mandatory metadata proving origin of each evidence fragment.¶
"confidence": numerical estimation combining multiple data sources. Per-property confidence values (e.g., "confidence_geo") may appear alongside property-specific data to indicate the reliability of individual attributes.¶
"summary": aggregate values to support privacy-preserving replies.¶
"completeness" appears at both the summary level (within "summary") and the top level of "pathview". The summary-level value reflects the completeness of aggregated data, while the top-level value reflects the overall completeness of the reconstructed path.¶
This field is REQUIRED. It contains an array of conformance results for each intent requirement.¶
{
"intent_results": [
{
"requirement_id": "xx-only",
"result": "match | no-match | unknown",
"explain": {
"violations": [
{"segment": "AS65004", "geo.country": "ZZ"}
]
}
}
]
}
¶
This field is REQUIRED. It indicates the overall conformance outcome of the query. For single-path queries, the value is derived from the "intent_results" array as follows:¶
"match": all intent requirements have "result" = "match"¶
"no-match": at least one intent requirement has "result" = "no-match"¶
"unknown": no requirement has "result" = "no-match", but at least one has "result" = "unknown" (i.e., insufficient data to determine conformance for that requirement)¶
For multi-candidate queries, an additional value is defined:¶
"partial": at least one candidate has "overall" = "match" and at least one has "overall" = "no-match" or "unknown"¶
Note: an opaque segment does not automatically produce "unknown". If the operator responsible for that segment asserts conformance within its service scope, the corresponding requirement may still evaluate to "match" at an OPAQUE verification level. "unknown" is returned only when the PCS Server cannot determine conformance — for example, when a sub-scope is unreachable, the recursion limit is exhausted, or the responding operator's service scope does not cover the requested property.¶
This field is OPTIONAL. It indicates whether cached telemetry was used.¶
{
"cache": {
"hit": false
}
}
¶
This field is OPTIONAL. It is used when evaluating multiple route candidates in bulk.¶
{
"candidates": [
{
"id": "primary",
"intent_results": [...],
"overall": "match",
"verification": "TRACED_PRESENT"
},
{
"id": "backup",
"intent_results": [...],
"overall": "no-match",
"verification": "OPAQUE_PRESENT"
}
],
"overall": "partial"
}
¶
Each candidate includes its own "verification" field because different candidates traverse different paths and may be backed by different levels of evidence. The response top-level "verification" for multi-candidate queries is derived as the lowest verification level across all candidates.¶
This field is OPTIONAL. It provides optional additional metadata.¶
{
"metadata": {
"recursion_limit_requested": 3,
"delegation_structure": "chain",
"evidence_sources": ["ipfix","gnmi","bgp-ls","geoip"],
"freshness": {"max_age":"60s"}
}
}
¶
"recursion_limit_requested": OPTIONAL. Echoes back the recursion limit value that was specified by the client in the query's "options.recursion_limit" field. This field reflects the client's requested value, not the actual recursion depth used by the PCS Server. PCS Servers do not populate this field with the actual recursion depth reached; this is a normative requirement specified in the Recursion Depth Information Leakage section (see Security Considerations). If the PCS Server applied a local policy to override or cap the client-specified value, this field still reflects the original client-specified value, so as not to reveal whether an override was applied.¶
"delegation_structure": OPTIONAL. Describes how recursive PCS-to-PCS queries were organized for this response. Possible values are:¶
"chain": sequential delegation (baton relay), where each PCS Server delegated to a single downstream PCS Server.¶
"tree": parallel or fan-out delegation, where a PCS Server delegated to multiple downstream PCS Servers simultaneously.¶
"direct": no delegation; all evidence was gathered locally.¶
This field is informative and intended to assist clients in interpreting the provenance chain structure. When the verification level is OPAQUE_PRESENT or OPAQUE_FUTURE, this field can be omitted, as the delegation structure is not relevant when only the conformance result is returned. When the verification level is TRANSPARENT_PRESENT or higher (see the Intent Matching Verification Levels section for the ordering), the delegation structure is implicitly visible in the provenance chain and this field serves as a convenience.¶
"evidence_sources": OPTIONAL. Indicates which existing telemetry mechanisms and data sources contributed to constructing the PathView for this response (e.g., "ipfix", "gnmi", "bgp-ls", "rpki", "geoip"). This field is informational and does not imply that PCS defines or operates these mechanisms.¶
This field is REQUIRED. It is a unique identifier assigned by the PCS Server to correlate this response with the original query. For asynchronous queries, the query_id is also used to retrieve results by polling the job endpoint.¶
This field is OPTIONAL. It indicates the verification level of the overall conformance result, derived as the lowest (weakest) verification level across all path segments. Possible values are defined in the Intent Matching Verification Levels section: TRACED_PRESENT, TRANSPARENT_PRESENT, TRACEABLE_OPAQUE_PRESENT, OPAQUE_PRESENT, TRACEABLE_OPAQUE_FUTURE, or OPAQUE_FUTURE. When a PathView is included in the response, clients can inspect per-segment verification levels within "pathview.segments" to identify which segments constrain the overall level.¶
This field is OPTIONAL. It is a timestamp (ISO 8601 format) indicating when the PCS Server constructed this response. Clients can use this value along with the "freshness" parameters to assess the timeliness of the result.¶
This field is OPTIONAL. It is a human-readable string summarizing the conformance result, intended for logging, alerting, or operator dashboards. The content of this field is informational and is not intended for automated decision-making; this is a normative requirement specified in Security Considerations (Information Disclosure). Unlike the structured "explain" data within "intent_results" (which provides machine-parseable violation details per requirement), "message" provides a single natural-language summary of the overall result suitable for direct display to operators.¶
{
"query_id": "q-uc1-1",
"cache": {"hit": false},
"intent_results": [
{
"requirement_id": "xx-only",
"result": "match"
}
],
"overall": "match",
"verification": "TRACED_PRESENT",
"constructed_at": "2025-10-21T01:00:03Z"
}
¶
{
"query_id": "q-uc1-2",
"intent_results": [
{
"requirement_id": "xx-only",
"result": "no-match",
"explain": {
"violations": [{"segment":"AS65004","geo.country":"ZZ"}]
}
}
],
"overall": "no-match",
"verification": "TRACED_PRESENT",
"constructed_at": "2025-10-21T01:05:05Z",
"message": "Intent (xx-only): non-conforming segment detected (AS65004, country=ZZ)"
}
¶
Used for subscriptions (SSE/Webhook/WebSocket). Each event includes a "verification" field so that the receiving operator or automation system can assess the confidence of the reported state change. For example, a "no-match" event at TRACED_PRESENT warrants immediate action (strong evidence of violation), whereas the same event at OPAQUE_PRESENT may call for further investigation before triggering remediation.¶
{
"event_id": "ev-20251021-001",
"type": "intent.no-match | topology.change | latency.exceed",
"occurred_at": "2025-10-21T01:05:05Z",
"query_id": "q-uc1-2",
"intent_results": [...],
"overall": "no-match",
"verification": "TRACED_PRESENT",
"message": "xx-only intent violated (AS65004, country=ZZ)"
}
¶
POST /v1/pcs/webhooks/events¶
{
"event_id": "wh-20251021-001",
"type": "intent.no-match",
"occurred_at": "2025-10-21T01:05:05Z",
"query_id": "q-uc1-2",
"endpoints": {"from":"10.1.1.10","to":"10.2.2.10"},
"intent_results": [...],
"overall": "no-match",
"verification": "TRACED_PRESENT",
"message": "xx-only intent violated: AS65004"
}
¶
HTTP paths and JSON examples in this document are illustrative and do not define a wire binding or encoding.¶
Only field names and constraints may become normative in future revisions.¶
Data model may be expressed in CDDL or JSON Schema in future revisions.¶
The constraint expression language used to evaluate intent conditions (currently CEL) is expected to be replaced by, or profiled as, a vendor-independent standard language; see the intent field definition in this section.¶
An intent matching response includes a verification level that indicates the degree of verifiability and temporal scope of the conformance result. The verification levels are listed below from highest (most transparent and verifiable) to lowest:¶
TRACED_PRESENT — strongest evidence, present-time¶
TRANSPARENT_PRESENT — full path detail, present-time¶
TRACEABLE_OPAQUE_PRESENT — opaque with trace ID, present-time¶
OPAQUE_PRESENT — conformance result only, present-time¶
TRACEABLE_OPAQUE_FUTURE — opaque with trace ID, future commitment within service scope¶
OPAQUE_FUTURE — conformance result only, future commitment within service scope¶
When this document refers to a verification level being "higher" than another, it means the level appears earlier in the list above (i.e., provides greater transparency and verifiability).¶
For traced verification, the intent matching result is backed by a recorded trace of the actual path, signed by each traversed network node with their identifications. This provides the strongest evidence that the intent requirements are satisfied at the present time. This type of verification requires dedicated support for packet traces in every network node.¶
For transparent verification, the intent matching result is accompanied by a list of traversed nodes and edges with their properties relevant to the intent evaluation. If the intent evaluation involves cascaded queries to other PCS Servers (e.g., for networks operated by third parties), the response includes the sub-results received from those servers. This verification level confirms that the intent is satisfied at the present time.¶
For traceable opaque verification, the intent matching result includes an opaque ID that corresponds to internal trace information. This ID can be used by operators to identify the records for troubleshooting in the future, without exposing the actual path details to the client. The result confirms that the intent is satisfied at the present time.¶
For opaque verification, the intent matching result contains only the conformance decision (match or no-match) without any supporting path details or trace identifiers. The result confirms that the intent is satisfied at the present time.¶
For traceable opaque future verification, the intent matching result includes an opaque ID for future troubleshooting reference. In addition, the responsible operator asserts, within its service scope, that the network is controlled so that the intent requirements are expected to remain satisfied even as dynamic routing changes occur.¶
For opaque future verification, the intent matching result contains only the conformance decision (match or no-match). Within its service scope, the responsible operator asserts that the network is controlled so that the intent requirements are expected to remain satisfied even as dynamic routing changes occur.¶
Secure Hybrid Network Monitoring with PCS will be shown with specific examples using several use cases.¶
Certain applications must ensure that communication paths remain entirely within a given legal jurisdiction.
For example, a financial institution may require that all customer data traffic remains within a specific jurisdiction, avoiding any transit through networks located in other countries.
The PCS Client declares this as an intent (e.g., geo.country IN ["XX"]) and submits it to the PCS Server.
PCS evaluates this intent by gathering geolocation evidence for each path segment and returning a conformance result.
If the intent is not matched (e.g., a segment is located outside the allowed set), the PCS Client can take preventive actions such as rejecting the path or raising an alert.¶
PCS role:¶
Receive intent declaring jurisdictional requirements from the PCS Client.¶
Gather geolocation and jurisdiction evidence for each path segment from existing telemetry mechanisms.¶
Perform intent matching to evaluate whether all segments satisfy the declared jurisdictional constraints.¶
Return a conformance result (match or no-match) with the appropriate verification level.¶
Some sectors, such as healthcare or energy, require that only approved network operators be involved in the transport of sensitive data.
For example, a healthcare information system may require that all intermediate networks along a path are operated by organizations on a predefined whitelist.
The PCS Client declares this as an intent (e.g., operator IN ["AS65001", "AS65003"]) and PCS evaluates whether the actual path conforms.¶
PCS role:¶
Receive intent declaring approved operator requirements from the PCS Client.¶
Gather operator identifiers and relevant cryptographic assertions from existing telemetry mechanisms and sources (e.g., RPKI, operator registries).¶
Perform intent matching to evaluate whether all path segments are operated by approved entities.¶
Return a conformance result (match or no-match) with the appropriate verification level.¶
When a security incident occurs, operators may need to reconstruct and verify the network path characteristics at the time of the incident. For example, during an investigation, a signed intent matching result and its associated provenance chain from PCS can be used as part of an evidence package to demonstrate whether the path conformed to the declared intent at a specific point in time. This can also support regulatory audits that require verifiable historical conformance data.¶
PCS role:¶
The following areas are candidates for additional use cases in future revisions of this document. They correspond to the architecture design goals identified in the Design Principles section and are noted here to ensure they are not overlooked:¶
Tunneling and virtualization verification: verifying that tunneled or virtualized path segments (e.g., VPN-over-VPN, SDN slices) satisfy intent requirements at both overlay and underlay levels.¶
DNS and addressing dependency: evaluating whether DNS resolution paths and addressing infrastructure conform to declared intent (e.g., DNS-over-HTTPS enforcement, address assignment authority).¶
Management-plane risk assessment: assessing non-network infrastructure risks (e.g., IaC configuration drift, cloud provider management access) as part of path conformance evaluation.¶
DoS resilience verification: verifying that path characteristics include adequate DoS mitigation properties (e.g., scrubbing center presence, rate-limiting capabilities).¶
The proposed "Secure Hybrid Network Monitoring - Path Characteristics Service" itself introduces several security considerations that have to be addressed:¶
The intent matching model is specifically designed to minimize information disclosure by returning conformance results (match/no-match) rather than raw network state. However, the system must still carefully balance the need for explainability (e.g., violation annotations) with the protection of sensitive infrastructure information. The human-readable message field in a PCS Response MUST NOT be used as the basis for automated decision-making; automated systems MUST instead use the structured intent_results (including explain) data.¶
Clear trust relationships must be established between different stakeholders in the hybrid cloud environment. Each PCS Server operates within a defined service scope, and trust chains are maintained through provenance metadata and digital signatures.¶
Proper mechanisms must be in place to ensure only authorized entities can submit intent queries and receive conformance results. Authentication credentials SHOULD be bound to specific connectivity channels.¶
Intent data, conformance results, and provenance chains must be protected from tampering or manipulation.¶
The intent submitted by a PCS Client may reveal sensitive information about the client's security requirements or business logic. PCS endpoints MUST protect intent data in transit and SHOULD restrict access to intent content based on authentication and authorization.¶
PCS Servers MUST only respond to queries within their pre-agreed service scope. Queries that fall outside this scope MUST be rejected without providing information that could be used to infer the server's capabilities or internal network structure. This prevents probing attacks, where an adversary systematically submits queries with varying parameters to map out the network topology or discover what properties a PCS Server can evaluate.¶
As described in Section 4, PCS supports recursive composition across administrative boundaries. The recursion_limit parameter in PCS queries carries inherent security implications. By varying the recursion depth across multiple queries and observing differences in response times, completeness, or conformance results, an adversary may be able to infer properties of the internal network structure, such as the number of intermediate autonomous systems, the depth of the network hierarchy, or the presence of specific transit relationships.¶
To mitigate this risk:¶
PCS Servers SHOULD apply their own local policy to override or cap the client-specified recursion_limit value.¶
PCS Servers SHOULD NOT expose the actual recursion depth used or reached in the response metadata.¶
PCS Servers MUST NOT populate response fields (e.g., recursion_limit_requested) with the actual recursion depth used or reached.¶
PCS Servers MAY normalize response timing to reduce the information available through timing analysis.¶
The specific security implications of the recursion_limit field should be documented in operational deployment guides.¶
PCS intent specifications for geographic constraints MUST use a whitelist (inclusion) approach exclusively; blacklist (exclusion) specifications MUST NOT be used because they create a risk of omission: if a new jurisdiction or transit path is not included in the blacklist, traffic may traverse that jurisdiction without detection. The whitelist approach is more robust because it requires explicit approval of each allowed jurisdiction, ensuring that any unlisted jurisdiction is automatically excluded.¶
The PCS Server gathers per-hop evidence made available by operator-controlled telemetry mechanisms within the operator's administrative domain. These mechanisms, their transport, and their protection are operator-internal concerns governed by the operator's policies and by the specifications of the mechanisms themselves (e.g., [RFC7011] for IPFIX, which recommends TLS/DTLS for its transport). This document does not define telemetry-acquisition mechanisms or their security requirements. Within the operator's trust boundary, the PCS Server is the entity that assembles this evidence into a PathView and asserts its trustworthiness to external parties through the provenance mechanisms described elsewhere in this document; the trustworthiness of inputs from individual telemetry mechanisms is established by operator-local controls.¶
This document has no IANA actions.¶
This work is supported by NEDO grants P23013 from the New Energy and Industrial Technology Development Organization.¶