WO2018097422A1

WO2018097422A1 - Method and system for traffic steering triggered by network security function, and device therefor

Info

Publication number: WO2018097422A1
Application number: PCT/KR2017/004510
Authority: WO
Inventors: 정재훈; 현상원; 우상욱; 여윤석
Original assignee: 성균관대학교 산학협력단
Priority date: 2016-11-24
Filing date: 2017-04-27
Publication date: 2018-05-31

Abstract

Disclosed are a method and a system for traffic steering triggered by a network security function (NSF), and a device therefor. Particularly, a system for supporting traffic steering triggered by an NSF can comprise an NSF forwarder (NSFF) for: performing a security check on a packet introduced to the system; determining whether an additional check by another NSF is necessary, on the basis of the result of the security check; attaching, to the packet, a packet forwarding header for summoning the additional check if the additional check is necessary; and transmitting the packet to a second NSF if a first NSF for transmitting, to the NSFF, the packet to which the packet forwarding header is attached and a second NSF having a security capability required for the additional check included in the packet forwarding header are discovered.

Description

Method and system for traffic steering triggered by network security function, apparatus therefor

The present invention relates to a system for providing a security service, and more particularly, to a method and system for traffic steering triggered by a network security function (NSF), and apparatus for the same.

Today, many companies, such as service providers and Internet service providers, have adopted Network Functions Virtualization (NFV) technology to reduce operating costs and leverage resources in a more efficient and flexible way. In addition, the use of network functions and resources provided by third-party service providers is becoming increasingly popular. To protect their network systems and information assets, companies have begun to subscribe to and use the security features provided by third-party security vendors instead of operating security appliances themselves.

This operational model offers a variety of benefits. Companies can reduce capital outlays because they do not have to pay for physical security equipment. In addition, you can always maintain an up-to-date database of various attack signatures.

However, since security functions are developed by multiple solution vendors and managed by multiple network operators, in order to successfully deploy NFV-based security functions, Standardization is required.

It is an object of the present invention to propose a traffic steering framework that is triggered by an NSF (Network Security Function).

The technical problems to be achieved in the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned above will be clearly understood by those skilled in the art from the following description. Could be.

According to an aspect of the present invention, in a system supporting traffic steering triggered by a network security function (NSF), a security check for a packet introduced into the system is performed, and the security is performed. Based on the result of the inspection, it is determined whether additional inspection by another NSF is necessary, and if the additional inspection is necessary, a packet forwarding header for attaching the additional inspection is attached to the packet, and When searching for a first NSF for transmitting a packet with a packet forwarding header to an NSF forwarder (NSFF) and a second NSF having the security capability required for the additional check included in the packet forwarding header, It may include an NSFF for delivering the packet to a second NSF.

Preferably, the packet forwarding header may include an action code field including a result of a security check of the packet, a capability information field including security capability information required for the additional inspection, and a capability information indicating a number of the capability information fields. It may include a number field.

Preferably, the packet introduced into the system may be received by the NSFF and forwarded by the NSFF to the first NSF.

Advantageously, according to the trust level of the source of the packet, the first NSF causes the packet to be a secure packet, a dangerous packet, and a suspicious packet. Can be classified.

Preferably, when the packet is classified as a secure packet, it may be delivered to another destination through the NSF without further security check.

Preferably, if the packet is classified as a dangerous packet, the packet may be dropped.

Preferably, when the packet is classified as the suspicious packet, the packet may be delivered to the NSFF with the packet forwarding header attached.

Preferably, the method may further include an NSF operation management for managing a list of information about all available NSFs.

Advantageously, if the second NSF is not discovered, the NSFF sends an NSF generation request packet containing the security capabilities required for the further inspection to the NSF operations manager, and a third generated from the NSF operations manager. Receiving the information on the NSF forwards the packet to the third NSF, the NSF operations manager is the first having the security capability required for the further inspection in consideration of the traffic load status of each NSF in the information list 3 NSF may be selected and information on the third NSF may be transmitted to the NSFF.

Preferably, if there is no NSF in the information list with the security capability required for the additional inspection, the developer's management system generates a NSF having the security capability required for the additional inspection. You can request

Preferably, when the NSF operations manager monitors the traffic load status of all available NSFs and detects that excessive traffic is generated for a particular NSF, the developer's management system is identical to the NSF in which the excessive traffic is generated. May request the creation of a new NSF with security capabilities.

Preferably, if the NSF operations manager monitors traffic load status of all available NSFs and detects that a particular NSF is not used, the NSF operations manager may request the developer's management system to remove the unused NSFs. .

According to another aspect of the present invention, in a method in which a network security function (NSF) performs traffic steering, security of a packet introduced to a system supporting the traffic steering is provided. Performing a check, determining whether an additional check by another NSF is necessary based on a result of the security check, and if a further check is needed, a packet forwarding header to invoke the additional check Attaching the packet forwarding packet to the NSF forwarder (NSFF), wherein the packet forwarding header is configured for the security capability required for the further inspection. May contain information.

Advantageously, the packet is secured, dangerous and suspicious by the first NSF according to the trust level of the source of the packet. Can be classified.

According to an embodiment of the present invention, traffic steering between NSFs is enabled, and composite inspection of network traffic is possible through various types of NSFs.

In addition, according to an embodiment of the present invention, it is possible to provide load balancing through dynamically generated NSF instances.

In addition, according to an embodiment of the present invention, by using a standardized interface and data model, it is possible to simplify control and management of various network security functions (NSFs).

In addition, according to an embodiment of the present invention, by providing only an abstract view of the NSF to the user, it enables user-friendly security policy specification.

In addition, according to an embodiment of the present invention, as NSF is dynamically enabled / disabled, it may support various network conditions and security requirements.

The effects obtainable in the present invention are not limited to the above-mentioned effects, and other effects not mentioned will be clearly understood by those skilled in the art from the following description. .

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, included as part of the detailed description in order to provide a thorough understanding of the present invention, provide embodiments of the present invention and together with the description, describe the technical features of the present invention.

1 illustrates the configuration of a traffic steering system that is triggered by an NSF (NSF-triggered) according to an embodiment of the present invention.

2 illustrates an existing service function chain architecture.

FIG. 3 is a diagram illustrating an information model for NSF capability in an NSF-triggered traffic steering system in accordance with an embodiment of the present invention.

4 illustrates an information model (IM) for NSF (s) with packet filtering capability in accordance with an embodiment of the present invention.

