WO2018097422A1 - Procédé et système d'orientation de trafic déclenchée par une fonction de sécurité de réseau, et dispositif associé - Google Patents

Procédé et système d'orientation de trafic déclenchée par une fonction de sécurité de réseau, et dispositif associé 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
Application number
PCT/KR2017/004510
Other languages
English (en)
Korean (ko)
Inventor
정재훈
현상원
우상욱
여윤석
Original Assignee
성균관대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 성균관대학교 산학협력단 filed Critical 성균관대학교 산학협력단
Publication of WO2018097422A1 publication Critical patent/WO2018097422A1/fr

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

L'invention concerne un procédé et un système d'orientation de trafic déclenchée par une fonction de sécurité de réseau (NSF), et un dispositif associé. En particulier, un système destiné à soutenir l'orientation de trafic déclenchée par une NSF peut comporter un moyen de transfert de NSF (NSFF) servant à: effectuer une vérification de sécurité sur un paquet introduit dans le système; déterminer si une vérification supplémentaire par une autre NSF est nécessaire, d'après le résultat de la vérification de sécurité; joindre au paquet un en-tête de transfert de paquet pour appeler la vérification supplémentaire si la vérification supplémentaire est nécessaire; et envoyer le paquet à une deuxième NSF si une première NSF destinée à envoyer au NSFF le paquet auquel l'en-tête de transfert de paquet est joint et une deuxième NSF dotée d'une capacité de sécurité exigée pour la vérification supplémentaire comprise dans l'en-tête de transfert de paquet sont découvertes.
PCT/KR2017/004510 2016-11-24 2017-04-27 Procédé et système d'orientation de trafic déclenchée par une fonction de sécurité de réseau, et dispositif associé WO2018097422A1 (fr)

Applications Claiming Priority (4)

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

Publications (1)

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

Family

ID=62195184

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/004510 WO2018097422A1 (fr) 2016-11-24 2017-04-27 Procédé et système d'orientation de trafic déclenchée par une fonction de sécurité de réseau, et dispositif associé

Country Status (1)

Country Link
WO (1) WO2018097422A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020009418A1 (fr) * 2018-07-02 2020-01-09 성균관대학교 산학협력단 Modèle de données yang d'interface côté fonctions de sécurité de réseau d'i2nsf
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 (fr) * 2018-07-02 2020-01-09 성균관대학교 산학협력단 Modèle de données yang d'interface côté fonctions de sécurité de réseau d'i2nsf
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 (fr) Système de gestion de flux de commande de nœud à base de code d'exécution à distance et procédé associé
WO2015046961A1 (fr) Procédé de remise de messages de notification dans un système m2m et dispositifs à cet effet
WO2020231120A1 (fr) Procédé et dispositif de gestion d'identifiant d'équipement utilisateur dans un service informatique périphérique
WO2013085281A1 (fr) Procédé et dispositif de sécurité dans un service informatique en nuage
WO2018101565A1 (fr) Structure de gestion de sécurité dans un environnement de virtualisation de réseau
EP3925189A1 (fr) Procédé et dispositif permettant de fournir une authentification dans un système de traitement multimédia basé sur un réseau (nbmp)
WO2012091529A2 (fr) Terminal
WO2014185754A1 (fr) Procédé d'abonnement et de notification dans un système de communications m2m et appareil associé
WO2021054747A1 (fr) Appareil et procédé de relocalisation d'upf psa dans un système de communication sans fil
WO2014186986A1 (fr) Procédé, dispositif et système de retransmission de flux
WO2016013846A1 (fr) Procédé de traitement de message de demande dans un système de communications sans fil, et appareil associé
WO2016089009A1 (fr) Procédé et serveur cloud pour dispositif de gestion
WO2012044064A4 (fr) Serveur et procédé de prestation de service associé
WO2018048230A1 (fr) Procédé de gestion de short data service (sds) dans un système de communication de données critiques pour la mission (données mc)
WO2021206519A1 (fr) Appareil et procédé de transmission d'informations de gestion de pont dans un système de communication sans fil
WO2023158111A1 (fr) Système de gestion de cybersécurité pour navire de surface autonome maritime
EP3114820A1 (fr) Procédé et système pour l'établissement d'une session de service entre un dispositif chercheur et un dispositif d'annonceur publicitaire
WO2023033588A1 (fr) Système de commande de flux de données dans un terminal de virtualisation, et procédé associé
WO2021071316A1 (fr) Procédé et appareil de service informatique périphérique
WO2018097422A1 (fr) Procédé et système d'orientation de trafic déclenchée par une fonction de sécurité de réseau, et dispositif associé
WO2019098678A1 (fr) Procédé permettant de fournir un service de sécurité et dispositif associé
WO2017131285A1 (fr) Système de gestion de réseau conteneur et procédé de mise en réseau conteneur
WO2013187719A1 (fr) Procédé et système pour signaler l'activité d'usagers pendant une session de communication
WO2019088671A1 (fr) Procédé de fourniture de service de sécurité de réseau et appareil pour cela
WO2014171711A1 (fr) Procédé pour favoriser la politique de restriction des changements de prestataires de services pour l'abonné dans les communications mobiles et appareil associé

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