Applicability of Interfaces to Network Security Functions to Network-Based Security Services
draft-ietf-i2nsf-applicability-15

Internet-Draft             I2NSF Applicability                 July 2019

   NSFs can be deployed in the forms of software-based virtual instances
   rather than physical appliances.  Virtualizing NSFs makes it possible
   to rapidly and flexibly respond to the amount of service requests by
   dynamically increasing or decreasing the number of NSF instances.
   Moreover, NFV technology facilitates flexibly including or excluding
   NSFs from multiple security solution vendors according to the changes
   on security requirements.  In order to take advantages of the NFV
   technology, the I2NSF framework can be implemented on top of an NFV
   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 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
   architecture is as follows:

   1.  The VNFM has a set of virtual machine (VM) images of NSFs, and
       each VM image can be used to create an NSF instance that provides
       a set of security capabilities.  The DMS initially registers a
       mapping table of the ID of each VM image and the set of
       capabilities that can be provided by an NSF instance created from
       the VM image into the Security Controller.

   2.  If the Security Controller does not have any instantiated NSF
       that has the set of capabilities required to meet the security
       requirements from users, it searches the mapping table
       (registered by the DMS) for the VM image ID corresponding to the
       required set of capabilities.

   3.  The Security Controller requests the DMS to instantiate an NSF
       with the VM image ID via VNFM.

Jeong, et al.           Expires January 25, 2020               [Page 17]
Internet-Draft             I2NSF Applicability                 July 2019

   4.  When receiving the instantiation request, the VNFM first asks the
       NFV orchestrator for the permission required to create the NSF
       instance, requests the VIM to allocate resources for the NSF
       instance, and finally creates the NSF instance based on the
       allocated resources.

   5.  Once the NSF instance has been created by the VNFM, the DMS
       performs the initial configurations of the NSF instance and then
       notifies the Security Controller of the NSF instance.

   6.  After being notified of the created NSF instance, the Security
       Controller delivers low-level security policy rules to the NSF
       instance for policy enforcement.

   We can conclude that the I2NSF framework can be implemented based on
   the NFV architecture framework.  Note that the registration of the
   capabilities of NSFs is performed through the Registration Interface
   and the lifecycle management for NSFs (VNFs) is performed through the
   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].

   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

