| Internet-Draft | Security Controller-Facing Interface | March 2023 |
| Kim, et al. | Expires 29 September 2023 | [Page] |
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 located in different Domains. This interface is used for the exchange of IPsec flow protection to protect the IP Communication 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).¶
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 29 September 2023.¶
Copyright (c) 2023 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 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.¶
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. [RFC8329].¶
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 under the control of the same I2NSF security controller. The security controller is in charge of generating, managing and distributing the IPsec Security Associations. This document describes the flow protection and key management process (i.e., IKE case and IKE-less case) between two 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, as described in [I-D.ietf-bess-bgp-sdwan-usage], multiple Software-Defined WANs (SD-WANs) scenarios demand a centralized way of flow protection using IPsec between SD-WAN peers(NSFs). In the scenarios, some SD-WAN peers that are located in different spaces (virtual or physical) are connected only by untrusted public networks.¶
Therefore, to ensure secure communication between NSFs located in different SD-WANs over untrusted public networks, flow protection is required. Additionally, an interface for exchanging information (e.g., security policies and IPsec parameters) between different SD-WANs is necessary.¶
In response to these requirements, I2NSF needs to extend by using [RFC9061]. The I2NSF security controller needs to extend to centrally manage multiple I2NSFs that are located in different domains, and needs to extend to exchange information between two I2NSFs located in two different domains.¶
To extend I2NSF, a centralized point that can manage multiple I2NSF domains is needed. It is necessary to introduce a new interface for centralized management and exchanging information between NSFs located in different I2NSF domains, i.e., a cross-domain environment with multiple ASes.¶
Therefore, this document proposes an information model and a YANG data model for a Security Controller-Facing Interface (SFI) for exchanging information (e.g., security policies and IPsec parameters) between security controllers. This interface performs the exchange of a security policy and provides flow protection among NSFs located in cross-domain environments. This document suggests two scenarios of configuration between peer-to-peer security controller cases (see Section 5.1.) and configuration in hierarchical security controller cases (see Section 5.2.).¶
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 an I2NSF security controller can manage.¶
Security Contorller-Facing Interface (SFI): An interface for the exchange of information between two security controllers located in two different I2NSF domains.¶
I2NSF Domain A I2NSF Domain B
+--------------------------------+ +-------------------------------+
| +-------------+ | | +-------------+ |
| | Security | Security Controller-Facing | Security | |
| | Controller A|<-------------------------->| Controller B| |
| | | |Interface| | | |
| +------+------+ | | +------+------+ |
| ^ | | ^ |
| | | | | |
| +---------+------+ | | +--------+-------+ |
| | | | | | | |
| v v | | v v |
| +---+---+ +---+---+ | IPsec | +---+---+ +---+---+ |
| | NSF-1 | | NSF-2 |==================| NSF-3 | | NSF-4 | |
| +---+---+ +---+---+ | | +---+---+ +---+---+ |
+--------------------------------+ +-------------------------------+
Figure 1 show the conceptual architecture of I2NSF framework for Cross-Domain IPsec flow protection. As shown in Figure 1, the two I2NSF security controllers located in different I2NSF domains, i.e., I2NSF Domains A and B. In one domain, the security controller only can manage NSFs registered by the Developer's Management System (DMS). Therefore, the security controller is not aware of the existence of NSFs in other domains. To enable communication between NSFs located in different I2NSF domains, each with its own security controller, a security controller can be used as an intermediary. The two security controllers in different domains MUST have a secure and trusted connection; the setup of this connection is out of the scope of this document. Through this secure connection, the security controllers can exchange the IPsec parameters using SFI and configure the NSFs located in different I2NSF domains so that they can establish IPsec SAs to protect data traffic between them.¶
In [RFC9061], the I2NSF security controller enables the key management for flow protection between NSFs in the I2NSF domain that it manages. Therefore, this section introduces the information model for exchanging information in different domains using Security Controller-Facing Interface (called SFI) between I2NSF Security Controllers to provide flow protection between NSFs existing in different I2NSF domains.¶
+-----------------+
| Security |
|Controller-Facing|
| Interface |
+--------+--------+
^
|
|
+--------+--------+
| |
+------+------+ +-----+------+
| Low-level | | |
| Security | | IPsec |
| Policy | | Parameters |
+-------------+ +------------+
Figure 2 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:¶
1.Security Policy
|
+------+ +------V-----+ +------------+ +------+
| NSF1 | | Security | | Security | | NSF2 |
| | |Controller A| |Controller B| | |
+--+---+ +------+-----+ +------+-----+ +-----++
| | 2.Deliver translated | |
| | Security Policy | |
| |----------------------->| |
| | 3. Reply OK | |
| |<-----------------------|4. Deliver Translated|
| | | Security Policy |
|5.Deliver translated | |-------------------->|
| Security Policy | | |
|<--------------------| | 6. Reply OK |
| 7. Reply OK | |<--------------------|
|-------------------->| | |
| 8.IPsec Parameter Negotiation |
|<--------------------|<---------------------->|-------------------->|
| | | |
| | | |
| 9.Service Function Chaining with IPsec SAs |
|<==================================================================>|
Figure 3 shows the peer-to-peer security controller use case's message sequence between entities in multiple domains. In this use case, an I2NSF A's administrator requests a security service that cannot address by only the NSFs located in their own I2NSF domain. The security controller A can request to cooperate with a trusted peer security controller B 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 up. The detailed sequence is as follows:¶
1.Security Policy
|
+------+ +-----V------+ +------------+ +------------+ +------+
| | | Secondary | | Primary | | Secondary | | |
| NSF1 | | Security | | Security | | Security | | NSF2 |
| | |Controller A| | Controller | |Controller B| | |
++-----+ +-----+------+ +-----+------+ +-----+------+ +-----++
| | 2.Deliver | | |
| | translated | | |
| | Security Policy| | |
| |--------------->| | |
| | | 4.Deliver | |
| | 3. Reply OK | translated | |
| 5.Deliver |<---------------|Security Policy | |
| translated | |--------------->| 6.Deliver |
| Security Policy| | | translated |
|<---------------| | |Security Policy |
| | | |---------------->|
| 8. Reply OK | | | 7. Reply OK |
|--------------->| | |<----------------|
| | | 9. Reply OK | |
| | 10. Reply OK >|<---------------| |
| |--------------->| | |
| | 11.IPsec Parameter Negotiation | |
|<---------------|<------------------------------->|---------------->|
| | | | |
| | | | |
|<==================================================================>|
12.Service Function Chaining with IPsec SAs
Figure 4 shows a message sequence between entities in multiple domains with a primary Security Controller. The primary Security Controller can act as a centralized controller. The primary Security Controller between secondary Security Controllers has a secure connection in advance. How to establish this secure connection is out of the scope of this document. Using this secure connection, the primary Security Controller collects all of the secondary Security Controller's information via SFI. In this usecase, when the administrator of an I2NSF A requests a security service that is not available in its own I2NSF domain, then the secondary Security Controller A, with the help of the primary Security Controller, can collaborate with a trusted peer Security Controller B from a different I2NSF domain to obtain the required security service. The detailed sequence is as follows:¶
This document does not require any IANA actions.¶
The same security considerations for the I2NSF framework [RFC8329] are applicable to this document.¶
This work was supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government, Ministry of Science and ICT (MSIT) (No. 2023R1A2C2002990).¶
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-01015, Development of Candidate Element Technology for Intelligent 6G Mobile Core Network).¶
The following are coauthors of this document:¶
The following changes are made from draft-kim-i2nsf-security-controller-interface-dm-00:¶