<?xml version="1.0" encoding="US-ASCII"?>
<!-- <?xml version="1.0" encoding="UTF-8"?> -->
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private)
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" category="info" docName="draft-ahn-nmrg-5g-security-i2nsf-framework-02">

<front>
    <title abbrev="A 5G Integrated Security Service System">
    An Integrated Security Service System for 5G Networks using an I2NSF Framework
    </title>

    <author role="editor" initials="Y." surname="Ahn" fullname="Yoseop Ahn">
        <organization abbrev="Sungkyunkwan University">
        Department of Computer Science &amp; Engineering
        </organization>	
		<address>
		    <postal>
			    <extaddr>Sungkyunkwan University</extaddr>
  			    <street>2066 Seobu-Ro, Jangan-Gu</street>
				<city>Suwon</city>
				<region>Gyeonggi-Do</region>
				<code>16419</code>
				<country>Republic of Korea</country>
			</postal>
			<phone>+82 31 299 4106</phone>
		    <email>ahnjs124@skku.edu</email>
			<uri>http://iotlab.skku.edu/people-Ahn-Yoseop.php</uri>
		</address>
    </author>

    <author role="editor" initials="J." surname="Jeong" fullname="Jaehoon Paul Jeong">
        <organization abbrev="Sungkyunkwan University">
        Department of Computer Science &amp; Engineering
        </organization>
        <address>
            <postal>                
                <extaddr>Sungkyunkwan University</extaddr>
                <street>2066 Seobu-Ro, Jangan-Gu</street>
                <city>Suwon</city> <region>Gyeonggi-Do</region>
                <code>16419</code>
                <country>Republic of Korea</country>
            </postal>
            <phone>+82 31 299 4957</phone>
            <facsimile>+82 31 290 7996</facsimile>
            <email>pauljeong@skku.edu</email>
            <uri>http://iotlab.skku.edu/people-jaehoon-jeong.php
         </uri>
        </address>
    </author>

    <author initials="Y." surname="Kim" fullname="Younghan Kim">
        <organization abbrev="Soongsil University">
        School of Electronic Engineering
        </organization>
		<address>
            <postal>
                <extaddr>Soongsil University</extaddr>
                <street>369, Sangdo-ro, Dongjak-gu</street>
                <city>Seoul</city>
                <code>06978</code>
                <country>Republic of Korea</country>
            </postal>
            <phone></phone>
            <email>younghak@ssu.ac.kr</email>
		</address>
    </author>
    
    <date month="June" day="23" year="2026" />

    <area>Network Management</area>
    
    <workgroup>Internet Research Task Force</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on http://www.rfc-editor.org/rfcsearch.html. -->

<keyword>Internet-Draft</keyword>
    <abstract>
        <t>
        This document presents a mobility-aware distributed security framework for 5G edge networks using
        the Interface to Network Security Functions (I2NSF) architecture. The proposed system uses Intent-Based
        Networking (IBN) to allow users or administrators to declare high-level security intents, which are translated
        into network and application policies. Network-level security policies may be enforced through distributed Network Security Functions (NSFs)
        deployed near User Plane Functions (UPFs), while application-level policies may be enforced
        on User Equipment (UE) through distributed IBN Controllers. This architecture is intended to support adaptive,
        context-aware, and distributed policy enforcement in response to dynamic edge conditions and user mobility scenarios
        such as handovers. Closed-loop monitoring and analytics provide feedback for maintaining policy consistency across
        heterogeneous 5G environments.
        </t>
    </abstract>
</front>


<middle>

<section anchor="section:Introduction" title="Introduction">
<t> 
Network softwarization technologies such as Network Functions Virtualization (NFV) <xref target="ETSI-NFV" /> and Software-Defined Networking (SDN) <xref target="RFC7149" />,
together with Intent-Based Networking (IBN) <xref target="RFC9315" />, provide a foundation for automated and adaptive security orchestration in 5G edge environments.
Through IBN, high-level security intents can be translated into network and application policies with reduced manual configuration. 
</t> 

<t>
This document defines a mobility-aware security framework for distributed 5G edge networks using the Interface to Network Security Functions (I2NSF) architecture <xref target="RFC8329" />.
The framework introduces intent-driven policy translation, distributed policy enforcement, and closed-loop monitoring mechanisms for adaptive security management across 5G edge domains.
The proposed architecture considers interaction with 5G core functions such as the Policy Control Function (PCF), Access and Mobility Management Function (AMF), Session Management Function (SMF), and Network Exposure Function (NEF).
</t>