5 is a diagram for conceptually explaining traffic steering according to an embodiment of the present invention.

6 illustrates a packet forwarding header according to an embodiment of the present invention.

FIG. 7 is a diagram illustrating the flow of traffic in a traffic steering system triggered by an NSF (NSF-triggered) according to an embodiment of the present invention.

8 is a diagram illustrating the flow of traffic in a traffic steering system triggered by NSF-triggered according to an embodiment of the present invention.

FIG. 9 is a diagram illustrating a load balancing method in a NF-triggered traffic steering system according to an embodiment of the present invention.

10 through 13 illustrate a step-by-step procedure performed on an incoming VoIP / VoLTE packet utilizing the traffic steering framework triggered by the NSF according to an embodiment of the present invention.

14 illustrates a method of traffic steering triggered by NSF-triggered according to an embodiment of the present invention.

FIG. 15 illustrates a block diagram of an apparatus in a NSF-triggered traffic steering system in accordance with an embodiment of the present invention.

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

In some instances, well-known structures and devices may be omitted or shown in block diagram form centering on the core functions of the structures and devices in order to avoid obscuring the concepts of the present invention.

Specific terms used in the following description are provided to help the understanding of the present invention, and the use of such specific terms may be changed to other forms without departing from the technical spirit of the present invention.

Recently, a basic standard interface for NFV-based security functions has been developed by the Interface to Network Security Functions (I2NSF) working group. It is part of the International Internet Standards Organization called the Internet Engineering Task Force (IETF).

The purpose of the I2NSF is to define a standardized interface for heterogeneous network security function (NSF) provided by a number of security solution vendors.

In the I2NSF architecture, without having to consider the management of the NSF (s) in detail (management of the NSF eventually requires enforcement of the security policy), the user is required to protect network resources in the user's network system. A protection policy can be defined. In addition, a standardized interface from multiple vendors to NSF (s) can simplify the setup and management of tasks for heterogeneous NSF (s).

In order to effectively cope with more sophisticated network attacks in recent years, various network security functions (NSFs) (or security functions) have cooperatively controlled network traffic. It is necessary to carry out a complex analysis. In addition, depending on the nature and suspiciousness level of the network traffic, various types of network traffic need to be analyzed through different sets of NSFs.

Interface to Network Security (I2NSF) is an information model (IM) that allows the NSF to trigger additional inspections by calling other NSFs based on the results of its own analysis. Functions) has been proposed for the NSF-Facing Interface (NFI) in the framework.

However, the current design of the I2NSF framework has the disadvantage of not fully considering network traffic steering to enable continuous inspection through multiple NSFs.

Accordingly, the present invention proposes an architecture for integrating additional components for traffic steering through NSF into the I2NSF framework.

In particular, in the present invention, the high-level policy of NSF-triggered traffic steering triggered (or NSF-triggered) by NSF is interpreted / transformed and managed as a low level policy. To do this, we propose a way to extend the functionality of a security controller.

In addition, according to the present invention, the NSF instance (s) available and the information (eg network information and workload) of the NSF instance (s) are tracked and the NSF to be used for a given security function. You can determine the instance.

In addition, according to the present invention, based on the information provided and delivered by the Security Controller, the Network Security Function Forwarder (NSFF) may perform network traffic steering through the required NSF (s).

In addition, according to the present invention, the NSFF can perform advanced inspection by interpreting inspection results from the NSF.

In addition, according to the present invention, an additional packet header format for specifying a security inspection result and an advanced inspection request may be defined.

The present invention has the following effects largely.

Policy setting for continuous inspection: The NSF-triggered traffic steering architecture according to the present invention allows policy setting / management for NSF triggering. Based on the triggering policy, the relevant network traffic can be analyzed in a collaborative, complex manner through various NSF (s).

Network traffic steering for continuous inspection: In the NSF-triggered traffic steering architecture according to the present invention, network traffic may be steered through a plurality of required NSF (s) based on a triggering policy. In addition, the I2NSF Information Model (IM) for the NSF facing interface (NFI) requires the NSF to call another NSF for further inspection based on its inspection results. In order to satisfy this requirement, in the NSF-triggered traffic steering architecture according to the present invention, traffic may be forwarded from one NSF to another NSF.

Load balancing between NSF instances: The NSF-triggered traffic steering architecture according to the present invention provides load balancing of traffic entering the available NSF instances by leveraging a flexible traffic steering mechanism. . For this purpose, when an NSF has an excessive request for a security function, it can perform dynamic instantiation of the NSF (ie, create a new NSF that can perform that security function).

Terminologies that may be used in this document are defined as follows.

Network Security Function (NSF): A device that is in charge of a function that handles a particular handling of a received packet. The NSF may operate at various layers of various protocol stacks (eg, network layer or other Open System Interconnection (OSI) layer, etc.).

For example, as an example of a network security service function type, a firewall, an intrusion prevention system (IPS) / intrusion detection system (IDS), and a deep packet inspection (DPI) , Application Visibility and Control (AVC), Network Virus and Malware Scanning, Sandbox, Data Loss Prevention (DLP), Distribute Denial of Service (DDoS), A transport layer security (TLS) proxy, anti-spoofing, and the like may be included. The NSF according to the present invention may be implemented in any of the above examples, and various types of NSF may be used. In addition, multiple NSFs of the same type may be implemented. In addition, the NSF according to the present invention may be implemented by combining any one or more of the above-described examples.

Advanced Inspection / Action: Like the I2NSF Information Model (IM) for NFI-facing interface (NFI), Advanced Inspection / Action allows NSF to add to another NSF based on its inspection results. It means a call to check.

Network Security Function Profile (NSF Profile): The NSF Profile represents NSF's security inspection capabilities. Each NSF may have its own NSF Profile to specify the type of security services it provides, its resource capabilities, and so on.

NSF Operation Manager: NSF Operation Manager refers to a device that continuously manages NSF instance information and status and provides NSF network access information to support advanced inspection requests. do. For example, the information of the NSF instance may include a supported transport protocol, an Internet Protocol (IP) address, and a location for the NSF instance. In addition, the NSF Operation Manager is responsible for the dynamic management of the pool of NSF instances by negotiating with the Developer's Management System and by load balancing the entire NSF instances.

