KR102753854B1 - I2nsf registration interface yang data model - Google Patents

Abstract

The present specification relates to a method for registering by a Developer's Management System in a security management system that manages a Network Secure Function (NSF) through a Registration Interface, the method comprising: a step of transmitting a first registration request message to a Security Controller through the Registration Interface, based on an NSF provided from an NSF vendor, for requesting registration of the provided NSF; a step of receiving a request message for requesting an additional NSF related to required capabilities through the Registration Interface, if there is no NSF among the NSFs registered from the Security Controller that provides required capabilities based on a security service request from an I2NSF (Interface to Network Security Functions) user; and a step of transmitting, to the Security Controller, a second registration request message for requesting registration of the additional NSF as a response to the request message through the Registration Interface. , and the registration interface may include 1) a first model for registering the capability of the NSF to the security controller, and 2) a second model for requesting the additional NSF to the developer management system.

Description

I2NSF Registration Interface YANG Data Model {I2NSF REGISTRATION INTERFACE YANG DATA MODEL}

This specification is about a data model, and more specifically, it defines an information model for the registration interface between a security controller and a Developer's Management System (DMS) in the Interface to Network Security Functions (I2NSF) and the YANG data model.

Connecting networks around the world allows for rapid access to information regardless of geographical distance. The Internet is essentially a network of interconnected hierarchies at different levels.

The Internet operates under the Transmission Control Protocol/Internet Protocol (TCP/IP) published by the Internet Engineering Task Force (IETF). TCP/IP can be found in Request For Comments (RFC) 703 and RFC 791 published by the IETF.

The purpose of this specification is to propose a method for defining an information model and a YANG data model for a registration interface between a security controller and a Developer's Management System (DMS) in the Interface to Network Security Functions (I2NSF).

Additionally, this specification proposes a method to support NSF function registration and querying via the I2NSF registration interface.

The technical problems to be achieved in this specification are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by a person having ordinary knowledge in the technical field to which this specification belongs from the description below.

One aspect of the present specification is a method for registering by a Developer's Management System in a security management system that manages a Network Secure Function (NSF) through a Registration Interface, the method comprising: transmitting a first registration request message to a Security Controller through the Registration Interface, based on an NSF provided from an NSF vendor, for requesting registration of the provided NSF; receiving a request message for requesting an additional NSF related to required capabilities through the Registration Interface, if there is no NSF among the NSFs registered from the Security Controller that provides required capabilities based on a security service request from an I2NSF (Interface to Network Security Functions) user; and transmitting a second registration request message to the Security Controller through the Registration Interface, for requesting registration of the additional NSF as a response to the request message. , and the registration interface may include 1) a first model for registering the capability of the NSF to the security controller, and 2) a second model for requesting the additional NSF to the developer management system.

In addition, the method may further include: receiving a renewal request message for requesting renewal of the registered NSF capability from the security controller; and transmitting a renewal message as a response to the renewal request message to the security controller through the registration interface.

Additionally, the first model may include 1) an NSF name indicating a unique name of an NSF that can be registered, 2) NSF capability information indicating a set of capabilities of the NSF that can be registered, and 3) NSF access information for the NSF that can be registered to communicate with a network.

Additionally, the NSF capability information may include time capabilities, event capabilities, condition capabilities, action capabilities, resolution strategy capabilities, and basic action capabilities.

Additionally, the NSF capability information may further include performance capability information to indicate the processing capability of the NSF that can be registered.

Additionally, the performance capability information may include 1) an available processing power value and 2) a bandwidth value related to an available network for determining whether the NSF that can be registered is congested.

Additionally, the request message may be based on the required capabilities generated by the security controller using the NSF capability information.

Additionally, the NSF capability information may further include IPsec method capability information for specifying the capability of an Internet Key Exchange (IKE) support method for secure communication with the available network.

Another aspect of the present specification is a security management system for managing a Network Secure Function (NSF) through a Registration Interface, comprising: a transceiver for transmitting and receiving signals; a memory for storing data; And a processor controlling the transceiver and the memory; wherein the processor transmits, through the transceiver, a first registration request message to a Security Controller through the registration interface, based on an NSF provided from an NSF vendor, to request registration of the provided NSF, and, based on a security service request of an I2NSF (Interface to Network Security Functions) user, if there is no NSF providing required capabilities among the registered NSFs from the Security Controller, receives a request message to request an additional NSF related to the required capabilities through the registration interface, and transmits, to the Security Controller, a second registration request message to request registration of the additional NSF as a response to the request message through the registration interface, wherein the registration interface may include 1) a first model for registering the capabilities of the NSF in the Security Controller and 2) a second model for requesting the additional NSF to the developer management system.

This specification defines an information model and a YANG data model for the registration interface between a security controller and a Developer's Management System (DMS) in the Interface to Network Security Functions (I2NSF).

Additionally, this specification may support NSF function registration and querying via the I2NSF registration interface.

The effects that can be obtained from this specification are not limited to the effects mentioned above, and other effects that are not mentioned will be clearly understood by those skilled in the art to which this specification belongs from the description below.

