draft-ietf-i2nsf-applicability-05.txt   draft-ietf-i2nsf-applicability-06.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: March 15, 2019 Chosun University Expires: April 25, 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
September 11, 2018 October 22, 2018
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-05 draft-ietf-i2nsf-applicability-06
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 March 15, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 3 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 4
4. Time-dependent Web Access Control Service . . . . . . . . . . 5 4. Time-dependent Web Access Control Service . . . . . . . . . . 5
5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 6 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 7
6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 9 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 8
6.1. Firewall: Centralized Firewall System . . . . . . . . . . 11 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 11
6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security
System . . . . . . . . . . . . . . . . . . . . . . . . . 12 System . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Attack Mitigation: Centralized DDoS-attack Mitigation 6.3. Attack Mitigation: Centralized DDoS-attack Mitigation
System . . . . . . . . . . . . . . . . . . . . . . . . . 14 System . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 16 7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Informative References . . . . . . . . . . . . . . . . . . . 19 11. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. Changes from draft-ietf-i2nsf-applicability-04 . . . 22 Appendix A. Changes from draft-ietf-i2nsf-applicability-05 . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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). 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 Network different security solution vendors to be used in the Network
Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing
the capabilities of such products and the virtualization of security the capabilities of such products and the virtualization of security
skipping to change at page 3, line 46 skipping to change at page 4, line 5
efficient firewall management. efficient firewall management.
o Centralized VoIP Security System: A centralized security system o Centralized VoIP Security System: A centralized security system
that handles the security functions required for VoIP and VoLTE that handles the security functions required for VoIP and VoLTE
services. services.
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. network resources for efficient DDoS-attack mitigation.
+------------+
| 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) | | (Web Filter) | |(DDoS-Attack Mitigator)|
+----------------+ +---------------+ +-----------------------+
Figure 1: I2NSF Framework
3. I2NSF Framework 3. I2NSF Framework
This section summarizes the I2NSF framework as defined in [RFC8329]. This section summarizes the I2NSF framework as defined in [RFC8329].
As shown in Figure 1, an I2NSF User can use security functions by As shown in Figure 1, an I2NSF User can use security functions by
delivering high-level security policies, which specify security delivering high-level security policies, which specify security
requirements that the I2NSF user wants to enforce, to the Security requirements that the I2NSF user wants to enforce, to the Security
Controller via the Consumer-Facing Interface Controller via the Consumer-Facing Interface
[consumer-facing-inf-im][consumer-facing-inf-dm]. [consumer-facing-inf-im][consumer-facing-inf-dm].
The Security Controller receives and analyzes the high-level security The Security Controller receives and analyzes the high-level security
skipping to change at page 4, line 27 skipping to change at page 5, line 4
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 developers (or vendors) services via the NSF-Facing Interface. The developers (or vendors)
inform the Security Controller of the capabilities of the NSFs inform the Security Controller of the capabilities of the NSFs
through the I2NSF Registration Interface [registration-inf-dm] for through the I2NSF Registration Interface [registration-inf-dm] for
registering (or deregistering) the corresponding NSFs. registering (or deregistering) the corresponding NSFs.
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
Interface. Interface.
+------------+
| 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) | | (Web Filter) | |(DDoS-Attack Mitigator)|
+----------------+ +---------------+ +-----------------------+
Figure 1: I2NSF Framework
The NSF-Facing Interface between the Security Controller and NSFs can The NSF-Facing Interface between the Security Controller and NSFs can
be implemented using NETCONF [RFC6241]. YANG data models describe be implemented using NETCONF [RFC6241]. YANG data models describe
low-level security policies for the sake of NSFs, which are 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 between the Security Controller and the
Developer's Management System can be implemented by RESTCONF Developer's Management System can be implemented by RESTCONF
[RFC8040]. The data model defined in [registration-inf-dm] can be [RFC8040]. The data model defined in [registration-inf-dm] can be
skipping to change at page 6, line 38 skipping to change at page 7, line 5
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 [nsf-triggered-steering].
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.
SFC generally requires classifiers and service function forwarders
(SFFs); classifiers are responsible for determining which service
function path (SFP) (i.e., an ordered sequence of service functions)
a given packet should pass through, according to pre-configured
classification rules, and SFFs perform 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 the I2NSF architecture with
SFC, the Security Controller can take responsibilities of generating
classification rules for classifiers and forwarding tables for SFFs.
By analyzing high-level security policies from I2NSF users, the
Security Controller can construct SFPs that are required to meet the
high-level security policies, generates classification rules of the
SFPs, and then configures classifiers with the classification rules
over NSF-Facing Interface so that relevant traffic packets can follow
the SFPs. Also, based on the global view of NSF instances available
in the system, the Security Controller constructs forwarding tables,
which are required for SFFs to forward a given packet to the next NSF
over the SFP, and configures SFFs with those forwarding tables over
NSF-Facing Interface.
+------------+ +------------+
| 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
| |------------------------- | |-------------------------
| | | |
| NSF-Facing Interface | | NSF-Facing Interface |
+-+-+-v-+-+-+-+-+-+ +------v-------+ +-----v-----------+ +------v-------+
| +-----------+ | ------>| NSF-1 | | +-----------+ | ------>| NSF-1 |
| |Classifier | | | | (Firewall) | | |Classifier | | | | (Firewall) |
| +-----------+ | | +--------------+ | +-----------+ | | +--------------+
| +-----+ |<-----| +--------------+ | +-----+ |<-----| +--------------+
| | SFF | | |----->| NSF-2 | | | SFF | | |----->| NSF-2 |
| +-----+ | | | (DPI) | | +-----+ | | | (DPI) |
+-+-+-+-+-+-+-+-+-+ | +--------------+ +-----------------+ | +--------------+
| . | .
| . | .
| . | .
| +-----------------------+ | +-----------------------+
------>| NSF-n | ------>| NSF-n |
|(DDoS-Attack Mitigator)| |(DDoS-Attack Mitigator)|
+-----------------------+ +-----------------------+
Figure 2: An I2NSF Framework with SFC Figure 2: 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 2 shows an I2NSF framework with the support of SFC. As shown
in the figure, SFC generally requires classifiers and service
function forwarders (SFFs); classifiers are responsible for
determining which service function path (SFP) (i.e., an ordered
sequence of service functions) a given packet should pass through,
according to pre-configured classification rules, and SFFs perform
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
the I2NSF architecture with SFC, the Security Controller can take
responsibilities of generating classification rules for classifiers
and forwarding tables for SFFs. By analyzing high-level security
policies from I2NSF users, the Security Controller can construct SFPs
that are required to meet the high-level security policies, generates
classification rules of the SFPs, and then configures classifiers
with the classification rules over NSF-Facing Interface so that
relevant traffic packets can follow the SFPs. Also, based on the
global view of NSF instances available in the system, the Security
Controller constructs forwarding tables, which are required for SFFs
to forward a given packet to the next NSF over the SFP, and
configures SFFs with those forwarding tables over NSF-Facing
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 a 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 and 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
skipping to change at page 9, line 16 skipping to change at page 9, line 5
This section describes an I2NSF framework with SDN for I2NSF This section describes an I2NSF framework with SDN for I2NSF
applicability and use cases, such as firewall, deep packet applicability and use cases, such as firewall, deep packet
inspection, and DDoS-attack mitigation functions. SDN enables some inspection, and DDoS-attack mitigation functions. SDN enables some
packet filtering rules to be enforced in network forwarding elements packet filtering rules to be enforced in network forwarding elements
(e.g., switch) by controlling their packet forwarding rules. By (e.g., switch) by controlling their packet forwarding rules. By
taking advantage of this capability of SDN, it is possible to taking advantage of this capability of SDN, it is possible to
optimize the process of security service enforcement in the I2NSF optimize the process of security service enforcement in the I2NSF
system. system.
+------------+
| 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)|
| +----------------+ +---------------+ +-----------------------+
|
|
| SDN Network
+--|----------------------------------------------------------------+
| V NSF-Facing Interface |
| +----------------+ |
| | SDN Controller | |
| +----------------+ |
| ^ |
| | SDN Southbound Interface |
| v |
| +--------+ +------------+ +--------+ +--------+ |
| |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| |
| | | |(Classifier)| | (SFF) | | | |
| +--------+ +------------+ +--------+ +--------+ |
+-------------------------------------------------------------------+
Figure 3: An I2NSF Framework with SDN Network
Figure 3 shows an I2NSF framework [RFC8329] with SDN networks to Figure 3 shows an I2NSF framework [RFC8329] with SDN networks to
support network-based security services. In this system, the support network-based security services. In this system, the
enforcement of security policy rules is divided into the SDN enforcement of security policy rules is divided into the SDN
forwarding elements (e.g., switch) and NSFs. Especially, SDN forwarding elements (e.g., switch) and NSFs. Especially, SDN
forwarding elements enforce simple packet filtering rules that can be forwarding elements enforce simple packet filtering rules that can be
translated into their packet forwarding rules, whereas NSFs enforce translated into their packet forwarding rules, whereas NSFs enforce
NSF-related security rules requiring the security capabilities of the NSF-related security rules requiring the security capabilities of the
NSFs. For this purpose, the Security Controller instructs the SDN NSFs. For this purpose, 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 perform the required security services with flow tables under the can perform the required security services with flow tables under the
skipping to change at page 10, line 7 skipping to change at page 10, line 32
elements and which should be enforced by NSFs. If some of the given elements and which should be enforced by NSFs. If some of the given
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.
+------------+ For the support of SFC in the I2NSF framework with SDN, as shown in
| I2NSF User | Figure 3, network forwarding elements (e.g., switch) can play the
+------------+ role of either SFC Classifier or SFF, which are explained in
^ Section 5. Classifier and SFF have an NSF-Facing Interface with
| Consumer-Facing Interface Security Controller. This interface is used to update security
v service function chaining information for traffic flows. For
+-------------------+ Registration +-----------------------+ example, when it needs to update an SFP for a traffic flow in an SDN
|Security Controller|<-------------------->|Developer's Mgmt System| network, as shown in Figure 3, SFF (denoted as Switch-3) asks
+-------------------+ Interface +-----------------------+ Security Controller to update the SFP for the traffic flow (needing
^ ^ another security service as an NSF) via NSF-Facing Interface. This
| | NSF-Facing Interface update lets Security Controller ask Classifier (denoted as Switch-2)
| v to update the mapping between the traffic flow and SFP in Classifier
| +----------------+ +---------------+ +-----------------------+ via NSF-Facing Interface.
| | NSF-1 |-| NSF-2 |...| NSF-n |
| | (Firewall) | | (DPI) | |(DDoS-Attack Mitigator)|
| +----------------+ +---------------+ +-----------------------+
| ^
| |
| v
| +--------+
| | SFF |
| +--------+
| ^
| |
| V SDN Network
+--|----------------------------------------------------------------+
| V NSF-Facing Interface |
| +----------------+ |
| | SDN Controller | |
| +----------------+ |
| ^ |
| | SDN Southbound Interface |
| v |
| +--------+ +--------+ +--------+ +--------+ |
| |Switch 1|-|Switch 2|-|Switch 3|......|Switch m| |
| +--------+ +--------+ +--------+ +--------+ |
+-------------------------------------------------------------------+
Figure 3: An I2NSF Framework with SDN Network
The following subsections introduce three use cases for cloud-based The following subsections introduce three use cases for cloud-based
security services: (i) firewall system, (ii) deep packet inspection security services: (i) firewall system, (ii) deep packet inspection
system, and (iii) attack mitigation system. [RFC8192] system, and (iii) attack mitigation system. [RFC8192]
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,
skipping to change at page 13, line 7 skipping to change at page 13, line 7
1. A switch forwards an unknown flow's packet to the SDN Controller, 1. A switch forwards an unknown flow's packet to the SDN Controller,
and the SDN Controller further forwards the unknown flow's packet and the SDN Controller further forwards the unknown flow's packet
to the Firewall for basic security inspection. to the Firewall for basic security inspection.
2. The Firewall analyzes the header fields of the packet, and 2. The Firewall analyzes the header fields of the packet, and
figures out that this is an unknown VoIP call flow's signal figures out that this is an unknown VoIP call flow's signal
packet (e.g., SIP packet) of a suspicious pattern. packet (e.g., SIP packet) of a suspicious pattern.
3. The Firewall triggers an appropriate security service function, 3. The Firewall triggers an appropriate security service function,
such as VoIP IPS, for detailed security analysis of the such as VoIP IPS, for detailed security analysis of the
suspicious signal packet. That is, the firewall sends the packet suspicious signal packet. In order for this triggering of VoIP
to the Service Function Forwarder (SFF) in the I2NSF framework IPS to be served, the suspicious packet is sent to the Service
[nsf-triggered-steering], as shown in Figure 3. The SFF forwards Function Forwarder (SFF) that is usually a switch in an SDN
the suspicious signal packet to the VoIP IPS. network, as shown in Figure 3. The SFF forwards the suspicious
signal packet to the VoIP IPS.
4. The VoIP IPS analyzes the headers and contents of the signal 4. The VoIP IPS analyzes the headers and contents of the signal
packet, such as calling number and session description headers packet, such as calling number and session description headers
[RFC4566]. [RFC4566].
5. If, for example, the VoIP IPS regards the packet as a spoofed 5. If, for example, the VoIP IPS regards the packet as a spoofed
packet by hackers or a scanning packet searching for VoIP/VoLTE packet by hackers or a scanning packet searching for VoIP/VoLTE
devices, it drops the packet. In addition, the VoIP IPS requests devices, it drops the packet. In addition, the VoIP IPS requests
the SDN Controller to block that packet and the subsequent the SDN Controller to block that packet and the subsequent
packets that have the same call-id. packets that have the same call-id.
skipping to change at page 16, line 18 skipping to change at page 16, line 18
This section discusses the implementation of the I2NSF framework This section discusses the implementation of the I2NSF framework
using Network Functions Virtualization (NFV). using Network Functions Virtualization (NFV).
+--------------------+ +--------------------+
+-------------------------------------------+ | ---------------- | +-------------------------------------------+ | ---------------- |
| I2NSF User (OSS/BSS) | | | NFV | | | I2NSF User (OSS/BSS) | | | NFV | |
+------+------------------------------------+ | | Orchestrator +-+ | +------+------------------------------------+ | | Orchestrator +-+ |
| Consumer-Facing Interface | -----+---------- | | | Consumer-Facing Interface | -----+---------- | |
+------|------------------------------------+ | | | | +------|------------------------------------+ | | | |
| -----+---------- (a) ----------------- | | | | | | -----+---------- (a) ----------------- | | ----+----- | |
| | Security |-------| Developer's | | | | | | | | Security +-------+ Developer's | | | | | | |
| |Controller(EM)| |Mgmt System(EM)| | | | | | | |Controller(EM)| |Mgmt System(EM)| +-(b)-+ VNFM(s)| | |
| -----+---------- ----------------- | | ----+----- | | | -----+---------- ----------------- | | | | | |
| | NSF-Facing Interface | | | | | | | | NSF-Facing Interface | | ----+----- | |
| ----+----- ----+----- ----+----- | | | VNFM(s)| | | | ----+----- ----+----- ----+----- | | | | |
| |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| +-(b)-+ | | | | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | | | |
| ----+----- ----+----- ----+----- | | ----+----- | | | ----+----- ----+----- ----+----- | | | | |
| | | | | | | | | | | | | | | | | |
+------|-------------|-------------|--------+ | | | | +------|-------------|-------------|--------+ | | | |
| | | | | | | | | | | | | |
+------+-------------+-------------+--------+ | | | | +------+-------------+-------------+--------+ | | | |
| NFV Infrastructure (NFVI) | | | | | | NFV Infrastructure (NFVI) | | | | |
| ----------- ----------- ----------- | | | | | | ----------- ----------- ----------- | | | | |
| | Virtual | | Virtual | | Virtual | | | | | | | | Virtual | | Virtual | | Virtual | | | | | |
| | Compute | | Storage | | Network | | | | | | | | Compute | | Storage | | Network | | | | | |
| ----------- ----------- ----------- | | ----+----- | | | ----------- ----------- ----------- | | ----+----- | |
| +---------------------------------------+ | | | | | | | +---------------------------------------+ | | | | | |
| | Virtualization Layer | +-----+ VIM(s) +------+ | | | Virtualization Layer | +-----+ VIM(s) +------+ |
| +---------------------------------------+ | | | | | | +---------------------------------------+ | | | | |
| +---------------------------------------+ | | ---------- | | +---------------------------------------+ | | ---------- |
| | ----------- ----------- ----------- | | | | | | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | | | | | Compute | | Storage | | Network | | | | |
| | | Hardware| | Hardware| | Hardware| | | | | | | | Hardware| | Hardware| | Hardware| | | | |
| | ----------- ----------- ----------- | | | | | | ----------- ----------- ----------- | | | |
| | Hardware Resources | | | NFV Management | | | Hardware Resources | | | NFV Management |
| +---------------------------------------+ | | and Orchestration | | +---------------------------------------+ | | and Orchestration |
| | | (MANO) |
+-------------------------------------------+ +--------------------+ +-------------------------------------------+ +--------------------+
(a) = Registration Interface (a) = Registration Interface
(b) = Ve-Vnfm Interface (b) = Ve-Vnfm Interface
Figure 4: I2NSF Framework Implementation with respect to the NFV Figure 4: I2NSF Framework Implementation with respect to the NFV
Reference Architectural Framework Reference Architectural Framework
NFV is a promising technology for improving the elasticity and NFV is a promising technology for improving the elasticity and
efficiency of network resource utilization. In NFV environments, efficiency of network resource utilization. In NFV environments,
NSFs can be deployed in the forms of software-based virtual instances NSFs can be deployed in the forms of software-based virtual instances
skipping to change at page 22, line 5 skipping to change at page 22, line 5
(I2NSF): Problem Statement and Use Cases", RFC 8192, July (I2NSF): Problem Statement and Use Cases", RFC 8192, July
2017. 2017.
[RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", RFC 8300, January 2018. Header (NSH)", RFC 8300, January 2018.
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Kumar, "Framework for Interface to Network Security Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, February 2018. Functions", RFC 8329, February 2018.
Appendix A. Changes from draft-ietf-i2nsf-applicability-04 Appendix A. Changes from draft-ietf-i2nsf-applicability-05
The following changes have been made from draft-ietf-i2nsf-
applicability-04:
o A more precise description of the basic I2NSF flows is provided.
o The structure of the document makes each discussed use case be an The following change has been made from draft-ietf-i2nsf-
applicability statement according to the applied technology, such applicability-05:
as SFC, SDN, and NFV.
o In Section 6, Switch Controller is replaced by SDN Controller for o In Figure 3, a separate box of SFF and the relevant interfaces
the terminology consistency in SDN standards. Switch is replaced have been omitted to avoid misleading. Instead, SDN switches may
by forwarding element as a general term. play the role of SFF and Classifier in an SDN network.
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. 23 change blocks. 
126 lines changed or deleted 134 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/