Packet Forwarding Header / Encapsulation: The Packet Forwarding Header is used to forward packets from one NSF to another for further inspection. The former NSF (ie, source NSF) constructs a Packet Forwarding Header with an NSF profile of the latter NSF (ie, target NSF), and delivers the packet to the NSFF. The required field may include an action code, a number of metadata, and metadata. In this case, the metadata may include a part or all of the NSF profile, and may be referred to as a spec info field in a Packet Forwarding Header to be described later.

Network Security Function Forwarder (NSFF) (or Security Function Forwarder (SFF)): When traffic is forwarded from the NSF, the NSFF is connected to one or more connections according to the information passed within the packet forwarding encapsulation. Means a device that delivers traffic to NSF. Thus, the NSFF may pass traffic to another NSFF (the same or another type of overlay) and terminate the overlay check.

Hereinafter, the basic operation of the NSF-triggered traffic steering architecture and traffic steering proposed by the present invention will be described. In addition, it examines each component of the architecture in detail.

Referring to FIG. 1, an NSF-triggered traffic steering architecture according to the present invention may be referred to as an I2NSF user (or user device), a network operator management security controller, or simply a security controller. May be configured as a vendor's management system (VMS), an NSF (or NSF device), and an NSF forwarder (NSFF) (or NSFF device). In addition, the Network Operator Management Security Controller may include an NSF Operation Manager (or NSF Operation Manager device).

The architecture according to FIG. 1 supports composite inspection of a packet being transmitted. According to the inspection result of each NSF stored in the Packet Forwarding Header, the traffic packet may be steered to another NSF for detailed analysis.

It can reflect the policies and settings for high-level advanced inspections from I2NSF users (or I2NSF clients) that are components of existing I2NSF frameworks.

In addition, the architecture proposed in the present invention can provide load balancing, automatic NSF instance creation and supplemental NSF instance removal.

To achieve this design goal, multiple components can be integrated into the existing I2NSF framework.

Hereinafter, each component will be described.

I2NSF User: An I2NSF user represents an administrator (or administrator device) of an enterprise network that receives network services through the network operator's infrastructure.

I2NSF users also need to use network security services to protect enterprise network traffic from various malicious attacks. In order to request a security service, an I2NSF user may specify a high-level security policy of a desired security service and notify a high-level security policy to a security controller.

In preparing high-level security policy, the I2NSF user does not consider the type of NSF (s) required to implement a security service or security policy rule configuration for each NSF (s). You may not.

In addition, the I2NSF user may be informed of the security event (s) occurring in the underlying NSF (s) by the Security Controller. By analyzing their security event (s), I2NSF users can identify new attacks and update (or create) high-level security policies to counter new attacks.

Network Operator Management Security Controller (Security Controller): The Security Controller is managed by the network operator.

One of the main roles of the Security Controller is to translate high-level security policies (or policy rules) from I2NSF users into low-level security policy rules for specific NSF (s). After the Security Controller receives the high-level security policy from the I2NSF user, the Security Controller may first determine the type of NSF (s) required to enforce the policy required by the I2NSF user. The Security Controller can then create a low-level security policy for each NSF (s) required. Eventually, the Security Controller can set the generated low-level security policy to each NSF (s).

In addition, the Security Controller can monitor running NSF (s) in the system and maintain various information about each NSF (s) (eg, network access information and workload status, etc.). . In addition, with the help of Vendor's Management System, the Security Controller can dynamically manage a pool of NSF instances through dynamic life-cycle management of the NSF instances.

NSF Operation Manager

NSF Operation Manager is responsible for the following three operations.

i) Maintain information about all available NSF instances, such as IP (Internet Protocol) addresses, supported transport protocols, NSF profiles, and load status.

ii) a response to a query of available NSF instances received from NSFF to assist in performing advanced inspections associated with a given NSF profile.

iii) requesting the Developer's Management System for the removal of an existing NSF instance to avoid wasting resources or for the instantiation of a supplementary NSF instance to avoid service congestion.

As illustrated in FIG. 1, the NSF Operation Manager corresponds to a lower module of the Security Controller.

In more detail, each time a new NSF instance is registered, the Developer's Management System may deliver information of the registered NSF instance to the NSF Operation Manager. Accordingly, the NSF Operation Manager may maintain an information list of all available NSF instances.

In addition, the NSF Operation Manger may receive a request packet (eg, an NSF generation request packet) including an NSF profile (ie, security capability information) for advanced inspection from the NSFF. When the NSF Operation Manger receives a query of a specific NSF profile from the NSFF, the NSF Operation Manger can retrieve all available NSF instances that can apply that NSF profile. The best instance can be found using selection criteria such as NSF location and traffic load status. The search result (that is, the optimal instance) may be returned to the NSFF.

In addition, each NSF instance may periodically report its load status to the NSF Operation Manger. Based on this report, the NSF Operation Manger may update the information of the NSF instance. In addition, a pool of NSF instances can be managed by requesting the Developer's Management System for additional instantiation (ie, additional NSF instance creation) or elimination (demination / destruct) of the NSF instance. As a result, the NSF Operation Manger enables efficient resource utilization by preventing congestion and waste of resources.

Developer ’s Management System

Developer's Management System may be referred to as Vendor's Management System. Developer's Management System may be managed by a third-party security vendor that provides NSF (s) to network operators. There may be multiple Developer's Management System (s) from various security vendors.

According to the present invention, the Developer's Management System can be extended for additional functions as follows.

As mentioned above, based on the request of the NSF Operation Manager, the Developer's Management System may create new NSF instance (s) or eliminate / destruct existing NSF instance (s) that are no longer used. .

In other words, the NSF Operation Manager may request the Developer's Management System to create an additional NSF instance when the existing instance of the NSF is congested. On the other hand, if the number of instances for a particular NSF is too large, the NSF Operation Manager may request the Developer's Management System to remove some of the NSF instances.

In response to this request, the Developer's Management System may create and / or remove an NSF instance. After creating a new NSF instance or removing an existing NSF instance, the Developer's Management System can notify the NSF Operation Manager of the change.

NSF and NSF Forwarder (NSFF):

NSF (eg, firewall, DPI, Denial of Service (MIT) attack mitigator, etc.) performs security checks on network traffic according to security policy rules received from the Security Controller.

In particular, the NSF in the architecture according to the present invention is advanced security inspection (e.g., DPI and distributed denial of service attack mediators (DDoS) to different NSF types based on their security inspection results. Service) attack mitigator, for example, a firewall can trigger additional inspection of suspicious traffic using DPI.

In this case, in order to realize such advanced composite inspection, the NSFF may perform the transfer of suspicious traffic from the current NSF to the next NSF.