<t>
To support mobility-aware security management, the framework uses distributed Network Security Functions (NSFs) deployed near User Plane Functions (UPFs) in edge environments.
During mobility events such as handovers between gNBs or transitions across UPFs, the framework is designed to support policy continuity through policy synchronization and policy re-application mechanisms. 
This approach provides a basis for context-aware and mobility-aware security orchestration in distributed 5G edge services.
</t>
</section>



<section anchor="section:Terminology" title="Terminology">
    <t> 
    This section provides definitions of the key terms and concepts used throughout this document.
    The terminology is intended to establish a common understanding of the architectural elements,
    interfaces, and operational principles discussed in the context of intent-based security management
    in 5G networks. These terms are used to describe 5G network automation based on the Intent-Based
    Networking (IBN) and Interface to Network Security Functions (I2NSF) framework.
    </t>

    <t>
    <list style="symbols">

      <t>
        Intent: A set of operational objectives and expected outcomes that a network is expected to fulfill,
        expressed in a declarative manner that focuses on desired outcomes rather than implementation details
        <xref target="RFC9315" />. The data model and transport mechanism used to exchange an intent can be
        selected according to the requirements of each deployment.
      </t>
      <t>
        I2NSF User Function (IUF): A functional component representing the I2NSF user role described in
        <xref target="RFC8329" />. It provides an interface through which an administrator or application
        expresses high-level security intents and submits them to the Security Control Function (SCF).
      </t>
      <t>
        Security Control Function (SCF): A functional component representing the security-controller role
        of the I2NSF framework <xref target="RFC8329" />. The SCF translates high-level security intents
        into security policies and coordinates delivery of the resulting policies to the relevant NSFs and
        other authorized security enforcement components.
      </t>
      <t>
        Security Data Analytics Function (SDAF): A functional component that collects and analyzes monitoring
        data to evaluate policy-enforcement status and the operation of security services. The SDAF supports
        feedback-driven validation and refinement of security policies within the proposed framework.
      </t>
      <t>
        Network Security Function (NSF): A security enforcement component that performs functions such as
        traffic filtering, traffic blocking, and access control according to policies delivered by the SCF
        <xref target="RFC8329" />.
      </t>
      <t>
        Policy Context: A set of policy rules, policy identifiers, policy versions, UE or session identifiers, target enforcement information,
        and enforcement state used to apply a security policy consistently across distributed 5G edge environments.
      </t>
      <t>
        Policy Migration: A procedure by which the SCF transfers, synchronizes, or re-instantiates an active policy context from a source
        edge enforcement point to a target edge enforcement point during a mobility event such as UE handover.
      </t>
      <t>
        Standby NSF: An NSF instance that is deployed at a target edge site but remains inactive for a specific UE until the corresponding
        policy context is migrated and the target enforcement point is selected for service continuity.
      </t>
      <t>
        N2-Based Handover: An inter-NG-RAN node handover in which the handover procedure is coordinated through the 5G Core over the N2 interface,
        as specified in 3GPP TS 23.502 <xref target="TS-23.502" />.
      </t>
      <t>
        Target Enforcement Point: The target NSF, and its associated target UPF or edge site, that enforces the migrated policy context after
        the user-plane path is switched during handover.
      </t>
      <t>
        Mobility and Session Context: Information used by the proposed framework to associate a mobility event
        with a UE or PDU session and a selected target UPF. This context carries the identifiers and target
        user-plane information required to coordinate policy continuity during handover.
      </t>
      <t>
        Policy-Ready Indication: A coordination signal indicating that the target NSF has installed and activated
        the applicable policy context. The signal communicates target-enforcement readiness to the relevant
        security-orchestration and mobility-coordination components.
      </t>
      <t>
        IBN Controller: A device-side component that receives application-level policies, performs localized
        policy enforcement, and generates monitoring reports for adaptive security management. The IBN Controller
        participates in the distributed policy-enforcement and feedback loop of the proposed framework.
      </t>

    </list>
    </t>

</section>


