idnits 2.17.1 draft-yang-i2nsf-security-policy-translation-03.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 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.) == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 141: '... an NSF, the NSF MUST receive at least...' RFC 2119 keyword, line 146: '...ntence, the user MUST know that the NS...' RFC 2119 keyword, line 154: '... policy is REQUIRED in I2NSF....' RFC 2119 keyword, line 429: '... security policy MUST be provided abst...' RFC 2119 keyword, line 475: '...evel policy data MUST be converted int...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1866 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Automata' ** Downref: Normative reference to an Informational RFC: RFC 8329 -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). 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: Standards Track J. Kim 5 Expires: September 12, 2019 Sungkyunkwan University 6 March 11, 2019 8 Security Policy Translation in Interface to Network Security Functions 9 draft-yang-i2nsf-security-policy-translation-03 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 September 12, 2019. 37 Copyright Notice 39 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Necessity for Policy Translator . . . . . . . . . . . . . . . 3 57 4. Design of Policy Translator . . . . . . . . . . . . . . . . . 4 58 4.1. Overall Structure of Policy Translator . . . . . . . . . 4 59 4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . 6 60 4.2.1. Design of DFA-based Data Extractor . . . . . . . . . 6 61 4.2.2. Example Scenario for Data Extractor . . . . . . . . . 7 62 4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . 9 63 4.3.1. Role of Data Converter . . . . . . . . . . . . . . . 9 64 4.3.2. NSF Database . . . . . . . . . . . . . . . . . . . . 10 65 4.3.3. Data Conversion in Data Converter . . . . . . . . . . 10 66 4.3.4. Policy Provisioning . . . . . . . . . . . . . . . . . 12 67 4.4. CFG-based Policy Generator . . . . . . . . . . . . . . . 13 68 4.4.1. Content Production . . . . . . . . . . . . . . . . . 13 69 4.4.2. Structure Production . . . . . . . . . . . . . . . . 14 70 4.4.3. Generator Construction . . . . . . . . . . . . . . . 14 71 5. Implementation Considerations . . . . . . . . . . . . . . . . 18 72 5.1. Data Model Auto-adaptation . . . . . . . . . . . . . . . 18 73 5.2. Data Conversion . . . . . . . . . . . . . . . . . . . . . 19 74 5.3. Policy Provisioning . . . . . . . . . . . . . . . . . . . 19 75 6. Features of Policy Translator Design . . . . . . . . . . . . 19 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 80 9.2. Informative References . . . . . . . . . . . . . . . . . 21 81 Appendix A. Changes from draft-yang-i2nsf-security-policy- 82 translation-02 . . . . . . . . . . . . . . . . . . . 22 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 85 1. Introduction 87 This document defines a scheme of a security policy translation in 88 Interface to Network Security Functions (I2NSF) Framework [RFC8329]. 89 First of all, this document explains the necessity of a security 90 policy translator (shortly called policy translator) in the I2NSF 91 framework. 93 The policy translator resides in Security Controller in the I2NSF 94 framework and translates a high-level security policy to a low-level 95 security policy for Network Security Functions (NSFs). A high-level 96 policy is specified by I2NSF User in the I2NSF framework and is 97 delivered to Security Controller via Consumer-Facing Interface 98 [consumer-facing-inf-dm]. It is translated into a low-level policy 99 by Policy Translator in Security Controller and is delivered to NSFs 100 to execute the rules corresponding to the low-level policy via NSF- 101 Facing Interface [nsf-facing-inf-dm]. 103 2. Terminology 105 This document uses the terminology specified in [i2nsf-terminology] 106 [RFC8329]. 108 3. Necessity for Policy Translator 110 Security Controller acts as a coordinator between I2NSF User and 111 NSFs. Also, Security Controller has capability information of NSFs 112 that are registered via Registration Interface [registration-inf-dm] 113 by Developer's Management System [RFC8329]. As a coordinator, 114 Security Controller needs to generate a low-level policy in the form 115 of security rules intended by the high-level policy, which can be 116 understood by the corresponding NSFs. 118 A high-level security policy is specified by RESTCONF/YANG 119 [RFC8040][RFC6020], and a low-level security policy is specified by 120 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level 121 security policy to the corresponding low-level security policy will 122 be able to rapidly elevate I2NSF in real-world deployment. A rule in 123 a high-level policy can include a broad target object, such as 124 employees in a company for a security service (e.g., firewall and web 125 filter). Such employees may be from human resource (HR) department, 126 software engineering department, and advertisement department. A 127 keyword of employee needs to be mapped to these employees from 128 various departments. This mapping needs to be handled by a policy 129 translator in a flexible way while understanding the intention of a 130 policy specification. Let us consider the following two policies: 132 o Block my son's computers from malicious websites. 134 o Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com 135 and illegal.com 137 The above two sentences are examples of policies for blocking 138 malicious websites. Both policies are for the same operation. 139 However, NSF cannot understand the first policy, because the policy 140 does not have any specified information for NSF. To set up the 141 policy at an NSF, the NSF MUST receive at least the source IP address 142 and website address for an operation. It means that the first 143 sentence is NOT compatible for an NSF policy. Conversely, when I2NSF 144 Users request a security policy to the system, they never make a 145 security policy like the second example. For generating a security 146 policy like the second sentence, the user MUST know that the NSF 147 needs to receive the specified information, source IP address and 148 website address. It means that the user understands the NSF 149 professionally, but there are not many professional users in a small 150 size of company or at a residential area. In conclusion, the I2NSF 151 User prefers to issue a security policy in the first sentence, but an 152 NSF will require the same policy as the second sentence with specific 153 information. Therefore, an advanced translation scheme of security 154 policy is REQUIRED in I2NSF. 156 This document proposes an approach using Automata theory [Automata] 157 for the policy tranlation, such as Deterministic Finite Automaton 158 (DFA) and Context Free Grammar (CFG). Note that Automata theory is 159 the foundation of programming language and compiler. Thus, with this 160 approach, I2NSF User can easily specify a high-level security policy 161 that will be enforced into the corresponding NSFs with a compatibly 162 low-level security policy with the help of Policy Translator. Also, 163 for easy management, a modularized translator structure is proposed. 165 4. Design of Policy Translator 167 Commonly used security policies are created as XML(Extensible Markup 168 Language) [XML] files. A popular way to change the format of an XML 169 file is to use an XSLT (Extensible Stylesheet Language 170 Transformation) [XSLT] document. XSLT is an XML-based language to 171 transform an input XML file into another output XML file. However, 172 the use of XSLT makes it difficult to manage the policy translator 173 and to handle the registration of new capabilities of NSFs. With the 174 necessity for a policy translator, this document describes a policy 175 translator based on Automata theory. 177 4.1. Overall Structure of Policy Translator 178 High-Level Policy 179 Security | 180 Controller V Consumer-Facing Interface 181 +------------------------+-------------------------+ 182 | Policy | | 183 | Translator | | 184 | +---------------------+----------------------+ | 185 | | | | | 186 | | +-------+--------+ | | 187 | | | DFA-based | | | 188 | | | Data Extractor | | | 189 | | +-------+--------+ | | 190 | | | Extracted Data from | | 191 | | V High-Level Policy | | 192 | | +-----+-----+ +--------+ | | 193 | | | Data | <-> | NSF DB | | | 194 | | | Converter | +--------+ | | 195 | | +-----+-----+ | | 196 | | | Required Data for | | 197 | | V Target NSFs | | 198 | | +--------+---------+ | | 199 | | | CFG-based | | | 200 | | | Policy Generator | | | 201 | | +--------+---------+ | | 202 | | | | | 203 | +---------------------+----------------------+ | 204 | | | 205 +------------------------+-------------------------+ 206 | NSF-Facing Interface 207 V 208 Low-Level Policy 210 Figure 1: The Overall Design of Policy Translator 212 Figure 1 shows the overall design for Policy Translator in Security 213 Controller. There are three main components for Policy Translator: 214 Data Extractor, Data Converter, and Policy Generator. 216 Extractor is a DFA-based module for extracting data from a high-level 217 policy which I2NSF User delivered via Consumer-Facing Interface. 218 Data Converter converts the extracted data to the capabilities of 219 target NSFs for a low-level policy. It refers to NSF Database (DB) 220 in order to convert an abstract subject or object into the 221 corresponding concrete subject or object (e.g., IP address and 222 website URL). Policy Generator generates a low-level policy which 223 will execute the NSF capabilities from Converter. 225 4.2. DFA-based Data Extractor 227 4.2.1. Design of DFA-based Data Extractor 229 +----------+ 230 | accepter | 231 +----------+ 232 | ^ 233 | | 234 v | 235 +------------------------------------------------------+ 236 | middle 1 | 237 +------------------------------------------------------+ 238 | ^ | ^ | ^ 239 | | | | ... | | 240 v | v | v | 242 ... ... ... 244 +-------------+ +-------------+ +-------------+ 245 | extractor 1 | | extractor 2 | ... | extractor m | 246 +-------------+ +-------------+ +-------------+ 247 data:1 data:2 data:m 249 Figure 2: DFA Architecture of Data Extractor 251 Figure 2 shows a design for Data Extractor in the policy translator. 252 If a high-level policy contains data along the hierarchical structure 253 of the standard Consumer-Facing Interface YANG data model 254 [consumer-facing-inf-dm], data can be easily extracted using the 255 state transition machine, such as DFA. The extracted data can be 256 processed and used by an NSF to understand it. Extractor can be 257 constructed by designing a DFA with the same hierarchical structure 258 as a YANG data model. 260 After constructing a DFA, Data Extractor can extract all of data in 261 the enterred high-level policy by using state transitions. Also, the 262 DFA can easily detect the grammar errors of the high-level policy. 263 The extracting algorithm of Data Extractor is as follows: 265 1. Start from the 'accepter' state. 267 2. Read the next tag from the high-level policy. 269 3. Transit to the corresponding state. 271 4. If the current state is in 'extractor', extract the corresponding 272 data, and then go back to step 2. 274 5. If the current state is in 'middle', go back to step 2. 276 6. If there is no possible transition and arrived at 'accepter' 277 state, the policy has no grammar error. Otherwise, there is a 278 grammar error, so stop the process with failure. 280 4.2.2. Example Scenario for Data Extractor 282 283 block_web 284 285 Son's_PC 286 malicious_websites 287 288 block 289 291 Figure 3: The Example of High-level Policy 293 +----------+ 294 | accepter | 295 +----------+ 296 | ^ 297 | | 298 v | 299 +------------------------------------------------------+ 300 | middle 1 | 301 +------------------------------------------------------+ 302 | ^ | ^ | ^ 303 | | | | | | 304 v | v | v | 305 +-------------+ +----------------------+ +-------------+ 306 | extractor 1 | | middle 2 | | extractor 4 | 307 +-------------+ +----------------------+ +-------------+ 308 block_web | ^ | ^ block 309 | | | | 310 v | v | 311 +-------------+ +-------------+ 312 | extractor 2 | | extractor 3 | 313 +-------------+ +-------------+ 314 Son's_PC malicious 315 _websites 317 Figure 4: The Example of Data Extractor 319 To explain the Data Extractor process by referring to an example 320 scenario, assume that Security Controller received a high-level 321 policy for a web-filtering as shown in Figure 3. Then we can 322 construct DFA-based Data Extractor by using the design as shown in 323 Figure 2. Figure 4 shows the architecture of Data Extractor that is 324 based on the architection in Figure 2 along with the input high-level 325 policy in Figure 3. Data Extractor can automatically extract all of 326 data in the high-level policy according to the following process: 328 1. Start from the 'accepter' state. 330 2. Read the first opening tag called '', and transit to the 331 'middle 1' state. 333 3. Read the second opening tag called '', and transit to the 334 'extractor 1' state. 336 4. The current state is an 'extractor' state. Extract the data of 337 'name' field called 'block_web'. 339 5. Read the second closing tag called '', and go back to the 340 'middle 1' state. 342 6. Read the third opening tag called '', and transit to the 343 'middle 2' state. 345 7. Read the fourth opening tag called '', and transit to the 346 'extractor 2' state. 348 8. The current state is an 'extractor' state. Extract the data of 349 'src' field called 'Son's_PC'. 351 9. Read the fourth closing tag called '', and go back to the 352 'middle 2' state. 354 10. Read the fifth opening tag called '', and transit to the 355 'extractor 3' state. 357 11. The current state is an 'extractor' state. Extract the data of 358 'dest' field called 'malicious_websites'. 360 12. Read the fifth closing tag called '', and go back to the 361 'middle 2' state. 363 13. Read the third closing tag called '', and go back to the 364 'middle 1' state. 366 14. Read the sixth opening tag called '', and transit to the 367 'extractor 4' state. 369 15. The current state is an 'extractor' state. Extract the data of 370 'action' field called 'block'. 372 16. Read the sixth closing tag called '', and go back to 373 the 'middle 1' state. 375 17. Read the first closing tag called '', and go back to the 376 'accepter' state. 378 18. There is no further possible transition, and the state is 379 finally on 'accepter' state. There is no grammar error in 380 Figure 3 so the scanning for data extraction is finished. 382 The above process is constructed by an extracting algorithm. After 383 finishing all the steps of the above process, Data Extractor can 384 extract all of data in Figure 3, 'block_web', 'Son's_PC', 385 'malicious', and 'block'. 387 Since the translator is modularized into a DFA structure, a visual 388 understanding is feasible. Also, The performance of Data Extractor 389 is excellent compared to one-to-one searching of data for a 390 particular field. In addition, the management is efficient because 391 the DFA completely follows the hierarchy of Consumer-Facing 392 Interface. If I2NSF User wants to modify the data model of a high- 393 level policy, it only needs to change the connection of the relevant 394 DFA node. 396 4.3. Data Converter 398 4.3.1. Role of Data Converter 400 Every NSF has its own unique capabilities. The capabilities of an 401 NSF are registered into Security Controller by a Developer's 402 Management System, which manages the NSF, via Registration Interface. 403 Therefore, Security Controller already has all information about the 404 capabilities of NSFs. This means that Security Controller can find 405 target NSFs with only the data (e.g., subject and object for a 406 security policy) of the high-level policy by comparing the extracted 407 data with all capabilities of each NSF. This search process for 408 appropriate NSFs is called by policy provisioning, and it eliminates 409 the need for I2NSF User to specify the target NSFs explicitly in a 410 high-level security policy. 412 Data Converter selects target NSFs and converts the extracted data 413 into the capabilities of selected NSFs. If Security Controller uses 414 this data convertor, it can provide the policy provisioning function 415 to I2NSF User automatically. Thus, the translator design provides 416 big benefits to the I2NSF Framework. 418 4.3.2. NSF Database 420 The NSF Database contains all the information needed to convert high- 421 level policy data to low-level policy data. The contents of NSF 422 Database are classified as the following two: "endpoint information" 423 and "NSF capability information". 425 The first is "endpoint information". Endpoint information is 426 necessary to convert an abstract high-level policy data such as 427 Son's_PC, malicious to a specific low-level policy data such as 428 10.0.0.1, illegal.com. In the high-level policy, the range of 429 endpoints for applying security policy MUST be provided abstractly. 430 Thus, endpoint information is needed to specify the abstracted high- 431 level policy data. Endpoint information is provided by I2NSF User as 432 the high-level policy through Consumer-Facing Interface, and Security 433 Controller builds NSF Database based on received information. 435 The second is "NSF capability information". Since capability is 436 information that allows NSF to know what features it can support, NSF 437 capability information is used in policy provisioning process to 438 search the appropriate NSFs through the security policy. NSF 439 capability information is provided by Developer's Management System 440 (DMS) through Registration Interface, and Security Controller builds 441 NSF Database based on received information. In addition, if the NSF 442 sends monitoring information such as initiating information to 443 Security Controller through NSF-Facing Interface, Security Controller 444 can modify NSF Database accordingly. 446 4.3.3. Data Conversion in Data Converter 447 High-level Low-level 448 Policy Data Policy Data 449 +---------------+ +------------------------------+ 450 | Rule Name | | Rule Name | 451 | +-----------+ | The Same value | +-------------------------+ | 452 | | block_web |-|------------------->|->| block_web | | 453 | +-----------+ | | +-------------------------+ | 454 | | | | 455 | Source | Conversion into | Source IPv4 | 456 | +-----------+ | User's IP address | +-------------------------+ | 457 | | Son's_PC |-|------------------->|->| [10.0.0.1, 10.0.0.3] | | 458 | +-----------+ | | +-------------------------+ | 459 | | | | 460 | Destination | Conversion into | URL Category | 461 | +-----------+ | malicious websites | +-------------------------+ | 462 | | malicious |-|------------------->|->| [harm.com, | | 463 | | _websites | | | | illegal.com] | | 464 | +-----------+ | | +-------------------------+ | 465 | | | | 466 | Action | Conversion into | Log Action Drop Action | 467 | +-----------+ | NSF Capability | +----------+ +----------+ | 468 | | block |-|------------------->|->| True | | True | | 469 | +-----------+ | | +----------+ +----------+ | 470 +---------------+ +------------------------------+ 472 Figure 5: Example of Data Conversion 474 Figure 5 shows an example for describing a data conversion in Data 475 Converter. High-level policy data MUST be converted into low-level 476 policy data which are compatible with NSFs. If a ystem administrator 477 attaches a database to Data Converter, it can convert contents by 478 referring to the database with SQL queries. Data conversion in 479 Figure 5 is based on the following list: 481 o 'Rule Name' field does NOT need the conversion. 483 o 'Source' field SHOULD be converted into a list of target IPv4 484 addresses. 486 o 'Destination' field SHOULD be converted into a URL category list 487 of malicious websites. 489 o 'Action' field SHOULD be converted into the corresponding 490 action(s) in NSF capabilities. 492 4.3.4. Policy Provisioning 494 Log-keeper Low-level Web-filter 495 NSF Policy Data NSF 496 +-------------------+ +--------------------+ +-------------------+ 497 | Rule Name | | Rule Name | | Rule Name | 498 | +--------------+ | | +--------------+ | | +--------------+ | 499 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | | 500 | +--------------+ | | +--------------+ | | +--------------+ | 501 | | | | | | 502 | Source IPv4 | | Source IPv4 | | Source IPv4 | 503 | +--------------+ | | +--------------+ | | +--------------+ | 504 | | [10.0.0.1, |<-|<-|<-| [10.0.0.1, |->|->|->| [10.0.0.1, | | 505 | | 10.0.0.3] | | | | 10.0.0.3] | | | | 10.0.0.3] | | 506 | +--------------+ | | +--------------+ | | +--------------+ | 507 | | | | | | 508 | | | URL Category | | URL Category | 509 | | | +--------------+ | | +--------------+ | 510 | | | | [harm.com, |->|->|->| [harm.com, | | 511 | | | | illegal.com] | | | | illegal.com] | | 512 | | | +--------------+ | | +--------------+ | 513 | | | | | | 514 | Log Action | | Log Action | | | 515 | +--------------+ | | +--------------+ | | | 516 | | True |<-|<-|<-| True | | | | 517 | +--------------+ | | +--------------+ | | | 518 +-------------------+ | | | | 519 | Drop Action | | Drop Action | 520 | +--------------+ | | +--------------+ | 521 | | True |->|->|->| True | | 522 | +--------------+ | | +--------------+ | 523 +--------------------+ +-------------------+ 525 Figure 6: Example of Policy Provisioning 527 Generator searches for proper NSFs which can cover all of 528 capabilities in the high-level policy. Generator searches for target 529 NSFs by comparing only NSF capabilities which is registered by Vendor 530 Management System. This process is called by "policy provisioning" 531 because Generator finds proper NSFs by using only the policy. If 532 target NSFs are found by using other data which is not included in a 533 user's policy, it means that the user already knows the specific 534 knowledge of an NSF in the I2NSF Framework. Figure 6 shows an 535 example of policy provisioning. In this example, log-keeper NSF and 536 web-filter NSF are selected for covering capabilities in the security 537 policy. All of capabilities can be covered by two selected NSFs. 539 4.4. CFG-based Policy Generator 541 Generator makes low-level security policies for each target NSF with 542 the extracted data. We constructed Generator by using Context Free 543 Grammar (CFG). CFG is a set of production rules which can describe 544 all possible strings in a given formal language(e.g., programming 545 language). The low-level policy also has its own language based on a 546 YANG data model of NSF-Facing Interface. Thus, we can construct the 547 productions based on the YANG data model. The productions that makes 548 up the low-level security policy are categorized into two types, 549 'Content Production' and 'Structure Production'. 551 4.4.1. Content Production 553 Content Production is for injecting data into low-level policies to 554 be generated. A security manager(i.e., a person (or software) to 555 make productions for security policies) can construct Content 556 Productions in the form of an expression as the following 557 productions: 559 o [cont_prod] -> [cont_prod][cont_prod] (Where duplication is 560 allowed.) 562 o [cont_prod] -> [cont_data] 564 o [cont_data] -> data_1 | data_2 | ... | data_n 566 Square brackets mean non-terminal state. If there are no non- 567 terminal states, it means that the string is completely generated. 568 When the duplication of content tag is allowed, the security manager 569 adds the first production for a rule. If there is no need to allow 570 duplication, the first production can be skipped because it is an 571 optional production. 573 The second production is the main production for Content Production 574 because it generates the tag which contains data for low-level 575 policy. Last, the third production is for injecting data into a tag 576 which is generated by the second production. If data is changed for 577 an NSF, the security manager needs to change "only the third 578 production" for data mapping in each NSF. 580 For example, if the security manager wants to express a low-level 581 policy for source IP address, Content Production can be constructed 582 in the following productions: 584 o [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.) 586 o [cont_ipv4] -> [cont_ipv4_data] 587 o [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 589 4.4.2. Structure Production 591 Structure Production is for grouping other tags into a hierarchy. 592 The security manager can construct Structure Production in the form 593 of an expression as the following production: 595 o [struct_prod] -> [prod_1]...[prod_n] 597 Structure Production can be expressed as a single production. The 598 above production means to group other tags by the name of a tag which 599 is called by 'struct_tag'. [prod_x] is a state for generating a tag 600 which wants to be grouped by Structure Production. [prod_x] can be 601 both Content Production and Structure Production. For example, if 602 the security manager wants to express the low-level policy for the 603 I2NSF tag, which is grouping 'name' and 'rules', Structure Production 604 can be constructed as the following production where [cont_name] is 605 the state for Content Production and [struct_rule] is the state for 606 Structure Production. 608 o [struct_i2nsf] -> [cont_name][struct_rules] 610 4.4.3. Generator Construction 612 The security manager can build a generator by combining the two 613 productions which are described in Section 4.4.1 and Section 4.4.2. 614 Figure 7 shows the CFG-based Generator construction of the web-filter 615 NSF. It is constructed based on the NSF-Facing Interface Data Model 616 in [nsf-facing-inf-dm]. According to Figure 7, the security manager 617 can express productions for each clause as in following CFG: 619 1. [cont_name] -> [cont_name_data] 621 2. [cont_name_data] -> block_web 623 3. [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication) 625 4. [cont_ipv4] -> [cont_ipv4_data] 627 5. [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 629 6. [cont_url] -> [cont_url][cont_url] (Allow duplication) 631 7. [cont_url] -> [cont_url_data] 633 8. [cont_url_data] -> harm.com | illegal.com 634 9. [cont_action] -> [cont_action_data] 636 10. [cont_action_data] -> drop 638 11. [struct_packet] -> [cont_ipv4] 640 12. [struct_payload] -> [cont_url] 642 13. [struct_cond] -> 643 [struct_packet][struct_payload] 645 14. [struct_rules] -> [struct_cond][cont_action] 647 15. [struct_i2nsf] -> [cont_name][struct_rules] 649 Then, Generator generates a low-level policy by using the above CFG. 650 The low-level policy is generated by the following process: 652 1. Start: [struct_i2nsf] 654 2. Production 15: [cont_name][struct_rules] 656 3. Production 1: [cont_name_data][struct_rules] 659 4. Production 2: block_web[struct_rules] 662 5. Production 14: block_web[struct_cond][cont_action] 665 6. Production 13: block_web[struct_packet][struct_payload][cont_action] 667 669 7. Production 11: block_web[cont_ipv4][struct_payload] 671 [cont_action] 673 8. Production 3: block_web[cont_ipv4][cont_ipv4][struct_payload][cont_action] 677 9. Production 4: block_web[cont_ipv4_data][cont_ipv4_dat 679 a][struct_payload][cont_action] 682 10. Production 5: block_web10.0.0.110.0.0.3[struct_payload][cont_action] 686 11. Production 12: block_web10.0.0.110.0.0.3[cont_url][cont_action] 691 12. Production 6: block_web10.0.0.110.0.0.3[cont_url][cont_url][cont_actio 694 n] 696 13. Production 7: block_web10.0.0.110.0.0.3[cont_url_data][cont_url_data]< 699 /payload>[cont_action] 701 14. Production 8: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action] 706 15. Production 9: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action_data] 711 16. Production 10: block_web10.0.0.110.0.0.3harm.comillegal.com< 714 /condition>drop 716 The last production has no non-terminal state, and the low-level 717 policy is completely generated. Figure 8 shows the generated low- 718 level policy where tab characters and newline characters are added. 720 +-----------------------------------------------------+ 721 | +----------+ +----------+ +----------+ +----------+ | 722 Content | | Rule | | Source | | URL | | Drop | | 723 Production | | Name | | IPv4 | | Category | | Action | | 724 | +-----+----+ +-----+----+ +----+-----+ +----+-----+ | 725 | | | | | | 726 +--------------------+-----------+--------------------+ 727 | | | | 728 V V V V 729 +-------+------------+-----------+------------+-------+ 730 | | | | | | 731 | | V V | | 732 | | +----------+ +----------+ | | 733 | | | Packet | | Payload | | | 734 | | | Clause | | Clause | | | 735 | | +-----+----+ +----+-----+ | | 736 | | | | | | 737 | | V V | | 738 | | +---------------+ | | 739 | | | Condition | | | 740 Structure | | | Clause | | | 741 Production | | +-------+-------+ | | 742 | | | | | 743 | | V V | 744 | | +----------------------+ | 745 | | | Rule Clause | | 746 | | +-----------+----------+ | 747 | | | | 748 | V V | 749 | +-----------------------------------------+ | 750 | | I2NSF Clause | | 751 | +--------------------+--------------------+ | 752 | | | 753 +--------------------------+--------------------------+ 754 | 755 V 756 Low-Level Policy 758 Figure 7: Generator Construction for Web-Filter NSF 759 760 block_web 761 762 763 764 10.0.0.1 765 10.0.0.3 766 767 768 harm.com 769 illegal.com 770 771 772 drop 773 774 776 Figure 8: Example of Low-Level Policy 778 5. Implementation Considerations 780 The implementation considerations in this document include the 781 following three: "data model auto-adaptation", "data conversion", and 782 "policy provisioning". 784 5.1. Data Model Auto-adaptation 786 Security Controller which acts as the intermediary MUST process the 787 data according to the data model of the connected interfaces. 788 However, the data model can be changed flexibly depending on the 789 situation, and Security Controller may adapt to the change. 790 Therefore, Security Controller can be implemented for convenience so 791 that the security policy translator can easily adapt to the change of 792 the data model. 794 The translator constructs and uses the DFA to adapt to Consumer- 795 Facing Interface Data Model. In addition, the CFG is constructed and 796 used to adapt to NSF-Facing Interface Data Model. Both the DFA and 797 the CFG follow the same tree structure of YANG Data Model. 799 The DFA starts at the a node and expands operations by changing the 800 state according to the input. Based on the YANG Data Model, a 801 container node is defined as a middle state and a leaf node is 802 defined as an extractor node. After that, if the nodes are connected 803 in the same way as the hierarchical structure of the data model, 804 Security Controller can automatically construct the DFA. The DFA can 805 be conveniently built by investigating the link structure using the 806 stack, starting with the root node. 808 The CFG starts at the leaf nodes and is grouped into clauses until 809 all the nodes are merged into one node. A leaf node is defined as 810 the content production, and a container node is defined as the 811 structure production. After that, if the nodes are connected in the 812 same way as the hierarchy of the data model, Security Controller can 813 automatically construct the CFG. The CFG can be conveniently 814 constructed by investigating the link structure using the priority 815 queue data, starting with the leaf nodes. 817 5.2. Data Conversion 819 Security Controller requires the ability to materialize the abstract 820 data in the high-level security policy and forward it to NSFs. 821 Security Controller can receive endpoint information as keywords 822 through the high-level security policy. At this time, if the 823 endpoint information corresponding to the keyword is mapped and the 824 query is transmitted to the NSF Database, the NSF Database can be 825 conveniently registered with necessary information for data 826 conversion. When a policy tries to establish a policy through the 827 keyword, Security Controller searches the details corresponding to 828 the keyword registered in the NSF Database and converts the keywords 829 into the appropriate and specified data. 831 5.3. Policy Provisioning 833 This document stated that policy provisioning function is necessary 834 to enable users without expert security knowledge to create policies. 835 Policy provisioning is determined by the capability of the NSF. If 836 the NSF has information about the capability in the policy, the 837 probability of selection increases. 839 Most importantly, selected NSFs may be able to performe all 840 capabilities in the security policy. This document recommends a 841 study of policy provisioning algorithms that are highly efficient and 842 can satisfy all capabilities in the security policy. 844 6. Features of Policy Translator Design 846 First, by showing a visualized translator structure, the security 847 manager can handle various policy changes. Translator can be shown 848 by visualizing DFA and Context-free Grammar so that the manager can 849 easily understand the structure of Policy Translator. 851 Second, if I2NSF User only keeps the hierarchy of the data model, 852 I2NSF User can freely create high-level policies. In the case of 853 DFA, data extraction can be performed in the same way even if the 854 order of input is changed. The design of the policy translator is 855 more flexible than the existing method that works by keeping the tag 856 's position and order exactly. 858 Third, the structure of Policy Translator can be updated even while 859 Policy Translator is operating. Because Policy Translator is 860 modularized, the translator can adapt to changes in the NSF 861 capability while the I2NSF framework is running. The function of 862 changing the translator's structure can be provided through 863 Registration Interface. 865 7. Security Considerations 867 There is no security concern in the proposed security policy 868 translator as long as the I2NSF interfaces (i.e., Consumer-Facing 869 Interface, NSF-Facing Interface, and Registration Interface) are 870 protected by secure communication channels. 872 8. Acknowledgments 874 This work was supported by Institute for Information & communications 875 Technology Promotion (IITP) grant funded by the Korea MSIT (Ministry 876 of Science and ICT) (R-20160222-002755, Cloud based Security 877 Intelligence Technology Development for the Customized Security 878 Service Provisioning). 880 This work was supported in part by the MSIT under the ITRC 881 (Information Technology Research Center) support program (IITP- 882 2018-2017-0-01633) supervised by the IITP. 884 9. References 886 9.1. Normative References 888 [Automata] 889 Peter, L., "Formal Languages and Automata, 6th Edition", 890 January 2016. 892 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 893 Network Configuration Protocol (NETCONF)", RFC 6020, 894 October 2010. 896 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 897 Bierman, "Network Configuration Protocol (NETCONF)", 898 RFC 6241, June 2011. 900 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 901 Protocol", RFC 8040, January 2017. 903 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 904 Kumar, "Framework for Interface to Network Security 905 Functions", RFC 8329, February 2018. 907 [XML] W3C, "On Views and XML (Extensible Markup Language)", June 908 1999. 910 9.2. Informative References 912 [consumer-facing-inf-dm] 913 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, 914 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 915 ietf-i2nsf-consumer-facing-interface-dm-03 (work in 916 progress), March 2019. 918 [i2nsf-terminology] 919 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 920 Birkholz, "Interface to Network Security Functions (I2NSF) 921 Terminology", draft-ietf-i2nsf-terminology-07 (work in 922 progress), July 2019. 924 [nsf-facing-inf-dm] 925 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, 926 "I2NSF Network Security Function-Facing Interface YANG 927 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-03 928 (work in progress), March 2019. 930 [registration-inf-dm] 931 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 932 Registration Interface YANG Data Model", draft-ietf-i2nsf- 933 registration-interface-dm-02 (work in progress), March 934 2019. 936 [XSLT] W3C, "Extensible Stylesheet Language Transformations 937 (XSLT) Version 1.0", November 1999. 939 Appendix A. Changes from draft-yang-i2nsf-security-policy- 940 translation-02 942 The following changes are made from draft-yang-i2nsf-security-policy- 943 translation-02: 945 o Section 4.3.2 is added for describing 'NSF Database'. This 946 section reinforces the ambiguous description of the NSF Database. 948 o Section 5 is added for describing 'Implementation Considerations'. 949 This section provides guidelines for a convenient implementation 950 of security policy translator. 952 Authors' Addresses 954 Jinhyuk Yang 955 Department of Computer Engineering 956 Sungkyunkwan University 957 2066 Seobu-Ro, Jangan-Gu 958 Suwon, Gyeonggi-Do 16419 959 Republic of Korea 961 Phone: +82 10 8520 8039 962 EMail: jin.hyuk@skku.edu 964 Jaehoon Paul Jeong 965 Department of Software 966 Sungkyunkwan University 967 2066 Seobu-Ro, Jangan-Gu 968 Suwon, Gyeonggi-Do 16419 969 Republic of Korea 971 Phone: +82 31 299 4957 972 Fax: +82 31 290 7996 973 EMail: pauljeong@skku.edu 974 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 976 Jinyong Tim Kim 977 Department of Computer Engineering 978 Sungkyunkwan University 979 2066 Seobu-Ro, Jangan-Gu 980 Suwon, Gyeonggi-Do 16419 981 Republic of Korea 983 Phone: +82 10 8273 0930 984 EMail: timkim@skku.edu