In FIG. 1, the NSFF is illustrated as a separate component from the Security Controller and the NSF, but the present invention is not limited thereto. In other words, NSFF is a logical component that can be included in any of the Security Controller or NSF (ie, implemented together as a device).

Next, the interface of the architecture illustrated in FIG. 1 will be described.

Consumer-Facing Interface (CFI): As shown in FIG. 1, the CFI is located between the I2NSF user and the Security Controller, and the CFI is the interface to the I2NSF system of the user. This design hides the details of the underlying NSF (s) and gives the user only an abstract view of the NSF (s).

The main purpose of this interface is to allow users to request security services from the I2NSF system. It is also for the Security Controller to forward security alerts received from the underlying NSF (s) to the user via this CFI. By analyzing the alerts received, users can identify new attacks and update (or create) high-level security policies to counter new attacks.

NSF-Facing Interface (NFI): The NFI is located between NSFF (s) and Security Controllers and / or between NSF (s) and Security Controllers.

The main purpose of NFI is to provide a standardized interface for controlling and managing NSF (s) from various security solution vendors by decoupled security management techniques from NSF (s). NFI is independent of the details of the NSF (s) (eg, vendor, form factor, etc.). Therefore, when setting security policy rules to NSF, the Security Controller does not need to consider vendor specific differences and / or form factors of NSF.

Basically, through the NFI interface, the Security Controller can deliver a flow-based security policy to each target NSF in order to enforce the high-level security policy by the I2NSF user. For the purpose of remote maintenance, the Security Controller may trigger a control command to the NSF (s) via the NFI interface.

Each NSF can also use the NFI interface to periodically inform the Security Controller of its current status (eg, workload level, congestion, etc.). In addition, whenever a security event / alarm occurs on the NSF, the NSF may report it to the Security Controller via the NFI interface.

Each NSFF may receive forwarding information of the NSF running in the system through the NFI interface from the Security Controller. In this case, when the NSFF does not have forwarding information for delivering a given traffic, the NSFF may transmit a query of information to the Security Controller through the NFI interface.

Registration Interface (RI): As shown in FIG. 1, the RI is located between the Security Controller and the Developer's Management System. The primary purpose of RI is to perform dynamic life-cycle management of NSF instances and to register new NSF instances on the system.

If a new NSF is required in the system, the Security Controller can request the Developer's Management System to create a new NSF. In this case, the request of the Security Controller includes a profile of the requested NSF instance, and this profile may specify a security capability and a service capacity to be provided by the NSF instance.

When this request is received, the Developer's Management System creates a new NSF instance that satisfies the requested NSF profile and tells the Security Controller the network access information (eg, Internet Protocol) of this new NSF instance. Address, port number, etc.). The network access information can be used as a unique identifier of a new NSF instance in the system.

On the other hand, if the Security Controller determines that a particular existing NSF instance is no longer needed, the Security Controller can request the Developer's Management System to destruct the NSF instance. This destruction request may include a unique identifier of the NSF instance to be removed.

Hereinafter, the NSF-Triggered Traffic Steering will be described.

2 illustrates an existing service function chain architecture.

Service Function Chain / Chaining (SFC) is a technology that enables this by steering traffic through multiple service functions (eg, NSF).

(Step 1) SFC configuration & management for traffic (ie, packet) is predefined.

(Step 2) The traffic (i.e., packet) introduced into the I2NSF architecture is first classified using the predefined SFC configuration & management. That is, the service function path (SFP) for determining which NSF the traffic is inspected is determined. In FIG. 2, it is assumed that the corresponding traffic is inspected through NSF1 and then the SFP that is inspected through NSF2 is determined.

(Step 3) Traffic is traffic steered through the determined SFP. That is, the traffic is delivered to the NSF1 via a service function forwarder (SFF) according to the determined SFP.

(Step 4) After the inspection is performed by NSF1, the traffic is forwarded to NSF2 via SFF. At this time, the SFP determined for the corresponding traffic is also delivered.

As such, when traffic flows into the I2NSF architecture, the SFP for the traffic is determined according to a predefined SFC configuration & management.

On the other hand, within the I2NSF architecture according to the present invention, the inspection path of traffic (that is, the path of NSF) is not predetermined and is determined dynamically.

The NSF in the I2NSF architecture according to the present invention performs advanced security inspection (i.e., advanced security inspection) (e.g. DPI and DDoS attack mitigation) to different NSF types based on its security inspection results. Can trigger. For example, a firewall can use DPI to trigger further inspection of suspicious packets.

That is, as shown in FIG. 3, the NSF can dynamically determine which advanced security action should be performed during DPI and DDos Mitigator based on the forwarder (FW) based on its security check result. have.

Hereinafter, an information model (IM) and data model (DM) for a standardized interface and a procedure for setting up a standardized interface to various NSF (s) by defining IM and DM are described. Examine.

In I2NSF, an information model (IM) and a data model (DM) can be defined to set up a standardized interface to NSF (s) of various security solution vendors.

Within the I2NSF system, various NSF (s) can be classified into one or more categories according to security capabilities. IM may be defined for each category of NSF (s). The main purpose of an IM is to define a comprehensive model to represent security policy rules for NSF (s) in the same category. For this purpose, as in the example of FIG. 4, the IM defines all required data items based on the concept of Event-Condition-Action (ECA) rules, and hierarchically structures the data items. It can be classified according to its characteristics.

In the next step, the content defined in the IM is actually implemented, and the result is referred to as a data model (DM). For example, YANG (Yet Another Next Generation) data modeling language may be used for DM implementation.

After the DM is implemented, each related NSF may be pre-configured with the implemented DM.

When the Security Controller needs to set an NSF with a new security policy rule, the Security Controller can express the security policy rule according to a specific format in the DM.

For example, I2NSF can use extensible markup language (XML) to encode security policy rules, and XML-encoded security policy rules can use the Network Configuration Protocol (NETCONF). May be passed to the NSF (s).

After the XML encoded security policy rule is received, the NSF can decode the received security policy rule based on a matching DM that is already pre-set, and extract the content from the received security policy rule. As a result, the NSF can register the received content in its policy rule table.

In order to standardize CFI and RI, the same concepts and procedures of IM and DM can be applied.