<section title="An I2NSF-Based Architecture for 5G Edge Security Management">
    <t>
    This section defines an architectural framework for 5G security management automation by introducing
    its essential components and explaining how each of them is designed to interconnect with functions
    in the 5G core networks <xref target="TS-23.501" />. The framework is grounded in intent-based networking principles,
    which enable high-level user or application intents to be automatically translated into actionable policies.
    These policies can then be enforced and monitored across both the core and edge domains with reduced
    manual intervention.
    </t>

    <t>
    As 5G networks become more distributed and support a growing number of latency-sensitive services and heterogeneous devices,
    traditional static security mechanisms may be difficult to operate at the scale and pace required by dynamic edge environments.
    Manual configuration may also become difficult to scale, motivating the use of automated security orchestration to support
    consistent policy application, shorter response times, and reduced configuration error.
    </t>
    
    <t>
    To realize this, the framework leverages a set of I2NSF-based functional modules that
    collectively support policy translation, enforcement, and continuous monitoring. By integrating these components
    into the 5G architecture, the system is intended to support scalable, adaptive, and context-aware security operations
    tailored to the needs of dynamic and heterogeneous edge environments.
    </t>

      <figure anchor="figure:5G-Edge-Security-Management-Automation" align="center"
          title="Mobility-Aware I2NSF-Based Security Framework for Distributed 5G Edge Networks">
          <artwork align="left"><![CDATA[
+------------------------------------+ +--------------------+
| 5G Core NFs                        | |                    |
| +-----+  +-----+  +-----+  +-----+ | | +-----+  +-----+   |
| |NSSF |  | UDM |  | NRF |  | PCF | | | | IUF |  | SDAF|   |
| +---+-+  +---+-+  +---+-+  +---+-+ | | +--+--+  +--+--+   |
|     |        |        |        |   | |    |        |      |
| --+-+------+-+------+-+---+--+-+---+-+----+---+----+----- |
|   |        |        |        |     | |        |           |
| +-+---+  +-+---+  +-+---+  +-+---+ | |     +-----+        |
| | AUSF|  | AMF |  | SMF |  | NEF | | |     | SCF |        |
| +-----+  +-+-+-+  +--+--+  +-----+ | |     +-----+        |
|            | |       |             | |   Intent-Based     |
|      +-----+ +--+    +------+      | | Security Services  |
+------+----------+-----------+------+ +--------------------+
       |          |           |                         
    +--+--+   +---+---+    +--+---+   +--+---+   +--------------+
    | UE  +---+ (R)AN +----+ UPFs +---+ NSFs +---+ Data Network |
    +-----+   +-------+    +--+---+   +------+   +--------------+
]]></artwork>
      </figure>


<t>
<xref target="figure:5G-Edge-Security-Management-Automation" /> illustrates a mobility-aware distributed security architecture for 5G edge networks based on the I2NSF framework <xref target="RFC8329" />. An intent-based management strategy
is used between the 5G Core network and distributed edge domains to support automated configuration and security enforcement
across heterogeneous edge environments.
</t>

<t>
On the right side of the architecture, the Intent-Based Security Services represent functional modules responsible for generating, translating, monitoring, and orchestrating security intents and policies. 
These functions support distributed security management across 5G edge environments. They also serve as the interface between external users or applications and the intent-based security system.
These services are composed of several key modules, including the I2NSF User Function (IUF), the Security Control Function (SCF), and the Security Data Analytics Function (SDAF),
which collectively support intent interpretation, policy translation, distributed enforcement, and monitoring across the network.
</t>

<t>
The security intent generated by the IUF is first interpreted as a high-level objective reflecting
the desired behavior of the network or specific applications. This intent is then processed by the Security Control Function (SCF),
which includes a Security Policy Translator responsible for translating abstract intents into concrete security policies. 
Through this translation process, the SCF generates both network-level policies and application-level policies for distributed security enforcement across 5G edge environments.
</t>

<t>
Once these policies are generated, authorized 5G capabilities may be accessed through the Network Exposure Function (NEF), where applicable.
The NEF provides exposure of selected 5G Core capabilities to external application functions according to 3GPP-defined procedures.
When coordination with the 5G Core is required, the framework uses authorized 5G Core capabilities exposed through the NEF.
To support flexible deployment and orchestration, the I2NSF components can be implemented as containerized microservices and managed using Kubernetes<xref target="Kubernetes" />.
</t>

<t>
The AMF, SMF, PCF, and other 5G Core functions retain their 3GPP-defined responsibilities, while I2NSF NSFs perform
network-level security enforcement near or in the traffic path of distributed UPFs. Applicable 5G Core configuration is
performed through the corresponding 3GPP interfaces and service operations. This functional separation combines standardized
5G Core control with localized security enforcement and mobility-aware policy adaptation.
</t>

<t>
For mobility support, the SCF maintains or retrieves policy contexts associated with UEs, PDU sessions, application flows, and target edge domains.
The SCF obtains mobility and target-UPF context through the NEF and the relevant 5G Core capability-exposure mechanisms. The information can be
derived from mobility context associated with AMF procedures and from PDU-session and selected target-UPF context maintained by the SMF. The
exposure layer aggregates this context and provides it to the SCF for policy-continuity coordination. In this deployment model, an edge server can
host a UPF and one or more NSFs, while another edge server can host a target UPF with a standby NSF. The target NSF is prepared during handover
preparation so that the applicable security policy is available when the user-plane path is switched.
</t>

</section>



