idnits 2.17.1 draft-jeong-i2nsf-security-management-automation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2020) is 1271 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-31) exists of draft-ietf-i2nsf-consumer-facing-interface-dm-12 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-10 == Outdated reference: A later version (-20) exists of draft-ietf-i2nsf-nsf-monitoring-data-model-04 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-09 == Outdated reference: A later version (-09) exists of draft-irtf-nmrg-ibn-concepts-definitions-02 == Outdated reference: A later version (-16) exists of draft-yang-i2nsf-security-policy-translation-06 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Jeong 3 Internet-Draft P. Lingga 4 Intended status: Informational Sungkyunkwan University 5 Expires: May 6, 2021 J. Park 6 ETRI 7 November 2, 2020 9 An Extension of I2NSF Framework for Security Management Automation in 10 Cloud-Based Security Services 11 draft-jeong-i2nsf-security-management-automation-00 13 Abstract 15 This document describes an extension of the framework of Interface to 16 Network Security Functions (I2NSF) for Security Management Automation 17 (SMA) in cloud-based security services. The security management 18 automation in this document deals with a security polity translation 19 and a feedback-based security service enforcement. To support these 20 two features in SMA, this document specifies an augmented 21 architecture of the I2NSF framework with a new system component and a 22 new interface. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 6, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. I2NSF Framework for Security Management Automation . . . . . 4 61 3.1. Components with I2NSF Framework for Security Management 62 Automation . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Interfaces with SMA-Based I2NSF Framework . . . . . . . . 5 64 4. Inter-Interface Automatic Policy Mapping . . . . . . . . . . 6 65 5. Security System Audit . . . . . . . . . . . . . . . . . . . . 9 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 8.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 72 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 Interface to Network Security Functions (I2NSF) defines a framework 78 and interfaces for interacting with Network Security Functions (NSFs) 79 [RFC8192][RFC8329]. Note that an NSF is defined as software that 80 provides a set of security-related services, such as (i) detecting 81 unwanted activity, (ii) blocking or mitigating the effect of such 82 unwanted activity in order to fulfill service requirements, and (iii) 83 supporting communication stream integrity and confidentiality 84 [RFC8329]. The NSF can be implemented as a Virtual Network Function 85 (VNF) in a Network Functions Virtualization (NFV) environment 86 [ETSI-NFV][I-D.ietf-i2nsf-applicability]. 88 This document describes an extension of the framework of Interface to 89 Network Security Functions (I2NSF) for Security Management Automation 90 (SMA) in cloud-based security services. The security management 91 automation includes a security polity translation and a feedback- 92 based security service enforcement. This document specifies an 93 augmented architecture of the I2NSF framework for the SMA services 94 with a new system component and a new interface. 96 For reliable management for networked security services, this 97 document proposes a network management and verification facility 98 using a decentralized audit system (e.g., blockchain [Bitcoin]). 99 This audit system can facilitate the non-repudiation of configuration 100 commands and monitoring data generated in the I2NSF framework. 102 Therefore, with the security service automation, this document 103 facilitates the foundation of Intent-Based Networking (IBN) for 104 intelligent security services 105 [I-D.irtf-nmrg-ibn-concepts-definitions]. 107 2. Terminology 109 This document uses the terminology described in [RFC8329] and 110 [I-D.ietf-i2nsf-applicability]. In addition, the following terms are 111 defined below: 113 o Security Management Automation (SMA): It means that a high-level 114 security policy from a user (or administrator) is well-enforced in 115 a target I2NSF system. The high-level security policy can be 116 translated into the corresponding low-level security policy by a 117 security policy translator and dispatched to appropriate NSFs. 118 Through the monitoring of the NSFs, the activity and performace of 119 the NSFs is monitored and analyzed. If needed, the security rules 120 of the low-level security policy are augmented or new security 121 rules are generated and configured to appropriate NSFs. 123 o Security Policy Translation (SPT): It means that a high-level 124 security policy is translated to a low-level security policy that 125 can be understood and configured by an NSF for a specific security 126 service, such as firewall, web filter, deep packet inspection, 127 DDoS-attack mitigation, and anti-virus. 129 o Feedback-Based Security Management (FSM): It means that a security 130 service is evolved by updating a security policy (having security 131 rules) and adding new security rules for detected security attacks 132 by processing and analzing the monitoring data of NSFs. 134 +------------+ 135 | I2NSF User | 136 +------------+ 137 ^ 138 | Consumer-Facing Interface 139 v 140 +-------------------+ Registration +-----------------------+ 141 |Security Controller|<-------------------->|Developer's Mgmt System| 142 +-------------------+ Interface +-----------------------+ 143 ^ ^ 144 | | 145 | | Application Interface +-----------------------+ 146 | +------------------------>| I2NSF Analyzer | 147 | +-----------------------+ 148 | NSF-Facing Interface ^ ^ ^ 149 | | | | 150 | | | | 151 | +------------------------------+ | | 152 | | +-----------------------+ | 153 | | | Monitoring Interface | 154 v v v v 155 +----------------+ +---------------+ +-----------------------+ 156 | NSF-1 |-| NSF-2 |...| NSF-n | 157 | (Firewall) | | (Web Filter) | |(DDoS-Attack Mitigator)| 158 +----------------+ +---------------+ +-----------------------+ 160 Figure 1: I2NSF Framework for Security Management Automation 162 3. I2NSF Framework for Security Management Automation 164 This section summarizes the I2NSF framework as defined in [RFC8329]. 165 As shown in Figure 1, an I2NSF User can use security functions by 166 delivering high-level security policies, which specify security 167 requirements that the I2NSF user wants to enforce, to the Security 168 Controller via the Consumer-Facing Interface (CFI) 169 [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 171 3.1. Components with I2NSF Framework for Security Management Automation 173 The following are the system components for the SMA-based I2NSF 174 framework. 176 o I2NSF User: An entity that delivers a high-level security policy 177 to Security Controller. 179 o Security Controller: An entity that controls and manages other 180 system components in the I2NSF framework. It translates a high- 181 level security policy into the corresponding low-level security 182 policy and selects appropriate NSFs to execute the security rules 183 of the low-level security policy. 185 o Developer's Management System (DMS): An entity that provides an 186 image of of a virtualized NSF for a security service to the I2NSF 187 framework, and registers the capability and access information of 188 an NSF with Security Controller. 190 o Network Security Function (NSF): An entity that is a Virtual 191 Network Function (VNF) for a specific network security service 192 such as firewall, web filter, deep packet inspection, DDoS-attack 193 mitigation, and anti-virus. 195 o I2NSF Analyzer: An entity that collects monitoring data from NSFs 196 and analyzes such data for checking the activity and performance 197 of the NSFs using machine learning techniques (e.g., Deep Learning 198 [Deep-Learning]). If there is a suspicious attack activity for 199 the target network or NSF, I2NSF Analyzer delivers a report of the 200 augmentation or generation of secuity rules to Security 201 Controller. 203 For SMA-based security services with Feedback-Based Security 204 Management (FSM), I2NSF Analyzer as a new I2NSF component is required 205 for the legacy I2NSF framework [RFC8329] to collect monitoring data 206 of NSFs and analyzing them. 208 3.2. Interfaces with SMA-Based I2NSF Framework 210 The following are the interfaces for the SMA-based I2NSF framework. 211 Note that the interfaces are modeled with YANG [RFC6020] and security 212 policies are delivered through either RESTCONF [RFC8040] or NETCONF 213 [RFC6241]. 215 o Consumer-Facing Interface: An interface between I2NSF User and 216 Security Controller for the delivery of a high-level security 217 policy [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 219 o NSF-Facing Interface: An interface between Security Controller and 220 an NSF for the delivery of a low-level security policy 221 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 223 o Registration Interface: An interface between a DMS and Security 224 Controller for the registration of an NSF's capability and access 225 information with Secutiy Controller or the query of an NSF for a 226 required low-level security policy 227 [I-D.ietf-i2nsf-registration-interface-dm]. 229 o Monitoring Interface: An interface between an NSF and I2NSF 230 Analyzer for collecting monitoring data from an NSF to check the 231 activity and performance of an NSF for a possible malicious 232 traffic [I-D.ietf-i2nsf-nsf-monitoring-data-model]. 234 o Application Interface: An interface between I2NSF Analyzer and 235 Security Controller for the delivery of a report of the 236 augmentation or generation of secuity rules to Security 237 Controller, and let Security Controller apply it to its security 238 policy management. 240 For SMA-based security services with FSM, Application Interface as a 241 new I2NSF interface is required for the legacy I2NSF framework 242 [RFC8329] to deliver a report of the augmentation or generation of 243 secuity rules to Security Controller on the basis of the analyzed 244 monitoring data of NSFs. 246 4. Inter-Interface Automatic Policy Mapping 248 To facilitate Security Policy Translation (SPT), Security Controller 249 needs to have a security policy translator that performs the 250 translation of a high-level security policy into the corresponding 251 low-level security policy. For the automatic SPT services, the I2NSF 252 framework needs to bridge a high-level YANG data model and a low- 253 level YANG data model in an automatic manner [I-D.ietf-i2nsf-applicab 254 ility][I-D.yang-i2nsf-security-policy-translation]. Note that a 255 high-level YANG data model is for the I2NSF Consumer-Facing Interface 256 [I-D.ietf-i2nsf-consumer-facing-interface-dm], and a low-level YANG 257 data model is for the I2NSF NSF-Facing Interface 258 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 260 Figure 2 shows automatic mapping of high-level and low-level data 261 models. Automatic Data Model Mapper takes a high-level YANG data 262 module for the Consumer-Facing Inteface and a low-level YANG data 263 module for the NSF-Facing Interface. It then constructs a mapping 264 table associating the data attributes (or variables) of the high- 265 level YANG data module with the corresponding data attributes (or 266 variables) of the low-level YANG data module. Also, it generates a 267 set of production rules of the grammar for the construction of an XML 268 file of low-level security policy rules. 270 Figure 3 shows high-to-low security policy translation. A security 271 policy translator is a component of Security Controller. The 272 translator consists of three components such as Policy Data 273 Extractor, Policy Attribute Mapper, and Policy Constructor. 275 High-level YANG Data Module Low-level YANG Data Model 276 | | 277 V V 278 +------------------------+-------------------------+ 279 | Automatic Data Model Mapper | 280 +------------------------+-------------------------+ 281 | 282 V 283 Data Model Mapping Table 285 Figure 2: Automatic Mapping of High-level and Low-level Data Models 286 +------------------------+-------------------------+ 287 | | 288 | I2NSF User | 289 | | 290 +------------------------+-------------------------+ 291 | Consumer-Facing Interface 292 | 293 High-level Security Policy 294 Security | 295 Controller V 296 +------------------------+-------------------------+ 297 | Security Policy | | 298 | Translator | | 299 | +---------------------+----------------------+ | 300 | | | | 301 | | +-------------------------+ | | 302 | | | Policy Data Extractor | | | 303 | | +-------------------------+ | | 304 | | | | 305 | | +-------------------------+ | | 306 | | | Policy Attribute Mapper | | | 307 | | +-------------------------+ | | 308 | | | | 309 | | +-------------------------+ | | 310 | | | Policy Constructor | | | 311 | | +-------------------------+ | | 312 | | | | 313 | +---------------------+----------------------+ | 314 | | | 315 +------------------------+-------------------------+ 316 | NSF-Facing Interface 317 | 318 Low-level Security Policy 319 | 320 V 321 +------------------------+-------------------------+ 322 | | 323 | NSF(s) | 324 | | 325 +------------------------+-------------------------+ 327 Figure 3: High-to-Low Security Policy Translation 329 Policy Data Extractor extracts attributes related to a security 330 policy from a high-level security policy XML file that is delivered 331 from an I2NSF User to a Security Controller 332 [I-D.ietf-i2nsf-consumer-facing-interface-dm]. 334 Policy Attribute Mapper maps the attributes and their values of a 335 high-level security policy to the corresponding attributes and their 336 values of a low-level security policy. 338 Policy Constructor constructs a low-level security policy XML file 339 that is delivered from the Security Controller to an appropriate NSF 340 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 342 5. Security System Audit 344 The I2NSF framework is weak to both an inside attack and a supply 345 chain attack since it trusts in NSFs provided by Developer's 346 Management System (DMS) and assumes that NSFs work for their security 347 services appropriately. [I-D.ietf-i2nsf-applicability]. 349 To detect the malicious activity of either an insider attacker with 350 its DMS or a supply chain attacker with its compromised DMS, an audit 351 system is required for the I2NSF framework. For this audit service 352 in the I2NSF framework, a decentralized audit system (e.g., 353 blockchain [Bitcoin]) is required. This audit system can facilitate 354 the non-repudiation of configuration commands and monitoring data 355 generated in the I2NSF framework. 357 To support the audit service in the I2NSF framework, all the 358 components in the I2NSF framework need to report their activities 359 (such as configuration commands and monitoring data) to the audit 360 sytem as transactions. 362 6. Security Considerations 364 The same security considerations for the I2NSF framework [RFC8329] 365 are applicable to this document. 367 7. IANA Considerations 369 This document does not require any IANA actions. 371 8. References 373 8.1. Normative References 375 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 376 Jeong, J., Chung, C., Ahn, T., Kumar, R., and S. Hares, 377 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 378 ietf-i2nsf-consumer-facing-interface-dm-12 (work in 379 progress), September 2020. 381 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 382 Kim, J., Jeong, J., J., J., PARK, P., Hares, S., and Q. 383 Lin, "I2NSF Network Security Function-Facing Interface 384 YANG Data Model", draft-ietf-i2nsf-nsf-facing-interface- 385 dm-10 (work in progress), August 2020. 387 [I-D.ietf-i2nsf-nsf-monitoring-data-model] 388 Jeong, J., Lingga, P., Hares, S., Xia, L., and H. 389 Birkholz, "I2NSF NSF Monitoring YANG Data Model", draft- 390 ietf-i2nsf-nsf-monitoring-data-model-04 (work in 391 progress), September 2020. 393 [I-D.ietf-i2nsf-registration-interface-dm] 394 Hyun, S., Jeong, J., Roh, T., Wi, S., J., J., and P. PARK, 395 "I2NSF Registration Interface YANG Data Model", draft- 396 ietf-i2nsf-registration-interface-dm-09 (work in 397 progress), August 2020. 399 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 400 the Network Configuration Protocol (NETCONF)", RFC 6020, 401 DOI 10.17487/RFC6020, October 2010, 402 . 404 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 405 and A. Bierman, Ed., "Network Configuration Protocol 406 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 407 . 409 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 410 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 411 . 413 [RFC8192] Hares, S., Lopez, D., Zarny, M., Jacquenet, C., Kumar, R., 414 and J. Jeong, "Interface to Network Security Functions 415 (I2NSF): Problem Statement and Use Cases", RFC 8192, 416 DOI 10.17487/RFC8192, July 2017, 417 . 419 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 420 Kumar, "Framework for Interface to Network Security 421 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 422 . 424 8.2. Informative References 426 [Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 427 System", URL: https://bitcoin.org/bitcoin.pdf, May 2009. 429 [Deep-Learning] 430 Goodfellow, I., Bengio, Y., and A. Courville, "Deep 431 Learning", Publisher: The MIT Press, 432 URL: https://www.deeplearningbook.org/, November 2016. 434 [ETSI-NFV] 435 "Network Functions Virtualisation (NFV); Architectural 436 Framework", Available: 437 https://www.etsi.org/deliver/etsi_gs/ 438 nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf, October 439 2013. 441 [I-D.ietf-i2nsf-applicability] 442 Jeong, J., Hyun, S., Ahn, T., Hares, S., and D. Lopez, 443 "Applicability of Interfaces to Network Security Functions 444 to Network-Based Security Services", draft-ietf-i2nsf- 445 applicability-18 (work in progress), September 2019. 447 [I-D.irtf-nmrg-ibn-concepts-definitions] 448 Clemm, A., Ciavaglia, L., Granville, L., and J. Tantsura, 449 "Intent-Based Networking - Concepts and Definitions", 450 draft-irtf-nmrg-ibn-concepts-definitions-02 (work in 451 progress), September 2020. 453 [I-D.yang-i2nsf-security-policy-translation] 454 Jeong, J., Yang, J., Chung, C., and J. Kim, "Security 455 Policy Translation in Interface to Network Security 456 Functions", draft-yang-i2nsf-security-policy- 457 translation-06 (work in progress), May 2020. 459 Appendix A. Acknowledgments 461 This work was supported in part by Institute of Information & 462 Communications Technology Planning & Evaluation (IITP) grant funded 463 by the Korea Ministry of Science and ICT (MSIT) (2020-0-00395, 464 Standard Development of Blockchain based Network Management 465 Automation Technology). This work was supported by the IITP grant 466 funded by the Korea MSIT (R-20160222-002755, Cloud based Security 467 Intelligence Technology Development for the Customized Security 468 Service Provisioning). 470 Appendix B. Contributors 472 This document is made by the group effort of I2NSF working group. 473 Many people actively contributed to this document, such as Linda 474 Dunbar, Yoav Nir, and Qin Wu. The authors sincerely appreciate their 475 contributions. 477 The following are co-authors of this document: 479 Yunchul Choi 480 Electronics and Telecommunications Research Institute 481 218 Gajeong-Ro, Yuseong-Gu 482 Daejeon, 34129 483 Republic of Korea 485 EMail: pjs@etri.re.kr 487 Younghan Kim 488 School of Electronic Engineering 489 Soongsil University 490 369, Sangdo-ro, Dongjak-gu 491 Seoul 06978 492 Republic of Korea 494 EMail: younghak@ssu.ac.kr 496 Authors' Addresses 497 Jaehoon Paul Jeong 498 Department of Computer Science and Engineering 499 Sungkyunkwan University 500 2066 Seobu-Ro, Jangan-Gu 501 Suwon, Gyeonggi-Do 16419 502 Republic of Korea 504 Phone: +82 31 299 4957 505 Fax: +82 31 290 7996 506 EMail: pauljeong@skku.edu 507 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 509 Patrick Lingga 510 Department of Electronic, Electrical and Computer Engineering 511 Sungkyunkwan University 512 2066 Seobu-Ro, Jangan-Gu 513 Suwon, Gyeonggi-Do 16419 514 Republic of Korea 516 Phone: +82 31 299 4957 517 EMail: patricklink@skku.edu 519 Jung-Soo Park 520 Electronics and Telecommunications Research Institute 521 218 Gajeong-Ro, Yuseong-Gu 522 Daejeon 305-700 523 Republic of Korea 525 Phone: +82 42 860 6514 526 EMail: pjs@etri.re.kr