]> China Unicom

Beijing China shijy70@chinaunicom.cn

China Unicom

Beijing China wangcc107@chinaunicom.cn

China Unicom

Beijing China fuy186@chinaunicom.cn

routing cats Internet-Draft Computing-Aware Traffic Steering (CATS) inherits potential security vulnerabilities from the network, computing nodes as well as workflows of CATS. This document describes various threats and security concerns related to CATS and existing approaches to solve these threats.

Introduction The CATS framework is an ingress-based overlay framework for the selection of the suitable service instance(s) from a set of instance candidates. By taking into account both networking and computing metrics, the CATS framework achieve a global of dispatching service demands over the various and available edge computing resources. However, ubiquitous distributed computing resources in CATS also pose challenges to security protection. The operators of CATS may not have complete control over the nodes and therefore guarantee the security and credibility of the computing nodes themselves. Moreover, there are great differences in the security capabilities provided by computing nodes in the network, which greatly improves the breadth and difficulty of security protection. This document describes various threats and security concerns related to CATS and existing approaches to solve these threats.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology This document makes use of the following terms: Computing-Aware Traffic Steering (CATS): A traffic engineering approach that takes into account the dynamic nature of computing resources and network state to optimize service-specific traffic forwarding towards a given service instance. Various relevant metrics may be used to enforce such computing-aware traffic steering policies. CATS Service ID (CS-ID): An identifier representing a service, which the clients use to access it. Service: An offering provided by a service provider and which is delivered using one or more service functions . CATS Service Metric Agent (C-SMA): An agent that is responsible for collecting service capabilities and status, and for reporting them to a CATS Path Selector (C-PS). Service request: The request for a specific service instance.

Security Issues of The Computing Resources The ubiquitous and flexible characterictics of computing resources and the frequent connections to the computing resources will lead to the following risks:

• Unauthorized Access and Control Attackers may exploit vulnerabilities in interfaces or APIs to gain unauthorized access, potentially hijacking computational resources or manipulating task execution.
• Data Confidentiality Breaches Sensitive data processed by computing resources (e.g., model parameters in ML workloads) could be intercepted during transmission or compromised through insecure memory handling.
• Denial-of-Service (DoS) Threats Malicious actors may flood computing resources with forged computation requests, degrading service availability or disrupting task scheduling.

To address these risks, CATS implementations COULD adopt the following safeguards:

• Secure Communication Frameworks
  • TLS 1.3 could be adopted for all control-plane and data-plane communications.
  • Certificate-based mutual authentication could be implemented using IETF SUIT for Computing Service to C-SMA interactions.
• Granular Access Control
  • Role-based access policies (RBAC) aligned with AAA architecture could be used to manage the data processing in computing resources .
  • Hardware-rooted attestation (e.g., TPM measurements) could be used for runtime authorization decisions.
• Resilience Against DoS
  • Proof-of-work challenges for request authentication could be deployed as the resilience against DoS during traffic anomalies.
  • Geo-distributed traffic scrubbing could be enabled through collaboration with CDN providers.
• Continuous Monitoring
  • Nodes could be instrumented with runtime integrity verification using OpenTelemetry standards.
  • Anomaly detection systems leveraging federated learning could be established to identify cross-node attack pattern.

Computing Path Selector Security Issues The Computing Path Selector which is responsible for dynamically selecting optimal forwarding paths, faces the following threats:

• Path Manipulation Attacks Adversaries may forge or alter path metadata (e.g., node capabilities, network latency) to steer computation tasks toward compromised nodes.
• Covert Channel Exploitation Path selection patterns could be abused to leak sensitive information through timing analysis or topology fingerprinting.
• Topology Poisoning Injection of forged network topology data could degrade path selection efficiency or enable man-in-the-middle (MITM) attacks.
• Decision Logic Corruption Runtime modification of C-PS algorithms may lead to suboptimal or adversarial path selections.
• Orchestrator Impersonation Spoofed control-plane messages could trick CPS into accepting unauthorized path directives.

To mitigate these risks, CATS implementations COULD implement the following countermeasures:

• Authenticated Path Metadata
  • Digitally sign topology updates and node capability information could be implemented using CBOR Object Signing and Encryption (COSE) .
  • Enforce strict schema validation for path attributes per IETF YANG models .
• Decision Integrity Protection
  • C-PS path selection logic could be isolated in hardware-rooted trusted execution environments (TEEs).
  • Runtime attestation of decision engines could be implemented via Remote Attestation Procedures (RATS) .
• Differential Privacy for Path Selection
  • Sensitive selection patterns could be Obfuscated by incorporating differentially private noise.
• Resilient Topology Discovery
  • RPKI or BGPsec principles could be adopted for secure topology propagation in multi-domain scenarios.
• Control-Plane Hardening
  • Mutual authentication could be adopted in communications between C-PS and C-SMA or C-NMA via OAuth 2.1 .

Computing Service Announcement Security Issues The announcement of computing services in distributed environments introduces several security risks that must be addressed to ensure system integrity, confidentiality, and availability. This section outlines key threats and proposed countermeasures.