<section title="The Procedure for I2NSF-Based 5G Edge Security Management">
<t>
This section describes a use case where high-level user intents are automatically translated into enforceable network and application policies.
Leveraging the I2NSF (Interface to Network Security Functions) framework <xref target="RFC8329" /> within a 5G Core environment,
this architecture supports automated, intent-driven security management and can reduce reliance on manual configuration and static rule sets.
</t>

<t>
The system is designed to support distributed policy enforcement by integrating key I2NSF components such as the IUF, Security Control Function (SCF), and Security Data Analytics Function (SDAF).
These components work collaboratively to process intents, generate appropriate policies, and enforce them dynamically across both the core network and the edge.
</t>

<section title="Policy Generation and Delivery for 5G Edge Security Management">

    <figure anchor="figure:Intent-Based-Policy-Generation-and-Delivery"
     title="Policy Generation and Delivery for 5G Edge Networks">
            <artwork><![CDATA[
                 +----------------------+
                 | User Equipment       |
                 | IBN Controller       |
                 +----------^-----------+
                            | Application Policy
+-----+       +-------------+-------------+
| IUF |------>| Security Control Function |
+-----+Intent | (SCF / Policy Translator) |
              +------+----------------+---+
                     |                :
      Network Policy |                : 5GC Capability
                     v                : Exposure through NEF
              +-------------+         v
              | Edge NSF /  |      +-----+
              | Edge Router |      | NEF |
              +-------------+      +-----+
]]></artwork>
    </figure>



