I2NSF Working Group J. Kim Internet-Draft J. Jeong, Ed. Intended status: Standards Track P. Lingga Expires: 27 April 2023 Sungkyunkwan University S. Hares Huawei R. Marin-Lopez University of Murcia 24 October 2022 I2NSF Security Controller-Facing Interface YANG Data Model for Cross- Domain IPsec Flow Protection draft-kim-i2nsf-security-controller-interface-dm-00 Abstract This document defines an information model and a YANG data model for the Security Controller-Facing Interface between two security controllers in an Interface to Network Security Functions (I2NSF) framework. This interface is used for the exchange of IPsec flow protection information between two Network Security Functions (NSFs) in cross-domain environments. The YANG data model in this document is built on the basis of the YANG data model for IPsec flow protection based on Software-Defined Networking (SDN). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 27 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Kim, et al. Expires 27 April 2023 [Page 1] Internet-Draft Security Controller-Facing Interface October 2022 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Information Model for Security Controller-Facing Interface . 5 3.1. Use Cases for the Security Controller-Facing Interface in Cross-Domain Environments . . . . . . . . . . . . . . . . 6 3.1.1. Use Case of Peer-to-Peer Security Controllers . . . . 6 3.1.2. Use Case of Hierarchical Distribution Security Controllers . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Interface to Network Security Functions (I2NSF) defines a framework and its interfaces for the security management and monitoring of Network Security Functions (NSFs) for security services. The NSFs are manufactured by different vendors [RFC8329]. I2NSF allows users to easily configure security policies on a target network. In an I2NSF framework, NSFs are network functions that are used to defend a target network against various security attacks such as Distributed Denial of Service (DDoS) attacks, viruses, and data breaches. Kim, et al. Expires 27 April 2023 [Page 2] Internet-Draft Security Controller-Facing Interface October 2022 To support multiple security services for a traffic flow with multiple NSFs, a Service Function Chaining (SFC) [RFC7665] can be used. In SFC, the integrity and confidentiality of security services between the NSFs must be guaranteed. [RFC9061] protects the flow between NSFs with a centralized security controller by generating, managing, and distributing the keys of NSFs. Flow protection covered in this document describes the flow protection and key management process (i.e., IKE case and IKE-less case) between NSFs within the coverage of I2NSF managed by one security controller, i.e., within one I2NSF domain (e.g., an autonomous system (AS)). However, recently, the concept of Software-Defined Wide Area Network (SD-WAN) was introduced to manage multiple SDN infrastructures. The goal of SD-WANs is to provide flexible and automated deployment from a centralized point to enable on-demand network security services, such as IPsec Security Association (SA) management [RFC9061]. To meet this goal of SD-WAN, a centralized point that can manage multiple I2NSF domains is needed. In addition, it was necessary to introduce a new interface for centralized management of NSFs existing on different I2NSF domains, i.e., a cross-domain environment (multiple ASs). Also, flow protection for collaboration and exchanging information between NSFs located in different I2NSF domains are needed in such cross-domain environments. In order to manage controllers in different I2NSF domains together, an interface that can exchange information (security policies, IPsec parameters) between security controllers in cross-domain environments for flow protection between NSFs located in different I2NSF domains and policy delivery is essential. Therefore, this document proposes an information model and a YANG data model for a Security Controller-Facing Iterface for exchanging information between security controllers to manage the security policy and flow protection among NSFs in cross-domain environments. Kim, et al. Expires 27 April 2023 [Page 3] Internet-Draft Security Controller-Facing Interface October 2022 I2NSF Domain A I2NSF Domain B +--------------------------------+ +-------------------------------+ | +-------------+ | | +-------------+ | | | Security | Security Controller Facing | Security | | | | Controller A|<-------------------------->| Controller B| | | | (Primary) | |Interface| | (Secondary) | | | +------+------+ | | +------+------+ | | ^ | | ^ | | | | | | | | +---------+--------+ | | +--------+-------+ | | | | | | | | | | v v | | v v | | +---+---+ +---+---+ | IPsec | +---+---+ +---+---+ | | | NSF-1 | | NSF-2 |==================| NSF-3 | | NSF-4 | | | +---+---+ +---+---+ | | +---+---+ +---+---+ | +--------------------------------+ +-------------------------------+ Figure 1: I2NSF Framework for Cross-Domain IPsec Flow Protection Figure 1 illustrates two I2NSF systems located in different I2NSF domains. To let NSFs of different I2NSF systems, which have their own security controller, communicate with each other, a security controller can be used as the intermediary. Two security controllers in different domains MUST have a secure and trust connection, this connection is out of the scope of this document. Through this secure connection, the security controller, which is a primary as a coordinator for other security controllers, can receive the IPsec parameters of secondary security controllers and can establish IPsec SA with secondary security controllers. The primary security controller can act as a centralized controller and can exchange information about managed NSFs safely through the Security Controller-Facing Interface (SFI) with all connected security controllers as secondaries. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. I2NSF Domain: An area that one I2NSF security controller can manage the security services of all the flows in its domain. Kim, et al. Expires 27 April 2023 [Page 4] Internet-Draft Security Controller-Facing Interface October 2022 Cross-Domain: An environment where multiple I2NSF domains (e.g., ASs) exist and are able to exchange information among the security controllers. 3. Information Model for Security Controller-Facing Interface In [RFC9061], the I2NSF security controller enables the key management procedure to be performed for flow protection between NSFs in an I2NSF domain it manages. Therefore, this section introduces the information model for exchanging information in different domains using Security Controller-Facing Interface (SFI) between I2NSF Security Controllers to provide flow protection between NSFs existing in different I2NSF domains. +-----------------+ | Security | |Controller-Facing| | Interface | +--------+--------+ ^ | +-------+------+ | Flow | | Protection | +-------+------+ | +--------+--------+ | | +------+------+ +-----+------+ | Security | | Flow | | Policy | | Protection | | Information | | Parameter | +-------------+ +------------+ Figure 2: Diagram for Security Controller-Facing Interface Figure 1 shows the high-level concept of SFI to deliver cross-domain flow protection for IPsec. Information that can be delivered through SFI is as follows: * Flow Protection Parameters: Parameters required to establish IPsec Security Associations (SAs) [RFC9061]. To establish IPsec SAs with NSFs located in a different domain, the security controller MUST be able to securely exchange the necessary parameters for those SAs. Kim, et al. Expires 27 April 2023 [Page 5] Internet-Draft Security Controller-Facing Interface October 2022 * Security Policy Information: Security policy information to configure the security policy rules [I-D.ietf-i2nsf-nsf-facing-interface-dm] of NSFs located in a cross-domain environment. The security controller can deliver the security policy rules to the other I2NSF domains security controller through SFI. After receiving the security policy, the security controller can deliver the security policy to the target NSFs via the NSF-Facing Interface [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 3.1. Use Cases for the Security Controller-Facing Interface in Cross- Domain Environments 3.1.1. Use Case of Peer-to-Peer Security Controllers +------+ +------------+ +------------+ +------+ | NSF1 | | Security | | Security | | NSF2 | | | |Controller A| |Controller B| | | +--+---+ +------+-----+ +------+-----+ +-----++ | |1.NSF2's Security Policy| | | |----------------------->| 2.Security Policy | | | |------------------->| | | | | | | | | | 3.Security Policy | | | |<-------------------| | | | | | | | | 4.IPsec Parameters | | | |----------------------->| | | | | | | |<-----------------------| | | | 5.IPsec Parameters | | | 6.IPsec Parameters | | 6.IPsec Parameters | |<-------------------| |------------------->| | 7.Service Function Chaining with IPsec SAs | |<================================================================>| Figure 3: Use Case of the Peer-to-Peer Security Controllers Kim, et al. Expires 27 April 2023 [Page 6] Internet-Draft Security Controller-Facing Interface October 2022 Figure 3 shows a message sequence between entities in multiple domains. In the case where an I2NSF user requests a security service that cannot be provided by the NSFs (e.g., BGP peers) in its own I2NSF domain, the security controller may request a trusted security controller in a different I2NSF domain for the required security service. In this scenario, it is assumed that the secure connection between the two security controllers is already set. The detailed sequence is as follows: 1. Security controller A delivers the security policy for NSF2 through SCFI via security controller B in a cross-domain environment. 2. If security controller B can handle the received security policy, it delivers the security policy to the target NSF, i.e., NSF2, through the NFI. 3. Security controller A also delivers the security policy for the NSF in its own I2NSF domain that can handle the security policy, i.e., NSF1, through the NFI. 4. Security controller A delivers IPsec parameters for NSF2 to establish IPsec SAs with NSF1 located in a cross-domain environment to security controller B. 5. Security controller B delivers IPsec parameters for NSF1 to establish IPsec SAs with NSF2 located in a cross-domain environment to security controller A. 6. Security controller A and security controller B deliver the IPsec parameters to the NSF1 and NSF2, respectively. 7. NSF1 and NSF2 establish an IPsec SAs using the received IPsec parameters and provide the requested security service to the user through SFC. 3.1.2. Use Case of Hierarchical Distribution Security Controllers Kim, et al. Expires 27 April 2023 [Page 7] Internet-Draft Security Controller-Facing Interface October 2022 +------+ +------------+ +------------+ +------------+ +------+ | | | | | Primary | | | | | | NSF1 | | Security | | Security | | Security | | NSF2 | | | |Controller A| | Controller | |Controller B| | | ++-----+ +-----+------+ +-----+------+ +-----+------+ +-----++ | 1.Security |1. Security | | | |<---------------|--------------->| | | | Policy for NSF1|Policy for NSF2 | | | | | |2. Security | | | | |--------------->| | | | |Policy for NSF2 | | | | | | 3. Security | | | | |---------------->| | | | | Policy for NSF2 | | |4.IPsec |4.IPsec | | | |<---------------|--------------->| | | | Parameter | Parameter | | |5.IPsec | | | 5. IPsec | |<---------------| | |---------------->| | Parameter | | | Parameter | | | | | | |<==================================================================>| 6.Service Function Chaining with IPsec SAs Figure 4: Use Case of the Hierarchical Distribution Security Controllers Figure 4 shows a message sequence between entities in multiple domains with a primary security controller. In the case where an I2NSF user requests a security service that the NSFs cannot be provided in its I2NSF domain, the security controller may request the primary security controller for the required security service. In this scenario, it is assumed that the secure connections between the security controllers and the primary security controller are already set. Also, it is assumed that the primary security controller has all the necessary IPsec parameters in advance. The detailed sequence is as follows: 1. Security controller A delivers the security policy through SFI to the primary security controller and delivers the security policy to NSF1 via NFI. 2. The primary security controller delivers the received security policy to the security controller that can provide the requested security services, i.e., security controller B. Kim, et al. Expires 27 April 2023 [Page 8] Internet-Draft Security Controller-Facing Interface October 2022 3. Security controller B delivers the security policy it can handle to the target NSF, i.e, NSF2, through the NFI. 4. The primary security controller delivers the IPsec parameters to establish IPsec SAs between NSF1 and NSF2 located in different I2NSF domains to the responsible security controllers. 5. Security controller A and security controller B deliver the IPsec parameters to the NSF1 and NSF2, respectively. 6. NSF1 and NSF2 establish an IPsec SAs using the received IPsec parameters and provide the requested security service to the user through SFC. 4. IANA Considerations This document does not require any IANA actions. 5. Security Considerations The same security considerations for the I2NSF framework [RFC8329] are applicable to this document. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. Kumar, "Framework for Interface to Network Security Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, . Kim, et al. Expires 27 April 2023 [Page 9] Internet-Draft Security Controller-Facing Interface October 2022 [RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez- Garcia, "A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)", RFC 9061, DOI 10.17487/RFC9061, July 2021, . 6.2. Informative References [I-D.ietf-i2nsf-nsf-facing-interface-dm] Kim, J. T., Jeong, J. P., Park, J., Hares, S., and Q. Lin, "I2NSF Network Security Function-Facing Interface YANG Data Model", Work in Progress, Internet-Draft, draft-ietf- i2nsf-nsf-facing-interface-dm-29, 1 June 2022, . Appendix A. Acknowledgments This work was supported by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT)(No. 2022-0-01015, Development of Candidate Element Technology for Intelligent 6G Mobile Core Network). This work was supported in part by Institute of Information & Communications Technology Planning & Evaluation (IITP) grant funded by the Korea Ministry of Science and ICT (MSIT)(No. 2022-0-01199, Regional strategic industry convergence security core talent training business). Appendix B. Contributors This document is made by the group effort of I2NSF WG. Many people actively contributed to this document, such as Linda Dunbar, Yoav Nir, and Diego R. Lopez. The authors sincerely appreciate their contributions. The following are co-authors of this document: Jiyong Uhm - Department of Computer Science and Engineering, Sungkyunkwan University, 2066 Seobu-Ro Jangan-Gu, Suwon, Gyeonggi-do 16419, Republic of Korea. EMail: jiyong423@skku.edu Jung-Soo Park - Electronics and Telecommunications Research Institute, 218 Gajeong-Ro, Yuseong-Gu, Daejeon, 34129, Republic of Korea. EMail: pjs@etri.re.kr Kim, et al. Expires 27 April 2023 [Page 10] Internet-Draft Security Controller-Facing Interface October 2022 Yunchul Choi - Electronics and Telecommunications Research Institute, 218 Gajeong-Ro, Yuseong-Gu, Daejeon, 34129, Republic of Korea. EMail: cyc79@etri.re.kr Gabriel Lopez-Millan - University of Murcia, Faculty of Computer Science, Campus de Espinardo S/N, 30100 Murcia, Spain. Phone: +34 868 88 85 04, EMail: gabilm@um.es Fernando Pereniguez-Garcia - University Defense Center, Spanish Air Force Academy, MDE-UPCT, 30720 San Javier Murcia, Spain. Phone: +34 968 18 99 46, EMail: fernando.pereniguez@cud.upct.es Authors' Addresses Jeonghyeon Joshua Kim 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 Email: jeonghyeon12@skku.edu Jaehoon Paul Jeong (editor) 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 Email: pauljeong@skku.edu URI: http://iotlab.skku.edu/people-jaehoon-jeong.php Patrick Lingga Department of Electrical and Computer Engineering Sungkyunkwan University 2066 Seobu-Ro, Jangan-Gu Suwon Gyeonggi-Do 16419 Republic of Korea Phone: +82 31 299 4957 Kim, et al. Expires 27 April 2023 [Page 11] Internet-Draft Security Controller-Facing Interface October 2022 Email: patricklink@skku.edu Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 United States of America Phone: +1-734-604-0332 Email: shares@ndzh.com Rafa Marin-Lopez University of Murcia Faculty of Computer Science Campus de Espinardo S/N 30100 Murcia Spain Phone: +34 868 88 85 01 Email: rafa@um.es Kim, et al. Expires 27 April 2023 [Page 12]