As a result, in the I2NSF architecture according to the present invention, steps 1 to 3 may be skipped compared to the conventional SFC approach illustrated in FIG. 2. In other words, in the first step of defining SFC configuration & management for traffic (i.e., packet), the traffic (i.e., packet) introduced in the I2NSF architecture is defined in the predefined SFC configuration and management (SFC configuration). step 2 of classifying the traffic for the first time using the & management and step 3 of traffic steering through the determined SFP can be omitted.

In other words, the approach that is friendly to the SFC architecture is an existing standard and is suitable for applying static service functional paths. In contrast, the proposal of the present invention, which is friendly to the I2NSF framework, does not predefine NSF path establishment and management. Thus, there is an advantage that no classifier and initial classification are required. In addition, there is an advantage that no re-classification is required.

As described above, the NSF in the I2NSF architecture according to the present invention may trigger advanced security actions (e.g. DPI and DDoS attack mitigation) with different NSF types based on their security check results. Can be. In the case of Figure 5, the traffic introduced in the I2NSF architecture is inspected by NSF1, NSF1 can trigger a security check of NSF2 based on its security check results, NSF2 based on the security check results of NSF3 It can trigger a security check, and NSF3 can trigger a security check of NSF4 based on its security check results.

When triggering an advanced security action, NSF can now add metadata to the suspicious packet, which describes the security capabilities required for the advanced security action. The current NSF forwards the packet to the NSFF for delivery to the next NSF.

NSFF performs a function (that is, traffic steering) of transmitting a packet from one NSF instance to another NSF instance.

For traffic forwarding / steering, the NSFF (or NSF Operation Manager) may maintain a forwarding information table of available NSF instances in the system. After receiving the packet to forward, the NSFF may first search the table for the NSF instance that matches the required security capability specified in the metadata added to the packet.

The NSFF can negotiate with the Security Controller (or NSF operation manager) which NSF instance is the next NSF instance for delivering packets. In other words, if the NSFF does not find any matching entry, the NSFF may send a query of the NSF instance to the Security Controller with the required security capability.

The Security Controller (or NSF operation manager) can also maintain a table of information (ie, NSF information table) of all currently running NSF instance (s) in the system.

Here, the information of the NSF instance may include one or more of NSF profile, delivery information (ie, IP address, VxLAN, etc.), NSF capability, and NSF load status.

When the Security Controller (or NSF operation manager) receives a query from the NSFF, the Security Controller (or NSF operation manager) can search the table for the NSF instance that matches the requested security capability.

The security controller (or NSF operation manager) may provide the NSFF with delivery information of the selected NSF instance. In other words, when the Security Controller (or NSF operation manager) finds a matching NSF instance, the Security Controller (or NSF operation manager) responds to the NSFF with forwarding information of the found NSF instance.

Otherwise, this means that there is no existing NSF instance with the required security capability in the system.

In this case, the Security Controller (or NSF operation manager) requests a dynamic instantiation (ie, NSF generation) or elimination from the developer's management system. In other words, the Security Controller (or NSF operation manager) may request the Developer's Management System to create a new NSF instance with the required security capability through the RI.

The Developer's Management System can reside in a third party domain (eg, an NSF vendor's cloud).

Developer's Management System can create NSF instance based on Security Controller's request. Afterwards, the Security Controller informs the NSFF of the forwarding information of the created NSF instance.

In addition, the Security Controller (or NSF operation manager) may request NSF instantiation or elimination from the Developer's Management System based on the current state of the NSF instance (ie, whether the load is heavy or unused).

In this case, the Developer's Management System can create additional NSF instances when existing NSF instances are congested, and can also remove one or more unused NSF instances.

As a result, the NSFF may forward the packet to the target NSF instance using forwarding information from its forwarding information table or received from the Security Controller.

Hereinafter, a packet forwarding header will be described in detail.

Since the Packet Forwarding Header is used to deliver the inspection result and necessary inspection to the NSFF, the length of the field may be variable as shown in FIG.

The Packet Forwarding Header may include a fixed Action or Action Code field, a SpecInfo Num field, and a variable Capability Information (SpecInfo) field (s). Can be.

The Action Code field may include a security check result for the packet.

"allow" if no abnormality in the security check result of the packet is allowed and forwarded to the destination. "Deny", if the security check results in the packet and additional security checks are required by another NSF, it may be "advanced" and forwarded to the destination as a result of the security check of the packet. It may contain a value of one of the " mirror "

The SpecInfo Num field indicates how many SpecInfo fields (ie, metadata) are included in a packet forwarding header.

Each SpecInfo field may include information on security capability required for the next security check. That is, it may include a part of the NSF profile. If a Packet Forwarding Header including a plurality of SpecInfo fields is attached to the packet, the packet may be delivered to the plurality of NSFs matching the service profile of the NSF in each SpecInfo field through the NSFF to perform additional inspection.

For example, the SepcInfo field may include "SYN flood mitigation (syn-flood-mitigate)", "UDP flood mitigation (udp-flood-mitigate)", etc., which are service profiles of the NSF.

SYN floods are a form of DoS attack in which an SYN request is sent to a target system in order to use sufficient server resources to prevent the attacker from responding to legitimate traffic. UDP flood attacks are a form of DoS attack that uses the User Datagram Protocol (UDP), a sessionless / connectionless computer networking protocol.

Hereinafter, a network security function forwarder (NSFF) (or a security function forwarder (SFF)) will be described in more detail.

NSFF is responsible for two functions:

Forward the incoming traffic / packet to the Network Security Sub-Module (ie NSF), as described in the I2NSF Information Model for NSF-facing Interface (NFI)

-Traffic / packet is forwarded to the matching NSF using NSF profile specified in Packet Forwarding Header.

NSFF first receives the incoming traffic / packet using the gateway function.

The NSFF attaches an outer encapsulation to the traffic / packet to deliver the traffic / packet to the Network Security Sub-Module (ie, NSF).

For example, the Network Security Sub-Module (ie, NSF) may correspond to a firewall that performs packet header inspection.

This Network Security Sub-Module attaches a Packet Forwarding Header between the outer encapsulation and the origin packet.

In addition, the NSF profile in the Packet Forwarding Header is specified so that the packet can be delivered to a Content Security Sub-Module or a Mitigation Sub-Module for advanced inspection.

Upon receiving a packet with a Packet Forwarding Header of a specific NSF profile from the Network Security Sub-Module, the NSFF searches for available NSF instances that provide network security services corresponding to (ie, matching) the NSF profile. The NSFF forwards the packet to the found NSF instance.