<t>
<xref target="figure:Intent-Based-Policy-Generation-and-Delivery" /> shows the procedure for automated 5G edge security management,
including the creation of user intents and the generation of corresponding network and application policies. The process begins when a user
or administrator expresses a security-related intent through the IUF. The intent is passed to the Security Control Function (SCF), whose
Security Policy Translator converts the high-level intent into network-level and application-level policies. Network-level policies are
delivered to the relevant edge NSF or security component, while application-level policies are delivered to the target UE. When policy
processing requires 5G Core capabilities, the SCF coordinates with the 5G Core through the NEF and the corresponding authorized service operations.
</t>

    <figure anchor="figure:5G-security-management-automation-framework-procedure"
     title="The Procedure within an I2NSF-Based Framework for 5G Edge Security Management">
            <artwork><![CDATA[   
           User Equipment 1 (SmartPhone)  User Equipment 2 (IoT Device)   
              +---------------------+        +---------------------+
              | +-----------------+ |        | +-----------------+ |
              | |Service Functions| |        | |Service Functions| |
              | |      (SFs)      | |        | |      (SFs)      | |
              | +-----------------+ |        | +-----------------+ |
              |          ^ |        |        |          ^ |        |
              |Monitoring| |  API   |        |Monitoring| |  API   |
              |   Data   | |Command |        |   Data   | |Command |
              |          | V        |        |          | V        |
              |   +--------------+  |        |   +--------------+  |
              |   |IBN Controller|  |        |   |IBN Controller|  |
              |   +--------------+  |        |   +--------------+  |
              |          ^  |       |        |        ^       |    |
              +----------+--+-------+        +--------+-------+----+
                         |  |                         |       | 
                         |  +---------------------------------+
                         |                            |       |   
                         +--------------+-----+-------+----+  +
                   Application Policy   |     |            |  |
                    (Configuration)     |     |            |  |
                                        |     |            |  |
            +---------------------------+-----+-----+      |  |
            |                           |     |     |      |  |
+--------+  |   +------+   +-----+   +--+--+  |     |      |  |
|  Data  +--|---+ NSFs +---+ UPF +---+ gNB |  |     |      |  |
| Network|  |   +------+   +--+--+   +--+--+  |     |      |  |
+--------+  |                 |         |     |     |      |  |
            |              +--+--+   +--+--+  |     |      |  |
            |              | SMF |   | AMF +--+     |      |  |
            |              +--+--+   +--+--+        |    +-+--+---+
            |                 |         |           |    |  Edge  |
            |         --------+----+----+----+---   |    | Router +---+
            |                      |         |      |    +---+----+   | 
            |                   +--+--+   +--+--+   |        |        |
            |                   | SCF |   | NEF |<--+--------+        |
            |                   +--+--+   +--+--+   | Network         |
            |                                       | Policy          |
            |                                       | (Firewall       |
            +---------------------------------------+ & Web Filter)   |
                  5G Core Network and I2NSF Security Services    |
                                                           Monitoring |
                                                             Report   |
                                                                      V
                                                        +-------------------+
                                                        |   Security Data   |
                                                        | Analytics Function|
                                                        +---------+---------+
                                                                  |
                                                  +---------------+---------+
                                                  | Monitoring Data Storage |
                                                  +-------------------------+  
]]></artwork>
   </figure>

    <t>
    <xref target="figure:5G-security-management-automation-framework-procedure" /> illustrates how intent-driven network policies
    and application policies are applied across distributed edge environments and user equipment. Network-level policies are delivered to
    the relevant NSFs and edge security components, where they are enforced in the user-plane traffic path. Where interaction with the 5G
    Core is required, an implementation may map the policy to authorized 5G Core configuration or service operations through
    authorized integration mechanisms consistent with the 5GS architecture <xref target="TS-23.501" />. At the same time,
    application-level policies are delivered to user devices, such as smartphones and IoT nodes, whose embedded controllers interpret and
    enforce the received policies locally. These distributed controllers enable localized and mobility-aware policy enforcement at the device edge.
    Figure 3 presents a logical service-flow view in which the SCF coordinates policy delivery with the NEF, distributed NSFs,
    edge security components, and device-side IBN Controllers.
    </t>

    <t>
    This allows each device to adjust its behavior according to the defined security or operational requirements. 
    In parallel, network-based security functions can apply controls such as access restrictions or traffic filtering,
    helping align device-side and network-side enforcement with the original intent. 
    This distributed approach supports flexible and adaptive policy enforcement across the mobile network environment.
    Distributed NSFs deployed near UPFs further support localized security enforcement and policy adaptation during mobility events in edge environments.
    </t>

    <t>
    To support adaptive security validation, each user equipment's IBN Controller periodically generates monitoring reports based on local
    policy enforcement status. These reports are sent to the Security Data Analytics Function (SDAF), which analyzes the monitoring data to
    evaluate whether the applied policies are effectively enforced. All collected data is stored in a centralized Monitoring Data Storage module,
    supporting ongoing policy validation and historical auditing. The operational workflow is summarized as follows:

    <list style="symbols">
        <t>
        Intent submission and policy translation: An intent is delivered from an application or user service
        to the Security Control Function (SCF), where the Security Policy Translator converts the high-level
        intent into network-level and application-level policies.
        </t>

        <t>
        Network-policy delivery: The network policy is delivered to the relevant NSFs and edge security
        components for enforcement. Where interaction with the 5G Core is required, the corresponding
        configuration or service operation is coordinated through authorized 5G Core capability exposure.
        </t>

        <t>
        Application-policy delivery: The application policy is sent to the IBN Controllers on target user
        devices, enabling automated delivery of policy instructions to the applicable device-side controllers.
        </t>

        <t>
        Local policy enforcement: Each device applies the policy to adjust its settings and behavior so that
        local operation reflects the system-wide intent.
        </t>

        <t>
        Device monitoring: Devices monitor their status and send relevant data back to their IBN Controllers,
        providing continued visibility into policy impact at the device level.
        </t>

        <t>
        Monitoring-report generation: The IBN Controllers compile and forward the data as monitoring reports,
        which provide a basis for evaluating the effectiveness of the applied policies.
        </t>

        <t>
        Analytics and storage: The reports are analyzed to determine whether the policies are operating as
        intended, and the results are stored for future use. This completes the feedback loop that supports
        adaptive policy refinement.
        </t>
    </list>
    </t>

    <t>
    Through this process, the system supports intent-driven security management across core network
    functions and user devices. By translating high-level intents into policies and monitoring their effects,
    the architecture can support ongoing adaptation to network conditions and user behavior.
    This feedback is intended to help maintain consistent and context-aware policy enforcement across distributed edge environments.
    Moreover, the closed-loop structure provides a foundation for scalable and feedback-driven
    policy management in distributed 5G edge networks.
    </t>

</section>