The accompanying drawings, which are incorporated in and are intended to provide an aid to the understanding of the present specification and which constitute a part of the detailed description, illustrate embodiments of the present specification and, together with the detailed description, serve to explain the technical features of the present specification.
FIG. 1 illustrates an Interface to Network Security Functions (I2NSF) system according to one embodiment of the present specification.
FIG. 2 illustrates the architecture of an I2NSF system according to one embodiment of the present specification.
Figure 3 is an example of an I2NSF Registration Interface Information Model to which this specification can be applied.
Figure 4 is an example of an NSF Capability Registration Sub-Model to which this specification can be applied.
Figure 5 is an example of NSF Capability Information to which this specification can be applied.
FIG. 6 illustrates the capabilities of NSF in the I2NSF Framework according to one embodiment of the present specification.
FIG. 7 illustrates a two-data model structure for NSF capabilities according to one embodiment of the present specification.
Figure 8 is an example of Performance Capability to which this specification can be applied.
Figure 9 is an example of a YANG Tree of NSF Capability Registration Module to which this specification can be applied.
Figure 10 is an example of a YANG Tree of NSF Capability Query Module to which the present specification can be applied.
Figure 11 is an example of a YANG Tree of I2NSF NSF Capability Information to which the present specification can be applied.
Figure 12 is an example of a YANG Tree of I2NSF NSF Performance Capability to which this specification can be applied.
Figure 13 is an example of a YANG Tree of I2NSF NSF Access Informantion to which the present specification can be applied.
Figure 14 is an example of the Registration Interface YANG Data Model to which this specification can be applied.
Figure 15 is an example of an embodiment to which this specification can be applied.

Hereinafter, preferred embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. The detailed description set forth below together with the accompanying drawings is intended to explain exemplary embodiments of the present disclosure and is not intended to represent the only embodiments in which the present disclosure may be practiced. The following detailed description includes specific details in order to provide a thorough understanding of the present disclosure. However, one of ordinary skill in the art will appreciate that the present disclosure may be practiced without these specific details.

In some cases, to avoid ambiguity in the concepts of this specification, well-known structures and devices may be omitted or illustrated in block diagram format focusing on the core capabilities of each structure and device.

Certain terms used in the following description are provided to aid in understanding this specification, and the use of such specific terms may be changed to other forms without departing from the technical spirit of this specification.

Recently, a basic standard interface for NFV-based security functions is being developed by the Interface to Network Security Functions (I2NSF) working group, which is part of the international Internet standards body called the Internet Engineering Task Force (IETF).

The purpose of I2NSF is to define a standardized interface for heterogeneous network security functions (NSFs) provided by multiple security solution vendors.

In the I2NSF architecture, users can define security policies to protect network resources within their network systems without having to consider the management of NSFs in detail (NSF management ultimately requires enforcement of security policies). In addition, standardized interfaces from multiple vendors to NSFs can simplify the configuration and management of tasks for heterogeneous NSFs.

FIG. 1 illustrates an Interface to Network Security Functions (I2NSF) system according to one embodiment of the present specification.

Referring to FIG. 1, the I2NSF system includes an I2NSF user, a Network Operator Management System, a Developer's Management System, and/or at least one Network Security Function (NSF).

I2NSF users communicate with the network operations management system through the I2NSF Consumer-Facing Interface. The network operations management system communicates with the NSF(s) through the I2NSF NSF-Facing Interface. The developer management system communicates with the network operations management system through the I2NSF Registration Interface. The following describes each component (I2NSF component) and each interface (I2NSF interface) of the I2NSF system.

I2NSF users

An I2NSF user is an I2NSF component that requests information from another I2NSF component (e.g., a network operations management system) and/or uses services (e.g., network security services) provided by another I2NSF component (e.g., a developer management system). For example, an I2NSF user may be an overlay network management system, an enterprise network management system, another network domain manager, etc.

An entity that performs a role assigned to such an I2NSF user component may be referred to as an I2NSF consumer. Examples of I2NSF consumers may include a video-conference network manager that needs to dynamically notify the underlay network to allow, rate-limit, or deny a flow based on specific fields in the packet for a time span, enterprise network administrators and management systems that need to request the provider network to enforce specific I2NSF policies on specific flows, and an IoT management system that sends a request to the underlay network to block flows that match a specific set of conditions.

I2NSF users can create and distribute high-level security policies. Specifically, I2NSF users need to use network security services to protect network traffic from various malicious attacks. To request this security service, I2NSF users can create high-level security policies for the security services they want and notify the network operation management system of this.

Meanwhile, in the process of preparing a high-level security policy, an I2NSF user may not consider the type of NSF(s) required to realize a security service or security policy rule configuration for each NSF(s).

Additionally, I2NSF users can be notified of security events that occur within the underlying NSF(s) by the network operations management system. By analyzing these security event(s), I2NSF users can identify new attacks and update (or create) higher-level security policies to address new attacks. In this way, I2NSF users can define, manage, and monitor security policies.

Network Operation Management System

A network operations management system is a component that acts as a collection and distribution point for security provisioning, monitoring, and other operations. For example, a network operations management system may be a security controller. Such a network operations management system may be managed by a network security manager and may also be referred to as an I2NSF management system.

One of the main roles of a network operation management system (or security controller) is to translate a high-level security policy (or policy rule) from an I2NSF user into a low-level security policy rule for specific NSF(s). After the network operation management system (or security controller) receives a high-level security policy from an I2NSF user, the network operation management system (or security controller) can first determine the type of NSF(s) required to enforce the policy requested by the I2NSF user. Then, the network operation management system (or security controller) can generate a low-level security policy for each of the required NSF(s). Finally, the network operation management system (or security controller) can set the generated low-level security policy to each of the NSF(s).

