WO2018097422A1 - 네트워크 보안 기능에 의해 트리거되는 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치 - Google Patents

네트워크 보안 기능에 의해 트리거되는 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치 Download PDF

Info

Publication number
WO2018097422A1
WO2018097422A1 PCT/KR2017/004510 KR2017004510W WO2018097422A1 WO 2018097422 A1 WO2018097422 A1 WO 2018097422A1 KR 2017004510 W KR2017004510 W KR 2017004510W WO 2018097422 A1 WO2018097422 A1 WO 2018097422A1
Authority
WO
WIPO (PCT)
Prior art keywords
nsf
packet
security
nsff
traffic
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/KR2017/004510
Other languages
English (en)
French (fr)
Inventor
정재훈
현상원
우상욱
여윤석
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sungkyunkwan University
Original Assignee
Sungkyunkwan University
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 Sungkyunkwan University filed Critical Sungkyunkwan University
Publication of WO2018097422A1 publication Critical patent/WO2018097422A1/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

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 by a network security function (NSF), and apparatus for the same.
  • NSF network security function
  • NFV Network Functions Virtualization
  • NSF Network Security Function
  • a security check for a packet introduced into the system is performed, and the security is performed. Based on the result of the inspection, it is determined whether additional inspection by another NSF is necessary, and if the additional inspection is necessary, a packet forwarding header for attaching the additional inspection is attached to the packet, and When searching for a first NSF for transmitting a packet with a packet forwarding header to an NSF forwarder (NSFF) and a second NSF having the security capability required for the additional check included in the packet forwarding header, It may include an NSFF for delivering the packet to a second NSF.
  • NSF forwarder NSF forwarder
  • the packet forwarding header may include an action code field including a result of a security check of the packet, a capability information field including security capability information required for the additional inspection, and a capability information indicating a number of the capability information fields. It may include a number field.
  • the packet introduced into the system may be received by the NSFF and forwarded by the NSFF to the first NSF.
  • the first NSF causes the packet to be a secure packet, a dangerous packet, and a suspicious packet. Can be classified.
  • the packet when the packet is classified as a secure packet, it may be delivered to another destination through the NSF without further security check.
  • the packet may be dropped.
  • the packet when the packet is classified as the suspicious packet, the packet may be delivered to the NSFF with the packet forwarding header attached.
  • the method may further include an NSF operation management for managing a list of information about all available NSFs.
  • the NSFF sends an NSF generation request packet containing the security capabilities required for the further inspection to the NSF operations manager, and a third generated from the NSF operations manager.
  • the NSF operations manager is the first having the security capability required for the further inspection in consideration of the traffic load status of each NSF in the information list 3 NSF may be selected and information on the third NSF may be transmitted to the NSFF.
  • the developer's management system Preferably, if there is no NSF in the information list with the security capability required for the additional inspection, the developer's management system generates a NSF having the security capability required for the additional inspection. You can request
  • the NSF operations manager monitors the traffic load status of all available NSFs and detects that excessive traffic is generated for a particular NSF
  • the developer's management system is identical to the NSF in which the excessive traffic is generated. May request the creation of a new NSF with security capabilities.
  • the NSF operations manager may request the developer's management system to remove the unused NSFs. .
  • a network security function performs traffic steering
  • security of a packet introduced to a system supporting the traffic steering is provided.
  • Performing a check determining whether an additional check by another NSF is necessary based on a result of the security check, and if a further check is needed, a packet forwarding header to invoke the additional check Attaching the packet forwarding packet to the NSF forwarder (NSFF), wherein the packet forwarding header is configured for the security capability required for the further inspection. May contain information.
  • the packet forwarding header may include an action code field including a result of a security check of the packet, a capability information field including security capability information required for the additional inspection, and a capability information indicating a number of the capability information fields. It may include a number field.
  • the packet is secured, dangerous and suspicious by the first NSF according to the trust level of the source of the packet. Can be classified.
  • 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.
  • NSF-triggered NSF-triggered
  • FIG. 3 is a diagram illustrating an information model for NSF capability in an NSF-triggered traffic steering system in accordance with an embodiment of the present invention.
  • FIG 4 illustrates an information model (IM) for NSF (s) with packet filtering capability in accordance with an embodiment of the present invention.
  • IM information model
  • FIG. 5 is a diagram for conceptually explaining traffic steering according to an embodiment of the present invention.
  • FIG. 6 illustrates a packet forwarding header according to an embodiment of the present invention.
  • FIG. 7 is a diagram illustrating the flow of traffic in a traffic steering system triggered by an NSF (NSF-triggered) according to an embodiment of the present invention.
  • FIG. 8 is a diagram illustrating the flow of traffic in a traffic steering system triggered by NSF-triggered according to an embodiment of the present invention.
  • FIG. 9 is a diagram illustrating a load balancing method in a NF-triggered traffic steering system according to an embodiment of the present invention.
  • FIG. 10 through 13 illustrate a step-by-step procedure performed on an incoming VoIP / VoLTE packet utilizing the traffic steering framework triggered by the NSF according to an embodiment of the present invention.
  • FIG. 14 illustrates a method of traffic steering triggered by NSF-triggered according to an embodiment of the present invention.
  • FIG. 15 illustrates a block diagram of an apparatus in a NSF-triggered traffic steering system in accordance with an embodiment of the present invention.
  • 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
  • NSFs network security functions
  • I2NSF Interface to Network Security
  • IM information model
  • NFI NSF-Facing Interface
  • 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 present invention proposes an architecture for integrating additional components for traffic steering through NSF into the I2NSF framework.
  • the high-level policy of NSF-triggered traffic steering triggered (or NSF-triggered) by NSF is interpreted / transformed and managed as a low level policy.
  • the NSF instance (s) available and the information (eg network information and workload) of the NSF instance (s) are tracked and the NSF to be used for a given security function. You can determine the instance.
  • the Network Security Function Forwarder may perform network traffic steering through the required NSF (s).
  • the NSFF can perform advanced inspection by interpreting inspection results from the NSF.
  • an additional packet header format for specifying a security inspection result and an advanced inspection request may be defined.
  • the present invention has the following effects largely.
  • 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).
  • Network traffic steering for continuous inspection In the NSF-triggered traffic steering architecture according to the present invention, network traffic may be steered through a plurality of required NSF (s) based on a triggering policy.
  • the I2NSF Information Model (IM) for the NSF facing interface (NFI) requires the NSF to call another NSF for further inspection based on its inspection results.
  • traffic may be forwarded from one NSF to another NSF.
  • the NSF-triggered traffic steering architecture provides load balancing of traffic entering the available NSF instances by leveraging a flexible traffic steering mechanism. .
  • an NSF when an NSF has an excessive request for a security function, it can perform dynamic instantiation of the NSF (ie, create a new NSF that can perform that security function).
  • NSF Network Security Function
  • OSI Open System Interconnection
  • a firewall for example, as an example of a network security service function type, a firewall, an intrusion prevention system (IPS) / intrusion detection system (IDS), and a deep packet inspection (DPI) , Application Visibility and Control (AVC), Network Virus and Malware Scanning, Sandbox, Data Loss Prevention (DLP), Distribute Denial of Service (DDoS), A transport layer security (TLS) proxy, anti-spoofing, and the like may be included.
  • the NSF according to the present invention may be implemented in any of the above examples, and various types of NSF may be used. In addition, multiple NSFs of the same type may be implemented. In addition, the NSF according to the present invention may be implemented by combining any one or more of the above-described examples.
  • Advanced Inspection / Action Like the I2NSF Information Model (IM) for NFI-facing interface (NFI), Advanced Inspection / Action allows NSF to add to another NSF based on its inspection results. It means a call to check.
  • IM I2NSF Information Model
  • NFI NFI-facing interface
  • NSF Profile The NSF Profile represents NSF's security inspection capabilities. Each NSF may have its own NSF Profile to specify the type of security services it provides, its resource capabilities, and so on.
  • NSF Operation Manager refers to a device that continuously manages NSF instance information and status and provides NSF network access information to support advanced inspection requests. do.
  • 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 Operation Manager is responsible for the dynamic management of the pool of NSF instances by negotiating with the Developer's Management System and by load balancing the entire NSF instances.
  • the Packet Forwarding Header is used to forward packets from one NSF to another for further inspection.
  • the former NSF ie, source NSF
  • the required field may include an action code, a number of metadata, and metadata.
  • the metadata may include a part or all of the NSF profile, and may be referred to as a spec info field in a Packet Forwarding Header to be described later.
  • Network Security Function Forwarder (NSFF) (or Security Function Forwarder (SFF): When traffic is forwarded from the NSF, the NSFF is connected to one or more connections according to the information passed within the packet forwarding encapsulation. Means a device that delivers traffic to NSF. Thus, the NSFF may pass traffic to another NSFF (the same or another type of overlay) and terminate the overlay check.
  • NSF-triggered NSF-triggered
  • an NSF-triggered traffic steering architecture may be referred to as an I2NSF user (or user device), a network operator management security controller, or simply a security controller. May be configured as a vendor's management system (VMS), an NSF (or NSF device), and an NSF forwarder (NSFF) (or NSFF device).
  • the Network Operator Management Security Controller may include an NSF Operation Manager (or NSF Operation Manager device).
  • the architecture according to FIG. 1 supports composite inspection of a packet being transmitted. According to the inspection result of each NSF stored in the Packet Forwarding Header, the traffic packet may be steered to another NSF for detailed analysis.
  • I2NSF users or I2NSF clients that are components of existing I2NSF frameworks.
  • the architecture proposed in the present invention can provide load balancing, automatic NSF instance creation and supplemental NSF instance removal.
  • I2NSF User An I2NSF user represents an administrator (or administrator device) of an enterprise network that receives network services through the network operator's infrastructure.
  • I2NSF users also need to use network security services to protect enterprise network traffic from various malicious attacks.
  • an I2NSF user may specify a high-level security policy of a desired security service and notify a high-level security policy to a security controller.
  • the I2NSF user In preparing high-level security policy, the I2NSF user does not consider the type of NSF (s) required to implement a security service or security policy rule configuration for each NSF (s). You may not.
  • the I2NSF user may be informed of the security event (s) occurring in the underlying NSF (s) by the Security Controller.
  • security event s
  • I2NSF users can identify new attacks and update (or create) high-level security policies to counter new attacks.
  • Network Operator Management Security Controller (Security Controller): The Security Controller is managed by the network operator.
  • One of the main roles of the Security Controller is to translate high-level security policies (or policy rules) from I2NSF users into low-level security policy rules for specific NSF (s).
  • the Security Controller may first determine the type of NSF (s) required to enforce the policy required by the I2NSF user. The Security Controller can then create a low-level security policy for each NSF (s) required. Eventually, the Security Controller can set the generated low-level security policy to each NSF (s).
  • the Security Controller can monitor running NSF (s) in the system and maintain various information about each NSF (s) (eg, network access information and workload status, etc.). .
  • the Security Controller can dynamically manage a pool of NSF instances through dynamic life-cycle management of the NSF instances.
  • NSF Operation Manager is responsible for the following three operations.
  • NSF Internet Protocol
  • the NSF Operation Manager corresponds to a lower module of the Security Controller.
  • the Developer's Management System may deliver information of the registered NSF instance to the NSF Operation Manager. Accordingly, the NSF Operation Manager may maintain an information list of all available NSF instances.
  • the NSF Operation Manger may receive a request packet (eg, an NSF generation request packet) including an NSF profile (ie, security capability information) for advanced inspection from the NSFF.
  • a request packet eg, an NSF generation request packet
  • an NSF profile ie, security capability information
  • the NSF Operation Manger can retrieve all available NSF instances that can apply that NSF profile. The best instance can be found using selection criteria such as NSF location and traffic load status.
  • the search result (that is, the optimal instance) may be returned to the NSFF.
  • each NSF instance may periodically report its load status to the NSF Operation Manger. Based on this report, the NSF Operation Manger may update the information of the NSF instance.
  • a pool of NSF instances can be managed by requesting the Developer's Management System for additional instantiation (ie, additional NSF instance creation) or elimination (demination / destruct) of the NSF instance. As a result, the NSF Operation Manger enables efficient resource utilization by preventing congestion and waste of resources.
  • Developer's Management System may be referred to as Vendor's Management System. Developer's Management System may be managed by a third-party security vendor that provides NSF (s) to network operators. There may be multiple Developer's Management System (s) from various security vendors.
  • the Developer's Management System can be extended for additional functions as follows.
  • the Developer's Management System may create new NSF instance (s) or eliminate / destruct existing NSF instance (s) that are no longer used. .
  • the NSF Operation Manager may request the Developer's Management System to create an additional NSF instance when the existing instance of the NSF is congested.
  • the NSF Operation Manager may request the Developer's Management System to remove some of the NSF instances.
  • the Developer's Management System may create and / or remove an NSF instance. After creating a new NSF instance or removing an existing NSF instance, the Developer's Management System can notify the NSF Operation Manager of the change.
  • NSF and NSF Forwarder (NSFF):
  • NSF eg, firewall, DPI, Denial of Service (MIT) attack mitigator, etc.
  • MIT Denial of Service
  • the NSF in the architecture according to the present invention is advanced security inspection (e.g., DPI and distributed denial of service attack mediators (DDoS) to different NSF types based on their security inspection results.
  • DPI distributed denial of service attack mediators
  • DDoS distributed denial of service attack mediators
  • Service attack mitigator for example, a firewall can 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.
  • NSFF is illustrated as a separate component from the Security Controller and the NSF, but the present invention is not limited thereto.
  • NSFF is a logical component that can be included in any of the Security Controller or NSF (ie, implemented together as a device).
  • CFI Consumer-Facing Interface
  • This interface The main purpose of this interface is to allow users to request security services from the I2NSF system. It is also for the Security Controller to forward security alerts received from the underlying NSF (s) to the user via this CFI. By analyzing the alerts received, users can identify new attacks and update (or create) high-level security policies to counter new attacks.
  • NFI NSF-Facing Interface
  • 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.). Therefore, when setting security policy rules to NSF, the Security Controller does not need to consider vendor specific differences and / or form factors of NSF.
  • the Security Controller can deliver a flow-based security policy to each target NSF in order to enforce the high-level security policy by the I2NSF user.
  • the Security Controller may trigger a control command to the NSF (s) via the NFI interface.
  • Each NSF can also use the NFI interface to periodically inform the Security Controller of its current status (eg, workload level, congestion, etc.).
  • the NSF may report it to the Security Controller via the NFI interface.
  • Each NSFF may receive forwarding information of the NSF running in the system through the NFI interface from the Security Controller. In this case, when the NSFF does not have forwarding information for delivering a given traffic, the NSFF may transmit a query of information to the Security Controller through the NFI interface.
  • RI Registration Interface
  • the RI is located between the Security Controller and the Developer's Management System.
  • the primary purpose of RI is to perform dynamic life-cycle management of NSF instances and to register new NSF instances on the system.
  • the Security Controller can request the Developer's Management System to create a new NSF.
  • the request of the Security Controller includes a profile of the requested NSF instance, and this profile may specify a security capability and a service capacity to be provided by the NSF instance.
  • the Developer's Management System creates a new NSF instance that satisfies the requested NSF profile and tells the Security Controller the network access information (eg, Internet Protocol) of this new NSF instance. Address, port number, etc.).
  • the network access information can be used as a unique identifier of a new NSF instance in the system.
  • the Security Controller can request the Developer's Management System to destruct the NSF instance.
  • This destruction request may include a unique identifier of the NSF instance to be removed.
  • Service Function Chain / Chaining is a technology that enables this by steering traffic through multiple service functions (eg, NSF).
  • Step 1 SFC configuration & management for traffic (ie, packet) is predefined.
  • Step 2 The traffic (i.e., packet) introduced into the I2NSF architecture is first classified using the predefined SFC configuration & management. That is, the service function path (SFP) for determining which NSF the traffic is inspected is determined.
  • SFP service function path
  • Step 3 Traffic is traffic steered through the determined SFP. That is, the traffic is delivered to the NSF1 via a service function forwarder (SFF) according to the determined SFP.
  • SFF service function forwarder
  • Step 4 After the inspection is performed by NSF1, the traffic is forwarded to NSF2 via SFF. At this time, the SFP determined for the corresponding traffic is also delivered.
  • the SFP for the traffic is determined according to a predefined SFC configuration & management.
  • the inspection path of traffic (that is, the path of NSF) is not predetermined and is determined dynamically.
  • FIG. 3 is a diagram illustrating an information model for NSF capability in an NSF-triggered traffic steering system in accordance with an embodiment of the present invention.
  • the NSF in the I2NSF architecture performs advanced security inspection (i.e., advanced security inspection) (e.g. DPI and DDoS attack mitigation) to different NSF types based on its security inspection results.
  • advanced security inspection e.g. DPI and DDoS attack mitigation
  • Can trigger e.g., a firewall can use DPI to trigger further inspection of suspicious packets.
  • the NSF can dynamically determine which advanced security action should be performed during DPI and DDos Mitigator based on the forwarder (FW) based on its security check result. have.
  • IM information model
  • DM data model
  • FIG 4 illustrates an information model (IM) for NSF (s) with packet filtering capability in accordance with an embodiment of the present invention.
  • IM information model
  • an information model (IM) and a data model (DM) can be defined to set up a standardized interface to NSF (s) of various security solution vendors.
  • NSF NSF
  • IM may be defined for each category of NSF (s).
  • the main purpose of an IM is to define a comprehensive model to represent security policy rules for NSF (s) in the same category.
  • the IM defines all required data items based on the concept of Event-Condition-Action (ECA) rules, and hierarchically structures the data items. It can be classified according to its characteristics.
  • ECA Event-Condition-Action
  • DM data model
  • each related NSF may be pre-configured with the implemented DM.
  • the Security Controller can express the security policy rule according to a specific format in the DM.
  • I2NSF can use extensible markup language (XML) to encode security policy rules
  • XML-encoded security policy rules can use the Network Configuration Protocol (NETCONF). May be passed to the NSF (s).
  • NETCONF Network Configuration Protocol
  • the NSF can decode the received security policy rule based on a matching DM that is already pre-set, and extract the content from the received security policy rule. As a result, the NSF can register the received content in its policy rule table.
  • steps 1 to 3 may be skipped compared to the conventional SFC approach illustrated in FIG. 2.
  • the traffic (i.e., packet) introduced in the I2NSF architecture is defined in the predefined SFC configuration and management (SFC configuration).
  • step 2 of classifying the traffic for the first time using the & management and step 3 of traffic steering through the determined SFP can be omitted.
  • the approach that is friendly to the SFC architecture is an existing standard and is suitable for applying static service functional paths.
  • the proposal of the present invention which is friendly to the I2NSF framework, does not predefine NSF path establishment and management.
  • no classifier and initial classification are required.
  • no re-classification is required.
  • FIG. 5 is a diagram for conceptually explaining traffic steering according to an embodiment of the present invention.
  • the NSF in the I2NSF architecture may trigger advanced security actions (e.g. DPI and DDoS attack mitigation) with different NSF types based on their security check results.
  • advanced security actions e.g. DPI and DDoS attack mitigation
  • the traffic introduced in the I2NSF architecture is inspected by NSF1, NSF1 can trigger a security check of NSF2 based on its security check results, NSF2 based on the security check results of NSF3 It can trigger a security check, and NSF3 can trigger a security check of NSF4 based on its security check results.
  • NSF When triggering an advanced security action, NSF can now add metadata to the suspicious packet, which describes the security capabilities required for the advanced security action.
  • the current NSF forwards the packet to the NSFF for delivery to the next NSF.
  • NSFF performs a function (that is, traffic steering) of transmitting a packet from one NSF instance to another NSF instance.
  • the NSFF (or NSF Operation Manager) may maintain a forwarding information table of available NSF instances in the system. After receiving the packet to forward, the NSFF may first search the table for the NSF instance that matches the required security capability specified in the metadata added to the packet.
  • the NSFF can negotiate with the Security Controller (or NSF operation manager) which NSF instance is the next NSF instance for delivering packets. In other words, if the NSFF does not find any matching entry, the NSFF may send a query of the NSF instance to the Security Controller with the required security capability.
  • the Security Controller or NSF operation manager
  • the Security Controller (or NSF operation manager) can also maintain a table of information (ie, NSF information table) of all currently running NSF instance (s) in the system.
  • the information of the NSF instance may include one or more of NSF profile, delivery information (ie, IP address, VxLAN, etc.), NSF capability, and NSF load status.
  • delivery information ie, IP address, VxLAN, etc.
  • NSF capability ie, IP address, VxLAN, etc.
  • NSF load status ie, IP address, VxLAN, etc.
  • the Security Controller (or NSF operation manager) receives a query from the NSFF, the Security Controller (or NSF operation manager) can search the table for the NSF instance that matches the requested security capability.
  • the security controller may provide the NSFF with delivery information of the selected NSF instance.
  • the Security Controller or NSF operation manager
  • the Security Controller or NSF operation manager responds to the NSFF with forwarding information of the found NSF instance.
  • the Security Controller (or NSF operation manager) requests a dynamic instantiation (ie, NSF generation) or elimination from the developer's management system.
  • the Security Controller (or NSF operation manager) may request the Developer's Management System to create a new NSF instance with the required security capability through the RI.
  • the Developer's Management System can reside in a third party domain (eg, an NSF vendor's cloud).
  • a third party domain eg, an NSF vendor's cloud.
  • Developer's Management System can create NSF instance based on Security Controller's request. Afterwards, the Security Controller informs the NSFF of the forwarding information of the created NSF instance.
  • the Security Controller may request NSF instantiation or elimination from the Developer's Management System based on the current state of the NSF instance (ie, whether the load is heavy or unused).
  • the Developer's Management System can create additional NSF instances when existing NSF instances are congested, and can also remove one or more unused NSF instances.
  • the NSFF may forward the packet to the target NSF instance using forwarding information from its forwarding information table or received from the Security Controller.
  • FIG. 6 illustrates a packet forwarding header according to an embodiment of the present invention.
  • the length of the field may be variable as shown in FIG.
  • the Packet Forwarding Header may include a fixed Action or Action Code field, a SpecInfo Num field, and a variable Capability Information (SpecInfo) field (s). Can be.
  • SpecInfo variable Capability Information
  • the Action Code field may include a security check result for the packet.
  • the SpecInfo Num field indicates how many SpecInfo fields (ie, metadata) are included in a packet forwarding header.
  • Each SpecInfo field may include information on security capability required for the next security check. That is, it may include a part of the NSF profile. If a Packet Forwarding Header including a plurality of SpecInfo fields is attached to the packet, the packet may be delivered to the plurality of NSFs matching the service profile of the NSF in each SpecInfo field through the NSFF to perform additional inspection.
  • the SepcInfo field may include "SYN flood mitigation (syn-flood-mitigate)", “UDP flood mitigation (udp-flood-mitigate)", etc., which are service profiles of the NSF.
  • SYN floods are a form of DoS attack in which an SYN request is sent to a target system in order to use sufficient server resources to prevent the attacker from responding to legitimate traffic.
  • UDP flood attacks are a form of DoS attack that uses the User Datagram Protocol (UDP), a sessionless / connectionless computer networking protocol.
  • UDP User Datagram Protocol
  • NSFF network security function forwarder
  • SFF security function forwarder
  • NSFF is responsible for two functions:
  • NSF Network Security Sub-Module
  • NSFF first receives the incoming traffic / packet using the gateway function.
  • the NSFF attaches an outer encapsulation to the traffic / packet to deliver the traffic / packet to the Network Security Sub-Module (ie, NSF).
  • NSF Network Security Sub-Module
  • the Network Security Sub-Module may correspond to a firewall that performs packet header inspection.
  • This Network Security Sub-Module attaches a Packet Forwarding Header between the outer encapsulation and the origin packet.
  • the NSF profile in the Packet Forwarding Header is specified so that the packet can be delivered to a Content Security Sub-Module or a Mitigation Sub-Module for advanced inspection.
  • the NSFF Upon receiving a packet with a Packet Forwarding Header of a specific NSF profile from the Network Security Sub-Module, the NSFF searches for available NSF instances that provide network security services corresponding to (ie, matching) the NSF profile. The NSFF forwards the packet to the found NSF instance.
  • the NSF constructs a packet forwarding header specified in (ie, containing) the NSF profile of the advanced NSF, and assigns the header to the packet. Attach. The packet is then transmitted to the NSFF.
  • the NSFF Upon receiving the packet, the NSFF checks the specified NSF profile in the packet forwarding header. The NSFF finds an NSF instance matching the NSF profile by negotiating with the NSF Operation Manager and delivers a packet to the corresponding NSF instance.
  • FIG. 7 is a diagram illustrating the flow of traffic in a traffic steering system triggered by an NSF (NSF-triggered) according to an embodiment of the present invention.
  • NSFF forwards the received packet to the firewall instance.
  • the firewall can identify the source of traffic and evaluate the source's trust level.
  • a firewall filter may first classify a network packet into secure packets, dangerous packets, and suspicious packets. As described above, by evaluating the trust level of the source, it can be classified into a secure packet, a dangerous packet, and a suspicious packet.
  • traffic may simply be delivered to the destination without further inspection. .
  • the firewall when traffic is received from an untrusted source (or classified as a suspicious packet) as shown in FIG. 7 (a), the firewall sends a packet forwarding header including an NSF profile corresponding to the DPI. And a packet with a packet forwarding header attached to the NSFF.
  • the NSFF may forward the packet to the DPI instance.
  • 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.
  • the dangerous packet may be simply dropped (ie, dropped) by the firewall filter.
  • This method can help improve the performance of intrusion detection systems by avoiding unnecessary analysis of packets that are already classified as safe or dangerous.
  • FIG. 7 (a) illustrates DPI as an NSF for additional inspection, this is only one example and the present invention is not limited thereto, and another NSF may be used.
  • the degree of suspicion when classifying a suspicious packet, the degree of suspicion may be divided into plural in consideration of the level of reliability of the source, and the degree / number of additional checks by the NSF may be determined according to the level of suspicion. Can be done. This will be described in more detail with reference to FIG. 8.
  • FIG. 8 is a diagram illustrating the flow of traffic in a traffic steering system triggered by NSF-triggered according to an embodiment of the present invention.
  • Step 2 The packet may be evaluated for a trust level by the firewall instance.
  • NSFF forwards the received packet to the firewall instance.
  • the firewall can identify the source of traffic and evaluate the source's trust level.
  • a firewall filter may first classify a network packet into secure packets, dangerous packets, and suspicious packets. As described above, by evaluating the trust level of the source, it can be classified into a secure packet, a dangerous packet, and a suspicious packet.
  • a suspicious degree when classifying a suspicious packet, a suspicious degree may be divided into a plurality in consideration of a level of reliability of a source.
  • the degree / number of additional tests by the NSF may be determined. For example, suppose that the level of suspiciousness of a packet is divided into two levels, and the greater the degree of suspicion, the larger the level is determined. In this case, when the level of suspiciousness of the packet is 1 level as a result of classification of the packet by the firewall instance, additional inspection by IDS / IPS may be performed.
  • the firewall attaches a packet forwarding header containing the NSF profile corresponding to the IDS / IPS to the packet, and attaches the packet forwarding header to the NSFF. Can return packet.
  • Step 3 the packet can be examined in detail by IDS / IPS.
  • the NSFF may forward the packet to the IDS / IPS instance.
  • the IDS / IPS instance may perform detailed inspection on the received packet.
  • the IDS / IPS instance may return the packet to the NSFF.
  • the IDS / IPS instance may drop the packet.
  • Step 4 After receiving the packet from the IDS / IPS instance, the NSFF may forward the packet to a destination.
  • Step 2 The packet may be evaluated for a trust level by the firewall instance.
  • NSFF forwards the received packet to the firewall instance.
  • the firewall can identify the source of traffic and evaluate the source's trust level.
  • a firewall filter may first classify a network packet into secure packets, dangerous packets, and suspicious packets. As described above, by evaluating the trust level of the source, it can be classified into a secure packet, a dangerous packet, and a suspicious packet.
  • a suspicious degree when classifying a suspicious packet, a suspicious degree may be divided into a plurality in consideration of a level of reliability of a source.
  • the degree / number of additional tests by the NSF may be determined. For example, suppose that the level of suspiciousness of a packet is divided into two levels, and the greater the degree of suspicion, the larger the level is determined.
  • the level of suspicion as a result of classification of the packet by the firewall instance is 2 levels, additional inspection by IDS / IPS, anti-spoofing, and DPI may be performed.
  • the firewall attaches a packet forwarding header containing the NSF profile corresponding to the IDS / IPS to the packet and attaches the packet forwarding header to the NSFF. Can return packet.
  • Step 3 the packet can be examined in detail by IDS / IPS.
  • the NSFF may forward the packet to the IDS / IPS instance.
  • the IDS / IPS instance may perform detailed inspection on the received packet.
  • the IDS / IPS instance corresponds to anti-spoofing to describe the next NSF to which the packet is delivered.
  • the packet forwarding header including the NSF profile may be attached to the packet, and the packet with the packet forwarding header attached to the NSFF may be returned.
  • the IDS / IPS instance may drop the packet.
  • the packet can be examined in detail by anti-spoofing.
  • the NSFF may forward the packet to the Anti-Spoofing instance.
  • the anti-spoofing instance may perform detailed inspection on the received packet.
  • the anti-spoofing instance attaches a packet forwarding header including an NSF profile corresponding to the DPI to the packet.
  • a packet with a packet forwarding header attached to the NSFF may be returned.
  • the anti-spoofing instance may drop the packet.
  • Step 5 the packet can be examined in detail by DPI.
  • the NSFF may forward the packet to the DPI instance.
  • the DPI instance may perform detailed inspection on the received packet.
  • the DPI instance may return the packet to the NSFF.
  • the DPI instance may drop the packet.
  • Step 6 After receiving the packet from the DPI instance, the NSFF may deliver the packet to the destination.
  • FIG. 9 is a diagram illustrating a load balancing method in a NF-triggered traffic steering system according to an embodiment of the present invention.
  • NSF instances In large network domains, there are generally multiple NSF instances that provide various security services. In this case, a specific NSF instance may experience excessive traffic beyond its capability. In this case, it is required to allocate some of the traffic to another available instance of the same NSF.
  • This process may be commonly referred to as load balancing.
  • the NSF Operation Manager can periodically monitor the traffic load status of available NSF instances.
  • a new NSF instance may be dynamically created through the Developer's Management System.
  • This dynamic NSF instance creation can be combined with the traffic steering mechanism to eventually provide load balancing services.
  • Step 1 The NSF Operation Manager detects that the currently available firewall instance has received too many requests. That is, it detects that excessive traffic has occurred in the firewall instance.
  • Step 2 Currently, assume that no additional firewall instance is available.
  • the NSF Operation Manager requests the creation of a new firewall instance that can provide the same security services to the Developer's Management System.
  • Step 3 The Developer's Management System creates a new firewall instance and registers the information of the new firewall instance with the NSF Operation Manager.
  • the NSF Operation Manager updates the NSF information table to reflect the new firewall instance and informs NSF and NSFF of such updates.
  • the NSFF forwards the following traffic to the new firewall instance.
  • the burden on existing firewall instances can be effectively alleviated.
  • the corporate network administrator is an I2NSF user.
  • the I2NSF user first specifies a high-level security policy that blocks employees' access to social networking sites during office hours.
  • a high-level security policy may be specified, such as "blocking all access to social networking sites by employees from 9 am to 6 pm.”
  • the Security Controller When a high-level security policy is received, the Security Controller translates the high-level security policy into a low-level security policy rule.
  • the Security Controller first accesses a database of IP address mappings in the corporate network system to figure out the IP addresses to be used by employees. Based on this information, the Security Controller creates a firewall rule that restricts access to social networking sites from employees' IP addresses. Firewall rules also contain information about working hours.
  • the Security Controller sets the security policy rule created through NFI to the firewall.
  • an access request packet is forwarded to the firewall.
  • the firewall examines the packet header and determines whether the packet is forwarded to the social networking site. For example, the source / destination IP address may be used to determine whether to be delivered to a social networking site.
  • the current time is checked to determine whether or not it is within working hours. If a packet meets two conditions, the firewall drops the packet to restrict access to the social networking site.
  • VoIP Voice over Internet Protocol
  • VoLTE Voice over Long Term Evolution
  • This scenario relates to a mobile telecommunications service provider who wants to provide security services for their customer's VoIP / VoLTE calls.
  • an administrator of a mobile communications service network wants to provide security services to his customer's VoIP / VoLTE calls.
  • the manager of this scenario is the I2NSF user.
  • the I2NSF user specifies (highest) a high-level security policy rule to apply to an incoming VoIP / VoLTE packet.
  • the Security Controller When receiving a high-level security policy rule from an administrator, the Security Controller translates the country name in the level security policy rule to the IP address range.
  • the Security Controller creates a firewall rule to determine whether the VoIP / VoLTE call is suspicious by checking the source address and destination address of the call packet and configures the generated rule in the firewall instance. do.
  • the Security Controller generates DPI rules for checking various fields of VoIP / VoLTE packets corresponding to malicious calls, and transmits those rules to the DPI instance.
  • FIG. 10 through 13 illustrate a step-by-step procedure performed on an incoming VoIP / VoLTE packet utilizing the traffic steering framework triggered by the NSF according to an embodiment of the present invention.
  • the VoIP / VoLTE packet arrives at the mobile service provider's network
  • the VoIP / VoLTE packet is forwarded or mirrored to the firewall.
  • the firewall determines whether this traffic corresponds to an unusual call pattern.
  • the firewall triggers DPI for more detailed security checks on various fields of the VoIP / VoLTE packet.
  • NSFF 1 may attach a packet forwarding header to a packet.
  • the packet forwarding header may include a T field (the Action Code field in FIG. 6 above), an N field (SpecInfo Num field), and a Spec field (SpecInfo 0 ... n field).
  • NSFF 1 may set the value of the T field in the Packet Forwarding Header to one of "advanced" and "mirror", and the Spec field may be set to an NSF profile to be additionally checked. have. If the T field is set to "advanced" and the Spec field is set to DPI profile, the corresponding traffic packet may be delivered in DPI via NSFF.
  • the incoming packet is delivered to the intranet as shown in FIG. 11 and the packet copied through mirroring (copying). May be delivered in DPI via NSFF.
  • the DPI checks various fields of the received VoIP / VoLTE packet based on the rule of the VoIP / VoLTE packet in the security policy rule table, and determines whether the call is malicious. As a result of the DPI determining, if it is determined to be a malicious traffic packet, the corresponding traffic packet may be dropped.
  • the DPI may notify the I2NSF user of the malicious operation detected through the NFI and the CFI. That is, DPI may notify NSF Operation Manager of malicious operation through NFI, and NSF Operation Manager may notify I2NSF user of malicious operation through CFI.
  • FIG. 14 illustrates a method of traffic steering triggered by NSF-triggered according to an embodiment of the present invention.
  • the NSF performs a security check on packets introduced to a system supporting traffic steering (S1401).
  • the packet introduced into the system may be received by the NSFF and delivered to the NSF by the NSFF.
  • the NSF determines whether an additional check by another NSF is necessary (S1402).
  • the NSF may classify a packet into a secure packet, a dangerous packet, and a suspicious packet according to a trust level of a source of the packet.
  • a packet If a packet is classified as a secure packet, it can be delivered to the destination of the packet without further security checking through another NSF. Alternatively, if a packet is classified as a dangerous packet, the packet may be dropped. Alternatively, if a packet is classified as a suspicious packet, the packet may be delivered to the NSFF with a packet forwarding header attached thereto.
  • the NSF attaches a packet forwarding header to the packet for invoking the additional check (S1403).
  • the packet forwarding header may include information on a security capability required for the additional check.
  • the packet forwarding header may include an action code field including a result of a security check of a packet, a capability information field including security capability information required for further inspection, and a number field of capability information indicating the number of capability information fields. It may include.
  • the NSF transmits the packet with the packet forwarding header to the NSFF (S1404).
  • FIG. 15 illustrates a block diagram of an apparatus in a NSF-triggered traffic steering system in accordance with an embodiment of the present invention.
  • a device 1500 in an NSF-triggered traffic steering system may include a processor 1501, a memory 1502, and a communication module 1503. ).
  • the device 1500 in the NSF-triggered traffic steering system may correspond to the NSF, NSFF, Security Controller, NSF Operation Manager, Developer's Management System, and I2NSF user.
  • the processor 1501 implements the functions, processes, and / or methods proposed in FIGS. 1 to 14.
  • the memory 1502 is connected to the processor 1501 and stores various information for driving the processor 1501.
  • the communication module 1503 is connected to the processor 1501 and transmits and / or receives a wired / wireless signal.
  • the memory 1502 may be inside or outside the processor 1501 and may be connected to the processor 1501 by various well-known means.
  • 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

