idnits 2.17.1 draft-yang-i2nsf-security-policy-translation-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 : ---------------------------------------------------------------------------- ** 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 2, 2018) is 2126 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 Network Working Group J. Yang 3 Internet-Draft J. Jeong 4 Intended status: Informational J. Kim 5 Expires: January 3, 2019 Sungkyunkwan University 6 July 2, 2018 8 Security Policy Translation in Interface to Network Security Functions 9 draft-yang-i2nsf-security-policy-translation-00 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 to IETF 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), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 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 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 3, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Necessity for Policy Translator . . . . . . . . . . . . . . . . 3 63 4. Design of Policy Translator . . . . . . . . . . . . . . . . . . 4 64 4.1. Overall Structure of Policy Translator . . . . . . . . . . 4 65 4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . . 6 66 4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . . 6 67 4.4. Context-free Grammar-based Policy Generator . . . . . . . . 7 68 5. Features of Policy Translator Design . . . . . . . . . . . . . 7 69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7. Informative References . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 This document defines a scheme of a security policy translation in 75 Interface to Network Security Functions (I2NSF) Framework [RFC8329]. 76 First of all, this document explains the necessity of a security 77 policy translator (shortly called policy translator) in the I2NSF 78 framework. 80 The policy translator resides in Security Controller in the I2NSF 81 framework and translates a high-level security policy to a low-level 82 security policy for Network Security Functions (NSFs). A high-level 83 policy is specified by I2NSF User in the I2NSF framework and is 84 delivered to Security Controller via Consumer-Facing Interface 85 [consumer-facing-inf-dm]. A low-level policy is translated by Policy 86 Translator in Security Controller and is delivered to NSFs to execute 87 the rules corresponding to the low-level policy via NSF-Facing 88 Interface [nsf-facing-inf-dm]. 90 2. Terminology 92 This document uses the terminology specified in [i2nsf-terminology] 93 [RFC8329]. 95 3. Necessity for Policy Translator 97 Security Controller acts as a coordinator between I2NSF User and 98 NSFs. Also, Security Controller has capability information of NSFs 99 that are registered via Registration Interface [registration-inf-dm] 100 by Developer's Management System [RFC8329]. 102 As a coordinator, Security Controller needs to generate a low-level 103 policy in the form of security rules intended by the high-level 104 policy, which can be understood by the corresponding NSFs. 106 A high-level security policy is specified by RESTCONF/YANG 107 [RFC8040][RFC6020], and a low-level security policy is specified by 108 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level 109 security policy to the corresponding low-level security policy will 110 be able to rapidly elevate I2NSF in real-world deployment. A rule in 111 a high-level policy can include a broad target object, such as 112 employees in a company for a security service (e.g., firewall and web 113 filter). Such employees are from human resource (HR) department, 114 software engineering department, and advertisement department. A 115 keyword of employee needs to be mapped to these employees from 116 various departments. This mapping needs to be handled by a policy 117 translator in a flexible way while understanding the intention of a 118 policy specification. 120 This document proposes an approach using Automata theory for the 121 policy tranlation, such as deterministic finite automaton (DFA) and 122 context-free grammar. Note that Automata theory is the foundation of 123 programming languates and compilers. Thus, with this approach, I2NSF 124 User can easily specify a high-level security policy that will be 125 enforced into the corresponding NSFs with a compatible low-level 126 security policy with the help of Policy Translator. Also, for easy 127 managment of Policy Translator, a modularized translator structure is 128 proposed. 130 4. Design of Policy Translator 132 Commonly used security policies are created as xml files. A popular 133 way to change the format of an xml file is to use an xslt document. 134 However, the use of xslt makes it difficult to manage the policy 135 translator and to handle the registration of new capabilities of 136 NSFs. With the nessity for policy translator, this document a policy 137 translator based on Automata. 139 4.1. Overall Structure of Policy Translator 141 Figure 1 shows the overall design for Policy Translator in Security 142 Controller. There are three main parts for Policy Translator: 143 Extractor, Capability Converter, and Policy Generator. 145 Extractor is a DFA-based tool for extracting data from a high-level 146 policy which I2NSF User delivered via Consumer-Facing Interface. 147 Data Converter converts the extracted data to the capabilities of 148 target NSFs for a low-level policy. Policy Generator generates a 149 low-level policy which will execute the NSF capabilities from 150 Converter. 152 +------------+ 153 | I2NSF User | 154 +-----+------+ 155 Security | I2NSF 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 | | | 173 | | | Converter | | | 174 | | +-----+-----+ | | 175 | | | Capabilities of | | 176 | | V Low-Level Policy | | 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 I2NSF 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 capability. NSF registration is 238 performed through Registration Interface, and the registration 239 process is dedicated to Security Controller. Therefore, Security 240 Controller already has all information about the capabilities of the 241 NSFs. This means that Security Controller can find target NSFs with 242 only the data of the high-level policy. Data Converter selects 243 target NSFs and converts the extracted data into the capabilities of 244 selected NSFs. This eliminates the need for I2NSF User to set the 245 target NSFs one by one. 247 4.4. Context-free Grammar-based Policy Generator 249 The grammar that makes up the low-level security policy is 250 categorized into two types, Structure Grammar and Content Grammar. 251 Structure Grammar is for grouping other tags into a hierarchy. A 252 security administrator called manager constructs Structure Grammar in 253 the form of an expression as the following equation: 255 o [structure_grammar] -> [policy:1][policy: 256 2]...[policy:n] 258 Content Grammar is for injecting data into low-level policies to be 259 generated. The manager can construct Content Grammar in the form of 260 an expression as following equation: 262 o [content_grammar] -> [content_data] 264 o [content_data] -> data:1 | data:2 | ... | data:n 266 o [content_grammar] -> [content_grammar][content_grammar] (When 267 duplication is allowed) 269 5. Features of Policy Translator Design 271 First, by showing the visualized translator structure, the manager 272 can handle various policy changes. Translator can be shown by 273 visualizing DFA and Context-free Grammar so that the manager can 274 easily understand the structure of Policy Translator. 276 Second, if I2NSF User only keeps the hierarchy of the data model, 277 I2NSF User can freely create high-level policies. In the case of 278 DFA, data extraction can be performed in the same way even if the 279 order of input is changed. The design of the policy translator is 280 more flexible than the existing method that works by keeping the tag 281 's position and order exactly. 283 Third, the structure of Policy Translator can be updated even while 284 Policy Translator is operating. Because Policy Translator is 285 modularized, the translator can adapt to changes in the NSF 286 capability while the I2NSF framework is running. The function of 287 changing the translator's structure can be provided through 288 Registration Interface. 290 6. Acknowledgments 292 This work was supported by Institute for Information & communications 293 Technology Promotion (IITP) grant funded by the Korea MSIT (Ministry 294 of Science and ICT) (R-20160222-002755, Cloud based Security 295 Intelligence Technology Development for the Customized Security 296 Service Provisioning). 298 This work was supported in part by the MSIT under the ITRC 299 (Information Technology Research Center) support program (IITP-2018- 300 2017-0-01633) supervised by the IITP. 302 7. Informative References 304 [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia, 305 L., and H. Birkholz, "Interface to Network 306 Security Functions (I2NSF) Terminology", 307 draft-ietf-i2nsf-terminology-05 (work in 308 progress), January 2018. 310 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., 311 Strassner, J., and R. Kumar, "Framework for 312 Interface to Network Security Functions", 313 RFC 8329, February 2018. 315 [consumer-facing-inf-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and 316 S. Hares, "I2NSF Consumer-Facing Interface 317 YANG Data Model", draft-ietf-i2nsf- 318 consumer-facing-interface-dm-01 (work in 319 progress), July 2018. 321 [nsf-facing-inf-dm] Kim, J., Jeong, J., Park, J., Hares, S., 322 and Q. Lin, "I2NSF Network Security 323 Function-Facing Interface YANG Data Model", 324 draft-ietf-i2nsf-nsf-facing-interface-data- 325 model-01 (work in progress), July 2018. 327 [registration-inf-dm] Hyun, S., Jeong, J., Roh, T., Wi, S., and 328 J. Park, "I2NSF Registration Interface YANG 329 Data Model", 330 draft-hyun-i2nsf-registration-dm-04 (work 331 in progress), July 2018. 333 [RFC6020] Bjorklund, M., "YANG - A Data Modeling 334 Language for the Network Configuration 335 Protocol (NETCONF)", RFC 6020, 336 October 2010. 338 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, 339 "RESTCONF Protocol", RFC 8040, 340 January 2017. 342 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., 343 and A. Bierman, "Network Configuration 344 Protocol (NETCONF)", RFC 6241, June 2011. 346 Authors' Addresses 348 Jinhyuk Yang 349 Department of Computer Engineering 350 Sungkyunkwan University 351 2066 Seobu-Ro, Jangan-Gu 352 Suwon, Gyeonggi-Do 16419 353 Republic of Korea 355 Phone: +82 10 8520 8039 356 EMail: jin.hyuk@skku.edu 358 Jaehoon Paul Jeong 359 Department of Software 360 Sungkyunkwan University 361 2066 Seobu-Ro, Jangan-Gu 362 Suwon, Gyeonggi-Do 16419 363 Republic of Korea 365 Phone: +82 31 299 4957 366 Fax: +82 31 290 7996 367 EMail: pauljeong@skku.edu 368 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 370 Jinyong Tim Kim 371 Department of Computer Engineering 372 Sungkyunkwan University 373 2066 Seobu-Ro, Jangan-Gu 374 Suwon, Gyeonggi-Do 16419 375 Republic of Korea 377 Phone: +82 10 8273 0930 378 EMail: timkim@skku.edu