In addition, the network operation management system (or security controller) can monitor the NSF(s) running in the system and maintain various information (e.g., network access information and workload status, etc.) for each NSF(s). In addition, the network operation management system (or security controller) can dynamically manage a pool of NSF instances through dynamic life-cycle management of NSF instances with the help of the developer management system.

NSF

NSF is a logical entity or software component that provides security-related services. For example, NSF can receive low-level security policies, detect malicious network traffic based on them, and block or mitigate them. Through this, the integrity and confidentiality of network communication streams can be guaranteed.

Developer Management System

A Developer Management System is an I2NSF component that sends information to other I2NSF components (e.g., I2NSF users, network operations management systems) and/or provides services (e.g., network security services). The Developer Management System may also be referred to as a Vendor's Management System. An entity that performs a role assigned to such a Developer Management System may be referred to as an I2NSF producer.

The Developer Management System may be managed by a third-party security vendor that provides NSF(s) to the Network Operations Management System. There may be multiple Developer Management System(s) from different security vendors.

I2NSF Consumer-Facing Interface (simply, Consumer-Facing Interface (CFI))

CFI is an interface to the user's I2NSF system, located between the I2NSF user and the network operations management system. By design, it hides the details of the underlying NSF(s), and provides the user with only an abstract view of the NSF(s).

This CFI can be used by different users of a given I2NSF system to define, manage and monitor security policies for specific flows within the management domain. Higher level security policies (or policy rules) created by I2NSF users can be passed to the network operations management system through this CFI.

I2NSF NSF-Facing Interface (simply, NSF-Facing Interface (NFI))

NFI is an interface located between the network operations management system (or security controller) and the NSF(s).

NFI can be used to specify and monitor flow-based security policies enforced by one or more NSFs. For example, an I2NSF system can use a flow-based NSF. Here, a flow-based NSF is an NSF that inspects network flows according to a set of policies to enhance security characteristics. Flow-based security by such a flow-based NSF means that packets are inspected in the order they are received and that no modifications are made to the packets during the inspection process. Interfaces for flow-based NSFs can be classified as follows:

- NSF Operational and Administrative Interface: A group of interfaces used by the I2NSF management system to program the operational state of the NSF; this group of interfaces also includes administrative control capabilities. I2NSF policy rules represent one way to change this group of interfaces in a consistent manner. Because applications and I2NSF components need to dynamically control the behavior of the traffic they send and receive, most of the I2NSF effort is focused on this group of interfaces.

- Monitoring Interfaces: A group of interfaces used by the I2NSF management system to obtain monitoring information from one or more selected NSFs; each interface in this group of interfaces may be a query-based or a report-based interface. The difference between the two is that a query-based interface is used by the I2NSF management system to obtain information, whereas a report-based interface is used by the NSF to provide information. The capabilities of this group of interfaces may also be defined by other protocols, such as LOG [RFC 5424] and DOTS (Distributed Denial-of-Service Open Threat Signaling) [RFC 8782]. The I2NSF management system may take one or more actions based on receipt of the information. This shall be specified by an I2NSF policy rule. This group of interfaces does not change the operational state of the NSF.

In this way, NFI can be developed using a flow-based paradigm. A common trait of flow-based NSF is to process packets based on the content (e.g., header/payload) and/or context (e.g., session state and authentication state) of the received packet. This feature is one of the requirements for defining the operation of an I2NSF system.

On the other hand, the I2NSF management system does not need to use all the capabilities of a given NSF, nor does it need to use all available NSFs. Therefore, this abstraction allows NSF features to be treated as building blocks by the NSF system. Therefore, developers are free to use security capabilities defined by vendor- and technology-independent NSFs.

I2NSF Registration Interface (simply, Registration Interface (RI))

RI is an interface between the network operation management system and the developer management system. NSFs provided by different vendors may have different capabilities. Therefore, in order to automate the process of utilizing the various types of security capabilities provided by different vendors, there is a need for vendors to have a dedicated interface to define the capabilities of their NSFs. This dedicated interface may be referred to as the I2NSF Registration Interface (RI).

Capabilities in an NSF can be pre-configured or discovered dynamically via the I2NSF registration interface. If a new capability is added to an NSF that is to be exposed to consumers, the capabilities of that new capability need to be registered in the I2NSF registry via the I2NSF registration interface so that interested management and control entities can be made aware of them.

FIG. 2 illustrates the architecture of an I2NSF system according to one embodiment of the present specification. The I2NSF system of FIG. 2 shows the configuration of an I2NSF user and network operation management system more specifically than the I2NSF system of FIG. 1. In FIG. 2, any description that is redundant with the description described above in FIG. 1 is omitted.

Referring to FIG. 2, the I2NSF system includes I2NSF user, security management system, and NSF instances layers. The I2NSF user layer includes application logic, policy updater, and event collector as components. The security management system layer includes a security controller and a developer management system. The security controller of the security management system layer includes a security policy manager and an NSF capability manager as components.