If the NSF determines that the packet requires additional inspection through another type of NSF, the NSF constructs a packet forwarding header specified in (ie, containing) the NSF profile of the advanced NSF, and assigns the header to the packet. Attach. The packet is then transmitted to the NSFF.

Upon receiving the packet, the NSFF checks the specified NSF profile in the packet forwarding header. The NSFF finds an NSF instance matching the NSF profile by negotiating with the NSF Operation Manager and delivers a packet to the corresponding NSF instance.

Look at two embodiments using the NSF-triggered Traffic Steering Framework according to the present invention.

(1) Enforcing Different NSFs Depending on a Packet Source's Trust Level

In the architecture according to the present invention, all packets coming into the architecture arrive at the NSFF for the first time.

Assume that the current security policy forces all incoming packets to be examined by the firewall by default. Therefore, NSFF forwards the received packet to the firewall instance.

The firewall can identify the source of traffic and evaluate the source's trust level.

For example, a firewall filter may first classify a network packet into secure packets, dangerous packets, and suspicious packets. As described above, by evaluating the trust level of the source, it can be classified into a secure packet, a dangerous packet, and a suspicious packet.

As shown in FIG. 7 (a), if traffic is received from a trusted source (or classified as a secure packet), traffic may simply be delivered to the destination without further inspection. .

On the other hand, when traffic is received from an untrusted source (or classified as a suspicious packet) as shown in FIG. 7 (a), the firewall sends a packet forwarding header including an NSF profile corresponding to the DPI. And a packet with a packet forwarding header attached to the NSFF.

When receiving a packet with a packet forwarding header attached from the firewall, the NSFF may forward the packet to the DPI instance.

The DPI instance may perform detailed checks on the payload of the received packet.

When a detailed check is performed on the payload of the packet by the DPI instance, when it is determined that the packet is a secure packet, the packet may be delivered to the destination via the NSFF.

As such, only suspicious packets can be inspected by the DPI module in the intrusion detection system.

At this time, the dangerous packet may be simply dropped (ie, dropped) by the firewall filter. This method can help improve the performance of intrusion detection systems by avoiding unnecessary analysis of packets that are already classified as safe or dangerous.

Although FIG. 7 (a) illustrates DPI as an NSF for additional inspection, this is only one example and the present invention is not limited thereto, and another NSF may be used.

On the other hand, when classifying a suspicious packet, the degree of suspicion may be divided into plural in consideration of the level of reliability of the source, and the degree / number of additional checks by the NSF may be determined according to the level of suspicion. Can be done. This will be described in more detail with reference to FIG. 8.

Referring to Figure 8 (a) looks at the flow of traffic.

(Phase 1) All packets coming into the I2NSF system first arrive at the NSFF.

(Step 2) The packet may be evaluated for a trust level by the firewall instance.

Looking at step 2 in more detail, NSFF forwards the received packet to the firewall instance.

In this case, when classifying a suspicious packet, a suspicious degree may be divided into a plurality in consideration of a level of reliability of a source. Thus, depending on the level of doubt, the degree / number of additional tests by the NSF may be determined. For example, suppose that the level of suspiciousness of a packet is divided into two levels, and the greater the degree of suspicion, the larger the level is determined. In this case, when the level of suspiciousness of the packet is 1 level as a result of classification of the packet by the firewall instance, additional inspection by IDS / IPS may be performed.

If the packet is classified as a suspicious packet and has a level of 1, the firewall attaches a packet forwarding header containing the NSF profile corresponding to the IDS / IPS to the packet, and attaches the packet forwarding header to the NSFF. Can return packet.

(Step 3) Next, the packet can be examined in detail by IDS / IPS.

In more detail with respect to step 3, upon receiving a packet with a packet forwarding header from the firewall, the NSFF may forward the packet to the IDS / IPS instance.

The IDS / IPS instance may perform detailed inspection on the received packet.

If a detailed packet is checked by the IDS / IPS instance and a secure packet is determined, the IDS / IPS instance may return the packet to the NSFF.

On the other hand, if a detailed inspection of the packet is performed by the IDS / IPS instance, and it is determined that the packet is not a secure packet, the IDS / IPS instance may drop the packet.

(Step 4) After receiving the packet from the IDS / IPS instance, the NSFF may forward the packet to a destination.

Referring to Figure 8 (b) looks at the flow of traffic.

(Phase 1) All packets coming into the I2NSF system first arrive at the NSFF.

In this case, when classifying a suspicious packet, a suspicious degree may be divided into a plurality in consideration of a level of reliability of a source. Thus, depending on the level of doubt, the degree / number of additional tests by the NSF may be determined. For example, suppose that the level of suspiciousness of a packet is divided into two levels, and the greater the degree of suspicion, the larger the level is determined. In this case, when the level of suspicion as a result of classification of the packet by the firewall instance is 2 levels, additional inspection by IDS / IPS, anti-spoofing, and DPI may be performed.

If the packet is classified as a suspicious packet and has a level of 2, the firewall attaches a packet forwarding header containing the NSF profile corresponding to the IDS / IPS to the packet and attaches the packet forwarding header to the NSFF. Can return packet.

(Step 3) Next, the packet can be examined in detail by IDS / IPS.

The IDS / IPS instance may perform detailed inspection on the received packet.

If a detailed inspection of the packet is performed by the IDS / IPS instance, and it is determined that the packet is a secure packet, the IDS / IPS instance corresponds to anti-spoofing to describe the next NSF to which the packet is delivered. The packet forwarding header including the NSF profile may be attached to the packet, and the packet with the packet forwarding header attached to the NSFF may be returned.

On the other hand, if a detailed check is performed on the packet by the IDS / IPS instance, and it is determined that the packet is not a secure packet, the IDS / IPS instance may drop the packet.

Next, the packet can be examined in detail by anti-spoofing.

In more detail with respect to step 4, upon receiving a packet with a packet forwarding header attached from the IDS / IPS, the NSFF may forward the packet to the Anti-Spoofing instance.

The anti-spoofing instance may perform detailed inspection on the received packet.

If, as a result of the detailed inspection of the packet by the anti-spoofing instance, it is determined that the packet is a secure packet, the anti-spoofing instance attaches a packet forwarding header including an NSF profile corresponding to the DPI to the packet. In addition, a packet with a packet forwarding header attached to the NSFF may be returned.

On the other hand, if a detailed inspection of the packet is performed by the anti-spoofing instance, and it is determined that the packet is not a secure packet, the anti-spoofing instance may drop the packet.

