draft-ietf-i2nsf-applicability-09.txt   draft-ietf-i2nsf-applicability-10.txt 
I2NSF Working Group J. Jeong I2NSF Working Group J. Jeong
Internet-Draft Sungkyunkwan University Internet-Draft Sungkyunkwan University
Intended status: Informational S. Hyun Intended status: Informational S. Hyun
Expires: September 12, 2019 Chosun University Expires: November 3, 2019 Chosun University
T. Ahn T. Ahn
Korea Telecom Korea Telecom
S. Hares S. Hares
Huawei Huawei
D. Lopez D. Lopez
Telefonica I+D Telefonica I+D
March 11, 2019 May 2, 2019
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-09 draft-ietf-i2nsf-applicability-10
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on November 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 5 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 5
4. Time-dependent Web Access Control Service . . . . . . . . . . 6 4. Time-dependent Web Access Control Service . . . . . . . . . . 7
5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 8 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 10
6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 10 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 12
6.1. Firewall: Centralized Firewall System . . . . . . . . . . 13 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 15
6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security
System . . . . . . . . . . . . . . . . . . . . . . . . . 14 System . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Attack Mitigation: Centralized DDoS-attack Mitigation 6.3. Attack Mitigation: Centralized DDoS-attack Mitigation
System . . . . . . . . . . . . . . . . . . . . . . . . . 16 System . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 19 7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from draft-ietf-i2nsf-applicability-08 . . . 25 Appendix A. Changes from draft-ietf-i2nsf-applicability-09 . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Interface to Network Security Functions (I2NSF) defines a framework Interface to Network Security Functions (I2NSF) defines a framework
and interfaces for interacting with Network Security Functions and interfaces for interacting with Network Security Functions
(NSFs). Note that Network Security Function (NSF) is defined as a (NSFs). Note that Network Security Function (NSF) is defined as
funcional block for a security service within an I2NSF framework that software that provides a set of security-related services, such as
has well-defined I2NSF NSF-facing interface and other external (i) detecting unwanted activity, (ii) blocking or mitigating the
interfaces and well-defined functional behavior [NFV-Terminology]. effect of such unwanted activity in order to fulfil service
requirements, and (iii) supporting communication stream integrity and
confidentiality [i2nsf-terminology].
The I2NSF framework allows heterogeneous NSFs developed by different The I2NSF framework allows heterogeneous NSFs developed by different
security solution vendors to be used in the Network Functions security solution vendors to be used in the Network Functions
Virtualization (NFV) environment [ETSI-NFV] by utilizing the Virtualization (NFV) environment [ETSI-NFV] by utilizing the
capabilities of such products and the virtualization of security capabilities of such NSFs through I2NSF interfaces such as Customer-
functions in the NFV platform. In the I2NSF framework, each NSF Facing Interface [consumer-facing-inf-dm] and NSF-Facing Interface
initially registers the profile of its own capabilities into the [nsf-facing-inf-dm]. In the I2NSF framework, each NSF initially
system in order for themselves to be available in the system. In registers the profile of its own capabilities into the Security
addition, the Security Controller is validated by the I2NSF User Controller (i.e., network operator management system [RFC8329]) in
(also called I2NSF Client) that a system administrator (as a user) is the I2NSF system via Registration Interface [registration-inf-dm] so
employing, so that the system administrator can request security that each NSF can be selected and used to enforce a given security
services through the Security Controller. policy from I2NSF User (i.e., network security administrator). Note
that Developer's Management System (DMS) is management software that
provides a vendor's security service software as a Virtual Network
Function (VNF) in an NFV environment (or middlebox in the legacy
network) as an NSF, and registers the capabilities of an NSF into
Security Controller via Registration Interface for a security service
[RFC8329].
Security Controller is defined as a management component that
contains control plane functions to manage NSFs and facilitate
information sharing among other components (e.g., NSFs and I2NSF
User) in an I2NSF system [i2nsf-terminology]. Security Controller
maintains the mapping between a capability and an NSF, so it can
perform to translate a high-level security policy received from I2NSF
User to a low-level security policy configured and enforced in an NSF
[policy-translation]. Security Controller can monitor the states and
security attacks in NSFs through NSF monitoring [nsf-monitoring-dm].
This document illustrates the applicability of the I2NSF framework This document illustrates the applicability of the I2NSF framework
with four different scenarios: with four different scenarios:
1. The enforcement of time-dependent web access control. 1. The enforcement of time-dependent web access control.
2. The application of I2NSF to a Service Function Chaining (SFC) 2. The application of I2NSF to a Service Function Chaining (SFC)
environment [RFC7665]. environment [RFC7665].
3. The integration of the I2NSF framework with Software-Defined 3. The integration of the I2NSF framework with Software-Defined
skipping to change at page 3, line 32 skipping to change at page 3, line 50
4. The use of Network Functions Virtualization (NFV) [ETSI-NFV] as a 4. The use of Network Functions Virtualization (NFV) [ETSI-NFV] as a
supporting technology. supporting technology.
The implementation of I2NSF in these scenarios has allowed us to The implementation of I2NSF in these scenarios has allowed us to
verify the applicability and effectiveness of the I2NSF framework for verify the applicability and effectiveness of the I2NSF framework for
a variety of use cases. a variety of use cases.
2. Terminology 2. Terminology
This document uses the terminology described in [RFC7665], [RFC7149], This document uses the terminology described in [RFC7665], [RFC7149],
[ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture], [ITU-T.Y.3300], [ONF-SDN-Architecture], [ITU-T.X.800],
[ITU-T.X.1252], [ITU-T.X.800], [NFV-Terminology], [RFC8329],
[i2nsf-terminology], [consumer-facing-inf-dm], [i2nsf-nsf-cap-im], [NFV-Terminology], [RFC8329], and [i2nsf-terminology]. In addition,
[nsf-facing-inf-dm], [registration-inf-dm], and the following terms are defined below:
[nsf-triggered-steering]. In addition, the following terms are
defined below:
o Software-Defined Networking (SDN): A set of techniques that o Software-Defined Networking (SDN): A set of techniques that
enables to directly program, orchestrate, control, and manage enables to directly program, orchestrate, control, and manage
network resources, which facilitates the design, delivery and network resources, which facilitates the design, delivery and
operation of network services in a dynamic and scalable manner operation of network services in a dynamic and scalable manner
[ITU-T.Y.3300]. [ITU-T.Y.3300].
o Network Function: A funcional block within a network o Network Function: A funcional block within a network
infrastructure that has well-defined external interfaces and well- infrastructure that has well-defined external interfaces and well-
defined functional behavior [NFV-Terminology]. defined functional behavior [NFV-Terminology].
o Network Security Function (NSF): A funcional block within a o Network Security Function (NSF): Software that provides a set of
security service within a network infrastructure that has well- security-related services. Examples include detecting unwanted
defined external interfaces and well-defined functional activity and blocking or mitigating the effect of such unwanted
behavior[NFV-Terminology]. activity in order to fulfil service requirements. The NSF can
also help in supporting communication stream integrity and
confidentiality [i2nsf-terminology].
o Network Functions Virtualization (NFV): A principle of separating o Network Functions Virtualization (NFV): A principle of separating
network functions (or network security functions) from the network functions (or network security functions) from the
hardware they run on by using virtual hardware abstraction hardware they run on by using virtual hardware abstraction
[NFV-Terminology]. [NFV-Terminology].
o Service Function Chaining (SFC): The execution of an ordered set o Service Function Chaining (SFC): The execution of an ordered set
of abstract service functions (i.e., network functions) according of abstract service functions (i.e., network functions) according
to ordering constraints that must be applied to packets, frames, to ordering constraints that must be applied to packets, frames,
and flows selected as a result of classification. The implied and flows selected as a result of classification. The implied
skipping to change at page 5, line 41 skipping to change at page 5, line 45
[consumer-facing-inf-dm]. [consumer-facing-inf-dm].
The Security Controller receives and analyzes the high-level security The Security Controller receives and analyzes the high-level security
policies from an I2NSF User, and identifies what types of security policies from an I2NSF User, and identifies what types of security
capabilities are required to meet these high-level security policies. capabilities are required to meet these high-level security policies.
The Security Controller then identifies NSFs that have the required The Security Controller then identifies NSFs that have the required
security capabilities, and generates low-level security policies for security capabilities, and generates low-level security policies for
each of the NSFs so that the high-level security policies are each of the NSFs so that the high-level security policies are
eventually enforced by those NSFs [policy-translation]. Finally, the eventually enforced by those NSFs [policy-translation]. Finally, the
Security Controller sends the generated low-level security policies Security Controller sends the generated low-level security policies
to the NSFs [i2nsf-nsf-cap-im][nsf-facing-inf-dm]. to the NSFs via the NSF-Facing Interface [nsf-facing-inf-dm].
The Security Controller requests NSFs to perform low-level security As shown in Figure 1, with a Developer's Management System (called
services via the NSF-Facing Interface. As shown in Figure 1, with a DMS), developers (or vendors) inform the Security Controller of the
Developer's Management System (DMS), developers (or vendors) inform capabilities of the NSFs through the Registration Interface
the Security Controller of the capabilities of the NSFs through the [registration-inf-dm] for registering (or deregistering) the
I2NSF Registration Interface [registration-inf-dm] for registering corresponding NSFs. Note that an inside attacker at the DMS can
(or deregistering) the corresponding NSFs. Note that an inside seriously weaken the I2NSF system's security. That is, DMS can be
attacker at the DMS can seriously weaken the I2NSF system's security. compromised to attack the Security Controller by providing the
To deal with this type of threat, the role of the DMS should be Security Controller with malicious NSFs, and controlling those NSFs
restricted to providing an I2NSF system with the software package/ in real time. To deal with this type of threat, the role of the DMS
image for NSF execution, and the DMS should never be able to access should be restricted to providing an I2NSF system with the software
NSFs in online/activated status for the I2NSF system's security. On package/image for NSF execution, and the DMS should never be able to
the other hand, an access to running (online) NSFs should be allowed access NSFs in online/activated status for the I2NSF system's
only to the Security Controller, not the DMS. Also, the Security security. On the other hand, an access to active NSFs should be
Controller can detect and prevent inside attacks by monitoring the allowed only to the Security Controller, not the DMS during the
activity of all the DMSs as well as the NSFs through the I2NSF NSF provisioning time of those NSFs to the I2NSF system. However, note
monitoring functionality [nsf-monitoring-dm]. that an inside attacker can access the active NSFs, which are being
executed as either VNFs or middleboxes in the I2NSF system, through a
back door (i.e., an IP address and a port number that are known to
the DMS to control an NSF). However, the Security Controller can
detect and prevent inside attacks by monitoring the activities of all
the DMSs as well as the NSFs through the I2NSF NSF monitoring
functionality [nsf-monitoring-dm]. Through the NSF monitoring, the
Security Controller can monitor the activities and states of NSFs,
and then can make a diagnosis to see whether the NSFs are working in
normal conditions or in abnormal conditions including the insider
threat. Note that the monitoring of the DMSs is out of scope for
I2NSF.
The Consumer-Facing Interface between an I2NSF User and the Security The Consumer-Facing Interface can be implemented as an XML file based
Controller can be implemented using, for example, RESTCONF [RFC8040]. on the Consumer-Facing Interface data model [consumer-facing-inf-dm]
Data models specified by YANG [RFC6020] describe high-level security along with RESTCONF [RFC8040], which befits a web-based user
policies to be specified by an I2NSF User. The data model defined in interface for an I2NSF User to send a Security Controller a high-
[consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing level security policy. Data models specified by YANG [RFC6020]
Interface. describe high-level security 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 Interface. Note that an inside
attacker at the I2NSF User can misuse the I2NSF system so that the
network system under the I2NSF system is vulnerable to security
attacks. To handle this type of threat, the Security Controller
needs to monitor the activities of all the I2NSF Users as well as the
NSFs through the I2NSF NSF monitoring functionality
[nsf-monitoring-dm]. Note that the monitoring of the I2NSF Users is
out of scope for I2NSF.
The NSF-Facing Interface between the Security Controller and NSFs can The NSF-Facing Interface can be implemented as an XML file based on
be implemented using NETCONF [RFC6241]. YANG data models describe the NSF-Facing Interface YANG data model [nsf-facing-inf-dm] along
low-level security policies for the sake of NSFs, which are with NETCONF [RFC6241], which befits a command-line-based remote-
procedure call for a Security Controller to configure an NSF with a
low-level security policy. Data models specified by YANG [RFC6020]
describe low-level security policies for the sake of NSFs, which are
translated from the high-level security policies by the Security translated from the high-level security policies by the Security
Controller. The data model defined in [nsf-facing-inf-dm] can be Controller. The data model defined in [nsf-facing-inf-dm] can be
used for the I2NSF NSF-Facing Interface. used for the I2NSF NSF-Facing Interface.
The Registration Interface between the Security Controller and the The Registration Interface can be implemented as an XML file based on
Developer's Management System can be implemented by RESTCONF the Registration Interface YANG data model [registration-inf-dm]
[RFC8040]. The data model defined in [registration-inf-dm] can be along with NETCONF [RFC6241], which befits a command-line-based
used for the I2NSF Registration Interface. remote-procedure call for a DMS to send a Security Controller an
NSF's capability information. Data models specified by YANG
[RFC6020] describe the registration of an NSF's capabilities to
enforce security services at the NSF. The data model defined in
[registration-inf-dm] can be used for the 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 SFC techniques for the I2NSF low-level security policies by means of SFC techniques for the I2NSF
architecture described in [nsf-triggered-steering]. architecture [RFC7665].
The following sections describe different security service scenarios The following sections describe different security service scenarios
illustrating the applicability of the I2NSF framework. illustrating the applicability of the I2NSF framework.
4. Time-dependent Web Access Control Service 4. Time-dependent Web Access Control Service
This service scenario assumes that an enterprise network This service scenario assumes that an enterprise network
administrator wants to control the staff members' access to a administrator wants to control the staff members' access to a
particular Internet service (e.g., Example.com) during business particular Internet service (e.g., Example.com) during business
hours. The following is an example high-level security policy rule hours. The following is an example high-level security policy rule
for a web filter that the administrator requests: Block the staff for a web filter that the administrator requests: Block the staff
members' access to Example.com from 9 AM to 6 PM. Figure 2 is an members' access to Example.com from 9 AM (i.e., 09:00) to 6 PM (i.e.,
example XML code for this web filter: 18:00) by dropping their packets. Figure 2 is an example XML code
for this web filter that is sent from the I2NSF User to the Security
Controller via the Consumer-Facing Interface
[consumer-facing-inf-dm]:
<I2NSF> <?xml version="1.0" encoding="UTF-8" ?>
<name>block_website</name> <ietf-i2nsf-cfi-policy:policy>
<cond> <policy-name>block_website</policy-name>
<src>Staff_Member's_PC</src> <rule>
<dest>Example.com</dest> <rule-name>block_website_during_working_hours</rule-name>
<time-span-start>9:00AM</time-span-start> <event>
<time-span-end>-6:00PM</time-span-end> <time-information>
</cond> <begin-time>09:00</begin-time>
<action>block<action> <end-time>18:00</end-time>
</I2NSF> </time-information>
</event>
<condition>
<firewall-condition>
<source-target>
<src-target>Staff_Member's_PC</src-target>
</source-target>
</firewall-condition>
<custom-condition>
<destination-target>
<dest-target>Example.com</dest-target>
</destination-target>
</custom-condition>
</condition>
<action>
<primary-action>drop</primary-action>
</action>
</rule>
</ietf-i2nsf-cfi-policy:policy>
Figure 2: An XML Example for Time-based Web-filter Figure 2: An XML Example for Time-based Web-filter
The security policy name is "block_website" with the tag "name". The The security policy name is "block_website" with the tag "policy-
filtering condition has the source group "Staff_Member's_PC" with the name", and the security policy rule name is
tag "src", the destination website "Example.com" with the tag "dest", "block_website_during_working_hours" with the tag "rule-name". The
the filtering start time is the time "9:00AM" with the tag " time- filtering event has the time span where the filtering begin time is
span-start", and the filtering end time is the time "6:00PM" with the the time "09:00" (i.e., 9:00AM) with the tag "begin-time", and the
tag "time-span-end". The action is to "block" the packets satisfying filtering end time is the time "18:00" (i.e., 6:00PM) with the tag
the above condition, that is, to drop those packets. "end-time". The filtering condition has the source target of
"Staff_Member's_PC" with the tag "src-target", the destination target
of a website "Example.com" with the tag "dest-target". The action is
to "drop" the packets satisfying the above event and condition with
the tag "primary-action".
After receiving the high-level security policy, the Security After receiving the high-level security policy, the Security
Controller identifies required security capabilities, e.g., IP Controller identifies required security capabilities, e.g., IP
address and port number inspection capabilities and URL inspection address and port number inspection capabilities and URL inspection
capability. In this scenario, it is assumed that the IP address and capability. In this scenario, it is assumed that the IP address and
port number inspection capabilities are required to check whether a port number inspection capabilities are required to check whether a
received packet is an HTTP packet from a staff member. The URL received packet is an HTTP packet from a staff member. The URL
inspection capability is required to check whether the target URL of inspection capability is required to check whether the target URL of
a received packet is in the Example.com domain or not. a received packet is in the Example.com domain or not.
The Security Controller maintains the security capabilities of each The Security Controller maintains the security capabilities of each
NSF running in the I2NSF system, which have been reported by the NSF running in the I2NSF system, which have been reported by the
Developer's Management System via the Registration interface. Based Developer's Management System via the Registration interface. Based
on this information, the Security Controller identifies NSFs that can on this information, the Security Controller identifies NSFs that can
perform the IP address and port number inspection and URL inspection perform the IP address and port number inspection and URL inspection
[policy-translation]. In this scenario, it is assumed that an NSF of [policy-translation]. In this scenario, it is assumed that a
firewall has the IP address and port number inspection capabilities firewall NSF has the IP address and port number inspection
and an NSF of web filter has URL inspection capability. capabilities and a web filter NSF has URL inspection capability.
The Security Controller generates low-level security rules for the The Security Controller generates low-level security rules for the
NSFs to perform IP address and port number inspection, URL NSFs to perform IP address and port number inspection, URL
inspection, and time checking. Specifically, the Security Controller inspection, and time checking. Specifically, the Security Controller
may interoperate with an access control server in the enterprise may interoperate with an access control server in the enterprise
network in order to retrieve the information (e.g., IP address in network in order to retrieve the information (e.g., IP address in
use, company identifier (ID), and role) of each employee that is use, company identifier (ID), and role) of each employee that is
currently using the network. Based on the retrieved information, the currently using the network. Based on the retrieved information, the
Security Controller generates low-level security rules to check Security Controller generates low-level security rules to check
whether the source IP address of a received packet matches any one whether the source IP address of a received packet matches any one
being used by a staff member. In addition, the low-level security 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 rules should be able to determine that a received packet is of HTTP
protocol. The low-level security rules for web filter check that the protocol. The low-level security rules for web filter check that the
target URL field of a received packet is equal to Example.com. target URL field of a received packet is equal to Example.com.
Finally, the Security Controller sends the low-level security rules Finally, the Security Controller sends the low-level security rules
of the IP address and port number inspection to the NSF of firewall of the IP address and port number inspection to the firewall NSF and
and the low-level rules for URL inspection to the NSF of web filter. the low-level rules for URL inspection to the web filter NSF.
The following describes how the time-dependent web access control The following describes how the time-dependent web access control
service is enforced by the NSFs of firewall and web filter. service is enforced by the NSFs of firewall and web filter.
1. A staff member tries to access Example.com during business hours, 1. A staff member tries to access Example.com during business hours,
e.g., 10 AM. e.g., 10 AM.
2. The packet is forwarded from the staff member's device to the 2. The packet is forwarded from the staff member's device to the
firewall, and the firewall checks the source IP address and port firewall, and the firewall checks the source IP address and port
number. Now the firewall identifies the received packet is an number. Now the firewall identifies the received packet is an
HTTP packet from the staff member. HTTP packet from the staff member.
3. The firewall triggers the web filter to further inspect the 3. The firewall triggers the web filter to further inspect the
packet, and the packet is forwarded from the firewall to the web packet, and the packet is forwarded from the firewall to the web
filter. SFC technology can be utilized to support such packet filter. SFC technology can be utilized to support such packet
forwarding in the I2NSF framework [nsf-triggered-steering]. forwarding in the I2NSF framework [RFC7665].
4. The web filter checks the target URL field of the received 4. The web filter checks the target URL field of the received
packet, and realizes the packet is toward Example.com. The web packet, and realizes the packet is toward Example.com. The web
filter then checks that the current time is in business hours. filter then checks that the current time is in business hours.
If so, the web filter drops the packet, and consequently the If so, the web filter drops the packet, and consequently the
staff member's access to Example.com during business hours is staff member's access to Example.com during business hours is
blocked. blocked.
5. I2NSF Framework with SFC
In the I2NSF architecture, an NSF can trigger an advanced security
action (e.g., DPI or DDoS attack mitigation) on a packet based on the
result of its own security inspection of the packet. For example, a
firewall triggers further inspection of a suspicious packet with DPI.
For this advanced security action to be fulfilled, the suspicious
packet should be forwarded from the current NSF to the successor NSF.
SFC [RFC7665] is a technology that enables this advanced security
action by steering a packet with multiple service functions (e.g.,
NSFs), and this technology can be utilized by the I2NSF architecture
to support the advanced security action.
+------------+ +------------+
| 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 +-----------------------+
^ ^ ^ ^
skipping to change at page 9, line 37 skipping to change at page 10, line 41
| . | .
| . | .
| . | .
| +-----------------------+ | +-----------------------+
------>| NSF-n | ------>| NSF-n |
|(DDoS-Attack Mitigator)| |(DDoS-Attack Mitigator)|
+-----------------------+ +-----------------------+
Figure 3: An I2NSF Framework with SFC Figure 3: An I2NSF Framework with SFC
5. I2NSF Framework with SFC
In the I2NSF architecture, an NSF can trigger an advanced security
action (e.g., DPI or DDoS attack mitigation) on a packet based on the
result of its own security inspection of the packet. For example, a
firewall triggers further inspection of a suspicious packet with DPI.
For this advanced security action to be fulfilled, the suspicious
packet should be forwarded from the current NSF to the successor NSF.
SFC [RFC7665] is a technology that enables this advanced security
action by steering a packet with multiple service functions (e.g.,
NSFs), and this technology can be utilized by the I2NSF architecture
to support the advanced security action.
Figure 3 shows an I2NSF framework with the support of SFC. As shown Figure 3 shows an I2NSF framework with the support of SFC. As shown
in the figure, SFC generally requires classifiers and service in the figure, SFC generally requires classifiers and service
function forwarders (SFFs); classifiers are responsible for function forwarders (SFFs); classifiers are responsible for
determining which service function path (SFP) (i.e., an ordered determining which service function path (SFP) (i.e., an ordered
sequence of service functions) a given packet should pass through, sequence of service functions) a given packet should pass through,
according to pre-configured classification rules, and SFFs perform according to pre-configured classification rules, and SFFs perform
forwarding the given packet to the next service function (e.g., NSF) forwarding the given packet to the next service function (e.g., NSF)
on the SFP of the packet by referring to their forwarding tables. In on the SFP of the packet by referring to their forwarding tables. In
the I2NSF architecture with SFC, the Security Controller can take the I2NSF architecture with SFC, the Security Controller can take
responsibilities of generating classification rules for classifiers responsibilities of generating classification rules for classifiers
skipping to change at page 10, line 11 skipping to change at page 11, line 30
classification rules of the SFPs, and then configures classifiers classification rules of the SFPs, and then configures classifiers
with the classification rules over NSF-Facing Interface so that with the classification rules over NSF-Facing Interface so that
relevant traffic packets can follow the SFPs. Also, based on the relevant traffic packets can follow the SFPs. Also, based on the
global view of NSF instances available in the system, the Security global view of NSF instances available in the system, the Security
Controller constructs forwarding tables, which are required for SFFs Controller constructs forwarding tables, which are required for SFFs
to forward a given packet to the next NSF over the SFP, and to forward a given packet to the next NSF over the SFP, and
configures SFFs with those forwarding tables over NSF-Facing configures SFFs with those forwarding tables over NSF-Facing
Interface. Interface.
To trigger an advanced security action in the I2NSF architecture, the To trigger an advanced security action in the I2NSF architecture, the
current NSF appends a metadata describing the security capability current NSF appends metadata describing the security capability
required for the advanced action to the suspicious packet and sends required for the advanced action to the suspicious packet to the
network service header (NSH) of the packet [RFC8300]. It then sends
the packet to the classifier. Based on the metadata information, the the packet to the classifier. Based on the metadata information, the
classifier searches an SFP which includes an NSF with the required classifier searches an SFP which includes an NSF with the required
security capability, changes the SFP-related information (e.g., security capability, changes the SFP-related information (e.g.,
service path identifier and service index [RFC8300]) of the packet service path identifier and service index [RFC8300]) of the packet
with the new SFP that has been found, and then forwards the packet to with the new SFP that has been found, and then forwards the packet to
the SFF. When receiving the packet, the SFF checks the SFP-related the SFF. When receiving the packet, the SFF checks the SFP-related
information such as the service path identifier and service index information such as the service path identifier and service index
contained in the packet and forwards the packet to the next NSF on contained in the packet and forwards the packet to the next NSF on
the SFP of the packet, according to its forwarding table. the SFP of the packet, according to its forwarding table.
6. 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 network forwarding elements
(e.g., switch) 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 4 shows an I2NSF framework [RFC8329] with SDN networks to
support network-based security services. In this system, the
enforcement of security policy rules is divided into the SDN
forwarding elements (e.g., switch running as either a hardware middle
box or a software virtual switch) and NSFs (e.g., firewall running in
a form of a virtual network function [ETSI-NFV]). Especially, SDN
forwarding elements 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 SDN
Controller via NSF-Facing Interface so that SDN forwarding elements
can perform the required security services with flow tables under the
supervision of the SDN Controller.
+------------+ +------------+
| 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 +-----------------------+
^ ^ ^ ^
skipping to change at page 11, line 40 skipping to change at page 12, line 40
| | SDN Southbound Interface | | | SDN Southbound Interface |
| v | | v |
| +--------+ +------------+ +--------+ +--------+ | | +--------+ +------------+ +--------+ +--------+ |
| |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| | | |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| |
| | | |(Classifier)| | (SFF) | | | | | | | |(Classifier)| | (SFF) | | | |
| +--------+ +------------+ +--------+ +--------+ | | +--------+ +------------+ +--------+ +--------+ |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 4: An I2NSF Framework with SDN Network Figure 4: An I2NSF Framework with SDN Network
6. 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 network forwarding elements
(e.g., switch) 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. For example, for efficient firewall services, simple packet
filtering can be performed by SDN forwarding elements (e.g.,
switches), and complicated packet filtering based on packet payloads
can be performed by a firewall NSF. This optimized firewall using
both SDN forwarding elements and a firewall NSF is more efficient
than a firewall where SDN forwarding elements forward all the packets
to a firewall NSF for packet filtering. This is because packets to
be filtered out can be early dropped by SDN forwarding elements
without consuming further network bandwidth due to the forwarding of
the packets to the firewall NSF.
Figure 4 shows an I2NSF framework [RFC8329] with SDN networks to
support network-based security services. In this system, the
enforcement of security policy rules is divided into the SDN
forwarding elements (e.g., switch running as either a hardware middle
box or a software virtual switch) and NSFs (e.g., firewall running in
a form of a virtual network function (VNF) [ETSI-NFV]). Note that
NSFs are created or removed by the NFV Management and Orchestration
(MANO) [ETSI-NFV-MANO], performing the life-cycle management of NSFs
as VNFs. Refer to Section 7 for the detailed discussion of the NSF
life-cycle management in the NFV MANO for I2NSF. SDN forwarding
elements enforce simple packet filtering rules that can be translated
into their packet forwarding rules, whereas NSFs enforce complicated
NSF-related security rules requiring the security capabilities of the
NSFs. Note that SDN packet forwarding rules are for packet
forwarding or filtering by flow table entries at SDN forwarding
elements, and NSF rules are for security enforcement at NSFs (e.g.,
firewall). Thus, simple firewall rules can be enforced by SDN packet
forwarding rules at SDN forwarding elements (e.g., switches). For
the tasks for security enforcement (e.g., packet filtering), the
Security Controller instructs the SDN Controller via NSF-Facing
Interface so that SDN forwarding elements can perform the required
security services with flow tables under the supervision of the SDN
Controller.
As an example, let us consider two different types of security rules: As an example, let us consider two different types of security rules:
Rule A is a simple packet filtering rule that checks only the IP Rule A is a simple packet filtering rule that checks only the IP
address and port number of a given packet, whereas rule B is a time- address and port number of a given packet, whereas rule B is a time-
consuming packet inspection rule for analyzing whether an attached consuming packet inspection rule for analyzing whether an attached
file being transmitted over a flow of packets contains malware. Rule file being transmitted over a flow of packets contains malware. Rule
A can be translated into packet forwarding rules of SDN forwarding A can be translated into packet forwarding rules of SDN forwarding
elements and thus be enforced by these elements. In contrast, rule B elements and thus be enforced by these elements. In contrast, rule B
cannot be enforced by forwarding elements, but it has to be enforced cannot be enforced by forwarding elements, but it has to be enforced
by NSFs with anti-malware capability. Specifically, a flow of by NSFs with anti-malware capability. Specifically, a flow of
packets is forwarded to and reassembled by an NSF to reconstruct the packets is forwarded to and reassembled by an NSF to reconstruct the
skipping to change at page 12, line 19 skipping to change at page 14, line 15
rules requires security capabilities that can be provided by SDN rules requires security capabilities that can be provided by SDN
forwarding elements, then the Security Controller instructs the SDN forwarding elements, then the Security Controller instructs the SDN
Controller via NSF-Facing Interface so that SDN forwarding elements Controller via NSF-Facing Interface so that SDN forwarding elements
can enforce those security policy rules with flow tables under the can enforce those security policy rules with flow tables under the
supervision of the SDN Controller. Or if some rules require security supervision of the SDN Controller. Or if some rules require security
capabilities that cannot be provided by SDN forwarding elements but capabilities that cannot be provided by SDN forwarding elements but
by NSFs, then the Security Controller instructs relevant NSFs to by NSFs, then the Security Controller instructs relevant NSFs to
enforce those rules. enforce those rules.
The distinction between software-based SDN forwarding elements and The distinction between software-based SDN forwarding elements and
NSFs, which can both run as virtual network functions, may be NSFs, which can both run as virtual network functions (VNFs), may be
necessary for some management purposes in this system. For this, we necessary for some management purposes in this system. Note that an
can take advantage of the NFV MANO where there is a subsystem that SDN forwarding element (i.e., switch) is a specific type of VNF
maintains the descriptions of the capabilities each VNF can offer rather than an NSF because an NSF is for security services rather
than for packet forwarding. For this distinction, we can take
advantage of the NFV MANO where there is a subsystem that maintains
the descriptions of the capabilities each VNF can offer
[ETSI-NFV-MANO]. This subsystem can determine whether a given [ETSI-NFV-MANO]. This subsystem can determine whether a given
software element (VNF instance) is an NSF or a virtualized SDN software element (VNF instance) is an NSF or a virtualized SDN
switch. For example, if a VNF instance has anti-malware capability switch. For example, if a VNF instance has anti-malware capability
according to the description of the VNF, it could be considered as an according to the description of the VNF, it could be considered as an
NSF. A VNF onboarding system [VNF-ONBOARDING] can be used as such a NSF. A VNF onboarding system [VNF-ONBOARDING] can be used as such a
subsystem that maintains the descriptions of each VNF to tell whether subsystem that maintains the descriptions of each VNF to tell whether
a VNF instance is for an NSF or for a virtualized SDN switch. a VNF instance is for an NSF or for a virtualized SDN switch.
For the support of SFC in the I2NSF framework with SDN, as shown in For the support of SFC in the I2NSF framework with SDN, as shown in
Figure 4, network forwarding elements (e.g., switch) can play the Figure 4, network forwarding elements (e.g., switch) can play the
skipping to change at page 12, line 45 skipping to change at page 14, line 44
Security Controller. This interface is used to update security Security Controller. This interface is used to update security
service function chaining information for traffic flows. For service function chaining information for traffic flows. For
example, when it needs to update an SFP for a traffic flow in an SDN example, when it needs to update an SFP for a traffic flow in an SDN
network, as shown in Figure 4, SFF (denoted as Switch-3) asks network, as shown in Figure 4, SFF (denoted as Switch-3) asks
Security Controller to update the SFP for the traffic flow (needing Security Controller to update the SFP for the traffic flow (needing
another security service as an NSF) via NSF-Facing Interface. This another security service as an NSF) via NSF-Facing Interface. This
update lets Security Controller ask Classifier (denoted as Switch-2) update lets Security Controller ask Classifier (denoted as Switch-2)
to update the mapping between the traffic flow and SFP in Classifier to update the mapping between the traffic flow and SFP in Classifier
via NSF-Facing Interface. via NSF-Facing Interface.
The following subsections introduce three use cases for cloud-based The following subsections introduce three use cases from [RFC8192]
security services: (i) firewall system, (ii) deep packet inspection for cloud-based security services: (i) firewall system, (ii) deep
system, and (iii) attack mitigation system. [RFC8192] packet inspection system, and (iii) attack mitigation system.
6.1. Firewall: Centralized Firewall System 6.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
apply common rules to individual network elements (e.g., switch). apply common rules to individual network elements (e.g., switch).
The centralized network firewall controls each forwarding element, The centralized network firewall controls each forwarding element,
and firewall rules can be added or deleted dynamically. and firewall rules can be added or deleted dynamically.
The procedure of firewall operations in this system is as follows: A time-based firewall can be enforced with packet filtering rules and
a time span (e.g., work hours). With this time-based firewall, a
1. A switch forwards an unknown flow's packet to one of the SDN time-based security policy can be enforced, as explained in
Controllers. Section 4. For example, employees at a company are allowed to access
social networking service websites during lunch time or after work
2. The SDN Controller forwards the unknown flow's packet to an hours.
appropriate security service application, such as the Firewall.
3. The Firewall analyzes, typically, the headers and contents of the
packet.
4. If the Firewall regards the packet as a malicious one with a
suspicious pattern, it reports the malicious packet to the SDN
Controller.
5. The SDN Controller installs new rules (e.g., drop packets with
the suspicious pattern) into underlying switches.
6. The suspected packets are dropped by these switches.
Existing SDN protocols can be used through standard interfaces
between the firewall application and switches
[RFC7149][ITU-T.Y.3300][ONF-OpenFlow] [ONF-SDN-Architecture].
Legacy firewalls have some challenges such as the expensive cost,
performance, management of access control, establishment of policy,
and packet-based access mechanism. The proposed framework can
resolve the challenges through the above centralized firewall system
based on SDN as follows:
o Cost: The cost of adding firewalls to network resources such as
routers, gateways, and switches is substantial due to the reason
that we need to add firewall on each network resource. To solve
this, each network resource can be managed centrally such that a
single firewall is manipulated by a centralized server.
o Performance: The performance of firewalls is often slower than the
link speed of network interfaces. Every network resource for
firewall needs to check firewall rules according to network
conditions. Firewalls can be adaptively deployed among network
switches, depending on network conditions in the framework.
o The management of access control: Since there may be hundreds of
network resources in a network, the dynamic management of access
control for security services like firewall is a challenge. In
the framework, firewall rules can be dynamically added for new
malware.
o The establishment of policy: Policy should be established for each
network resource. However, it is difficult to describe what flows
are permitted or denied for firewall within a specific
organization network under management. Thus, a centralized view
is helpful to determine security policies for such a network.
o Packet-based access mechanism: Packet-based access mechanism is
not enough for firewall in practice since the basic unit of access
control is usually users or applications. Therefore, application
level rules can be defined and added to the firewall system
through the centralized server.
6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System 6.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, according to the flow and manage VoIP/VoLTE security rules, according to the
configuration of a VoIP/VoLTE security service called VoIP Intrusion configuration of a VoIP/VoLTE security service called VoIP Intrusion
Prevention System (IPS). This centralized VoIP/VoLTE security system Prevention System (IPS). This centralized VoIP/VoLTE security system
controls each switch for the VoIP/VoLTE call flow management by controls each switch for the VoIP/VoLTE call flow management by
manipulating the rules that can be added, deleted or modified manipulating the rules that can be added, deleted or modified
dynamically. dynamically.
The centralized VoIP/VoLTE security system can cooperate with a The centralized VoIP/VoLTE security system can cooperate with a
network firewall to realize VoIP/VoLTE security service. network firewall to realize VoIP/VoLTE security service.
Specifically, a network firewall performs the basic security check of Specifically, a network firewall performs the basic security check of
an unknown flow's packet observed by a switch. If the network an unknown flow's packet observed by a switch. If the network
firewall detects that the packet is an unknown VoIP call flow's firewall detects that the packet is an unknown VoIP call flow's
packet that exhibits some suspicious patterns, then it triggers the packet that exhibits some suspicious patterns, then it triggers the
VoIP/VoLTE security system for more specialized security analysis of VoIP/VoLTE security system for more specialized security analysis of
the suspicious VoIP call packet. the suspicious VoIP call packet.
The procedure of VoIP/VoLTE security operations in this system is as
follows:
1. A switch forwards an unknown flow's packet to the SDN Controller,
and the SDN Controller further forwards the unknown flow's packet
to the Firewall for basic security inspection.
2. The Firewall analyzes the header fields of the packet, and
figures out that this is an unknown VoIP call flow's signal
packet (e.g., SIP packet) of a suspicious pattern.
3. The Firewall triggers an appropriate security service function,
such as VoIP IPS, for detailed security analysis of the
suspicious signal packet. In order for this triggering of VoIP
IPS to be served, the suspicious packet is sent to the Service
Function Forwarder (SFF) that is usually a switch in an SDN
network, as shown in Figure 4. The SFF forwards the suspicious
signal packet to the VoIP IPS.
4. The VoIP IPS analyzes the headers and contents of the signal
packet, such as calling number and session description headers
[RFC4566].
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 SDN Controller to block that packet and the subsequent
packets that have the same call-id.
6. The SDN Controller installs new rules (e.g., drop packets) into
underlying switches.
7. The malicious packets are dropped by these switches.
Existing SDN protocols can be used through standard interfaces
between the VoIP IPS application and switches [RFC7149][ITU-T.Y.3300]
[ONF-OpenFlow][ONF-SDN-Architecture].
Legacy hardware based VoIP IPS has some challenges, such as
provisioning time, the granularity of security, expensive cost, and
the establishment of policy. The I2NSF framework can resolve the
challenges through the above centralized VoIP/VoLTE security system
based on SDN as follows:
o Provisioning: The provisioning time of setting up a legacy VoIP
IPS to network is substantial because it takes from some hours to
some days. By managing the network resources centrally, VoIP IPS
can provide more agility in provisioning both virtual and physical
network resources from a central location.
o The granularity of security: The security rules of a legacy VoIP
IPS are compounded considering the granularity of security. The
proposed framework can provide more granular security by
centralizing security control into a switch controller. The VoIP
IPS can effectively manage security rules throughout the network.
o Cost: The cost of adding VoIP IPS to network resources, such as
routers, gateways, and switches is substantial due to the reason
that we need to add VoIP IPS on each network resource. To solve
this, each network resource can be managed centrally such that a
single VoIP IPS is manipulated by a centralized server.
o The establishment of policy: Policy should be established for each
network resource. However, it is difficult to describe what flows
are permitted or denied for VoIP IPS within a specific
organization network under management. Thus, a centralized view
is helpful to determine security policies for such a network.
6.3. Attack Mitigation: Centralized DDoS-attack Mitigation System 6.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 configure rules to each switch for DDoS-attack mitigation (called and configure rules to each switch for DDoS-attack mitigation (called
DDoS-attack Mitigator) on a common server. The centralized DDoS- DDoS-attack Mitigator) on a common server. The centralized DDoS-
attack mitigation system defends servers against DDoS attacks outside attack mitigation system defends servers against DDoS attacks outside
the private network, that is, from public networks. the private network, that is, from public networks.
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, the forwarding of traffic flows in switches can be mitigation, the forwarding of traffic flows in switches can be
dynamically configured such that malicious traffic flows are handled dynamically configured such that malicious traffic flows are handled
by the paths separated from normal traffic flows in order to minimize by the paths separated from normal traffic flows in order to minimize
the impact of those malicious traffic on the the servers. This flow the impact of those malicious traffic on the servers. This flow path
path separation can be done by a flow forwarding path management separation can be done by a flow forwarding path management scheme
scheme based on [AVANT-GUARD]. This management should consider the based on [AVANT-GUARD]. This management should consider the load
load balance among the switches for the defense against DDoS attacks. balance among the switches for the defense against DDoS attacks.
The procedure of DDoS-attack mitigation in this system is as follows:
1. A Switch periodically reports an inter-arrival pattern of a
flow's packets to one of the SDN Controllers.
2. The SDN Controller forwards the flow's inter-arrival pattern to
an appropriate security service application, such as DDoS-attack
Mitigator.
3. The DDoS-attack Mitigator analyzes the reported pattern for the
flow.
4. If the DDoS-attack Mitigator regards the pattern as a DDoS
attack, it computes a packet dropping probability corresponding
to suspiciousness level and reports this DDoS-attack flow to the
SDN Controller.
5. The SDN Controller installs new rules into switches (e.g.,
forward packets with the suspicious inter-arrival pattern with a
dropping probability).
6. The suspicious flow's packets are randomly dropped by switches
with the dropping probability.
For the above centralized DDoS-attack mitigation system, the existing
SDN protocols can be used through standard interfaces between the
DDoS-attack mitigator application and switches [RFC7149]
[ITU-T.Y.3300][ONF-OpenFlow][ONF-SDN-Architecture].
The centralized DDoS-attack mitigation system has challenges similar
to the centralized firewall system. The proposed framework can
resolve the challenges through the above centralized DDoS-attack
mitigation system based on SDN as follows:
o Cost: The cost of adding DDoS-attack mitigators to network
resources such as routers, gateways, and switches is substantial
due to the reason that we need to add DDoS-attack mitigator on
each network resource. To solve this, each network resource can
be managed centrally such that a single DDoS-attack mitigator is
manipulated by a centralized server.
o Performance: The performance of DDoS-attack mitigators is often
slower than the link speed of network interfaces. The checking of
DDoS attacks may reduce the performance of the network interfaces.
DDoS-attack mitigators can be adaptively deployed among network
switches, depending on network conditions in the framework.
o The management of network resources: Since there may be hundreds
of network resources in an administered network, the dynamic
management of network resources for performance (e.g., load
balancing) is a challenge for DDoS-attack mitigation. In the
framework, for dynamic network resource management, a flow
forwarding path management scheme can handle the load balancing of
network switches [AVANT-GUARD]. With this management scheme, the
current and near-future workload can be spread among the network
switches for DDoS-attack mitigation. In addition, DDoS-attack
mitigation rules can be dynamically added for new DDoS attacks.
o The establishment of policy: Policy should be established for each
network resource. However, it is difficult to describe what flows
are permitted or denied for new DDoS-attacks (e.g., DNS reflection
attack) within a specific organization network under management.
Thus, a centralized view is helpful to determine security policies
for such a network.
So far this section has described the procedure and impact of the So far this section has described the three use cases for network-
three use cases for network-based security services using the I2NSF based security services using the I2NSF framework with SDN networks.
framework with SDN networks. To support these use cases in the To support these use cases in the proposed data-driven security
proposed data-driven security service framework, YANG data models service framework, YANG data models described in
described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and [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].
+--------------------+ +--------------------+
+-------------------------------------------+ | ---------------- | +-------------------------------------------+ | ---------------- |
| I2NSF User (OSS/BSS) | | | NFV | | | I2NSF User (OSS/BSS) | | | NFV | |
+------+------------------------------------+ | | Orchestrator +-+ | +------+------------------------------------+ | | Orchestrator +-+ |
| Consumer-Facing Interface | -----+---------- | | | Consumer-Facing Interface | -----+---------- | |
+------|------------------------------------+ | | | | +------|------------------------------------+ | | | |
skipping to change at page 19, line 28 skipping to change at page 18, line 20
on security requirements. In order to take advantages of the NFV on security requirements. In order to take advantages of the NFV
technology, the I2NSF framework can be implemented on top of an NFV technology, the I2NSF framework can be implemented on top of an NFV
infrastructure as show in Figure 5. infrastructure as show in Figure 5.
Figure 5 shows an I2NSF framework implementation based on the NFV Figure 5 shows an I2NSF framework implementation based on the NFV
reference architecture that the European Telecommunications Standards reference architecture that the European Telecommunications Standards
Institute (ETSI) defines [ETSI-NFV]. The NSFs are deployed as Institute (ETSI) defines [ETSI-NFV]. The NSFs are deployed as
virtual network functions (VNFs) in Figure 5. The Developer's virtual network functions (VNFs) in Figure 5. The Developer's
Management System (DMS) in the I2NSF framework is responsible for Management System (DMS) in the I2NSF framework is responsible for
registering capability information of NSFs into the Security registering capability information of NSFs into the Security
Controller. Those NSFs are created or removed by a virtual network Controller. However, those NSFs are created or removed by a virtual
functions manager (VNFM) in the NFV architecture that performs the network functions manager (VNFM) in the NFV MANO that performs the
life-cycle management of VNFs. The Security Controller controls and life-cycle management of VNFs. Note that the life-cycle management
monitors the configurations (e.g., function parameters and security of VNFs are out of scope for I2NSF. The Security Controller controls
policy rules) of VNFs. Both the DMS and Security Controller can be and monitors the configurations (e.g., function parameters and
implemented as the Element Managements (EMs) in the NFV architecture. security policy rules) of VNFs via NSF-Facing Interface along with
Finally, the I2NSF User can be implemented as OSS/BSS (Operational NSF monitoring capability [nsf-facing-inf-dm][nsf-monitoring-dm].
Support Systems/Business Support Systems) in the NFV architecture Both the DMS and Security Controller can be implemented as the
that provides interfaces for users in the NFV system. Element Managements (EMs) in the NFV architecture. Finally, the
I2NSF User can be implemented as OSS/BSS (Operational Support
Systems/Business Support Systems) in the NFV architecture that
provides interfaces for users in the NFV system.
The operation procedure in the I2NSF framework based on the NFV The operation procedure in the I2NSF framework based on the NFV
architecture is as follows: architecture is as follows:
1. The VNFM has a set of virtual machine (VM) images of NSFs, and 1. The VNFM has a set of virtual machine (VM) images of NSFs, and
each VM image can be used to create an NSF instance that provides each VM image can be used to create an NSF instance that provides
a set of security capabilities. The DMS initially registers a a set of security capabilities. The DMS initially registers a
mapping table of the ID of each VM image and the set of mapping table of the ID of each VM image and the set of
capabilities that can be provided by an NSF instance created from capabilities that can be provided by an NSF instance created from
the VM image into the Security Controller. the VM image into the Security Controller.
skipping to change at page 20, line 27 skipping to change at page 19, line 24
6. After being notified of the created NSF instance, the Security 6. After being notified of the created NSF instance, the Security
Controller delivers low-level security policy rules to the NSF Controller delivers low-level security policy rules to the NSF
instance for policy enforcement. instance for policy enforcement.
We can conclude that the I2NSF framework can be implemented based on We can conclude that the I2NSF framework can be implemented based on
the NFV architecture framework. Note that the registration of the the NFV architecture framework. Note that the registration of the
capabilities of NSFs is performed through the Registration Interface capabilities of NSFs is performed through the Registration Interface
and the lifecycle management for NSFs (VNFs) is performed through the and the lifecycle management for NSFs (VNFs) is performed through the
Ve-Vnfm interface between the DMS and VNFM, as shown in Figure 5. Ve-Vnfm interface between the DMS and VNFM, as shown in Figure 5.
More details about the I2NSF framework based on the NFV reference
architecture are described in [i2nsf-nfv-architecture].
8. Security Considerations 8. Security Considerations
The same security considerations for the I2NSF framework [RFC8329] The same security considerations for the I2NSF framework [RFC8329]
are applicable to this document. are applicable to this document.
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].
9. Acknowledgments 9. Acknowledgments
skipping to change at page 21, line 47 skipping to change at page 20, line 39
Available: https://www.itu.int/rec/T-REC-Y.3300-201406-I, Available: https://www.itu.int/rec/T-REC-Y.3300-201406-I,
June 2014. June 2014.
[NFV-Terminology] [NFV-Terminology]
"Network Functions Virtualisation (NFV); Terminology for "Network Functions Virtualisation (NFV); Terminology for
Main Concepts in NFV", Available: Main Concepts in NFV", Available:
https://www.etsi.org/deliver/etsi_gs/ https://www.etsi.org/deliver/etsi_gs/
NFV/001_099/003/01.02.01_60/gs_nfv003v010201p.pdf, NFV/001_099/003/01.02.01_60/gs_nfv003v010201p.pdf,
December 2014. December 2014.
[ONF-OpenFlow]
"OpenFlow Switch Specification (Version 1.4.0)",
Available: https://www.opennetworking.org/wp-
content/uploads/2014/10/openflow-spec-v1.4.0.pdf, October
2013.
[ONF-SDN-Architecture] [ONF-SDN-Architecture]
"SDN Architecture (Issue 1.1)", Available: "SDN Architecture (Issue 1.1)", Available:
https://www.opennetworking.org/wp- https://www.opennetworking.org/wp-
content/uploads/2014/10/TR- content/uploads/2014/10/TR-
521_SDN_Architecture_issue_1.1.pdf, June 2016. 521_SDN_Architecture_issue_1.1.pdf, June 2016.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", RFC 6020, Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. October 2010.
skipping to change at page 23, line 12 skipping to change at page 21, line 47
ietf-i2nsf-consumer-facing-interface-dm-03 (work in ietf-i2nsf-consumer-facing-interface-dm-03 (work in
progress), March 2019. progress), March 2019.
[ETSI-NFV-MANO] [ETSI-NFV-MANO]
"Network Functions Virtualisation (NFV); Management and "Network Functions Virtualisation (NFV); Management and
Orchestration", Available: Orchestration", Available:
https://www.etsi.org/deliver/etsi_gs/nfv- https://www.etsi.org/deliver/etsi_gs/nfv-
man/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf, man/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf,
December 2014. December 2014.
[i2nsf-nfv-architecture]
Yang, H., Kim, Y., Jeong, J., and J. Kim, "I2NSF on the
NFV Reference Architecture", draft-yang-i2nsf-nfv-
architecture-04 (work in progress), November 2018.
[i2nsf-nsf-cap-im]
Xia, L., Strassner, J., Basile, C., and D. Lopez,
"Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-04 (work in progress), October 2018.
[i2nsf-terminology] [i2nsf-terminology]
Hares, S., Strassner, J., Lopez, D., Xia, L., and H. Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
Birkholz, "Interface to Network Security Functions (I2NSF) Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-07 (work in Terminology", draft-ietf-i2nsf-terminology-07 (work in
progress), January 2019. progress), January 2019.
[ITU-T.X.1252]
"Baseline Identity Management Terms and Definitions",
April 2010.
[ITU-T.X.800] [ITU-T.X.800]
"Security Architecture for Open Systems Interconnection "Security Architecture for Open Systems Interconnection
for CCITT Applications", March 1991. for CCITT Applications", March 1991.
[nsf-facing-inf-dm] [nsf-facing-inf-dm]
Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
"I2NSF Network Security Function-Facing Interface YANG "I2NSF Network Security Function-Facing Interface YANG
Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-03 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-03
(work in progress), March 2019. (work in progress), March 2019.
[nsf-monitoring-dm] [nsf-monitoring-dm]
Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz, Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz,
"A YANG Data Model for Monitoring I2NSF Network Security "A YANG Data Model for Monitoring I2NSF Network Security
Functions", draft-ietf-i2nsf-nsf-monitoring-data-model-00 Functions", draft-ietf-i2nsf-nsf-monitoring-data-model-00
(work in progress), March 2019. (work in progress), March 2019.
[nsf-triggered-steering]
Hyun, S., Jeong, J., Park, J., and S. Hares, "Service
Function Chaining-Enabled I2NSF Architecture", draft-hyun-
i2nsf-nsf-triggered-steering-06 (work in progress), July
2018.
[opsawg-firewalls] [opsawg-firewalls]
Baker, F. and P. Hoffman, "On Firewalls in Internet Baker, F. and P. Hoffman, "On Firewalls in Internet
Security", draft-ietf-opsawg-firewalls-01 (work in Security", draft-ietf-opsawg-firewalls-01 (work in
progress), October 2012. progress), October 2012.
[policy-translation] [policy-translation]
Yang, J., Jeong, J., and J. Kim, "Security Policy Yang, J., Jeong, J., and J. Kim, "Security Policy
Translation in Interface to Network Security Functions", Translation in Interface to Network Security Functions",
draft-yang-i2nsf-security-policy-translation-03 (work in draft-yang-i2nsf-security-policy-translation-03 (work in
progress), March 2019. progress), March 2019.
[registration-inf-dm] [registration-inf-dm]
Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF
Registration Interface YANG Data Model", draft-ietf-i2nsf- Registration Interface YANG Data Model", draft-ietf-i2nsf-
registration-interface-dm-02 (work in progress), March registration-interface-dm-02 (work in progress), March
2019. 2019.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[VNF-ONBOARDING] [VNF-ONBOARDING]
"VNF Onboarding", Available: "VNF Onboarding", Available:
https://wiki.opnfv.org/display/mano/VNF+Onboarding, https://wiki.opnfv.org/display/mano/VNF+Onboarding,
November 2016. November 2016.
Appendix A. Changes from draft-ietf-i2nsf-applicability-08 Appendix A. Changes from draft-ietf-i2nsf-applicability-09
The following changes have been made from draft-ietf-i2nsf- The following changes have been made from draft-ietf-i2nsf-
applicability-08: applicability-09:
o This version has reflected the additional comments from Eric o This version has reflected the questions and comments from Roman
Rescorla who is a Security Area Director as follows. Danyliw who is a Security Area Director as follows.
o In Section 3, for a Developer's Management System, the problem of o In Section 1, the description of I2NSF components and interfaces
an inside attacker is addressed, and a possible solution for the is clarified with typo correction.
inside attacks is suggested through I2NSF NSF monitoring
functionality. Also, some restrictions on the role of the DMS are
required to deal with the inside attacks.
o In Section 4, an XML code for the time-dependent web access o In Section 2, unnecessary references are deleted, and the
control is explained as an example. definition of a term "NSF" is clarified with the I2NSF terminology
draft [i2nsf-terminology].
o In Section 3, inside attacks at DMS or I2NSF User are described
clearly along with feasible counterattacks against those inside
attacks. Also, the usage of RESTCONF and NETCONF with YANG data
model language is clarified for three I2NSF interfaces such as the
Consumer-Facing Interface, NSF-Facing Interface, and Registration
Interface.
o In Section 4, a real XML code for the time-dependent web access
control is added for the Consumer-Facing Interface as an example.
o In Section 5, the network service header (NSH) as a reference is
added for the metadata format for I2NSF traffic steering based on
SFC.
o In Section 6, the definitions of an SDN forwarding element and an o In Section 6, the definitions of an SDN forwarding element and an
NSF are clarified such that an SDN forwarding element is a switch NSF are clarified. Also, the optimization of an SDN-and-NFV-based
running as either a hardware middle box or a software virtual firewall is explained clearly in terms of delay and network
switch, and an NSF is a virtual network function for a security bandwidth saving.
service. It also discusses about how to determine whether a given
software element in virtualized environments is an NSF or a
virtualized switch.
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
 End of changes. 47 change blocks. 
402 lines changed or deleted 291 lines changed or added

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