The I2NSF user layer communicates with the security management system layer via a consumer-facing interface. For example, the policy updater and event collector of the I2NSF user layer communicate with the security controller of the security management system layer via the consumer-facing interface. In addition, the security management system layer communicates with the NSF instance layer via the NSF-facing interface. For example, the security controller of the security management system layer communicates with the NSF instance(s) of the NSF instance layer via the NSF-facing interface. In addition, the developer management system of the security management system layer communicates with the security controller of the security management system layer via the registration interface.

The I2NSF user layer, the security controller component of the security management system layer, the developer management system component of the security management system layer, and the NSF instance layer of FIG. 2 correspond to the I2NSF user component, the network operation management system component, the developer management system component, and the NSF component of FIG. 1, respectively. In addition, the consumer-facing interface, the NSF-facing interface, and the registration interface of FIG. 2 correspond to the consumer-facing interface, the NSF-facing interface, and the registration interface of FIG. 1. Hereinafter, newly defined components included in each layer will be described.

I2NSF users

As described above, the I2NSF user layer includes three components: Application Logic, Policy Updater, and Event Collector. The roles and operations of each are described below.

The application logic is a component that generates a high-level security policy. To do this, the application logic receives events from the event collector to update (or generate) the high-level policy, and updates (or generates) the high-level policy based on the collected events. After that, the high-level policy is sent to the policy updater for distribution to the security controller. To update (or generate) the high-level policy, the event collector receives events sent by the security collector and sends them to the application logic. Based on this feedback, the application logic can update (or generate) the high-level security policy.

In Figure 2, the application logic, policy updater, and event collector are each depicted as separate components, but this specification is not limited thereto. In other words, each is a logical component and may be implemented as one or two components in an I2NSF system.

Security Management System

As described above, the security controller in the security management system layer includes two components: a security policy manager and an NSF capability manager.

The security policy manager can receive a high-level policy from a policy updater via CFI and map this policy to several low-level policies. These low-level policies are related to a given NSF capability registered with the NSF capability manager. In addition, the security policy manager can pass this policy to the NSF(s) via NFI.

The NSF capability manager can specify the capabilities of an NSF registered by the developer management system and share it with the security policy manager to create lower-level policies related to the given NSF capability. Whenever a new NSF is registered, the NSF capability manager can request the developer management system to register the capabilities of the NSF in the management table of the NSF capability manager through the registration interface. The developer management system corresponds to another part of the security management system to register the capabilities of a new NSF with the NSF capability manager.

In Figure 2, the security policy manager and the NSF capability manager are each depicted as separate configurations, but this specification is not limited thereto. In other words, each is a logical component and may be implemented as one component in an I2NSF system.

NSF Instances

As illustrated in Fig. 2, the NSF instance layer includes NSFs. At this time, all NSFs are located in this NSF instance layer. Meanwhile, after mapping the upper-level policy to the lower-level policy, the security policy manager transfers the policy to the NSF(s) through the NFI. In this case, the NSF can detect malicious network traffic and block or mitigate it based on the received lower-level security policy.

Rapid development of virtualized systems requires advanced security capabilities in a variety of scenarios (e.g., network devices in enterprise networks, user equipment in mobile networks, devices on the Internet, or residential access users).

NSFs produced by various security vendors can provide customers with various security capabilities. That is, multiple NSFs can be combined together to provide security services for a given network traffic, regardless of whether they are implemented as physical or virtual capabilities.

Security capabilities are a set of network security-related capabilities that can be used for security policy enforcement purposes. Security capabilities are independent of the security control mechanisms that are actually implemented, and every NSF has a registered set of capabilities that the NSF can provide.

Security Capabilities is a market leader in providing a way to define customized security protection by unambiguously describing the security capabilities offered by a particular NSF. Additionally, Security Capabilities allow for vendor-neutral descriptions of security capabilities.

That is, when designing a network, there is no need to mention a specific product, and features can be considered according to capability.

As discussed above, there are two types of I2NSF interfaces that can be used to provide security policies, as follows:

- I2NSF Consumer-Facing Interface: A service-oriented interface that provides a communication channel between NSF data and service users and the network operations management system (or security controller).

The I2NSF Consumer-Facing Interface can be used to exchange security information between various applications (e.g. OpenStack or various BSS/OSS components) and a security controller. The design goal of the Consumer-Facing Interface is to separate the specification of security services from their implementation.

- Interface between NSFs (e.g. firewall, intrusion prevention or anti-virus) and security controller (NSF-Facing Interface): The NSF-Facing Interface is used to decouple the security management system from the set of NSFs and their various implementations, and is independent of how the NSFs are implemented (e.g. virtual machines or physical appliances, etc.).

Below, we will explore an object-oriented information model for network security, content security, and attack mitigation capabilities along with associated I2NSF policy objects.

The terms used in the information model in this specification can be defined as follows:

AAA: Access control, Authorization, Authentication

ACL: Access Control List

(D)DoD: (Distributed) Denial of Service (attack)

ECA: Event-Condition-Action

FMR: First Matching Rule (resolution strategy)

FW: Firewall

GNSF: Generic Network Security Function

HTTP: HyperText Transfer Protocol

I2NSF: Interface to Network Security Functions

IPS: Intrusion Prevention System

LMR: Last Matching Rule (resolution strategy)

MIME: Multipurpose Internet Mail Extensions

NAT: Network Address Translation

NSF: Network Security Function

RPC: Remote Procedure Call

SMA: String Matching Algorithm

URL: Uniform Resource Locator

VPN: Virtual Private Network