(Step 5) Next, the packet can be examined in detail by DPI.

In more detail with respect to step 5, upon receiving a packet with a packet forwarding header from Anti-Spoofing, the NSFF may forward the packet to the DPI instance.

The DPI instance may perform detailed inspection on the received packet.

If, as a result of the detailed inspection of the packet by the DPI instance, a secure packet is determined, the DPI instance may return the packet to the NSFF.

On the other hand, when a detailed inspection of the packet is performed by the DPI instance, when it is determined that the packet is not a secure packet, the DPI instance may drop the packet.

(Step 6) After receiving the packet from the DPI instance, the NSFF may deliver the packet to the destination.

(2) Effective Load Balancing with Dynamic NSF Instantiation

In large network domains, there are generally multiple NSF instances that provide various security services. In this case, a specific NSF instance may experience excessive traffic beyond its capability. In this case, it is required to allocate some of the traffic to another available instance of the same NSF.

If no additional instances of the same NSF are available, you need to create a new NSF instance and direct the following traffic to the new instance. By doing so, service congestion can be prevented and more efficient resource utilization can be achieved.

This process may be commonly referred to as load balancing.

In the architecture according to the present invention, the NSF Operation Manager can periodically monitor the traffic load status of available NSF instances.

In addition, according to the present invention, a new NSF instance may be dynamically created through the Developer's Management System.

This dynamic NSF instance creation can be combined with the traffic steering mechanism to eventually provide load balancing services.

The following describes the detailed process of load balancing when congestion occurs in a firewall instance.

(Step 1) The NSF Operation Manager detects that the currently available firewall instance has received too many requests. That is, it detects that excessive traffic has occurred in the firewall instance.

(Step 2) Currently, assume that no additional firewall instance is available.

Since no additional firewall instance is available, the NSF Operation Manager requests the creation of a new firewall instance that can provide the same security services to the Developer's Management System.

(Step 3) The Developer's Management System creates a new firewall instance and registers the information of the new firewall instance with the NSF Operation Manager.

The NSF Operation Manager updates the NSF information table to reflect the new firewall instance and informs NSF and NSFF of such updates.

According to the new forwarding information, the NSFF forwards the following traffic to the new firewall instance. As a result, the burden on existing firewall instances can be effectively alleviated.

Hereinafter, an example using the NSF-triggered Traffic Steering Framework according to the present invention will be described.

Hereinafter, two scenarios will be described.

Time-dependent Web Access Filtering

In this scenario, assume an I2NSF based corporate network system, and assume that a corporate manager wants to prevent employees from accessing social networking sites during office hours.

In this scenario, the corporate network administrator is an I2NSF user. The I2NSF user first specifies a high-level security policy that blocks employees' access to social networking sites during office hours.

For example, a high-level security policy may be specified, such as "blocking all access to social networking sites by employees from 9 am to 6 pm."

Administrator delivers high-level security policy to Security Controller through CFI.

When a high-level security policy is received, the Security Controller translates the high-level security policy into a low-level security policy rule. The Security Controller first accesses a database of IP address mappings in the corporate network system to figure out the IP addresses to be used by employees. Based on this information, the Security Controller creates a firewall rule that restricts access to social networking sites from employees' IP addresses. Firewall rules also contain information about working hours.

The Security Controller sets the security policy rule created through NFI to the firewall.

And when an employee attempts to access a social networking site using his computer during working hours, an access request packet is forwarded to the firewall.

The firewall examines the packet header and determines whether the packet is forwarded to the social networking site. For example, the source / destination IP address may be used to determine whether to be delivered to a social networking site.

The current time is checked to determine whether or not it is within working hours. If a packet meets two conditions, the firewall drops the packet to restrict access to the social networking site.

Optional security checks for suspicious Voice over Internet Protocol (VoIP) / VoLTE (Voice over Long Term Evolution) packets

This scenario relates to a mobile telecommunications service provider who wants to provide security services for their customer's VoIP / VoLTE calls.

In this scenario, an administrator of a mobile communications service network wants to provide security services to his customer's VoIP / VoLTE calls. The manager of this scenario is the I2NSF user. In addition, the I2NSF user specifies (highest) a high-level security policy rule to apply to an incoming VoIP / VoLTE packet.

For example, "Security check is performed on packets of VoIP / VoLTE calls initiated by an unusual country at night to determine whether they are malicious, and reports detected malicious calls to an administrator." A high-level security policy can be specified. The administrator sends a high-level security policy rule to the Security Controller.

When receiving a high-level security policy rule from an administrator, the Security Controller translates the country name in the level security policy rule to the IP address range. The Security Controller creates a firewall rule to determine whether the VoIP / VoLTE call is suspicious by checking the source address and destination address of the call packet and configures the generated rule in the firewall instance. do.

In addition, the Security Controller generates DPI rules for checking various fields of VoIP / VoLTE packets corresponding to malicious calls, and transmits those rules to the DPI instance.

As shown in FIG. 10, after the VoIP / VoLTE packet arrives at the mobile service provider's network, the VoIP / VoLTE packet is forwarded or mirrored to the firewall. Based on the rules set by the Security Controller, the firewall determines whether this traffic corresponds to an unusual call pattern.

If this traffic is unusual and suspicious, the firewall triggers DPI for more detailed security checks on various fields of the VoIP / VoLTE packet.

For example, NSFF 1 may attach a packet forwarding header to a packet. The packet forwarding header may include a T field (the Action Code field in FIG. 6 above), an N field (SpecInfo Num field), and a Spec field (SpecInfo 0 ... n field). NSFF 1 may set the value of the T field in the Packet Forwarding Header to one of "advanced" and "mirror", and the Spec field may be set to an NSF profile to be additionally checked. have. If the T field is set to "advanced" and the Spec field is set to DPI profile, the corresponding traffic packet may be delivered in DPI via NSFF.

If the T field is set to "mirror" and the Spec field is set to DPI profile, the incoming packet is delivered to the intranet as shown in FIG. 11 and the packet copied through mirroring (copying). May be delivered in DPI via NSFF.

As shown in FIG. 12, the DPI checks various fields of the received VoIP / VoLTE packet based on the rule of the VoIP / VoLTE packet in the security policy rule table, and determines whether the call is malicious. As a result of the DPI determining, if it is determined to be a malicious traffic packet, the corresponding traffic packet may be dropped.

