Secure Hybrid Network Monitoring - Path Characteristics Service

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 10 April 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Virtualized resources such as cloud computing infrastructure are rapidly replacing traditional network and computing environments, including on-premises servers and locally managed clusters. In such infrastructures, 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 "Secure hybrid network monitoring - Problem statement" [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 obtaining and verifying relevant characteristics of the network paths used in complex environments such as hybrid or multi-cloud deployments. PCS is intended to provide a common framework for securely obtaining, interpreting, and acting upon path-level information, 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 framework for obtaining, synthesizing, and evaluating verifiable information about the characteristics of network paths used by an application or tenant. 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). PCS defines:¶

• (1) mechanisms to obtain path-related evidence from multiple sources,¶

• (2) methods to reconstruct a coherent view of the path and its attributes from such evidence,¶

• (3) a policy-matching mechanism that evaluates whether a given path conforms to declarative requirements.¶

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. Rather, it provides a verifiable interface and data model that higher-layer systems can use to reason about path trust and to trigger operational actions.¶

2. Design Principles

3. Architecture Overview

The PCS architecture is organized into three conceptual layers, shown in {#fig-pcs-layers}:¶

• PCS Layer - Hosts PCS Servers and Clients, which exchange queries and responses regarding path characteristics. A PCS Server gathers data from one or more Telemetry Layer components, reconstructs path-level views, and evaluates them against applicable policies. PCS instances may also recursively query other PCS instances in adjacent administrative domains to obtain a broader or deeper view of the path.¶

• Telemetry Layer - Provides standardized access to measurements and topology information, collected by Telemetry Collectors from the underlying network. Depending on operator policy and technical constraints, this may include performance metrics, topology summaries, or security-related status. PCS uses defined APIs to query this layer, allowing integration with existing protocols (e.g., NETCONF, gNMI, BGP-LS, SNMP).¶

• Network Layer - Comprises the physical and virtual network elements such as routers, switches, links, VPN endpoints, and SDN-controlled domains. These elements generate raw operational data, which is exposed upward through the Telemetry Layer.¶

+-----------------------------------------------------------+
|                       PCS Layer                           |
|   [PCS Server]  <-->  [PCS Server]  <-->  [PCS ...]       |
|      (gathering / reconstruction / policy matching)       |
+-----------------------------------------------------------+
|                    Telemetry Layer                        |
|   [Collector]   [Normalizer]   [DB/Cache]   [Topology]    |
+-----------------------------------------------------------+
|                     Network Layer                         |
|   [Routers/Switches]  [Links]  [VPNs]  [SDN Domains]      |
+-----------------------------------------------------------+

Client -> PCS(Server-G): Query{target, required_properties, freshness, recursion_limit}
PCS(Server-G) -> PCS(Server-A): SubQuery{scope=A, required_properties..., freshness, trail}
PCS(Server-A) -> Telemetry(A): gather()
PCS(Server-G) <- PCS(Server-A): PathView{A}, evidence_refs, confidence
PCS(Server-G) -> PCS(Server-B): SubQuery{scope=B, ...}
PCS(Server-G) <- PCS(Server-B): PathView{B}, ...
Client <- PCS(Server-G): Result{PathView{A-B}, policy_decision, trace, completeness}

4. Roles and Responsibilities

This section defines the main roles in a PCS-enabled environment. The roles align with the three-layer model described in {#fig-pcs-layers}.¶

• Network Operator / Domain Owner - Responsible for the physical and virtual network infrastructure. They control the disclosure policy for topology and telemetry data, and may operate or delegate the Telemetry Layer components. They are the authoritative source of truth for the properties of network elements within their administrative domain.¶

• Telemetry Collector / Aggregator - Operates within the Telemetry Layer to gather and normalize data from network devices and services. Collectors may use standardized protocols (e.g., NETCONF, gNMI, BGP-LS, SNMP) or vendor-specific mechanisms. Aggregators combine data from multiple collectors or domains, and may provide cached or summarized information to PCS Servers.¶

• PCS Server - Hosts the PCS functionality, including querying the Telemetry Layer, reconstructing path-level characteristics, and applying policy matching. A PCS Server may recursively query other PCS Servers in adjacent domains to extend its view beyond local telemetry.¶

• PCS Client - An application or system component that requests path characteristics from a PCS Server. Clients may use the information to make operational or security decisions, such as selecting a compliant path or avoiding a path with undesirable properties.¶

5. PCS Main Functions

The PCS Layer provides three main functional stages when processing a path characteristics query:¶

• Gathering - Collects relevant evidence from the Telemetry Layer and, where applicable, from other PCS Servers via recursive queries. Evidence may include metrics, topology fragments, operational status, and security-relevant events. Data sources can be heterogeneous and may vary in freshness and granularity.¶

• Reconstruction - Builds an end-to-end "PathView" from the gathered evidence. Reconstruction may operate at different levels of abstraction:¶

  • Point-level view - Characteristics for each individual network element (e.g., router, link).¶

  • Domain-level view - Aggregated characteristics for an entire administrative domain or SDN segment. The reconstruction process resolves conflicts, fills gaps using partial data, and ensures that the resulting PathView is internally consistent.¶

• Policy Matching - Compares the reconstructed PathView against a set of predefined policies provided by the PCS Client. Policies may include security requirements (e.g., encryption in transit, jurisdiction constraints), performance thresholds (e.g., maximum latency), or operational constraints (e.g., avoiding specific domains). The PCS Server returns a compliance result, possibly with annotations explaining non-compliance or uncertainty.¶

6. Path Characteristics Service (PCS)

The Path Characteristics Service (PCS) provides an authenticated and access-controlled endpoint for requesting and receiving status statements regarding the characteristics of network paths. PCS is typically operated by network operators or connectivity providers, or it may also be offered by third-party service providers or cloud operators. It answers queries about the real-time or recent status of network paths to authenticated clients.¶

In multi-stakeholder environments, such as hybrid or multi-cloud deployments, a PCS Server may query other PCS Servers operated by different providers. This recursive gathering enables a PCS to return aggregated and policy-filtered status information to the requesting client.¶

7. PCS Query

A PCS Query is the primary mechanism by which a PCS Client requests path characteristics information from a PCS Server.¶

A query typically includes: - Target Path - The path or set of candidate paths for which characteristics are requested, identified by endpoints, AS-paths, or other topology identifiers. - Requested Characteristics - Specific metrics or properties to be returned (e.g., jurisdiction, encryption status, latency). - Policy Set (optional) - Policies to be applied for Policy Matching, expressed in a structured form understood by the PCS Server. - Query Constraints - Optional parameters such as maximum acceptable data age, recursion depth, or partial data acceptance.¶

The PCS Server processes the query by: 1. Gathering evidence from the Telemetry Layer and, if necessary, from other PCS Servers. 2. Reconstructing the PathView from the gathered data. 3. Performing Policy Matching if a policy set is provided.¶

The server returns a PCS Response that may contain: - The reconstructed PathView (point-level and/or domain-level view). - Policy Matching results (pass/fail/unknown) for each policy. - Metadata such as data age, sources used, and recursion depth reached.¶

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, and responses MAY apply redaction or aggregation according to the policies of the Network Operator or Domain Owner.¶

8. Use cases

Secure Hybrid Network Monitoring with PCS will be shown with specific examples using several use cases.¶

9. Security Considerations

The proposed "Secure Hybrid Network Monitoring - Path Characteristics Service" itself introduces several security considerations that have to be addressed:¶

• Information Disclosure: The system must carefully balance the need for security monitoring with the protection of sensitive infrastructure information.¶

• Trust Model: Clear trust relationships must be established between different stakeholders in the hybrid cloud environment.¶

• Authentication and Authorization: Proper mechanisms must be in place to ensure only authorized entities can access monitoring information.¶

• Integrity Protection: The monitoring data itself must be protected from tampering or manipulation.¶

10. IANA Considerations

Currently, we assume that IANA actions are not necessary, but we plan to make corrections as necessary.¶

11. References

Acknowledgments

This work is based on results obtained from a project JPNP23013 commissioned by the New Energy and Industrial Technology Development Organization (NEDO).¶

Authors' Addresses