purpose

Registering NSFs with I2NSF Framework: The Developer Management System (DMS) of the I2NSF framework is typically operated by the NSF vendor, and provides the NSFs developed by the NSF vendor to the Security Controller using the registration interface. The DMS registers the NSF and its capabilities with the I2NSF framework through the registration interface. For a registered NSF, the Security Controller maintains a capabilities catalog of that NSF.

Updating the capabilities of a registered NSF: After an NSF is registered with a security controller, some modifications to the capabilities of the NSF may be required later. In this case, the DMS uses the registration interface to update the capabilities of the NSF, and this update must be reflected in the NSF's catalog.

Ask DMS for some capabilities: If some security capabilities are required to process a security service request from an I2NSF user, the Security Controller searches the registered NSFs to find an NSF that can provide the required capabilities. However, the Security Controller may not find an NSF with the required capabilities among the registered NSFs. In this case, the Security Controller should request additional NSFs that can provide the required security capabilities from the DMS through the registration interface.

Figure 3 is an example of an I2NSF Registration Interface Information Model to which this specification can be applied.

The I2NSF registration interface is used by the Security Controller and the Developer's Management System (DMS) in the I2NSF framework. Referring to Fig. 3, the information model of the I2NSF registration interface, which consists of two sub-modules: NSF Capability Registration and NSF Capability Query, is used for the tasks listed above. An in-depth description of each sub-model is provided below.

NSF Capability Registration

Figure 4 is an example of an NSF Capability Registration Sub-Model to which this specification can be applied.

Referring to Fig. 4, this sub-model is used by the DMS to register an NSF with the security controller. Fig. 4 shows how these sub-modules are structured. The most important part in Fig. 4 is the NSF capability, which specifies the set of capabilities that the NSF to be registered can provide. The NSF name contains a unique name of the NSF with the specified set of capabilities. When registering an NSF, the DMS may additionally include the network access information of the NSF that is necessary to enable network communication with the NSF. The NSF capability information and the NSF access information are described in more detail below.

NSF Capability Information

Figure 5 is an example of NSF Capability Information to which this specification can be applied.

NSF capability information basically describes the security capability of NSF. Referring to Fig. 5, it shows the capability object of SF. According to the information model of NSF capability defined in [capability-dm], it shares the same I2NSF security capabilities: time capability, event capability, condition capability, operation capability, resolution strategy capability, basic operation capability, and IPsec method [i2nsf-ipsec]. In addition, NSF capability information additionally includes the performance capability of NSF, as shown in Fig. 5.

capability-dm / i2nsf-ipsec

FIG. 6 illustrates the capabilities of an NSF in the I2NSF Framework according to an embodiment of the present disclosure. FIG. 6 illustrates the capabilities of an NSF in the I2NSF Framework according to an embodiment of the present disclosure.

Referring to Figure 6, the Network Operator Management (Mgmt) system of the NSF developer can register the capabilities that the NSF and the network security device can support. In order to register the NSF in this way, the developer Mgmt system utilizes the YANG data model of this standardized capability through the registration interface. By maintaining the capabilities of these network security devices centrally, the security devices can be easily managed.

The NSF-Facing interface is used to configure security policy rules of general network security capabilities [draft-ietf-i2nsf-nsf-nsf-face-dm], and the NSF monitoring interface can be used to configure security policy rules of advanced network security capabilities [draft-dong-i2nsf-asf-asf-config] respectively.

When a network administrator applies security policy rules to block malicious users, it can be a huge burden to apply all the necessary rules to the NSF one by one. This problem can be solved by managing the capabilities of the NSF.

For example, if a network administrator wants to block malicious users over IPv6, the network administrator can use an I2NSF user (i.e., a web browser or software) to send a security policy rule to the Mgmt system that blocks the user.

When the network operator management system receives a security policy rule, it can automatically forward the security policy rule to the appropriate NSF (i.e., NSF-m of developer management system A and NSF-1 of developer management system B) to support the required capability (i.e., IPv6). Therefore, the I2NSF user does not need to consider the NSF to which the rule applies.

If the NSF encounters a malicious packet, it can be a huge burden for the network administrator to apply rules to the NSF to block the malicious packets one by one. This problem can be solved by managing the capabilities of the NSF.

For example, if the NSF detects a suspicious IPv4 packet, the NSF can request information about the suspicious IPv4 packet to the Network Operations Management System in order to change certain rules and/or configurations. The Network Operations Management System, upon receiving the above information, can examine the information about the suspicious IPv4 packet. If a large number of packets are determined to be malicious packets, the Mgmt System can support the ability to manage them by creating a security policy rule and sending it to the appropriate NSF (i.e., NSF-1 of Developer's Mgmt System A and NSF-1 and NSF-n of Developer's Mgmt System B). In this way, the new security policy rule to block the malicious packet can be applied to the appropriate NSF without human intervention.

FIG. 7 illustrates a two-data model structure for NSF capabilities according to one embodiment of the present specification.

Referring to Figure 7, the two data models include NSF capabilities. NSF capabilities include time capabilities, event capabilities, conditional capabilities, action capabilities, resolution strategy capabilities, and basic action capabilities.

Time capabilities are used to specify the ability to specify when an I2NSF policy rule is to be executed. Time capabilities are defined in terms of absolute time and periodic time. Absolute time means the exact time of the start or end. Periodic time means a recurring time, such as a day, week, or month.