If the call is malicious as shown in FIG. 13, the DPI may notify the I2NSF user of the malicious operation detected through the NFI and the CFI. That is, DPI may notify NSF Operation Manager of malicious operation through NFI, and NSF Operation Manager may notify I2NSF user of malicious operation through CFI.

Referring to FIG. 14, the NSF performs a security check on packets introduced to a system supporting traffic steering (S1401).

At this time, the packet introduced into the system may be received by the NSFF and delivered to the NSF by the NSFF.

Based on the result of the security check, the NSF determines whether an additional check by another NSF is necessary (S1402).

The NSF may classify a packet into a secure packet, a dangerous packet, and a suspicious packet according to a trust level of a source of the packet.

If a packet is classified as a secure packet, it can be delivered to the destination of the packet without further security checking through another NSF. Alternatively, if a packet is classified as a dangerous packet, the packet may be dropped. Alternatively, if a packet is classified as a suspicious packet, the packet may be delivered to the NSFF with a packet forwarding header attached thereto.

If additional check is needed, the NSF attaches a packet forwarding header to the packet for invoking the additional check (S1403).

In this case, the packet forwarding header may include information on a security capability required for the additional check.

More specifically, the packet forwarding header may include an action code field including a result of a security check of a packet, a capability information field including security capability information required for further inspection, and a number field of capability information indicating the number of capability information fields. It may include.

The NSF transmits the packet with the packet forwarding header to the NSFF (S1404).

Referring to FIG. 15, a device 1500 in an NSF-triggered traffic steering system may include a processor 1501, a memory 1502, and a communication module 1503. ).

The device 1500 in the NSF-triggered traffic steering system may correspond to the NSF, NSFF, Security Controller, NSF Operation Manager, Developer's Management System, and I2NSF user.

The processor 1501 implements the functions, processes, and / or methods proposed in FIGS. 1 to 14. The memory 1502 is connected to the processor 1501 and stores various information for driving the processor 1501. The communication module 1503 is connected to the processor 1501 and transmits and / or receives a wired / wireless signal.

The memory 1502 may be inside or outside the processor 1501 and may be connected to the processor 1501 by various well-known means.

The embodiments described above are the components and features of the present invention are combined in a predetermined form. Each component or feature is to be considered optional unless stated otherwise. Each component or feature may be embodied in a form that is not combined with other components or features. It is also possible to combine some of the components and / or features to form an embodiment of the invention. The order of the operations described in the embodiments of the present invention 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 the claims may be combined to form an embodiment by combining claims that do not have an explicit citation relationship in the claims or as new claims by post-application correction.

Embodiments according to the present invention may be implemented by various means, for example, hardware, firmware, software, or a combination thereof. In the case of a hardware implementation, an embodiment of the present invention may include one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), 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 invention may be implemented in the form of a module, procedure, function, etc. that performs the functions or operations described above. The software code may be stored in memory and driven by the processor. The memory may be located inside or outside the processor, and may exchange data with the processor by various known means.

It will be apparent to those skilled in the art that the present invention may be embodied in other specific forms without departing from the essential features of the present invention. Accordingly, the above detailed description should not be construed as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.

The present invention can be applied to various systems for providing a security service.

Claims

In a system that supports traffic steering triggered by a network security function (NSF),

Perform a security check on the packet introduced into the system, determine whether an additional check by another NSF is necessary based on the result of the security check, and if the additional check is required, call the additional check. A first NSF attaching a packet forwarding header to the packet and transmitting a packet with the packet forwarding header attached to an NSF forwarder (NSFF); And

And a NSFF for forwarding the packet to the second NSF when searching for a second NSF having the security capability required for the additional check included in the packet forwarding header.
The method of claim 1,

The packet forwarding header may include an action code field including a result of the security check of the packet, a capability information field including security capability information required for the additional inspection, and a number field of capability information indicating the number of the capability information fields. Including traffic steering system.
The method of claim 1,

Packets introduced into the system are received by the NSFF and forwarded by the NSFF to the first NSF.
The method of claim 1,

The packet is classified by the first NSF into a secure packet, a dangerous packet and a suspicious packet according to a trust level of the source of the packet. Steering system.
The method of claim 4, wherein

And when the packet is classified as a secure packet, it is passed through another NSF to the destination of the packet without further security checking.
The method of claim 4, wherein

And if the packet is classified as a dangerous packet, the packet is dropped.
The method of claim 4, wherein

And when the packet is classified as the suspicious packet, the packet is attached to the packet forwarding header and forwarded to the NSFF.
The method of claim 1,

The traffic steering system further comprises an NSF operation management for managing a list of information for all available NSFs.
The method of claim 8,

If it fails to discover the second NSF, the NSFF sends an NSF generation request packet containing the security capabilities required for the further inspection to the NSF operations manager and for the third NSF generated from the NSF operations manager. Receiving the information, forwarding the packet to the third NSF,

The NSF operations manager selects the third NSF having the security capability required for the further inspection in consideration of the traffic load status of each NSF in the information list, and transmits information about the third NSF to the NSFF. Traffic steering system.
The method of claim 9,

If there is no NSF in the information list with the security capability required for the further inspection,

A traffic steering system requesting a developer's management system to create an NSF with the security capabilities required for the further inspection.
The method of claim 8,

The NSF operations manager monitors traffic load status of all available NSFs,

And upon detecting that excessive traffic is generated for a specific NSF, requesting a developer's management system to generate a new NSF having the same security capability as that of the excessive traffic generated NSF.
The method of claim 8,

The NSF operations manager monitors traffic load status of all available NSFs,

Detecting that a particular NSF is not used, requesting a developer's management system to remove the unused NSF.
In the method for the network security function (NSF) to perform traffic steering (traffic steering),

Performing a security check on packets introduced to the system supporting the traffic steering;

Determining whether further inspection by another NSF is necessary based on a result of the security inspection;

If the additional check is needed, attaching a packet forwarding header to the packet to invoke the additional check; And

Transmitting the packet with the packet forwarding header attached thereto to an NSF forwarder (NSFF).

The packet forwarding header includes information about the security capability required for the further inspection.
The method of claim 13,

The packet forwarding header may include an action code field including a result of the security check of the packet, a capability information field including security capability information required for the additional inspection, and a number field of capability information indicating the number of the capability information fields. Including traffic steering method.
The method of claim 13,

Traffic classified by the first NSF into a secure packet, a dangerous packet, and a suspicious packet according to a trust level of a source of the packet. Steering way.