I2NSF Security Controller-Facing Interface YANG Data Model for Cross-Domain IPsec Flow Protection
draft-kim-i2nsf-security-controller-interface-dm-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jeonghyeon Kim , Jaehoon Paul Jeong , Patrick Lingga , Susan Hares , Rafael Marin-Lopez | ||
| Last updated | 2022-10-24 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kim-i2nsf-security-controller-interface-dm-00
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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,
<https://www.rfc-editor.org/info/rfc8329>.
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,
<https://www.rfc-editor.org/info/rfc9061>.
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,
<https://www.ietf.org/archive/id/draft-ietf-i2nsf-nsf-
facing-interface-dm-29.txt>.
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]