idnits 2.17.1 draft-yang-i2nsf-security-policy-translation-02.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 5 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 136: '... an NSF, the NSF MUST receive at least...' RFC 2119 keyword, line 141: '...ntence, the user MUST know that the NS...' RFC 2119 keyword, line 149: '... policy is REQUIRED in I2NSF....' RFC 2119 keyword, line 441: '...evel policy data MUST be converted int...' RFC 2119 keyword, line 449: '... 'Source' field SHOULD be converted i...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 2003 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: April 25, 2019 Sungkyunkwan University 6 October 22, 2018 8 Security Policy Translation in Interface to Network Security Functions 9 draft-yang-i2nsf-security-policy-translation-02 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 April 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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. Data Conversion in Data Converter . . . . . . . . . . 10 65 4.3.3. Policy Provisioning . . . . . . . . . . . . . . . . . 11 66 4.4. CFG-based Policy Generator . . . . . . . . . . . . . . . 12 67 4.4.1. Content Production . . . . . . . . . . . . . . . . . 12 68 4.4.2. Structure Production . . . . . . . . . . . . . . . . 13 69 4.4.3. Generator Construction . . . . . . . . . . . . . . . 13 70 5. Features of Policy Translator Design . . . . . . . . . . . . 17 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 75 8.2. Informative References . . . . . . . . . . . . . . . . . 18 76 Appendix A. Changes from draft-yang-i2nsf-security-policy- 77 translation-01 . . . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 This document defines a scheme of a security policy translation in 83 Interface to Network Security Functions (I2NSF) Framework [RFC8329]. 84 First of all, this document explains the necessity of a security 85 policy translator (shortly called policy translator) in the I2NSF 86 framework. 88 The policy translator resides in Security Controller in the I2NSF 89 framework and translates a high-level security policy to a low-level 90 security policy for Network Security Functions (NSFs). A high-level 91 policy is specified by I2NSF User in the I2NSF framework and is 92 delivered to Security Controller via Consumer-Facing Interface 93 [consumer-facing-inf]. It is translated into a low-level policy by 94 Policy Translator in Security Controller and is delivered to NSFs to 95 execute the rules corresponding to the low-level policy via NSF- 96 Facing Interface [nsf-facing-inf]. 98 2. Terminology 100 This document uses the terminology specified in [i2nsf-terminology] 101 [RFC8329]. 103 3. Necessity for Policy Translator 105 Security Controller acts as a coordinator between I2NSF User and 106 NSFs. Also, Security Controller has capability information of NSFs 107 that are registered via Registration Interface [registration-inf] by 108 Developer's Management System [RFC8329]. As a coordinator, Security 109 Controller needs to generate a low-level policy in the form of 110 security rules intended by the high-level policy, which can be 111 understood by the corresponding NSFs. 113 A high-level security policy is specified by RESTCONF/YANG 114 [RFC8040][RFC6020], and a low-level security policy is specified by 115 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level 116 security policy to the corresponding low-level security policy will 117 be able to rapidly elevate I2NSF in real-world deployment. A rule in 118 a high-level policy can include a broad target object, such as 119 employees in a company for a security service (e.g., firewall and web 120 filter). Such employees may be from human resource (HR) department, 121 software engineering department, and advertisement department. A 122 keyword of employee needs to be mapped to these employees from 123 various departments. This mapping needs to be handled by a policy 124 translator in a flexible way while understanding the intention of a 125 policy specification. Let us consider the following two policies: 127 o Block my son's computers from malicious websites. 129 o Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com 130 and illegal.com 132 The above two sentences are examples of policies for blocking 133 malicious websites. Both policies are for the same operation. 134 However, NSF cannot understand the first policy, because the policy 135 does not have any specified information for NSF. To set up the 136 policy at an NSF, the NSF MUST receive at least the source IP address 137 and website address for an operation. It means that the first 138 sentence is NOT compatible for an NSF policy. Conversely, when I2NSF 139 users request a security policy to the system, they never make a 140 security policy like the second example. For generating a security 141 policy like the second sentence, the user MUST know that the NSF 142 needs to receive the specified information, source IP address and 143 website address. It means that the user understands the NSF 144 professionally, but there are not many professional users in a small 145 size of company or at a residential area. In conclusion, the I2NSF 146 user prefers to issue a security policy in the first sentence, but an 147 NSF will require the same policy as the second sentence with specific 148 information. Therefore, an advanced translation scheme of security 149 policy is REQUIRED in I2NSF. 151 This document proposes an approach using Automata theory [Automata] 152 for the policy tranlation, such as Deterministic Finite Automaton 153 (DFA) and Context-Free Grammar (CFG). Note that Automata theory is 154 the foundation of programming language and compiler. Thus, with this 155 approach, I2NSF User can easily specify a high-level security policy 156 that will be enforced into the corresponding NSFs with a compatibly 157 low-level security policy with the help of Policy Translator. Also, 158 for easy management, a modularized translator structure is proposed. 160 4. Design of Policy Translator 162 Common security policies are created by Extensible Markup Language 163 (XML) [XML] files. A popular way to change the format of an XML file 164 is to use an Extensible Stylesheet Language Transformation (XSLT) 165 [XSLT] document. XSLT is an XML-based language to transform an input 166 XML file into another output XML file. However, the use of XSLT 167 makes it difficult to manage the policy translator and to handle the 168 registration of new capabilities of NSFs. With the necessity for a 169 policy translator, this document describes a policy translator based 170 on Automata theory [Automata]. 172 4.1. Overall Structure of Policy Translator 173 High-Level Policy 174 Security | 175 Controller V Consumer-Facing Interface 176 +------------------------+-------------------------+ 177 | Policy | | 178 | Translator | | 179 | +---------------------+----------------------+ | 180 | | | | | 181 | | +-------+--------+ | | 182 | | | DFA-based | | | 183 | | | Data Extractor | | | 184 | | +-------+--------+ | | 185 | | | Extracted Data from | | 186 | | V High-Level Policy | | 187 | | +-----+-----+ +--------+ | | 188 | | | Data | <-> | NSF DB | | | 189 | | | Converter | +--------+ | | 190 | | +-----+-----+ | | 191 | | | Required Data for | | 192 | | V Target NSFs | | 193 | | +--------+---------+ | | 194 | | | CFG-based | | | 195 | | | Policy Generator | | | 196 | | +--------+---------+ | | 197 | | | | | 198 | +---------------------+----------------------+ | 199 | | | 200 +------------------------+-------------------------+ 201 | NSF-Facing Interface 202 V 203 Low-Level Policy 205 Figure 1: The Overall Design of Policy Translator 207 Figure 1 shows the overall design for Policy Translator in Security 208 Controller. There are three main components for Policy Translator: 209 Data Extractor, Data Converter, and Policy Generator. 211 Extractor is a DFA-based module for extracting data from a high-level 212 policy which I2NSF User delivered via Consumer-Facing Interface. 213 Data Converter converts the extracted data to the capabilities of 214 target NSFs for a low-level policy. It refers to NSF Database (DB) 215 in order to convert an abstract subject or object into the 216 corresponding concrete subject or object (e.g., IP address and 217 website URL). Policy Generator generates a low-level policy which 218 will execute the NSF capabilities from Converter. 220 4.2. DFA-based Data Extractor 222 4.2.1. Design of DFA-based Data Extractor 224 +----------+ 225 | accepter | 226 +----------+ 227 | ^ 228 | | 229 v | 230 +------------------------------------------------------+ 231 | middle 1 | 232 +------------------------------------------------------+ 233 | ^ | ^ | ^ 234 | | | | ... | | 235 v | v | v | 237 ... ... ... 239 +-------------+ +-------------+ +-------------+ 240 | extractor 1 | | extractor 2 | ... | extractor m | 241 +-------------+ +-------------+ +-------------+ 242 data:1 data:2 data:m 244 Figure 2: DFA Architecture of Data Extractor 246 Figure 2 shows a design for Data Extractor in the policy translator. 247 If a high-level policy contains data along the hierarchical structure 248 of the standard Consumer-Facing Interface YANG data model 249 [consumer-facing-inf], data can be easily extracted using the state 250 transition machine, such as DFA. The extracted data can be processed 251 and used by an NSF to understand it. Extractor can be constructed by 252 designing a DFA with the same hierarchical structure as a YANG data 253 model. 255 After constructing a DFA, Data Extractor can extract all of data in 256 the enterred high-level policy by using state transitions. Also, the 257 DFA can easily detect the grammar errors of the high-level policy. 258 The extracting algorithm of Data Extractor is as follows: 260 1. Start from the 'accepter' state. 262 2. Read the next tag from the high-level policy. 264 3. Transit to the corresponding state. 266 4. If the current state is in 'extractor', extract the corresponding 267 data, and then go back to step 2. 269 5. If the current state is in 'middle', go back to step 2. 271 6. If there is no possible transition and arrived at 'accepter' 272 state, the policy has no grammar error. Otherwise, there is a 273 grammar error, so stop the process with failure. 275 4.2.2. Example Scenario for Data Extractor 277 278 block_web 279 280 Son's_PC 281 malicious 282 283 block 284 286 Figure 3: The Example of High-level Policy 288 +----------+ 289 | accepter | 290 +----------+ 291 | ^ 292 | | 293 v | 294 +------------------------------------------------------+ 295 | middle 1 | 296 +------------------------------------------------------+ 297 | ^ | ^ | ^ 298 | | | | | | 299 v | v | v | 300 +-------------+ +----------------------+ +-------------+ 301 | extractor 1 | | middle 2 | | extractor 4 | 302 +-------------+ +----------------------+ +-------------+ 303 block_web | ^ | ^ block 304 | | | | 305 v | v | 306 +-------------+ +-------------+ 307 | extractor 2 | | extractor 3 | 308 +-------------+ +-------------+ 309 Son's_PC malicious 311 Figure 4: The Example of Data Extractor 313 To explain the Data Extractor process by referring to an example 314 scenario, assume that Security Controller received a high-level 315 policy for a web-filtering as shown in Figure 3. Then we can 316 construct DFA-based Data Extractor by using the design as shown in 317 Figure 2. Figure 4 shows the architecture of Data Extractor that is 318 based on the architection in Figure 2 along with the input high-level 319 policy in Figure 3. Data Extractor can automatically extract all of 320 data in the high-level policy according to the following process: 322 1. Start from the 'accepter' state. 324 2. Read the first opening tag called '', and transit to the 325 'middle 1' state. 327 3. Read the second opening tag called '', and transit to the 328 'extractor 1' state. 330 4. The current state is an 'extractor' state. Extract the data of 331 'name' field called 'block_web'. 333 5. Read the second closing tag called '', and go back to the 334 'middle 1' state. 336 6. Read the third opening tag called '', and transit to the 337 'middle 2' state. 339 7. Read the fourth opening tag called '', and transit to the 340 'extractor 2' state. 342 8. The current state is an 'extractor' state. Extract the data of 343 'src' field called 'Son's_PC'. 345 9. Read the fourth closing tag called '', and go back to the 346 'middle 2' state. 348 10. Read the fifth opening tag called '', and transit to the 349 'extractor 3' state. 351 11. The current state is an 'extractor' state. Extract the data of 352 'dest' field called 'malicious'. 354 12. Read the fifth closing tag called '', and go back to the 355 'middle 2' state. 357 13. Read the third closing tag called '', and go back to the 358 'middle 1' state. 360 14. Read the sixth opening tag called '', and transit to the 361 'extractor 4' state. 363 15. The current state is an 'extractor' state. Extract the data of 364 'action' field called 'block'. 366 16. Read the sixth closing tag called '', and go back to 367 the 'middle 1' state. 369 17. Read the first closing tag called '', and go back to the 370 'accepter' state. 372 18. There is no further possible transition, and the state is 373 finally on 'accepter' state. There is no grammar error in 374 Figure 3 so the scanning for data extraction is finished. 376 The above process is constructed by an extracting algorithm. After 377 finishing all the steps of the above process, Data Extractor can 378 extract all of data in Figure 3, 'block_web', 'Son's_PC', 379 'malicious', and 'block'. 381 Since the translator is modularized into a DFA structure, a visual 382 understanding is feasible. Also, The performance of Data Extractor 383 is excellent compared to one-to-one searching of data for a 384 particular field. In addition, the management is efficient because 385 the DFA completely follows the hierarchy of Consumer-Facing 386 Interface. If I2NSF User wants to modify the data model of a high- 387 level policy, it only needs to change the connection of the relevant 388 DFA node. 390 4.3. Data Converter 392 4.3.1. Role of Data Converter 394 Every NSF has its own unique capabilities. The capabilities of an 395 NSF are registered into Security Controller by a Developer's 396 Management System, which manages the NSF, via Registration Interface. 397 Therefore, Security Controller already has all information about the 398 capabilities of NSFs. This means that Security Controller can find 399 target NSFs with only the data (e.g., subject and object for a 400 security policy) of the high-level policy by comparing the extracted 401 data with all capabilities of each NSF. This search process for 402 appropriate NSFs is called by policy provisioning, and it eliminates 403 the need for I2NSF User to specify the target NSFs explicitly in a 404 high-level security policy. 406 Data Converter selects target NSFs and converts the extracted data 407 into the capabilities of selected NSFs. If Security Controller uses 408 this data convertor, it can provide the policy provisioning function 409 to the I2NSF User automatically. Thus, the translator design 410 provides big benefits to the I2NSF Framework. 412 4.3.2. Data Conversion in Data Converter 414 High-level Low-level 415 Policy Data Policy Data 416 +---------------+ +------------------------------+ 417 | Rule Name | | Rule Name | 418 | +-----------+ | The Same value | +-------------------------+ | 419 | | block_web |-|------------------->|->| block_web | | 420 | +-----------+ | | +-------------------------+ | 421 | | | | 422 | Source | Conversion into | Source IPv4 | 423 | +-----------+ | User's IP address | +-------------------------+ | 424 | | Son's_PC |-|------------------->|->| [10.0.0.1, 10.0.0.3] | | 425 | +-----------+ | | +-------------------------+ | 426 | | | | 427 | Destination | Conversion into | URL Category | 428 | +-----------+ | malicious websites | +-------------------------+ | 429 | | malicious |-|------------------->|->| [harm.com, illegal.com] | | 430 | +-----------+ | | +-------------------------+ | 431 | | | | 432 | Action | Conversion into | Log Action Drop Action | 433 | +-----------+ | NSF Capability | +----------+ +----------+ | 434 | | block |-|------------------->|->| True | | True | | 435 | +-----------+ | | +----------+ +----------+ | 436 +---------------+ +------------------------------+ 438 Figure 5: Example of Data Conversion 440 Figure 5 shows an example for describing a data conversion in Data 441 Converter. High-level policy data MUST be converted into low-level 442 policy data which are compatible with NSFs. If a ystem administrator 443 attaches a database to Data Converter, it can convert contents by 444 referring to the database with SQL queries. Data conversion in 445 Figure 5 is based on the following list: 447 o 'Rule Name' field does NOT need the conversion. 449 o 'Source' field SHOULD be converted into a list of target IPv4 450 addresses. 452 o 'Destination' field SHOULD be converted into a URL category list 453 of malicious websites. 455 o 'Action' field SHOULD be converted into the corresponding 456 action(s) in NSF capabilities. 458 4.3.3. Policy Provisioning 460 Log-keeper Low-level Web-filter 461 NSF Policy Data NSF 462 +-------------------+ +--------------------+ +-------------------+ 463 | Rule Name | | Rule Name | | Rule Name | 464 | +--------------+ | | +--------------+ | | +--------------+ | 465 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | | 466 | +--------------+ | | +--------------+ | | +--------------+ | 467 | | | | | | 468 | Source IPv4 | | Source IPv4 | | Source IPv4 | 469 | +--------------+ | | +--------------+ | | +--------------+ | 470 | | [10.0.0.1, |<-|<-|<-| [10.0.0.1, |->|->|->| [10.0.0.1, | | 471 | | 10.0.0.3] | | | | 10.0.0.3] | | | | 10.0.0.3] | | 472 | +--------------+ | | +--------------+ | | +--------------+ | 473 | | | | | | 474 | | | URL Category | | URL Category | 475 | | | +--------------+ | | +--------------+ | 476 | | | | [harm.com, |->|->|->| [harm.com, | | 477 | | | | illegal.com] | | | | illegal.com] | | 478 | | | +--------------+ | | +--------------+ | 479 | | | | | | 480 | Log Action | | Log Action | | | 481 | +--------------+ | | +--------------+ | | | 482 | | True |<-|<-|<-| True | | | | 483 | +--------------+ | | +--------------+ | | | 484 +-------------------+ | | | | 485 | Drop Action | | Drop Action | 486 | +--------------+ | | +--------------+ | 487 | | True |->|->|->| True | | 488 | +--------------+ | | +--------------+ | 489 +--------------------+ +-------------------+ 491 Figure 6: Example of Policy Provisioning 493 Generator searches for proper NSFs which can cover all of 494 capabilities in the high-level policy. Generator searches for target 495 NSFs by comparing only NSF capabilities which is registered by Vendor 496 Management System. This process is called by "policy provisioning" 497 because Generator finds proper NSFs by using only the policy. If 498 target NSFs are found by using other data which is not included in a 499 user's policy, it means that the user already knows the specific 500 knowledge of an NSF in the I2NSF Framework. Figure 6 shows an 501 example of policy provisioning. In this example, log-keeper NSF and 502 web-filter NSF are selected for covering capabilities in the security 503 policy. All of capabilities can be covered by two selected NSFs. 505 4.4. CFG-based Policy Generator 507 Generator makes low-level security policies for each target NSF with 508 the extracted data. We constructed Generator by using a Context-Free 509 Grammar called CFG. CFG is a set of production rules which can 510 describe all possible strings in a given formal language(e.g., 511 programming language). The low-level policy also has its own 512 language based on a YANG data model of NSF-Facing Interface. Thus, 513 we can construct the productions based on the YANG data model. The 514 productions that makes up the low-level security policy are 515 categorized into two types, 'Content Production' and 'Structure 516 Production'. 518 4.4.1. Content Production 520 Content Production is for injecting data into low-level policies to 521 be generated. A security manager(i.e., a person (or software) to 522 make productions for security policies) can construct Content 523 Productions in the form of an expression as the following 524 productions: 526 o [cont_prod] -> [cont_prod][cont_prod] (Where duplication is 527 allowed.) 529 o [cont_prod] -> [cont_data] 531 o [cont_data] -> data_1 | data_2 | ... | data_n 533 Square brackets mean non-terminal state. If there are no non- 534 terminal states, it means that the string is completely generated. 535 When the duplication of content tag is allowed, the security manager 536 adds the first production for a rule. If there is no need to allow 537 duplication, the first production can be skipped because it is an 538 optional production. 540 The second production is the main production for Content Production 541 because it generates the tag which contains data for low-level 542 policy. Last, the third production is for injecting data into a tag 543 which is generated by the second production. If data is changed for 544 an NSF, the security manager needs to change "only the third 545 production" for data mapping in each NSF. 547 For example, if the security manager wants to express a low-level 548 policy for source IP address, Content Production can be constructed 549 in the following productions: 551 o [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.) 552 o [cont_ipv4] -> [cont_ipv4_data] 554 o [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 556 4.4.2. Structure Production 558 Structure Production is for grouping other tags into a hierarchy. 559 The security manager can construct Structure Production in the form 560 of an expression as the following production: 562 o [struct_prod] -> [prod_1]...[prod_n] 564 Structure Production can be expressed as a single production. The 565 above production means to group other tags by the name of a tag which 566 is called by 'struct_tag'. [prod_x] is a state for generating a tag 567 which wants to be grouped by Structure Production. [prod_x] can be 568 both Content Production and Structure Production. For example, if 569 the security manager wants to express the low-level policy for the 570 I2NSF tag, which is grouping 'name' and 'rules', Structure Production 571 can be constructed as the following production where [cont_name] is 572 the state for Content Production and [struct_rule] is the state for 573 Structure Production. 575 o [struct_i2nsf] -> [cont_name][struct_rules] 577 4.4.3. Generator Construction 579 The security manager can build a generator by combining the two 580 productions which are described in Section 4.4.1 and Section 4.4.2. 581 Figure 7 shows the CFG-based Generator construction of the web-filter 582 NSF. It is constructed based on the NSF-Facing Interface Data Model 583 in [nsf-facing-inf]. According to Figure 7, the security manager can 584 express productions for each clause as in following CFG: 586 1. [cont_name] -> [cont_name_data] 588 2. [cont_name_data] -> block_web 590 3. [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication) 592 4. [cont_ipv4] -> [cont_ipv4_data] 594 5. [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 596 6. [cont_url] -> [cont_url][cont_url] (Allow duplication) 598 7. [cont_url] -> [cont_url_data] 599 8. [cont_url_data] -> harm.com | illegal.com 601 9. [cont_action] -> [cont_action_data] 603 10. [cont_action_data] -> drop 605 11. [struct_packet] -> [cont_ipv4] 607 12. [struct_payload] -> [cont_url] 609 13. [struct_cond] -> 610 [struct_packet][struct_payload] 612 14. [struct_rules] -> [struct_cond][cont_action] 614 15. [struct_i2nsf] -> [cont_name][struct_rules] 616 Then, Generator generates a low-level policy by using the above CFG. 617 The low-level policy is generated by the following process: 619 1. Start: [struct_i2nsf] 621 2. Production 15: [cont_name][struct_rules] 623 3. Production 1: [cont_name_data][struct_rules] 626 4. Production 2: block_web[struct_rules] 629 5. Production 14: block_web[struct_cond][cont_action] 632 6. Production 13: block_web[struct_packet][struct_payload][cont_action] 634 636 7. Production 11: block_web[cont_ipv4][struct_payload] 638 [cont_action] 640 8. Production 3: block_web[cont_ipv4][cont_ipv4][struct_payload][cont_action] 644 9. Production 4: block_web[cont_ipv4_data][cont_ipv4_dat 646 a][struct_payload][cont_action] 649 10. Production 5: block_web10.0.0.110.0.0.3[struct_payload][cont_action] 653 11. Production 12: block_web10.0.0.110.0.0.3[cont_url][cont_action] 658 12. Production 6: block_web10.0.0.110.0.0.3[cont_url][cont_url][cont_actio 661 n] 663 13. Production 7: block_web10.0.0.110.0.0.3[cont_url_data][cont_url_data]< 666 /payload>[cont_action] 668 14. Production 8: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action] 673 15. Production 9: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action_data] 678 16. Production 10: block_web10.0.0.110.0.0.3harm.comillegal.com< 681 /condition>drop 683 The last production has no non-terminal state, and the low-level 684 policy is completely generated. Figure 8 shows the generated low- 685 level policy where tab characters and newline characters are added. 687 +-----------------------------------------------------+ 688 | +----------+ +----------+ +----------+ +----------+ | 689 Content | | Rule | | Source | | URL | | Drop | | 690 Production | | Name | | IPv4 | | Category | | Action | | 691 | +-----+----+ +-----+----+ +----+-----+ +----+-----+ | 692 | | | | | | 693 +--------------------+-----------+--------------------+ 694 | | | | 695 V V V V 696 +-------+------------+-----------+------------+-------+ 697 | | | | | | 698 | | V V | | 699 | | +----------+ +----------+ | | 700 | | | Packet | | Payload | | | 701 | | | Clause | | Clause | | | 702 | | +-----+----+ +----+-----+ | | 703 | | | | | | 704 | | V V | | 705 | | +---------------+ | | 706 | | | Condition | | | 707 Structure | | | Clause | | | 708 Production | | +-------+-------+ | | 709 | | | | | 710 | | V V | 711 | | +----------------------+ | 712 | | | Rule Clause | | 713 | | +-----------+----------+ | 714 | | | | 715 | V V | 716 | +-----------------------------------------+ | 717 | | I2NSF Clause | | 718 | +--------------------+--------------------+ | 719 | | | 720 +--------------------------+--------------------------+ 721 | 722 V 723 Low-Level Policy 725 Figure 7: Generator Construction for Web-Filter NSF 726 727 block_web 728 729 730 731 10.0.0.1 732 10.0.0.3 733 734 735 harm.com 736 illegal.com 737 738 739 drop 740 741 743 Figure 8: Example of Low-Level Policy 745 5. Features of Policy Translator Design 747 First, by showing a visualized translator structure, the security 748 manager can handle various policy changes. Translator can be shown 749 by visualizing DFA and Context-Free Grammar so that the manager can 750 easily understand the structure of Policy Translator. 752 Second, if I2NSF User only keeps the hierarchy of the data model, 753 I2NSF User can freely create high-level policies. In the case of 754 DFA, data extraction can be performed in the same way even if the 755 order of input is changed. The design of the policy translator is 756 more flexible than the existing method that works by keeping the tag 757 's position and order exactly. 759 Third, the structure of Policy Translator can be updated even while 760 Policy Translator is operating. Because Policy Translator is 761 modularized, the translator can adapt to changes in the NSF 762 capability while the I2NSF framework is running. The function of 763 changing the translator's structure can be provided through 764 Registration Interface. 766 6. Security Considerations 768 There is no security concern in a security policy translator proposed 769 in this document as long as the I2NSF interfaces (i.e., Consumer- 770 Facing Interface, NSF-Facing Interface, and Registration Interface) 771 are protected by secure communication channels. 773 7. Acknowledgments 775 This work was supported by Institute for Information & communications 776 Technology Promotion (IITP) grant funded by the Korea MSIT (Ministry 777 of Science and ICT) (R-20160222-002755, Cloud based Security 778 Intelligence Technology Development for the Customized Security 779 Service Provisioning). 781 This work was supported in part by the MSIT under the ITRC 782 (Information Technology Research Center) support program (IITP- 783 2018-2017-0-01633) supervised by the IITP. 785 8. References 787 8.1. Normative References 789 [Automata] 790 Peter, L., "Formal Languages and Automata, 6th Edition", 791 January 2016. 793 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 794 Network Configuration Protocol (NETCONF)", RFC 6020, 795 October 2010. 797 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 798 Bierman, "Network Configuration Protocol (NETCONF)", 799 RFC 6241, June 2011. 801 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 802 Protocol", RFC 8040, January 2017. 804 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 805 Kumar, "Framework for Interface to Network Security 806 Functions", RFC 8329, February 2018. 808 [XML] W3C, "On Views and XML (Extensible Markup Language)", June 809 1999. 811 8.2. Informative References 813 [consumer-facing-inf] 814 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, 815 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 816 ietf-i2nsf-consumer-facing-interface-dm-01 (work in 817 progress), July 2018. 819 [i2nsf-terminology] 820 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 821 Birkholz, "Interface to Network Security Functions (I2NSF) 822 Terminology", draft-ietf-i2nsf-terminology-06 (work in 823 progress), July 2018. 825 [nsf-facing-inf] 826 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, 827 "I2NSF Network Security Function-Facing Interface YANG 828 Data Model", draft-ietf-i2nsf-nsf-facing-interface-data- 829 model-01 (work in progress), July 2018. 831 [registration-inf] 832 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 833 Registration Interface YANG Data Model", draft-ietf-i2nsf- 834 registration-dm-00 (work in progress), October 2018. 836 [XSLT] W3C, "Extensible Stylesheet Language Transformations 837 (XSLT) Version 1.0", November 1999. 839 Appendix A. Changes from draft-yang-i2nsf-security-policy- 840 translation-01 842 The following changes are made from draft-yang-i2nsf-security-policy- 843 translation-01: 845 o In Section 3, an example is added to emphasis the necessity of a 846 security policy translator. Also, the citation for Automata 847 theory is added. 849 o In Section 3 and Section 4, some grammatical errors are corrected. 851 o In Figure 1, NSF DB component is added. 853 o In Section 4.2, an extraction scenario is added for clearer 854 explanation. 856 o In Section 4.3, an example of data conversion is added for clearer 857 explanation. Also, the detailed description and the schematic 858 diagram of policy provisioning is added. 860 o In Figure 5, the expression for each conversion is changed. 862 o In Section 4.4, an example of CFG is added for clearer 863 explanation. Also, the detailed description and the schematic 864 diagram of CFG-based Generator is added. 866 o Section 6 is added for describing "Security Considerations". 868 o The References section is divided into two subsections, such as, 869 Normative References and Informative References. Also, the 870 references for Automata theory and XML (Extensible Markup Langage) 871 are added to Normative References. In addition, the reference of 872 XSLT (Extensible Stylesheet Language Transformations) is added to 873 Informative References. 875 Authors' Addresses 877 Jinhyuk Yang 878 Department of Computer Engineering 879 Sungkyunkwan University 880 2066 Seobu-Ro, Jangan-Gu 881 Suwon, Gyeonggi-Do 16419 882 Republic of Korea 884 Phone: +82 10 8520 8039 885 EMail: jin.hyuk@skku.edu 886 Jaehoon Paul Jeong 887 Department of Software 888 Sungkyunkwan University 889 2066 Seobu-Ro, Jangan-Gu 890 Suwon, Gyeonggi-Do 16419 891 Republic of Korea 893 Phone: +82 31 299 4957 894 Fax: +82 31 290 7996 895 EMail: pauljeong@skku.edu 896 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 898 Jinyong Tim Kim 899 Department of Computer Engineering 900 Sungkyunkwan University 901 2066 Seobu-Ro, Jangan-Gu 902 Suwon, Gyeonggi-Do 16419 903 Republic of Korea 905 Phone: +82 10 8273 0930 906 EMail: timkim@skku.edu