--- 1/draft-ietf-i2nsf-applicability-13.txt 2019-07-20 22:14:02.483079797 -0700 +++ 2/draft-ietf-i2nsf-applicability-14.txt 2019-07-20 22:14:02.531081015 -0700 @@ -1,26 +1,26 @@ I2NSF Working Group J. Jeong Internet-Draft Sungkyunkwan University Intended status: Informational S. Hyun -Expires: December 24, 2019 Chosun University +Expires: January 21, 2020 Chosun University T. Ahn Korea Telecom S. Hares Huawei D. Lopez Telefonica I+D - June 22, 2019 + July 20, 2019 Applicability of Interfaces to Network Security Functions to Network- Based Security Services - draft-ietf-i2nsf-applicability-13 + draft-ietf-i2nsf-applicability-14 Abstract This document describes the applicability of Interface to Network Security Functions (I2NSF) to network-based security services in Network Functions Virtualization (NFV) environments, such as firewall, deep packet inspection, or attack mitigation engines. Status of This Memo @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -52,37 +52,37 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. I2NSF Framework . . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Time-dependent Web Access Control Service . . . . . . . . . . 6 - 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 9 - 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 11 - 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 13 + 4. Time-dependent Web Access Control Service . . . . . . . . . . 7 + 5. I2NSF Framework with SFC . . . . . . . . . . . . . . . . . . 10 + 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 12 + 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 14 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security - System . . . . . . . . . . . . . . . . . . . . . . . . . 14 + System . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. Attack Mitigation: Centralized DDoS-attack Mitigation - System . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 15 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 11.2. Informative References . . . . . . . . . . . . . . . . . 20 - Appendix A. Changes from draft-ietf-i2nsf-applicability-12 . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + System . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7. I2NSF Framework with NFV . . . . . . . . . . . . . . . . . . 16 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 11.2. Informative References . . . . . . . . . . . . . . . . . 21 + Appendix A. Changes from draft-ietf-i2nsf-applicability-13 . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Interface to Network Security Functions (I2NSF) defines a framework and interfaces for interacting with Network Security Functions (NSFs). Note that an NSF is defined as software that provides a set of security-related services, such as (i) detecting unwanted activity, (ii) blocking or mitigating the effect of such unwanted activity in order to fulfil service requirements, and (iii) supporting communication stream integrity and confidentiality @@ -269,133 +269,156 @@ an NSF's capabilities to enforce security services at the NSF. The data model defined in [registration-inf-dm] can be used for the I2NSF Registration Interface. The I2NSF framework can chain multiple NSFs to implement low-level security policies with the SFC architecture [RFC7665]. The following sections describe different security service scenarios 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]: - block_website block_website_during_working_hours 09:00 18:00 Staff_Member's_PC - Example.com + example.com drop 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- name", and the security policy rule name is "block_website_during_working_hours" with the tag "rule-name". The 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 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 - "Staff_Member's_PC" with the tag "src-target", the destination target - of a website "Example.com" with the tag "dest-target". The action is - to "drop" the packets satisfying the above event and condition with - the tag "primary-action". + "Staff_Member's_PC" with the tag "src-target", and the destination + target of a website "example.com" with the tag "dest-target". Note + that the destination target can be translated to IP address(es) + 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 Controller identifies required security capabilities, e.g., IP address and port number inspection capabilities and URL inspection capability. In this scenario, it is assumed that the IP address and port number inspection capabilities are required to check whether a - received packet is an HTTP packet from a staff member. The URL + 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 - 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 active NSF in the I2NSF system, which have been reported by the Developer's Management System via the Registration interface. Based on this information, the Security Controller identifies NSFs that can perform the IP address and port number inspection and URL inspection [policy-translation]. In this scenario, it is assumed that a firewall NSF has the IP address and port number inspection capabilities and a web filter NSF has URL inspection capability. The Security Controller generates low-level security rules for the NSFs to perform IP address and port number inspection, URL inspection, and time checking. Specifically, the Security Controller may interoperate with an access control server in the enterprise network in order to retrieve the information (e.g., IP address in use, company identifier (ID), and role) of each employee that is currently using the network. Based on the retrieved information, the Security Controller generates low-level security rules to check whether the source IP address of a received packet matches any one - being used by a staff member. In addition, the low-level security - rules should be able to determine that a received packet is of HTTP - protocol. The low-level security rules for web filter check that the - target URL field of a received packet is equal to Example.com. + being used by a staff member. + + In addition, the low-level security rules should be able to determine + 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 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 following describes how the time-dependent web access control service is enforced by the NSFs of firewall and web filter. - 1. A staff member tries to access Example.com during business hours, + 1. A staff member tries to access example.com during business hours, e.g., 10 AM. 2. The packet is forwarded from the staff member's device to the firewall, and the firewall checks the source IP address and port number. Now the firewall identifies the received packet is an - HTTP packet from the staff member. + HTTP-session packet from the staff member. 3. The firewall triggers the web filter to further inspect the packet, and the packet is forwarded from the firewall to the web filter. The SFC architecture [RFC7665] can be utilized to support such packet forwarding in the I2NSF framework. - 4. The web filter checks the target URL field of the received - packet, and realizes the packet is toward Example.com. The web - filter then checks that the current time is in business hours. - If so, the web filter drops the packet, and consequently the - staff member's access to Example.com during business hours is - blocked. + 4. The web filter checks the received packet's target URL field or + its destination IP address corresponding to the target URL, and + detects that the packet is being sent to the server for + example.com. The web filter then checks that the current time is + within business hours. If so, the web filter drops the packet, + and consequently the staff member's access to example.com during + business hours is blocked. +------------+ | I2NSF User | +------------+ ^ | Consumer-Facing Interface v +-------------------+ Registration +-----------------------+ |Security Controller|<-------------------->|Developer's Mgmt System| +-------------------+ Interface +-----------------------+ @@ -893,20 +916,23 @@ (I2NSF): Problem Statement and Use Cases", RFC 8192, July 2017. [RFC8300] Quinn, P., Elzur, U., and C. Pignataro, "Network Service Header (NSH)", RFC 8300, January 2018. [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security 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 [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. [consumer-facing-inf-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, "I2NSF Consumer-Facing Interface YANG Data Model", draft- @@ -957,34 +983,32 @@ Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF Registration Interface YANG Data Model", draft-ietf-i2nsf- registration-interface-dm-04 (work in progress), June 2019. [VNF-ONBOARDING] "VNF Onboarding", Available: https://wiki.opnfv.org/display/mano/VNF+Onboarding, 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- - applicability-12: + applicability-13: - o This version has reflected further questions and comments from - Roman Danyliw who is a Security Area Director. + o This version has reflected comments from Tommy Pauly who is a + member of the Transport Area Review Team (TSVART). - o In Section 3, it is mentioned that the lifecycle management of NSF - code from Developer's Management System (DMS) is out of scope for - I2NSF. + o In Section 4, the discussion is added to explain how to handle + HTTP-session packets using TLS in web filtering. - o In Section 8, the security issues and discussion related to DMS - are refined. + o Some editorial comments are reflected. Authors' Addresses Jaehoon Paul Jeong Department of Computer Science and Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon, Gyeonggi-Do 16419 Republic of Korea