Event capabilities are used to specify how to trigger the execution of a condition in an I2NSF policy rule.

Event capabilities defined in this way are defined as system events and system alarms. Event capabilities can be extended based on specific vendor conditional capabilities. Event capabilities are described in detail in [draf-ietf-i2nsf-capability].

Conditional capabilities are used to specify the ability of a set of attributes, characteristics, and/or values to be compared against a known set of attributes, characteristics, and/or values to determine whether a set of actions associated with a given (expressed) I2NSF policy rule can be executed. Conditional capabilities are categorized into general network security capabilities and advanced network security capabilities.

For general network security capabilities, conditional capabilities can be defined as IPv4 capabilities, IPv6 capabilities, TCP capabilities, UDP capabilities, and ICMP capabilities. For advanced network security capabilities, conditional capabilities can be defined as antivirus capabilities, anti-DDoS capabilities, IPS capabilities, HTTP capabilities, and VoIP/VoLTE capabilities. Conditional capabilities can be extended by specific vendor conditional capabilities. Conditional capabilities are described in detail in [draf-ietf-i2nsf-capability].

Action capabilities are used to specify the ability to control and monitor aspects of a flow-based NSF when events and conditions are met. Action capabilities can be defined as receive action capabilities, send action capabilities, and log action capabilities. Action capabilities can be extended based on the action capabilities of a particular vendor. Action capabilities are described in detail in [draft-ietf-i2nsf-1991].

Resolution strategy capability is used to specify how to resolve conflicts that occur between specific NSF matches or between the actions of identical or different policy rules contained in a specific NSF. Resolution strategy capabilities can be defined as First Matching Rule (FMR), Last Matching Rule (LMR), Priority Matching Rule (PMR), Priority Matching Rule (PMR) with Errors (PMRE), and Priority Matching Rule with No Errors (PMRN). Resolution strategy capabilities can be extended based on the operational capabilities of a specific vendor. Resolution strategy capabilities are detailed in [draf-ietf-i2nsf-capability].

The default action capability is used to specify how to execute I2NSF policy rules when no rule matches the received packet. The default action capability can be defined as pass, drop, reject, warn, and mirror. The default action capability can be extended by specific vendor action capabilities. The default action capability is described in detail in [draf-ietf-i2nsf-capability].

IPsec method capability is used to specify the capability of the Internet Key Exchange (IKE) method for secure communication. The basic operation capability can be defined as IKE and IKE-less. The basic operation capability can be extended by specific vendor operation capabilities. The basic operation capability is described in detail in [draft-ietf-i2nsf-sdn-ipsec-flow-protection].

Performance Capabilities

Fig. 8 is an example of Performance Capability to which the present specification can be applied. Referring to Fig. 8, this information can represent the processing capability of the NSF. Assuming that the current workload status of each NSF is collected through NSF monitoring [i2nsf-monitoring], this capability information of the NSF can be used to determine whether the NSF is in a congested state by comparing it with the current workload of the NSF. Furthermore, this information can specify the availability of each type of resource, such as the processing capability available to the NSF (the registration interface can control the usage and limits of the created instances and make appropriate requests according to the status). As described in Fig. 8, this information consists of two items: processing and bandwidth. The processing information describes the available processing capability of the NSF. It can describe information about the network with available bandwidth.

NSF Access Information

NSF access information includes the IPv4 address, IPv6 address, port number, and supported transport protocol (e.g., Virtual Extensible LAN (VXLAN) [RFC 7348], Generic Protocol Extensions for VXLAN [VXLAN-GPE]) required to communicate with the NSF. The NSF access information described in this specification can be used to identify a specific NSF instance (i.e., the NSF access information is a signature (unique identifier) of an NSF instance in the entire system).

NSF Capability Query

A security controller may require some additional capabilities to process a security service request from an I2NSF user, but none of the registered NSFs may have the required capabilities. In this case, the security controller can use the NSF Capability Information submodel to describe the required capabilities and query the DMS for an NSF that can provide these capabilities.

Data Model

1. I2NSF Registration Interface

Figure 8 is an example of a YANG Tree of I2NSF Registration Interface to which this specification can be applied.

Referring to Figure 8, the I2NSF registration interface is used for the following purposes. The Developer Management System (DMS) registers an NSF and its capabilities with the Security Controller through the registration interface. If the Security Controller cannot find an NSF among the registered NSFs that can provide some required capabilities, the Security Controller uses the registration interface to query the DMS for an NSF that has the required capabilities. The following section describes the YANG data model that supports these operations.

(1) NSF Capability Registration

Fig. 9 is an example of a YANG Tree of NSF Capability Registration Module to which the present specification can be applied. Referring to Fig. 9, when registering an NSF with a security controller, this module can be used by the DMS to describe the capabilities that the NSF can provide. The DMS includes the network access information of the NSF required for network connection with the NSF and the capability description of the NSF.

(2) NSF Capability Query

FIG. 10 is an example of a YANG Tree of NSF Capability Query Module to which the present specification can be applied. Referring to FIG. 10, a security controller may require some additional capabilities to provide a security service requested by an I2NSF user, but none of the registered NSFs may have the required capabilities. In this case, the security controller uses this module to describe the required capabilities and then queries the DMS for an NSF that can provide these capabilities. NETCONF RPC can be used to send an NSF capability query. The input data is query-i2nsf-capability-info and the output data is nsf-access-info. In FIG. 10, ietf-i2nsf-capability refers to a module defined in [capability-dm].

