draft-ietf-i2nsf-applicability-07.txt   draft-ietf-i2nsf-applicability-08.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: April 25, 2019 Chosun University Expires: June 28, 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
October 22, 2018 December 25, 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-07 draft-ietf-i2nsf-applicability-08
Abstract Abstract
This document describes the applicability of Interface to Network This document describes the applicability of Interface to Network
Security Functions (I2NSF) to network-based security services in Security Functions (I2NSF) to network-based security services in
Network Functions Virtualization (NFV) environments, such as Network Functions Virtualization (NFV) environments, such as
firewall, deep packet inspection, or attack mitigation engines. firewall, deep packet inspection, or attack mitigation engines.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). 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 http://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 April 25, 2019. This Internet-Draft will expire on June 28, 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
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 4 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 5
4. Time-dependent Web Access Control Service . . . . . . . . . . 5 4. Time-dependent Web Access Control Service . . . . . . . . . . 6
5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . . 7 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 8
6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . . 8 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 9
6.1. Firewall: Centralized Firewall System . . . . . . . . . . 10 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 12
6.2. Deep Packet Inspection: Centralized VoIP/VoLTE 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security
Security System . . . . . . . . . . . . . . . . . . . . . 12 System . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Attack Mitigation: Centralized DDoS-attack Mitigation 6.3. Attack Mitigation: Centralized DDoS-attack Mitigation
System . . . . . . . . . . . . . . . . . . . . . . . . . . 14 System . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . . 16 7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Informative References . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Changes from draft-ietf-i2nsf-applicability-06 . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from draft-ietf-i2nsf-applicability-07 . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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). Note that Network Security Function (NSF) is defined as a
different security solution vendors to be used in the Network funcional block for a security service within an I2NSF framework that
Functions Virtualization (NFV) environment [ETSI-NFV] by utilizing has well-defined I2NSF NSF-facing interface and other external
the capabilities of such products and the virtualization of security interfaces and well-defined functional behavior [NFV-Terminology].
The I2NSF framework allows heterogeneous NSFs developed by different
security solution vendors to be used in the Network Functions
Virtualization (NFV) environment [ETSI-NFV] by utilizing the
capabilities of such products and the virtualization of security
functions in the NFV platform. In the I2NSF framework, each NSF functions in the NFV platform. In the I2NSF framework, each NSF
initially registers the profile of its own capabilities into the initially registers the profile of its own capabilities into the
system in order for themselves to be available in the system. In system in order for themselves to be available in the system. In
addition, the Security Controller is validated by the I2NSF Client addition, the Security Controller is validated by the I2NSF User
(also called I2NSF User) that the user is employing, so that the user (also called I2NSF Client) that a system administrator (as a user) is
can request security services through the Security Controller. employing, so that the system administrator can request security
services through the Security Controller.
This document illustrates the applicability of the I2NSF framework This document illustrates the applicability of the I2NSF framework
with four different scenarios: (i) the enforcement of time-dependent with four different scenarios:
web access control; (ii) the application of I2NSF to a Service
Function Chaining (SFC) environment [RFC7665]; (iii) the integration 1. The enforcement of time-dependent web access control.
of the I2NSF framework with Software-Defined Networking (SDN)
[RFC7149] to provide different security functionality such as 2. The application of I2NSF to a Service Function Chaining (SFC)
firewalls [opsawg-firewalls], Deep Packet Inspection (DPI), and environment [RFC7665].
Distributed Denial of Service (DDoS) attack mitigation; (iv) the use
of NFV as supporting technology. The implementation of I2NSF in 3. The integration of the I2NSF framework with Software-Defined
these scenarios has allowed us to verify the applicability and Networking (SDN) [RFC7149] to provide different security
effectiveness of the I2NSF framework for a variety of use cases. functionality such as firewalls [opsawg-firewalls], Deep Packet
Inspection (DPI), and Distributed Denial of Service (DDoS) attack
mitigation.
4. The use of Network Functions Virtualization (NFV) [ETSI-NFV] as a
supporting technology.
The implementation of I2NSF in these scenarios has allowed us to
verify the applicability and effectiveness of the I2NSF framework for
a variety of use cases.
2. Terminology 2. Terminology
This document uses the terminology described in [RFC7149], This document uses the terminology described in [RFC7665], [RFC7149],
[ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture], [ITU-T.Y.3300], [ONF-OpenFlow], [ONF-SDN-Architecture],
[ITU-T.X.1252], [ITU-T.X.800], [RFC8329], [i2nsf-terminology], [ITU-T.X.1252], [ITU-T.X.800], [NFV-Terminology], [RFC8329],
[consumer-facing-inf-im], [consumer-facing-inf-dm], [i2nsf-terminology], [consumer-facing-inf-im],
[i2nsf-nsf-cap-im], [nsf-facing-inf-dm], [registration-inf-dm], and [consumer-facing-inf-dm], [i2nsf-nsf-cap-im], [nsf-facing-inf-dm],
[nsf-triggered-steering]. In addition, the following terms are [registration-inf-dm], and [nsf-triggered-steering]. In addition,
defined below: 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
infrastructure that has well-defined external interfaces and well-
defined functional behavior [NFV-Terminology].
o Network Security Function (NSF): A funcional block within a
security service within a network infrastructure that has well-
defined external interfaces and well-defined functional
behavior[NFV-Terminology].
o Network Functions Virtualization (NFV): A principle of separating
network functions (or network security functions) from the
hardware they run on by using virtual hardware abstraction
[NFV-Terminology].
o Service Function Chaining (SFC): The execution of an ordered set
of abstract service functions (i.e., network functions) according
to ordering constraints that must be applied to packets, frames,
and flows selected as a result of classification. The implied
order may not be a linear progression as the architecture allows
for SFCs that copy to more than one branch, and also allows for
cases where there is flexibility in the order in which service
functions need to be applied [RFC7665].
o Firewall: A service function at the junction of two network o Firewall: A service function at the junction of two network
segments that inspects every packet that attempts to cross the segments that inspects some suspicious packets that attempt to
boundary. It also rejects any packet that does not satisfy cross the boundary. It also rejects any packet that does not
certain criteria for, for example, disallowed port numbers or IP satisfy certain criteria for, for example, disallowed port numbers
addresses. or IP addresses.
o Centralized Firewall System: A centralized firewall that can o Centralized Firewall System: A centralized firewall that can
establish and distribute policy rules into network resources for establish and distribute policy rules into network resources for
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
skipping to change at page 5, line 8 skipping to change at page 5, line 44
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 [i2nsf-nsf-cap-im][nsf-facing-inf-dm].
The Security Controller requests NSFs to perform low-level security The Security Controller requests NSFs to perform low-level security
services via the NSF-Facing Interface. The developers (or vendors) services via the NSF-Facing Interface. As shown in Figure 1, with a
inform the Security Controller of the capabilities of the NSFs Developer's Management System, developers (or vendors) inform the
through the I2NSF Registration Interface [registration-inf-dm] for Security Controller of the capabilities of the NSFs through the I2NSF
registering (or deregistering) the corresponding NSFs. Registration Interface [registration-inf-dm] for registering (or
deregistering) the corresponding NSFs. Note that an inside attacker
at the Development Management System can seriously weaken the I2NSF
system's security. For the detection and prevention of inside
attacks, the Security Controller needs to monitor the activity of all
the Development Management Systems as well as the NSFs through the
I2NSF NSF monitoring functionality [nsf-monitoring-dm].
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.
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
skipping to change at page 5, line 43 skipping to change at page 6, line 37
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 described in [nsf-triggered-steering].
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 Interner 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
that the administrator requests: Block the staff members' access to that the administrator requests: Block the staff members' access to
Example.com from 9 AM to 6 PM. The administrator sends this high- Example.com from 9 AM to 6 PM. The administrator sends this high-
level security policy to the Security Controller, then the Security level security policy to the Security Controller. Refer to an XML
file for the high-level security policy of a time-based web-filter in
[consumer-facing-inf-dm], whose data model is defined by YANG, and
which is delivered over RESTCONF.
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 Registation 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 an NSF of
firewall has the IP address and port number inspection capabilities firewall has the IP address and port number inspection capabilities
and an NSF of web filter has URL inspection capability. and an NSF of web filter 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 checks that protocol. The low-level security rules for web filter check that the
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 NSF of firewall
and the low-level rules for URL inspection to the NSF of web filter. and the low-level rules for URL inspection to the NSF of web filter.
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.
skipping to change at page 9, line 43 skipping to change at page 10, line 43
| |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| | | |Switch-1|-| Switch-2 |-|Switch-3|.......|Switch-m| |
| | | |(Classifier)| | (SFF) | | | | | | | |(Classifier)| | (SFF) | | | |
| +--------+ +------------+ +--------+ +--------+ | | +--------+ +------------+ +--------+ +--------+ |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
Figure 3: An I2NSF Framework with SDN Network 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 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 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
supervision of the SDN Controller. 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 fltering 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
attached file stored in the flow of packets. The NSF then analyzes attached file stored in the flow of packets. The NSF then analyzes
the file to check the existence of malware. If the file contains the file to check the existence of malware. If the file contains
skipping to change at page 12, line 31 skipping to change at page 13, line 35
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 basic security checks of an Specifically, a network firewall performs the basic security check of
unknown flow's packet observed by a switch. If the network firewall an unknown flow's packet observed by a switch. If the network
detects that the packet is an unknown VoIP call flow's packet that firewall detects that the packet is an unknown VoIP call flow's
exhibits some suspicious patterns, then it triggers the VoIP/VoLTE packet that exhibits some suspicious patterns, then it triggers the
security system for more specialized security analysis of the VoIP/VoLTE security system for more specialized security analysis of
suspicious VoIP call packet. the suspicious VoIP call packet.
The procedure of VoIP/VoLTE security operations in this system is as The procedure of VoIP/VoLTE security operations in this system is as
follows: follows:
1. A switch forwards an unknown 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
skipping to change at page 13, line 22 skipping to change at page 14, line 26
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.
6. The SDN Controller installs new rules (e.g., drop packets) into 6. The SDN Controller installs new rules (e.g., drop packets) into
underlying switches. underlying switches.
7. The illegal packets are dropped by these switches. 7. The malicious packets are dropped by these switches.
Existing SDN protocols can be used through standard interfaces Existing SDN protocols can be used through standard interfaces
between the VoIP IPS application and switches [RFC7149][ITU-T.Y.3300] between the VoIP IPS application and switches [RFC7149][ITU-T.Y.3300]
[ONF-OpenFlow][ONF-SDN-Architecture]. [ONF-OpenFlow][ONF-SDN-Architecture].
Legacy hardware based VoIP IPS has some challenges, such as Legacy hardware based VoIP IPS has some challenges, such as
provisioning time, the granularity of security, expensive cost, and provisioning time, the granularity of security, expensive cost, and
the establishment of policy. The I2NSF framework can resolve the the establishment of policy. The I2NSF framework can resolve the
challenges through the above centralized VoIP/VoLTE security system challenges through the above centralized VoIP/VoLTE security system
based on SDN as follows: based on SDN as follows:
skipping to change at page 14, line 14 skipping to change at page 15, line 16
o The establishment of policy: Policy should be established for each o The establishment of policy: Policy should be established for each
network resource. However, it is difficult to describe what flows network resource. However, it is difficult to describe what flows
are permitted or denied for VoIP IPS within a specific are permitted or denied for VoIP IPS within a specific
organization network under management. Thus, a centralized view organization network under management. Thus, a centralized view
is helpful to determine security policies for such a network. is helpful to determine security policies for such a network.
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 manipulate rules to each switch through a common server for DDoS- and configure rules to each switch for DDoS-attack mitigation (called
attack mitigation (called DDoS-attack Mitigator). The centralized DDoS-attack Mitigator) on a common server. The centralized DDoS-
DDoS-attack mitigation system defends servers against DDoS attacks attack mitigation system defends servers against DDoS attacks outside
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, traffic flows in switches are dynamically configured by mitigation, the forwarding of traffic flows in switches can be
traffic flow forwarding path management according to the category of dynamically configured such that malicious traffic flows are handled
servers [AVANT-GUARD]. Such a managenent should consider the load by the paths separated from normal traffic flows in order to minimize
balance among the switches for the defense against DDoS attacks. the impact of those malicious traffic on the the servers. This flow
path separation can be done by a flow forwarding path management
scheme based on [AVANT-GUARD]. This management should consider the
load balance among the switches for the defense against DDoS attacks.
The procedure of DDoS-attack mitigation operations in this system is The procedure of DDoS-attack mitigation in this system is as follows:
as follows:
1. A Switch periodically reports an inter-arrival pattern of a 1. A Switch periodically reports an inter-arrival pattern of a
flow's packets to one of the SDN Controllers. flow's packets to one of the SDN Controllers.
2. The SDN Controller forwards the flow's inter-arrival pattern to 2. The SDN Controller forwards the flow's inter-arrival pattern to
an appropriate security service application, such as DDoS-attack an appropriate security service application, such as DDoS-attack
Mitigator. Mitigator.
3. The DDoS-attack Mitigator analyzes the reported pattern for the 3. The DDoS-attack Mitigator analyzes the reported pattern for the
flow. flow.
skipping to change at page 15, line 29 skipping to change at page 16, line 35
o Performance: The performance of DDoS-attack mitigators is often o Performance: The performance of DDoS-attack mitigators is often
slower than the link speed of network interfaces. The checking of slower than the link speed of network interfaces. The checking of
DDoS attacks may reduce the performance of the network interfaces. DDoS attacks may reduce the performance of the network interfaces.
DDoS-attack mitigators can be adaptively deployed among network DDoS-attack mitigators can be adaptively deployed among network
switches, depending on network conditions in the framework. switches, depending on network conditions in the framework.
o The management of network resources: Since there may be hundreds o The management of network resources: Since there may be hundreds
of network resources in an administered network, the dynamic of network resources in an administered network, the dynamic
management of network resources for performance (e.g., load management of network resources for performance (e.g., load
balancing) is a challenge for DDoS-attack mitigation. In the balancing) is a challenge for DDoS-attack mitigation. In the
framework, as dynamic network resource management, traffic flow framework, for dynamic network resource management, a flow
forwarding path management can handle the load balancing of forwarding path management scheme can handle the load balancing of
network switches [AVANT-GUARD]. With this management, the current network switches [AVANT-GUARD]. With this management scheme, the
and near-future workload can be spread among the network switches current and near-future workload can be spread among the network
for DDoS-attack mitigation. In addition, DDoS-attack mitigation switches for DDoS-attack mitigation. In addition, DDoS-attack
rules can be dynamically added for new DDoS attacks. mitigation rules can be dynamically added for new DDoS attacks.
o The establishment of policy: Policy should be established for each o The establishment of policy: Policy should be established for each
network resource. However, it is difficult to describe what flows network resource. However, it is difficult to describe what flows
are permitted or denied for new DDoS-attacks (e.g., DNS reflection are permitted or denied for new DDoS-attacks (e.g., DNS reflection
attack) within a specific organization network under management. attack) within a specific organization network under management.
Thus, a centralized view is helpful to determine security policies Thus, a centralized view is helpful to determine security policies
for such a network. for such a network.
So far this section has described the procedure and impact of the So far this section has described the procedure and impact of the
three use cases for network-based security services using the I2NSF three use cases for network-based security services using the I2NSF
framework with SDN networks. To support these use cases in the framework with SDN networks. To support these use cases in the
proposed data-driven security service framework, YANG data models proposed data-driven security service framework, YANG data models
described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and described in [consumer-facing-inf-dm], [nsf-facing-inf-dm], and
[registration-inf-dm] can be used as Consumer-Facing Interface, NSF- [registration-inf-dm] can be used as Consumer-Facing Interface, NSF-
Facing Interface, and Registration Interface, respectively, along Facing Interface, and Registration Interface, respectively, along
with RESTCONF [RFC8040] and NETCONF [RFC6241]. with RESTCONF [RFC8040] and NETCONF [RFC6241].
7. I2NSF Framework with NFV
This section discusses the implementation of the I2NSF framework
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)| +-(b)-+ VNFM(s)| | | | |Controller(EM)| |Mgmt System(EM)| +-(b)-+ VNFM(s)| | |
| -----+---------- ----------------- | | | | | | | -----+---------- ----------------- | | | | | |
skipping to change at page 16, line 51 skipping to change at page 18, line 5
| | Hardware Resources | | | NFV Management | | | Hardware Resources | | | NFV Management |
| +---------------------------------------+ | | and Orchestration | | +---------------------------------------+ | | and Orchestration |
| | | (MANO) | | | | (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
7. I2NSF Framework with NFV
This section discusses the implementation of the I2NSF framework
using Network Functions Virtualization (NFV).
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
rather than physical appliances. Virtualizing NSFs makes it possible rather than physical appliances. Virtualizing NSFs makes it possible
to rapidly and flexibly respond to the amount of service requests by to rapidly and flexibly respond to the amount of service requests by
dynamically increasing or decreasing the number of NSF instances. dynamically increasing or decreasing the number of NSF instances.
Moreover, NFV technology facilitates flexibly including or excluding Moreover, NFV technology facilitates flexibly including or excluding
NSFs from multiple security solution vendors according to the changes NSFs from multiple security solution vendors according to the changes
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
skipping to change at page 19, line 16 skipping to change at page 20, line 24
o Hyunsik Yang (Soongsil University) o Hyunsik Yang (Soongsil University)
o Younghan Kim (Soongsil University) o Younghan Kim (Soongsil University)
o Jung-Soo Park (ETRI) o Jung-Soo Park (ETRI)
o Se-Hui Lee (Korea Telecom) o Se-Hui Lee (Korea Telecom)
o Mohamed Boucadair (Orange) o Mohamed Boucadair (Orange)
11. Informative References 11. References
[RFC8329] Lopez, D., Lopez, E., Dunbar, L., 11.1. Normative References
Strassner, J., and R. Kumar, "Framework for
Interface to Network Security Functions",
RFC 8329, February 2018.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling [ETSI-NFV]
Language for the Network Configuration ETSI GS NFV 002 V1.1.1, "Network Functions Virtualisation
Protocol (NETCONF)", RFC 6020, (NFV); Architectural Framework", Available:
October 2010. https://www.etsi.org/deliver/etsi_gs/
nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf, October
2013.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., [ITU-T.Y.3300]
and A. Bierman, "Network Configuration Recommendation ITU-T Y.3300, "Framework of Software-
Protocol (NETCONF)", RFC 6241, June 2011. Defined Networking", Available: https://www.itu.int/rec/T-
REC-Y.3300-201406-I, June 2014.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, [NFV-Terminology]
"RESTCONF Protocol", RFC 8040, ETSI GS NFV 003 V1.2.1, "Network Functions Virtualisation
January 2017. (NFV); Terminology for Main Concepts in NFV", Available:
https://www.etsi.org/deliver/etsi_gs/
NFV/001_099/003/01.02.01_60/gs_nfv003v010201p.pdf,
December 2014.
[consumer-facing-inf-im] Kumar, R., Lohiya, A., Qi, D., Bitar, N., [ONF-OpenFlow]
Palislamovic, S., Xia, L., and J. Jeong, ONF, "OpenFlow Switch Specification (Version 1.4.0)",
"Information Model for Consumer-Facing Available: https://www.opennetworking.org/wp-
Interface to Security Controller", draft- content/uploads/2014/10/openflow-spec-v1.4.0.pdf, October
kumar-i2nsf-client-facing-interface-im-07 2013.
(work in progress), July 2018.
[consumer-facing-inf-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and [ONF-SDN-Architecture]
S. Hares, "I2NSF Consumer-Facing Interface ONF TR-521, "SDN Architecture (Issue 1.1)", Available:
YANG Data Model", draft-ietf-i2nsf- https://www.opennetworking.org/wp-
consumer-facing-interface-dm-01 (work in content/uploads/2014/10/TR-
progress), July 2018. 521_SDN_Architecture_issue_1.1.pdf, June 2016.
[i2nsf-nsf-cap-im] Xia, L., Strassner, J., Basile, C., and D. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
Lopez, "Information Model of NSFs Network Configuration Protocol (NETCONF)", RFC 6020,
Capabilities", October 2010.
draft-ietf-i2nsf-capability-02 (work in
progress), July 2018.
[policy-translation] Yang, J., Jeong, J., and J. Kim, "Security [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Policy Translation in Interface to Network Bierman, "Network Configuration Protocol (NETCONF)",
Security Functions", draft-yang-i2nsf- RFC 6241, June 2011.
security-policy-translation-01 (work in
progress), July 2018.
[nsf-facing-inf-dm] Kim, J., Jeong, J., Park, J., Hares, S., [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined
and Q. Lin, "I2NSF Network Security Networking: A Perspective from within a Service Provider
Function-Facing Interface YANG Data Model", Environment", RFC 7149, March 2014.
draft-ietf-i2nsf-nsf-facing-interface-data-
model-01 (work in progress), July 2018.
[registration-inf-dm] Hyun, S., Jeong, J., Roh, T., Wi, S., and [RFC7665] Halpern, J. and C. Pignataro, "Service Function Chaining
J. Park, "I2NSF Registration Interface YANG (SFC) Architecture", RFC 7665, October 2015.
Data Model",
draft-hyun-i2nsf-registration-dm-06 (work
in progress), July 2018.
[nsf-triggered-steering] Hyun, S., Jeong, J., Park, J., and S. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Hares, "Service Function Chaining-Enabled Protocol", RFC 8040, January 2017.
I2NSF Architecture",
draft-hyun-i2nsf-nsf-triggered-steering-06
(work in progress), July 2018.
[i2nsf-nfv-architecture] Yang, H. and Y. Kim, "I2NSF on the NFV [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
Reference Architecture", and J. Jeong, "Interface to Network Security Functions
draft-yang-i2nsf-nfv-architecture-02 (work (I2NSF): Problem Statement and Use Cases", RFC 8192, July
in progress), June 2018. 2017.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software- [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Defined Networking: A Perspective from Header (NSH)", RFC 8300, January 2018.
within a Service Provider Environment",
RFC 7149, March 2014.
[ITU-T.Y.3300] Recommendation ITU-T Y.3300, "Framework of [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
Software-Defined Networking", June 2014. Kumar, "Framework for Interface to Network Security
Functions", RFC 8329, February 2018.
[ONF-OpenFlow] ONF, "OpenFlow Switch Specification 11.2. Informative References
(Version 1.4.0)", October 2013.
[ONF-SDN-Architecture] ONF, "SDN Architecture", June 2014. [AVANT-GUARD]
Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT-
GUARD: Scalable and Vigilant Switch Flow Management in
Software-Defined Networks", ACM CCS, November 2013.
[ITU-T.X.1252] Recommendation ITU-T X.1252, "Baseline [consumer-facing-inf-dm]
Identity Management Terms and Definitions", Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares,
April 2010. "I2NSF Consumer-Facing Interface YANG Data Model", draft-
ietf-i2nsf-consumer-facing-interface-dm-02 (work in
progress), November 2018.
[ITU-T.X.800] Recommendation ITU-T X.800, "Security [consumer-facing-inf-im]
Architecture for Open Systems Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic,
Interconnection for CCITT Applications", S., Xia, L., and J. Jeong, "Information Model for
March 1991. Consumer-Facing Interface to Security Controller", draft-
kumar-i2nsf-client-facing-interface-im-07 (work in
progress), July 2018.
[AVANT-GUARD] Shin, S., Yegneswaran, V., Porras, P., and [i2nsf-nfv-architecture]
G. Gu, "AVANT-GUARD: Scalable and Vigilant Yang, H., Kim, Y., Jeong, J., and J. Kim, "I2NSF on the
Switch Flow Management in Software-Defined NFV Reference Architecture", draft-yang-i2nsf-nfv-
Networks", ACM CCS, November 2013. architecture-04 (work in progress), November 2018.
[ETSI-NFV] ETSI GS NFV 002 V1.1.1, "Network Functions [i2nsf-nsf-cap-im]
Virtualization (NFV); Architectural Xia, L., Strassner, J., Basile, C., and D. Lopez,
Framework", October 2013. "Information Model of NSFs Capabilities", draft-ietf-
i2nsf-capability-04 (work in progress), October 2018.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, [i2nsf-terminology]
"SDP: Session Description Protocol", Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
RFC 4566, July 2006. Birkholz, "Interface to Network Security Functions (I2NSF)
Terminology", draft-ietf-i2nsf-terminology-06 (work in
progress), July 2018.
[i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, [ITU-T.X.1252]
L., and H. Birkholz, "Interface to Network Recommendation ITU-T X.1252, "Baseline Identity Management
Security Functions (I2NSF) Terminology", Terms and Definitions", April 2010.
draft-ietf-i2nsf-terminology-06 (work in
progress), July 2018.
[opsawg-firewalls] Baker, F. and P. Hoffman, "On Firewalls in [ITU-T.X.800]
Internet Security", Recommendation ITU-T X.800, "Security Architecture for
draft-ietf-opsawg-firewalls-01 (work in Open Systems Interconnection for CCITT Applications",
progress), October 2012. March 1991.
[RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, [nsf-facing-inf-dm]
C., Kumar, R., and J. Jeong, "Interface to Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
Network Security Functions (I2NSF): Problem "I2NSF Network Security Function-Facing Interface YANG
Statement and Use Cases", RFC 8192, Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-02
July 2017. (work in progress), November 2018.
[RFC7665] Halpern, J. and C. Pignataro, "Service [nsf-monitoring-dm]
Function Chaining (SFC) Architecture", Jeong, J., Kim, J., Hong, D., Hares, S., Xia, L., and H.
RFC 7665, October 2015. Birkholz, "A YANG Data Model for Monitoring I2NSF Network
Security Functions", draft-hong-i2nsf-nsf-monitoring-data-
model-06 (work in progress), November 2018.
[RFC8300] Quinn, P., Elzur, U., and C. Pignataro, [nsf-triggered-steering]
"Network Service Header (NSH)", RFC 8300, Hyun, S., Jeong, J., Park, J., and S. Hares, "Service
January 2018. Function Chaining-Enabled I2NSF Architecture", draft-hyun-
i2nsf-nsf-triggered-steering-06 (work in progress), July
2018.
Appendix A. Changes from draft-ietf-i2nsf-applicability-06 [opsawg-firewalls]
Baker, F. and P. Hoffman, "On Firewalls in Internet
Security", draft-ietf-opsawg-firewalls-01 (work in
progress), October 2012.
The following change has been made from [policy-translation]
draft-ietf-i2nsf-applicability-06: Yang, J., Jeong, J., and J. Kim, "Security Policy
Translation in Interface to Network Security Functions",
draft-yang-i2nsf-security-policy-translation-02 (work in
progress), October 2018.
o Add the acknowledgment to the EU H2020 project SHIELD. [registration-inf-dm]
Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF
Registration Interface YANG Data Model", draft-ietf-i2nsf-
registration-interface-dm-01 (work in progress), November
2018.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Appendix A. Changes from draft-ietf-i2nsf-applicability-07
The following changes have been made from draft-ietf-i2nsf-
applicability-07:
o This version has reflected all the comments from Eric Rescorla who
is a Security Area Director as follows.
o In Section 1, Network Security Function (NFV) is defined in the
viewpoint of the I2NSF framework.
o In Section 1, a user using the I2NSF User is clarified as a system
administrator in the I2NSF framework.
o In Section 1, as the applicability of the I2NSF framework, four
different scenarios are represented with a standard bulleted list.
o The standard document about ETSI-NFV is moved to Normative
References.
o In Section 2, key terms (e.g., Network Function, Network Security
Function, Network Functions Virtualization, and Servive Function
Chaining) are internally defined along with the reference to open
specifications.
o In Section 2, the definition of Firewall is corrected such that
some suspicious packets are inspected by the firewall rather than
every packet.
o In Section 3, for a Developer's Management System, the problem of
an inside attacker is addressed, and a possible solution for the
inside attacks is suggested through I2NSF NSF monitoring
functionality.
o In Section 4, an XML file for the RESTCONF/YANG for the time-
dependent web access control is pointed out with a reference to
the Consumer-Facing Interface's data model
[consumer-facing-inf-dm].
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
running as either a hardware middle box or a software virtual
switch, and an NSF is a virtual network function for a security
service.
o In Section 6.3, a flow forwarding path management scheme in
[AVANT-GUARD] is described in a self-contained way as follows.
For DDoS-attack mitigation, the forwarding of traffic flows in
switches can be dynamically configured such that malicious traffic
flows are handled by the paths separated from normal traffic flows
in order to minimize the impact of those malicious traffic on the
the servers. This flow path separation can be done by a flow
forwarding path management scheme based on [AVANT-GUARD].
o Some typos are corrected such as "Interner -> Internet",
"Registation -> Registration", "The low-level security rules for
web filter checks -> The low-level security rules for web filter
check", "fltering -> filtering", "illegal packets -> malicious
packets", "manipulate rules -> configure rules", "managenent ->
management", and "DDoS-attack mitigation operations -> DDoS-attack
mitigation".
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong
Department of Software Department of Software
Sungkyunkwan University Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu 2066 Seobu-Ro, Jangan-Gu
Suwon, Gyeonggi-Do 16419 Suwon, Gyeonggi-Do 16419
Republic of Korea Republic of Korea
skipping to change at page 22, line 39 skipping to change at page 26, line 4
EMail: shyun@chosun.ac.kr EMail: shyun@chosun.ac.kr
Tae-Jin Ahn Tae-Jin Ahn
Korea Telecom Korea Telecom
70 Yuseong-Ro, Yuseong-Gu 70 Yuseong-Ro, Yuseong-Gu
Daejeon 305-811 Daejeon 305-811
Republic of Korea Republic of Korea
Phone: +82 42 870 8409 Phone: +82 42 870 8409
EMail: taejin.ahn@kt.com EMail: taejin.ahn@kt.com
Susan Hares Susan Hares
Huawei Huawei
7453 Hickory Hill 7453 Hickory Hill
Saline, MI 48176 Saline, MI 48176
USA USA
Phone: +1-734-604-0332 Phone: +1-734-604-0332
EMail: shares@ndzh.com EMail: shares@ndzh.com
Diego R. Lopez Diego R. Lopez
Telefonica I+D Telefonica I+D
Jose Manuel Lara, 9 Jose Manuel Lara, 9
Seville, 41013 Seville 41013
Spain Spain
Phone: +34 682 051 091 Phone: +34 682 051 091
EMail: diego.r.lopez@telefonica.com EMail: diego.r.lopez@telefonica.com
 End of changes. 63 change blocks. 
196 lines changed or deleted 326 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/