Jeong, et al.           Expires January 25, 2020               [Page 18]
Internet-Draft             I2NSF Applicability                 July 2019

   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 of Information & Communications
   Technology Planning & Evaluation (IITP) grant funded by the Korea
   MSIT (Ministry of Science and ICT) (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
   under Horizon 2020 grant agreement no. 700199 "Securing against
   intruders and other threats through a NFV-enabled environment
   (SHIELD)".  This support does not imply endorsement.

10.  Contributors

   I2NSF is a group effort.  I2NSF has had a number of contributing
   authors.  The following are considered co-authors:

   o  Hyoungshick Kim (Sungkyunkwan University)

   o  Jinyong Tim Kim (Sungkyunkwan University)

   o  Hyunsik Yang (Soongsil University)

   o  Younghan Kim (Soongsil University)

   o  Jung-Soo Park (ETRI)

   o  Se-Hui Lee (Korea Telecom)

   o  Mohamed Boucadair (Orange)

11.  References

11.1.  Normative References

   [ETSI-NFV]
              "Network Functions Virtualisation (NFV); Architectural
              Framework", Available:
              https://www.etsi.org/deliver/etsi_gs/
              nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf, October
              2013.

Jeong, et al.           Expires January 25, 2020               [Page 19]
Internet-Draft             I2NSF Applicability                 July 2019

   [ITU-T.Y.3300]
              "Framework of Software-Defined Networking",
              Available: https://www.itu.int/rec/T-REC-Y.3300-201406-I,
              June 2014.

   [NFV-Terminology]
              "Network Functions Virtualisation (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.

   [ONF-SDN-Architecture]
              "SDN Architecture (Issue 1.1)", Available:
              https://www.opennetworking.org/wp-
              content/uploads/2014/10/TR-
              521_SDN_Architecture_issue_1.1.pdf, June 2016.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)",
              RFC 6241, June 2011.

   [RFC7149]  Boucadair, M. and C. Jacquenet, "Software-Defined
              Networking: A Perspective from within a Service Provider
              Environment", RFC 7149, March 2014.

   [RFC7665]  Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", RFC 7665, October 2015.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, January 2017.

   [RFC8192]  Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R.,
              and J. Jeong, "Interface to Network Security Functions
              (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.

Jeong, et al.           Expires January 25, 2020               [Page 20]
Internet-Draft             I2NSF Applicability                 July 2019

   [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-
              ietf-i2nsf-consumer-facing-interface-dm-06 (work in
              progress), July 2019.

   [ETSI-NFV-MANO]
              "Network Functions Virtualisation (NFV); Management and
              Orchestration", Available:
              https://www.etsi.org/deliver/etsi_gs/nfv-
              man/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf,
              December 2014.

   [i2nsf-terminology]
              Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
              Birkholz, "Interface to Network Security Functions (I2NSF)
              Terminology", draft-ietf-i2nsf-terminology-08 (work in
              progress), July 2019.

   [ITU-T.X.800]
              "Security Architecture for Open Systems Interconnection
              for CCITT Applications", March 1991.

   [nsf-facing-inf-dm]
              Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
              "I2NSF Network Security Function-Facing Interface YANG
              Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-07
              (work in progress), July 2019.

   [nsf-monitoring-dm]
              Jeong, J., Chung, C., Hares, S., Xia, L., and H. Birkholz,
              "I2NSF NSF Monitoring YANG Data Model", draft-ietf-i2nsf-
              nsf-monitoring-data-model-01 (work in progress), July
              2019.

Jeong, et al.           Expires January 25, 2020               [Page 21]
Internet-Draft             I2NSF Applicability                 July 2019

   [opsawg-firewalls]
              Baker, F. and P. Hoffman, "On Firewalls in Internet
              Security", draft-ietf-opsawg-firewalls-01 (work in
              progress), October 2012.

   [policy-translation]
              Jeong, J., Yang, J., Chung, C., and J. Kim, "Security
              Policy Translation in Interface to Network Security
              Functions", draft-yang-i2nsf-security-policy-
              translation-04 (work in progress), July 2019.

   [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-05 (work in progress), July
              2019.

   [tls-esni]
              Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
              "Encrypted Server Name Indication for TLS 1.3", draft-
              ietf-tls-esni-04 (work in progress), July 2019.

   [VNF-ONBOARDING]
              "VNF Onboarding", Available:
              https://wiki.opnfv.org/display/mano/VNF+Onboarding,
              November 2016.

Jeong, et al.           Expires January 25, 2020               [Page 22]
Internet-Draft             I2NSF Applicability                 July 2019

Appendix A.  Changes from draft-ietf-i2nsf-applicability-14

   The following changes have been made from draft-ietf-i2nsf-
   applicability-14:

   o  In Section 4, to handle HTTP-session packets using TLS in web
      filtering, it is clarified that the Server Name Indication (SNI)
      can be used to detect a website's URL if the SNI field is not
      encryped in TLS versions without the encrypted SNI.

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

   Phone: +82 31 299 4957
   Fax:   +82 31 290 7996
   EMail: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php

   Sangwon Hyun
   Department of Computer Engineering
   Chosun University
   309 Pilmun-daero, Dong-Gu
   Gwangju  61452
   Republic of Korea

   Phone: +82 62 230 7473
   EMail: shyun@chosun.ac.kr

   Tae-Jin Ahn
   Korea Telecom
   70 Yuseong-Ro, Yuseong-Gu
   Daejeon  305-811
   Republic of Korea

   Phone: +82 42 870 8409
   EMail: taejin.ahn@kt.com

Jeong, et al.           Expires January 25, 2020               [Page 23]
Internet-Draft             I2NSF Applicability                 July 2019

   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Phone: +1-734-604-0332
   EMail: shares@ndzh.com

   Diego R. Lopez
   Telefonica I+D
   Jose Manuel Lara, 9
   Seville  41013
   Spain

   Phone: +34 682 051 091
   EMail: diego.r.lopez@telefonica.com

Jeong, et al.           Expires January 25, 2020               [Page 24]