• Unauthorized Announcement Injection Malicious actors may forge or manipulate service announcements to advertise rogue computing nodes, redirect traffic to compromised resources, or disrupt service discovery, which may lead to data exfiltration, computation tampering or denial of service.
• Sensitive Information Exposure Service announcements containing unencrypted metadata (e.g., topology details, capability descriptors) may reveal sensitive infrastructure or operational patterns, which may lead to attack surface expansion for targeted exploits or reconnaissance.
• Replay/Reuse of Legacy Announcements Replayed announcements of deprecated services could lead to resource misallocation or dependency on outdated/insecure compute nodes.
• DoS Through Announcement Flooding Flooding the control plane with excessive or malformed announcements may lead to system resources exhausted.
• Identity Spoofing Impersonation of legitimate service providers through forged identity claims in announcements.

To address these risks, CATS implementations COULD adopt the following mitigation measures:

• Cryptographic Integrity Protection
  • Digital signatures (e.g., using COSE/JOSE) could be adopted for all announcements to ensure authenticity and integrity.
  • Verifiable attestation (via frameworks like RATS) could be used for critical service claims.
• Metadata Minimization & Encryption
  • Data minimization principles could be applied to limit exposed metadata in announcements.
  • Hybrid encryption (e.g., ECIES) could be used for sensitive fields while maintaining routable/public attributes in cleartext.
• Anti-Replay Mechanisms
  • Timestamp/nonce could be used in announcements with strict freshness validation.
• Rate Limiting & Prioritization
  • QoS controls could be applied to prioritize announcements from authenticated entities.
  • Rate limits per node/domain could be adopted using token-bucket or similar algorithms.
• Identity Verification
  • The announcement from the computing devices could be binded to DIDs (Decentralized Identifiers) or VCs (Verifiable Credentials) for cryptographic identity proof.

Metrics Distribution Security Issues Metrics distribution mechanisms in CATS are critical for performance optimization and resource coordination. However, they introduce specific security challenges that must be mitigated to prevent misuse or systemic compromise. This section identifies key threats and proposes countermeasures.

• Tampering with Metric Data Adversaries may alter metrics (e.g., latency, throughput, resource utilization) during transmission to mislead the decision-making of control plane, triggering suboptimal traffic placement or resource allocation and leading to degraded service performance.
• Eavesdropping on Sensitive Metrics Unauthorized interception of metrics may cause the eavesdropping on sensitive operational details (e.g., geo-location patterns, infrastructure capacity), which will lead to the exposure of business-critical intelligence or user behavior profiling.
• Forged Metric Sources Spoofing of metric publishers to inject false data or impersonate trusted entities (e.g., fake "low-load" signals to attract traffic).
• Privacy Violations via Aggregation The statistical analysis of aggregated metrics may produce inference of sensitive information (e.g., user activity, infrastructure weaknesses) which may result in privacy violation.

To address these risks, CATS implementations COULD adopt the following safeguards:

• End-to-End Integrity Protection
  • Cryptographic signatures (e.g., using COSE/JOSE) could be applied to metric payloads to ensure authenticity and detect tampering.
  • Hash-chaining or Merkle trees could be used for batch metric verification in streaming scenarios.
• Confidentiality Preservation
  • Sensitive metric fields could be encrypted (e.g., using AES-GCM or HPKE)while preserving routable headers in cleartext.
  • Differential privacy or noise injection could be employed for aggregated metrics to prevent inference attacks.
• Source Authentication
  • Metric publishers could be binded to cryptographically verifiable identities (e.g., X.509 certificates, DIDs).
  • Role-based access control (RBAC) could be used for metric publication rights.
• Privacy-Aware Metric Design
  • The high-granularity data (e.g., masking exact geolocation to regional levels) could be anonymized or truncated to protect the privacy.
  • The federated learning or on-device aggregation could be used to minimize raw data exposure.

Security-related Metrics The service and network metrics could include the security-related capabilities which could be used by the CATS Path selector to compute paths with security guarantee. The security capabilities of nodes could be one of the metrics for C-PS to computing the traffic forwarding path and form a secure routing path. And C-PS will fetch the real-time awareness of the security capabilities available in the network and computing services and finally provide security protection for users. Clients with high security requirements could choose the service with desired security attributes and achieve dependable forwarding on top of only devices that satisfies certain trust requirements, which will avoid the risks of traffic eavesdropping, sensitive data leakage etc.

Security Considerations The security considerations of CATS are presented throughout this document. .

IANA Considerations This document has no IANA actions.

References Normative References RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Informative References Huawei Technologies China Mobile Orange Telefonica Juniper Networks, Inc. This document describes a framework for Computing-Aware Traffic Steering (CATS). Particularly, the document identifies a set of CATS components, describes their interactions, and exemplifies the workflow of the control and data planes. This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality. In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. This memo provides information for the Internet community. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed. This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF.

Acknowledgements TBD