<section title="Policy Migration and NSF Activation during an N2-Based UE Handover">
    <t>
    This section describes a policy-continuity procedure that combines an inter-NG-RAN node N2-based handover with
    I2NSF policy migration and target-NSF activation. <xref target="figure:N2-Handover-Preparation-Target-UPF" />,
    <xref target="figure:Proposed-I2NSF-Policy-Migration" />, and
    <xref target="figure:N2-Handover-Execution-Path-Update" /> form one continuous operational flow. Figures 4 and 6
    illustrate the handover preparation and execution stages based on 3GPP TS 23.502 <xref target="TS-23.502" />, while
    Figure 5 introduces the I2NSF functions performed between target user-plane preparation and user-plane path switching.
    Together, these stages prepare the target user-plane path, migrate and activate the applicable policy context at the target NSF,
    and complete the UE handover while maintaining policy continuity.
    </t>

    <t>
    In this procedure, the source and target NG-RAN nodes are served by the same AMF, and one PDU session is handed over.
    The target UPF is associated with a target NSF that receives and activates the migrated policy context. When the same UPF
    and NSF remain in use after the handover, the SCF verifies or updates the existing policy binding and maintains the active
    policy context at the current enforcement point.
    </t>

    <t>
    The integrated procedure proceeds as follows:
    <list style="numbers">
        <t>
        The source NG-RAN initiates the handover by sending Handover Required to the AMF.
        </t>
        <t>
        The AMF and SMF prepare the target NG-RAN, target UPF, and target user-plane path.
        </t>
        <t>
        The NEF provides the mobility and session context to the SCF.
        </t>
        <t>
        The SCF migrates the active policy context and activates the target NSF.
        </t>
        <t>
        The UE accesses the target NG-RAN after receiving the Handover Command.
        </t>
        <t>
        The AMF and SMF switch the user-plane path to the target UPF, and the SCF removes the source policy
        context after policy continuity is verified.
        </t>
    </list>
    </t>

    <t>
    <xref target="figure:N2-Handover-Preparation-Target-UPF" /> shows the handover-preparation stage based on the inter-NG-RAN
    node N2-based handover procedure in 3GPP TS 23.502, Clause 4.9.1.3.2 <xref target="TS-23.502" />. This stage determines
    the target NG-RAN and target user-plane context that are used by the subsequent I2NSF policy-migration procedure.
    </t>

    <figure anchor="figure:N2-Handover-Preparation-Target-UPF"
     title="3GPP N2-Based Handover Preparation and Target UPF Selection">
            <artwork><![CDATA[
   S-NG-RAN       AMF          SMF       T-UPF      T-NG-RAN
       |           |            |          |           |
       | Handover Decision      |          |           |
       | Handover Required      |          |           |
       |---------->|            |          |           |
       |           |            |          |           |
       |           | PDU Session Update Request        |
       |           |----------->|          |           |
       |           |            | Target User-Plane    |
       |           |            | Selection and Preparation
       |           |            |--------->|           |
       |           |            |<---------|           |
       |           |            |          |           |
       |           | PDU Session Update Response       |
       |           |<-----------|          |           |
       |           |    Handover Request   |           |
       |           |---------------------------------->|
       |           |    Handover Request Acknowledge   |
       |           |<----------------------------------|
]]></artwork>
    </figure>

    <t>
    The source NG-RAN sends Handover Required to the AMF after making the handover decision. The AMF requests the SMF to
    update the PDU-session context, and the SMF selects or confirms the target UPF and prepares the target user-plane path.
    The AMF then requests handover resources from the target NG-RAN and receives the Handover Request Acknowledge. At this
    point, the target UPF and target NG-RAN are available for the policy-migration and handover-execution stages.
    </t>

    <t>
    The security orchestration system uses the selected target UPF to determine the corresponding edge site and target NSF.
    This mapping allows the SCF to select the target enforcement point and coordinate migration of the active policy context
    from the source NSF when the enforcement point changes.
    </t>

    <t>
    <xref target="figure:Proposed-I2NSF-Policy-Migration" /> shows the policy-migration stage between target user-plane
    preparation and user-plane path switching. The objective of this stage is to make the target NSF policy-ready before
    UE traffic begins to traverse the target UPF.
    </t>

    <figure anchor="figure:Proposed-I2NSF-Policy-Migration"
     title="I2NSF Policy Migration and Target NSF Activation">
            <artwork><![CDATA[
       NEF             SCF          S-UPF+NSF1              T-UPF+NSF2
        |               |                |                       |
        | Mobility and Session Context   |                       |
        | (UE, PDU session, target UPF)  |                       |
        | I2NSF Context Exposure         |                       |
        |-------------->|                |                       |
        |               | Active Policy Context Request          |
        |               |--------------->|                       |
        |               | Active Policy Context Response         |
        |               |<---------------|                       |
        |             Policy Migration and Target NSF Activation |
        |               |--------------------------------------->|
        |               |    Target NSF Activation Response      |
        |               |<---------------------------------------|
        | Policy-Ready Indication        |                       |
        |<--------------|                |                       |
]]></artwork>
    </figure>

    <t>
    The NEF provides the SCF with mobility and session context containing the UE or PDU-session identifier and the selected
    target UPF. Using this information, the SCF identifies the source enforcement point and the NSF associated with the target
    UPF. The SCF sends an Active Policy Context Request to the source NSF associated with the source UPF and receives the
    currently enforced policy context, including the applicable policy rules, identifiers, versions, UE or session bindings,
    and enforcement state.
    </t>

    <t>
    The SCF then transfers or re-instantiates the policy context at the target NSF associated with the target UPF. The target
    NSF installs the policy, associates it with the target user-plane context, and activates the required security functions.
    The Target NSF Activation Response confirms that the target enforcement point is ready. The SCF then provides a Policy-Ready
    Indication through the NEF to report target-enforcement readiness. The resulting policy-ready state ensures that the
    applicable security policy is available when UE traffic begins to traverse the target user-plane path.
    </t>

    <t>
    <xref target="figure:N2-Handover-Execution-Path-Update" /> shows the handover-execution and path-update stage based on
    3GPP TS 23.502, Clause 4.9.1.3.3 <xref target="TS-23.502" />. This stage moves the UE to the target NG-RAN and switches
    the PDU-session user-plane path to the prepared target UPF.
    </t>

    <figure anchor="figure:N2-Handover-Execution-Path-Update"
     title="3GPP N2-Based Handover Execution and User-Plane Path Switch">
            <artwork><![CDATA[
   UE       S-NG-RAN      T-NG-RAN        AMF           SMF          T-UPF
    |           |             |             |             |             |
    |           | Handover Command          |             |             |
    |           |<--------------------------|             |             |
    | Handover Command        |             |             |             |
    |<----------|             |             |             |             |
    |           | Uplink RAN Status Transfer|             |             |
    |           |-------------------------->|             |             |
    |           |             | Downlink RAN Status       |             |
    |           |             | Transfer    |             |             |
    |           |             |<------------|             |             |
    | [Target-Cell Synchronization]         |             |             |
    | Handover Confirm        |             |             |             |
    |------------------------>|             |             |             |
    |           |             | Handover Notify           |             |
    |           |             |------------>|             |             |
    |           |             |             | PDU Session Context       |
    |           |             |             | Update      |             |
    |           |             |             |------------>|             |
    |           |             |             |             | User-Plane  |
    |           |             |             |             | Path Update |
    |           |             |             |             |------------>|
    |           |             |  [Target User-Plane Path Establishment] |
]]></artwork>
    </figure>

    <t>
    The AMF delivers the Handover Command through the source NG-RAN, and the RAN status is transferred to the target NG-RAN.
    The UE synchronizes with the target cell and sends Handover Confirm. The target NG-RAN then sends Handover Notify to the
    AMF. In response, the AMF and SMF update the PDU-session context and switch the user-plane path to the target UPF.
    </t>

    <t>
    Because the target NSF has already installed and activated the migrated policy context, traffic forwarded through the
    target UPF is subject to the same security policy that was enforced on the source path. The source policy context remains
    available until the target enforcement state is confirmed, after which the SCF can remove the source-side policy context.
    This ordering maintains policy continuity across handover preparation, policy migration, UE movement, and user-plane
    path switching.
    </t>
