draft-ietf-i2nsf-applicability-00.txt   draft-ietf-i2nsf-applicability-01.txt 
Network Working Group J. Jeong Network Working Group J. Jeong
Internet-Draft S. Hyun Internet-Draft S. Hyun
Intended status: Informational Sungkyunkwan University Intended status: Informational Sungkyunkwan University
Expires: April 5, 2018 T. Ahn Expires: May 18, 2018 T. Ahn
Korea Telecom Korea Telecom
S. Hares S. Hares
Huawei Huawei
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
October 2, 2017 November 14, 2017
Applicability of Interfaces to Network Security Functions to Network- Applicability of Interfaces to Network Security Functions to Network-
Based Security Services Based Security Services
draft-ietf-i2nsf-applicability-00 draft-ietf-i2nsf-applicability-01
Abstract Abstract
This document describes the applicability of Interface to Network This document describes the applicability of Interface to Network
Security Functions (I2NSF) to network-based security services in Security Functions (I2NSF) to network-based security services in
Network Functions Virtualization (NFV) environments, such as Network Functions Virtualization (NFV) environments, such as
firewall, deep packet inspection, or attack mitigation engines. firewall, deep packet inspection, or attack mitigation engines.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on May 18, 2018.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 4
4. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Time-dependent Web Access Control Service . . . . . . . . 5
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 7
5.1. Firewall: Centralized Firewall System . . . . . . . . . . 6 4.1. Firewall: Centralized Firewall System . . . . . . . . . . 9
5.2. Deep Packet Inspection: Centralized VoIP/VoLTE 4.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security
Security System . . . . . . . . . . . . . . . . . . . . . 7 System . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Attack Mitigation: Centralized DDoS-attack Mitigation 4.3. Attack Mitigation: Centralized DDoS-attack Mitigation
System . . . . . . . . . . . . . . . . . . . . . . . . . . 9 System . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Informative References . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 Appendix A. Changes from draft-ietf-i2nsf-applicability-01 . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Interface to Network Security Functions (I2NSF) defined a framework Interface to Network Security Functions (I2NSF) defined a framework
and interfaces for interacting with Network Security Functions and interfaces for interacting with Network Security Functions
(NSFs). The I2NSF framework allows heterogeneous NSFs developed by (NSFs). The I2NSF framework allows heterogeneous NSFs developed by
different security solution vendors to be used in the NFV environment different security solution vendors to be used in the NFV environment
by utilizing the capabilities of such products and the virtualization by utilizing the capabilities of such products and the virtualization
of security functions in the NFV platform. In the I2NSF framework, of security functions in the NFV platform. In the I2NSF framework,
each NSF initially registers the profile of its own capabilities into each NSF initially registers the profile of its own capabilities into
the system in order for themselves to be available in the system. In the system in order for themselves to be available in the system. In
addition, the Security Controller registers itself to the I2NSF user addition, the Security Controller registers itself to the I2NSF user
so that the user can request security services to the Security so that the user can request security services to the Security
Controller. Controller.
This document describes the applicability of I2NSF to network-based This document describes the applicability of I2NSF framework to
security services with use cases, such as firewall network-based security services with a use case of time-dependent web
access control. This document also describes integrating I2NSF
framework with Software-Defined Networking (SDN) technology for
efficient security services and use cases, such as firewall
[opsawg-firewalls], Deep Packet Inspection (DPI), and Distributed [opsawg-firewalls], Deep Packet Inspection (DPI), and Distributed
Denial of Service (DDoS) attack mitigation. We implemented the I2NSF Denial of Service (DDoS) attack mitigation. We implemented the I2NSF
framework based on SDN for these use cases, and the implementation framework based on SDN for these use cases, and the implementation
successfully verified the effectiveness of the I2NSF framework. successfully verified the effectiveness of the I2NSF framework.
2. Requirements Language 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology
This document uses the terminology described in [RFC7149], This document uses the terminology described in [RFC7149],
[ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture], [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture],
[ITU-T.X.1252], [ITU-T.X.800], [i2nsf-framework], [ITU-T.X.1252], [ITU-T.X.800], [i2nsf-framework],
[i2nsf-terminology], [consumer-facing-inf-im], [i2nsf-terminology], [consumer-facing-inf-im],
[consumer-facing-inf-dm], [i2nsf-nsf-cap-im], [nsf-facing-inf-dm], [consumer-facing-inf-dm], [i2nsf-nsf-cap-im], [nsf-facing-inf-dm],
[registration-inf-im], [registration-inf-dm], and [registration-inf-im], [registration-inf-dm], and
[nsf-triggered-steering]. In addition, the following terms are [nsf-triggered-steering]. In addition, the following terms are
defined below: defined below:
skipping to change at page 4, line 29 skipping to change at page 4, line 5
o Centralized DDoS-attack Mitigation System: A centralized mitigator o Centralized DDoS-attack Mitigation System: A centralized mitigator
that can establish and distribute access control policy rules into that can establish and distribute access control policy rules into
network resources for efficient DDoS-attack mitigation. These network resources for efficient DDoS-attack mitigation. These
rules can be managed dynamically by a centralized server for DDoS- rules can be managed dynamically by a centralized server for DDoS-
attack mitigation. The SDN controller and switches can attack mitigation. The SDN controller and switches can
cooperatively work as a network-based firewall system through a cooperatively work as a network-based firewall system through a
standard interface between an SDN switch and a firewall function standard interface between an SDN switch and a firewall function
as a VNF running in the SDN controller. as a VNF running in the SDN controller.
4. I2NSF Framework 3. I2NSF Framework
This section describes an I2NSF framework with SDN for I2NSF
applicability and use cases, such as firewall, deep packet
inspection, and DDoS-attack mitigation functions.
Figure 1 shows an I2NSF framework [i2nsf-framework] with SDN networks This section describes an I2NSF framework and its use case. Figure 1
to support network-based security services. As shown in Figure 1, shows an I2NSF framework [i2nsf-framework] to support network-based
I2NSF User can use security functions by delivering their high-level security services. As shown in Figure 1, I2NSF User can use security
security policies to the Security Controller via the Consumer-Facing functions by delivering high-level security policies, which specify
Interface [consumer-facing-inf-im][consumer-facing-inf-dm]. security requirements the I2NSF user wants to enforce, to the
Security Controller via the Consumer-Facing Interface
[consumer-facing-inf-im][consumer-facing-inf-dm].
The Security Controller can translate the high-level security The Security Controller receives and analyzes the high-level security
policies (received from an I2NSF User via the Consumer-Facing policies from an I2NSF User, and identifies what types of security
Interface) into low-level security policies for the corresponding capabilities are required to meet these high-level security policies.
NSFs. These low-level security policies are sent to NSFs via the The Security Controller then identifies NSFs that have the required
NSF-Facing Interface [i2nsf-nsf-cap-im][nsf-facing-inf-dm]. security capabilities, and generates low-level security policies for
each of the NSFs so that the high-level security policies are
eventually enforced by those NSFs. Finally, the Security Controller
sends the generated low-level security policies to the NSFs
[i2nsf-nsf-cap-im][nsf-facing-inf-dm].
The Security Controller requests NSFs to perform low-level security The Security Controller requests NSFs to perform low-level security
services via the NSF-Facing Interface. The NSFs are enabled as services via the NSF-Facing Interface. The NSFs are enabled as
Virtual Network Functions (VNFs) on top of virtual machines through Virtual Network Functions (VNFs) on top of virtual machines through
Network Functions Virtualization (NFV) [ETSI-NFV]. The Security Network Functions Virtualization (NFV) [ETSI-NFV]. In addition, the
Controller also instructs the Switch Controller to perform their Security Controller uses the I2NSF Registration Interface
required security services on switches under the supervision of
Switch Controller (i.e., SDN Controller). In addition, the Security
Controller uses the I2NSF Registration Interface
[registration-inf-im][registration-inf-dm] to communicate with [registration-inf-im][registration-inf-dm] to communicate with
Developer's Management System (called Developer's Mgmt System) for Developer's Management System (called Developer's Mgmt System) for
registering (or deregistering) the developer's NSFs into (or from) registering (or deregistering) the developer's NSFs into (or from)
the NFV system using the I2NSF framework. the NFV system using the I2NSF framework.
The Consumer-Facing Interface between an I2NSF User and the Security The Consumer-Facing Interface between an I2NSF User and the Security
Controller can be implemented using, for example, RESTCONF [RFC8040]. Controller can be implemented using, for example, RESTCONF [RFC8040].
Data models specified by YANG [RFC6020] describe high-level security Data models specified by YANG [RFC6020] describe high-level security
policies to be specified by an I2NSF User. The data model defined in policies to be specified by an I2NSF User. The data model defined in
[consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing [consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing
skipping to change at page 5, line 28 skipping to change at page 5, line 14
+------------+ +------------+
| I2NSF User | | I2NSF User |
+------------+ +------------+
^ ^
| Consumer-Facing Interface | Consumer-Facing Interface
v v
+-------------------+ Registration +-----------------------+ +-------------------+ Registration +-----------------------+
|Security Controller|<-------------------->|Developer's Mgmt System| |Security Controller|<-------------------->|Developer's Mgmt System|
+-------------------+ Interface +-----------------------+ +-------------------+ Interface +-----------------------+
^ ^ ^
| | NSF-Facing Interface | NSF-Facing Interface
| v v
| +----------------+ +---------------+ +-----------------------+ +----------------+ +---------------+ +-----------------------+
| | NSF-1 |-| NSF-2 |...| NSF-n | | NSF-1 |-| NSF-2 |...| NSF-n |
| | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)| | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)|
| +----------------+ +---------------+ +-----------------------+ +----------------+ +---------------+ +-----------------------+
|
| NSF-Facing Interface
v SDN Network
+-------------------------------------------------------------------+
| +-----------------+ |
| |Switch Controller| |
| +-----------------+ |
| ^ |
| | SDN Southbound Interface |
| v |
| +--------+ +--------+ +--------+ |
| |Switch 1|-|Switch 2|......|Switch m| |
| +--------+ +--------+ +--------+ |
+-------------------------------------------------------------------+
Figure 1: An I2NSF Framework with SDN Networks Figure 1: I2NSF Framework
The NSF-Facing Interface between Security Controller and NSFs can be The NSF-Facing Interface between Security Controller and NSFs can be
implemented using NETCONF [RFC6241]. YANG data models describe low- implemented using NETCONF [RFC6241]. YANG data models describe low-
level security policies for the sake of NSFs, which are translated level security policies for the sake of NSFs, which are translated
from the high-level security policies by the Security Controller. from the high-level security policies by the Security Controller.
The data model defined in [nsf-facing-inf-dm] can be used for the The data model defined in [nsf-facing-inf-dm] can be used for the
I2NSF NSF-Facing Interface. I2NSF NSF-Facing Interface.
The Registration Interface between the Security Controller and the The Registration Interface between the Security Controller and the
Developer's Mgmt System can be implemented by RESTCONF [RFC8040]. Developer's Mgmt System can be implemented by RESTCONF [RFC8040].
The data model defined in [registration-inf-dm] can be used for the The data model defined in [registration-inf-dm] can be used for the
I2NSF Registration Interface. I2NSF Registration Interface.
Also, the I2NSF framework can enforce multiple chained NSFs for the Also, the I2NSF framework can enforce multiple chained NSFs for the
low-level security policies by means of service function chaining low-level security policies by means of service function chaining
(SFC) techniques for the I2NSF architecture described in (SFC) techniques for the I2NSF architecture described in
[nsf-triggered-steering]. [nsf-triggered-steering].
5. Use Cases The following describes a security service scenario using the I2NSF
framework.
This section introduces three use cases for cloud-based security 3.1. Time-dependent Web Access Control Service
services: (i) firewall system, (ii) deep packet inspection system,
and (iii) attack mitigation system. [RFC8192]
5.1. Firewall: Centralized Firewall System This service scenario assumes that an enterprise network
administrator wants to control the staff members' access to Facebook
during business hours. The following is an example high-level
security policy rule that the administrator requests: Block the staff
members' access to Facebook from 9 am to 6 pm. The administrator
sends this high-level security policy to the security controller,
then the security controller identifies required secuity
capabilities, e.g., IP address and port number inspection
capabilities and URL inspection capability. In this scenario, it is
assumed that the IP address and port number inspection capabilities
are required to check whether a received packet is an HTTP packet
from a staff member. The URL inspection capability is required to
check whether the target URL of a received packet is facebook.com or
not.
The Security Controller maintains the security capabilities of each
NSF running in the I2NSF system, which have been reported by the
Developer's Management System via the Registation interface. Based
on this information, the Security Controller identifies NSFs that can
perform the IP address and port number inspection and URL inspection.
In this scenario, it is assumed that an NSF of firewall has the IP
address and port number inspection capabilities and an NSF of web
filter has URL inspection capability.
The Security Controller generates low-level security rules for the
NSFs to perform IP address and port number inspection, URL
inspection, and time checking. Specifically, the Security Controller
may interoperate with an access control server in the enterprise
network in order to retrieve the information (e.g., IP address in
use, company ID, and role) of each employee that is currently using
the network. Based on the retrieved information, the Security
Controller generates low-level security rules to check whether the
source IP address of a received packet matches any one being used by
a staff member. In addition, the low-level security rules should be
able to determine that a received packet is of HTTP protocol. The
low-level security rules for web filter checks that the target URL
field of a received packet is equal to facebook.com. Finally, the
Security Controller sends the low-level security rules of the IP
address and port number inspection to the NSF of firewall and the
low-level rules for URL inspection to the NSF of web filter.
The following describes how the time-dependent web access control
service is enforced by the NSFs of firewall and web filter.
1. A staff member tries to access Fackbook.com during business
hours, e.g., 10 am.
2. The packet is forwarded from the staff member's device to the
firewall, and the firewall checks the source IP address and port
number. Now the firewall identifies the received packet is an
HTTP packet from the staff member.
3. The firewall triggers the web filter to further inspect the
packet, and the packet is forwarded from the firewall to the web
filter. Service Function Chaining (SFC) technology can be
utilized to support such packet forwarding in the I2NSF framework
[nsf-triggered-steering].
4. The web filter checks the target URL field of the received
packet, and realizes the packet is toward Facebook.com. The web
filter then checks that the current time is in business hours.
If so, the web filter drops the packet, and consequently the
staff member's access to Facebook during business hours is
blocked.
4. I2NSF Framework with SDN
This section describes an I2NSF framework with SDN for I2NSF
applicability and use cases, such as firewall, deep packet
inspection, and DDoS-attack mitigation functions. SDN enables some
packet filtering rules to be enforced in the network switches by
controlling their packet forwarding rules. By taking advantage of
this capability of SDN, it is possible to optimize the process of
security service enforcement in the I2NSF system.
Figure 2 shows an I2NSF framework [i2nsf-framework] with SDN networks
to support network-based security services. In this system, the
enforcement of security policy rules is divided into the SDN switches
and NSFs. Especially, SDN switches enforce simple packet filtering
rules that can be translated into their packet forwarding rules,
whereas NSFs enforce NSF-related security rules requiring the
security capabilities of the NSFs. For this purpose, the Security
Controller instructs the Switch Controller via NSF-Facing Interface
so that SDN switches can perform the required security services with
flow tables under the supervision of the Switch Controller (i.e., SDN
Controller).
+------------+
| I2NSF User |
+------------+
^
| Consumer-Facing Interface
v
+-------------------+ Registration +-----------------------+
|Security Controller|<-------------------->|Developer's Mgmt System|
+-------------------+ Interface +-----------------------+
^ ^
| | NSF-Facing Interface
| v
| +----------------+ +---------------+ +-----------------------+
| | NSF-1 |-| NSF-2 |...| NSF-n |
| | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)|
| +----------------+ +---------------+ +-----------------------+
| ^
| |
| v
| +--------+
| | SFF |
| +--------+
| ^
| |
| V SDN Network
+--|----------------------------------------------------------------+
| V NSF-Facing Interface |
| +-----------------+ |
| |Switch Controller| |
| +-----------------+ |
| ^ |
| | SDN Southbound Interface |
| v |
| +--------+ +--------+ +--------+ +--------+ |
| |Switch 1|-|Switch 2|-|Switch 3|......|Switch m| |
| +--------+ +--------+ +--------+ +--------+ |
+-------------------------------------------------------------------+
Figure 2: An I2NSF Framework with SDN Network
The following subsections introduce three use cases for cloud-based
security services: (i) firewall system, (ii) deep packet inspection
system, and (iii) attack mitigation system. [RFC8192]
4.1. Firewall: Centralized Firewall System
A centralized network firewall can manage each network resource and A centralized network firewall can manage each network resource and
firewall rules can be managed flexibly by a centralized server for firewall rules can be managed flexibly by a centralized server for
firewall (called Firewall). The centralized network firewall firewall (called Firewall). The centralized network firewall
controls each switch for the network resource management and the controls each switch for the network resource management and the
firewall rules can be added or deleted dynamically. firewall rules can be added or deleted dynamically.
The procedure of firewall operations in this system is as follows: The procedure of firewall operations in this system is as follows:
1. A switch forwards an unknown flow's packet to one of the Switch 1. A switch forwards an unknown flow's packet to one of the Switch
skipping to change at page 7, line 47 skipping to change at page 10, line 25
are permitted or denied for firewall within a specific are permitted or denied for firewall within a specific
organization network under management. Thus, a centralized view organization network under management. Thus, a centralized view
is helpful to determine security policies for such a network. is helpful to determine security policies for such a network.
o Packet-based access mechanism: Packet-based access mechanism is o Packet-based access mechanism: Packet-based access mechanism is
not enough for firewall in practice since the basic unit of access not enough for firewall in practice since the basic unit of access
control is usually users or applications. Therefore, application control is usually users or applications. Therefore, application
level rules can be defined and added to the firewall system level rules can be defined and added to the firewall system
through the centralized server. through the centralized server.
5.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System 4.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System
A centralized VoIP/VoLTE security system can monitor each VoIP/VoLTE A centralized VoIP/VoLTE security system can monitor each VoIP/VoLTE
flow and manage VoIP/VoLTE security rules controlled by a centralized flow and manage VoIP/VoLTE security rules controlled by a centralized
server for VoIP/VoLTE security service called VoIP Intrusion server for VoIP/VoLTE security service called VoIP Intrusion
Prevention System (IPS). The VoIP/VoLTE security system controls Prevention System (IPS). The VoIP/VoLTE security system controls
each switch for the VoIP/VoLTE call flow management by manipulating each switch for the VoIP/VoLTE call flow management by manipulating
the rules that can be added, deleted or modified dynamically. the rules that can be added, deleted or modified dynamically.
A centralized VoIP/VoLTE security system can cooperate with a network
firewall to realize VoIP/VoLTE security service. Specifically, a
network firewall performs basic security checks of an unknown flow's
packet observed by a switch. If the network firewall detects that
the packet is an unknown VoIP call flow's packet that exhibits some
suspicious patterns, then it triggers the VoIP/VoLTE security system
for more specialized security analysis of the suspicious VoIP call
packet.
The procedure of VoIP/VoLTE security operations in this system is as The procedure of VoIP/VoLTE security operations in this system is as
follows: follows:
1. A switch forwards an unknown call flow's signal packet (e.g., SIP 1. A switch forwards an unknown flow's packet to the Switch
packet) to the Switch Controller. Also, if the packet belongs to Controller, and the Switch Controller further forwards the
a matched flow's packet related to SIP (called matched SIP unknown flow's packet to the Firewall for basic security
packet), the Switch forwards the packet to the Switch Controller inspection.
so that the packet can be checked by an NSF for VoIP (i.e., VoIP
IPS) via the Switch Controller, which monitors the behavior of
its SIP call.
2. The Switch Controller forwards the unknown flow's packet or the 2. The Firewall analyzes the header fields of the packet, and
matched SIP packet to an appropriate security service function, figures out that this is an unknown VoIP call flow's signal
such as VoIP IPS. packet (e.g., SIP packet) of a suspicious pattern.
3. VoIP IPS analyzes the headers and contents of the signal packet, 3. The Firewall triggers an appropriate security service function,
such as IP addresses, calling number, and session description such as VoIP IPS, for detailed security analysis of the
headers [RFC4566]. suspicious signal packet. That is, the firewall sends the packet
to the Service Function Forwarder (SFF) in the I2NSF framework
[nsf-triggered-steering], as shown in Figure 2. The SFF forwards
the suspicious signal packet to the VoIP IPS.
4. If, for example, VoIP IPS regards the packet as a spoofed packet 4. The VoIP IPS analyzes the headers and contents of the signal
by hackers or a scanning packet searching for VoIP/VoLTE devices, packet, such as calling number and session description headers
it requests the Switch Controller to block that packet and the [RFC4566].
subsequent packets that have the same call-id.
5. The Switch Controller installs new rules (e.g., drop packets) 5. If, for example, the VoIP IPS regards the packet as a spoofed
packet by hackers or a scanning packet searching for VoIP/VoLTE
devices, it drops the packet. In addition, the VoIP IPS requests
the Switch Controller to block that packet and the subsequent
packets that have the same call-id.
6. The Switch Controller installs new rules (e.g., drop packets)
into underlying switches. into underlying switches.
6. The illegal packets are dropped by these switches. 7. The illegal packets are dropped by these switches.
Existing SDN protocols can be used through standard interfaces Existing SDN protocols can be used through standard interfaces
between the VoIP IPS application and switches [RFC7149][ITU-T.Y.3300] between the VoIP IPS application and switches [RFC7149][ITU-T.Y.3300]
[ONF-OpenFlow][ONF-SDN-Architecture]. [ONF-OpenFlow][ONF-SDN-Architecture].
Legacy hardware based VoIP IPS has some challenges, such as Legacy hardware based VoIP IPS has some challenges, such as
provisioning time, the granularity of security, expensive cost, and provisioning time, the granularity of security, expensive cost, and
the establishment of policy. The I2NSF framework can resolve the the establishment of policy. The I2NSF framework can resolve the
challenges through the above centralized VoIP/VoLTE security system challenges through the above centralized VoIP/VoLTE security system
based on SDN as follows: based on SDN as follows:
skipping to change at page 9, line 23 skipping to change at page 12, line 17
that we need to add VoIP IPS on each network resource. To solve that we need to add VoIP IPS on each network resource. To solve
this, each network resource can be managed centrally such that a this, each network resource can be managed centrally such that a
single VoIP IPS is manipulated by a centralized server. single VoIP IPS is manipulated by a centralized server.
o The establishment of policy: Policy should be established for each o The establishment of policy: Policy should be established for each
network resource. However, it is difficult to describe what flows network resource. However, it is difficult to describe what flows
are permitted or denied for VoIP IPS within a specific are permitted or denied for VoIP IPS within a specific
organization network under management. Thus, a centralized view organization network under management. Thus, a centralized view
is helpful to determine security policies for such a network. is helpful to determine security policies for such a network.
5.3. Attack Mitigation: Centralized DDoS-attack Mitigation System 4.3. Attack Mitigation: Centralized DDoS-attack Mitigation System
A centralized DDoS-attack mitigation can manage each network resource A centralized DDoS-attack mitigation can manage each network resource
and manipulate rules to each switch through a centralized server for and manipulate rules to each switch through a centralized server for
DDoS-attack mitigation (called DDoS-attack Mitigator). The DDoS-attack mitigation (called DDoS-attack Mitigator). The
centralized DDoS-attack mitigation system defends servers against centralized DDoS-attack mitigation system defends servers against
DDoS attacks outside private network, that is, from public network. DDoS attacks outside private network, that is, from public network.
Servers are categorized into stateless servers (e.g., DNS servers) Servers are categorized into stateless servers (e.g., DNS servers)
and stateful servers (e.g., web servers). For DDoS-attack and stateful servers (e.g., web servers). For DDoS-attack
mitigation, traffic flows in switches are dynamically configured by mitigation, traffic flows in switches are dynamically configured by
skipping to change at page 11, line 17 skipping to change at page 14, line 9
So far this document has described the procedure and impact of the So far this document has described the procedure and impact of the
three use cases for network-based security services using the I2NSF three use cases for network-based security services using the I2NSF
framework with SDN networks. To support these use cases in the framework with SDN networks. To support these use cases in the
proposed data-driven security service framework, YANG data models proposed data-driven security service framework, YANG data models
described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and
[registration-inf-dm] can be used as Consumer-Facing Interface, NSF- [registration-inf-dm] can be used as Consumer-Facing Interface, NSF-
Facing Interface, and Registration Interface, respectively, along Facing Interface, and Registration Interface, respectively, along
with RESTCONF [RFC8040] and NETCONF [RFC6241]. with RESTCONF [RFC8040] and NETCONF [RFC6241].
6. Security Considerations 5. Security Considerations
The I2NSF framework with SDN networks in this document is derived The I2NSF framework with SDN networks in this document is derived
from the I2NSF framework [i2nsf-framework], so the security from the I2NSF framework [i2nsf-framework], so the security
considerations of the I2NSF framework should be included in this considerations of the I2NSF framework should be included in this
document. Therefore, proper secure communication channels should be document. Therefore, proper secure communication channels should be
used the delivery of control or management messages among the used the delivery of control or management messages among the
components in the proposed framework. components in the proposed framework.
This document shares all the security issues of SDN that are This document shares all the security issues of SDN that are
specified in the "Security Considerations" section of [ITU-T.Y.3300]. specified in the "Security Considerations" section of [ITU-T.Y.3300].
7. Acknowledgments 6. Acknowledgments
This work was supported by Institute for Information & communications This work was supported by Institute for Information & communications
Technology Promotion (IITP) grant funded by the Korea government Technology Promotion (IITP) grant funded by the Korea government
(MSIP) (No.R-20160222-002755, Cloud based Security Intelligence (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence
Technology Development for the Customized Security Service Technology Development for the Customized Security Service
Provisioning). Provisioning).
8. Contributors 7. Contributors
I2NSF is a group effort. I2NSF has had a number of contributing I2NSF is a group effort. I2NSF has had a number of contributing
authors. The following are considered co-authors: authors. The following are considered co-authors:
o Hyoungshick Kim (Sungkyunkwan University) o Hyoungshick Kim (Sungkyunkwan University)
o Jung-Soo Park (ETRI) o Jung-Soo Park (ETRI)
o Tae-Jin Ahn (Korea Telecom)
o Se-Hui Lee (Korea Telecom) o Se-Hui Lee (Korea Telecom)
o Mohamed Boucadair (Orange) o Mohamed Boucadair (Orange)
9. References 8. Informative References
9.1. Normative References [AVANT-GUARD]
Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT-
GUARD: Scalable and Vigilant Switch Flow Management in
Software-Defined Networks", ACM CCS, November 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to [consumer-facing-inf-dm]
Indicate Requirement Levels", BCP 14, Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares,
RFC 2119, March 1997. "I2NSF Consumer-Facing Interface YANG Data Model", draft-
jeong-i2nsf-consumer-facing-interface-dm-05 (work in
progress), November 2017.
[i2nsf-framework] Lopez, D., Lopez, E., Dunbar, L., [consumer-facing-inf-im]
Strassner, J., and R. Kumar, "Framework for Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
Interface to Network Security Functions", S., and L. Xia, "Information model for Client-Facing
draft-ietf-i2nsf-framework-07 (work in Interface to Security Controller", draft-kumar-i2nsf-
progress), August 2017. client-facing-interface-im-04 (work in progress), October
2017.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling [ETSI-NFV]
Language for the Network Configuration ETSI GS NFV 002 V1.1.1, "Network Functions Virtualisation
Protocol (NETCONF)", RFC 6020, (NFV); Architectural Framework", October 2013.
October 2010.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., [i2nsf-framework]
and A. Bierman, "Network Configuration Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Protocol (NETCONF)", RFC 6241, June 2011. Kumar, "Framework for Interface to Network Security
Functions", draft-ietf-i2nsf-framework-08 (work in
progress), October 2017.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, [i2nsf-nsf-cap-im]
"RESTCONF Protocol", RFC 8040, Xia, L., Strassner, J., Basile, C., and D. Lopez,
January 2017. "Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-00 (work in progress), September 2017.
9.2. Informative References [i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-04 (work in
progress), July 2017.
[consumer-facing-inf-im] Kumar, R., Lohiya, A., Qi, D., Bitar, N., [ITU-T.X.1252]
Palislamovic, S., and L. Xia, "Information Recommendation ITU-T X.1252, "Baseline Identity Management
model for Client-Facing Interface to Terms and Definitions", April 2010.
Security Controller", draft-kumar-i2nsf-
client-facing-interface-im-03 (work in
progress), July 2017.
[consumer-facing-inf-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and [ITU-T.X.800]
S. Hares, "I2NSF Consumer-Facing Interface Recommendation ITU-T X.800, "Security Architecture for
YANG Data Model", draft-jeong-i2nsf- Open Systems Interconnection for CCITT Applications",
consumer-facing-interface-dm-04 (work in March 1991.
progress), October 2017.
[i2nsf-nsf-cap-im] Xia, L., Strassner, J., Basile, C., and D. [ITU-T.Y.3300]
Lopez, "Information Model of NSFs Recommendation ITU-T Y.3300, "Framework of Software-
Capabilities", Defined Networking", June 2014.
draft-ietf-i2nsf-capability-00 (work in
progress), September 2017.
[nsf-facing-inf-dm] Kim, J., Jeong, J., Park, J., Hares, S., [nsf-facing-inf-dm]
and L. Xia, "I2NSF Network Security Kim, J., Jeong, J., Park, J., Hares, S., and L. Xia,
Functions-Facing Interface YANG Data "I2NSF Network Security Functions-Facing Interface YANG
Model", draft-kim-i2nsf-nsf-facing- Data Model", draft-kim-i2nsf-nsf-facing-interface-data-
interface-data-model-03 (work in progress), model-04 (work in progress), October 2017.
October 2017.
[registration-inf-im] Hyun, S., Jeong, J., Woo, S., Yeo, Y., and [nsf-triggered-steering]
J. Park, "I2NSF Registration Interface Hyun, S., Jeong, J., Park, J., and S. Hares, "Service
Information Model", draft-hyun-i2nsf- Function Chaining-Enabled I2NSF Architecture", draft-hyun-
registration-interface-im-02 (work in i2nsf-nsf-triggered-steering-04 (work in progress),
progress), July 2017. October 2017.
[registration-inf-dm] Hyun, S., Jeong, J., Yeo, Y., Woo, S., and [ONF-OpenFlow]
J. Park, "I2NSF Registration Interface YANG ONF, "OpenFlow Switch Specification (Version 1.4.0)",
Data Model", October 2013.
draft-hyun-i2nsf-registration-dm-01 (work
in progress), July 2017.
[nsf-triggered-steering] Hyun, S., Jeong, J., Park, J., and S. [ONF-SDN-Architecture]
Hares, "Service Function Chaining-Enabled ONF, "SDN Architecture", June 2014.
I2NSF Architecture",
draft-hyun-i2nsf-nsf-triggered-steering-03
(work in progress), July 2017.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software- [opsawg-firewalls]
Defined Networking: A Perspective from Baker, F. and P. Hoffman, "On Firewalls in Internet
within a Service Provider Environment", Security", draft-ietf-opsawg-firewalls-01 (work in
RFC 7149, March 2014. progress), October 2012.
[ITU-T.Y.3300] Recommendation ITU-T Y.3300, "Framework of [registration-inf-dm]
Software-Defined Networking", June 2014. Hyun, S., Jeong, J., Yeo, Y., Woo, S., and J. Park, "I2NSF
Registration Interface YANG Data Model", draft-hyun-i2nsf-
registration-dm-02 (work in progress), October 2017.
[ONF-OpenFlow] ONF, "OpenFlow Switch Specification [registration-inf-im]
(Version 1.4.0)", October 2013. Hyun, S., Jeong, J., Woo, S., Yeo, Y., and J. Park, "I2NSF
Registration Interface Information Model", draft-hyun-
i2nsf-registration-interface-im-03 (work in progress),
October 2017.
[ONF-SDN-Architecture] ONF, "SDN Architecture", June 2014. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[ITU-T.X.1252] Recommendation ITU-T X.1252, "Baseline [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Identity Management Terms and Definitions", Network Configuration Protocol (NETCONF)", RFC 6020,
April 2010. October 2010.
[ITU-T.X.800] Recommendation ITU-T X.800, "Security [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Architecture for Open Systems Bierman, "Network Configuration Protocol (NETCONF)",
Interconnection for CCITT Applications", RFC 6241, June 2011.
March 1991.
[AVANT-GUARD] Shin, S., Yegneswaran, V., Porras, P., and [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
G. Gu, "AVANT-GUARD: Scalable and Vigilant Networking: A Perspective from within a Service Provider
Switch Flow Management in Software-Defined Environment", RFC 7149, March 2014.
Networks", ACM CCS, November 2013.
[ETSI-NFV] ETSI GS NFV 002 V1.1.1, "Network Functions [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Virtualisation (NFV); Architectural Protocol", RFC 8040, January 2017.
Framework", October 2013.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
"SDP: Session Description Protocol", and J. Jeong, "Interface to Network Security Functions
RFC 4566, July 2006. (I2NSF): Problem Statement and Use Cases", RFC 8192, July
2017.
[i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, Appendix A. Changes from draft-ietf-i2nsf-applicability-01
L., and H. Birkholz, "Interface to Network
Security Functions (I2NSF) Terminology",
draft-ietf-i2nsf-terminology-04 (work in
progress), July 2017.
[opsawg-firewalls] Baker, F. and P. Hoffman, "On Firewalls in The following changes have been made from draft-ietf-i2nsf-
Internet Security", applicability-01:
draft-ietf-opsawg-firewalls-01 (work in
progress), October 2012.
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, o In Section 3, a time-based web access control service is added as
C., Kumar, R., and J. Jeong, "Interface to a general use case in the I2NSF framework.
Network Security Functions (I2NSF): Problem
Statement and Use Cases", RFC 8192, o In Section 4, the movitation of the I2NSF framework with SDN is
July 2017. explained, that is, supporting the divided security policy
enforcement for efficient security service.
o In Section 4.2, the centralized VoIP/VoLTE security system is
clarified as a use case to explain the security service chaining
using SFC technology.
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong
Department of Software Department of Software
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
skipping to change at page 15, line 37 skipping to change at page 19, line 25
7453 Hickory Hill 7453 Hickory Hill
Saline, MI 48176 Saline, MI 48176
USA USA
Phone: +1-734-604-0332 Phone: +1-734-604-0332
EMail: shares@ndzh.com EMail: shares@ndzh.com
Diego R. Lopez Diego R. Lopez
Telefonica I+D Telefonica I+D
Jose Manuel Lara, 9 Jose Manuel Lara, 9
Seville, 41013 Seville 41013
Spain Spain
Phone: +34 682 051 091 Phone: +34 682 051 091
EMail: diego.r.lopez@telefonica.com EMail: diego.r.lopez@telefonica.com
 End of changes. 61 change blocks. 
212 lines changed or deleted 334 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/