draft-ietf-i2nsf-applicability-13.txt   draft-ietf-i2nsf-applicability-14.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: December 24, 2019 Chosun University Expires: January 21, 2020 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
June 22, 2019 July 20, 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-13 draft-ietf-i2nsf-applicability-14
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 December 24, 2019. This Internet-Draft will expire on January 21, 2020.
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 . . . . . . . . . . . . . . . . . . 9 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 10
6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 11 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 12
6.1. Firewall: Centralized Firewall System . . . . . . . . . . 13 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 System . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 15 7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from draft-ietf-i2nsf-applicability-12 . . . 22 Appendix A. Changes from draft-ietf-i2nsf-applicability-13 . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 an NSF is defined as software that provides a set (NSFs). Note that an NSF is defined as software that provides a set
of security-related services, such as (i) detecting unwanted of security-related services, such as (i) detecting unwanted
activity, (ii) blocking or mitigating the effect of such unwanted activity, (ii) blocking or mitigating the effect of such unwanted
activity in order to fulfil service requirements, and (iii) activity in order to fulfil service requirements, and (iii)
supporting communication stream integrity and confidentiality supporting communication stream integrity and confidentiality
skipping to change at page 6, line 42 skipping to change at page 7, line 5
an NSF's capabilities to enforce security services at the NSF. The 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 data model defined in [registration-inf-dm] can be used for the I2NSF
Registration Interface. Registration Interface.
The I2NSF framework can chain multiple NSFs to implement low-level The I2NSF framework can chain multiple NSFs to implement low-level
security policies with the SFC architecture [RFC7665]. security policies with the SFC 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
This service scenario assumes that an enterprise network
administrator wants to control the staff members' access to a
particular Internet service (e.g., Example.com) during business
hours. The following is an example high-level security policy rule
for a web filter that the administrator requests: Block the staff
members' access to Example.com from 9 AM (i.e., 09:00) to 6 PM (i.e.,
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]:
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?>
<ietf-i2nsf-cfi-policy:policy> <ietf-i2nsf-cfi-policy:policy>
<policy-name>block_website</policy-name> <policy-name>block_website</policy-name>
<rule> <rule>
<rule-name>block_website_during_working_hours</rule-name> <rule-name>block_website_during_working_hours</rule-name>
<event> <event>
<time-information> <time-information>
<begin-time>09:00</begin-time> <begin-time>09:00</begin-time>
<end-time>18:00</end-time> <end-time>18:00</end-time>
</time-information> </time-information>
</event> </event>
<condition> <condition>
<firewall-condition> <firewall-condition>
<source-target> <source-target>
<src-target>Staff_Member's_PC</src-target> <src-target>Staff_Member's_PC</src-target>
</source-target> </source-target>
</firewall-condition> </firewall-condition>
<custom-condition> <custom-condition>
<destination-target> <destination-target>
<dest-target>Example.com</dest-target> <dest-target>example.com</dest-target>
</destination-target> </destination-target>
</custom-condition> </custom-condition>
</condition> </condition>
<action> <action>
<primary-action>drop</primary-action> <primary-action>drop</primary-action>
</action> </action>
</rule> </rule>
</ietf-i2nsf-cfi-policy:policy> </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
4. Time-dependent Web Access Control Service
This service scenario assumes that an enterprise network
administrator wants to control the staff members' access to a
particular Internet service (e.g., example.com) during business
hours. The following is an example high-level security policy rule
for a web filter that the administrator requests: Block the staff
members' access to example.com from 9 AM (i.e., 09:00) to 6 PM (i.e.,
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].
The security policy name is "block_website" with the tag "policy- The security policy name is "block_website" with the tag "policy-
name", and the security policy rule name is name", and the security policy rule name is
"block_website_during_working_hours" with the tag "rule-name". The "block_website_during_working_hours" with the tag "rule-name". The
filtering event has the time span where the filtering begin time is filtering event has the time span where the filtering begin time is
the time "09:00" (i.e., 9:00AM) with the tag "begin-time", and the the time "09:00" (i.e., 9:00AM) with the tag "begin-time", and the
filtering end time is the time "18:00" (i.e., 6:00PM) with the tag filtering end time is the time "18:00" (i.e., 6:00PM) with the tag
"end-time". The filtering condition has the source target of "end-time". The filtering condition has the source target of
"Staff_Member's_PC" with the tag "src-target", the destination target "Staff_Member's_PC" with the tag "src-target", and the destination
of a website "Example.com" with the tag "dest-target". The action is target of a website "example.com" with the tag "dest-target". Note
to "drop" the packets satisfying the above event and condition with that the destination target can be translated to IP address(es)
the tag "primary-action". corresponding to the website's URL, and then either the website's URL
or the corresponding IP address(es) can be used by both firewall and
web filter. 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-session packet from a staff member, which
is part of an HTTP session generated by the 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
active NSF in the I2NSF system, which have been reported by the active NSF 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 a [policy-translation]. In this scenario, it is assumed that a
firewall NSF has the IP address and port number inspection firewall NSF has the IP address and port number inspection
capabilities and a web filter NSF 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.
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 In addition, the low-level security rules should be able to determine
target URL field of a received packet is equal to Example.com. that a received packet uses either the HTTP protocol without
Transport Layer Security (TLS) [RFC8446] or the HTTP protocol with
TLS as HTTPS. The low-level security rules for web filter check that
the target URL field of a received packet is equal to example.com, or
that the destination IP address of a received packet is an IP address
corresponding to example.com. Note that if HTTPS is used for an
HTTP-session packet, the HTTP protocol header is encrypted, so the
URL information may not be seen from the packet for the web
filtering. Thus, the IP address(es) corresponding to the target URL
needs to be obtained from the certificate in TLS versions prior to
1.3 [RFC8446] or the Server Name Indication (SNI) in a TCP-session
packet in TLS. Also, to obtain IP address(es) corresponding to a
target URL, the DNS name resolution process can be observed through a
packet capturing tool because the DNS name resolution will translate
the target URL into IP address(es). The IP addresses obtained
through either TLS or DNS can be used by both firewall and web filter
for whitelisting or blacklisting the TCP five-tuples of HTTP
sessions.
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 firewall NSF and of the IP address and port number inspection to the firewall NSF and
the low-level rules for URL inspection to the web filter NSF. 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-session 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. The SFC architecture [RFC7665] can be utilized to filter. The SFC architecture [RFC7665] can be utilized to
support such packet forwarding in the I2NSF framework. support such packet forwarding in the I2NSF framework.
4. The web filter checks the target URL field of the received 4. The web filter checks the received packet's target URL field or
packet, and realizes the packet is toward Example.com. The web its destination IP address corresponding to the target URL, and
filter then checks that the current time is in business hours. detects that the packet is being sent to the server for
If so, the web filter drops the packet, and consequently the example.com. The web filter then checks that the current time is
staff member's access to Example.com during business hours is within business hours. If so, the web filter drops the packet,
blocked. and consequently the staff member's access to example.com during
business hours is blocked.
+------------+ +------------+
| 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 20, line 5 skipping to change at page 21, 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.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018.
11.2. Informative References 11.2. Informative References
[AVANT-GUARD] [AVANT-GUARD]
Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT- Shin, S., Yegneswaran, V., Porras, P., and G. Gu, "AVANT-
GUARD: Scalable and Vigilant Switch Flow Management in GUARD: Scalable and Vigilant Switch Flow Management in
Software-Defined Networks", ACM CCS, November 2013. Software-Defined Networks", ACM CCS, November 2013.
[consumer-facing-inf-dm] [consumer-facing-inf-dm]
Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares,
"I2NSF Consumer-Facing Interface YANG Data Model", draft- "I2NSF Consumer-Facing Interface YANG Data Model", draft-
skipping to change at page 22, line 5 skipping to change at page 23, line 5
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-04 (work in progress), June registration-interface-dm-04 (work in progress), June
2019. 2019.
[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-12 Appendix A. Changes from draft-ietf-i2nsf-applicability-13
The following changes have been made from draft-ietf-i2nsf- The following changes have been made from draft-ietf-i2nsf-
applicability-12: applicability-13:
o This version has reflected further questions and comments from o This version has reflected comments from Tommy Pauly who is a
Roman Danyliw who is a Security Area Director. member of the Transport Area Review Team (TSVART).
o In Section 3, it is mentioned that the lifecycle management of NSF o In Section 4, the discussion is added to explain how to handle
code from Developer's Management System (DMS) is out of scope for HTTP-session packets using TLS in web filtering.
I2NSF.
o In Section 8, the security issues and discussion related to DMS o Some editorial comments are reflected.
are refined.
Authors' Addresses Authors' Addresses
Jaehoon Paul Jeong Jaehoon Paul Jeong
Department of Computer Science and Engineering Department of Computer Science and Engineering
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. 
60 lines changed or deleted 84 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/