2. NSF Capability Information

Fig. 11 is an example of YANG Tree of I2NSF NSF Capability Information to which the present specification can be applied. Referring to Fig. 11, an extended structure of the above-described nsf-capability-info is exemplified. ietf-i2nsf-capability points to a module defined in [capability-dm]. Capability is used to specify the performance capability of NSF.

Fig. 12 is an example of a YANG Tree of I2NSF NSF Performance Capability to which the present specification can be applied. Fig. 12 is an example of the nsf-performance-capability described above.

Referring to Figure 12, this module is used to specify the performance capabilities of an NSF when registering or starting an NSF.

3. NSF Access Information

Figure 13 is an example of a YANG Tree of I2NSF NSF Access Informantion to which the present specification can be applied.

Referring to Figure 13, this module contains network access information of the NSF required to enable network communication with the NSF.

YANG Data Modules

Fig. 14 is an example of a Registration Interface YANG Data Model to which the present specification can be applied. Referring to Fig. 14, a YANG module of a data model for a registration interface between a security controller and a developer management system can be provided.

Security Considerations

The YANG module specified in this specification defines a data schema designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is a secure transport layer, and the required secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the required secure transport is TLS [RFC8446].

The NETCONF Access Control Model [RFC8341] provides a means to restrict access for specific NETCONF or RESTCONF users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content.

This YANG module defines a number of data nodes that are writable/creable/deletable (i.e. config true, the default). These data nodes may be considered sensitive or vulnerable in some network environments. Without proper protection, write operations (e.g. edit-configure) to these data nodes may have negative impacts on network operation. Below are the subtrees and data nodes and their sensitivities/vulnerabilities.

o nsf-registrations: An attacker can use this to register a compromised or malicious NSF instead of a legitimate NSF with the security controller.

o nsf-performance-capability: An attacker can illegally modify this to provide false information about the performance capabilities of the target NSF.

o nsf-capability-info: An attacker can illegally modify this to provide false information about the security capabilities of the target NSF.

o nsf-access-info: An attacker can illegally modify this to provide incorrect network access information for the target NSF.

Some readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. Therefore, it is important to control read access (e.g. via get, get-config or notification) to these data nodes. Below are the subtrees and data nodes and their sensitivities/vulnerabilities.

o nsf-registrations: An attacker may intercept this and attempt to collect sensitive information about registered NSFs.

o nsf-performance-capability: Attackers can collect performance capability information of the target NSF and misuse the information for subsequent attacks.

o nsf-capability-info: Attackers can collect security capability information of the target NSF and misuse the information for subsequent attacks.

o nsf-access-info: Attackers can collect network access information of the target NSF and misuse the information for subsequent attacks.

The RPC operations of this YANG module may be considered sensitive or vulnerable in some network environments. Therefore, it is important to control access to these operations. The operations and their sensitivities/vulnerabilities are as follows:

o nsf-capability-query: An attacker can use this RPC operation to degrade the availability of the DMS or collect some relevant NSF information from the DMS.

Figure 15 is an example of an embodiment to which this specification can be applied.

Referring to FIG. 15, a security management system for managing a Network Secure Function (NSF) includes a developer management system, an I2NSF (Interface to Network Security Functions) user, and a security controller. The developer management system and the security controller can be connected via a registration interface. More specifically, the registration interface can include 1) a first model for registering the capability of the NSF to the security controller, and 2) a second model for requesting the additional NSF to the developer management system.

1. The developer management system sends a first registration request message to the Security Controller through the registration interface to request registration of the NSF provided from the NSF vendor.

2. The developer management system receives a request message for requesting an additional NSF related to the required capabilities through the registration interface, if there is no NSF among the registered NSFs from the security controller that provides the required capabilities based on a security service request from an I2NSF (Interface to Network Security Functions) user. For example, the security controller can be connected to an I2NSF user through the I2NSF consumer-facing interface.

3. As a security controller, a second registration request message is sent to request registration of the additional NSF as a response to the request message through the registration interface.

Additionally, when a renewal of a registered NSF capability is required, the developer management system may receive a renewal request message from the security controller to request a renewal of the registered NSF capability, and transmit a renewal message to the security controller as a response to the renewal request message through the registration interface.

The embodiments described above are combinations of the components and features of the present specification in a given form. Each component or feature should be considered optional unless explicitly stated otherwise. Each component or feature may be implemented in a form that is not combined with other components or features. In addition, it is also possible to combine some components and/or features to form an embodiment of the present specification. The order of the operations described in the embodiments of the present specification may be changed. Some components or features of one embodiment may be included in another embodiment, or may be replaced with corresponding components or features of another embodiment. It is obvious that claims that do not have an explicit citation relationship in the scope of the patent may be combined to form an embodiment or may be included as a new claim by post-application amendment.

Embodiments according to the present specification may be implemented by various means, for example, hardware, firmware, software, or a combination thereof. In case of hardware implementation, an embodiment of the present specification may be implemented by one or more ASICs (application specific integrated circuits), DSPs (digital signal processors), DSPDs (digital signal processing devices), PLDs (programmable logic devices), FPGAs (field programmable gate arrays), processors, controllers, microcontrollers, microprocessors, and the like.