</section>

</section>


<section title="Security Considerations">
  <t>
  In the context of intent-based edge security management in 5G networks, several important security aspects
  must be considered to ensure robust and trustworthy system behavior. One key concern involves the potential for malicious manipulation 
  of user intents. Since intents are high-level expressions of user goals that drive the automated generation of network and application policies, any unauthorized
  alteration could lead to unintended or insecure outcomes. Ensuring that each intent originates from a trusted source
  and is protected by integrity validation mechanisms is therefore essential.
  </t>

  <t>
  Another important consideration is the accuracy and reliability of the policy translation and enforcement process.
  When translating abstract intents into concrete policies, the system must preserve the user's original intent while
  maintaining consistent and validated configurations. Implementations should incorporate validation checks, authorization
  controls, and feedback mechanisms to ensure that policies are correctly interpreted and consistently enforced.
  </t>


  <t>
  Additional security considerations arise in distributed edge environments where
  policies and related security contexts are dynamically migrated across distributed
  enforcement points during mobility events. Ensuring policy consistency and secure
  synchronization between distributed NSFs is important for maintaining continuous
  security enforcement during handovers.
  </t>

  <t>
  For mobility-aware policy migration, the SCF and distributed NSFs need to protect migrated policy contexts against
  unauthorized modification, replay, and disclosure. A migrated policy context should be bound to explicit identifiers
  such as the UE, PDU session, target UPF, policy identifier, policy version, and validity period. The activation of the
  target NSF should be acknowledged before the source policy context is removed or deactivated, in order to avoid a temporary
  gap in policy enforcement during handover. Implementations should also log migration events and activation results so that
  the SDAF can verify policy continuity and detect inconsistent or failed migrations.
  </t>

  <t>
  The implementation applies an explicit continuity policy when target-NSF activation extends beyond the available handover-preparation interval. Available actions include retaining enforcement at a reachable source or central NSF, postponing the policy
  cutover, or applying a fail-closed rule for protected traffic. The I2NSF security-orchestration layer applies the selected behavior
  in coordination with the ongoing handover procedure.
  </t>
  
