I2NSF Security Controller-Facing Interface YANG Data Model for Cross-Domain IPsec Flow Protection
Department of Computer Science and Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957jeonghyeon12@skku.edu
Department of Computer Science and Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957+82 31 290 7996pauljeong@skku.eduhttp://iotlab.skku.edu/people-jaehoon-jeong.php
Department of Electrical and Computer Engineering
Sungkyunkwan University2066 Seobu-Ro, Jangan-GuSuwonGyeonggi-Do16419Republic of Korea+82 31 299 4957patricklink@skku.edu
Huawei
7453 Hickory HillSalineMI48176USA+1-734-604-0332shares@ndzh.comUniversity of MurciaFaculty of Computer ScienceCampus de Espinardo S/NMurcia30100Spain+34 868 88 85 01rafa@um.es
Security
I2NSF Working GroupInternet-Draft
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).
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. .
To support multiple security services for a traffic flow with multiple
NSFs, a Service Function Chaining (SFC) can be
used. In SFC, the integrity and confidentiality of security services between the NSFs
must be guaranteed. 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 ,
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
. 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
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.
| Controller B| |
| | | |Interface| | | |
| +------+------+ | | +------+------+ |
| ^ | | ^ |
| | | | | |
| +---------+------+ | | +--------+-------+ |
| | | | | | | |
| v v | | v v |
| +---+---+ +---+---+ | IPsec | +---+---+ +---+---+ |
| | NSF-1 | | NSF-2 |==================| NSF-3 | | NSF-4 | |
| +---+---+ +---+---+ | | +---+---+ +---+---+ |
+--------------------------------+ +-------------------------------+
]]>
show the conceptual architecture of
I2NSF framework for Cross-Domain IPsec flow protection. As shown in ,
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 , 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.
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:
Low-level Security Policy : A low-level security policy to configure NSFs located in a cross-domain environment.
The low-level security policy means the translated security policy that the security administrator wants to configure,
such as blocking the SNS website, and flow protection between NSFs A and B.
The security controller can deliver the low-level security policy to the security controllers
other I2NSF domains through SFI. After receiving the security policy, the security controller
can deliver the security policy to the target NSFs via the NSF-Facing Interface .
IPsec Parameters: Parameters required to establish IPsec Security Associations (SAs) . 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.
| |
| | 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 |
|<==================================================================>|
]]>
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:
I2NSF A's administrator requests a security service that cannot be addressed by only the NSFs located in
their own I2NSF domain.
Security Controller A delivers the security policy for NSF2 through SFI to Security Controller B
in a cross-domain environment.
If Security Controller B can handle the received security policy, reply OK message to Security Controller A.
Security Controller B delivers the security policy to NSF2 for checking that NSF2 can be configured by the sent policy.
Security Controller A deliver the translated security policy for NSF1.
If NSF2 can handle the received security policy, it replies OK message to Security Controller B.
If NSF1 can handle the received security policy, it replies OK message to Security Controller A.
NSF1 and NSF2 negotiate IPsec parameters through Security Controller A and Security Controller B.
NSF1 and NSF2 establish IPsec SAs using the received IPsec parameters and provide the
requested security service to the user through SFC.
| | |
| | | 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
]]>
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:
I2NSF A's administrator requests a security service that cannot be addressed only by the NSFs located in its
own I2NSF domain.
The secondary Security Controller A delivers the translated security policy through SFI to the primary Security Controller.
If the primary Security Controller knows which secondary Security
Controller can handle the delivered security policy, the primary
Security Controller sends an OK message to Security Controller A.
The primary Security Controller delivers the received security policy
to the secondary Security Controller that can provide the requested
security services, i.e., the secondary Security Controller B.
The secondary Security Controller A delivers the translated security
policy to NSF1 via NFI.
The secondary Security Controller B delivers the received security
policy to NSF2 via NFI.
If NSF2 can handle the received security policy, it replies OK
message to the secondary Security Controller B.
If NSF1 can handle the received security policy, it replies OK
message to the secondary Security Controller A.
The secondary Security Controller B delivers NSF2's reply OK message
to the primary Security Controller.
The secondary Security Controller A delivers NSF1's reply OK message
to the primary Security Controller.
Security Controller A and Security Controller B negotiate IPsec parameters
through the primary Security Controller.
NSF1 and NSF2 establish IPsec SAs using the received IPsec parameters
and provide the requested security service to the user through SFC.
TBD
This document does not require any IANA actions.
The same security considerations for the I2NSF framework
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:
Electronics and Telecommunications Research Institute218 Gajeong-Ro, Yuseong-GuDaejeon34129Republic of Koreapjs@etri.re.krElectronics and Telecommunications Research Institute218 Gajeong-Ro, Yuseong-GuDaejeon34129Republic of Koreacyc79@etri.re.krUniversity of MurciaFaculty of Computer ScienceCampus de Espinardo S/NMurcia30100Spaingabilm@um.esUniversity Defense CenterSpanish Air Force AcademySan Javier MurciaMurcia30720Spainfernando.pereniguez@cud.upct.es
The following changes are made from draft-kim-i2nsf-security-controller-interface-dm-00:
This version has been revised with Rafa Marin-Lopez's comments.