네트워크 보안 기능(Network Security Function)에 의해 트리거되는 트래픽 스티어링(traffic steering)을 위한 방법 및 시스템, 이를 위한 장치가 개시된다. 구체적으로, 네트워크 보안 기능(NSF: Network Security Function)에 의해 트리거되는 트래픽 스티어링(traffic steering)을 지원하는 시스템에 있어서, 상기 시스템에 유입된 패킷에 대한 보안 검사를 수행하고, 상기 보안 검사의 결과에 기반하여 또 다른 NSF에 의한 추가적인 검사가 필요한지 여부를 판단하고, 상기 추가적인 검사가 필요하면, 상기 추가적인 검사를 호출하기 위한 패킷 전달 헤더(packet forwarding header)를 상기 패킷에 부착하고, 상기 패킷 전달 헤더가 부착된 패킷을 NSF 전달자(NSFF: NSF Forwarder)에게 전송하는 제1 NSF 및 상기 패킷 전달 헤더에 포함된 상기 추가적인 검사를 위해 요구되는 보안 능력을 가진 제2 NSF를 탐색한 경우, 상기 제2 NSF에게 상기 패킷을 전달하는 NSFF를 포함할 수 있다.

Description

네트워크 보안 기능에 의해 트리거되는 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치
본 발명은 보안 서비스를 제공하는 시스템에 관한 것으로서, 보다 상세하게 네트워크 보안 기능(NSF: Network Security Function)에 의해 트리거되는 트래픽 스티어링(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: Network Security Function)에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 프레임워크를 제안한다.
본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명의 일 양상은, 네트워크 보안 기능(NSF: Network Security Function)에 의해 트리거되는 트래픽 스티어링(traffic steering)을 지원하는 시스템에 있어서, 상기 시스템에 유입된 패킷에 대한 보안 검사를 수행하고, 상기 보안 검사의 결과에 기반하여 또 다른 NSF에 의한 추가적인 검사가 필요한지 여부를 판단하고, 상기 추가적인 검사가 필요하면, 상기 추가적인 검사를 호출하기 위한 패킷 전달 헤더(packet forwarding header)를 상기 패킷에 부착하고, 상기 패킷 전달 헤더가 부착된 패킷을 NSF 전달자(NSFF: NSF Forwarder)에게 전송하는 제1 NSF 및 상기 패킷 전달 헤더에 포함된 상기 추가적인 검사를 위해 요구되는 보안 능력을 가진 제2 NSF를 탐색한 경우, 상기 제2 NSF에게 상기 패킷을 전달하는 NSFF를 포함할 수 있다.
바람직하게, 상기 패킷 전달 헤더는 상기 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 상기 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드, 상기 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함할 수 있다.
바람직하게, 상기 시스템에 유입된 패킷은 상기 NSFF에 의해 수신되고, 상기 NSFF에 의해 상기 제1 NSF에게 전달될 수 있다.
바람직하게, 상기 패킷의 소스(source)의 신뢰 레벨(trust level)에 따라 상기 제1 NSF에 의해 상기 패킷은 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류될 수 있다.
바람직하게, 상기 패킷이 상기 안전한 패킷(secure packet)으로 분류된 경우 또 다른 NSF를 통해 추가의 보안 검사 없이 상기 패킷의 목적지(destination)으로 전달될 수 있다.
바람직하게, 상기 패킷이 상기 위험한 패킷(dangerous packet)으로 분류된 경우 상기 패킷은 드랍(drop)될 수 있다.
바람직하게, 상기 패킷이 상기 의심스러운 패킷(suspicious packet)으로 분류된 경우 상기 패킷은 상기 패킷 전달 헤더가 부착되어 상기 NSFF에게 전달될 수 있다.
바람직하게, 이용 가능한 모든 NSF에 대한 정보 리스트를 관리하는 NSF 운영 관리자(operation management)를 더 포함할 수 있다.
바람직하게, 상기 제2 NSF를 탐색하지 못한 경우, 상기 NSFF는 상기 추가적인 검사를 위해 요구되는 보안 능력을 포함하는 NSF 생성 요청 패킷을 상기 NSF 운영 관리자에게 전송하고, 상기 NSF 운영 관리자로부터 생성된 제3 NSF에 대한 정보를 수신하면 상기 제3 NSF에게 상기 패킷을 전달하고, 상기 NSF 운영 관리자는 상기 정보 리스트 내에서 각 NSF의 트래픽 로드 상태를 고려하여 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 상기 제3 NSF를 선택하고, 상기 제3 NSF에 대한 정보를 상기 NSFF에게 전송할 수 있다.
바람직하게, 상기 정보 리스트 내에서 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 NSF가 존재하지 않는 경우, 개발자 관리 시스템(developer's management system)에게 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 NSF의 생성을 요청할 수 있다.
바람직하게, 상기 NSF 운영 관리자가 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF에 대하여 과도한 트래픽이 발생됨을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 과도한 트래픽이 발생된 NSF와 동일한 보안 능력을 가지는 새로운 NSF의 생성을 요청할 수 있다.
바람직하게, 상기 NSF 운영 관리자가 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고, 특정 NSF가 이용되지 않음을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 이용되지 않는 NSF의 제거를 요청할 수 있다.
본 발명의 다른 일 양상은, 네트워크 보안 기능(NSF: Network Security Function)이 트래픽 스티어링(traffic steering)을 수행하는 방법에 있어서, 상기 트래픽 스티어링(traffic steering)을 지원하는 시스템에 유입된 패킷에 대한 보안 검사를 수행하는 단계, 상기 보안 검사의 결과에 기반하여 또 다른 NSF에 의한 추가적인 검사가 필요한지 여부를 판단하는 단계, 상기 추가적인 검사가 필요하면, 상기 추가적인 검사를 호출하기 위한 패킷 전달 헤더(packet forwarding header)를 상기 패킷에 부착하는 단계 및 상기 패킷 전달 헤더가 부착된 패킷을 NSF 전달자(NSFF: NSF Forwarder)에게 전송하는 단계를 포함하고, 상기 패킷 전달 헤더는 상기 추가적인 검사를 위해 요구되는 보안 능력에 대한 정보를 포함할 수 있다.
바람직하게, 상기 패킷 전달 헤더는 상기 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 상기 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드, 상기 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함할 수 있다.
바람직하게, 상기 패킷의 소스(source)의 신뢰 레벨(trust level)에 따라 상기 제1 NSF에 의해 상기 패킷이 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류될 수 있다.
본 발명의 실시예에 따르면, NSF 간에 트래픽 스티어링을 가능하게 하고, 다양한 타입의 NSF를 통해 네트워크 트래픽의 복합적인 검사(composite inspection)를 가능하게 한다.
또한, 본 발명의 실시예에 따르면, 동적으로 생성된 NSF 인스턴스(instance)들을 통한 로드 밸런싱(load balancing)을 제공할 수 있다.
또한, 본 발명의 실시예에 따르면, 표준화된 인터페이스 및 데이터 모델을 이용함으로써, 다양한 네트워크 보안 기능(NSF)들을 제어 및 관리를 단순화 할 수 있다.
또한, 본 발명의 실시예에 따르면, NSF의 추상적인 뷰(abstract view)만을 사용자에게 제공함으로써, 사용자 친화적인(user-friendly) 보안 정책 설정(specification)을 가능하게 한다.
또한, 본 발명의 실시예에 따르면, NSF가 동적으로 활성화/비활성화(enabled/disabled)됨에 따라 다양한 네트워크 조건 및 보안 요구 사항을 지원할 수 있다.
본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 발명에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 발명에 대한 실시예를 제공하고, 상세한 설명과 함께 본 발명의 기술적 특징을 설명한다.
도 1은 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템의 구성을 예시한다.
도 2는 기존의 서비스 기능 체인 아키텍처를 예시한다.
도 3은 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 NSF 능력에 대한 정보 모델을 예시하는 도면이다.
도 4는 본 발명의 일 실시예에 따른 패킷 필터링 능력을 가지는 NSF(들)을 위한 정보 모델(IM)을 예시한다.
도 5는 본 발명의 일 실시예에 따른 트래픽 스티어링을 개념적으로 설명하기 위한 도면이다.
도 6은 본 발명의 일 실시예에 따른 패킷 전달 헤더(Packet Forwarding Header)를 예시한다.
도 7은 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 트래픽의 흐름을 예시하는 도면이다.
도 8은 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 트래픽의 흐름을 예시하는 도면이다.
도 9는 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 로드 밸런싱 방법을 예시하는 도면이다.
도 10 내지 도 13은 본 발명의 일 실시예에 따른 NSF에 의해 트리거된 트래픽 스티어링 프레임워크를 활용하여 유입되는 VoIP/VoLTE 패킷에 수행되는 단계 별 절차를 예시한다.
도 14는 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 방법을 예시한다.
도 15는 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 장치의 블록 구성도를 예시한다.
이하, 본 발명에 따른 바람직한 실시 형태를 첨부된 도면을 참조하여 상세하게 설명한다. 첨부된 도면과 함께 이하에 개시될 상세한 설명은 본 발명의 예시적인 실시형태를 설명하고자 하는 것이며, 본 발명이 실시될 수 있는 유일한 실시형태를 나타내고자 하는 것이 아니다. 이하의 상세한 설명은 본 발명의 완전한 이해를 제공하기 위해서 구체적 세부사항을 포함한다. 그러나, 당업자는 본 발명이 이러한 구체적 세부사항 없이도 실시될 수 있음을 안다.
몇몇 경우, 본 발명의 개념이 모호해지는 것을 피하기 위하여 공지의 구조 및 장치는 생략되거나, 각 구조 및 장치의 핵심기능을 중심으로 한 블록도 형식으로 도시될 수 있다.
이하의 설명에서 사용되는 특정 용어들은 본 발명의 이해를 돕기 위해서 제공된 것이며, 이러한 특정 용어의 사용은 본 발명의 기술적 사상을 벗어나지 않는 범위에서 다른 형태로 변경될 수 있다.
최근에는, 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들의 세트를 통해 분석될 필요가 있다.
NSF가 자체 분석 결과를 기반으로 다른 NSF를 호출함으로써 NSF가 추가 검사(inspection)를 트리거 할 수 있게 해주는 정보 모델(IM: Information Model)이 네트워크 보안 기능(들)로의 인터페이스(I2NSF: Interface to Network Security Functions) 프레임워크(framework) 내 NSF 향한 인터페이스(NFI: NSF-Facing Interface)를 위해 제안되었다.
그러나, I2NSF framework의 현재 설계는 다중 NSF를 통한 연속적인(consecutive) 검사를 가능하게 하기 위해 네트워크 트래픽 스티어링(network traffic steering)을 완전히 고려하지 않는 단점이 있다.
이에 따라, 본 발명에서는 NSF를 통한 traffic steering을 위한 추가 구성 요소를 I2NSF 프레임 워크(framework)에 통합하는 아키텍처를 제안한다.
특히, 본 발명에서는, NSF에 의해 트리거된(또는 NSF-트리거된)(NSF-triggered) traffic steering의 상위-레벨 정책(high-level policy)을 낮은 수준의 정책으로 해석(interpret)/변환하고 관리할 수 있도록, 보안 컨트롤러(security controller)의 기능을 확장하는 방법을 제안한다.
또한, 본 발명에 따르면, 사용 가능한 NSF 인스턴스(들)(instance) 및 NSF 인스턴스(들)의 정보(예를 들어, 네트워크 정보 및 작업로드(workload))를 추적하고, 주어진 보안 기능을 위해 사용할 NSF 인스턴스를 결정할 수 있다.
또한, 본 발명에 따르면, Security Controller에 의해 제공되어 전달되는 정보에 기반하여, 네트워크 보안 기능 전달자(NSFF: Network Security Function Forwarder)는 요구되는 NSF(들)을 통해 네트워크 traffic steering을 수행할 수 있다.
또한, 본 발명에 따르면, NSFF는 NSF로부터의 검사 결과를 해석하여 진보된 검사(advanced inspection)를 시행할 수 있다.
또한, 본 발명에 따르면, 보안 검사 결과 및 advanced inspection 요청을 특정하기 위한 추가적인 패킷 헤더(packet header) 포맷이 정의될 수 있다.
본 발명은 크게 다음과 같은 효과를 가진다.
- 연속적인(consecutive) 검사를 위한 정책 설정: 본 발명에 따른 NSF-triggered traffic steering 아키텍처(architecture)는 NSF 트리거링(triggering)을 위한 정책 설정/관리를 허용한다. 트리거링 정책(triggering policy)에 기반하여, 관련된 네트워크 트래픽은 다양한 NSF(들)을 통해 복합적으로, 협업 방식으로 분석될 수 있다.
- 연속적인 검사를 위한 network traffic steering: 본 발명에 따른 NSF-triggered traffic steering architecture에서는, 트리거링 정책에 기반하여 network traffic이 복수의 요구되는 NSF(들)을 통해 스티어링될 수 있다. 또한, NSF 향한 인터페이스(NFI: NSF facing interface)를 위한 I2NSF 정보 모델(IM)은 NSF가 자신의 검사 결과에 기반하여 추가의 검사를 위해 다른 NSF를 호출하도록 요구한다. 이러한 요구 사항을 만족하기 위하여, 본 발명에 따른 NSF-triggered traffic steering architecture에서는, 하나의 NSF로부터 또 다른 NSF로의 traffic 전달(forwarding)될 수 있다.
- NSF 인스턴스(instance) 간의 로드 밸런싱(load balancing): 본 발명에 따른 NSF-triggered traffic steering architecture는 유연한 traffic steering 메커니즘을 활용(leveraging)함으로써 이용 가능한 NSF instance들에 유입되는 traffic의 load balancing을 제공한다. 이러한 목적을 위해, NSF에게 보안 기능에 대한 과도한 요청이 있을 때, NSF의 동적 인스턴스화(instantiation)를 수행(즉, 해당 보안 기능을 수행할 수 있는 새로운 NSF를 생성)할 수 있다.
본 문서에서 사용될 수 있는 용어(terminology)들은 다음과 같이 정의된다.
- 네트워크 보안 기능(NSF: Network Security Function): 수신된 패킷(packet)의 특정 취급을 담당하는 기능을 담당하는 장치를 의미한다. NSF는 다양한 프로토콜 스택(stack)의 다양한 계층(예를 들어, 네트워크 계층 또는 다른 OSI(Open System Interconnection) 계층 등)에서 동작할 수 있다.
예를 들어, 네트워크 보안 서비스 기능 타입의 일례로서, 방화벽(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), 전송 계층 보안(TLS: Transport Layer Security) 프록시, 안티스푸핑(Anti-Spoofing) 등이 포함될 수 있다. 본 발명에 따른 NSF는 상술한 예시 중 어느 하나로 구현될 수 있으며, 다양한 타입의 NSF가 이용될 수 있다. 또한, 동일한 타입의 NSF가 다수로 구현될 수도 있다. 또한, 본 발명에 따른 NSF는 상술한 예시 중 어느 하나 이상이 결합되어 구현될 수도 있다.
- 진보된 검사/동작(Advanced Inspection/Action): NFI(NSF-facing interface)를 위한 I2NSF 정보 모델(IM)과 같이, Advanced Inspection/Action은 NSF가 자신의 검사 결과에 기반하여 또 다른 NSF에게 추가적인 검사를 위한 호출을 의미한다.
- 네트워크 보안 기능 프로파일(NSF Profile): NSF Profile은 NSF의 보안 검사 능력을 나타낸다. 각 NSF는 자신이 제공하는 보안 서비스의 타입, 자신의 자원 능력 등을 특정하기 위하여 자신의 NSF Profile을 가질 수 있다.
- 네트워크 보안 기능 운영 관리자(NSF Operation Manager): NSF Operation Manager는 지속적으로 NSF instance의 정보 및 상태를 관리하고, advanced inspection 요청을 지원하기 위하여 NSF 네트워크 액세스 정보(network access information)을 제공하는 장치를 의미한다. 예를 들어, NSF instance의 정보는 지원되는 전송 프로토콜(transport protocol), IP(Internet Protocol) 주소, NSF instance을 위한 위치를 포함할 수 있다. 또한, NSF Operation Manager는 개발자의 관리 시스템(Developer’s Management System)과의 협의 그리고 전체 NSF instance들에 대한 load balancing에 의해 NSF instance의 풀(pool)의 동적인 관리를 담당한다.
- 패킷 전달 헤더/인캡슐레이션(Packet Forwarding Header/Encapsulation): Packet Forwarding Header는 추가 검사를 위해 하나의 NSF로부터 또 다른 NSF로의 packet을 전달하기 위하여 사용된다. 전자의 NSF(즉, 소스 NSF)는 후자의 NSF(즉, 타겟 NSF)의 NSF 프로파일로 Packet Forwarding Header을 구성(construct)하고, NSFF에게 해당 packet을 전달한다. 요구되는 필드는 동작 코드(action code), 메타데이터(metadata)의 수, 메타데이터(metadata)를 포함할 수 있다. 이때, metadata는 NSF profile의 일부 또는 전체를 포함할 수 있으며, 후술하는 Packet Forwarding Header에서 Spec info 필드로 지칭될 수 있다.
- 네트워크 보안 기능 전달자(NSFF: Network Security Function Forwarder)(또는 보안 기능 전달자(SFF: Security Function Forwarder)): traffic이 NSF로부터 전달될 때, NSFF는 packet forwarding encapsulation 내에서 전달된 정보에 따라 하나 이상의 연결된 NSF에게 traffic을 전달하는 장치를 의미한다. 따라서, NSFF는 traffic을 또 다른 NSFF(동일한 또는 다른 타입의 오버레이(overlay))에게 전달하고, overlay 검사를 종료할 수 있다.
이하, 본 발명에서 제안하는 NSF-triggered traffic steering architecture 및 traffic steering의 기본 동작에 대하여 살펴본다. 또한, architecture의 각 구성 요소에 대하여 상세히 살펴본다.
도 1은 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템의 구성을 예시한다.
도 1을 참조하면, 본 발명에 따른 NSF-triggered traffic steering architecture는 I2NSF 사용자(user)(또는 사용자 장치), 네트워크 운영자 관리 보안 컨트롤러(Network Operator Management Security Controller, 간단히 보안 컨트롤러(Security Controller)로 지칭될 수 있음), 벤더의 관리 시스템(VMS: Vendor's Management System), NSF(또는 NSF 장치) 및 NSF 전달자(NSFF: NSF Forwarder)(또는 NSFF 장치)로 구성될 수 있다. 또한, Network Operator Management Security Controller는 NSF 운영 관리자(NSF Operation Manager)(또는 NSF Operation Manager 장치)를 포함할 수 있다.
도 1에 따른 architecture는 전송중인 packet의 복합 검사(composite inspection)를 지원한다. Packet Forwarding Header에 저장된 각 NSF의 검사 결과에 따라, traffic packet은 상세한 분석을 위해 또 다른 NSF로 스티어링될 수 있다.
기존의 I2NSF 프레임 워크의 구성 요소인 I2NSF 사용자(I2NSF User)(또는 I2NSF 클라이언트)로부터 상위-레벨(high-level) 진보된 검사에 대한 정책 및 설정을 반영할 수 있다.
또한, 본 발명에서 제안되는 architecture는 load balancing, 자동으로 추가적인(supplementary) NSF instance 생성 및 사용되지 않는 NSF instance 제거 기능을 제공할 수 있다.
이러한 설계 목적을 달성하기 위해 기존의 I2NSF 프레임 워크에 여러 구성 요소를 통합할 수 있다.
이하, 각 구성 요소에 대하여 살펴본다.
- I2NSF User: I2NSF user는 네트워크 운영자의 기반시설(infrastructure)을 통해 네트워크 서비스를 수신하는 기업 네트워크(enterprise network)의 관리자(administrator)(또는 관리자 장치)를 나타낸다.
I2NSF user는 또한 다양한 악의적인(malicious) 공격으로부터 enterprise network 트래픽(traffic)을 보호하기 위하여 네트워크 보안 서비스(network security service)를 이용할 필요가 있다. security service를 요청하기 위하여, I2NSF user는 자신이 원하는 security service의 상위-레벨(high-level) 보안 정책(security policy)을 특정(specify)하고, Security Controller에게 high-level security policy을 알릴 수 있다.
high-level security policy를 준비하는 과정에서, I2NSF user는 각 NSF(들)를 위한 security service 또는 보안 정책 규칙 설정(security policy rule configuration)을 실현하기 위하여 요구되는 NSF(들)의 타입에 대하여 고려하지 않을 수 있다.
또한, I2NSF user는 Security Controller에 의해 기본적인(underlying) NSF(들) 내에서 발생되는 보안 이벤트(들)(security event)를 통지 받을 수 있다. 이들의 security event(들)을 분석함으로써, I2NSF user는 새로운 공격을 식별하고, 새로운 공격에 대처하기 위한 high-level security policy를 업데이트(또는 생성)할 수 있다.
- Network Operator Management Security Controller(Security Controller): Security Controller는 네트워크 운영자에 의해 관리된다.
Security Controller의 주요한 역할 중 하나는 I2NSF user로부터의 high-level 보안 정책(또는 정책 규칙)을 특정 NSF(들)을 위한 하위-레벨(low-level) 보안 정책 규칙으로 변환(translate)하는 것이다. Security Controller가 high-level 보안 정책을 I2NSF user로부터 수신한 후, Security Controller는 우선 I2NSF user에 의해 요구되는 정책을 시행하기 위하여 요구되는 NSF(들)의 타입을 결정할 수 있다. 그리고, Security Controller는 요구되는 각 NSF(들)을 위한 low-level 보안 정책을 생성할 수 있다. 결국, Security Controller는 생성된 low-level 보안 정책을 각 NSF(들)에게 설정할 수 있다.
또한, Security Controller는 시스템 내 구동 중인 NSF(들)을 모니터링하고, 각 NSF(들)에 대한 다양한 정보(예를 들어, 네트워크 액세스(access) 정보 및 작업로드(workload) 상태 등)를 유지할 수 있다. 또한, Security Controller는 Vendor's Management System의 도움을 받아 NSF 인스턴스의 동적인 수명시간(life-cycle) 관리를 통해 NSF 인스턴스(instance)의 풀(pool)을 동적으로 관리할 수 있다.
- NSF 운영 관리자(NSF Operation Manager)
NSF Operation Manager는 다음 3 가지의 동작을 담당한다.
i) IP(Internet Protocol) 주소, 지원되는 전송 프로토콜(transport protocol), NSF profile, 로드 상태와 같이 사용 가능한 모든 NSF instance의 정보를 유지
ii) 주어진 NSF profile과 관련된 진보된 검사(advanced inspection) 수행을 돕기 위하여 NSFF로부터 수신된 사용 가능한 NSF instance의 쿼리(query)에 대한 응답
iii) 자원 낭비를 피하기 위한 기존 NSF instance의 제거 또는 서비스 혼잡을 피하기 위한 추가의(supplementary) NSF instance의 인스턴스화(instantiation)를 위하여 개발자의 관리 시스템(Developer’s Management System)으로의 요청
도 1에서 예시된 바와 같이, NSF Operation Manager는 Security Controller의 하위 모듈에 해당한다.
보다 구체적으로 살펴보면, 새로운 NSF instance가 등록될 때마다, Developer's Management System은 등록된 NSF instance의 정보를 NSF Operation Manager로 전달할 수 있다. 이에 따라, NSF Operation Manager는 사용 가능한 모든 NSF instance의 정보 리스트를 유지할 수 있다.
또한, NSF Operation Manger는 NSFF로부터 advanced inspection을 위한 NSF profile(즉, 보안 능력 정보)을 포함하는 요청 packet(예를 들어, NSF 생성 요청 패킷)을 수신할 수 있다. NSF Operation Manger가 NSFF로부터 특정 NSF profile의 query를 수신하면, NSF Operation Manger는 해당 NSF profile을 적용 가능한 모든 이용 가능한 NSF instance를 검색할 수 있다. 그리고, NSF의 위치 및 트래픽 로드 상태와 같은 선택 기준을 이용하여 최적(best)의 instance를 찾을 수 있다. 그리고, 검색 결과(즉, 최적의 instance)를 NSFF에게 반환할 수 있다.
또한, 각 NSF instance는 주기적으로 자신의 로드 상태를 NSF Operation Manger에게 보고할 수 있다. 이러한 보고에 기초하여, NSF Operation Manger는 NSF instance의 정보를 업데이트할 수 있다. 또한, NSF instance의 추가적인 인스턴스화(instantiation)(즉, 추가의 NSF instance 생생) 또는 NSF instance의 제거(elimination/destruct)를 위해 Developer’s Management System에게 요청함으로써 NSF instance의 pool을 관리할 수 있다. 결과적으로, NSF Operation Manger는 혼잡 및 자원 낭비를 방지함으로써 효율적인 자원 활용을 가능하게 한다.
- 개발자의 관리 시스템(Developer’s Management System)
Developer’s Management System은 벤더의 관리 시스템(Vendor's Management System)으로 지칭될 수도 있다. Developer’s Management System은 네트워크 운영자에게 NSF(들)을 제공하는 제3자(third-party) 보안 벤더에 의해 관리될 수 있다. 다양한 보안 벤더의 다수의 Developer’s Management System(들)이 존재할 수 있다.
본 발명에 따르면, 다음과 같이 추가 기능을 위해 Developer’s Management System이 확장될 수 있다.
상술한 바와 같이, NSF Operation Manager의 요청에 기반하여, Developer’s Management System는 새로운 NSF 인스턴스(들)을 생성하거나 또는 더 이상 사용되지 않는 기존의 NSF 인스턴스(들)을 제거(eliminate/destruct)할 수 있다.
다시 말해, NSF Operation Manager는 NSF의 기존 instance가 혼잡하면 추가적인 NSF instance를 생성하기 위해 Developer’s Management System에게 요청할 수 있다. 반면에 특정 NSF에 대한 instance의 수가 너무 많으면, NSF Operation Manager는 Developer’s Management System에게 NSF instance들 중 일부를 제거하도록 요청할 수 있다.
이러한 요청에 대한 응답으로 Developer's Management System은 NSF instance를 생성 및/또는 제거할 수 있다. 그리고, 새로운 NSF instance를 생성하거나 기존 NSF instance를 제거한 후에 Developer's Management System은 변경 사항을 NSF Operation Manager에 통보할 수 있다.
- NSF 및 NSF Forwarder(NSFF):
NSF(예를 들어, firewall, DPI, 서비스 거부 공격 중재자(Dos(Denial of Service) attack mitigator) 등)는 Security Controller로부터 수신한 보안 정책 규칙에 따라 network traffic의 보안 검사를 수행한다.
특히, 본 발명에 따른 architecture 내 NSF는 자신의 보안 검사 결과에 기반하여 서로 다른 NSF 타입으로 진보된 보안 검사(advanced security inspection)(예를 들어, DPI 및 분산 서비스 거부 공격 중재자(DDoS(Distribute Denial of Service) attack mitigator)를 트리거(trigger)할 수 있다. 예를 들어, firewall은 DPI를 이용한 suspicious traffic의 추가적인 검사를 트리거할 수 있다.
이 경우, 그러한 진보되고 복합적인 검사(composite inspection)를 실현하기 위하여, NSFF는 현재 NSF로부터 다음의(successor) NSF로의 suspicious traffic의 전달을 수행할 수 있다.
도 1에서는 NSFF가 Security Controller 및 NSF와는 별도의 구성 요소로 도시하고 있으나, 본 발명이 이에 한정되는 것은 아니다. 즉, NSFF는 Security Controller 또는 NSF 중에 어느 것에도 포함(즉, 하나의 장치로 함께 구현)될 수 있는 논리적인 구성 요소이다.
다음으로, 도 1에 예시된 architecture의 인터페이스에 대하여 살펴본다.
- 소비자를 향한 인터페이스(CFI: Consumer-Facing Interface): 도 1에서 볼 수 있듯이, CFI는 I2NSF user와 Security Controller 사이에 위치하고, CFI는 사용자의 I2NSF 시스템으로의 인터페이스이다. 이렇게 설계됨으로써, 하위(underlying) NSF(들)의 상세한 내용을 숨기고, 사용자에게 NSF(들)의 추상적인 시각(abstract view)만을 제공한다.
이 인터페이스의 주요한 목적은 사용자가 I2NSF 시스템에게 보안 서비스를 요청할 수 있도록 허용하기 위함이다. 또한, Security Controller가 하위(underlying) NSF(들)로부터 수신한 보안 경보(alert)를 이 CFI를 통해 사용자에게 전달하기 위함이다. 수신한 경보를 분석함으로써, 사용자는 새로운 공격을 식별하고, 새로운 공격에 대처하기 위한 high-level security policy를 업데이트(또는 생성)할 수 있다.
- NSF를 향한 인터페이스(NFI: NSF-Facing Interface): NFI는 NSFF(들)과 Security Controller 사이 및/또는 NSF(들)과 Security Controller 사이에 위치한다.
NFI의 주요한 목적은 NSF(들)로부터 보안 관리 기법을 분리(decouple)함으로써 다양한 보안 솔루션 벤더들의 NSF(들)을 제어하고 관리하기 위한 표준화된 인터페이스를 제공하기 위함이다. NFI는 NSF(들)의 상세한 내용(예를 들어, 벤더, 유형 인자(form factor) 등)과 독립된다. 따라서, security policy rule을 NSF에게 설정할 때, Security Controller는 벤더 특정한 차이 및/또는 NSF의 form factor를 고려할 필요가 없다.
기본적으로, NFI 인터페이스를 통해, Security Controller는 I2NSF user에 의한 high-level security policy를 시행하기 위하여 플로우 기반(flow-based) security policy를 각 타겟 NSF에게 전달할 수 있다. 원격 유지(maintenance)의 목적으로, Security Controller는 NFI 인터페이스를 통해 NSF(들)에게 제어 명령을 트리거할 수 있다.
각 NSF는 또한 Security Controller에게 현재 상태(예를 들어, workload 레벨, 혼잡(congestion) 등)를 주기적으로 알리기 위하여 NFI 인터페이스를 사용할 수 있다. 또한, 보안 이벤트/경보가 NSF 상에 발생할 때마다, NSF는 NFI 인터페이스를 통해 Security Controller에게 이를 보고할 수 있다.
각 NSFF는 Security Controller로부터 NFI 인터페이스를 통해 시스템 내 구동 중인 NSF의 전달 정보(forwarding information)를 수신할 수 있다. 이때, NSFF가 주어진 traffic을 전달하기 위한 forwarding information를 가지고 있지 않은 경우, NSFF는 NFI 인터페이스를 통해 Security Controller에게 정보의 쿼리(query)를 전송할 수 있다.
- 등록 인터페이스(RI: Registration Interface): 도 1에서 볼 수 있듯이, RI는 Security Controller와 Developer's Management System 사이에 위치한다. RI의 주요한 목적은 NSF instance의 동적인 life-cycle 관리 및 시스템 상에 새로운 NSF instance의 등록을 수행하기 위함이다.
새로운 NSF가 시스템 내 요구되면, Security Controller는 새로운 NSF 생성을 Developer's Management System에게 요청할 수 있다. 이때, Security Controller의 요청은 요청된 NSF instance의 프로파일(profile)을 포함하고, 이 profile은 NSF instance에 의해 제공되어야 하는 보안 능력(security capability) 및 서비스 능력(service capacity)을 특정할 수 있다.
이 요청이 수신되면, Developer's Management System은 요청된 NSF profile을 만족하는 새로운 NSF instance를 생성하고, Security Controller에게 이 새로운 NSF instance의 네트워크 액세스 정보(network access information)(예를 들어, IP(Internet Protocol) 주소, 포트 넘버(port number) 등)를 알릴 수 있다. 네트워크 액세스 정보는 시스템 내 새로운 NSF instance의 고유한 식별자로서 사용될 수 있다.
반면, Security Controller가 특정한 기존의 NSF instance가 더 이상 필요하지 않다고 결정하면, Security Controller는 Developer's Management System에게 해당 NSF instance를 제거(destruct)하라고 요청할 수 있다. 이 제거 요청(destruction request)는 제거될 NSF instance의 고유한 식별자를 포함할 수 있다.
이하, NSF에 의해 트리거된 트래픽 스티어링(NSF-Triggered Traffic Steering)에 대하여 살펴본다.
도 2는 기존의 서비스 기능 체인 아키텍처를 예시한다.
서비스 기능 체인/체이닝(SFC: Service Function Chain/Chaining)은 다수의 서비스 기능(예를 들어, NSF)을 통해 traffic을 steering함으로써 이를 가능하게 하는 기술에 해당한다.
(1 단계) 트래픽(즉, packet)에 대한 SFC 설정 및 관리(SFC configuration & management)가 미리 정의된다.
(2 단계) I2NSF 아키텍처 내 유입된 트래픽(즉, packet)은 미리 정의된 SFC 설정 및 관리(SFC configuration & management)를 이용하여 해당 트래픽을 최초로 분류한다. 즉, 해당 트래픽이 어떠한 NSF을 통해 검사되는지에 대한 서비스 기능 경로(SFP: Service Function Path)를 결정한다. 도 2에서는 해당 트래픽이 NSF1을 통해 검사되고, 이어 NSF2를 통해 검사되는 SFP가 결정되었다고 가정한다.
(3 단계) 트래픽은 결정된 SFP에 통해 트래픽 스티어링된다. 즉, 트래픽은 결정된 SFP에 따라 서비스 기능 전달자(SFF: Service Function Forwarder)를 경유하여 NSF1에게 전달된다.
(4 단계) NSF1에 의해 검사가 수행된 후, 해당 트래픽은 SFF를 경유하여 NSF2에게 전달된다. 이때, 해당 트래픽에 대하여 결정된 SFP도 함께 전달된다.
이와 같이, 트래픽이 I2NSF 아키텍처 내 유입되면, 미리 정해진 미리 정의된 SFC 설정 및 관리(SFC configuration & management)에 따라 해당 트래픽에 대한 SFP가 결정된다.
반면, 본 발명에 따른 I2NSF architecture 내에서는 트래픽의 검사 경로(즉, NSF의 경로)가 미리 정해지지 않고, 동적으로 결정된다.
도 3은 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 NSF 능력에 대한 정보 모델을 예시하는 도면이다.
본 발명에 따른 I2NSF architecture 내 NSF는 자신의 보안 검사 결과에 기반하여 서로 다른 NSF 타입으로 진보된 보안 검사(advanced security action)(즉, advanced security inspection)(예를 들어, DPI 및 DDoS attack mitigation)을 트리거할 수 있다. 예를 들어, firewall은 DPI를 이용하여 suspicious packet의 추가적인 검사를 트리거할 수 있다.
즉, 도 3과 같이, NSF는 자신의 보안 검사 결과에 기반하여 동적으로 전달자(FW: Forwarder)를 통해 DPI와 DDos Mitigator 중에 어떠한 진보된 보안 동작(advanced security action)이 다음에 수행되어야 할지를 결정할 수 있다.
이하, 표준화된 인터페이스를 위한 정보 모델(IM: Information Model) 및 데이터 모델(DM: Data Model)과, IM 및 DM을 정의함으로써 다양한 NSF(들)로의 표준화된 인터페이스를 셋업(set up)하는 절차에 대하여 살펴본다.
도 4는 본 발명의 일 실시예에 따른 패킷 필터링 능력을 가지는 NSF(들)을 위한 정보 모델(IM)을 예시한다.
I2NSF에서는 다양한 보안 솔루션 벤더의 NSF(들)로의 표준화된 인터페이스를 셋업하기 위하여 정보 모델(IM) 및 데이터 모델(DM)이 정의될 수 있다.
I2NSF 시스템 내에서, 다양한 NSF(들)은 security capability에 따라 하나 이상의 카테고리로 분류될 수 있다. IM은 NSF(들)의 각 카테고리 별로 정의될 수 있다. IM의 주요 목적은 동일한 카테고리 내 NSF(들)을 위한 security policy rule을 표현(represent)하기 위하여 종합적인(comprehensive) 모델을 정의하기 위함이다. 이러한 목적을 위해, 도 4의 예시와 같이, IM은 이벤트-조건-동작(ECA: Event-Condition-Action) 규칙의 개념에 기반하여 모든 요구되는 데이터 아이템을 정의하고, 계층적인 구조로 데이터 아이템을 특징에 따라 분류할 수 있다.
다음 단계로 IM 내 정의된 콘텐츠(content)가 실제 구현되고, 구현된 결과는 데이터 모델(DM)으로 지칭된다. 예를 들어, DM 구현을 위해 YANG(Yet Another Next Generation) 데이터 모델링 언어가 사용될 수 있다.
DM이 구현된 후, 각 관련된 NSF는 구현된 DM으로 사전-설정(pre-configure)될 수 있다.
Security Controller가 새로운 security policy rule을 가지는 NSF를 설정할 필요가 있을 때, Security Controller는 해당 DM 내 특정된 포맷에 따라 security policy rule을 표현할 수 있다.
예를 들어, I2NSF는 security policy rule을 인코딩하기 위하여 XML(extensible markup language)를 사용할 수 있으며, XML로 인코딩된(XML-encoded) security policy rule은 네트워크 설정 프로토콜(NETCONF: Network Configuration Protocol)을 이용하여 NSF(들)에게 전달될 수 있다.
XML로 인코딩된 security policy rule이 수신된 후, NSF는 이미 사전-설정되어 있는 매칭되는 DM을 기반으로 수신된 security policy rule을 디코딩하고, 수신된 security policy rule로부터 content를 추출할 수 있다. 결국, NSF는 자신의 policy rule table 내 수신한 content를 등록할 수 있다.
CFI 및 RI를 표준화하기 위하여, IM 및 DM의 동일한 개념 및 절차가 적용될 수 있다.
결국, 본 발명에 따른 I2NSF architecture에서는 앞서 도 2에서 예시된 기존의 SFC 접근 방식과 비교하여 1 단계 내지 3 단계가 생략(skip)될 수 있다. 다시 말해, 트래픽(즉, packet)에 대한 SFC 설정 및 관리(SFC configuration & management)를 미리 정의하는 1 단계, I2NSF 아키텍처 내 유입된 트래픽(즉, packet)은 미리 정의된 SFC 설정 및 관리(SFC configuration & management)를 이용하여 해당 트래픽을 최초로 분류하는 2 단계 및 결정된 SFP에 통해 트래픽이 스티어링되는 3 단계가 생략될 수 있다.
즉, SFC 아키텍처에 친화적인 접근 방식은 기존의 표준이며, 정적인 서비스 기능 경로를 적용하기 위해 적합하다. 반면, I2NSF framework에 친화적인 본 발명의 제안은 NSF 경로 설정 및 관리가 미리 정의되지 않는다. 따라서, 분류기(classifier) 및 초기 분류(initial classification)가 요구되지 않는 장점이 있다. 또한, 재분류(re-classification)가 요구되지 않는 장점이 있다.
도 5는 본 발명의 일 실시예에 따른 트래픽 스티어링을 개념적으로 설명하기 위한 도면이다.
상술한 바와 같이, 본 발명에 따른 I2NSF architecture 내 NSF는 자신의 보안 검사 결과에 기반하여 서로 다른 NSF 타입으로 진보된 보안 동작(advanced security action)(예를 들어, DPI 및 DDoS attack mitigation)을 트리거할 수 있다. 도 5의 경우, I2NSF architecture 내 유입된 트래픽은 NSF1에 의해 검사되고, NSF1은 자신의 보안 검사 결과에 기반하여 NSF2의 보안 검사를 트리거할 수 있으며, NSF2는 자신의 보안 검사 결과에 기반하여 NSF3의 보안 검사를 트리거할 수 있으며, NSF3은 자신의 보안 검사 결과에 기반하여 NSF4의 보안 검사를 트리거할 수 있다.
advanced security action을 트리거링할 때, 현재 NSF는 suspicious packet에 메타데이터(metadata)를 추가할 수 있으며, metadata는 advanced security action을 위해 요구되는 security capability를 기술한다. 그리고, 현재 NSF는 다음 NSF에게 전달하기 위하여 패킷을 NSFF에게 전달한다.
NSFF는 하나의 NSF instance로부터 또 다른 NSF instance에게 packet을 전달하는 기능(즉, 트래픽 스티어링)을 수행한다.
traffic forwarding/steering 작업을 위해, NSFF(또는 NSF Operation Manager)는 시스템 내 이용 가능한 NSF instance의 forwarding information 테이블(table)을 유지할 수 있다. 전달할 패킷을 수신한 후에, NSFF는 먼저 패킷에 추가된 metadata 내에서 특정된 요구된(required) security capability와 매칭되는 NSF instance를 위한 table을 탐색할 수 있다.
NSFF는 packet을 전달하기 위한 다음 NSF instance가 어떤 NSF instance인지 Security Controller(또는 NSF operation manager)와 협의할 수 있다. 즉, NSFF가 어떠한 매칭되는 항목(entry)를 찾지 못하면, NSFF는 required security capability와 함께 NSF instance의 query를 Security Controller에게 전송할 수 있다.
Security Controller(또는 NSF operation manager)는 또한 시스템 내 현재 구동 중인 모든 NSF instance(들)의 정보의 table(즉, NSF 정보 테이블)을 유지할 수 있다.
여기서, NSF instance의 정보는 NSF profile, 전달 정보(즉, IP 주소, VxLAN 등), NSF의 능력, NSF의 로드 상태 중 하나 이상을 포함할 수 있다.
Security Controller(또는 NSF operation manager)가 NSFF로부터 query를 수신할 때, Security Controller(또는 NSF operation manager)는 문의된 security capability와 매칭되는 NSF instance를 위한 table을 탐색할 수 있다.
Security Controller(또는 NSF operation manager)는 NSFF에게 선택된 NSF instance의 전달 정보를 제공할 수 있다. 다시 말해, Security Controller(또는 NSF operation manager)가 매칭되는 NSF instance를 찾으면, Security Controller(또는 NSF operation manager)는 찾은 NSF instance의 forwarding information을 NSFF에게 응답한다.
그렇지 않으면, 시스템 내 required security capability를 가지는 기존의 NSF instance가 존재하지 않은 경우를 의미한다.
이 경우, Security Controller(또는 NSF operation manager)는 developer's management system에게 동적 인스턴스화(instantiation)(즉, NSF 생성) 또는 제거(elimination)을 요청한다. 다시 말해, Security Controller(또는 NSF operation manager)는 Developer's Management System에게 RI를 통해 required security capability로 새로운 NSF instance를 생성하도록 요청할 수 있다.
Developer's Management System은 제3자(third party) 도메인(예를 들어, NSF 벤더(vendor)의 클라우드) 내 존재할 수 있다.
Developer's Management System은 Security Controller의 요청에 기반하여 NSF instance를 생성할 수 있다. 이후에, Security Controller는 NSFF에게 생성된 NSF instance의 forwarding information를 알린다.
또한, Security Controller(또는 NSF operation manager)는 NSF instance의 현재 상태(즉, 로드가 가중되는지 혹은 사용되지 않는지)에 기반하여 Developer's Management System에게 NSF 인스턴스화(instantiation) 또는 제거(elimination)을 요청할 수 있다.
이 경우, Developer's Management System은 기존의 NSF instance가 혼잡될 때 추가의 NSF instance를 생성할 수 있으며, 또한, 사용되지 않은 하나 이상의 NSF instance를 제거할 수 있다.
결국, NSFF는 자신의 forwarding information table로부터의 또는 Security Controller로부터 수신한 forwarding information을 이용하여 타겟 NSF instance에게 패킷을 전달할 수 있다.
이하, 패킷 전달 헤더(Packet Forwarding Header)에 대하여 상세히 살펴본다.
도 6은 본 발명의 일 실시예에 따른 패킷 전달 헤더(Packet Forwarding Header)를 예시한다.
Packet Forwarding Header는 NSFF에게 검사 결과와 필요한 검사를 전달하기 위해 사용되므로 도 6과 같이 필드의 길이가 가변적일 수 있다.
Packet Forwarding Header는 고정된(fixed) 동작(Action) 또는 동작 코드(Action Code) 필드와 능력 정보의 수(SpecInfo Num) 필드, 그리고 가변적인(variable) 능력 정보(SpecInfo) 필드(들)을 포함할 수 있다.
Action Code 필드는 packet에 대한 보안 검사 결과를 포함할 수 있다.
packet의 보안 검사 결과 이상이 없어 목적지(destination)으로 전달하는 것을 허용하는 경우 "허용(allow)", packet의 보안 검사 결과 이상이 발견되어 packet을 목적지(destination)으로 전달하는 것을 허용하지 않는 경우 "거부(deny)", packet의 보안 검사 결과 또 다른 NSF에 의해 추가 보안 검사가 요구되는 경우 "진보된(advanced)" 및 packet의 보안 검사 결과 목적지(destination)으로 전달하는 것을 허용하되 또 다른 NSF에 의해 추가 보안 검사가 요구되는 경우 "미러(mirror)" 중 하나의 값을 포함할 수 있다.
SpecInfo Num 필드는 Packet Forwarding Header에 몇 개의 SpecInfo 필드(즉, 메타데이터)가 포함되는지 나타낸다.
각 SpecInfo 필드는 다음의 보안 검사를 위해 요구되는 보안 능력에 대한 정보를 포함할 수 있다. 즉, NSF profile의 일부를 포함할 수 있다. 복수의 SpecInfo 필드를 포함하는 Packet Forwarding Header가 패킷에 부착된 경우, NSFF를 통해 각 SpecInfo 필드 내 NSF의 서비스 프로파일에 매칭되는 복수의 NSF에게 패킷이 전달되어 추가 검사가 수행될 수 있다.
예를 들어, SepcInfo 필드는 NSF의 서비스 프로파일인 "SYN 플러드 완화(syn-flood-mitigate)", "UDP 플러드 완화(udp-flood-mitigate)" 등을 포함할 수 있다.
SYN 플러드는 공격자가 합법적인 트래픽에 대해 시스템이 응답하지 않도록 충분한 서버 자원을 사용하기 위해 SYN 요청을 대상 시스템에 전송하는 DoS 공격의 하나의 형태이다. UDP 플러드 공격은 세션없는/연결없는 컴퓨터 네트워킹 프로토콜인 UDP(User Datagram Protocol)를 사용하는 DoS 공격의 하나의 형태이다.
이하, 네트워크 보안 기능 전달자(NSFF: Network Security Function Forwarder)(또는 보안 기능 전달자(SFF: Security Function Forwarder))에 대하여 보다 상세히 살펴본다.
NSFF는 다음과 같은 두 가지 기능을 담당한다.
- NSF 향한 인터페이스(NFI)를 위한 I2NSF 정보 모델에서 설명된 바와 같이, 초기에 유입된(incoming) traffic/packet을 Network Security 서브-모듈(Sub-Module)(즉, NSF)로 전달
- Packet Forwarding Header에 지정된 NSF profile을 사용하여 일치하는 NSF로 traffic/packet을 전달
NSFF는 게이트웨이 기능을 사용하여 유입되는(incoming) traffic/packet을 먼저 수신한다.
그리고, NSFF는 traffic/packet을 Network Security Sub-Module(즉, NSF)에게 전달하기 위하여 외부 인캡슐레이션(outer encapsulation)을 traffic/packet에 부착한다.
예를 들어, Network Security Sub-Module(즉, NSF)은 packet header 검사를 수행하는 방화벽에 해당될 수 있다.
이 Network Security Sub-Module은 outer encapsulation와 원본 패킷(origin packet) 사이에 Packet Forwarding Header를 부착한다.
그리고, packet이 진보된 검사를 위해 컨텐츠 보안 서브-모듈(Content Security Sub-Module) 또는 완화 서브-모듈(Mitigate Sub-Module)에게 전달될 수 있도록, Packet Forwarding Header 내 NSF profile을 특정한다.
Network Security Sub-Module로부터 특정 NSF profile의 Packet Forwarding Header가 부착된 packet을 수신하면, NSFF는 NSF profile에 해당되는(즉, 매칭되는) 네트워크 보안 서비스를 제공하는 이용 가능한 NSF instance를 탐색한다. 그리고, NSFF는 찾은 NSF instance에게 packet을 전달한다.
NSF가 packet이 또 다른 타입의 NSF를 통한 추가적인 검사가 요구된다고 결정하면, NSF는 진보된 NSF의 NSF profile로 특정된(즉, 포함하는) packet forwarding header를 구성(construct)하고, 헤더를 packet에 부착한다. 그리고, packet을 NSFF에게 전송한다.
packet을 수신하면, NSFF는 packet forwarding header 내 특정된 NSF profile을 체크한다. 그리고, NSFF는 NSF Operation Manager와 협의함으로써 NSF profile와 매칭되는 NSF instance를 찾고, 해당 NSF instance에게 packet을 전달한다.
본 발명에 따른 NSF-triggered Traffic Steering Framework를 이용한 2가지의 실시예를 살펴본다.
(1) 패킷 소스의 신뢰 레벨에 따른 서로 다른 NSF의 시행(Enforcing Different NSFs Depending on a Packet Source’s Trust Level)
도 7은 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 트래픽의 흐름을 예시하는 도면이다.
본 발명에 따른 architecture에서, architecture로 유입된(incoming) 모든 packet은 최초로 NSFF에 도착한다.
현재 보안 정책이 모든 유입된(incoming) packet이 기본적으로 firewall에 의해 검사되도록 강제한다고 가정한다. 따라서, NSFF는 수신한 packet을 firewall instance에게 전달한다.
firewall은 traffic의 소스(source)를 식별하고, source의 신뢰 레벨(trust level)을 평가할 수 있다.
예를 들어, 방화벽 필터(firewall filter)는 먼저 네트워크 패킷(network packet)을 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류할 수 있다. 상술한 바와 같이, source의 신뢰 레벨(trust level)을 평가함으로써 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류할 수 있다.
도 7(a)와 같이 만약, traffic이 신뢰되는 source로부터 수신된 경우(또는 안전한 패킷(secure packet)으로 분류된 경우), traffic은 추가의 세부적인 검사 없이 단순히 목적지(destination)에게 전달될 수 있다.
반면, 도 7(a)와 같이 traffic이 신뢰되지 않은 source로부터 수신된 경우(또는 의심스러운 패킷(suspicious packet)으로 분류된 경우), firewall은 DPI에 해당하는 NSF profile을 포함하는 packet forwarding header를 packet에 부착하고, NSFF에게 packet forwarding header가 부착된 packet을 반환할 수 있다.
firewall로부터 packet forwarding header가 부착된 packet을 수신하면, NSFF는 해당 packet을 DPI instance에게 전달할 수 있다.
DPI instance는 수신한 packet의 페이로드(payload)에 대하여 상세한 검사를 수행할 수 있다.
그리고, DPI instance에 의해 packet의 페이로드(payload)에 대하여 상세한 검사를 수행한 결과, 안전한 패킷(secure packet)으로 판정된 경우, 해당 packet은 NSFF를 경유하여 목적지(destination)로 전달될 수 있다.
이와 같이, suspicious packet만을 침입 탐지 시스템(intrusion detection system) 내 DPI 모듈로 검사할 수 있다.
이때, dangerous packet은 firewall filter에 의해 단순히 드랍(drop)(즉, 삭제)될 수도 있다. 이 방법은 이미 안전하거나 위험한 것으로 분류 된 패킷에 대한 불필요한 분석 작업을 방지함으로써 intrusion detection system의 성능을 향상시키는 데 도움이 될 수 있다.
도 7(a)에서는 추가적인 검사를 위한 NSF로서 DPI를 예시하고 있으나 이는 하나의 예시에 불과하며 본 발명이 이에 한정되는 것은 아니고 다른 NSF가 이용될 수도 있다.
한편, 의심스러운 패킷(suspicious packet)으로 분류할 때 소스의 신뢰도의 레벨의 고려하여 의심스러운 정도가 복수로 구분될 수도 있으며, 의심스러운 정도의 레벨에 따라 NSF에 의한 추가적인 검사의 정도/횟수가 정해질 수 있다. 이에 대하여 도 8을 참조하여 보다 상세히 살펴본다.
도 8은 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 트래픽의 흐름을 예시하는 도면이다.
도 8(a)를 참조하여 트래픽의 흐름을 살펴본다.
(1 단계) I2NSF 시스템으로 유입된(incoming) 모든 packet은 최초로 NSFF에 도착한다.
(2 단계) packet은 firewall instance에 의해 신뢰 레벨(trust level)이 평가될 수 있다.
2 단계에 대하여 보다 구체적으로 살펴보면, NSFF는 수신한 packet을 firewall instance에게 전달한다.
firewall은 traffic의 소스(source)를 식별하고, source의 신뢰 레벨(trust level)을 평가할 수 있다.
예를 들어, 방화벽 필터(firewall filter)는 먼저 네트워크 패킷(network packet)을 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류할 수 있다. 상술한 바와 같이, source의 신뢰 레벨(trust level)을 평가함으로써 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류할 수 있다.
이때, 의심스러운 패킷(suspicious packet)으로 분류할 때 소스의 신뢰도의 레벨의 고려하여 의심스러운 정도가 복수로 구분될 수도 있다. 따라서, 의심스러운 정도의 레벨에 따라 NSF에 의한 추가적인 검사의 정도/횟수가 정해질 수 있다. 예를 들어, packet의 의심스러운 정도의 레벨이 2가지의 레벨로 구분되고, 그 의심스러운 정도의 정도가 클수록 레벨이 크게 정해진다고 가정한다. 이 경우, Firewall instance에 의한 packet의 분류 결과 packet의 의심스러운 정도의 레벨이 1 레벨인 경우, IDS/IPS에 의한 추가 검사가 진행될 수 있다.
해당 packet이 의심스러운 패킷(suspicious packet)으로 분류되고 그 레벨이 1인 경우, firewall은 IDS/IPS에 해당하는 NSF profile을 포함하는 packet forwarding header를 packet에 부착하고, NSFF에게 packet forwarding header가 부착된 packet을 반환할 수 있다.
(3 단계) 다음으로, packet은 IDS/IPS에 의해 상세하게 검사될 수 있다.
3 단계에 대하여 보다 구체적으로 살펴보면, firewall로부터 packet forwarding header가 부착된 packet을 수신하면, NSFF는 해당 packet을 IDS/IPS instance에게 전달할 수 있다.
IDS/IPS instance는 수신한 packet에 대하여 상세한 검사를 수행할 수 있다.
만약, IDS/IPS instance에 의해 packet에 대하여 상세한 검사를 수행한 결과, 안전한 패킷(secure packet) 판정된 경우, IDS/IPS instance는 packet을 NSFF에게 반환할 수 있다.
반면, IDS/IPS instance에 의해 packet에 대하여 상세한 검사를 수행한 결과, 안전한 패킷(secure packet)이 아니라고 판정된 경우, IDS/IPS instance는 packet을 드랍(drop)할 수 있다.
(4 단계) IDS/IPS instance로부터 packet을 수신한 NSFF는 목적지(destination)로 packet을 전달할 수 있다.
도 8(b)를 참조하여 트래픽의 흐름을 살펴본다.
(1 단계) I2NSF 시스템으로 유입된(incoming) 모든 packet은 최초로 NSFF에 도착한다.
(2 단계) packet은 firewall instance에 의해 신뢰 레벨(trust level)이 평가될 수 있다.
2 단계에 대하여 보다 구체적으로 살펴보면, NSFF는 수신한 packet을 firewall instance에게 전달한다.
firewall은 traffic의 소스(source)를 식별하고, source의 신뢰 레벨(trust level)을 평가할 수 있다.
예를 들어, 방화벽 필터(firewall filter)는 먼저 네트워크 패킷(network packet)을 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류할 수 있다. 상술한 바와 같이, source의 신뢰 레벨(trust level)을 평가함으로써 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류할 수 있다.
이때, 의심스러운 패킷(suspicious packet)으로 분류할 때 소스의 신뢰도의 레벨의 고려하여 의심스러운 정도가 복수로 구분될 수도 있다. 따라서, 의심스러운 정도의 레벨에 따라 NSF에 의한 추가적인 검사의 정도/횟수가 정해질 수 있다. 예를 들어, packet의 의심스러운 정도의 레벨이 2가지의 레벨로 구분되고, 그 의심스러운 정도의 정도가 클수록 레벨이 크게 정해진다고 가정한다. 이 경우, Firewall instance에 의한 packet의 분류 결과 의심스러운 정도의 레벨이 2 레벨인 경우, IDS/IPS, Anti-Spoofing, DPI에 의한 추가 검사가 진행될 수 있다.
해당 packet이 의심스러운 패킷(suspicious packet)으로 분류되고 그 레벨이 2인 경우, firewall은 IDS/IPS에 해당하는 NSF profile을 포함하는 packet forwarding header를 packet에 부착하고, NSFF에게 packet forwarding header가 부착된 packet을 반환할 수 있다.
(3 단계) 다음으로, packet은 IDS/IPS에 의해 상세하게 검사될 수 있다.
3 단계에 대하여 보다 구체적으로 살펴보면, firewall로부터 packet forwarding header가 부착된 packet을 수신하면, NSFF는 해당 packet을 IDS/IPS instance에게 전달할 수 있다.
IDS/IPS instance는 수신한 packet에 대하여 상세한 검사를 수행할 수 있다.
만약, IDS/IPS instance에 의해 packet에 대하여 상세한 검사를 수행한 결과, 안전한 패킷(secure packet)으로 판정된 경우, IDS/IPS instance는 패킷이 전달될 다음 NSF를 기술하기 위해 Anti-Spoofing에 해당하는 NSF profile을 포함하는 packet forwarding header를 packet에 부착하고, NSFF에게 packet forwarding header가 부착된 packet을 반환할 수 있다.
반면, IDS/IPS instance에 의해 packet에 대하여 상세한 검사가 수행된 결과, 안전한 패킷(secure packet)이 아니라고 판정된 경우, IDS/IPS instance는 packet을 드랍(drop)할 수 있다.
(4 단계) 다음으로, packet은 Anti-Spoofing에 의해 상세하게 검사될 수 있다.
4 단계에 대하여 보다 구체적으로 살펴보면, IDS/IPS로부터 packet forwarding header가 부착된 packet을 수신하면, NSFF는 해당 packet을 Anti-Spoofing instance에게 전달할 수 있다.
Anti-Spoofing instance는 수신한 packet에 대하여 상세한 검사를 수행할 수 있다.
만약, Anti-Spoofing instance에 의해 packet에 대하여 상세한 검사가 수행된 결과, 안전한 패킷(secure packet)으로 판정된 경우, Anti-Spoofing instance는 DPI에 해당하는 NSF profile을 포함하는 packet forwarding header를 packet에 부착하고, NSFF에게 packet forwarding header가 부착된 packet을 반환할 수 있다.
반면, Anti-Spoofing instance에 의해 packet에 대하여 상세한 검사를 수행한 결과, 안전한 패킷(secure packet)이 아니라고 판정된 경우, Anti-Spoofing instance는 packet을 드랍(drop)할 수 있다.
(5 단계) 다음으로, packet은 DPI에 의해 상세하게 검사될 수 있다.
5 단계에 대하여 보다 구체적으로 살펴보면, Anti-Spoofing으로부터 packet forwarding header가 부착된 packet을 수신하면, NSFF는 해당 packet을 DPI instance에게 전달할 수 있다.
DPI instance는 수신한 packet에 대하여 상세한 검사를 수행할 수 있다.
만약, DPI instance에 의해 packet에 대하여 상세한 검사가 수행된 결과, 안전한 패킷(secure packet) 판정된 경우, DPI instance는 packet을 NSFF에게 반환할 수 있다.
반면, DPI instance에 의해 packet에 대하여 상세한 검사를 수행한 결과, 안전한 패킷(secure packet)이 아니라고 판정된 경우, DPI instance는 packet을 드랍(drop)할 수 있다.
(6 단계) DPI instance로부터 packet을 수신한 NSFF는 목적지(destination)에게 packet을 전달할 수 있다.
(2) 동적 NSF 인스턴스화를 이용한 효과적인 로드 밸런싱(Effective Load Balancing with Dynamic NSF Instantiation)
도 9는 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 로드 밸런싱 방법을 예시하는 도면이다.
대규모의 네트워크 도메인(domain)에서, 일반적으로 다양한 보안 서비스를 제공하는 다수의 NSF instance가 존재한다. 이때, 특정 NSF instance가 자신의 능력을 벗어나 과도한 traffic 양을 겪을 수 있다. 이 경우, traffic의 일부를 또 다른 이용 가능한 동일 NSF의 instance에게 할당하는 것이 요구된다.
만약, 동일 NSF의 이용 가능한 추가의 instance가 없다면, 새로운 NSF instance를 생성하고, 새로운 instance에게 다음의 traffic이 향하도록 할 필요가 있다. 이렇게 함으로써, 서비스 혼잡을 방지하고, 더욱 효율적인 자원 활용을 달성할 수 있다.
이 프로세스는 공통적으로 load balancing으로 지칭될 수 있다.
본 발명에 따른 architecture에서, NSF Operation Manager는 이용 가능한 NSF instance의 트래픽 로드 상태를 주기적으로 모니터링할 수 있다.
또한, 본 발명에 따르면, Developer’s Management System을 통해 새로운 NSF instance가 동적으로 생성될 수 있다.
이러한 동적 NSF instance 생성이 traffic steering 메커니즘과 결합됨으로서 결국 load balancing 서비스를 제공할 수 있다.
이하, firewall instance에서 혼잡이 발생될 때, load balancing의 상세한 프로세스를 살펴본다.
(1 단계) NSF Operation Manager는 현재 가용한 firewall instance가 너무 많은 요청을 수신하였음을 감지한다. 즉, firewall instance에 과도한 트래픽이 발생하였음을 감지한다.
(2 단계) 현재, 추가로 이용 가능한 firewall instance가 없다고 가정한다.
추가로 이용 가능한 firewall instance가 없으므로, NSF Operation Manager가 Developer’s Management System에게 동일한 보안 서비스를 제공할 수 있는 새로운 firewall instance의 생성을 요청한다.
(3 단계) Developer’s Management System은 새로운 firewall instance를 생성하고, 새로운 firewall instance의 정보를 NSF Operation Manager에게 등록한다.
NSF Operation Manager는 새로운 firewall instance를 반영하여 NSF 정보 테이블(NSF information table)을 업데이트하고, NSF 및 NSFF에게 이러한 업데이트를 알린다.
(4 단계) 새로운 전달 정보(forwarding information)에 따라, NSFF는 다음의 traffic을 새로운 firewall instance에게 전달한다. 결과적으로, 기존의 firewall instance의 부담을 효과적으로 완화시킬 수 있다.
이하, 본 발명에 따른 NSF-triggered Traffic Steering Framework를 활용한 예를 살펴본다.
이하, 2가지의 시나리오에 대하여 살펴본다.
- 시간-종속적인 웹 액세스 필터링(Time-dependent Web Access Filtering)
이 시나리오에서, I2NSF 기반 기업(corporate) 네트워크 시스템을 가정하고, 기업(corporate) 관리자가 근무 시간 동안에 직원들이 소셜 네트워킹 사이트에 액세스하는 것을 방지하는 것을 원한다고 가정한다.
이 시나리오에서, 기업 네트워크 관리자는 I2NSF user에 해당한다. 그리고, I2NSF user는 먼저 근무 시간 동안 직원들의 소셜 네트워킹 사이트로의 액세스를 제한(block)하는 high-level security policy를 명시(특정)한다.
예를 들어, "오전 9시부터 오후 6시까지 직원들에 의한 소셜 네트워킹 사이트로의 모든 액세스를 차단"와 같이 high-level security policy가 특정될 수 있다.
관리자는 CFI를 통해 Security Controller에게 high-level security policy를 전달한다.
high-level security policy가 수신될 때, Security Controller는 high-level security policy를 low-level security policy rule으로 변환한다. Security Controller는 먼저 기업 네트워크 시스템의 IP 주소 매핑의 데이터베이스를 액세스하여, 직원들에 의해 사용될 IP 주소들을 찾는다(figure out). 이 정보에 기반하여, Security Controller는 직원들의 IP 주소로부터 소셜 네트워킹 사이트로의 액세스를 제한하는 firewall rule을 생성한다. firewall rule은 또한 근무 시간에 대한 정보를 포함한다.
Security Controller는 NFI를 통해 생성된 security policy rule를 firewall에 설정한다.
그리고, 직원이 근무 시간 동안에 그의 컴퓨터를 이용하여 소셜 네트워킹 사이트로 액세스를 시도하면, 액세스 요청 패킷(access request packet)은 firewall에게 전달된다.
firewall은 패킷 헤더(packet header)를 검사하고, 해당 packet이 소셜 네트워킹 사이트로 전달될지 여부를 판단한다. 예를 들어, 소스/목적지 IP 주소를 이용하여 소셜 네트워킹 사이트로 전달될지 여부를 판단할 수 있다.
그리고, 현재 시간을 체크하여 근무 시간 내인지 여부를 판단한다. packet이 2가지의 조건에 만족하면, firewall은 소셜 네트워킹 사이트로의 액세스를 제한하기 위하여 해당 packet을 드랍(drop)한다.
- suspicious VoIP(Voice over Internet Protocol)/VoLTE(Voice over Long Term Evolution) 패킷에 대한 선택적인 보안 검사
이 시나리오는 자신의 고객의 VoIP/VoLTE 호(call)를 위한 보안 서비스를 제공하길 원하는 이동 통신 서비스 제공자에 관한 것이다.
이 시나리오에서, 이동 통신 서비스 네트워크의 관리자가 자신의 고객의 VoIP/VoLTE 호(call)에 보안 서비스를 제공하길 원한다. 이 시나리오의 관리자는 I2NSF user에 해당한다. 그리고, I2NSF user는 도착하는(incoming) VoIP/VoLTE packet에 적용하길 원하는 high-level security policy rule을 명시(특정)한다.
예를 들어, "밤에 특이한(unusual) 국가로부터 개시된 VoIP/VoLTE call의 패킷에 대하여 보안 검사를 수행하여, 악의적인지(malicious) 여부를 판단하고, 검출된 malicious call는 관리자에게 보고한다"와 같이 high-level security policy가 특정될 수 있다. 관리자는 Security Controller에게 high-level security policy rule을 전송한다.
관리자로부터 high-level security policy rule을 수신할 때, Security Controller는 level security policy rule 내 국가 명칭을 해당 IP 주소 범위로 변환한다. 그리고, Security Controller는 call packet의 소스 주소(source address) 및 목적지 주소(destination address)를 체크함으로써 VoIP/VoLTE call이 의심스러운지 여부를 결정하기 위하여 firewall rule을 생성하고, 생성된 rule을 firewall instance에 설정한다.
또한, Security Controller는 malicious call에 해당하는 VoIP/VoLTE packet의 다양한 필드를 체크하기 위한 DPI rule을 생성하고, 그러한 rule을 DPI instance에 전송한다.
도 10 내지 도 13은 본 발명의 일 실시예에 따른 NSF에 의해 트리거된 트래픽 스티어링 프레임워크를 활용하여 유입되는 VoIP/VoLTE 패킷에 수행되는 단계 별 절차를 예시한다.
도 10과 같이, VoIP/VoLTE packet이 모바일 서비스 제공자의 네트워크에 도착한 후, VoIP/VoLTE packet은 firewall에 전달되거나 또는 복사(mirror)된다. Security Controller에 의해 설정된 rule에 기반하여, firewall은 이 트래픽이 unusual call 패턴에 해당하는지 여부를 결정한다.
이 트래픽이 unusual하고, suspicious하다면, firewall은 VoIP/VoLTE packet의 다양한 필드에 대한 더욱 상세한 보안 검사를 위한 DPI를 트리거한다.
예를 들어, NSFF 1은 패킷에 Packet Forwarding Header를 부착할 수 있다. Packet Forwarding Header는 T 필드(앞서 도 6에서 Action Code 필드), N 필드(SpecInfo Num 필드), Spec 필드(SpecInfo 0...n 필드)를 포함할 수 있다. 그리고, NSFF 1은 Packet Forwarding Header 내 T 필드의 값을 "진보된(advanced)" 및 "미러(mirror)" 중 하나로 셋팅할 수 있으며, Spec 필드는 추가로 검사되어야 할 NSF의 profile로 셋팅될 수 있다. 만약, T 필드가 "진보된(advanced)"으로 셋팅되고, Spec 필드가 DPI profile로 셋팅된 경우, 해당 트래픽 패킷은 NSFF를 경유하여 DPI로 전달될 수 있다.
만약, T 필드가 "미러(mirror)"로 셋팅되고, Spec 필드가 DPI profile로 셋팅된 경우, 도 11과 같이 유입된 패킷은 인트라넷(intranet)으로 전달되고, 미러링(복사)를 통해 복사된 패킷은 NSFF를 경유하여 DPI로 전달될 수 있다.
도 12와 같이, security policy rule table 내 VoIP/VoLTE packet의 rule에 기반하여, DPI는 수신한 VoIP/VoLTE packet의 다양한 필드를 체크하고, 이 call이 악의적(malicious)인지 여부를 결정한다. 그리고, DPI가 판단한 결과, malicious traffic packet 으로 결정한 경우, 해당 traffic packet을 드랍(drop)할 수 있다.
그리고, 도 13과 같이 call이 malicious하다면, DPI는 NFI 및 CFI를 통해 검출된 malicious 동작을 I2NSF user에게 통지할 수 있다. 즉, DPI는 NFI를 통해 malicious 동작을 NSF Operation Manager에게 통지하고, NSF Operation Manager는 CFI를 통해 malicious 동작을 I2NSF user에게 통지할 수 있다.
도 14는 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 방법을 예시한다.
도 14를 참조하면, NSF는 트래픽 스티어링(traffic steering)을 지원하는 시스템에 유입된 패킷에 대한 보안 검사를 수행한다(S1401).
이때, 시스템에 유입된 패킷은 NSFF에 의해 수신되고, NSFF에 의해 NSF에게 전달될 수 있다.
보안 검사의 결과에 기반하여, NSF는 또 다른 NSF에 의한 추가적인 검사가 필요한지 여부를 판단한다(S1402).
NSF는 패킷의 소스(source)의 신뢰 레벨(trust level)에 따라 패킷을 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류할 수 있다.
패킷이 상기 안전한 패킷(secure packet)으로 분류된 경우 또 다른 NSF를 통해 추가의 보안 검사 없이 패킷의 목적지(destination)으로 전달될 수 있다. 또는 패킷이 상기 위험한 패킷(dangerous packet)으로 분류된 경우 패킷은 드랍(drop)될 수 있다. 또는 패킷이 상기 의심스러운 패킷(suspicious packet)으로 분류된 경우 패킷은 패킷 전달 헤더가 부착되어 NSFF에게 전달될 수 있다.
추가적인 검사가 필요하면, NSF는 추가적인 검사를 호출하기 위한 패킷 전달 헤더(packet forwarding header)를 패킷에 부착한다(S1403).
이때, 패킷 전달 헤더는 상기 추가적인 검사를 위해 요구되는 보안 능력에 대한 정보를 포함할 수 있다.
보다 구체적으로, 패킷 전달 헤더는 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드, 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함할 수 있다.
NSF는 패킷 전달 헤더가 부착된 패킷을 NSFF에게 전송한다(S1404).
도 15는 본 발명의 일 실시예에 따른 NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 장치의 블록 구성도를 예시한다.
도 15를 참조하면, NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 장치(1500)는 프로세서(processor, 1501), 메모리(memory, 1502) 및 통신 모듈(communication module, 1503)을 포함한다.
NSF에 의해 트리거되는(NSF-triggered) 트래픽 스티어링(traffic steering) 시스템 내 장치(1500)는 앞서 설명한 NSF, NSFF, Security Controller, NSF Operation Manager, Developer's Management System, I2NSF user에 해당될 수 있다.
프로세서(1501)는 앞서 도 1 내지 도 14에서 제안된 기능, 과정 및/또는 방법을 구현한다. 메모리(1502)는 프로세서(1501)와 연결되어, 프로세서(1501)를 구동하기 위한 다양한 정보를 저장한다. 통신 모듈(1503)은 프로세서(1501)와 연결되어, 유/무선 신호를 송신 및/또는 수신한다.
메모리(1502)는 프로세서(1501) 내부 또는 외부에 있을 수 있고, 잘 알려진 다양한 수단으로 프로세서(1501)와 연결될 수 있다.
이상에서 설명된 실시예들은 본 발명의 구성요소들과 특징들이 소정 형태로 결합된 것들이다. 각 구성요소 또는 특징은 별도의 명시적 언급이 없는 한 선택적인 것으로 고려되어야 한다. 각 구성요소 또는 특징은 다른 구성요소나 특징과 결합되지 않은 형태로 실시될 수 있다. 또한, 일부 구성요소들 및/또는 특징들을 결합하여 본 발명의 실시예를 구성하는 것도 가능하다. 본 발명의 실시예들에서 설명되는 동작들의 순서는 변경될 수 있다. 어느 실시예의 일부 구성이나 특징은 다른 실시예에 포함될 수 있고, 또는 다른 실시예의 대응하는 구성 또는 특징과 교체될 수 있다. 특허청구범위에서 명시적인 인용 관계가 있지 않은 청구항들을 결합하여 실시예를 구성하거나 출원 후의 보정에 의해 새로운 청구항으로 포함시킬 수 있음은 자명하다.
본 발명에 따른 실시예는 다양한 수단, 예를 들어, 하드웨어, 펌웨어(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 (15)

  1. 네트워크 보안 기능(NSF: Network Security Function)에 의해 트리거되는 트래픽 스티어링(traffic steering)을 지원하는 시스템에 있어서,
    상기 시스템에 유입된 패킷에 대한 보안 검사를 수행하고, 상기 보안 검사의 결과에 기반하여 또 다른 NSF에 의한 추가적인 검사가 필요한지 여부를 판단하고, 상기 추가적인 검사가 필요하면, 상기 추가적인 검사를 호출하기 위한 패킷 전달 헤더(packet forwarding header)를 상기 패킷에 부착하고, 상기 패킷 전달 헤더가 부착된 패킷을 NSF 전달자(NSFF: NSF Forwarder)에게 전송하는 제1 NSF; 및
    상기 패킷 전달 헤더에 포함된 상기 추가적인 검사를 위해 요구되는 보안 능력을 가진 제2 NSF를 탐색한 경우, 상기 제2 NSF에게 상기 패킷을 전달하는 NSFF를 포함하는 트래픽 스티어링 시스템.
  2. 제1항에 있어서,
    상기 패킷 전달 헤더는 상기 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 상기 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드, 상기 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함하는 트래픽 스티어링 시스템.
  3. 제1항에 있어서,
    상기 시스템에 유입된 패킷은 상기 NSFF에 의해 수신되고, 상기 NSFF에 의해 상기 제1 NSF에게 전달되는 트래픽 스티어링 시스템.
  4. 제1항에 있어서,
    상기 패킷의 소스(source)의 신뢰 레벨(trust level)에 따라 상기 제1 NSF에 의해 상기 패킷은 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류되는 트래픽 스티어링 시스템.
  5. 제4항에 있어서,
    상기 패킷이 상기 안전한 패킷(secure packet)으로 분류된 경우 또 다른 NSF를 통해 추가의 보안 검사 없이 상기 패킷의 목적지(destination)으로 전달되는 트래픽 스티어링 시스템.
  6. 제4항에 있어서,
    상기 패킷이 상기 위험한 패킷(dangerous packet)으로 분류된 경우 상기 패킷은 드랍(drop)되는 트래픽 스티어링 시스템.
  7. 제4항에 있어서,
    상기 패킷이 상기 의심스러운 패킷(suspicious packet)으로 분류된 경우 상기 패킷은 상기 패킷 전달 헤더가 부착되어 상기 NSFF에게 전달되는 트래픽 스티어링 시스템.
  8. 제1항에 있어서,
    이용 가능한 모든 NSF에 대한 정보 리스트를 관리하는 NSF 운영 관리자(operation management)를 더 포함하는 트래픽 스티어링 시스템.
  9. 제8항에 있어서,
    상기 제2 NSF를 탐색하지 못한 경우, 상기 NSFF는 상기 추가적인 검사를 위해 요구되는 보안 능력을 포함하는 NSF 생성 요청 패킷을 상기 NSF 운영 관리자에게 전송하고, 상기 NSF 운영 관리자로부터 생성된 제3 NSF에 대한 정보를 수신하면 상기 제3 NSF에게 상기 패킷을 전달하고,
    상기 NSF 운영 관리자는 상기 정보 리스트 내에서 각 NSF의 트래픽 로드 상태를 고려하여 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 상기 제3 NSF를 선택하고, 상기 제3 NSF에 대한 정보를 상기 NSFF에게 전송하는 트래픽 스티어링 시스템.
  10. 제9항에 있어서,
    상기 정보 리스트 내에서 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 NSF가 존재하지 않는 경우,
    개발자 관리 시스템(developer's management system)에게 상기 추가적인 검사를 위해 요구되는 보안 능력을 가지는 NSF의 생성을 요청하는 트래픽 스티어링 시스템.
  11. 제8항에 있어서,
    상기 NSF 운영 관리자가 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고,
    특정 NSF에 대하여 과도한 트래픽이 발생됨을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 과도한 트래픽이 발생된 NSF와 동일한 보안 능력을 가지는 새로운 NSF의 생성을 요청하는 트래픽 스티어링 시스템.
  12. 제8항에 있어서,
    상기 NSF 운영 관리자가 이용 가능한 모든 NSF의 트래픽 로드 상태를 모니터링하고,
    특정 NSF가 이용되지 않음을 감지하면, 개발자 관리 시스템(developer's management system)에게 상기 이용되지 않는 NSF의 제거를 요청하는 트래픽 스티어링 시스템.
  13. 네트워크 보안 기능(NSF: Network Security Function)이 트래픽 스티어링(traffic steering)을 수행하는 방법에 있어서,
    상기 트래픽 스티어링(traffic steering)을 지원하는 시스템에 유입된 패킷에 대한 보안 검사를 수행하는 단계;
    상기 보안 검사의 결과에 기반하여 또 다른 NSF에 의한 추가적인 검사가 필요한지 여부를 판단하는 단계;
    상기 추가적인 검사가 필요하면, 상기 추가적인 검사를 호출하기 위한 패킷 전달 헤더(packet forwarding header)를 상기 패킷에 부착하는 단계; 및
    상기 패킷 전달 헤더가 부착된 패킷을 NSF 전달자(NSFF: NSF Forwarder)에게 전송하는 단계를 포함하고,
    상기 패킷 전달 헤더는 상기 추가적인 검사를 위해 요구되는 보안 능력에 대한 정보를 포함하는 트래픽 스티어링 방법.
  14. 제13항에 있어서,
    상기 패킷 전달 헤더는 상기 패킷의 보안 검사의 결과를 포함하는 동작 코드 필드, 상기 추가적인 검사를 위해 요구되는 보안 능력 정보를 포함하는 능력 정보 필드, 상기 능력 정보 필드의 개수를 나타내는 능력 정보의 수 필드를 포함하는 트래픽 스티어링 방법.
  15. 제13항에 있어서,
    상기 패킷의 소스(source)의 신뢰 레벨(trust level)에 따라 상기 제1 NSF에 의해 상기 패킷이 안전한 패킷(secure packet), 위험한 패킷(dangerous packet) 및 의심스러운 패킷(suspicious packet)으로 분류되는 트래픽 스티어링 방법.
PCT/KR2017/004510 2016-11-24 2017-04-27 네트워크 보안 기능에 의해 트리거되는 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치 Ceased WO2018097422A1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2016-0157771 2016-11-24
KR20160157771 2016-11-24
KR20160160786 2016-11-29
KR10-2016-0160786 2016-11-29

Publications (1)

Publication Number Publication Date
WO2018097422A1 true WO2018097422A1 (ko) 2018-05-31

Family

ID=62195184

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/004510 Ceased WO2018097422A1 (ko) 2016-11-24 2017-04-27 네트워크 보안 기능에 의해 트리거되는 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치

Country Status (1)

Country Link
WO (1) WO2018097422A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020009418A1 (ko) * 2018-07-02 2020-01-09 성균관대학교 산학협력단 I2nsf 네트워크 보안 기능에 직면한 인터페이스 yang 데이터 모델
US20210029175A1 (en) * 2019-07-24 2021-01-28 Research & Business Foundation Sungkyunkwan University Security policy translation in interface to network security functions

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090031380A (ko) * 2006-06-07 2009-03-25 퀄컴 인코포레이티드 통신 프로세싱을 제어하기 위해 제어값을 사용하는 방법 및장치
KR20100132079A (ko) * 2002-11-07 2010-12-16 팁핑포인트 테크놀러지스 인코포레이티드 능동 네트워크 방어 시스템 및 방법
KR101445765B1 (ko) * 2013-07-03 2014-10-06 한국전자통신연구원 네트워크 관리 장치 및 그 관리 방법
US20150215285A1 (en) * 2012-07-31 2015-07-30 Hewlett-Packard Developement Company, L.P. Network traffic processing system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100132079A (ko) * 2002-11-07 2010-12-16 팁핑포인트 테크놀러지스 인코포레이티드 능동 네트워크 방어 시스템 및 방법
KR20090031380A (ko) * 2006-06-07 2009-03-25 퀄컴 인코포레이티드 통신 프로세싱을 제어하기 위해 제어값을 사용하는 방법 및장치
US20150215285A1 (en) * 2012-07-31 2015-07-30 Hewlett-Packard Developement Company, L.P. Network traffic processing system
KR101445765B1 (ko) * 2013-07-03 2014-10-06 한국전자통신연구원 네트워크 관리 장치 및 그 관리 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HYUN, S. ET AL.: "NSF-triggered Traffic Steering in I2NSF Framework draft-hyun-i2-nsf-triggered-steering-01", NETWORK WORKING GROUP, 13 November 2016 (2016-11-13), pages 1 - 14, XP015116617 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020009418A1 (ko) * 2018-07-02 2020-01-09 성균관대학교 산학협력단 I2nsf 네트워크 보안 기능에 직면한 인터페이스 yang 데이터 모델
KR20200003738A (ko) * 2018-07-02 2020-01-10 성균관대학교산학협력단 I2nsf 네트워크 보안 기능에 직면한 인터페이스 yang 데이터 모델
KR102256641B1 (ko) * 2018-07-02 2021-05-27 성균관대학교산학협력단 I2nsf 네트워크 보안 기능에 직면한 인터페이스 yang 데이터 모델
US20210029175A1 (en) * 2019-07-24 2021-01-28 Research & Business Foundation Sungkyunkwan University Security policy translation in interface to network security functions
US11632402B2 (en) * 2019-07-24 2023-04-18 Research & Business Foundation Sungkyunkwan University Security policy translation in interface to network security functions

Similar Documents

Publication Publication Date Title
WO2021060857A1 (ko) 원격 실행 코드 기반 노드의 제어 플로우 관리 시스템 및 그에 관한 방법
WO2020231120A1 (ko) 에지 컴퓨팅 서비스에서 단말의 식별자 관리 방법 및 장치
WO2021133092A1 (en) Method and apparatus to manage nssaa procedure in wireless communication network
WO2021235880A1 (ko) 무선 통신 시스템에서 단말로 지역 데이터 네트워크 정보를 제공하기 위한 방법 및 장치
WO2021054747A1 (ko) 무선 통신 시스템에서 psa-upf 재배치를 위한 장치 및 방법
WO2018101565A1 (ko) 네트워크 가상화 환경에서 보안 관리를 위한 구조
WO2019098678A1 (ko) 보안 서비스를 제공하기 위한 방법 및 이를 위한 장치
WO2015046961A1 (ko) M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치
WO2012091529A2 (ko) 단말기
WO2021206519A1 (en) Apparatus and method for transmitting bridge management information in wireless communication system
WO2013085281A1 (ko) 클라우딩 컴퓨팅 서비스에서의 보안을 위한 방법 및 장치
WO2014185754A1 (ko) M2m 통신 시스템에서 구독 및 통지를 위한 방법 및 이를 위한 장치
WO2014186986A1 (zh) 流转发方法、设备及系统
WO2023158111A1 (ko) 자율 운항 선박의 사이버 보안 관리 시스템
WO2020149617A1 (en) A method of securing unicast message communication in 3gpp based wireless networks
WO2018048230A1 (en) Method for managing short data service (sds) in mission critical data (mc data) communication system
WO2016013846A1 (ko) 무선 통신 시스템에서 요청 메시지를 처리하기 위한 방법 및 이를 위한 장치
EP3114820A1 (en) Method and system for establishing a service session between seeker device and advertiser device
WO2019088671A1 (ko) 네트워크 보안 서비스를 제공하기 위한 방법 및 이를 위한 장치
WO2023059127A1 (ko) 무선 통신 시스템에서 트래픽 분류를 이용한 트래픽 처리 방법 및 장치
WO2021071316A1 (en) Method and apparatus for edge computing service
WO2023033588A1 (ko) 가상화 단말에서 데이터 플로우를 제어하기 위한 시스템 및 그에 관한 방법
WO2018097422A1 (ko) 네트워크 보안 기능에 의해 트리거되는 트래픽 스티어링을 위한 방법 및 시스템, 이를 위한 장치
WO2020009418A1 (ko) I2nsf 네트워크 보안 기능에 직면한 인터페이스 yang 데이터 모델
WO2017131285A1 (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: 17874431

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: 17874431

Country of ref document: EP

Kind code of ref document: A1