--- 1/draft-ietf-i2nsf-applicability-12.txt 2019-06-22 00:13:09.386423221 -0700 +++ 2/draft-ietf-i2nsf-applicability-13.txt 2019-06-22 00:13:09.434424438 -0700 @@ -1,26 +1,26 @@ I2NSF Working Group J. Jeong Internet-Draft Sungkyunkwan University Intended status: Informational S. Hyun -Expires: December 20, 2019 Chosun University +Expires: December 24, 2019 Chosun University T. Ahn Korea Telecom S. Hares Huawei D. Lopez Telefonica I+D - June 18, 2019 + June 22, 2019 Applicability of Interfaces to Network Security Functions to Network- Based Security Services - draft-ietf-i2nsf-applicability-12 + draft-ietf-i2nsf-applicability-13 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 20, 2019. + This Internet-Draft will expire on December 24, 2019. 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 @@ -64,24 +64,24 @@ 6. I2NSF Framework with SDN . . . . . . . . . . . . . . . . . . 11 6.1. Firewall: Centralized Firewall System . . . . . . . . . . 13 6.2. Deep Packet Inspection: Centralized VoIP/VoLTE Security System . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 20 - Appendix A. Changes from draft-ietf-i2nsf-applicability-10 . . . 22 + Appendix A. Changes from draft-ietf-i2nsf-applicability-12 . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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) @@ -225,36 +225,38 @@ security capabilities, and generates low-level security policies for each of the NSFs so that the high-level security policies are eventually enforced by those NSFs [policy-translation]. Finally, the Security Controller sends the generated low-level security policies to the NSFs via the NSF-Facing Interface [nsf-facing-inf-dm]. As shown in Figure 1, with a Developer's Management System (called DMS), developers (or vendors) inform the Security Controller of the capabilities of the NSFs through the Registration Interface [registration-inf-dm] for registering (or deregistering) the - corresponding NSFs. + corresponding NSFs. Note that the lifecycle management of NSF code + from DMS (e.g., downloading of NSF modules and testing of NSF code) + is out of scope for I2NSF. The Consumer-Facing Interface can be implemented with the Consumer- Facing Interface YANG data model [consumer-facing-inf-dm] using RESTCONF [RFC8040] which befits a web-based user interface for an I2NSF User to send a Security Controller a high-level security policy. Data models specified by YANG [RFC6020] describe high-level security policies to be specified by an I2NSF User. The data model defined in [consumer-facing-inf-dm] can be used for the I2NSF Consumer-Facing Interface. Note that an inside attacker at the I2NSF User can misuse the I2NSF system so that the network system under the I2NSF system is vulnerable to security attacks. To handle this type of threat, the Security Controller needs to monitor the activities of all the I2NSF Users as well as the NSFs through the I2NSF NSF monitoring functionality [nsf-monitoring-dm]. Note that the - monitoring of the I2NSF Users is out of scope of I2NSF. + monitoring of the I2NSF Users is out of scope for I2NSF. The NSF-Facing Interface can be implemented with the NSF-Facing Interface YANG data model [nsf-facing-inf-dm] using NETCONF [RFC6241] which befits a command-line-based remote-procedure call for a Security Controller to configure an NSF with a low-level security policy. Data models specified by YANG [RFC6020] describe low-level security policies for the sake of NSFs, which are translated from the high-level security policies by the Security Controller. The data model defined in [nsf-facing-inf-dm] can be used for the I2NSF NSF- Facing Interface. @@ -719,21 +721,21 @@ infrastructure as show in Figure 5. Figure 5 shows an I2NSF framework implementation based on the NFV reference architecture that the European Telecommunications Standards Institute (ETSI) defines [ETSI-NFV]. The NSFs are deployed as VNFs in Figure 5. The Developer's Management System (DMS) in the I2NSF framework is responsible for registering capability information of NSFs into the Security Controller. However, those NSFs are created or removed by a virtual network function manager (VNFM) in the NFV MANO that performs the lifecycle management of VNFs. Note that the - lifecycle management of VNFs is out of scope of I2NSF. The Security + lifecycle management of VNFs is out of scope for I2NSF. The Security Controller controls and monitors the configurations (e.g., function parameters and security policy rules) of VNFs via the NSF-Facing Interface along with the NSF monitoring capability [nsf-facing-inf-dm][nsf-monitoring-dm]. Both the DMS and Security Controller can be implemented as the Element Managements (EMs) in the NFV architecture. Finally, the I2NSF User can be implemented as OSS/ BSS (Operational Support Systems/Business Support Systems) in the NFV architecture that provides interfaces for users in the NFV system. The operation procedure in the I2NSF framework based on the NFV @@ -776,55 +778,43 @@ Ve-Vnfm interface between the DMS and VNFM, as shown in Figure 5. 8. Security Considerations The same security considerations for the I2NSF framework [RFC8329] are applicable to this document. This document shares all the security issues of SDN that are specified in the "Security Considerations" section of [ITU-T.Y.3300]. - Note that an inside attacker (or supply chain attacker) at the DMS - can seriously weaken the I2NSF system's security. Note that a - malicious NSF provider (as a DMS) is relevant to an insider attack, - and a compromised NSF provider is relevant to a supply chain attack. - Also, note that a malicious (or compromised) DMS sending the wrong - NSF may not modify the original code of the NSF but may alter the - sent NSF as an instant. As a result, a malicious (or compromised) - DMS can attack the Security Controller by providing the Security - Controller with malicious (or compromised) NSFs, and controlling - those NSFs in real time. Also, an unwitting DMS vendor could be - compromised and their infrastructure could be coerced into - distributing modified NSFs. To deal with these types of threats, the - role of the DMS should be restricted to providing an I2NSF system - with the software package/image for NSF execution, and the DMS should - never be able to access NSFs in activated status for the I2NSF - system's security. On the other hand, an access to active NSFs - should be allowed only to the Security Controller, not the DMS during - the provisioning time of those NSFs to the I2NSF system. However, - note that an inside attacker (or supply chain attacker) can access - the active NSFs, which are being executed as either VNFs or - middleboxes in the I2NSF system, through a back door (i.e., an IP - address and a port number that are known to the DMS to control an - NSF). However, the Security Controller may detect and prevent those - inside attacks (or supply chain attacks) by monitoring the activities - of all the DMSs as well as the NSFs through the I2NSF NSF Monitoring - Interface [nsf-monitoring-dm] as part of the I2NSF NSF-Facing - Interface. Through the NSF Monitoring Interface, the Security - Controller can monitor the activities and states of NSFs, and then - can make a diagnosis to see whether the NSFs are working in normal - conditions or in abnormal conditions including the insider threats - (or supply chain threats). Note that the monitoring of the DMSs is - out of scope of I2NSF. However, as a general caution, a mitigation - strategy for insider attacks and supply chain attacks is not to use - an NSF without prior testing for an automated security action in the - I2NSF system. + The role of the DMS is to provide an I2NSF system with the software + packages or images for NSF execution. The DMS must not access NSFs + in activated status. An inside attacker or a supply chain attacker + at the DMS can seriously weaken the I2NSF system's security. A + malicious DMS is relevant to an insider attack, and a compromised DMS + is relevant to a supply chain attack. A malicious (or compromised) + DMS could register an NSF of its choice in response to a capability + request by the Security Controller. As a result, a malicious DMS can + attack the I2NSF system by providing malicious NSFs with arbitrary + capabilities to include potentially controlling those NSFs in real + time. An unwitting DMS could be compromised and the infrastructure + of the DMS could be coerced into distributing modified NSFs as well. + + To deal with these types of threats, an I2NSF system should not use + NSFs from an untrusted DMS or without prior testing. The practices + by which these packages are downloaded and loaded into the system are + out of scope for I2NSF. + + I2NSF system operators should audit and monitor interactions with + DMSs. Additionally, the operators should monitor the running NSFs + through the I2NSF NSF Monitoring Interface [nsf-monitoring-dm] as + part of the I2NSF NSF-Facing Interface. Note that the mechanics for + monitoring the DMSs are out of scope for I2NSF. 9. Acknowledgments This work was supported by Institute for Information & communications Technology Promotion (IITP) grant funded by the Korea government (MSIP) (No.R-20160222-002755, Cloud based Security Intelligence Technology Development for the Customized Security Service Provisioning). This work has been partially supported by the European Commission @@ -967,33 +957,34 @@ 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-10 +Appendix A. Changes from draft-ietf-i2nsf-applicability-12 The following changes have been made from draft-ietf-i2nsf- - applicability-11: + applicability-12: o This version has reflected further questions and comments from Roman Danyliw who is a Security Area Director. - o The security issues and discussion related to Developer's - Management System (DMS) are moved to Section 8. The monitoring of - DMSs is out of scope of I2NSF. + 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 Some typos are corrected. + o In Section 8, the security issues and discussion related to DMS + are refined. 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