Network Working Group Xuan Internet-Draft China Telecom Intended status: Informational 5 July 2026 Expires: 6 January 2027 Security Capability Coordination Execution Framework for 5G Core Networks draft-si-zt-cpp-5g-securityframework-00 Abstract This document defines a security capability coordination execution framework for 5G core networks. The framework employs a set of Security Coordination Components (SCC) that work collaboratively with core network functions to achieve continuous trust verification and least-privilege access control. It specifies the division of responsibilities between the Network Function Security Agent and the Management Security Controller. This document aims to provide a standardized architecture reference for the ZT-CPP working group. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 6 January 2027. Xuan Expires 6 January 2027 [Page 1] Internet-Draft Security Capability Coordination Executi July 2026 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Background and Motivation . . . . . . . . . . . . . . . . 2 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 4.1. Logical Components . . . . . . . . . . . . . . . . . . . 4 5. Key Technical Elements . . . . . . . . . . . . . . . . . . . 5 5.1. Identity-Based Micro-Segmentation . . . . . . . . . . . . 6 5.2. Local Intrusion Detection and Trust Scoring . . . . . . . 6 5.3. Policy Information Model Overview . . . . . . . . . . . . 7 6. Interfaces and Protocols . . . . . . . . . . . . . . . . . . 7 6.1. Southbound Interface (Policy Provisioning) . . . . . . . 7 6.2. Northbound Interface (Event Reporting) . . . . . . . . . 8 6.3. Asset Data Interface . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 1.1. Background and Motivation The evolution of 5G networks has led to a significant expansion of the attack surface, a surge in east-west traffic, and dynamic scaling of network functions, resulting in blurred trust boundaries. Traditional perimeter-based security models cannot perceive threat behaviors inside network functions and struggle to adapt to rapid changes in virtualized environments. Xuan Expires 6 January 2027 [Page 2] Internet-Draft Security Capability Coordination Executi July 2026 To address these issues, we propose a security capability coordination approach: deploy lightweight security agents near 5G core network functions, achieving zero-trust control and policy enforcement through local monitoring and execution without invading the core network functions themselves. This mode preserves the independence of the core network while providing fine-grained security enhancement. This document defines a zero-trust security enforcement framework for 5G core networks, consisting of two types of attached security coordination components: * Network Function Security Agent (NF-SA): deployed alongside each 5G network function instance, responsible for local monitoring, micro-segmentation enforcement, and asset data collection. * Management Security Controller (MSC): deployed centrally, responsible for policy decision, event correlation, asset management, and component orchestration. 1.2. Scope The security capability coordination execution framework defined in this document applies to 5G core network environments. The framework focuses on the coordination between security components and core network functions and does not involve modifications to the core network functions themselves. 2. Terminology and Definitions The following terms are used in this document: Security Coordination Component (SCC): A set of software modules deployed independently from 5G core network functions but closely collaborating with them to provide security capabilities. Includes NF-SA and MSC. Network Function Security Agent (NF-SA): An independent process running in the same virtual machine or container as a 5G network function (e.g., AMF, SMF, UPF), performing monitoring and enforcement through local operating system interfaces. Management Security Controller (MSC): Can be deployed independently or co-located with the local management system, aggregating data from multiple NF-SAs for global policy decision and event analysis. Xuan Expires 6 January 2027 [Page 3] Internet-Draft Security Capability Coordination Executi July 2026 Micro-Segmentation: Fine-grained access control between network functions, VMs, Pods, and management systems based on identity labels rather than IP addresses alone. Trust Score: A numerical value dynamically computed based on observed security events, reflecting the trustworthiness of a network function or workload, and serving as input to policy decisions. 3. Problem Statement Current security deployments in 5G core networks face the following challenges: * Trust Drift: Static security policies quickly become outdated when VNFs are instantiated, migrated, or scaled, creating blind spots. * Lateral Movement: Once an attacker compromises one network function, they can exploit internal implicit trust relationships to spread laterally across the network. * Insufficient Granularity: IP-based policies cannot distinguish different services within the same Pod, leading to overly permissive rules. * Disjointed Orchestration: The security policy lifecycle is decoupled from the network service lifecycle managed by NFVO/VNFM, making coordination difficult. Security Coordination Components, deployed close to network functions, can sense the state of network functions in real time and adjust policies dynamically, effectively mitigating the above problems. This framework provides a standardized architecture for this solution. 4. Architecture Overview 4.1. Logical Components Figure 1 shows the high-level architecture. Xuan Expires 6 January 2027 [Page 4] Internet-Draft Security Capability Coordination Executi July 2026 +---------------------+ | Upper Security | | Platform (SOC/SIEM)| +----------+----------+ | Northbound Interface | +----------+----------+ | MSC (PDP) | | - Policy Decision | | - Event Correlator | | - Asset Manager | +----------+----------+ | Southbound Interface | +----------+----------+ | NF-SA (PEP/Sensor) | | - Micro-seg. Engine| | - Intrusion Det. | | - Asset Collector | +----------+----------+ | +----------+----------+ | 5G NF Instance | | (AMF/SMF/UPF etc.) | +---------------------+ Figure 1 The NF-SA coexists as a sidecar with the network function instance in the same virtual machine or container. It obtains the runtime status of the network function through operating system interfaces (e.g., eBPF, netlink) and enforces access control policies. There is no direct business coupling between the NF-SA and the network function; they exchange necessary information only through local IPC. The MSC centrally manages all NF-SAs, maintains a network-wide asset view and event correlation, and generates new policy instructions based on preconfigured policies or dynamic trust scores, delivering them via the southbound interface. 5. Key Technical Elements Xuan Expires 6 January 2027 [Page 5] Internet-Draft Security Capability Coordination Executi July 2026 5.1. Identity-Based Micro-Segmentation Traditional micro-segmentation relies on IP five-tuples, which are costly to maintain in dynamic environments. This framework uses identity labels instead of static addresses. Labels include: * VNF name * NF type * Service name * Deployment region * Trust level Policy rules are based on label matching. The NF-SA translates abstract rules into underlying enforcement rules based on the current mapping between IP addresses and labels. The framework supports automatic learning of baseline connectivity patterns: during a learning period, the NF-SA records all normal connections, and the MSC generates whitelist policies accordingly. When business flows and ports change, the MSC synchronously updates security policies and delivers them to the relevant NF-SAs. 5.2. Local Intrusion Detection and Trust Scoring The NF-SA incorporates a lightweight intrusion detection engine that can monitor the following types of events: * Malware: Rootkit, Webshell, Reverse Shell * Intrusion Attempt: Brute force (including seven subtypes: single- target fast, single-target slow, multi-target fast, multi-target slow, password spraying, distributed brute force, slow login attempt), password guessing * Account Anomaly: Unauthorized account creation, unauthorized password change, user privilege escalation, file privilege escalation, process privilege escalation * File Integrity: Shell file tampering, critical file tampering, illegal file download * Kernel Anomaly: Hidden processes/ports, VM escape attempt Xuan Expires 6 January 2027 [Page 6] Internet-Draft Security Capability Coordination Executi July 2026 Each event carries a severity level (info, low, medium, high, critical) and a unique event class identifier. After collecting events, the MSC computes a trust score for each network function using a configurable algorithm. For example, deduct points when a critical event occurs, and slowly recover during event-free periods. The trust score can directly influence policies: when a network function's trust score falls below a threshold, the MSC automatically issues an isolation policy, allowing only management-plane communication. 5.3. Policy Information Model Overview To enable vendor-neutral policy representation, this framework defines a policy information model containing the following core elements: * Policy Identifier: Uniquely identifies a policy. * Subject: The asset object to which the policy applies, specified by asset type or label. * Condition: Conditions under which the policy takes effect, including time range, trust score range, triggering event class, etc. * Action: The action type to be enforced, including allow, deny, alert, isolate, etc. * Target: The target asset on which the action operates, similarly specified by asset type or label. * Priority: The basis for resolving conflicts among multiple policies. * Status: Whether the policy is active or inactive. The detailed data model definition will be provided in a future version of this draft. 6. Interfaces and Protocols 6.1. Southbound Interface (Policy Provisioning) The southbound interface connects the MSC (PDP) to the NF-SA (PEP) for policy configuration, updates, and health checks. The transport layer MUST be secured with TLS or SSH for mutual authentication and encryption. Xuan Expires 6 January 2027 [Page 7] Internet-Draft Security Capability Coordination Executi July 2026 Request data fields include: security event ID, source asset ID, destination asset ID, source address, destination address, source port, destination port, communication protocol (UDP/TCP), service name, policy type (add to whitelist/blacklist). Response data fields include error code and failure detail message. 6.2. Northbound Interface (Event Reporting) The northbound interface exports security events and asset information to an upper security platform. The event format contains fields such as priority, version, timestamp, hostname, app-name, procid, msgid, and message content. The message content contains specific security event fields: event ID, affected asset ID/name/type/IP, affected business asset information, event type, event name, event class, event level, evidence, attack status, occurrence time, first/last occurrence time, source IP/port, attacker IP, destination IP/port, victim IP, username, user group, source asset ID, service name, etc. 6.3. Asset Data Interface The asset data interface is used for asset inventory synchronization between the NF-SA and the MSC. Asset data fields include: region ID, network function ID, network function name, manufacturer ID, VM list (including VM ID, attributes, hostname, network interface information, IP address, broadcast address, description, destination address, MAC address, name, netmask, NIC type, NAT address list, etc.), operating system attributes (distribution version, name, patch level, kernel version), database/middleware/web application attribute list (installation path, component name, component open port, component version, project list, plugin list, etc.). 7. Security Considerations The Security Coordination Components themselves need to be protected: * Sensitive data MUST be encrypted at rest and in transit. * NF-SA and MSC should implement integrity verification and anti- tampering mechanisms. * Resource consumption of NF-SA must be limited to avoid impacting network function performance. * Policy conflicts must be resolved deterministically, with logging. Xuan Expires 6 January 2027 [Page 8] Internet-Draft Security Capability Coordination Executi July 2026 8. IANA Considerations None 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", May 2017, . Author's Address Xuan China Telecom Kangqiao Town, Pudong New District Shanghai 201315 China Email: six1@chinatelecom.cn Xuan Expires 6 January 2027 [Page 9]