In the case of implementation by firmware or software, an embodiment of the present specification may be implemented in the form of a module, procedure, function, etc. that performs the capabilities or operations described above. The software code may be stored in a memory and may be driven by a processor. The memory may be located inside or outside the processor and may exchange data with the processor by various means already known.

It will be apparent to those skilled in the art that this specification may be embodied in other specific forms without departing from the essential characteristics of this specification. Accordingly, the above detailed description should not be construed in all respects as restrictive but as illustrative. The scope of this specification should be determined by a reasonable interpretation of the appended claims, and all changes within the equivalency range of this specification are intended to be included in the scope of this specification.

Industrial applicability

This specification can be applied to various security management systems.

Claims (16)

In a security management system that manages a network security function (NSF) through a registration interface, a method of registering by a developer's management system,
A step of transmitting a first registration request message to a Security Controller through the registration interface to request registration of the provided NSF based on the NSF provided from the NSF Vendor;
A step of receiving a request message for requesting an additional NSF related to the required capabilities through the registration interface, when there is no NSF among the NSFs registered by the security controller that provides the required capabilities based on a security service request from an I2NSF (Interface to Network Security Functions) user; and
A step of transmitting a second registration request message to the security controller through the registration interface as a response to the request message to request registration of the additional NSF;
, wherein the registration interface comprises 1) a first model for registering the capability of the NSF to the security controller, and 2) a second model for requesting the additional NSF to the developer management system.
The above method,
Further comprising a step of receiving, from a network security manager, a security policy rule applicable to a specific NSF among the NSFs registered in the developer management system,
A registration method wherein the above security policy rule is automatically generated and transmitted by the network security manager without user intervention based on malicious packets detected by the specific NSF.
In the first paragraph,
A step of receiving a renewal request message for requesting renewal of the registered NSF capability from the security controller; and
A step of transmitting a renewal message as a response to the renewal request message through the registration interface to the security controller;
A registration method further comprising:
In the first paragraph,
The above first model
A registration method comprising: 1) an NSF name indicating a unique name of an NSF that can be registered, 2) NSF capability information indicating a set of capabilities of the NSF that can be registered, and 3) NSF access information for the NSF that can be registered to communicate with a network.
In the third paragraph,
The above NSF capability information is
A registration method comprising time ability, event ability, condition ability, action ability, solution strategy ability and basic action ability.
In the fourth paragraph,
The above NSF capability information is
A registration method further comprising performance capability information for indicating the processing capability of the NSF that can be registered.
In clause 5,
The above performance capability information
A registration method including 1) an available processing power value and 2) a bandwidth value related to an available network, for determining whether the NSF that can be registered is congested.
In the third paragraph,
The above request message is
A registration method based on the required capabilities generated by the above security controller using the above NSF capability information.
In Article 6,
The above NSF capability information is
A registration method further comprising IPsec method capability information for specifying the capability of supporting Internet Key Exchange (IKE) for secure communication with the available network.
In a security management system that manages the Network Security Function (NSF) through the Registration Interface, in the Developer's Management System,
A transceiver for transmitting and receiving signals;
memory for storing data; and
A processor controlling the above transceiver and the above memory;
The above processor
Through the above transceiver, a first registration request message is transmitted to the Security Controller through the registration interface to request registration of the provided NSF based on the NSF provided from the NSF Vendor,
Based on a security service request from an I2NSF (Interface to Network Security Functions) user, if there is no NSF among the NSFs registered by the security controller that provides the required capabilities, a request message is received to request an additional NSF related to the required capabilities through the registration interface.
To the above security controller, a second registration request message is transmitted to request registration of the additional NSF as a response to the request message through the registration interface,
The above registration interface includes 1) a first model for registering the capability of the NSF to the security controller and 2) a second model for requesting the additional NSF to the developer management system.
The above processor,
Receive from the network security manager a security policy rule that applies to a specific NSF among the NSFs registered in the developer management system.
The above security policy rule is a developer management system that is automatically generated and transmitted by the network security manager without user intervention based on malicious packets detected by the above specific NSF.
In Article 9,
The above processor
A developer management system for receiving, through the transceiver, an update request message for requesting the update of the registered NSF capability from the security controller, and transmitting, through the registration interface, an update message as a response to the update request message to the security controller.
In Article 9,
The above first model
A developer management system including 1) an NSF name indicating a unique name of an NSF that can be registered, 2) NSF capability information indicating a set of capabilities of the NSF that can be registered, and 3) NSF access information for the NSF that can be registered to communicate with a network.
In Article 11,
The above NSF capability information is
A developer management system that includes time capabilities, event capabilities, condition capabilities, action capabilities, solution strategy capabilities, and basic action capabilities.
In Article 12,
The above NSF capability information is
A developer management system further comprising performance capability information for indicating the processing capability of the NSF that may be registered above.
In Article 13,
The above performance capability information
A developer management system, including 1) available processing power value and 2) bandwidth value related to available network, for determining whether the NSF that can be registered above is congested.
In Article 11,
The above request message is
A developer management system based on the required capabilities generated by the above security controller using the above NSF capability information.
In Article 14,
The above NSF capability information is
A developer management system further comprising IPsec method capability information for specifying the capability of supporting Internet Key Exchange (IKE) methods for secure communications with the available networks.

Images