Intent-Based Network Management in SRv6 network

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 11 January 2024.¶

Copyright Notice

Copyright (c) 2023 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

Interface to Network Security Functions (I2NSF) defines a framework and interfaces for interacting with Network Security Functions (NSFs) [RFC8192][RFC8329]. Note that an NSF is defined as software that provides a set of security-related services, such as (i) detecting unwanted activity, (ii) blocking or mitigating the effect of such unwanted activity in order to fulfill service requirements, and (iii) supporting communication stream integrity and confidentiality [RFC8329]. Th e NSF can be implemented as a Virtual Network Function (VNF) in a Network Functions Virtualization (NFV) environment [ETSI-NFV][I-D.ietf-i2nsf-applicability].¶

The term "intent" is defined as "an abstract, high-level policy used to operate the network" in the context of autonomic networks [RFC7575]. According to this definition, an intent is a specific type of policy provided by a user to provide guidance to the autonomic network that would otherwise operate without human intervention.¶

Intent-Based Networking (IBN) Management (IBNM) aims to lead towards networks that are fundamentally simpler to manage and operate, requiring only minimal outside intervention. The IBNM supports a closed-loop network control architecture that can adapt to the current status of a target network by collecting and analyzing monitoring data from Network Service Functions (NSFs) of I2NSF framework. NSFs can be either Virtual Network Functions (VNFs) or Physical Network Functions (PNFs) in cloud and edge computing environments.¶

Segment Routing (SR) [RFC8402] allows a node to steer a packet flow along any path. The headend (i.e., ingress router) is a node where the instructions for source routing (i.e., segments) are written into the packet. It hence becomes the starting node for a specific segment routing path. Intermediate per-path states are eliminated thanks to source routing. [RFC8754] and [RFC8986] describe the same for Segment Routing over IPv6 (SRv6) with the use of the Segment Routing Header (SRH).¶

Therefore, the instructions for source routing is made by a Segment Routing Policy (SR Policy) [RFC8402]. The SR policy is an ordered list of segments and come from the Intent, which is given by users (i.e., network operators). According to the Intent, IBNM will support several funtionalities.¶

2. Terminology

This document uses the terminology described in [RFC8329], [I-D.ietf-i2nsf-applicability], [I-D.jeong-i2nsf-security-management-automation], and [I-D.jeong-nmrg-ibn-network-management-automation]. In addition, the following terms are defined below:¶

• Autonomous Network Management (ANM): It means that an intent from a user (or administrator or network operator) is well-enforced in a target SRv6 network. The intent can be aligned with high-level network policy and then high-level network policy can be translated into the corresponding low-level network policy (including SRv6 Policy) by a network policy translator and dispatched to appropriate NSFs. Through the monitoring of the NSFs, the activity and performace of the NSFs is monitored and analyzed whether or not NSFs are operating well according to the intent of the users. If needed, the network rules of the low-level network and SRv6 policy are augmented or new network rules are generated and configured to appropriate NSFs.¶
• Network Policy Translation (NPT): It means that a high-level network policy is translated to a low-level network policy (including SRv6 policy) that can be understood and configured by an NSF for autonomous network services, such as self-configuration, self-optimization, self-healing, and self-protection.¶
• Feedback-Based Network Management (FNM): It means that a network service in SRv6 network is evolved by updating a network policy (i.e., a set of network rules) and adding new network rules for resolving network problems, which were detected by monitoring and analzing data from NSFs.¶

   +-------------+                   +-----------------------------+
   |  IBN User   |                   | Global Distributed Database |
   +-------------+                   +-----------------------------+
          ^                                                     ^
          | Consumer-Facing                    Software Update  |
          | Interface                            Interface (Up) |
          v                                                     v
+-------------------+     Registration     +-----------------------+
|   IBN Controller  |<-------------------->|  Vendor's Mgmt System |
+-------------------+      Interface       +-----------------------+
          ^      ^                                            ^
          |      |                  Software Update Interface |
          |      |                                     (Down) |
          |      |   Analytics Interface   +----------------+ |
          |      +------------------------>|  IBN Analyzer  | |
          |                                +----------------+ |
          | NSF-Facing Interface                   ^          |
          |                                        |          |
          |                  +---------------------+          |
          |                  |  Monitoring Interface          |
          |                  |                                |
+---------+------------------+--------------------------------+----+
|         v                  v         SRv6 Nodes             v    |
|  +---------------+  +---------------+         +---------------+  |
|  |     NSF-1     |--|     NSF-2     | ....... |     NSF-n     |  |
|  |(Policy Control|  | (Monitoring   |         | (Application  |  |
|  | Function, PCF)|  |  Function, MF)|         | Function, AF) |  |
|  +---------------+  +---------------+         +---------------+  |
+------------------------------------------------------------------+

