WO2018169293A1 - 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치 - Google Patents

트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치 Download PDF

Info

Publication number
WO2018169293A1
WO2018169293A1 PCT/KR2018/002956 KR2018002956W WO2018169293A1 WO 2018169293 A1 WO2018169293 A1 WO 2018169293A1 KR 2018002956 W KR2018002956 W KR 2018002956W WO 2018169293 A1 WO2018169293 A1 WO 2018169293A1
Authority
WO
WIPO (PCT)
Prior art keywords
nsf
packet
security
information
i2nsf
Prior art date
Application number
PCT/KR2018/002956
Other languages
English (en)
French (fr)
Inventor
정재훈
현상원
우상욱
여윤석
Original Assignee
성균관대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 성균관대학교 산학협력단 filed Critical 성균관대학교 산학협력단
Publication of WO2018169293A1 publication Critical patent/WO2018169293A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present invention relates to a system for providing a security service, and more particularly, to a method and system for traffic steering triggered in more detail, and an apparatus therefor.
  • NFV Network Functions Virtualization
  • An object of the present invention is to propose a triggered (NSF-triggered) traffic steering framework.
  • a packet forwarding method of a network security function (NSF) forwarder is the step of receiving the packet from a first NSF that performs a security check on the packet, wherein the packet is a packet for invoking an additional check.
  • Receiving the packet comprising a forwarding header; And 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.
  • NSF network security function
  • the packet forwarding header may include an operation 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 of.
  • the second NSF if the second NSF is not detected, transmitting an NSF generation request packet including a security capability required for the additional inspection to an NSF operations manager; And forwarding the packet to the third NSF when receiving the information on the third NSF generated from the NSF operation manager.
  • the NSF operations manager maintains a list of information about all available NSFs, wherein the third NSF has the security capability required for the further inspection in consideration of the traffic load status of each NSF in the information list. Select, and transmit information on the third NSF to the NSFF.
  • the NSF operations manager monitors the traffic load status of all available NSFs, and if it detects that excessive traffic is generated for a particular NSF, then the developer's management system sends an NSF with the excessive traffic.
  • the NSF Operations Manager monitors the traffic load status of all available NSFs and, upon detecting that a particular NSF is not used, requests a developer's management system to remove the unused NSFs. , Packet forwarding method.
  • the network security function (NSF) forwarder includes a communication module for communicating data; And a processor for controlling the communication module, the processor receiving the packet from a first NSF that performs a security check on the packet, the packet including a packet forwarding header for invoking an additional check; And when searching for a second NSF having the security capability required for the additional check included in the packet forwarding header, the packet may be delivered to the second NSF.
  • NSF network security function
  • the packet forwarding header may include an operation 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.
  • NSF forwarder containing a number field.
  • the processor is further configured to: send an NSF generation request packet to the NSF Operations Manager that includes the security capability required for the additional check if the second NSF is not discovered; And forwarding the packet to the third NSF when receiving the information on the third NSF generated from the NSF operations manager.
  • the NSF operations manager maintains a list of information about all available NSFs, wherein the third NSF has the security capability required for the further inspection in consideration of the traffic load status of each NSF in the information list. May be selected and information about the third NSF may be transmitted to the NSFF.
  • the NSF operations manager monitors the traffic load status of all available NSFs, and if it detects that excessive traffic is generated for a particular NSF, then the developer's management system sends an NSF with the excessive traffic. You can request the creation of a new NSF with the same security capabilities.
  • the NSF operations manager may request a developer's management system to remove the unused NSFs. have.
  • traffic steering between NSFs is enabled, and composite inspection of network traffic is possible through various types of NSFs.
  • NSFs network security functions
  • NSF may support various network conditions and security requirements.
  • FIG 1 illustrates an I2NSF (Interface to Network Security Functions) system according to an embodiment of the present invention.
  • I2NSF Interface to Network Security Functions
  • FIG. 2A illustrates the configuration of an I2NSF system for traffic steering triggered by NSF in accordance with an embodiment of the present invention.
  • FIG. 2B illustrates a configuration of an I2NSF system for an SFC according to an embodiment of the present invention.
  • FIG. 3 illustrates a packet forwarding header according to an embodiment of the present invention.
  • FIG 4 illustrates an NSF-face interface according to one embodiment of the present invention.
  • FIG 5 illustrates an NSF query message according to an embodiment of the present invention.
  • FIG 6 illustrates an NSF response message according to an embodiment of the present invention.
  • FIG. 7 is a diagram illustrating the flow of traffic in the I2NSF system according to an embodiment of the present invention.
  • FIG. 8 is a diagram illustrating a load balancing method in an I2NSF system according to an embodiment of the present invention.
  • FIG. 9 illustrates a block diagram of a network device according to an embodiment of the present invention.
  • FIG. 10 is a flowchart of a data transfer method of a network device according to an embodiment of the present invention.
  • I2NSF Interface to Network Security Functions
  • 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.
  • NSF network security function
  • NSF network security function
  • IM information model
  • the current design of the I2NSF framework has the disadvantage of not fully considering network traffic steering to enable continuous inspection through multiple NSFs.
  • the specification proposes an architecture that integrates additional components for traffic steering through NSF into the I2NSF framework.
  • a user-level policy of NSF-triggered traffic steering triggered by NSF is interpreted as a low-level policy.
  • NSF-triggered a user-level policy of NSF-triggered traffic steering triggered by NSF (or NSF-triggered) is interpreted as a low-level policy.
  • the user perspective policy may be referred to as a high level policy.
  • the present specification tracks the available NSF instance (s) and information (eg network information and workload) of the NSF instance (s), and identifies the NSF instance to use for a given security function. You can decide.
  • a network security function forwarder (or a security function forwarder) may be required.
  • Network traffic steering may be required.
  • the NSFF may perform advanced inspection by interpreting inspection results from the NSF.
  • an additional packet header format for specifying a security check result and an advanced check request may be defined.
  • the invention disclosed herein has largely the following objects / effects.
  • the NSF-triggered traffic steering architecture 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).
  • NSF-triggered traffic steering allows network traffic to be steered through a plurality of required NSF (s) based on a triggering policy.
  • the I2NSF Information Model (IM) for the NSF-facing interface requires the NSF to call another NSF for further inspection based on its inspection results.
  • the NSF-triggered traffic steering architecture enables traffic forwarding from one NSF to another.
  • the NSF-triggered traffic steering architecture provides incoming traffic through the NSF instances available by leveraging a flexible traffic steering mechanism. provide load balancing of traffic). For this purpose, if there is an excessive request for an NSF, the NSF-triggered traffic steering architecture can perform dynamic instantiation of the NSF (eg, create a new NSF that can perform its security functions). .
  • Network Security Function Means a function for handling a specific packet or a device therefor.
  • the NSF may operate at various layers of various protocol stacks (eg, network layer or other Open System Interconnection (OSI) layer, etc.).
  • OSI Open System Interconnection
  • NSFs For example, as examples of NSFs, firewalls, intrusion prevention systems (IPS) / intrusion detection systems (IDS), deep packet inspection (DPI), application visibility and Application Visibility and Control (AVC), Network Virus and Malware Scanning, Sandbox, Data Loss Prevention (DLP), Distribute Denial of Service (DDoS) mitigation, A transport layer security (TLS) proxy, anti-spoofing, and the like may be included.
  • IPS intrusion prevention systems
  • IDPS deep packet inspection
  • AVC application visibility and Application Visibility and Control
  • AVC Application Visibility and Control
  • DLP Data Loss Prevention
  • DLP Distribute Denial of Service
  • TLS transport layer security
  • anti-spoofing and the like
  • the NSF according to an embodiment of the present invention may be implemented in any of the above-described 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
  • Advanced Inspection / Action As with the I2NSF Information Model (IM) for NFI-facing interface (NFI), advanced inspection / action is based on the NSF's own inspection results. It means to invoke additional checks.
  • IM I2NSF Information Model
  • NFI NFI-facing interface
  • NSF Profile represents the inspection capabilities of the NSF. Each NSF may have its own NSF profile to specify the type of security service it provides, its resource capabilities, and so on.
  • An NSF Operation Manager refers to a device that continuously manages information and status of an NSF instance and provides NSF network access information to support advanced inspection requests.
  • the information of the NSF instance may include a supported transport protocol, an Internet Protocol (IP) address, and a location for the NSF instance.
  • IP Internet Protocol
  • the NSF Operations Manager is also responsible for the dynamic management of the pool of NSF instances by negotiating with the Developer's Management System and by load balancing across all NSF instances.
  • a packet forwarding header is used to forward a packet from one NSF to another for further inspection.
  • the former NSF i.e. source NSF
  • the required field may include an action code, a number of metadata, and metadata.
  • the metadata may include 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 one or more depending on the information carried in the packet forwarding encapsulation. A device (or forwarder) that delivers traffic to a connected NSF. Thus, the NSFF may forward traffic to another NSFF (same or another type of overlay) and terminate the overlay check.
  • NSFF Network Security Function Forwarder
  • SFF Security Function Forwarder
  • the I2NSF framework allows users of an I2NSF system (e.g., an application, overlay or cloud network management system, or enterprise network administrator or management system) to inform the I2NFS system which I2NSF functions should be applied to which traffic (or traffic patterns). Requires a standard interface.
  • the I2NSF system can recognize this standard interface as a set of security rules for monitoring and controlling the behavior of different traffic.
  • the I2NSF framework also provides a standard interface for monitoring flow-based security functions where users are hosted and managed by different administrative domains.
  • FIG 1 illustrates an I2NSF (Interface to Network Security Functions) system according to an embodiment of the present invention.
  • I2NSF Interface to Network Security Functions
  • FIG. 1 is a basic architecture / framework of an I2NSF system, which is illustrated in terms of a network operator management system. Thus, FIG. 1 does not assume any particular management architecture for NSFs or how NSFs are managed (at the developer side). In particular, the network operations management system does not participate in NSF data plane activity. In general, all I2NSF interfaces may require at least mutual authentication and authorization for use.
  • an 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).
  • NSF Network Security Function
  • the I2NSF user communicates with the network operations management system via the I2NSF Consumer-Facing Interface.
  • the network operations management system communicates with the NSF (s) via an I2NSF NSF-Facing Interface.
  • the developer management system communicates with the network operations management system through the I2NSF Registration Interface.
  • each component (I2NSF component) and each interface (I2NSF interface) of the I2NSF system will be described.
  • An I2NSF user requests information (eg, information from NSF) from another I2NSF component (eg, network operations management system) and / or a security service (eg, network security) provided by another I2NSF component (eg, developer management system). Service) is an I2NSF component.
  • the I2NSF user may be an overlay network management system, an enterprise network administrator system, another network domain administrator, or the like. I2NSF users may be referred to as I2NSF clients.
  • the object performing the role assigned to this I2NSF user component may be referred to as an I2NSF consumer.
  • An example of an I2NSF consumer is the need to dynamically inform an underlay network to allow, rate-limit, or reject flow based on a particular field of a packet over a time span.
  • Video-conference network manager, enterprise network administrators and management systems that need to request provider networks to enforce specific I2NSF policies for specific flows,
  • An IoT management system may be included that sends a request to the underlay network to block flows that match a set of specific conditions.
  • I2NSF users can create and deploy high-level security policies. Specifically, the I2NSF user needs to use a network security service to protect network traffic from various malicious attacks. To request this security service, the I2NSF user can create a user perspective security policy for the security service he wants and notify the network operations management system.
  • the I2NSF user in preparing the user perspective security policy, the I2NSF user considers the types of NSF (s) required to realize a security service or security policy rule configuration for each NSF (s). You can't.
  • the I2NSF user may be informed of security event (s) occurring in the underlying NSF (s) by the network operations management system.
  • security event s
  • I2NSF users can identify new attacks and update (or create) user perspective security policies to cope with the new attacks.
  • I2NSF users can define, manage, and monitor security policies.
  • a network operations management system is a component that acts as a collection and distribution point for providing security, monitoring, and other operations.
  • the network operations management system may correspond to a security controller or may be a component including a security controller.
  • Such a network operations management system may be managed by a network operator and may be referred to as an I2NSF management system.
  • network operations management systems or security controllers
  • the network operations management system may receive the user perspective security policy from the I2NSF user and then first determine the type of NSF (s) required to enforce the policy required by the I2NSF user.
  • the network operations management system can then create a low-level security policy for each NSF (s) required.
  • the network operations management system may set the generated low level security policy to each NSF (s).
  • the network operations management system (or security controller) monitors the NSF (s) running in the I2NSF system, and provides various information about each NSF (s) (e.g., network access information and workloads). ), Etc.) can be maintained.
  • network operations management systems (or security controllers) can dynamically manage pools of NSF instances through dynamic life-cycle management of NSF instances with the help of developer management systems. have.
  • NSF is a logical entity or software component that provides security related services.
  • NFC eg, a firewall
  • the developer management system is an I2NSF component that sends information (eg, NSF's information) to other I2NSF components (eg, network operations management system) and / or provides security services (eg, network security services).
  • the developer management system may be referred to as Vendor's Management System.
  • An object performing 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 network operators. There may be multiple developer management system (s) from various security vendors.
  • I2NSF consumer-facing interface (simply, consumer-facing interface (CFI))
  • the CFI is an interface to the user's I2NSF system, located between the I2NSF user and the network operations management system. By designing this, the I2NSF system can hide the details of the underlying NSF (s) and provide only an abstract view of the NSF (s) to the user.
  • This CFI can be used to allow different users of a given I2NSF system to define, manage, and monitor security policies for specific flows in an administrative domain.
  • User perspective security policies (or policy rules) created by I2NSF users may be communicated to the network operations management system via this CFI.
  • security alerts by the NSF (s) may be communicated from the network operations management system to the I2NSF user via this CFI.
  • NFI is an interface located between the network operations management system (or security controller) and the NSF (s).
  • NFI 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.).
  • This NFI may be used to specify and monitor a flow-based security policy enforced by one or more NSFs.
  • the network operations management system may deliver a flow-based security policy to each flow-based NSF via an NFI interface in order to enforce a user perspective security policy by an I2NSF user.
  • flow-based NSF is an NSF that examines network flow according to a set of policies to enhance security characteristics.
  • This flow-based security by flow-based NSF means that packets are examined in the order in which they are received, and there is no modification to the packets according to the inspection process.
  • Interfaces for flow-based NSF can be classified as follows:
  • NSF Operational and Administrative Interface group of interfaces used by the I2NSF management system to program the operational state of the NSF; This interface group also includes administrative control functions. I2NSF policy rules represent one way of changing this interface group in a consistent manner. Since applications and I2NSF components need to dynamically control the behavior of the traffic they send and receive, much of the I2NSF effort is concentrated in this group of interfaces.
  • Monitoring Interface group of interfaces used by the I2NSF management system to obtain monitoring information from one or more selected NSFs; Each interface in this interface group can be a query or report based interface. The difference between the two is that the query based interface is used by the I2NSF management system to obtain the information, while the report based interface is used by the NSF to provide the information.
  • the functionality of this interface group can also be defined by other protocols such as SYSLOG and DOTS.
  • the I2NSF management system may take one or more actions based on the receipt of the information. This should be specified by the I2NSF policy rule. This interface group does not change the operational state of the NSF.
  • NFI may be developed using a flow-based paradigm.
  • a common trait of flow-based NSF is to process packets based on the content (eg header / payload) and / or context (eg session state and authentication state) of the received packet. This feature is one of the requirements for defining the behavior of an I2NSF system.
  • the I2NSF management system does not need to use all the functions of a given NSF, nor need to use all available NSFs.
  • this abstraction allows NSF features to be treated as building blocks by the NSF system.
  • developers are free to use the security features defined by NSF, which are vendor and technology independent.
  • I2NSF registration interface simple registration interface (RI)
  • RI is an interface located between the network operations management system and the developer management system. NSFs provided by different vendors may have different capabilities. Thus, in order to automate processes that take advantage of the different types of security capabilities offered by different vendors, it is necessary for vendors to have a dedicated interface for defining the functionality of their NSF. This dedicated interface may be referred to as an I2NSF Registration Interface (RI).
  • RI I2NSF Registration Interface
  • the NSF's capabilities can be preconfigured or dynamically retrieved through the I2NSF registration interface. If new features exposed to consumers are added to the NSF, the capabilities of those new features need to be registered in the I2NSF registry through this RI so that interested management and control entities know them. .
  • I2NSF system or architecture
  • traffic steering for NSF-triggered traffic steering will be described with reference to FIG. 2A.
  • each component of this architecture is described.
  • FIG. 2A illustrates the configuration of an I2NSF system for traffic steering triggered by NSF in accordance with an embodiment of the present invention.
  • the I2NSF system of FIG. 2A may further include a component for traffic steering triggered by NSF as compared to the I2NSF system of FIG. 1.
  • the I2NSF system of FIG. 2A may further include an NSF forwarder, that is, NSFF, to be described later.
  • NSF forwarder that is, NSFF
  • an I2NSF system for traffic steering triggered by an NSF may be referred to as an NSF-triggered traffic steering system or an NSF-triggered I2NSF system.
  • an NSF-triggered traffic steering system includes an I2NSF user, a security management system, and / or a security network.
  • the I2NSF user may include a user / app controller.
  • the security management system may include a security controller and a developer management system including an NSF operations manager.
  • the secure network may include NSFF (s) and NSF (s).
  • the NSF-triggered traffic steering system may support composite inspection of packets in transit. Depending on the check result of each NSF stored in the packet forwarding header, the traffic packet can be steered to another NSF for further detailed analysis.
  • I2NSF systems that are components of existing I2NSF frameworks (eg, the I2NSF framework of FIG. 1).
  • the NSF-triggered traffic steering system proposed herein may provide load balancing, automatic supplementary NSF instance creation, and unused NSF instance removal.
  • the I2NSF system of FIG. 2A may further include components such as NSFF and NSF Operation Manager, compared to the I2NSF system of FIG. The component may further perform additional actions for this.
  • the NSF Operations Manager is a major component of the NSF-triggered traffic steering system. As illustrated in FIG. 2A, the NSF Operations Manager corresponds to a submodule of the security controller. The NSF Operations Manager is responsible for the following three operations.
  • IP Internet Protocol
  • the developer management system may deliver information of the registered NSF instance to the NSF operations manager. Accordingly, the NSF Operations Manager can maintain a list of information of all available NSF instances.
  • the NSF operations manager may receive a request packet (eg, an NSF generation request packet) containing an NSF profile (eg, security capability information) for advanced inspection from the NSFF.
  • a request packet eg, an NSF generation request packet
  • an NSF profile eg, security capability information
  • the NSF Operations Manager can retrieve all available NSF instances that can apply that NSF profile. The NSF operations manager can then find the best instance using selection criteria such as location and load status. After finding the best instance, the NSF operations manager can return the search results to NSFF.
  • each NSF instance can periodically report its load status to the NSF Operations Manager. Based on these reports, the NSF Operations Manager can update the information of the NSF instance and manage the developer for additional instantiation of the NSF instance (ie, creation of additional NSF instances) or elimination / destruct of the NSF instance. You can manage the pool of NSF instances by asking the system. As a result, NSF Operations Manager enables efficient resource utilization by preventing congestion and waste of resources.
  • the developer management system can be extended for the following additional features:
  • the developer management system may create new NSF instance (s) or eliminate / destruct existing NSF instance (s) that are no longer used. .
  • the NSF operations manager may request the developer management system to create additional NSF instances when existing instances of the NSF become congested.
  • the NSF Operations Manager may ask the developer management system to remove some of the NSF instances.
  • the developer management system may create and / or remove an NSF instance.
  • the developer management system can notify the NSF operations manager of the change.
  • NSF Forwarder (NSFF)
  • NSFF may be included in a secure network.
  • NSFF is responsible for two functions:
  • NSF Network Security Sub-Module
  • the NSFF uses an gateway feature to receive incoming traffic / packets and to perform outer encapsulation to forward traffic / packets to the network security submodule (ie, NSF). Can be attached to traffic / packets.
  • the network security submodule ie, NSF
  • the network security submodule may be, for example, a firewall that performs packet header inspection.
  • This network security submodule may attach a packet forwarding header between the external encapsulation and the origin packet.
  • the NSF profile in the packet forwarding header can be specified so that the packet can be delivered to a Content Security Sub-Module or a Mitigating Sub-Module for advanced inspection.
  • the NSFF may search for available NSF instances that provide network security services corresponding (matched) to the NSF profile.
  • the NSFF may deliver a packet to the retrieved NSF instance.
  • the NSF may construct a packet forwarding header (including) that is specified by the NSF profile of the advanced NSF and attach the header to the packet. have.
  • the NSF may transmit the packet to the NSFF.
  • the NSFF Upon receiving the packet, the NSFF checks the NSF profile specified in the packet forwarding header. In addition, the NSFF may search for an NSF instance matching the NSF profile and forward a packet to the corresponding NSF instance by negotiating with an NSF operation manager.
  • the NSF eg, firewall, DPI, denial of service attack mitigator, etc.
  • the NSF performs security checks on network traffic according to security policy rules received from the security controller.
  • the NSF in the I2NSF system of FIG. 2 uses advanced security inspection (e.g., DPI and distributed denial of service attack mediators (DDoS) to different NSF types based on their security check results.
  • advanced security inspection e.g., DPI and distributed denial of service attack mediators (DDoS) to different NSF types based on their security check results.
  • DPI distributed denial of service attack mediators
  • DDoS distributed denial of service attack mediators
  • Service attack mitigator for example, a firewall may trigger additional inspection of suspicious traffic using DPI.
  • the NSFF may perform the transfer of suspicious traffic from the current NSF to the next NSF.
  • the NSFF is illustrated as a separate component from the security controller and the NSF, but the present invention is not limited thereto.
  • the NSFF is a logical component that can be included (ie, implemented together as one device) in either the security controller or the NSF.
  • I2NSF consumer-facing interface The CFI is the same as described above with reference to FIG.
  • NFI NSF-Directional 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.
  • 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 delivery information for delivering a given traffic, the NSFF may transmit a query of information to the security controller through the NFI interface.
  • the security controller can request the developer management system to create a new NSF through the RI interface.
  • the request of the security controller includes a profile of the requested NSF instance, which profile may specify a security capability and a service capacity to be provided by the NSF instance.
  • the developer management system When this request is received, the developer management system creates a new NSF instance that satisfies the requested NSF profile and, via the RI interface, tells the security controller the network access information of this new NSF instance (e.g. IP (Internet Protocol) address, port number, etc.).
  • the network access information can be used as a unique identifier of a new NSF instance in the system.
  • the security controller can request the developer management system to destruct the NSF instance via the RI interface.
  • This destruction request may include a unique identifier of the NSF instance to be removed.
  • FIG. 2B illustrates a configuration of an I2NSF system for an SFC according to an embodiment of the present invention.
  • the I2NSF system of FIG. 2B may further include components for the SFC as compared to the I2NSF system of FIG. 1.
  • the I2NSF system of FIG. 2B may further include a classifier and a service function forwarder (SFCC) to be described later.
  • SFCC service function forwarder
  • an I2NSF system for SFC may be referred to as an SFC-enabled I2NSF system.
  • an SFC-enabled I2NSF system includes an I2NSF user, a security management system, and / or a security network.
  • the security management system may include a security controller and developer management system including an SFC Policy Manager and an SFC Catalog Manager.
  • the secure network may include a classifier, SFF (s) and SF (s).
  • SFF classifier
  • SF SF
  • the SFC-enabled I2NSF system may support similar functionality as the NSF-triggered I2NSF system described above in FIG. 2A.
  • an SFC-enabled I2NSF system may support composite inspection of packets in transit. Depending on the check result of each SF, traffic packets can be steered to another SF for further detailed analysis.
  • I2NSF systems that are components of existing I2NSF frameworks (eg, the I2NSF framework of FIG. 1).
  • the SFC-enabled I2NSF system proposed herein may provide load balancing, automatic supplementary SF instance creation, and unused SF instance removal.
  • the I2NSF system of FIG. 2B may further include components such as classifier, SFF, SFC policy manager, and SFC catalog manager, as compared to the I2NSF system of FIG. The component of may further perform additional operations for this.
  • the SFC Policy Manager is a major component of the SFC-enabled I2NSF system. As illustrated in FIG. 2B, the SFC policy manager corresponds to a submodule of the security controller. The SFC Policy Manager is responsible for two things:
  • I2NSF client i.e. I2NSF user
  • low level SFC policy or configuration
  • the SFC policy manager may perform this additional function through the consumer-facing interface (CFI) and the NSF-facing interface (NFI).
  • CFI consumer-facing interface
  • NFI NSF-facing interface
  • the SFC policy manager may interpret the user perspective SFC policy / setting as a low-level policy / setting so that the classifier can comprehensible.
  • the SFC policy manager can quickly respond to the current state of SF to create new policies for flexible changes in traffic steering. For example, the SFC policy manager may create a new rule that forwards all subsequent packets to "firewall instance 2" instead of "firewall instance 1" if "firewall instance 1" is congested. Can be.
  • the SFC policy manager may obtain information about SF from the SFC catalog to generate an SF forwarding table.
  • the SFC policy manager may consider various criteria such as SFC policy, SF load status, SF physical location, and supported transport protocol.
  • the entry of the SF forwarding table may include a Service Path Identifier (SPI), a Service Function Path (SFP), a Service Index (SI), and next hop information. Examples of next hop information may include an IP address and supported transport protocols (eg, VxLAN, GRE).
  • This propagation table can be distributed as SFF (s) using either the Push or Pull method.
  • the SFC catalog manager corresponds to a submodule of the security controller.
  • the SFC Catalog Manager is responsible for three things:
  • IP Internet Protocol
  • iii) requests to the Developer's Management System for the removal of existing SF instances to avoid wasting resources or for the instantiation of supplementary SF instances to avoid service congestion.
  • the developer management system may transmit information of the registered SF instance to the SFC catalog manager. Accordingly, the SFC catalog manager can maintain a list of information of all available SF instances.
  • the SFC catalog manager can retrieve all available NSF instances applicable to that SFP. The SFC catalog manager can then return the search results to the SFC policy manager.
  • each SF instance can periodically report its load status to the SFC catalog manager. Based on these reports, the SFC Catalog Manager can update the information on the SF instance and manage developer elimination or further elimination / destruct of the SF instance (ie creating additional NSF instances). You can manage the pool of SF instances by asking the system. As a result, the SFC catalog manager enables efficient resource utilization by avoiding congestion and waste of resources.
  • the developer management system can be extended for the following additional features:
  • the developer management system may create new SF instance (s) or eliminate / destruct existing SF instance (s) that are no longer used. .
  • the SFC policy manager may ask the developer management system to remove some of the SF instances.
  • the developer management system may create and / or remove an NSF instance. And, after creating a new NSF instance or removing an existing NSF instance, the developer management system can notify the SFC catalog manager of the change.
  • a classifier is a logical component that can exist alone or as a submodule of another component.
  • the initial classifier is typically located at an entry point, such as a boundary router in the network domain, and performs an initial classification of all incoming packets according to the SFC policy given by the SFC policy manager.
  • Classification means determining which SFP a given packet must pass through. Once the SFP is determined, the classifier constructs a Network Service Header (NSF) that specifies that SPI and SI and attaches it to the packet.
  • NSF Network Service Header
  • an SFF may be included in a secure network.
  • SFF is responsible for two functions:
  • the SFF has a forwarding function and needs to find the next SF / SFF for incoming traffic.
  • the SFF may search the forwarding table to find next hop information corresponding to a given traffic. If the SFF finds the target entry in the forwarding table, the SFF may forward traffic to the next SF / SFF specified in the next hop information. If the SFF does not have an entry for a given packet, the SFF may request next hop information from the SFC policy manager using the SFF identifier, SPI and SI information.
  • the SFC policy manager responds to the SFF with next hop information, that is, the SFC policy manager forwards the next hop information to the SFF, and the SFF uses the response to update the forwarding table and forward traffic to the next hop.
  • SF may want to forward very suspicious packets to another SF for further security checks. As mentioned above, this may be referred to as an advanced security check.
  • this may be referred to as an advanced security check.
  • the SF may update the SPI field of the NSH in the packet to provide advanced security operation. Otherwise, if the classifier is present on its own, SF may attach the result of the packet inspection to the metadata field of the NSH and forward it to the source SFF.
  • the attached metadata may include a reclassification request to change the SFP of the packet to another SFP for more robust inspection. If the SFF receives traffic requiring reclassification, the SFF may forward the traffic to the classifier for which reclassification will be performed as a result.
  • the SFF is illustrated as a separate component from the security controller and the SF, but the present invention is not limited thereto.
  • SFF is a logical component that can be included (ie, implemented together as one device) in either the security controller or SF.
  • I2NSF system is the I2NSF system of FIG. 2A.
  • this is for convenience of description, and the same or similar description to the following description may be applied or mutatis mutandis even when the I2NSF system is the I2NSF system of FIG. 2B.
  • FIG. 3 illustrates a packet forwarding header according to an embodiment of the present invention.
  • the NSF may use the packet forwarding header to inform the NSFF of the result of the check and / or further advanced security checks required. Therefore, the packet forwarding header may have a variable length as shown in FIG. 3. Referring to FIG. 3, the packet forwarding header may include an action code field, a capability information number (SpecInfo Num) field, and / or at least one capability information (SpecInfo) field. Each field will be described below.
  • the Action Code field may include a security check result for the packet.
  • the Action Code field may include one of "allow”, “deny”, “advanced” and “mirror”.
  • the Action Code field may contain a value indicating "allow” if the packet is allowed to be delivered to the destination because there is no abnormality in the security check result of the packet, and an abnormality in the security check result of the packet is found.
  • a value indicating "deny” if the packet is not allowed to be delivered to its destination, or "advanced” if the packet's security check requires further security checks by another NSF.
  • a value indicating "mirror” if the security check of the packet allows it to be passed to the destination but requires further security check by another NSF. have.
  • the SpecInfo Num field indicates how many SpecInfo fields (ie, metadata) are included in a packet forwarding header.
  • the SpecInfo field may include information on a security capability required for the next security check.
  • each SpecInfo field may contain a portion of an NSF profile that describes the NSF's capabilities required for advanced security checks.
  • the value of the SepcInfo field may be "syn-flood-mitigate", "udp-flood-mitigate", or the like, which describes the service profile of the NSF.
  • SYN floods are a form of DoS attack in which an attacker sends a SYN request to a target system to use sufficient server resources so that the system does not respond 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.
  • UDP User Datagram Protocol
  • the packet When the packet forwarding header including the 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, and further inspection may be performed.
  • FIG 4 illustrates an NSF-face interface according to one embodiment of the present invention.
  • the NSF-facing interface may perform a major function for steering packets in an I2NSF system.
  • the NSF-direct interface includes an NSF query sub-model and an NSF response sub-model.
  • NSF query sub-model and an NSF response sub-model.
  • a query and response procedure of NSF delivery information using an NSF query message and an NSF response message will be described with reference to FIGS. 5 and 6.
  • FIG 5 illustrates an NSF query message according to an embodiment of the present invention.
  • the NSF may ask the NSFF to forward the packet to another NSF for advanced security checking of the packet.
  • the NSFF can send a query to the NSF Operations Manager via the NSF-Directional Interface.
  • This query may include an NSF profile that describes the security (capabilities) required for advanced inspection capabilities.
  • the NSF query message may include check result information.
  • the NSF profile basically represents the inspection capability of the NSF instance.
  • the NSF profile may include Packet Content-Matching Capability, Content-Matching Capability, Context-Matching Capability, Attack-Mitigation Capability, It may include capability information such as an action capability and a performance capability. Each will be described as follows.
  • Packet Content-Matching Capability refers to a kind of information or attribute obtained from a packet header or payload that can be used in a security policy. This capability information may be a packet L2 / L3 / L4 header, or any field or attribute in a special segment of the packet payload.
  • This capability is another category of security capabilities that apply to the application layer. By detecting content carried in traffic at the application layer, this capability implements a variety of security features, such as defense against intrusions, virus scanning, filtering of malicious URLs or junk mail, blocking illegal web access, or blocking malicious data retrieval ( realize)
  • Context-matching capability This capability refers to content information for the received packet. This capability may be user, schedule, region, target, status and direct information.
  • Attack-mitigation ability This ability is used to detect and mitigate various types of network attacks. For example, network attacks can be classified as DDoS attacks and single-packet attacks.
  • the NSF may provide security functionality by executing at least one operation. At least one operation includes at least some or all of the following operations.
  • Ingress actions such as pass, drop, and mirroring
  • Egress actions such as invoke signaling, tunnel encapsulation, packet forwarding and / or transformation
  • This functional profile or signature file defines security capabilities for content security controls and / or attack mitigation controls.
  • One goal of I2NSF is to standardize the functional interfaces and forms of security performance while supporting vendor-specific implementations.
  • This capability represents the processing capability of the NSF. That is, processing power, such as how much traffic the NSF handles for a unit time period. This capability can be used to determine if the NSF is in a congested state by comparing it with the workload that the NSF is currently experiencing. This capability can also specify the amount of available resource of each type of resource, such as processing power and memory available in the NSF.
  • FIG 6 illustrates an NSF response message according to an embodiment of the present invention.
  • the NSF Operations Manager can maintain a table of information of all NSFs operating in the system. If the NSF operations manager receives a query from the NSFF, the NSF operations manager can retrieve a table for the NSF that matches the NSF profile included in the query. If there are multiple candidate NSFs, the NSF Operations Manager may further consider the current workload levels of those NSFs. After selecting the NSF, the NSF Operations Manager may inform the NSFF of the network delivery information of the selected NSF. For example, the NSF Operations Manager can provide the NSFF with network delivery information of the selected NSF through an NSF Response message.
  • the NSF response message may include an NSF profile and / or network delivery information.
  • the network delivery information may include IP address, supported protocols and / or location information.
  • the network delivery information may include IPv4 address, IPv6 address, supported transport protocol and / or location information. Each information (field) is demonstrated below.
  • IP Address Indicates the NSF's IP address. As a unique identifier of an NSF, an IP address is basic network information that allows forwarding packets to the NSF.
  • Supported transport protocols Indicates the transport protocols supported by NSF. In order to forward packets to the NSF, it is essential to find out which transport protocols the NSF supports. Examples of transport protocols may include Virtual Extensible LAN (VXLAN), Generic Protocol Extension for VXLAN (VXLAN-GPE), Generic Route Encapsulation (GRE), Ethernet, and the like.
  • the NSFF may perform encapsulation of packets for transmission as defined in the transport protocol.
  • Location Information Provides location information of NSF. NSFs in a system can be distributed in a wide physical region. Unlike the IP address, the location information specifies the physical location of the NSF. Thus, the NSF Operations Manager may consider physical proximity as an additional factor in selecting an NSF.
  • the I2NSF system may be an NSF-triggered I2NSF system or an SFC-enabled system.
  • the firewall can identify the source of the traffic and evaluate the source's level of trust. For example, a firewall may classify network packets into secure packets, dangerous packets, and suspicious packets by evaluating the source's confidence level.
  • Fig. 7 (a) if traffic is received from a trusted source (or classified as a secure packet), the traffic is likely to be benign. In this case, traffic can simply be forwarded to the destination without further inspection.
  • the firewall sends a packet forwarding header containing an NSF profile corresponding to the DPI. And return a resulting packet (ie, a packet with a packet forwarding header attached) to the NSFF.
  • the NSFF can forward the packet to the DPI instance to perform a detailed check of the packet payload.
  • the DPI instance may perform detailed checks on the payload of the received packet.
  • the packet may be delivered to the destination via the NSFF.
  • only packets classified as suspicious packets may be inspected through a DPI module in an intrusion detection system.
  • dangerous packets may simply be dropped (ie dropped) by the firewall. This can help improve the performance of intrusion detection systems by avoiding unnecessary analysis of packets that are already classified as safe or dangerous.
  • DPI is illustrated as an NSF for additional inspection, but this is only an example, and the present invention is not limited thereto. Another NSF may be used.
  • the degree of suspicion when classifying as a suspicious packet, the degree of suspicion may be divided into plural in consideration of the trust level of the source, and the degree / number of additional checks by the NSF may be determined according to the level of suspicion. It may be.
  • the I2NSF system may be an NSF-triggered I2NSF system or an SFC-enabled system.
  • NSF instances In large network domains, there are typically multiple NSF instances providing various security services. At this point, a particular NSF instance may experience excessive traffic beyond its capabilities. In this case, it is required to allocate some of the traffic to another available instance of the same NSF.
  • This process may be commonly referred to as load balancing.
  • the NSF operations manager may periodically monitor the traffic load status of available NSF instances.
  • a new NSF instance may be dynamically created through the developer management system. This dynamic NSF instance generation can be combined with the traffic steering mechanism to eventually provide load balancing services.
  • Step 1 The NSF Operations 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. On the other hand, it is assumed that no additional firewall instance is currently available.
  • Step 2 Since there are no additional firewall instances available, the NSF Operations Manager requests the creation of a new firewall instance that can provide the same security services to the developer management system.
  • Step 3 The developer management system creates a new firewall instance and registers information of the new firewall instance with the NSF Operations Manager.
  • Step 4 The NSF Operations Manager updates the NSF information table to reflect the new firewall instance and informs the NSF and NSFF of this update.
  • the NSF information table may be referred to as a service function chaining (SFC) information table.
  • Step 5 According to the new forwarding information, the NSFF forwards the following traffic to the new firewall instance. As a result, this can effectively alleviate the burden of existing firewall instances.
  • the network device may correspond to the above-described I2NSF system or may be a device included in the I2NSF system.
  • Examples of devices included in the I2NSF system include the aforementioned I2NSF, security controller, developer management system, NSF (or SF), NSFF (or SFF), classifier, NSF operations manager (or SFC policy manager, SFC catalog manager), and the like. May be included.
  • the network device 900 includes a processor 910, a memory 920, and a communication module 930.
  • the processor 910 implements the functions, processes, and / or methods proposed in FIGS. 1 to 8.
  • the memory 920 is connected to the processor 910 and stores various information for driving the processor 910.
  • the communication module 930 is connected to the processor 910 to transmit and / or receive a wired / wireless signal.
  • the memory 920 may be inside or outside the processor 910 and may be connected to the processor 910 by various well-known means.
  • the network device may be the NSFF of FIG. 2A or the SFF of 2B.
  • the NSFF may receive a packet from a first NSF that performs a security check on the packet.
  • the packet may include a packet forwarding header for invoking an additional check (S1010).
  • the NSFF may search for a second NSF having a security capability required for further inspection based on the information included in the packet forwarding header (S1020).
  • 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 NSFF may transmit a packet to the second NSF (S1030). Alternatively, if the second NSF is not found, the NSFF may forward the packet to the third NSF newly generated by the NSF operation manager (S1040). To this end, the NSFF sends an NSF generation request packet containing the security capabilities required for further inspection to the NSF operations manager, receives information about the third NSF generated from the NSF operations manager, and sends the packet to the third NSF. I can deliver it.
  • the NSF Operations Manager maintains a list of information about all available NSFs, selects a third NSF with the security capabilities required for the further inspection, taking into account the traffic load status of each NSF within the information list and In addition, information about a third NSF may be transmitted to the NSFF.
  • the NSF Operations Manager monitors the traffic load status of all available NSFs and, upon detecting that excessive traffic is generated for a particular NSF, causes the developer's management system to be identical to the NSF that generated the excessive traffic. May request the creation of a new NSF with security capabilities.
  • the NSF operations manager may monitor the traffic load status of all available NSFs and, upon detecting that a particular NSF is not used, may request the developer's management system to remove the unused NSFs.
  • 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.
  • 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.
  • 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.
  • 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.
  • the present invention can be applied to various systems for providing a security service.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