</section>




<section title="Conclusion"> 

<t> 
This document presented a mobility-aware distributed security framework for 5G edge networks based on the I2NSF architecture and Intent-Based Networking.
The handover example combines the preparation and execution stages of an N2-based handover with the proposed I2NSF policy-migration and NSF-activation operations.
The framework is designed to support adaptive policy translation, distributed security enforcement, and policy continuity during mobility events through distributed NSFs and edge-aware orchestration mechanisms.
Closed-loop monitoring and mobility-aware policy management provide a basis for scalable and resilient security orchestration in future 5G edge environments. 
</t> 

</section>





<section anchor="section:IANA-Considerations" title="IANA Considerations">
  <t>
    This document has no IANA actions.
  </t>
</section>


</middle>


<back>

<!-- START: Normative References -->
<references title="Normative References">

    <?rfc include="reference.RFC.8329"?>
    <?rfc include="reference.RFC.9315"?>

    <reference anchor="TS-23.502">
        <front>
            <title>Procedures for the 5G System (5GS)</title>
            <author>
                <organization>3GPP</organization>
            </author>
            <date month="March" year="2026" />
        </front>
        <seriesInfo name="3GPP TS" value="23.502 V18.13.0" />
        <seriesInfo name="Available:" value="https://www.3gpp.org/dynareport/23502.htm" />
    </reference>

</references>
<!-- END: Normative References -->


<!-- START: Informative References -->
<references title="Informative References">

    <?rfc include="reference.RFC.7149"?>

    <reference anchor="TS-23.501">
        <front>
            <title>System Architecture for the 5G System (5GS)</title>
            <author>
                <organization>3GPP</organization>
            </author>
            <date month="January" year="2026" />
        </front>
        <seriesInfo name="3GPP TS" value="23.501 V18.12.0" />
        <seriesInfo name="Available:" value="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144" />
    </reference>

    <reference anchor="ETSI-NFV">
        <front>
            <title>Network Functions Virtualisation (NFV); Architectural Framework</title>
            <author>
                <organization>ETSI</organization>
            </author>
            <date month="December" year="2014" />
        </front>
        <seriesInfo name="ETSI GS" value="NFV 002 V1.2.1" />
        <seriesInfo name="Available:" value="https://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf" />
    </reference>

    <reference anchor="Kubernetes">
        <front>
            <title>Kubernetes: Cloud Native Computing Platform</title>
            <author>
                <organization>Kubernetes</organization>
            </author>
            <date month="March" year="2024" />
        </front>
        <seriesInfo name="Available:" value="https://kubernetes.io/" />
    </reference>

</references>
<!-- END: Informative References -->


<!-- START: Acknowledgments -->
<section anchor="section:Acknowledgments" numbered="false" title="Acknowledgments">
    <t indent="0" pn="section-appendix.a-1">
    This work was supported by Institute of Information &amp; Communications
    Technology Planning &amp; Evaluation (IITP) grant funded by the Korea
    Ministry of Science and ICT (MSIT) (No. RS-2024-00398199 and
    RS-2022-II221015).
    </t>
</section>
<!-- END: Acknowledgments -->



<!-- START: Contributors -->
<section anchor="section:Contributors" numbered="false" title="Contributors">
    <t indent="0" pn="section-appendix.b-1">
    This document is made by the group effort of NMRG, greatly benefiting 
    from inputs and texts by <contact fullname="Linda Dunbar"/> (Futurewei),
    <contact fullname="Yong-Geun Hong"/> (Daejeon University), and
    <contact fullname="Joo-Sang Youn"/> (Dong-Eui University).
    The authors sincerely appreciate their contributions.
    </t>

    <t indent="0" pn="section-appendix.b-2">  
    The following is the coauthor of this document:
    </t>   
      <contact fullname="Mose Gu">
        <organization showOnFrontPage="true">Department of Computer Science &amp; Engineering</organization>
        <address>
          <postal>
            <extaddr>Sungkyunkwan University</extaddr>
            <street>2066 Seobu-Ro, Jangan-Gu</street>
            <city>Suwon</city>
            <region>Gyeonggi-Do</region>
            <code>16419</code>
            <country>Republic of Korea</country>
          </postal>
          <phone>+82 31 299 4106</phone>
          <email>rna0415@skku.edu</email>
          <uri>http://iotlab.skku.edu/people-Moses-Gu.php</uri>
        </address>
      </contact>    
</section>
<!-- END: Contributors -->

</back>

<!-- <vspace blankLines="100"/> -->
<!-- page break to put addresses onto one page-->

</rfc>