3. Intent based Network Management in SRv6 Network

This section describes an IBNM framework in SRv6 network. Note that this IBNM Framework is based on the Framework for Interface to Network Security Functions (I2NSF) [RFC8329][I-D.jeong-i2nsf-security-management-automation]. As shown in Figure 1, an IBN User can use network functions by delivering high-level network intents, which specify network requirements that the IBNM User wants to enforce, to the IBN Controller via the Consumer-Facing Interface (CFI).¶

4. Network Policy Translation

To facilitate Network Policy Translation (NPT), IBN Controller needs to have a network policy translator that performs the translation of a high-level network policy into the corresponding low-level network policy. For the automatic NPT services, the IBN framework needs to bridge a high-level YANG data model and a low-level YANG data model in an automatic manner [I-D.yang-i2nsf-security-policy-translation]. Note that a high-level YANG data model is for the IBN Consumer-Facing Interface, and a low-level YANG data model is for the IBN NSF-Facing Interface.¶

Figure 2 shows automatic mapping of high-level and low-level data models for network policies. Automatic Data Model Mapper takes a high-level YANG data module for the Consumer-Facing Inteface and a low-level YANG data module for the NSF-Facing Interface. It then constructs a mapping table associating the data attributes (or variables) of the high-level YANG data module with the corresponding data attributes (or variables) of the low-level YANG data module. Also, it generates a set of production rules of the grammar for the construction of an XML file of low-level network policy rules.¶

       High-level YANG Data Module   Low-level YANG Data Model
                   |                              |
                   V                              V
         +---------+------------------------------+---------+
         |             Policy Data Model Mapper             |
         +------------------------+-------------------------+
                                  |
               Mapping Model (Data Model Mapping Table)
                                  |
                                  V
         +--------------------------------------------------+
         |               local NSF Database                 |
         +--------------------------------------------------+

5. Network Audit System

The IBN framework is weak to both an insider attack and a supply chain attack since it trusts in NSFs provided by VMS and assumes that NSFs work for their network services appropriately [I-D.ietf-i2nsf-applicability].¶

To detect the malicious activity of either an insider attack by a malicious VMS or a supply chain attack by a compromised VMS, a network audit system is required by the IBN framework. This network audit system can facilitate the non-repudiation of configuration commands and monitoring data generated in the IBN framework.¶

A network audit system has the following four main objectives:¶

• To check the existence of a network policy, a management system, and its procedures;¶
• To identify and understand the existing vulnerabilities and risks of either an insider attack or a supply chain attack;¶
• To review existing network controls on operational and administrative issues;¶
• To provide recommendations and corrective actions to IBN Controller for further network and security improvement.¶

+-----------------------------+                   +----------------+
|           IBN User          |                   |  Vendor's Mgmt |
|                             +------------+      |     System     |
+--------------+--------------+            |      +--------+-------+
               | Consumer-Facing Interface |               |
               |                           |  Remote       |
   High-level Security Policy              |  Attestation  |
               |                           |  Interface    |
               |                           |               |
               V                           |               V
+--------------+--------------+            |     +---------+--------+
|                             |            V     |      Network     |
|        IBN Controller       +------------+---->|       Audit      |
|                             |            ^     |      System      |
+--------------+--------------+            |     +---------+--------+
               |  NSF-Facing Interface     |               ^
               |                           |  Remote       |
   Low-level Security Policy               |  Attestation  |
               |                           |  Interface    |
               V                           |               |
+--------------+--------------+            |      +--------+-------+
|            NSF(s)           +------------+      |  IBN Analyzer  |
|                             +------------------>|                |
+-----------------------------+    Monitoring     +----------------+
                                   Interface

Figure 3 shows activity auditing with a network audit system in the IBN framework. All the components in the IBN framwork report its activities (such as configuration commands and monitoring data) to Network Audit System as transactions through Remote Attestation Interface [I-D.yang-i2nsf-remote-attestation-interface-dm]. The network audit system can analyze the reported activities from the IBN components to detect malicious activities such as an insider attack and a supply chain attack. Note that such a network audit system can be implemented by remote attestation [RFC9334][I-D.yang-i2nsf-remote-attestation-interface-dm] or Blockchain [Bitcoin]. The details of the implementation of the network audit system are out of the scope of this document.¶

In order to determine a minimum set of controls required to reduce the risks from either an insider attack or a supply chain attack, the network audit system should analyze the activities of all the components in the IBN framework periodically, evaluate possible risks, and take an action to such risks since vulnerabilities and threats may change in different environments over time.¶

6. IANA Considerations

This document does not require any IANA actions.¶

7. Security Considerations

The same security considerations for the IBN framework [RFC8329] are applicable to this document.¶

Authors' Addresses