NeoTec L. Dunbar, Ed.
Internet-Draft Futurewei
Intended status: Standards Track H. Chihi
Expires: 4 September 2025 InnovCOM Sup'COM
3 March 2025
Zero Trust Network Access DM for Network Cloud Interface
draft-dunchihi-neotec-zerotrust-access-dm-00
Abstract
This document defines a YANG data model for implementing Zero Trust
Network Access (ZTNA) principles at the network-cloud interface. It
addresses security gaps in traditional network architectures by
enforcing identity-based access control, least privilege enforcement,
secure exposure of resources, and continuous monitoring. The model
enables real-time policy enforcement between Cloud-Aware Service
Orchestrators and Network Controllers, ensuring that only authorized
entities have access to specific network and cloud telemetry.
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 4 September 2025.
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
Dunbar & Chihi Expires 4 September 2025 [Page 1]
Internet-Draft Resource Abstraction March 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. What is Zero Trust . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 4
5. High-Level Objective of the ZTNA YANG Model . . . . . . . . . 5
5.1. Least Privilege Enforcement . . . . . . . . . . . . . . . 5
5.2. Secure Exposure . . . . . . . . . . . . . . . . . . . . . 6
6. ZTNA YANG Model in TREE Format . . . . . . . . . . . . . . . 6
7. ZTNA YANG Model . . . . . . . . . . . . . . . . . . . . . . . 7
8. Utilizing the ZTNA YANG Module . . . . . . . . . . . . . . . 11
8.1. Utilizing Least Privilege Enforcement . . . . . . . . . . 11
8.2. Using Secure Exposure . . . . . . . . . . . . . . . . . . 12
8.3. Utilizing Continuous Monitoring . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Normative References . . . . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Modern telecom networks increasingly rely on cloud based
infrastructures to deploy and manage services. However, existing
network cloud coordination lacks security mechanisms to enforce
identity based access control and least privilege principles, leaving
critical interfaces vulnerable to unauthorized access and potential
data leaks.
Zero Trust Network Access (ZTNA) principles mandate strict
verification of identities, access control based on policies, and the
least privilege model to ensure only authorized entities can interact
with network and cloud resources. This document defines a YANG model
that introduces ZTNA policies into the Neotec (NetOps4Clouds)
framework to address these security concern.
Dunbar & Chihi Expires 4 September 2025 [Page 2]
Internet-Draft Resource Abstraction March 2025
1.1. What is Zero Trust
Zero Trust is a cybersecurity framework (NIST-800-207) that assumes
no implicit trust between users, devices, or applications within or
outside an organization's network. Instead, it enforces continuous
verification of identity, strict access control policies, and least
privilege enforcement to minimize security risks.
Key principles of Zero Trust include:
- Verify Explicitly: Always authenticate and authorize based on all
available data points (e.g., user identity, device health, location,
access time).
- Least Privilege Access: Limit user and device access to only the
resources necessary for their function.
- Assume Breach: Implement security measures as if a breach has
already occurred, including micro segmentation and monitoring.
- Continuous Monitoring: Regularly assess and enforce security
policies based on real time threat intelligence.
- Secure Access to Resources: Ensure that network and cloud resources
are exposed only to authenticated and authorized entities.
2. Conventions used in this document
The following conventions are used in this document.
Edge DC: Edge Data Center, which provides the hosting environment
for the edge services. An Edge DC might host 5G core functions in
addition to the frequently used edge services.
ZTNA: Zero Trust Network Access [NIST-800-207]
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 [RFC8174] when, and only when, they appear in all capitals, as
shown here.
Dunbar & Chihi Expires 4 September 2025 [Page 3]
Internet-Draft Resource Abstraction March 2025
3. Problem Statement
The rapid adoption of cloud-hosted services and dynamic network
policies has introduced new security challenges for network
operators. Traditional network security models rely on perimeter-
based defenses, which are inadequate for securing interfaces between
cloud-aware orchestrators and network controllers. The following
issues highlight the necessity of a ZTNA-based approach:
- Lack of Fine-Grained Access Control: Existing mechanisms do not
provide identity-based access restrictions for network-cloud
coordination, leading to excessive privileges being granted.
- Exposure of Sensitive Network and Cloud Resources**: Without proper
restrictions, sensitive cloud and network telemetry data may be
exposed to unauthorized entities.
- Dynamic Nature of Cloud Services: As cloud services scale
dynamically, security policies must adapt in real time to ensure
continuous enforcement of least privilege principles.
- Absence of Standardized Security Policies: There is no standardized
framework for enforcing ZTNA principles in network-cloud
coordination, leading to inconsistent implementations across
operators.
To address these concerns, this document proposes a YANG model to
integrate ZTNA-based policies into the Neotec framework, ensuring
secure, dynamic, and identity-driven access control for network-cloud
interactions
4. Gap Analysis
Existing IETF initiatives, including TEAS, OPSAWG, and CATS,
primarily focus on policy-based network orchestration, telemetry, and
capability-aware routing. However, these initiatives do not
adequately address real-time ZTNA policy enforcement for network-
cloud interfaces. The following gaps exist:
- Lack of identity-based access control mechanisms between Cloud
Service Orchestrators and Network Controllers.
- Absence of least privilege enforcement to restrict access to
network and cloud telemetry.
- No standardized model to secure exposure of cloud and network
resources dynamically.
Dunbar & Chihi Expires 4 September 2025 [Page 4]
Internet-Draft Resource Abstraction March 2025
This draft introduces a YANG model to bridge these gaps, ensuring
secure network-cloud interactions and enabling trust-based
coordination.
5. High-Level Objective of the ZTNA YANG Model
The primary objective of this YANG model is to provide a standardized
mechanism to enforce ZTNA principles at the interface between network
and cloud Aware Orchestration systems. Specifically, the model aims
to:
- Establish identity-based access control policies for securing
network-cloud interactions.
- Enable least privilege enforcement, ensuring entities only access
necessary resources.
- Secure the exposure of network and cloud telemetry, preventing
unauthorized access.
- Provide continuous monitoring capabilities to detect unauthorized
access attempts and security anomalies.
- Provide a scalable and extensible structure for future security
enhancements.
- Ensure real-time, policy-driven security coordination between
cloud-aware orchestrators and network controllers.
To address these concerns, this document proposes a YANG model to
integrate ZTNA based policies into the Neotec framework, ensuring
secure, dynamic, and identity-driven access control for network-cloud
interactions.
5.1. Least Privilege Enforcement
Least Privilege Enforcement ensures that users, devices, or systems
have only the minimum level of access necessary to perform their
tasks, nothing more.
Key Aspects of Least Privilege Enforcement:
- Granular Access Control: Restrict access to only the specific
resources, data, or services needed for a user or system to perform
its function.
Dunbar & Chihi Expires 4 September 2025 [Page 5]
Internet-Draft Resource Abstraction March 2025
- Role-Based Access Control (RBAC): Assign permissions based on roles
(e.g., admin, operator, viewer) rather than granting broad,
unrestricted access.
- Time-Bound Access: Limit access duration to only when needed,
ensuring that privileges expire automatically when a task is
complete.
- Just-In-Time (JIT) Access: Dynamically grant access only when it is
required and revoke it immediately after use.
- Audit and Monitoring: Continuously track access and permissions to
detect potential violations or suspicious activity.
In the YANG model for ZTNA, Least Privilege Enforcement is
implemented through the restricted metric list inside the least-
privilege-enforcement container. This ensures that access to network
and cloud metrics is controlled and restricted.
5.2. Secure Exposure
Secure Exposure in ZTNA ensures that sensitive network and cloud
resources are exposed in a controlled, encrypted, and policy-driven
manner, preventing unauthorized access while still providing
necessary information to authorized entities. Instead of allowing
unrestricted access to network telemetry, cloud metrics, or
infrastructure details, Secure Exposure defines what data is shared,
with whom, and at what level of detail while ensuring that the
exposed data remains protected from potential threats.
In cloud-network integration, Secure Exposure ensures that a Cloud
Orchestrator or a Network Controller receives only the essential
network or cloud information needed for their operations. For
example, a Cloud Orchestrator may require network utilization metrics
for service placement optimization but should not have access to
detailed routing tables or security logs. This principle not only
restricts access but also ensures that any exposed information is
encrypted and transmitted securely, reducing the risk of interception
or misuse.
6. ZTNA YANG Model in TREE Format
The following is the TREE format representation of the ZTNA YANG
model for the interface betweem network controller and cloud aware
service orchestrator.
Dunbar & Chihi Expires 4 September 2025 [Page 6]
Internet-Draft Resource Abstraction March 2025
module: ietf-ztna-netcloud
+--rw ztna-policy
+--rw enable-ztna boolean
+--rw identity-based-access
| +--rw access-rule* [id]
| +--rw id string
| +--rw identity string
| +--rw role string
| +--rw access-level enumeration
+--rw least-privilege-enforcement
| +--rw enforce boolean
| +--rw restricted-metric* [metric-name]
| +--rw metric-name string
| +--rw access-level enumeration
+--rw secure-exposure
| +--rw encrypt-metrics boolean
| +--rw exposed-metric* [metric-name]
| +--rw metric-name string
| +--rw exposure-level enumeration
+--rw continuous-monitoring
+--rw enable-monitoring boolean
+--rw log-events boolean
+--rw alert-threshold uint32
+--rw threat-detection boolean
+--rw monitoring-interval uint32
+--rw audit-logs* [log-id]
+--rw log-id string
+--rw timestamp string
+--rw source string
+--rw severity enumeration
+--rw description string
7. ZTNA YANG Model
module ietf-ztna-netcloud {
namespace "urn:ietf:params:xml:ns:yang:ietf-ztna-netcloud";
prefix ztna-netcloud;
import ietf-inet-types {
prefix inet;
}
organization
"IETF Neotec (NetOps4Clouds) Working Group";
contact
Dunbar & Chihi Expires 4 September 2025 [Page 7]
Internet-Draft Resource Abstraction March 2025
"WG Web: ";
description
"ZTNA YANG Model.";
revision 2025-02-27 {
description
"Initial version with complete ZTNA support.";
reference
"Neotec (NetOps4Clouds) ";
}
container ztna-policy {
description "ZTNA Policy";
leaf enable-ztna {
type boolean;
default true;
description "Enable or disable ZTNA.";
}
container identity-based-access {
description "Identity-based access control policies.";
list access-rule {
key "id";
description "List of ID-based access control rules.";
leaf id {
type string;
description "Unique identifier for the access rule.";
}
leaf identity {
type string;
description "Identity authorized for access.";
}
leaf role {
type string;
description "Role or privilege associated with the ID.";
}
leaf access-level {
type enumeration {
enum read-only;
enum read-write;
enum full-control;
Dunbar & Chihi Expires 4 September 2025 [Page 8]
Internet-Draft Resource Abstraction March 2025
}
description "Level of access granted to the ID.";
}
}
}
container least-privilege-enforcement {
description "Enforce least privilege access.";
leaf enforce {
type boolean;
default true;
description "Enable enforcement of least privilege .";
}
list restricted-metric {
key "metric-name";
description "List of metrics that require restricted access.";
leaf metric-name {
type string;
description "Name of the restricted metric.";
}
leaf access-level {
type enumeration {
enum none;
enum summary-only;
enum detailed;
}
description "Level of access permitted for the metric.";
}
}
}
container secure-exposure {
description "Controls the secure exposure.";
leaf encrypt-metrics {
type boolean;
default true;
description "Enable encryption of exchanged metrics.";
}
list exposed-metric {
key "metric-name";
description "List of metrics securely exposed.";
Dunbar & Chihi Expires 4 September 2025 [Page 9]
Internet-Draft Resource Abstraction March 2025
leaf metric-name {
type string;
description "Name of the metric being exposed.";
}
leaf exposure-level {
type enumeration {
enum public;
enum restricted;
enum private;
}
description "Level of exposure allowed for the metric.";
}
}
}
container continuous-monitoring {
description "Continuous monitoring and anomaly settings.";
leaf enable-monitoring {
type boolean;
default true;
description "Enable or disable continuous monitoring.";
}
leaf log-events {
type boolean;
default true;
description "Enable or disable logging of security events.";
}
leaf alert-threshold {
type uint32;
description "Threshold for triggering security alerts.";
}
leaf threat-detection {
type boolean;
default true;
description "Enable or disable threat detection mechanisms.";
}
leaf monitoring-interval {
type uint32;
units "seconds";
description "Interval for security monitoring checks.";
}
}
Dunbar & Chihi Expires 4 September 2025 [Page 10]
Internet-Draft Resource Abstraction March 2025
}
}
8. Utilizing the ZTNA YANG Module
8.1. Utilizing Least Privilege Enforcement
Enforcing Least-Privilege Access ensures that cloud aware service
orchestrators and network controllers only access the data they need,
at the appropriate granularity, without exposing unnecessary
information. For example, a Cloud aware servuce Orchestrator may
require access to network-latency metrics for service optimization
but should not have visibility into sensitive bandwidth usage data.
Meanwhile, a Network Controller performing advanced analytics may
need detailed CPU load metrics to optimize resource allocation. The
following JSON representation enforces these access controls
dynamically, ensuring that only authorized entities can access
specific network and cloud metrics at the required level.
{
"ztna-policy": {
"enable-ztna": true,
"least-privilege-enforcement": {
"enforce": true,
"restricted-metric": [
{
"metric-name": "network-latency",
"access-level": "summary-only"
},
{
"metric-name": "bandwidth-usage",
"access-level": "none"
},
{
"metric-name": "cpu-load",
"access-level": "detailed"
}
]
}
}
}
This JSON structure defines a policy where the Cloud Aware Service
Orchestrator has summary-only access to network-latency, meaning it
can see only high-level trends without detailed breakdowns. The
bandwidth-usage metric is completely restricted (none), preventing
Dunbar & Chihi Expires 4 September 2025 [Page 11]
Internet-Draft Resource Abstraction March 2025
unauthorized access. Meanwhile, the Network Controller is granted
detailed access to cpu-load, allowing it to monitor and adjust
network resources in real time. This approach ensures strict access
control, aligning with ZTNA principles to minimize security risks
while maintaining operational efficiency.
8.2. Using Secure Exposure
The following JSON example illustrates how Secure Exposure policies
can be implemented to control access to network and cloud telemetry
data. The model enforces encryption for all exposed metrics, allows
latency information to be fully available (public), restricts CPU
usage to only selected orchestrators (restricted), and keeps network
topology completely hidden (private).
{
"ztna-policy": {
"enable-ztna": true,
"secure-exposure": {
"encrypt-metrics": true,
"exposed-metric": [
{
"metric-name": "latency",
"exposure-level": "public"
},
{
"metric-name": "cpu-usage",
"exposure-level": "restricted"
},
{
"metric-name": "network-topology",
"exposure-level": "private"
}
]
}
}
}
This implementation ensures that all exchanged network and cloud
metrics are encrypted while allowing latency data to be freely
accessed, CPU usage to be visible only to authorized entities, and
network topology to remain private. Secure Exposure helps reduce the
attack surface, prevents data leaks, and ensures compliance with Zero
Trust security policies by dynamically regulating what is exposed
based on security posture and operational needs.
Dunbar & Chihi Expires 4 September 2025 [Page 12]
Internet-Draft Resource Abstraction March 2025
8.3. Utilizing Continuous Monitoring
Continuous monitoring enables **real-time security assessment,
anomaly detection, and proactive threat mitigation**. It ensures that
network and cloud interactions are continuously observed, logged, and
analyzed to detect unauthorized behavior, policy violations, and
potential security threats. By enforcing continuous monitoring,
network administrators can gain better visibility into security
incidents and automate responses based on predefined policies.
A practical application of continuous monitoring involves setting up
**log event tracking, anomaly detection, and threshold-based
alerts**. For example, a **Cloud Orchestrator** may require
monitoring of specific network resources to detect unauthorized
access attempts, while a **Network Controller** may need to track
unusual spikes in traffic that could indicate a potential
**Distributed Denial of Service (DDoS) attack**.
The following JSON module illustrates how continuous monitoring can
be applied within the ZTNA framework:
Dunbar & Chihi Expires 4 September 2025 [Page 13]
Internet-Draft Resource Abstraction March 2025
{
"ztna-policy": {
"enable-ztna": true,
"continuous-monitoring": {
"enable-monitoring": true,
"log-events": true,
"alert-threshold": 5,
"threat-detection": true,
"monitoring-interval": 60,
"audit-logs": [
{
"log-id": "log-001",
"timestamp": "2025-02-27T12:00:00Z",
"source": "cloud-orchestrator",
"severity": "high",
"description": "Unauthorized access attempt detected."
},
{
"log-id": "log-002",
"timestamp": "2025-02-27T12:05:00Z",
"source": "network-controller",
"severity": "critical",
"description": "DDoS attack detected on service endpoint."
}
]
}
}
}
This implementation enables continuous monitoring by activating
**event logging, threshold-based alerts, and anomaly detection**. The
**`enable-monitoring`** flag ensures that monitoring is active, while
**`log-events`** captures security-related activities. The **`alert-
threshold`** parameter sets the number of detected anomalies required
before an alert is triggered, helping to reduce false positives.
**Threat detection** is enabled to monitor unusual activities such as
unauthorized access attempts or traffic anomalies. The
**`monitoring-interval`** specifies the frequency (in seconds) at
which security events are analyzed.
Additionally, the **`audit-logs`** list stores security event
records, including timestamps, event sources, severity levels, and
descriptions. In the example above, one log entry records an
**unauthorized access attempt** detected by the Cloud Orchestrator,
while another logs a **DDoS attack** flagged by the Network
Controller. These logs provide valuable insights for security teams
to **analyze trends, investigate incidents, and take corrective
actions in real time**.
Dunbar & Chihi Expires 4 September 2025 [Page 14]
Internet-Draft Resource Abstraction March 2025
This approach minimizes security risks by continuously validating and
enforcing access controls in network-cloud interactions.
9. Security Considerations
10. IANA Considerations
IANA is requested to register the YANG module namespaces for ietf-
ztna-netcloud under the "YANG Module Names" registry at
https://www.iana.org/assignments/yang-parameters. These namespaces
should be registered as follows:
(Artwork only available as (unknown type): see
https://www.ietf.org/archive/id/draft-dunchihi-neotec-zerotrust-
access-dm-00.html)
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, .
Acknowledgements
The authors would like to thank for following for discussions and
providing input to this document: xxx.
Contributors
Authors' Addresses
Linda Dunbar (editor)
Futurewei
United States of America
Email: ldunbar@futurewei.com
Dunbar & Chihi Expires 4 September 2025 [Page 15]
Internet-Draft Resource Abstraction March 2025
Houda Chihi
InnovCOM Sup'COM
Tunisia
Email: houda.chihi@supcom.tn
Dunbar & Chihi Expires 4 September 2025 [Page 16]