idnits 2.17.1 draft-yang-i2nsf-security-policy-translation-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 17, 2018) is 2109 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Yang 3 Internet-Draft J. Jeong 4 Intended status: Informational J. Kim 5 Expires: January 18, 2019 Sungkyunkwan University 6 July 17, 2018 8 Security Policy Translation in Interface to Network Security Functions 9 draft-yang-i2nsf-security-policy-translation-01 11 Abstract 13 This document proposes a scheme of security policy translation (i.e., 14 Security Policy Translator) in Interface to Network Security 15 Functions (I2NSF) Framework. When I2NSF User delivers a high-level 16 security policy for a security service, Security Policy Translator in 17 Security Controller translates it into a low-level security policy 18 for Network Security Functions (NSFs). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 18, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Necessity for Policy Translator . . . . . . . . . . . . . . . 2 57 4. Design of Policy Translator . . . . . . . . . . . . . . . . . 3 58 4.1. Overall Structure of Policy Translator . . . . . . . . . 3 59 4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . 6 60 4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . 6 61 4.4. Context-free Grammar-based Policy Generator . . . . . . . 7 62 5. Features of Policy Translator Design . . . . . . . . . . . . 7 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Informative References . . . . . . . . . . . . . . . . . . . 8 65 Appendix A. Changes from draft-yang-i2nsf-security-policy- 66 translation-00 . . . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 This document defines a scheme of a security policy translation in 72 Interface to Network Security Functions (I2NSF) Framework [RFC8329]. 73 First of all, this document explains the necessity of a security 74 policy translator (shortly called policy translator) in the I2NSF 75 framework. 77 The policy translator resides in Security Controller in the I2NSF 78 framework and translates a high-level security policy to a low-level 79 security policy for Network Security Functions (NSFs). A high-level 80 policy is specified by I2NSF User in the I2NSF framework and is 81 delivered to Security Controller via Consumer-Facing Interface 82 [consumer-facing-inf-dm]. A low-level policy is translated by Policy 83 Translator in Security Controller and is delivered to NSFs to execute 84 the rules corresponding to the low-level policy via NSF-Facing 85 Interface [nsf-facing-inf-dm]. 87 2. Terminology 89 This document uses the terminology specified in [i2nsf-terminology] 90 [RFC8329]. 92 3. Necessity for Policy Translator 94 Security Controller acts as a coordinator between I2NSF User and 95 NSFs. Also, Security Controller has capability information of NSFs 96 that are registered via Registration Interface [registration-inf-dm] 97 by Developer's Management System [RFC8329]. 99 As a coordinator, Security Controller needs to generate a low-level 100 policy in the form of security rules intended by the high-level 101 policy, which can be understood by the corresponding NSFs. 103 A high-level security policy is specified by RESTCONF/YANG 104 [RFC8040][RFC6020], and a low-level security policy is specified by 105 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level 106 security policy to the corresponding low-level security policy will 107 be able to rapidly elevate I2NSF in real-world deployment. A rule in 108 a high-level policy can include a broad target object, such as 109 employees in a company for a security service (e.g., firewall and web 110 filter). Such employees are from human resource (HR) department, 111 software engineering department, and advertisement department. A 112 keyword of employee needs to be mapped to these employees from 113 various departments. This mapping needs to be handled by a policy 114 translator in a flexible way while understanding the intention of a 115 policy specification. 117 This document proposes an approach using Automata theory for the 118 policy tranlation, such as deterministic finite automaton (DFA) and 119 context-free grammar. Note that Automata theory is the foundation of 120 programming languates and compilers. Thus, with this approach, I2NSF 121 User can easily specify a high-level security policy that will be 122 enforced into the corresponding NSFs with a compatible low-level 123 security policy with the help of Policy Translator. Also, for easy 124 managment of Policy Translator, a modularized translator structure is 125 proposed. 127 4. Design of Policy Translator 129 Commonly used security policies are created as xml files. A popular 130 way to change the format of an xml file is to use an xslt document. 131 However, the use of xslt makes it difficult to manage the policy 132 translator and to handle the registration of new capabilities of 133 NSFs. With the nessity for policy translator, this document a policy 134 translator based on Automata theory. 136 4.1. Overall Structure of Policy Translator 138 Figure 1 shows the overall design for Policy Translator in Security 139 Controller. There are three main parts for Policy Translator: 140 Extractor, Capability Converter, and Policy Generator. 142 Extractor is a DFA-based tool for extracting data from a high-level 143 policy which I2NSF User delivered via Consumer-Facing Interface. 145 Data Converter converts the extracted data to the capabilities of 146 target NSFs for a low-level policy. It refers to NSF Database (DB) 147 in order to convert an abstract subject or object into the 148 corresponding concrete subject or object (e.g., IP address and 149 website URL). Policy Generator generates a low-level policy which 150 will execute the NSF capabilities from Converter. 152 +------------+ 153 | I2NSF User | 154 +-----+------+ 155 Security | Consumer-Facing Interface 156 Controller V 157 +------------------------+-------------------------+ 158 | High-Level | 159 | Policy | 160 | (from I2NSF User) | 161 | Policy | | 162 | Translator V | 163 | +---------------------+----------------------+ | 164 | | | | | 165 | | +-------+--------+ | | 166 | | | DFA-based | | | 167 | | | Data Extractor | | | 168 | | +-------+--------+ | | 169 | | | Extracted Data from | | 170 | | V High-Level Policy | | 171 | | +-----+-----+ | | 172 | | | Data | <-> Refer to | | 173 | | | Converter | NSF DB | | 174 | | +-----+-----+ | | 175 | | | Required Data for | | 176 | | V Target NSFs | | 177 | | +-------+-------+ | | 178 | | | Context-free | | | 179 | | | Grammar-based | | | 180 | | | Policy | | | 181 | | | Generator | | | 182 | | +-------+-------+ | | 183 | | | | | 184 | +---------------------+----------------------+ | 185 | | | 186 | Low-Level Policy | 187 | (for NSFs) | 188 | | | 189 +------------------------+-------------------------+ 190 | 191 V NSF-Facing Interface 193 Figure 1: The Overall Design of Policy Translator 195 4.2. DFA-based Data Extractor 197 Figure 2 shows a design for Data Extractor in the policy translator. 198 If the high-level policy contains data along the hierarchical 199 structure of the standard YANG data model, data can be easily 200 extracted using the state transition machine, DFA. 202 The extracted data is processed and used by an NSF to understand it. 203 Extractor can be constructed by designing a DFA with the same 204 hierarchical structure as a YANG data model. 206 Since the translator is modularized into a DFA structure, a visual 207 understanding is feasible. Also, the following structure of 208 Extractor is easy to manage. If I2NSF User wants to modify the data 209 model of a high-level policy, it only needs to change the connection 210 of the relevant DFA node. 212 213 +----------+ ------> +----------+ -------> +-------------+ 214 | accepter | | | . . . | extractor 1 | 215 +----------+ <------ | | <------- +-------------+ 216 | | 217 | | 218 | | 219 | | -------> +-------------+ 220 | | . . . | extractor 2 | 221 | | <------- +-------------+ 222 | middle 1 | 223 | | . 224 | | . 225 | | . 226 | | 227 | | -------> +-------------+ 228 | | . . . | extractor N | 229 | | <------- +-------------+ 230 | | 231 +----------+ 233 Figure 2: The Design of Data Extractor 235 4.3. Data Converter 237 Every NSF has its own unique capabilities. The capabilities of an 238 NSF are registered into Security Controller by a Developer's 239 Management System, which manages the NSF, via Registration Interface. 240 Therefore, Security Controller already has all information about the 241 capabilities of NSFs. This means that Security Controller can find 242 target NSFs with only the data (e.g., subject and object for a 243 security policy) of the high-level policy by comparing all 244 capabilities of each NSF. This search process for appropriate NSFs 245 is called by NSF provisioning, and it eliminates the need for I2NSF 246 User to specify the target NSFs explicitly. Data Converter selects 247 target NSFs and converts the extracted data into the capabilities of 248 selected NSFs. If Security Controller uses this data convertor, it 249 can provide the NSF provisioning function to the I2NSF User 250 automatically. Thus, the translator design provides big benefits to 251 I2NSF Framework. 253 4.4. Context-free Grammar-based Policy Generator 255 The productions that makes up the low-level security policy are 256 categorized into two types, Structure Production and Content 257 Production. Structure Production is for grouping other tags into a 258 hierarchy. A security manager constructs Structure Production in the 259 form of an expression as the following equation: 261 o [structure_prod] -> 262 [policy:1][policy:2]...[policy:n] 264 Content Production is for injecting data into low-level policies to 265 be generated. The manager can construct Content Production in the 266 form of an expression as following equation: 268 o [content_prod] -> [content_data] 270 o [content_data] -> data:1 | data:2 | ... | data:n 272 o [content_prod] -> [content_prod][content_prod] (Where duplication 273 is allowed.) 275 5. Features of Policy Translator Design 277 First, by showing the visualized translator structure, the manager 278 can handle various policy changes. Translator can be shown by 279 visualizing DFA and Context-free Grammar so that the manager can 280 easily understand the structure of Policy Translator. 282 Second, if I2NSF User only keeps the hierarchy of the data model, 283 I2NSF User can freely create high-level policies. In the case of 284 DFA, data extraction can be performed in the same way even if the 285 order of input is changed. The design of the policy translator is 286 more flexible than the existing method that works by keeping the tag 287 's position and order exactly. 289 Third, the structure of Policy Translator can be updated even while 290 Policy Translator is operating. Because Policy Translator is 291 modularized, the translator can adapt to changes in the NSF 292 capability while the I2NSF framework is running. The function of 293 changing the translator's structure can be provided through 294 Registration Interface. 296 6. Acknowledgments 298 This work was supported by Institute for Information & communications 299 Technology Promotion (IITP) grant funded by the Korea MSIT (Ministry 300 of Science and ICT) (R-20160222-002755, Cloud based Security 301 Intelligence Technology Development for the Customized Security 302 Service Provisioning). 304 This work was supported in part by the MSIT under the ITRC 305 (Information Technology Research Center) support program (IITP- 306 2018-2017-0-01633) supervised by the IITP. 308 7. Informative References 310 [consumer-facing-inf-dm] 311 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, 312 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 313 ietf-i2nsf-consumer-facing-interface-dm-01 (work in 314 progress), July 2018. 316 [i2nsf-terminology] 317 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 318 Birkholz, "Interface to Network Security Functions (I2NSF) 319 Terminology", draft-ietf-i2nsf-terminology-06 (work in 320 progress), July 2018. 322 [nsf-facing-inf-dm] 323 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, 324 "I2NSF Network Security Function-Facing Interface YANG 325 Data Model", draft-ietf-i2nsf-nsf-facing-interface-data- 326 model-01 (work in progress), July 2018. 328 [registration-inf-dm] 329 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 330 Registration Interface YANG Data Model", draft-hyun-i2nsf- 331 registration-dm-05 (work in progress), July 2018. 333 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 334 Network Configuration Protocol (NETCONF)", RFC 6020, 335 October 2010. 337 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 338 Bierman, "Network Configuration Protocol (NETCONF)", 339 RFC 6241, June 2011. 341 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 342 Protocol", RFC 8040, January 2017. 344 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 345 Kumar, "Framework for Interface to Network Security 346 Functions", RFC 8329, February 2018. 348 Appendix A. Changes from draft-yang-i2nsf-security-policy- 349 translation-00 351 The following changes are made from draft-yang-i2nsf-security-policy- 352 translation-00: 354 o In Section 3, the necessity for the proposed translation design is 355 clarified. 357 o In Section 4.3, the description of Data Converter is clarified. 359 o In Section 4.4, "Structure Grammar" and "Content Grammar" are 360 replaced with "Structure Production" and "Content Production", 361 respectively. 363 o The references are updated to reflect the latest documents. 365 Authors' Addresses 367 Jinhyuk Yang 368 Department of Computer Engineering 369 Sungkyunkwan University 370 2066 Seobu-Ro, Jangan-Gu 371 Suwon, Gyeonggi-Do 16419 372 Republic of Korea 374 Phone: +82 10 8520 8039 375 EMail: jin.hyuk@skku.edu 377 Jaehoon Paul Jeong 378 Department of Software 379 Sungkyunkwan University 380 2066 Seobu-Ro, Jangan-Gu 381 Suwon, Gyeonggi-Do 16419 382 Republic of Korea 384 Phone: +82 31 299 4957 385 Fax: +82 31 290 7996 386 EMail: pauljeong@skku.edu 387 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 388 Jinyong Tim Kim 389 Department of Computer Engineering 390 Sungkyunkwan University 391 2066 Seobu-Ro, Jangan-Gu 392 Suwon, Gyeonggi-Do 16419 393 Republic of Korea 395 Phone: +82 10 8273 0930 396 EMail: timkim@skku.edu