Security Capability Coordination Execution Framework for 5G Core Networks
draft-si-ztcpp-5g-securityframework-00

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-ztcpp-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 ZTCPP 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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

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]