네트워크 보안 기능(NSF) 전달자의 패킷 전달 방법은 패킷에 대한 보안 검사를 수행하는 제1 NSF로부터 패킷을 수신하는 단계로서, 패킷은 추가적인 검사를 호출하기 위한 패킷 전달 헤더를 포함하는, 패킷을 수신하는 단계; 및 패킷 전달 헤더에 포함된 추가적인 검사를 위해 요구되는 보안 능력을 가진 제2 NSF를 탐색한 경우, 제2 NSF에게 상기 패킷을 전달하는 단계를 포함할 수 있다. 패킷 전달 헤더는 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드, 및 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함할 수 있다.

Description

[규칙 제26조에 의한 보정 27.03.2018]　트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치
본 발명은 보안 서비스를 제공하는 시스템에 관한 것으로서, 보다 상세하게 트리거되는 트래픽 스티어링(traffic steering)을 위한 방법 및 시스템, 이를 위한 장치에 관한 것이다.
오늘날 통신 사업자 및 인터넷 서비스 제공 업체와 같은 다양한 기업에서 운영 비용을 줄이고 보다 효율적이고 유연한 방법으로 자원을 활용하기 위해 네트워크 기능 가상화(NFV: Network Functions Virtualization) 기술을 널리 채택하고 있다. 또한, 제3자(third-party)의 서비스 공급 업체에 의해 제공되는 네트워크 기능 및 자원의 사용이 점차 대중화되고 있다. 기업들은 자신의 네트워크 시스템 및 정보 자산을 보호하기 위하여, 보안 기기(security appliance)를 직접 운영하는 대신에 third-party 보안 공급 업체에 의해 제공되는 보안 기능을 가입하여 사용하기 시작하였다.
이러한 운영 모델은 다양한 이점을 제공한다. 회사는 물리적인 보안 장비 구매에 비용을 지불하지 않아도 되기 때문에 자본 지출(capital outlay)을 줄일 수 있다. 또한, 다양한 공격 시그니처(attack signature)에 대한 최신(up-to-date) 데이터베이스를 항상 유지할 수 있다.
다만, 보안 기능(security function)은 다수의 솔루션 공급 업체(solution vendor)에 의해 개발되고, 다수의 네트워크 운영자에 의해 관리되기 때문에, NFV 기반 보안 기능(NFV-based security function)을 성공적으로 배포하기 위해서는 표준화가 요구된다.
본 발명의 목적은 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 프레임워크를 제안한다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명의 일 실시예에 따른 네트워크 보안 기능(NSF) 전달자의 패킷 전달 방법은 패킷에 대한 보안 검사를 수행하는 제1 NSF로부터 상기 패킷을 수신하는 단계로서, 상기 패킷은 추가적인 검사를 호출하기 위한 패킷 전달 헤더를 포함하는, 상기 패킷을 수신하는 단계; 및 상기 패킷 전달 헤더에 포함된 상기 추가적인 검사를 위해 요구되는 보안 능력을 가진 제2 NSF를 탐색한 경우, 상기 제2 NSF에게 상기 패킷을 전달하는 단계를 포함할 수 있다.
실시예로서, 상기 패킷 전달 헤더는 상기 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 상기 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드 및 상기 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함할 수 있다.
실시예로서, 상기 제2 NSF를 탐색하지 못한 경우, 상기 추가적인 검사를 위해 요구되는 보안 능력을 포함하는 NSF 생성 요청 패킷을 NSF 운영 관리자에게 전송하는 단계; 및 상기 NSF 운영 관리자로부터 생성된 제3 NSF에 대한 정보를 수신하면 상기 제3 NSF에게 상기 패킷을 전달하는 단계를 포함할 수 있다.
실시예로서, 상기 NSF 운영 관리자는 이용 가능한 모든 NSF에 대한 정보 리스트를 관리하며, 상기 정보 리스트 내에서 각 NSF의 트래픽 로드 상태를 고려하여 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 상기 제3 NSF를 선택하고, 상기 제3 NSF에 대한 정보를 상기 NSFF에게 전송하는, 패킷 전달 방법.
실시예로서, 상기 NSF 운영 관리자는 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF에 대하여 과도한 트래픽이 발생됨을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 과도한 트래픽이 발생된 NSF와 동일한 보안 능력을 가지는 새로운 NSF의 생성을 요청하는, 패킷 전달 방법.
실시예로서, 상기 NSF 운영 관리자가 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF가 이용되지 않음을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 이용되지 않는 NSF의 제거를 요청하는, 패킷 전달 방법.
본 발명의 일 실시예에 따른 네트워크 보안 기능(NSF) 전달자는 데이터를 통신하는 통신 모듈; 및 상기 통신 모듈을 제어하는 프로세서를 포함하며, 상기 프로세서는, 패킷에 대한 보안 검사를 수행하는 제1 NSF로부터 상기 패킷을 수신하고, 상기 패킷은 추가적인 검사를 호출하기 위한 패킷 전달 헤더를 포함하며; 및 상기 패킷 전달 헤더에 포함된 상기 추가적인 검사를 위해 요구되는 보안 능력을 가진 제2 NSF를 탐색한 경우, 상기 제2 NSF에게 상기 패킷을 전달할 수 있다.
실시예로서, 상기 패킷 전달 헤더는 상기 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 상기 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드 및 상기 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함하는, NSF 전달자.
실시예로서, 상기 프로세서는, 상기 제2 NSF를 탐색하지 못한 경우, 상기 추가적인 검사를 위해 요구되는 보안 능력을 포함하는 NSF 생성 요청 패킷을 NSF 운영 관리자에게 전송하고; 및 상기 NSF 운영 관리자로부터 생성된 제3 NSF에 대한 정보를 수신하면 상기 제3 NSF에게 상기 패킷을 전달하는 것을 더 포함할 수 있다.
실시예로서, 상기 NSF 운영 관리자는 이용 가능한 모든 NSF에 대한 정보 리스트를 관리하며, 상기 정보 리스트 내에서 각 NSF의 트래픽 로드 상태를 고려하여 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 상기 제3 NSF를 선택하고, 상기 제3 NSF에 대한 정보를 상기 NSFF에게 전송할 수 있다.
실시예로서, 상기 NSF 운영 관리자는 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF에 대하여 과도한 트래픽이 발생됨을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 과도한 트래픽이 발생된 NSF와 동일한 보안 능력을 가지는 새로운 NSF의 생성을 요청할 수 있다.
실시예로서, 상기 NSF 운영 관리자가 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF가 이용되지 않음을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 이용되지 않는 NSF의 제거를 요청할 수 있다.
본 발명의 실시예에 따르면, NSF 간에 트래픽 스티어링을 가능하게 하고, 다양한 타입의 NSF를 통해 네트워크 트래픽의 복합적인 검사(composite inspection)를 가능하게 한다.
또한, 본 발명의 실시예에 따르면, 동적으로 생성된 NSF 인스턴스(instance)들을 통한 로드 밸런싱(load balancing)을 제공할 수 있다.
또한, 본 발명의 실시예에 따르면, 표준화된 인터페이스 및 데이터 모델을 이용함으로써, 다양한 네트워크 보안 기능(NSF)들을 제어 및 관리를 단순화 할 수 있다.
또한, 본 발명의 실시예에 따르면, NSF의 추상적인 뷰(abstract view)만을 사용자에게 제공함으로써, 사용자 친화적인(user-friendly) 보안 정책 설정(specification)을 가능하게 한다.
또한, 본 발명의 실시예에 따르면, NSF가 동적으로 활성화/비활성화(enabled/disabled)됨에 따라 다양한 네트워크 조건 및 보안 요구 사항을 지원할 수 있다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다.
도 1은 본 발명의 일 실시예에 따른 I2NSF(Interface to Network Security Functions) 시스템을 예시한다.
도 2a는 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering)을 위한 I2NSF 시스템의 구성을 예시한다.
도 2b는 본 발명의 일 실시예에 따른 SFC를 위한 I2NSF 시스템의 구성을 예시한다.
도 3은 본 발명의 일 실시예에 따른 패킷 전달 헤더를 예시한다.
도 4는 본 발명의 일 실시예에 따른 NSF-직면 인터페이스를 예시한다.
도 5는 본 발명의 일 실시예에 따른 NSF 쿼리 메시지를 예시한다.
도 6은 본 발명의 일 실시예에 따른 NSF 응답 메시지를 예시한다.
도 7은 본 발명의 일 실시예에 따른 I2NSF 시스템 내 트래픽의 흐름을 예시하는 도면이다.
도 8은 본 발명의 일 실시예에 따른 I2NSF 시스템 내 로드 밸런싱 방법을 예시하는 도면이다.
도 9는 본 발명의 일 실시예에 따른 네트워크 장치의 블록 구성도를 예시한다.
도 10은 본 발명의 일 실시예에 따른 네트워크 장치의 데이터 전달 방법의 순서도이다.
이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.
몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다.
이하의 설명에서 사용되는 특정 용어들은 본 발명의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 발명의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
최근에는, NFV-based security function을 위한 기본 표준 인터페이스가 I2NSF(Interface to Network Security Functions) 워킹 그룹에 의해 개발되고 있다. 이는 인터넷 엔지니어링 태스크 포스(IETF: Internet Engineering Task Force)로 불리는 국제 인터넷 표준 기구의 일부이다.
I2NSF의 목적은 다수의 보안 솔루션 벤더(security solution vendor)들에 의해 제공되는 이종의(heterogeneous) 네트워크 보안 기능(들)(NSF: network security function)을 위한 표준화된 인터페이스를 정의하기 위함이다.
I2NSF 아키텍처(architecture)에서, NSF(들)의 관리에 대하여 상세히 고려할 필요 없이(NSF의 관리는 결국 보안 정책의 시행(enforce)을 요구한다), 사용자는 사용자의 네트워크 시스템 내 네트워크 자원을 보호하기 위한 보호 정책을 정의할 수 있다. 또한, 다수의 vendor들로부터 NSF(들)로의 표준화된 인터페이스는 이종의 NSF(들)에 대한 태스크(task)의 설정 및 관리를 단순화할 수 있다. 최근 들어 더 정교한(sophisticated) 네트워크 공격에 효과적으로 대처하기 위해서는 다양한 네트워크 보안 기능(들)(NSF: Network Security Functions)(또는 보안 기능(들)(security functions))이 협력하여(cooperatively) 네트워크 트래픽에 대한 복합적인 분석을 수행할 필요가 있다. 또한, 네트워크 트래픽의 특성과 의심되는 수준(suspiciousness level)에 따라, 다양한 타입의 네트워크 트래픽이 서로 다른 NSF들의 세트를 통해 분석될 필요가 있다.
I2NSF 인터페이스(Interface to Network Security Functions) 내의 보안 제어기와 NSF 사이의 인터페이스(NSF-직면 인터페이스(NSF-Facing Interface))에 대한 정보 모델(IM: Information Model)이 제안되었다. 이 NSF-직면 인터페이스는 NSF가 자체 분석 결과에 기초하여 다른 NSF를 호출함으로써 추가적인 검사(inspection)를 트리거할 수 있다.
그러나, I2NSF 프레임워크(framework)의 현재 설계는 다중 NSF를 통한 연속적인(consecutive) 검사를 가능하게 하기 위해 네트워크 트래픽 스티어링(network traffic steering)을 완전히 고려하지 않는 단점이 있다.
이에 따라, 본 명세서에서는 NSF를 통한 트래픽 스티어링(traffic steering)을 위한 추가 구성 요소를 I2NSF 프레임워크에 통합하는 아키텍처를 제안한다.
또한, 본 명세서에서는, NSF에 의해 트리거된(또는 NSF-트리거된)(NSF-triggered) 트래픽 스티어링(traffic steering)의 사용자 관점 정책(high-level policy)을 저수준 정책(low-level policy)으로 해석(interpret)/변환하고 그것들을 관리할 수 있도록, 보안 제어기(security controller)의 기능을 확장하는 방법을 제안한다. 사용자 관점 정책은 고수준 정책으로 지칭될 수도 있다.
또한, 본 명세서에 따르면, 사용 가능한 NSF 인스턴스(들)(instance) 및 NSF 인스턴스(들)의 정보(예컨대, 네트워크 정보 및 작업로드(workload))를 추적하고, 주어진 보안 기능을 위해 사용할 NSF 인스턴스를 결정할 수 있다.
또한, 본 명세서에 따르면, 보안 제어기에 의해 제공되는 전달 정보(forwarding information)에 기반하여, 네트워크 보안 기능 전달자(NSFF: Network Security Function Forwarder)(또는 보안 기능 전달자(Security Function Forwarder)는 요구되는 NSF(들)을 통해 네트워크 트래픽 스티어링을 수행할 수 있다.
또한, 본 명세서에 따르면, NSFF는 NSF로부터의 검사 결과를 해석하여 진보된 검사(advanced inspection)를 시행할 수 있다.
또한, 본 명세서에 따르면, 보안 검사 결과 및 진보된 검사 요청을 특정하기 위한 추가적인 패킷 헤더(packet header) 포맷이 정의될 수 있다.
본 명세서에 개시된 발명은 크게 다음과 같은 목적/효과를 가진다.
- 연속적인(consecutive) 검사를 위한 정책 설정: 본 발명의 일 실시예에 따르면, NSF-트리거된 트래픽 스티어링 아키텍처(architecture)는 NSF 트리거링(triggering)을 위한 정책 설정/관리를 허용한다. 트리거링 정책(triggering policy)에 기반하여, 관련된 네트워크 트래픽은 다양한 NSF(들)을 통해 복합적으로, 협업 방식으로 분석될 수 있다.
- 연속적인 검사를 위한 네트워크 트래픽 스티어링: 본 발명의 일 실시예에 따르면, NSF-트리거된 트래픽 스티어링은 네트워크 트래픽이 트리거링 정책에 기반하여 복수의 요구되는 NSF(들)을 통해 스티어링되는 것을 허용한다. 또한, NSF-직면 인터페이스를 위한 I2NSF 정보 모델(IM)은 NSF가 자신의 검사 결과에 기반하여 추가의 검사를 위해 다른 NSF를 호출하도록 요구한다. 또한, 이러한 요구 사항을 만족하기 위하여, NSF-트리거된 트래픽 스티어링 아키텍처는 하나의 NSF로부터 다른 NSF로의 트래픽 전달(forwarding)이 가능하게 한다.
- NSF 인스턴스(instance) 간의 로드 밸런싱(load balancing): 본 발명의 일 실시예에 따르면, NSF-트리거된 트래픽 스티어링 아키텍처는 유연한 트래픽 스티어링 메커니즘을 활용(leveraging)함으로써 이용 가능한 NSF 인스턴스을 통한 유입 트래픽(incoming traffic)의 로드 밸런싱을 제공한다. 이러한 목적을 위해, NSF에 대한 과도한 요청이 있는 경우, NSF-트리거된 트래픽 스티어링 아키텍처는 NSF의 동적 인스턴스화(instantiation)를 수행(예컨대, 해당 보안 기능을 수행할 수 있는 새로운 NSF를 생성)할 수 있다.
본 명세서에서 사용될 수 있는 용어(terminology)들은 다음과 같이 정의된다.
- 네트워크 보안 기능(NSF: Network Security Function): 수신된 패킷(packet)의 특정 취급을 담당하는 기능 또는 이를 위한 장치를 의미한다. NSF는 다양한 프로토콜 스택(stack)의 다양한 계층(예컨대, 네트워크 계층 또는 다른 OSI(Open System Interconnection) 계층 등)에서 동작할 수 있다.
예를 들어, NSF의 일례로서, 방화벽(firewall), 침입 방지 시스템(IPS: Intrusion Prevention System)/침입 탐지 시스템(IDS: Intrusion Detection System), 강한 패킷 검사(DPI: Deep Packet Inspection), 애플리케이션 가시성 및 제어(AVC: Application Visibility and Control), 네트워크 바이러스 및 악성 코드 스캐닝, 샌드박스(sandbox), 데이터 손실 방지(DLP: Data Loss Prevention), 분산 서비스 거부(DDoS: Distribute Denial of Service) 완화(mitigation), 전송 계층 보안(TLS: Transport Layer Security) 프록시, 안티스푸핑(Anti-Spoofing) 등이 포함될 수 있다. 본 발명의 일 실시예에 따른 NSF는 상술한 예시 중 어느 하나로 구현될 수 있으며, 다양한 타입의 NSF가 이용될 수 있다. 또한, 동일한 타입의 NSF가 다수로 구현될 수도 있다. 또한, 본 발명에 따른 NSF는 상술한 예시 중 어느 하나 이상이 결합되어 구현될 수도 있다.
- 진보된 검사/동작(Advanced Inspection/Action): NFI(NSF-facing interface)를 위한 I2NSF 정보 모델(IM)과 같이, 진보된 검사/동작 은 NSF가 자신의 검사 결과에 기반하여 다른 NSF에 대한 추가적인 검사를 호출하는 것을 의미한다.
- NSF 프로파일(NSF Profile): NSF 프로파일은 NSF의 검사 능력(inspection capabilities)을 나타낸다. 각 NSF는 자신이 제공하는 보안 서비스의 타입, 자신의 리소스 능력 등을 지정하기 위하여 자신의 NSF 프로파일을 가질 수 있다.
- NSF 운영 관리자(NSF Operation Manager): NSF 운영 관리자는 지속적으로 NSF 인스턴스의 정보 및 상태를 관리하고, 진보된 검사 요청을 지원하기 위한 NSF 네트워크 액세스 정보(network access information)을 제공하는 장치를 의미한다. 예를 들면, NSF 인스턴스의 정보는 지원되는 전송 프로토콜(transport protocol), IP(Internet Protocol) 주소, NSF 인스턴스를 위한 위치를 포함할 수 있다. 또한, NSF 운영 관리자는 개발자의 관리 시스템(Developer’s Management System)과의 협의 그리고 전체 NSF 인스턴스들에 대한 로드 밸런싱에 의해 NSF 인스턴스의 풀(pool)의 동적인 관리를 담당한다.
- 패킷 전달 헤더/인캡슐레이션(Packet Forwarding Header/Encapsulation): 패킷 전달 헤더는 추가 검사를 위해 하나의 NSF로부터 또 다른 NSF로의 패킷을 전달하기 위하여 사용된다. 전자의 NSF(즉, 소스 NSF)는 후자의 NSF(즉, 타겟 NSF)의 NSF 프로파일로 패킷 전달 헤더를 구성(construct)하고, NSFF에게 해당 패킷을 전달한다. 요구되는 필드는 동작 코드(action code), 메타데이터(metadata)의 수, 메타데이터(metadata)를 포함할 수 있다. 이때, 메타데이터는 NSF 프로파일의 일부 또는 전체를 포함할 수 있으며, 후술하는 패킷 전달 헤더에서 Spec info 필드로 지칭될 수 있다.
- 네트워크 보안 기능 전달자(NSFF: Network Security Function Forwarder)(또는 보안 기능 전달자(SFF: Security Function Forwarder)): 트래픽이 NSF로부터 전달될 때, NSFF는 패킷 전달 인캡슐레이션에서 운반되는 정보에 따라 하나 이상의 연결된 NSF에게 트래픽을 전달하는 장치(또는 전달자)를 의미한다. 따라서, NSFF는 트래픽을 또 다른 NSFF(동일한 또는 다른 타입의 오버레이(overlay))에게 전달하고, 오버레이(overlay) 검사를 종료할 수 있다.
## 이하에서는 I2NSF 시스템의 아키텍처/프레임워크 및 I2NSF 시스템의 각 컴포넌트들에 대하여 설명한다. 또한, 어떻게 I2NSF가 SDN(Software-Defined Networking) 및 NFV(Network Function Virtualization) 환경에서 기술 및 벤더 독립적인 방식으로 보안 기능을 구현하는 것을 용이하게 하면서, NFS들의 기능을 제한할 수 있는 잠재적 제약(constraint)을 피하게 하는지를 설명한다.
I2NSF 프레임워크는 I2NSF 시스템의 사용자(예컨대, 어플리케이션, 오버레이 또는 클라우드 네트워크 관리 시스템, 또는 기업 네트워크 관리자 또는 관리 시스템)가 어떤 I2NSF 기능이 어떤 트래픽(또는, 트래픽 패턴)에 적용되어야 하는지를 I2NFS 시스템에 알리기 위한 표준 인터페이스를 요구한다. I2NSF 시스템은 이 표준 인터페이스를 상이한 트래픽의 동작(behavior)을 모니터링하고 제어하기 위한 보안 규칙들의 세트로서 인식할 수 있다. I2NSF 프레임워크는 또한 사용자가 상이한 관리 도메인에 의해 호스팅되고 관리되는 흐름-기반(flow-based) 보안 기능을 모니터링하기 위한 표준 인터페이스를 제공한다.
도 1은 본 발명의 일 실시예에 따른 I2NSF(Interface to Network Security Functions) 시스템을 예시한다.
도 1은 I2NSF 시스템의 기본 아키텍처/프레임워크로서, 네트워크 운영 관리 시스템(Network Operator Management System)의 관점에서 도시된 것이다. 따라서, 도 1은 NSF들에 대한 임의의 특정 관리 아키텍처 또는 (개발자 측에서) 어떻게 NSF들이 관리되는지를 가정하지 않는다. 특히, 네트워크 운영 관리 시스템은 NSF 데이터 평면 활동(activity)에 참여하지 않는다. 일반적으로, 모든 I2NSF 인터페이스는 사용을 위해 적어도(at least) 상호 인증(authentication) 및 인가(authorization)를 요구할 수 있다.
도 1을 참조하면, I2NSF 시스템은 I2NSF 사용자(user), 네트워크 운영 관리 시스템(Network Operator Management System), 개발자 관리 시스템(Developer's Management System) 및/또는 적어도 하나의 NSF(Network Security Function)을 포함한다.
I2NSF 사용자는 I2NSF 소비자-직면 인터페이스(I2NSF Consumer-Facing Interface)를 통해 네트워크 운영 관리 시스템과 통신한다. 네트워크 운영 관리 시스템은 I2NSF NSF-직면 인터페이스(I2NSF NSF-Facing Interface)를 통해 NSF(들)과 통신한다. 개발자 관리 시스템은 I2NSF 등록 인터페이스(I2NSF Registration Interface)를 통해 네트워크 운영 관리 시스템과 통신한다. 이하에서는 I2NSF 시스템의 각 컴포넌트(I2NSF 컴포넌트) 및 각 인터페이스(I2NSF 인터페이스)에 설명한다.
I2NSF 사용자
I2NSF 사용자는 다른 I2NSF 컴포넌트(예컨대, 네트워크 운영 관리 시스템)에서 정보(예컨대, NSF의 정보)를 요청하거나 및/또는 다른 I2NSF 컴포넌트(예컨대, 개발자 관리 시스템)에 의해 제공되는 보안 서비스(예컨대, 네트워크 보안 서비스)를 사용하는 I2NSF 컴포넌트이다. 예를 들면, I2NSF 사용자는 오버레이 네트워크 관리 시스템, 기업 네트워크 관리자 시스템, 다른 네트워크 도메인 관리자 등일 수 있다. I2NSF 사용자는 I2NSF 클라이언트로 지칭될 수 있다.
이러한 I2NSF 사용자 컴포넌트에 할당된 역할을 수행하는 대상은 I2NSF 소비자로 지칭될 수 있다. I2NSF 소비자의 예로는, 일정 기간(time span) 동안 패킷의 특정 필드에 기초하여 흐름을 허용, 속도-제한(rate-limit), 또는 거부하기 위해 언더레이 네트워크(underlay network)에 동적으로 알릴 필요가 있는 화상 회의 네트워크 관리자(video-conference network manager), 특정 흐름에 대한 특정 I2NSF 정책을 시행(enforce)하기 위해 제공자 네트워크를 요청할 필요가 있는 기업 네트워크 관리자(Enterprise network administrators) 및 관리 시스템(management systems), 특정 조건의 세트와 일치하는 흐름을 차단하기 위해 언더레이 네트워크에 요청을 전송하는 IoT 관리 시스템(IoT management system)이 포함될 수 있다.
I2NSF 사용자는 사용자 관점(high-level) 보안 정책(security policy)을 생성 및 배포할 수 있다. 구체적으로 설명하면, I2NSF 사용자는 다양한 악의적인(malicious) 공격으로부터 네트워크 트래픽(traffic)을 보호하기 위하여 네트워크 보안 서비스(network security service)를 이용할 필요가 있다. 이 보안 서비스를 요청하기 위하여, I2NSF 사용자는 자신이 원하는 보안 서비스에 대한 사용자 관점 보안 정책을 생성하고 네트워크 운영 관리 시스템에게 이를 알릴 수 있다.
한편, 사용자 관점 보안 정책을 준비하는 과정에서, I2NSF 사용자는 각 NSF(들)를 위한 보안 서비스 또는 보안 정책 규칙 구성(security policy rule configuration)을 실현하기 위하여 요구되는 NSF(들)의 타입에 대하여 고려하지 않을 수 있다.
또한, I2NSF 사용자는 네트워크 운영 관리 시스템에 의해 기본적인(underlying) NSF(들) 내에서 발생되는 보안 이벤트(들)(security event)를 통지 받을 수 있다. 이들의 보안 이벤트(들)을 분석함으로써, I2NSF 사용자는 새로운 공격을 식별하고, 새로운 공격에 대처하기 위한 사용자 관점 보안 정책을 업데이트(또는 생성)할 수 있다. 이와 같이, I2NSF 사용자는 보안 정책을 정의, 관리 및 모니터링할 수 있다.
네트워크 운영 관리 시스템
네트워크 운영 관리 시스템은 보안 제공, 모니터링 및 기타 동작을 위한 수집(collection) 및 배포(distribution) 지점(point)의 역할을 수행하는 컴포넌트이다. 예를 들면, 네트워크 운영 관리 시스템은 보안 제어기(Security Controller)에 해당하거나, 또는 보안 제어기를 포함하는 컴포넌트일 수 있다. 이러한 네트워크 운영 관리 시스템은 네트워크 운영자에 의해 관리될 수 있고, I2NSF 관리 시스템으로 지칭될 수도 있다.
네트워크 운영 관리 시스템(또는 보안 제어기)의 주요한 역할 중 하나는 I2NSF 사용자로부터의 사용자 관점 보안 정책(또는 정책 규칙)을 특정 NSF(들)을 위한 저수준(low-level) 보안 정책 규칙으로 번역(translate)하는 것이다. 네트워크 운영 관리 시스템(또는 보안 제어기)은 사용자 관점 보안 정책을 I2NSF 사용자로부터 수신한 후, 우선 I2NSF 사용자에 의해 요구되는 정책을 시행하기 위하여 요구되는 NSF(들)의 타입을 결정할 수 있다. 그리고, 네트워크 운영 관리 시스템(또는 보안 제어기)은 요구되는 각 NSF(들)을 위한 저수준(low-level) 보안 정책을 생성할 수 있다. 결국, 네트워크 운영 관리 시스템(또는 보안 제어기)는 생성된 저수준 보안 정책을 각 NSF(들)에게 설정할 수 있다.
또한, 네트워크 운영 관리 시스템(또는 보안 제어기)은 I2NSF 시스템 내 구동 중인 NSF(들)을 모니터링하고, 각 NSF(들)에 대한 다양한 정보(예를 들어, 네트워크 액세스(access) 정보 및 작업로드(workload) 상태 등)를 유지할 수 있다. 또한, 네트워크 운영 관리 시스템(또는 보안 제어기)은 개발자 관리 시스템의 도움을 받아 NSF 인스턴스의 동적인 수명시간(life-cycle) 관리를 통해 NSF 인스턴스(instance)의 풀(pool)을 동적으로 관리할 수 있다.
NSF
NSF는 보안 관련 서비스를 제공하는 논리적 엔티티(logical entity) 또는 소프트웨어 컴포넌트이다. 예를 들면, NFC(예컨대, 방화벽)는 저수준 보안정책을 수신하고, 이에 기초하여 악의적인 네트워크 트래픽을 감지하고, 이를 차단하거나 완화할 수 있다. 이를 통해, 네트워크 통신 스트림의 무결성(integrity) 및 기밀성(confidentiality)이 보장될 수 있다.
개발자 관리 시스템
개발자 관리 시스템은 다른 I2NSF 컴포넌트(예컨대, 네트워크 운영 관리 시스템)으로 정보(예컨대, NSF의 정보)를 보내거나, 및/또는 보안 서비스(예컨대, 네트워크 보안 서비스)를 제공하는 I2NSF 컴포넌트이다. 개발자 관리 시스템은 벤더 관리 시스템(Vendor's Management System)으로 지칭될 수도 있다. 이러한 개발자 관리 시스템에 할당된 역할을 수행하는 대상은 I2NSF 생산자(producer)로 지칭될 수 있다.
개발자 관리 시스템은 네트워크 운영자에게 NSF(들)을 제공하는 제3자(third-party) 보안 벤더에 의해 관리될 수 있다. 다양한 보안 벤더의 다수의 개발자 관리 시스템(들)이 존재할 수 있다.
I2NSF 소비자-직면 인터페이스(간단히, 소비자-직면 인터페이스(CFI))
CFI는 I2NSF 사용자와 네트워크 운영 관리 시스템 사이에 위치하는, 사용자의 I2NSF 시스템으로의 인터페이스이다. 이렇게 설계됨으로써, I2NSF 시스템은 하위(underlying) NSF(들)의 상세한 내용을 숨기고, 사용자에게 NSF(들)의 추상적인 시각(abstract view)만을 제공할 수 있다.
이 CFI는 주어진 I2NSF 시스템의 상이한 사용자가 관리 도메인 내의 특정 흐름(flow)에 대한 보안 정책을 정의, 관리 및 모니터링할 수 있게 하기 위해 사용될 수 있다. I2NSF 사용자에 의해 생성된 사용자 관점 보안 정책(또는 정책 규칙)은 이 CFI를 통해 네트워크 운영 관리 시스템으로 전달될 수 있다. 또한, NSF(들)에 의한 보안 경보(alert)는 이 CFI를 통해 네트워크 운영 관리 시스템으로부터 I2NSF 사용자로 전달될 수 있다.
I2NSF NSF-직면 인터페이스(간단히, NSF-직면 인터페이스(NFI))
NFI는 네트워크 운영 관리 시스템(또는 보안 제어기)과 NSF(들) 사이에 위치하는 인터페이스이다.
NFI의 주요한 목적은 NSF(들)로부터 보안 관리 기법을 분리(decouple)함으로써 다양한 보안 솔루션 벤더들의 NSF(들)을 제어하고 관리하기 위한 표준화된 인터페이스를 제공하기 위함이다. NFI는 NSF(들)의 상세한 내용(예를 들어, 벤더, 유형 인자(form factor) 등)과 독립된다. 따라서, 보안 정책 규칙을 NSF에게 설정할 때, 네트워크 운영 관리 시스템은 벤더 특정한 차이 및/또는 NSF의 폼 팩터(form factor)를 고려할 필요가 없다. 이 NFI는 하나 이상의 NSF에 의해 시행되는 흐름-기반(flow-based) 보안 정책을 지정하고 모니터링하기 위해 사용될 수 있다. 예를 들면, 네트워크 운영 관리 시스템은 I2NSF 사용자에 의한 사용자 관점 보안 정책을 시행하기 위하여 흐름-기반(flow-based) 보안 정책을 NFI 인터페이스를 통해, 각 흐름-기반 NSF에게 전달할 수 있다. 여기서, 흐름-기반 NSF는 보안 특성을 강화하기 위해 정책의 세트에 따라 네트워크 흐름을 검사하는 NSF이다. 이러한 흐름-기반 NSF에 의한 흐름-기반 보안은 수신된 순서대로 패킷들이 검사되고, 검사 프로세스에 따라 패킷에 대한 수정이 없는 것을 의미한다. 흐름-기반 NSF에 대한 인터페이스는 다음과 같이 분류될 수 있다:
- NSF 운영 및 관리 인터페이스(NSF Operational and Administrative Interface): NSF의 운영 상태를 프로그래밍하기 위해 I2NSF 관리 시스템에 의해 사용되는 인터페이스 그룹; 이 인터페이스 그룹은 또한 관리 제어 기능을 포함한다. I2NSF 정책 규칙은 일관된 방식으로 이 인터페이스 그룹을 변경하는 한가지 방법을 나타낸다. 어플리케이션 및 I2NSF 컴포넌트가 그들이 송신 및 수신하는 트래픽의 동작을 동적으로 제어할 필요가 있기 때문에, I2NSF 노력(effort)의 대부분이 이 인터페이스 그룹에 집중된다.
- 모니터링 인터페이스(Monitoring Interface): 하나 이상의 선택된 NSF로부터의 모니터링 정보를 획득하기 위해 I2NSF 관리 시스템에 의해 시용되는 인터페이스 그룹; 이 인터페이스 그룹의 각 인터페이스는 쿼리 또는 리포트 기반 인터페이스일 수 있다. 둘 사이의 차이점은 쿼리 기반 인터페이스는 정보를 획득하기 위해 I2NSF 관리 시스템에 의해 사용되고, 이에 반하여 리포트 기반 인터페이스는 정보를 제공하기 위해 NSF에 의해 사용된다는 것이다. 이 인터페이스 그룹의 기능은 또한 SYSLOG 및 DOTS와 같은 다른 프로토콜에 의해 정의될 수 있다. I2NSF 관리 시스템은 정보의 수신에 기초하여 하나 이상의 동작(action)을 취할 수 있다. 이는 I2NSF 정책 규칙에 의해 지정되어야 한다. 이 인터페이스 그룹은 NSF의 운영 상태를 변경하지 않는다.
이와 같이, NFI는 흐름-기반 패러다임을 사용하여 개발될 수 있다. 흐름-기반 NSF의 공동 특성(common trait)은 수신된 패킷의 컨텐츠(예컨대, 헤더/페이로드) 및/또는 컨텍스트(예컨대, 세션 상태 및 인증 상태)에 기초하여 패킷을 처리하는 것이다. 이 특징은 I2NSF 시스템의 동작을 정의하기 위한 요구사항(requirement) 중 하나이다.
한편, I2NSF 관리 시스템은 주어진 NSF의 모든 기능들을 사용할 필요가 없으며, 모든 사용 가능한 NSF들을 사용할 필요도 없다. 따라서, 이 추상화(abstraction)는 NSF 특징(feature)을 NSF 시스템에 의해 빌딩 블록(building block)으로 취급될 수 있게 해준다. 그러므로, 개발자는 벤더 및 기술에 독립적인 NSF에 의해 정의되는 보안 기능을 자유롭게 사용할 수 있게 된다.
I2NSF 등록 인터페이스(간단히, 등록 인터페이스(RI))
RI는 네트워크 운영 관리 시스템 및 개발자 관리 시스템 사이에 위치하는 인터페이스이다. 상이한 벤더에 의해 제공되는 NSF는 상이한 능력(capability)을 가질 수 있다. 따라서, 상이한 벤더에 의해 제공되는 여러 유형의 보안 능력을 이용하는 프로세스를 자동화하기 위해, 벤더가 그들의 NSF의 기능을 정의하기 위한 전용 인터페이스를 가질 필요가 있다. 이러한 전용 인터페이스는 I2NSF 등록 인터페이스(RI)로 지칭될 수 있다.
NSF의 능력은 미리 구성되거나 또는 I2NSF 등록 인터페이스를 통해 동적으로 검색될 수 있다. 만일 소비자에게 노출되는 새로운 기능이 NSF에 추가된다면, 관심 있는(interested) 관리 및 제어 엔티티가 그것들을 알 수 있도록, 그 새로운 기능의 능력이 이 RI를 통해 I2NSF 레지스트리(registry)에 등록될 필요가 있다.
## 이하에서는, 도 2a를 참조하여 NSF-트리거된 트래픽 스티어링을 위한 I2NSF 시스템(또는 아키텍처) 및 트래픽 스티어링의 기본 동작에 대하여 살펴본다. 또한, 이 아키텍처의 각 구성 요소에 대하여 설명한다.
도 2a는 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering)을 위한 I2NSF 시스템의 구성을 예시한다. 도 2a의 I2NSF 시스템은 도 1의 I2NSF 시스템에 비하여 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링을 위한 컴포넌트를 더 포함할 수 있다. 예를 들면, 도 2a의 I2NSF 시스템은 후술할 NSF 전달자(Forwarder), 즉, NSFF를 더 포함할 수 있다. 도 2a에서는 도 1에서 상술한 설명과 중복된 설명은 생략한다.
본 명세서에서, NSF에 의해 트리거되는 트래픽 스티어링을 위한 I2NSF 시스템은 NSF-트리거된 트래픽 스티어링 시스템 또는 NSF-트리거된 I2NSF 시스템으로 지칭될 수 있다.
도 2a를 참조하면, 본 발명의 일 실시예에 따른 NSF-트리거된 트래픽 스티어링 시스템은 I2NSF 사용자(user), 보안 관리 시스템(Security Management System) 및/또는 보안 네트워크(Security Network)를 포함한다. 또한, I2NSF 사용자는 사용자/앱 컨트롤러(User/App Controller)를 포함할 수 있다. 보안 관리 시스템은 NSF 운영 관리자를 포함하는 보안 컨트롤러 및 개발자 관리 시스템을 포함할 수 있다. 보안 네트워크는 NSFF(들) 및 NSF(들)을 포함할 수 있다.
도 2a의 실시예에 따른 NSF-트리거된 트래픽 스티어링 시스템은 전송중인 패킷의 복합 검사(composite inspection)를 지원할 수 있다. 패킷 전달 헤더에 저장된 각 NSF의 검사 결과에 따라, 트래픽 패킷은 추가적인 상세한 분석을 위해 또 다른 NSF로 스티어링될 수 있다.
기존의 I2NSF 프레임워크(예컨대, 도 1의 I2NSF 프레임워크)의 컴포넌트인 I2NSF 사용자로부터 사용자 관점의(high-level) 진보된 검사에 대한 정책 및 설정이 반영될 수 있다. 또한, 본 명세서에서 제안되는 NSF-트리거된 트래픽 스티어링 시스템은 로드 밸런싱, 자동적인 추가(supplementary) NSF 인스턴스 생성 및 사용되지 않는(unused) NSF 인스턴스 제거 기능을 제공할 수 있다. 이러한 설계 목적을 성취하기 위하여, 도 2a의 I2NSF 시스템은 도 1의 I2NSF 시스템에 비해 NSFF, NSF 운영 관리자(NSF Operation Manager)와 같은 컴포넌트들을 더 포함할 수 있고, 개발자 관리 시스템, NSF와 같은 기존의 컴포넌트가 이를 위한 추가적인 동작을 더 수행할 수 있다.
이하, 각 구성 요소에 대하여 살펴본다.
- NSF 운영 관리자(NSF Operation Manager)
NSF 운영 관리자는 NSF-트리거된 트래픽 스티어링 시스템의 주요 컴포넌트이다. 도 2a에서 예시된 바와 같이, NSF 운영 관리자는 보안 제어기의 하위 모듈에 해당한다. NSF 운영 관리자는 다음 3 가지의 동작을 담당한다.
i) IP(Internet Protocol) 주소, 지원되는 전송 프로토콜(transport protocol), NSF 프로파일, 로드 상태와 같이 사용 가능한 모든 NSF 인스턴스의 정보를 유지
ii) 주어진 NSF 프로파일과 관련된 진보된 검사(advanced inspection) 수행을 돕기 위하여 NSFF로부터 수신된 사용 가능한 NSF 인스턴스의 쿼리(query)에 대한 응답
iii) 리소스 낭비를 피하기 위한 기존 NSF 인스턴스의 제거 또는 서비스 혼잡을 피하기 위한 추가의(supplementary) NSF 인스턴스의 인스턴스화(instantiation)를 위하여 개발자 관리 시스템(Developer's Management System)으로의 요청
보다 구체적으로 살펴보면, 새로운 NSF 인스턴스가 등록될 때마다, 개발자 관리 시스템은 등록된 NSF 인스턴스의 정보를 NSF 운영 관리자로 전달할 수 있다. 이에 따라, NSF 운영 관리자는 사용 가능한 모든 NSF 인스턴스의 정보 리스트를 유지할 수 있다.
또한, NSF 운영 관리자는 NSFF로부터 진보된 검사를 위한 NSF 프로파일(예컨대, 보안 능력 정보)을 포함하는 요청 패킷(예컨대, NSF 생성 요청 패킷)을 수신할 수 있다. NSF 운영 관리자가 NSFF로부터 특정 NSF 프로파일의 쿼리를 수신하면, NSF 운영 관리자는 해당 NSF 프로파일을 적용 가능한 모든 이용 가능한 NSF 인스턴스를 검색할 수 있다. 그 후, NSF 운영 관리자는 위치 및 로드 상태와 같은 선택 기준을 이용하여 최적(best)의 인스턴스를 찾을 수 있다. 최적의 인스턴스를 찾은 후에, NSF 운영 관리자는 검색 결과를 NSFF에게 반환할 수 있다.
또한, 각 NSF 인스턴스는 주기적으로 자신의 로드 상태를 NSF 운영 관리자에게 보고할 수 있다. 이러한 보고에 기초하여, NSF 운영 관리자는 NSF 인스턴스의 정보를 업데이트할 수 있고, NSF 인스턴스의 추가적인 인스턴스화(instantiation)(즉, 추가의 NSF 인스턴스 생성) 또는 NSF 인스턴스의 제거(elimination/destruct)를 개발자 관리 시스템에 요청함으로써 NSF 인스턴스의 pool을 관리할 수 있다. 결과적으로, NSF 운영 관리자는 혼잡 및 자원 낭비를 방지함으로써 효율적인 자원 활용을 가능하게 한다.
- 개발자 관리 시스템(Developer's Management System)
다음과 같은 추가 기능을 위해 개발자 관리 시스템이 확장될 수 있다.
상술한 바와 같이, NSF 운영 관리자의 요청에 기반하여, 개발자 관리 시스템은 새로운 NSF 인스턴스(들)을 생성하거나 또는 더 이상 사용되지 않는 기존의 NSF 인스턴스(들)을 제거(eliminate/destruct)할 수 있다.
다시 말해, NSF 운영 관리자는 NSF의 기존 인스턴스가 혼잡하면 추가적인 NSF 인스턴스를 생성하기 위해 개발자 관리 시스템에게 요청할 수 있다. 반면에 특정 NSF에 대한 인스턴스의 수가 너무 많으면, NSF 운영 관리자는 개발자 관리 시스템에게 NSF 인스턴스들 중 일부를 제거하도록 요청할 수 있다.
이러한 요청에 대한 응답으로 개발자 관리 시스템은 NSF 인스턴스를 생성 및/또는 제거할 수 있다. 그리고, 새로운 NSF 인스턴스를 생성하거나 기존 NSF 인스턴스를 제거한 후에 개발자 관리 시스템은 변경 사항을 NSF 운영 관리자에 통보할 수 있다.
- NSF 전달자(NSFF)
도 2a에서 예시된 바와 같이, NSFF가 보안 네트워크에 포함될 수 있다. NSFF는 다음과 같은 두 가지 기능을 담당한다.
i) NSF-직면 인터페이스(NFI)를 위한 I2NSF 정보 모델에서 설명된 바와 같이, 유입된(incoming) 트래픽/패킷을 네트워크 보안(Network Security) 서브-모듈(Sub-Module)(즉, NSF)로 초기에 전달(Initially forwarding)하는 기능.
ii) 패킷 전달 헤더에 지정된 NSF 프로파일을 사용하여 일치하는 NSF로 트래픽/패킷을 전달하는 기능.
보다 구체적으로 설명하면, NSFF는 게이트웨이 기능을 사용하여 유입되는(incoming) 트래픽/패킷을 수신하고, 트래픽/패킷을 네트워크 보안 서브 모듈(즉, NSF)로 전달하기 위하여 외부 인캡슐레이션(outer encapsulation)을 트래픽/패킷에 부착(attach)할 수 있다. 이때, 네트워크 보안 서브 모듈(즉, NSF)은 예컨대, 패킷 헤더 검사를 수행하는 방화벽일 수 있다. 이 네트워크 보안 서브 모듈은 외부 인캡슐레이션과 원본 패킷(origin packet) 사이에 패킷 전달 헤더를 부착할 수 있다. 그리고, 패킷이 진보된 검사를 위해 컨텐츠 보안 서브-모듈(Content Security Sub-Module) 또는 완화 서브-모듈(Mitigate Sub-Module)에게 전달될 수 있도록, 패킷 전달 헤더 내 NSF 프로파일을 지정할 수 있다.
네트워크 보안 서브 모듈로부터 특정 NSF 프로파일의 패킷 전달 헤더가 부착된 패킷을 수신하는 경우, NSFF는 NSF 프로파일에 해당되는(매칭되는) 네트워크 보안 서비스를 제공하는 이용 가능한 NSF 인스턴스를 검색할 수 있다. 그리고, NSFF는 검색된 NSF 인스턴스에게 패킷을 전달할 수 있다.
NSF가 패킷이 또 다른 타입의 NSF를 통한 추가적인 검사가 요구된다고 결정하면, NSF는 진보된 NSF의 NSF 프로파일로 지정된(포함하는) 패킷 전달 헤더를 구성(construct)하고, 헤더를 패킷에 부착할 수 있다. 그리고, NSF는 패킷을 NSFF에게 전송할 수 있다.
패킷을 수신하면, NSFF는 패킷 전달 헤더 내 지정된 NSF 프로파일을 체크한다. 그리고, NSFF는 NSF 운영 관리자와 협의함으로써 NSF 프로파일과 매칭되는 NSF 인스턴스를 검색하고, 해당 NSF 인스턴스에게 패킷을 전달할 수 있다.
- NSF
상술한 것처럼, NSF(예를 들어, firewall, DPI, 서비스 거부 공격 중재자(Dos(Denial of Service) attack mitigator) 등)는 보안 제어기로부터 수신한 보안 정책 규칙에 따라 네트워크 트래픽의 보안 검사를 수행한다.
특히, 도 2의 I2NSF 시스템 내 NSF는 자신의 보안 검사 결과에 기반하여 서로 다른 NSF 타입으로 진보된 보안 검사(advanced security inspection)(예를 들어, DPI 및 분산 서비스 거부 공격 중재자(DDoS(Distribute Denial of Service) attack mitigator)를 트리거(trigger)할 수 있다. 예를 들어, 방화벽은 DPI를 이용한 의심스러운 패킷(suspicious traffic)의 추가적인 검사를 트리거할 수 있다.
이 경우, 그러한 진보되고 복합적인 검사(composite inspection)를 실현하기 위하여, NSFF는 현재 NSF로부터 다음의(successor) NSF로의 의심스러운 트래픽의 전달을 수행할 수 있다.
도 2a에서는 NSFF가 보안 제어기 및 NSF와는 별도의 구성 요소로 도시하고 있으나, 본 발명이 이에 한정되는 것은 아니다. 즉, NSFF는 보안 제어기 또는 NSF 중에 어느 것에도 포함(즉, 하나의 장치로 함께 구현)될 수 있는 논리적인 구성 요소이다.
다음으로, 도 2a에 예시된 architecture의 인터페이스에 대하여 살펴본다.
- I2NSF 소비자-직면 인터페이스(CFI): CFI에 대하여는 도 1에서 상술한 바와 같으므로 자세한 설명은 생략한다.
- I2NSF NSF-직면 인터페이스(NFI): NFI의 주요 기능에 대하여는 도 1에서 상술한 바와 같으므로 중복되는 설명은 생략한다.
각 NSF는 또한 보안 제어기에게 현재 상태(예를 들어, workload 레벨, 혼잡(congestion) 등)를 주기적으로 알리기 위하여 NFI 인터페이스를 사용할 수 있다. 또한, 보안 이벤트/경보가 NSF 상에 발생할 때마다, NSF는 NFI 인터페이스를 통해 보안 제어기에게 이를 보고할 수 있다.
각 NSFF는 보안 제어기로부터 NFI 인터페이스를 통해 시스템 내 구동 중인 NSF의 전달 정보(forwarding information)를 수신할 수 있다. 이때, NSFF가 주어진 트래픽을 전달하기 위한 전달 정보를 가지고 있지 않은 경우, NSFF는 NFI 인터페이스를 통해 보안 제어기에게 정보의 쿼리(query)를 전송할 수 있다.
- 등록 인터페이스(RI: Registration Interface): RI의 주요 기능에 대하여 도 1에서 상술한 바와 같으므로 중복되는 설명은 생략한다.
새로운 NSF가 시스템 내 요구되면, 보안 제어기는 RI 인터페이스를 통해 새로운 NSF 생성을 개발자 관리 시스템에게 요청할 수 있다. 이때, 보안 제어기의 요청은 요청된 NSF 인스턴스의 프로파일(profile)을 포함하고, 이 프로파일은 NSF 인스턴스에 의해 제공되어야 하는 보안 능력(security capability) 및 서비스 능력(service capacity)을 특정할 수 있다.
이 요청이 수신되면, 개발자 관리 시스템은 요청된 NSF 프로파일을 만족하는 새로운 NSF 인스턴스를 생성하고, RI 인터페이스를 통해 보안 제어기에게 이 새로운 NSF 인스턴스의 네트워크 액세스 정보(network access information)(예를 들어, IP(Internet Protocol) 주소, 포트 넘버(port number) 등)를 알릴 수 있다. 네트워크 액세스 정보는 시스템 내 새로운 NSF 인스턴스의 고유한 식별자로서 사용될 수 있다.
반면, 보안 제어기가 특정한 기존의 NSF 인스턴스가 더 이상 필요하지 않다고 결정하면, 보안 제어기는 RI 인터페이스를 통해 개발자 관리 시스템에게 해당 NSF 인스턴스를 제거(destruct)하라고 요청할 수 있다. 이 제거 요청(destruction request)는 제거될 NSF 인스턴스의 고유한 식별자를 포함할 수 있다.
## 이하에서는, 도 2b를 참조하여 서비스 기능 체이닝(SFC: Service Function Chaining)을 위한 I2NSF 시스템(또는 아키텍처) 및 SFC의 기본 동작에 대하여 살펴본다. 또한, 이 아키텍처의 각 구성 요소에 대하여 설명한다.
도 2b는 본 발명의 일 실시예에 따른 SFC를 위한 I2NSF 시스템의 구성을 예시한다. 도 2b의 I2NSF 시스템은 도 1의 I2NSF 시스템에 비하여 SFC를 위한 컴포넌트를 더 포함할 수 있다. 예를 들면, 도 2b의 I2NSF 시스템은 후술할 분류기(Classifier) 및 서비스 기능 전달자(SFCC: Service Function Forwarder)를 더 포함할 수 있다. 도 2b에서는 도 1 및 2a에서 상술한 설명과 중복된 설명은 생략한다.
본 명세서에서, SFC를 위한 I2NSF 시스템은 SFC-이네이블된(enabled) I2NSF 시스템으로 지칭될 수 있다.
도 2b를 참조하면, 본 발명의 일 실시예에 따른 SFC-이네이블된 I2NSF 시스템은 I2NSF 사용자(user), 보안 관리 시스템(Security Management System) 및/또는 보안 네트워크(Security Network)를 포함한다. 보안 관리 시스템은 SFC 정책 관리자(SFC Policy Manager) 및 SFC 카탈로그 관리자(SFC Catalog Manager)를 포함하는 보안 컨트롤러 및 개발자 관리 시스템을 포함할 수 있다. 보안 네트워크는 분류기, SFF(들) 및 SF(들)을 포함할 수 있다. 도 2b의 I2NSF 사용자, SFF, SF는 각각 도 2a의 I2NSF 사용자, NFF, NSF에 대응될 수 있다.
도 2b의 실시예에 따른 SFC-이네이블된 I2NSF 시스템은 도 2a에서 상술한 NSF-트리거된 I2NSF 시스템과 유사한 기능을 지원할 수 있다. 예를 들면, SFC-이네이블된 I2NSF 시스템은 전송중인 패킷의 복합 검사(composite inspection)를 지원할 수 있다. 각 SF의 검사 결과에 따라, 트래픽 패킷은 추가적인 상세한 분석을 위해 또 다른 SF로 스티어링될 수 있다.
기존의 I2NSF 프레임워크(예컨대, 도 1의 I2NSF 프레임워크)의 컴포넌트인 I2NSF 사용자로부터 사용자 관점의(high-level) 진보된 검사에 대한 정책 및 설정이 반영될 수 있다. 또한, 본 명세서에서 제안되는 SFC-이네이블된 I2NSF 시스템은 로드 밸런싱, 자동적인 추가(supplementary) SF 인스턴스 생성 및 사용되지 않는(unused) SF 인스턴스 제거 기능을 제공할 수 있다. 이러한 설계 목적을 성취하기 위하여, 도 2b의 I2NSF 시스템은 도 1의 I2NSF 시스템에 비해 분류기, SFF, SFC 정책 관리자, SFC 카탈로그 관리자와 같은 컴포넌트들을 더 포함할 수 있고, 개발자 관리 시스템, SF와 같은 기존의 컴포넌트가 이를 위한 추가적인 동작을 더 수행할 수 있다.
이하, 각 구성 요소에 대하여 살펴본다.
- SFC 정책 관리자(SFC Policy Manager)
SFC 정책 관리자는 SFC-이네이블된 I2NSF 시스템의 주요 컴포넌트이다. 도 2b에서 예시된 바와 같이, SFC 정책 관리자는 보안 제어기의 하위 모듈에 해당한다. SFC 정책 관리자는 다음 2 가지의 동작을 담당한다.
i) I2NSF 클라이언트(즉, I2NSF 사용자)에 의해 주어진, 사용자 관점 SFC 정책 (또는 설정(configuration))을 저수준 SFC 정책(또는 설정)으로 해석하고, 해석된 정책을 SFC를 위한 분류기로 전달.
ii) SF 전달 테이블을 생성하고, SFC 카탈로그와 협의함으로써 전달 정보를 SFF로 배포.
도 2a에 도시된 것처럼, SFC 정책 관리자는 소비자-직면 인터페이스(CFI) 및 NSF-직면 인터페이스(NFI)를 통해 이 추가적인 기능을 수행할 수 있다.
CFI를 통해 I2NSF 클라이언트로부터 사용자 관점 SFC 정책/설정이 주어진 경우, SFC 정책 관리자는 사용자 관점 SFC 정책/설정을 분류기가 이해가능하도록(comprehensible) 저수준 정책/설정으로 해석할 수 있다. 또한, SFC 정책 관리자는 SF의 현재 상태에 빠르게 반응하여 트래픽 스티어링의 유연한 변경을 위한 새로운 정책을 생성할 수 있다. 예를 들면, SFC 정책 관리자는 "방화벽 인스턴스 1"이 혼잡한 상태인 경우, "방화벽 인스턴스 1" 대신에 "방화벽 인스턴스 2"로 모든 다음 패킷들(all subsequent packets)을 전달하는 새로운 규칙을 생성할 수 있다.
SFC 정책 관리자는 SF 전달 테이블을 생성하기 위하여 SFC 카탈로그로부터 SF에 대한 정보를 획득할 수 있다. 테이블 생성 절차에서, SFC 정책 관리자는 SFC 정책, SF 로드 상태, SF 물리적 위치, 및 지원되는 전송 프로토콜과 같은 다양한 기준을 고려할 수 있다. SF 전달 테이블의 엔트리는 SFF 식별자(SPI: Service Path Identifier), SFP(Service Function Path), SI(Service Index) 및 다음 홉 정보를 포함할 수 있다. 다음 홉 정보의 예로는 IP 주소 및 지원되는 전송 프로토콜(예컨대, VxLAN, GRE)이 포함될 수 있다. 이 전달 테이블은 Push 또는 Pull 방법 중 하나를 이용하여 SFF(들)로 배포될 수 있다.
- SFC 카탈로그 관리자(SFC Catalog Manager)
도 2b에서 예시된 바와 같이, SFC 카탈로그 관리자는 보안 제어기의 하위 모듈에 해당한다. SFC 카탈로그 관리자는 다음 3 가지의 동작을 담당한다.
i) IP(Internet Protocol) 주소, 지원되는 전송 프로토콜(transport protocol), 서비스 이름, 로드 상태와 같이 사용 가능한 모든 SF 인스턴스의 정보를 유지
ii) 주어진 SFP에 관련된 전달 테이블 엔트리 생성을 돕기 위하여 SFC 정책 관리자로부터 수신된 사용 가능한 SF 인스턴스의 쿼리(query)에 대한 응답
iii) 리소스 낭비를 피하기 위한 기존 SF 인스턴스의 제거 또는 서비스 혼잡을 피하기 위한 추가의(supplementary) SF 인스턴스의 인스턴스화(instantiation)를 위하여 개발자 관리 시스템(Developer's Management System)으로의 요청
보다 구체적으로 살펴보면, 새로운 SF 인스턴스가 등록될 때마다, 개발자 관리 시스템은 등록된 SF 인스턴스의 정보를 SFC 카탈로그 관리자로 전달할 수 있다. 이에 따라, SFC 카탈로그 관리자는 사용 가능한 모든 SF 인스턴스의 정보 리스트를 유지할 수 있다.
SFC 정책 관리자로부터 특정 SFP의 쿼리를 수신하면, SFC 카탈로그 관리자는 해당 SFP를 적용 가능한 모든 이용 가능한 NSF 인스턴스를 검색할 수 있다. 그 후, SFC 카탈로그 관리자는 검색 결과를 SFC 정책 관리자에게 반환할 수 있다.
또한, 각 SF 인스턴스는 주기적으로 자신의 로드 상태를 SFC 카탈로그 관리자에게 보고할 수 있다. 이러한 보고에 기초하여, SFC 카탈로그 관리자는 SF 인스턴스의 정보를 업데이트할 수 있고, SF 인스턴스의 추가적인 인스턴스화(instantiation)(즉, 추가의 NSF 인스턴스 생성) 또는 SF 인스턴스의 제거(elimination/destruct)를 개발자 관리 시스템에 요청함으로써 SF 인스턴스의 pool을 관리할 수 있다. 결과적으로, SFC 카탈로그 관리자는 혼잡 및 자원 낭비를 방지함으로써 효율적인 자원 활용을 가능하게 한다.
- 개발자 관리 시스템(Developer's Management System)
다음과 같은 추가 기능을 위해 개발자 관리 시스템이 확장될 수 있다.
상술한 바와 같이, SFC 카탈로그 관리자의 요청에 기반하여, 개발자 관리 시스템은 새로운 SF 인스턴스(들)을 생성하거나 또는 더 이상 사용되지 않는 기존의 SF 인스턴스(들)을 제거(eliminate/destruct)할 수 있다.
반면에 특정 SF에 대한 인스턴스의 수가 너무 많으면, SFC 정책 관리자는 개발자 관리 시스템에게 SF 인스턴스들 중 일부를 제거하도록 요청할 수 있다.
이러한 요청에 대한 응답으로 개발자 관리 시스템은 NSF 인스턴스를 생성 및/또는 제거할 수 있다. 그리고, 새로운 NSF 인스턴스를 생성하거나 기존 NSF 인스턴스를 제거한 후에 개발자 관리 시스템은 변경 사항을 SFC 카탈로그 관리자에 통보할 수 있다.
- 분류기
분류기는 단독으로(standalone) 또는 다른 컴포넌트의 하위 모듈로서 존재할 수 있는 논리적인 컴포넌트이다. 초기(initial) 분류기는 네트워크 도메인의 경계 라우터와 같은 엔트리 포인트에 일반적으로 위치하고, SFC 정책 관리자에 의해 주어진 SFC 정책에 따라 모든 유입되는 패킷의 초기 분류를 수행한다. 분류는 주어진 패킷이 통과해야 하는 SFP를 결정하는 것을 의미한다. SFP가 결정되면, 분류기는 해당 SPI 및 SI를 지정하는 NSF(Network Service Header)를 구성하고, 그것을 패킷에 부착한다. 패킷은 NSF 정보에 기초하여 결정된 SFP를 통해 전달될 수 있다.
- SF 전달자(SFF)
도 2b에서 예시된 바와 같이, SFF가 보안 네트워크에 포함될 수 있다. SFF는 다음과 같은 두 가지 기능을 담당한다.
i) 패킷을 다음 SFF/SF로 전달.
ii) SF로부터의 재분류 요청(reclassification request)을 처리(handling).
보다 구체적으로 설명하면, SFF는 전달 기능을 가지며, 유입되는(incoming) 트래픽에 대한 다음 SF/SFF를 발견할 필요가 있다. SFF는 주어진 트래픽에 대응하는 다음 홉 정보를 발견하기 위해 전달 테이블을 검색할 수 있다. SFF가 전달 테이블에서 타겟 엔트리를 발견한 경우, SFF는 다음 홉 정보에 지정된 다음 SF/SFF로 트래픽을 전달할 수 있다. 만일 SFF가 주어진 패킷에 대한 엔트리를 갖지 않는다면, SFF는 SFF 식별자, SPI 및 SI 정보를 이용하여 SFC 정책 관리자로 다음 홉 정보를 요청할 수 있다. SFC 정책 관리자는 다음 홉 정보로 SFF에 응답하고, 즉, SFC 정책 관리자는 다음 홉 정보를 SFF 전달하고, SFF는 그 응답을 이용하여 전달 테이블을 업데이트 하고, 트래픽을 다음 홉으로 전달할 수 있다.
SF가 매우 의심스러운 패킷을 추가 보안 검사를 위해 다른 SF로 전달하기를 원할 수 있다. 상술한 것처럼, 이는 진보된 보안 검사로 지칭될 수 있다. 이 상황에서, 다음 SF가 패킷의 현재 SFP 상의 것이 아니라면, 재분류가 패킷의 SFP를 변경하기 위해 요구된다. 만일 현재 SF가 패킷을 재분류 할 수 있다면, SF는 진보된 보안 동작을 제공하기 위해 패킷 내의 NSH의 SPI 필드를 업데이트할 수 있다. 그렇지 않다면, 분류기가 독자적으로 존재하는 경우, SF는 NSH의 메타데이터 필드에 패킷의 검사 결과를 부착하고, 소스 SFF로 전달할 수 있다. 부착된 메타데이터는 더 강력한 검사를 위해 다른 SFP로 패킷의 SFP를 변경하기 위한 재분류 요청을 포함할 수 있다. SFF가 재분류를 요구하는 트래픽을 수신하는 경우, SFF는 재분류가 결과적으로 수행될 분류기로 트래픽을 전달할 수 있다.
도 2b에서는 SFF가 보안 제어기 및 SF와는 별도의 구성 요소로 도시하고 있으나, 본 발명이 이에 한정되는 것은 아니다. 즉, SFF는 보안 제어기 또는 SF 중에 어느 것에도 포함(즉, 하나의 장치로 함께 구현)될 수 있는 논리적인 구성 요소이다.
이하의 실시예에서는 I2NSF 시스템이 도 2a의 I2NSF 시스템인 것으로 가정하고 본 발명의 다양한 실시예들을 설명한다. 그러나, 이는 설명의 편의를 위한 것이고, 이하의 설명과 동일 또는 유사한 설명이 I2NSF 시스템이 도 2b의 I2NSF 시스템인 경우에도 적용 또는 준용될 수 있다.
## 이하에서는 I2NSF 시스템 내의 NSF들 간의 패킷 전달을 위한 패킷 전달 헤더 및 NSF 전달 정보에 대하여 상세히 설명한다.
도 3은 본 발명의 일 실시예에 따른 패킷 전달 헤더를 예시한다.
NSF는 검사 결과 및/또는 추가적으로 요구되는 진보된 보안 검사를 NSFF에게 알리기 위해 패킷 전달 헤더를 사용할 수 있다. 따라서, 패킷 전달 헤더는 도 3과 같이 필드의 길이가 가변적일 수 있다. 도 3을 참조하면, 패킷 전달 헤더는 동작 코드(Action Code) 필드, 능력 정보 수(SpecInfo Num) 필드 및/또는 적어도 하나의 능력 정보(SpecInfo) 필드를 포함할 수 있다. 이하에서 각 필드에 대하여 설명한다.
Action Code 필드: Action Code 필드는 패킷에 대한 보안 검사 결과를 포함할 수 있다. 실시예로서, Action Code 필드는 "허용(allow)", "거부(deny)", "진보된(advanced)" 및 "미러(mirror)" 중 하나의 값을 포함할 수 있다. 예를 들면, Action Code 필드는 패킷의 보안 검사 결과 이상이 없어 목적지(destination)으로 전달하는 것을 허용하는 경우 "허용(allow)"을 지시하는 값을 포함하고, 패킷의 보안 검사 결과 이상이 발견되어 패킷을 목적지(destination)으로 전달하는 것을 허용하지 않는 경우 "거부(deny)"를 지시하는 값을, 패킷의 보안 검사 결과 또 다른 NSF에 의해 추가 보안 검사가 요구되는 경우 "진보된(advanced)"을 지시하는 값을 포함하고, 또는 패킷의 보안 검사 결과 목적지(destination)으로 전달하는 것을 허용하되 또 다른 NSF에 의해 추가 보안 검사가 요구되는 경우 "미러(mirror)"를 지시하는 값을 포함할 수 있다.
SpecInfo Num 필드: SpecInfo Num 필드는 패킷 전달 헤더에 몇 개의 SpecInfo 필드(즉, 메타데이터)가 포함되는지 나타낸다.
SpecInfo 필드: SpecInfo 필드는 다음의 보안 검사를 위해 요구되는 보안 능력에 대한 정보를 포함할 수 있다. 예를 들면, 각 SpecInfo 필드는 진보된 보안 검사를 위해 요구되는 NSF의 능력을 설명하는 NSF 프로파일의 일부를 포함할 수 있다. 예를 들면, SepcInfo 필드의 값은 NSF의 서비스 프로파일을 설명하는, "SYN 플러드 완화(syn-flood-mitigate)", "UDP 플러드 완화(udp-flood-mitigate)" 등일 수 있다. 여기서, SYN 플러드는 공격자가 합법적인 트래픽에 대해 시스템이 응답하지 않도록 충분한 서버 자원을 사용하기 위해 SYN 요청을 대상 시스템에 전송하는 DoS 공격의 하나의 형태이다. UDP 플러드 공격은 세션없는/연결없는 컴퓨터 네트워킹 프로토콜인 UDP(User Datagram Protocol)를 사용하는 DoS 공격의 하나의 형태이다.
이러한 복수의 SpecInfo 필드를 포함하는 패킷 전달 헤더가 패킷에 부착된 경우, NSFF를 통해 각 SpecInfo 필드 내 NSF의 서비스 프로파일에 매칭되는 복수의 NSF에게 패킷이 전달되어 추가 검사가 수행될 수 있다.
도 4는 본 발명의 일 실시예에 따른 NSF-직면 인터페이스를 예시한다.
NSF-직면 인터페이스는 I2NSF 시스템에서 패킷을 스티어링하기 위한 주요 기능을 수행할 수 있다. 도 4를 참조하면, NSF-직면 인터페이스는 NSF 질의 서브-모델 및 NSF 응답 서브-모델을 포함한다. 이하에서는 도 5 및 6을 참조하여 NSF 쿼리 메시지 및 NSF 응답 메시지를 이용한 NSF 전달 정보의 쿼리 및 응답 절차에 대하여 설명한다.
도 5는 본 발명의 일 실시예에 따른 NSF 쿼리 메시지를 예시한다.
NSF는 패킷의 진보된 보안 검사를 위해 패킷을 다른 NSF로 전달할 것을 NSFF에 요청할 수 있다. 이 경우에, 만일 NSFF가 전달 정보 테이블 내의 진보된 검사를 위해 요구되는 보안 능력을 제공할 수 있는 NSF를 발견하는데 실패한다면, NSFF는 NSF-직면 인터페이스를 통해 NSF 운영 관리자에게 쿼리를 전송할 수 있다. 이 쿼리는 진보된 검사 능력을 위해 요구되는 보안 (능력)을 설명하는 NSF 프로파일을 포함할 수 있다. 도 5를 참조하면, NSF 쿼리 메시지는 검사 결과 정보를 포함할 수 있다.
NSF 프로파일은 기본적으로 NSF 인스턴스의 검사 능력을 나타낸다. 예를 들면, NSF 프로파일은 패킷 컨텐츠-매칭 능력(Packet Content-Matching Capability), 컨텐츠-매칭(Content-Matching) 능력, 컨텍스트-매칭(Context-Matching) 능력, 공격-완화(Attack-Mitigation) 능력, 동작(Action) 능력, 성능(Performance) 능력과 같은 능력 정보를 포함할 수 있다. 각각에 대하여 설명하면 다음과 같다.
패킷 컨텐츠-매칭 능력: 보안 정책에서 사용될 수 있는 패킷 헤더 또는 페이로드로부터 획득되는 정보 또는 속성의 종류를 지칭함. 이 능력 정보는 패킷 L2/L3/L4 헤더, 또는 패킷 페이로드의 특수 세그먼트 내의 임의의 필드 또는 속성일 수 있다.
컨텐츠-매칭 능력: 이 능력은 어플리케이션 계층에 적용되는 보안 능력의 다른 카테고리이다. 어플리케이션 레이어에서 트래픽을 통해 운반되는 컨텐츠를 검출하는 것을 통해, 이 능력은 침입에 대한 방어, 바이러스 검사, 악성 URL 또는 정크 메일 필터링, 불법 웹 액세스 차단 또는 악성 데이터 검색 차단과 같은 다양한 보안 기능을 구현(realize)할 수 있다.
컨텍스트-매칭 능력: 이 능력은 수신된 패킷에 대한 컨텐츠 정보를 지칭한다. 이 능력은 사용자, 스케줄, 영역, 타겟, 상태 및 지시(direct) 정보일 수 있다.
공격-완화 능력: 이 능력은 다양한 타입의 네트워크 공격을 검출하고 완화하기 위해 사용된다. 예를 들면, 네트워크 공격은 DDoS 공격 및 단일-패킷 공격으로 분류될 수 있다.
동작 능력: NSF는 적어도 하나의 동작을 실행함으로써 보안 기능을 제공할 수 있다. 적어도 하나의 동작은 적어도 다음 동작의 일부 또는 전부를 포함한다.
- 허가(pass), 드랍(drop), 미러링(mirroring)과 같은 인그레스 동작(ingress action)
- 인보크 시그널링(invoke signaling), 터널 인캡슐레이션(tunnel encapsulation), 패킷 전달(packet forwarding) 및/또는 변환(transformation)과 같은 이그레스 동작(Egress actions)
- 특정 기능 프로파일 또는 서명(NSF 프로파일)의 적용. 이 기능 프로파일 또는 서명 파일은 컨텐츠 보안 제어 및/또는 공격 완화 제어를 위한 보안 능력을 정의한다. I2NSF의 하나의 목표는 벤더-특정 구현을 지원하면서 보안 성능의 기능적 인터페이스 및 형태(form)를 표준화하는 것이다.
성능 능력: 이 능력은 NSF의 처리 능력을 나타낸다. 즉, NSF가 단위 시간 기간 동안 얼마나 많은 양의 트래픽을 처리하는 지와 같은 처리 능력. 이 능력은 NSF가 현재 겪고 있는 작업로드와 이것을 비교함으로써 NSF가 혼잡 상태에 있는지를 결정하기 위해 사용될 수 있다. 또한, 이 능력은 NSF에서 이용가능한 처리 전력(processing power) 및 메모리와 같은 각 유형의 리소스의 이용가능한 양을 지정할 수 있다.
도 6은 본 발명의 일 실시예에 따른 NSF 응답 메시지를 예시한다.
NSF 운영 관리자는 시스템 내에서 운영중인 모든 NSF의 정보 테이블을 유지할 수 있다. 만일 NSF 운영 관리자가 NSFF로부터 쿼리를 수신한다면, NSF 운영 관리자는 쿼리에 포함된 NSF 프로파일과 매칭되는 NSF에 대한 테이블을 검색할 수 있다. 만일 복수의 후보 NSF들이 있다면, NSF 운영 관리자는 그 NSF들의 현재 워크로드 수준을 추가적으로 고려할 수 있다. NSF를 선택한 후에, NSF 운영 관리자는 선택된 NSF의 네트워크 전달 정보를 NSFF에 알려줄 수 있다. 예를 들면, NSF 운영 관리자는 NSF 응답 메시지를 통해 선택된 NSF의 네트워크 전달 정보를 NSFF에 제공할 수 있다.
도 6을 참조하면, NSF 응답 메시지는 NSF 프로파일 및/또는 네트워크 전달 정보를 포함할 수 있다. 실시예로서, 네트워크 전달 정보는 IP 주소, 지원되는 프로토콜 및/또는 위치 정보를 포함할 수 있다. 예를 들면, 네트워크 전달 정보는 IPv4 주소, IPv6 주소, 지원되는 전송 프로토콜 및/또는 위치 정보를 포함할 수 있다. 이하에서 각 정보(필드)에 대하여 설명한다.
IP 주소: NSF의 IP 주소를 지시함. NSF의 고유한 식별자로서, IP 주소는 NSF로 패킷을 전달하는 것을 허용하는 기본 네트워크 정보이다.
지원되는 전송 프로토콜: NSF가 지원하는 전송 프로토콜을 지시함. NSF로 패킷을 전달하기 위하여, NSF가 지원하는 전송 프로토콜을 알아내는 것일 필수적이다. 전송 프로토콜의 예로서, Virtual Extensible LAN (VXLAN), Generic Protocol Extension for VXLAN (VXLAN-GPE), Generic Route Encapsulation (GRE), Ethernet 등이 포함될 수 있다. NSFF는 전송 프로토콜에 정의된 바에 따라 전송을 위한 패킷의 인캡슐레이션을 수행할 수 있다.
위치 정보: NSF의 위치 정보를 제공함. 시스템 내의 NSF는 광범위한 물리적 영역(wide physical region)에 분산될 수 있다. IP 주소와 달리, 위치 정보는 NSF의 물리적 위치를 지정한다. 따라서, NSF 운영 관리자는 NSF를 선택하기 위한 추가적인 요인(factor)로서 물리적 근접성(physical proximity)을 고려할 수 있다.
## 이하에서는, 본 발명의 일 실시예에 따른 NSF-트리거된 트래픽 스티어링 프레임워크를 이용한 2가지의 실시예를 살펴본다.
(1) 패킷 소스의 신뢰 수준에 따른 상이한 NSF의 시행(Enforcing Different NSFs Depending on a Packet Source's Trust Level)
도 7은 본 발명의 일 실시예에 따른 I2NSF 시스템 내 트래픽의 흐름을 예시하는 도면이다. 도 7의 실시예에서, I2NSF 시스템은 NSF-트리거된 I2NSF 시스템 또는 SFC-이네이블된 시스템일 수 있다.
본 발명의 일 실시예에 따른 아키텍처에서, 아키텍처로 유입된(incoming) 모든 패킷은 최초로 NSFF에 도착한다. 도 7의 실시예에서는, 현재 보안 정책이 모든 유입된(incoming) 패킷이 기본적으로 방화벽에 의해 검사되도록 강제하는 것으로 가정한다. 따라서, NSFF는 수신한 패킷을 방화벽 인스턴스에게 전달한다.
방화벽은 트래픽의 소스(source)를 식별하고, 소스의 신뢰 수준을 평가할 수 있다. 예를 들면, 방화벽은 소스의 신뢰 수준을 평가함으로써, 네트워크 패킷(network packet)을 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류할 수 있다.
도 7(a)와 같이 만약, 트래픽이 신뢰되는 소스로부터 수신된 경우(또는 안전한 패킷(secure packet)으로 분류된 경우), 트래픽은 양성(benign)일 가능성이 있다. 이 경우, 트래픽은 추가의 세부적인 검사 없이 단순히 목적지(destination)로 전달될 수 있다.
반면, 도 7(b)와 같이 트래픽이 신뢰되지 않은 소스로부터 수신된 경우(또는 의심스러운 패킷(suspicious packet)으로 분류된 경우), 방화벽은 DPI에 해당하는 NSF 프로파일을 포함하는 패킷 전달 헤더를 패킷에 부착하고, NSFF에게 결과(resulting) 패킷(즉, 패킷 전달 헤더가 부착된 패킷)을 반환할 수 있다. 방화벽로부터 그 결과 패킷을 수신하면, NSFF는 해당 패킷을 패킷 페이로드에 대한 상세한 검사를 수행할 DPI 인스턴스에게 전달할 수 있다. DPI 인스턴스는 수신한 패킷의 페이로드에 대하여 상세한 검사를 수행할 수 있다. DPI 인스턴스에 의해 패킷 페이로드에 대하여 상세한 검사를 수행한 결과, 안전한 패킷(secure packet)으로 판정된 경우, 해당 패킷은 NSFF를 경유하여 목적지(destination)로 전달될 수 있다.
한편, 실시예에 따라서는 의심스로운 패킷으로 분류된 패킷만이 침입 탐지 시스템(intrusion detection system) 내 DPI 모듈을 통해 검사될 수 있다. 이 경우, 위험한 패킷은 방화벽에 의해 단순히 드랍(drop)(즉, 삭제)될 수도 있다. 이는 이미 안전하거나 위험한 것으로 분류된 패킷에 대한 불필요한 분석 작업을 방지함으로써 침입 탐지 시스템의 성능을 향상시키는 데 도움이 될 수 있다.
도 7(b)에서는 추가적인 검사를 위한 NSF로서 DPI를 예시하고 있으나 이는 하나의 예시에 불과하며 본 발명이 이에 한정되는 것은 아니고 다른 NSF가 이용될 수도 있다.
한편, 의심스러운 패킷(suspicious packet)으로 분류할 때 소스의 신뢰 수준을 고려하여 의심스러운 정도가 복수로 구분될 수도 있으며, 의심스러운 정도의 수준에 따라 NSF에 의한 추가적인 검사의 정도/횟수가 정해질 수도 있다.
(2) 동적 NSF 인스턴스화를 이용한 효과적인 로드 밸런싱(Effective Load Balancing with Dynamic NSF Instantiation)
도 8은 본 발명의 일 실시예에 따른 I2NSF 시스템 내 로드 밸런싱 방법을 예시하는 도면이다. 도 8의 실시예에서, I2NSF 시스템은 NSF-트리거된 I2NSF 시스템 또는 SFC-이네이블된 시스템일 수 있다.
대규모의 네트워크 도메인(domain)에서, 일반적으로 다양한 보안 서비스를 제공하는 다수의 NSF 인스턴스가 존재한다. 이때, 특정 NSF 인스턴스가 자신의 능력을 벗어나 과도한 트래픽 양을 겪을 수 있다. 이 경우, 트래픽의 일부를 또 다른 이용 가능한 동일 NSF의 인스턴스에게 할당하는 것이 요구된다.
만약, 동일 NSF의 이용 가능한 추가의 인스턴스가 없다면, 새로운 NSF 인스턴스를 생성하고, 새로운 인스턴스에게 다음의 트래픽이 향하도록 할 필요가 있다. 이렇게 함으로써, 서비스 혼잡을 방지하고, 더욱 효율적인 자원 활용을 달성할 수 있다.
이 프로세스는 공통적으로 로드 밸런싱으로 지칭될 수 있다.
본 발명의 일 실시예에 따른 아키텍처에서, NSF 운영 관리자는 이용 가능한 NSF 인스턴스의 트래픽 로드 상태를 주기적으로 모니터링할 수 있다. 또한, 본 발명의 일 실시예에 따르면, 개발자 관리 시스템을 통해 새로운 NSF 인스턴스가 동적으로 생성될 수 있다. 이러한 동적 NSF 인스턴스 생성이 트래픽 스티어링 메커니즘과 결합됨으로서 결국 로드 밸런싱 서비스를 제공할 수 있다.
도 8의 실시예에서는, 방화벽 인스턴스에서 혼잡이 발생되는 것으로 가정하고, 이 경우에 수행되는 로드 밸런싱의 상세한 프로세스를 예시적으로 설명한다.
(1 단계) NSF 운영 관리자는 현재 가용한 방화벽 인스턴스가 너무 많은 요청을 수신하였음을 감지한다. 즉, 방화벽 인스턴스에 과도한 트래픽이 발생하였음을 감지한다. 한편, 현재 추가로 이용 가능한 방화벽 인스턴스가 없다고 가정한다.
(2 단계) 추가로 이용 가능한 방화벽 인스턴스가 없으므로, NSF 운영 관리자가 개발자 관리 시스템에게 동일한 보안 서비스를 제공할 수 있는 새로운 방화벽 인스턴스의 생성을 요청한다.
(3 단계) 개발자 관리 시스템은 새로운 방화벽 인스턴스를 생성하고, 새로운 방화벽 인스턴스의 정보를 NSF 운영 관리자에게 등록한다.
(4 단계) NSF 운영 관리자는 새로운 방화벽 인스턴스를 반영하여 NSF 정보 테이블(NSF information table)을 업데이트하고, NSF 및 NSFF에게 이러한 업데이트를 알린다. NSF 정보 테이블은 SFC(Service Function Chaining) 정보 테이블로 지칭될 수도 있다.
(5 단계) 새로운 전달 정보(forwarding information)에 따라, NSFF는 다음의 트래픽을 새로운 방화벽 인스턴스에게 전달한다. 결과적으로, 이는 기존의 방화벽 인스턴스의 부담을 효과적으로 완화시킬 수 있다.
도 9는 본 발명의 일 실시예에 따른 네트워크 장치의 블록 구성도를 예시한다. 네트워크 장치는 상술한 I2NSF 시스템에 해당하거나, I2NSF 시스템 내에 포함되는 장치일 수 있다. I2NSF 시스템 내에 포함되는 장치의 예로는 상술한 I2NSF, 보안 제어기, 개발자 관리 시스템, NSF(또는 SF), NSFF(또는 SFF), 분류기, NSF 운영 관리자(또는, SFC 정책 관리자, SFC 카탈로그 관리자) 등이 포함될 수 있다.
도 9를 참조하면, 네트워크 장치(900)는 프로세서(processor, 910), 메모리(memory, 920) 및 통신 모듈(communication module, 930)을 포함한다.
프로세서(910)는 앞서 도 1 내지 도 8에서 제안된 기능, 과정 및/또는 방법을 구현한다. 메모리(920)는 프로세서(910)와 연결되어, 프로세서(910)를 구동하기 위한 다양한 정보를 저장한다. 통신 모듈(930)은 프로세서(910)와 연결되어, 유/무선 신호를 송신 및/또는 수신한다.
메모리(920)는 프로세서(910) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(910)와 연결될 수 있다.
도 10은 본 발명의 일 실시예에 따른 네트워크 장치의 데이터 전달 방법의 순서도이다. 도 10의 실시예에서 네트워크 장치는 도 2a의 NSFF 또는 2b의 SFF일 수 있다.
도 10을 참조하면, NSFF는 패킷에 대한 보안 검사를 수행하는 제1 NSF로부터 패킷을 수신할 수 있다. 실시예로서, 패킷은 추가적인 검사를 호출하기 위한 패킷 전달 헤더를 포함할 수 있다(S1010).
NSFF는 패킷 전달 헤더에 포함된 정보에 기초하여 추가적인 검사를 위해 요구되는 보안 능력을 가진 제2 NSF를 탐색할 수 있다(S1020). 실시예로서, 패킷 전달 헤더는 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드 및 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함할 수 있다.
제2 NSF를 탐색한 경우, NSFF는 제2 NSF에게 패킷을 전달할 수 있다(S1030). 또는, 제2 NSF를 탐색하지 못한 경우, NSFF는 NSF 운영 관리자에 의해 새로 생성된 제3 NSF에 패킷을 전달할 수 있다(S1040). 이를 위해, NSFF는 추가적인 검사를 위해 요구되는 보안 능력을 포함하는 NSF 생성 요청 패킷을 NSF 운영 관리자에게 전송하고, NSF 운영 관리자로부터 생성된 제3 NSF에 대한 정보를 수신하고, 제3 NSF에게 패킷을 전달할 수 있다.
실시예로서, NSF 운영 관리자는 이용 가능한 모든 NSF에 대한 정보 리스트를 관리하며, 정보 리스트 내에서 각 NSF의 트래픽 로드 상태를 고려하여 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 제3 NSF를 선택하고, 제3 NSF에 대한 정보를 상기 NSFF에게 전송할 수 있다.
실시예로서, NSF 운영 관리자는 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF에 대하여 과도한 트래픽이 발생됨을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 과도한 트래픽이 발생된 NSF와 동일한 보안 능력을 가지는 새로운 NSF의 생성을 요청할 수 있다.
실시예로서, NSF 운영 관리자는 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF가 이용되지 않음을 감지하면, 개발자 관리 시스템(developer's management system)에게 이용되지 않는 NSF의 제거를 요청할 수 있다.
이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(firmware), 소프트웨어 또는 그것들의 결합 등에 의해 구현될 수 있다. 하드웨어에 의한 구현의 경우, 본 발명의 일 실시예는 하나 또는 그 이상의 ASICs(application specific integrated circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서, 콘트롤러, 마이크로 콘트롤러, 마이크로 프로세서 등에 의해 구현될 수 있다.
펌웨어나 소프트웨어에 의한 구현의 경우, 본 발명의 일 실시예는 이상에서 설명된 기능 또는 동작들을 수행하는 모듈, 절차, 함수 등의 형태로 구현될 수 있다. 소프트웨어 코드는 메모리에 저장되어 프로세서에 의해 구동될 수 있다. 상기 메모리는 상기 프로세서 내부 또는 외부에 위치하여, 이미 공지된 다양한 수단에 의해 상기 프로세서와 데이터를 주고 받을 수 있다.
본 발명은 본 발명의 필수적 특징을 벗어나지 않는 범위에서 다른 특정한 형태로 구체화될 수 있음은 당업자에게 자명하다. 따라서, 상술한 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니 되고 예시적인 것으로 고려되어야 한다. 본 발명의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 발명의 등가적 범위 내에서의 모든 변경은 본 발명의 범위에 포함된다.
본 발명은 보안 서비스를 제공하는 다양한 시스템에 적용될 수 있다.

Claims (12)

  1. 네트워크 보안 기능(NSF) 전달자의 패킷 전달 방법에 있어서,
    패킷에 대한 보안 검사를 수행하는 제1 NSF로부터 상기 패킷을 수신하는 단계로서, 상기 패킷은 추가적인 검사를 호출하기 위한 패킷 전달 헤더를 포함하는, 상기 패킷을 수신하는 단계; 및
    상기 패킷 전달 헤더에 포함된 상기 추가적인 검사를 위해 요구되는 보안 능력을 가진 제2 NSF를 탐색한 경우, 상기 제2 NSF에게 상기 패킷을 전달하는 단계를 포함하는, 패킷 전달 방법.
  2. 제1항에 있어서,
    상기 패킷 전달 헤더는 상기 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 상기 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드 및 상기 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함하는, 패킷 전달 방법.
  3. 제1항에 있어서,
    상기 제2 NSF를 탐색하지 못한 경우, 상기 추가적인 검사를 위해 요구되는 보안 능력을 포함하는 NSF 생성 요청 패킷을 NSF 운영 관리자에게 전송하는 단계; 및
    상기 NSF 운영 관리자로부터 생성된 제3 NSF에 대한 정보를 수신하면 상기 제3 NSF에게 상기 패킷을 전달하는 단계를 포함하는, 패킷 전달 방법.
  4. 제3항에 있어서,
    상기 NSF 운영 관리자는 이용 가능한 모든 NSF에 대한 정보 리스트를 관리하며, 상기 정보 리스트 내에서 각 NSF의 트래픽 로드 상태를 고려하여 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 상기 제3 NSF를 선택하고, 상기 제3 NSF에 대한 정보를 상기 NSFF에게 전송하는, 패킷 전달 방법.
  5. 제3항에 있어서,
    상기 NSF 운영 관리자는 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF에 대하여 과도한 트래픽이 발생됨을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 과도한 트래픽이 발생된 NSF와 동일한 보안 능력을 가지는 새로운 NSF의 생성을 요청하는, 패킷 전달 방법.
  6. 제3항에 있어서,
    상기 NSF 운영 관리자가 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF가 이용되지 않음을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 이용되지 않는 NSF의 제거를 요청하는, 패킷 전달 방법.
  7. 네트워크 보안 기능(NSF) 전달자에 있어서,
    데이터를 통신하는 통신 모듈; 및
    상기 통신 모듈을 제어하는 프로세서를 포함하며,
    상기 프로세서는,
    패킷에 대한 보안 검사를 수행하는 제1 NSF로부터 상기 패킷을 수신하고, 상기 패킷은 추가적인 검사를 호출하기 위한 패킷 전달 헤더를 포함하며; 및
    상기 패킷 전달 헤더에 포함된 상기 추가적인 검사를 위해 요구되는 보안 능력을 가진 제2 NSF를 탐색한 경우, 상기 제2 NSF에게 상기 패킷을 전달하는, NSF 전달자.
  8. 제7항에 있어서,
    상기 패킷 전달 헤더는 상기 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 상기 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드 및 상기 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함하는, NSF 전달자.
  9. 제7항에 있어서,
    상기 프로세서는,
    상기 제2 NSF를 탐색하지 못한 경우, 상기 추가적인 검사를 위해 요구되는 보안 능력을 포함하는 NSF 생성 요청 패킷을 NSF 운영 관리자에게 전송하고; 및
    상기 NSF 운영 관리자로부터 생성된 제3 NSF에 대한 정보를 수신하면 상기 제3 NSF에게 상기 패킷을 전달하는 것을 더 포함하는, NSF 전달자.
  10. 제9항에 있어서,
    상기 NSF 운영 관리자는 이용 가능한 모든 NSF에 대한 정보 리스트를 관리하며, 상기 정보 리스트 내에서 각 NSF의 트래픽 로드 상태를 고려하여 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 상기 제3 NSF를 선택하고, 상기 제3 NSF에 대한 정보를 상기 NSFF에게 전송하는, NSF 전달자.
  11. 제9항에 있어서,
    상기 NSF 운영 관리자는 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF에 대하여 과도한 트래픽이 발생됨을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 과도한 트래픽이 발생된 NSF와 동일한 보안 능력을 가지는 새로운 NSF의 생성을 요청하는, NSF 전달자.
  12. 제9항에 있어서,
    상기 NSF 운영 관리자가 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF가 이용되지 않음을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 이용되지 않는 NSF의 제거를 요청하는, NSF 전달자.
PCT/KR2018/002956 2017-03-13 2018-03-13 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치 WO2018169293A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20170031426 2017-03-13
KR10-2017-0031426 2017-03-13

Publications (1)

Publication Number Publication Date
WO2018169293A1 true WO2018169293A1 (ko) 2018-09-20

Family

ID=63523692

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/002956 WO2018169293A1 (ko) 2017-03-13 2018-03-13 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치

Country Status (1)

Country Link
WO (1) WO2018169293A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6163843A (en) * 1996-10-25 2000-12-19 Kabushiki Kaisha Toshiba Packet inspection device, mobile computer and packet transfer method in mobile computing with improved mobile computer authenticity check scheme
US20040042609A1 (en) * 2002-09-04 2004-03-04 Tekelec Methods and systems for enhancing network security in a telecommunications signaling network
US20100269171A1 (en) * 2009-04-20 2010-10-21 Check Point Software Technologies, Ltd. Methods for effective network-security inspection in virtualized environments
US20150207813A1 (en) * 2012-02-01 2015-07-23 Vorstack, Inc. Techniques for sharing network security event information
US9264400B1 (en) * 2013-12-02 2016-02-16 Trend Micro Incorporated Software defined networking pipe for network traffic inspection

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6163843A (en) * 1996-10-25 2000-12-19 Kabushiki Kaisha Toshiba Packet inspection device, mobile computer and packet transfer method in mobile computing with improved mobile computer authenticity check scheme
US20040042609A1 (en) * 2002-09-04 2004-03-04 Tekelec Methods and systems for enhancing network security in a telecommunications signaling network
US20100269171A1 (en) * 2009-04-20 2010-10-21 Check Point Software Technologies, Ltd. Methods for effective network-security inspection in virtualized environments
US20150207813A1 (en) * 2012-02-01 2015-07-23 Vorstack, Inc. Techniques for sharing network security event information
US9264400B1 (en) * 2013-12-02 2016-02-16 Trend Micro Incorporated Software defined networking pipe for network traffic inspection

Similar Documents

Publication Publication Date Title
WO2021060857A1 (ko) 원격 실행 코드 기반 노드의 제어 플로우 관리 시스템 및 그에 관한 방법
US11057349B2 (en) Cloud-based multi-function firewall and zero trust private virtual network
US7917621B2 (en) Method and system for network access control
Yu et al. PSI: Precise Security Instrumentation for Enterprise Networks.
CN113055369B (zh) 软件定义网络中的安全
US7853998B2 (en) Firewall propagation
WO2014185754A1 (ko) M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
WO2018101565A1 (ko) 네트워크 가상화 환경에서 보안 관리를 위한 구조
WO2014209075A1 (ko) 인터넷 프로토콜을 이용한 서비스를 위한 다중 연결 시스템 및 방법
WO2012091529A2 (ko) 단말기
US20060059552A1 (en) Restricting communication service
EP4222920A1 (en) Dynamic optimization of client application access via a secure access service edge (sase) network optimization controller (noc)
MXPA06013129A (es) Contencion automatizada de un invasor en redes.
WO2016013846A1 (ko) 무선 통신 시스템에서 요청 메시지를 처리하기 위한 방법 및 이를 위한 장치
WO2019088671A1 (ko) 네트워크 보안 서비스를 제공하기 위한 방법 및 이를 위한 장치
JP6052692B1 (ja) セキュリティ管理方法、プログラム、およびセキュリティ管理システム
WO2023211124A1 (ko) 컨트롤러 기반의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2019098678A1 (ko) 보안 서비스를 제공하기 위한 방법 및 이를 위한 장치
WO2023177238A1 (ko) 컨트롤러 기반의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
WO2017131285A1 (ko) 컨테이너 네트워크 관리 시스템 및 컨테이너 네트워킹 방법
WO2023163514A1 (ko) 컨트롤러 기반의 네트워크 접속을 제어하기 위한 시스템 및 그에 관한 방법
CN111295640A (zh) 使用会话app id和端点进程id相关性的精细粒度防火墙策略实施
WO2018097422A1 (ko) 네트워크 보안 기능에 의해 트리거되는 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치
US20070011732A1 (en) Network device for secure packet dispatching via port isolation
WO2018169293A1 (ko) 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18766651

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18766651

Country of ref document: EP

Kind code of ref document: A1