idnits 2.17.1 draft-yang-i2nsf-security-policy-translation-07.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 : ---------------------------------------------------------------------------- == 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 149: '... an NSF, the NSF MUST receive at least...' RFC 2119 keyword, line 154: '...ntence, the user MUST know that the NS...' RFC 2119 keyword, line 162: '... policy is REQUIRED in I2NSF....' RFC 2119 keyword, line 437: '... security policy MUST be provided abst...' RFC 2119 keyword, line 539: '...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 (November 2, 2020) is 1270 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Jeong 3 Internet-Draft J. Yang 4 Intended status: Informational C. Chung 5 Expires: May 6, 2021 J. Kim 6 Sungkyunkwan University 7 November 2, 2020 9 Security Policy Translation in Interface to Network Security Functions 10 draft-yang-i2nsf-security-policy-translation-07 12 Abstract 14 This document proposes a scheme of security policy translation (i.e., 15 Security Policy Translator) in Interface to Network Security 16 Functions (I2NSF) Framework. When I2NSF User delivers a high-level 17 security policy for a security service, Security Policy Translator in 18 Security Controller translates it into a low-level security policy 19 for Network Security Functions (NSFs). For this security policy 20 translation, this document specifies the mapping between a high-level 21 security policy based on the Consumer-Facing Interface YANG data 22 model and a low-level security policy based on the NSF-Facing 23 Interface YANG data model. Also, it describes an architecture of a 24 security policy translator along with an NSF database, and the 25 process of security policy translation with the NSF database. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 6, 2021. 44 Copyright Notice 46 Copyright (c) 2020 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Necessity for Policy Translator . . . . . . . . . . . . . . . 3 64 4. Design of Policy Translator . . . . . . . . . . . . . . . . . 4 65 4.1. Overall Structure of Policy Translator . . . . . . . . . 4 66 4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . 6 67 4.2.1. Design of DFA-based Data Extractor . . . . . . . . . 6 68 4.2.2. Example Scenario for Data Extractor . . . . . . . . . 7 69 4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . 9 70 4.3.1. Role of Data Converter . . . . . . . . . . . . . . . 9 71 4.3.2. NSF Database . . . . . . . . . . . . . . . . . . . . 10 72 4.3.3. Data Conversion in Data Converter . . . . . . . . . . 12 73 4.3.4. Policy Provisioning . . . . . . . . . . . . . . . . . 20 74 4.4. CFG-based Policy Generator . . . . . . . . . . . . . . . 21 75 4.4.1. Content Production . . . . . . . . . . . . . . . . . 21 76 4.4.2. Structure Production . . . . . . . . . . . . . . . . 22 77 4.4.3. Generator Construction . . . . . . . . . . . . . . . 22 78 5. Implementation Considerations . . . . . . . . . . . . . . . . 26 79 5.1. Data Model Auto-adaptation . . . . . . . . . . . . . . . 26 80 5.2. Data Conversion . . . . . . . . . . . . . . . . . . . . . 27 81 5.3. Policy Provisioning . . . . . . . . . . . . . . . . . . . 27 82 6. Features of Policy Translator Design . . . . . . . . . . . . 27 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 88 10.2. Informative References . . . . . . . . . . . . . . . . . 29 89 Appendix A. Changes from draft-yang-i2nsf-security-policy- 90 translation-06 . . . . . . . . . . . . . . . . . . . 30 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Introduction 95 This document defines a scheme of a security policy translation in 96 Interface to Network Security Functions (I2NSF) Framework [RFC8329]. 97 First of all, this document explains the necessity of a security 98 policy translator (shortly called policy translator) in the I2NSF 99 framework. 101 The policy translator resides in Security Controller in the I2NSF 102 framework and translates a high-level security policy to a low-level 103 security policy for Network Security Functions (NSFs). A high-level 104 policy is specified by I2NSF User in the I2NSF framework and is 105 delivered to Security Controller via Consumer-Facing Interface 106 [consumer-facing-inf-dm]. It is translated into a low-level policy 107 by Policy Translator in Security Controller and is delivered to NSFs 108 to execute the rules corresponding to the low-level policy via NSF- 109 Facing Interface [nsf-facing-inf-dm]. 111 2. Terminology 113 This document uses the terminology specified in [i2nsf-terminology] 114 [RFC8329]. 116 3. Necessity for Policy Translator 118 Security Controller acts as a coordinator between I2NSF User and 119 NSFs. Also, Security Controller has capability information of NSFs 120 that are registered via Registration Interface [registration-inf-dm] 121 by Developer's Management System [RFC8329]. As a coordinator, 122 Security Controller needs to generate a low-level policy in the form 123 of security rules intended by the high-level policy, which can be 124 understood by the corresponding NSFs. 126 A high-level security policy is specified by RESTCONF/YANG 127 [RFC8040][RFC6020], and a low-level security policy is specified by 128 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level 129 security policy to the corresponding low-level security policy will 130 be able to rapidly elevate I2NSF in real-world deployment. A rule in 131 a high-level policy can include a broad target object, such as 132 employees in a company for a security service (e.g., firewall and web 133 filter). Such employees may be from human resource (HR) department, 134 software engineering department, and advertisement department. A 135 keyword of employee needs to be mapped to these employees from 136 various departments. This mapping needs to be handled by a policy 137 translator in a flexible way while understanding the intention of a 138 policy specification. Let us consider the following two policies: 140 o Block my son's computers from malicious websites. 142 o Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com 143 and illegal.com 145 The above two sentences are examples of policies for blocking 146 malicious websites. Both policies are for the same operation. 147 However, NSF cannot understand the first policy, because the policy 148 does not have any specified information for NSF. To set up the 149 policy at an NSF, the NSF MUST receive at least the source IP address 150 and website address for an operation. It means that the first 151 sentence is NOT compatible for an NSF policy. Conversely, when I2NSF 152 Users request a security policy to the system, they never make a 153 security policy like the second example. For generating a security 154 policy like the second sentence, the user MUST know that the NSF 155 needs to receive the specified information, source IP address and 156 website address. It means that the user understands the NSF 157 professionally, but there are not many professional users in a small 158 size of company or at a residential area. In conclusion, the I2NSF 159 User prefers to issue a security policy in the first sentence, but an 160 NSF will require the same policy as the second sentence with specific 161 information. Therefore, an advanced translation scheme of security 162 policy is REQUIRED in I2NSF. 164 This document proposes an approach using Automata theory [Automata] 165 for the policy translation, such as Deterministic Finite Automaton 166 (DFA) and Context Free Grammar (CFG). Note that Automata theory is 167 the foundation of programming language and compiler. Thus, with this 168 approach, I2NSF User can easily specify a high-level security policy 169 that will be enforced into the corresponding NSFs with a compatibly 170 low-level security policy with the help of Policy Translator. Also, 171 for easy management, a modularized translator structure is proposed. 173 4. Design of Policy Translator 175 Commonly used security policies are created as XML(Extensible Markup 176 Language) [XML] files. A popular way to change the format of an XML 177 file is to use an XSLT (Extensible Stylesheet Language 178 Transformation) [XSLT] document. XSLT is an XML-based language to 179 transform an input XML file into another output XML file. However, 180 the use of XSLT makes it difficult to manage the policy translator 181 and to handle the registration of new capabilities of NSFs. With the 182 necessity for a policy translator, this document describes a policy 183 translator based on Automata theory. 185 4.1. Overall Structure of Policy Translator 186 High-Level Policy 187 Security | 188 Controller V Consumer-Facing Interface 189 +------------------------+-------------------------+ 190 | Policy | | 191 | Translator | | 192 | +---------------------+----------------------+ | 193 | | | | | 194 | | +-------+--------+ | | 195 | | | DFA-based | | | 196 | | | Data Extractor | | | 197 | | +-------+--------+ | | 198 | | | Extracted Data from | | 199 | | V High-Level Policy | | 200 | | +-----+-----+ +--------+ | | 201 | | | Data | <-> | NSF DB | | | 202 | | | Converter | +--------+ | | 203 | | +-----+-----+ | | 204 | | | Required Data for | | 205 | | V Target NSFs | | 206 | | +--------+---------+ | | 207 | | | CFG-based | | | 208 | | | Policy Generator | | | 209 | | +--------+---------+ | | 210 | | | | | 211 | +---------------------+----------------------+ | 212 | | | 213 +------------------------+-------------------------+ 214 | NSF-Facing Interface 215 V 216 Low-Level Policy 218 Figure 1: The Overall Design of Policy Translator 220 Figure 1 shows the overall design for Policy Translator in Security 221 Controller. There are three main components for Policy Translator: 222 Data Extractor, Data Converter, and Policy Generator. 224 Extractor is a DFA-based module for extracting data from a high-level 225 policy which I2NSF User delivered via Consumer-Facing Interface. 226 Data Converter converts the extracted data to the capabilities of 227 target NSFs for a low-level policy. It refers to an NSF Database 228 (DB) in order to convert an abstract subject or object into the 229 corresponding concrete subject or object (e.g., IP address and 230 website URL). Policy Generator generates a low-level policy which 231 will execute the NSF capabilities from Converter. 233 4.2. DFA-based Data Extractor 235 4.2.1. Design of DFA-based Data Extractor 237 +----------+ 238 | accepter | 239 +----------+ 240 | ^ 241 | | 242 v | 243 +------------------------------------------------------+ 244 | middle 1 | 245 +------------------------------------------------------+ 246 | ^ | ^ | ^ 247 | | | | ... | | 248 v | v | v | 250 ... ... ... 252 +-------------+ +-------------+ +-------------+ 253 | extractor 1 | | extractor 2 | ... | extractor m | 254 +-------------+ +-------------+ +-------------+ 255 data:1 data:2 data:m 257 Figure 2: DFA Architecture of Data Extractor 259 Figure 2 shows a design for Data Extractor in the policy translator. 260 If a high-level policy contains data along the hierarchical structure 261 of the standard Consumer-Facing Interface YANG data model 262 [consumer-facing-inf-dm], data can be easily extracted using the 263 state transition machine, such as DFA. The extracted data can be 264 processed and used by an NSF to understand it. Extractor can be 265 constructed by designing a DFA with the same hierarchical structure 266 as a YANG data model. 268 After constructing a DFA, Data Extractor can extract all of data in 269 the entered high-level policy by using state transitions. Also, the 270 DFA can easily detect the grammar errors of the high-level policy. 271 The extracting algorithm of Data Extractor is as follows: 273 1. Start from the 'accepter' state. 275 2. Read the next tag from the high-level policy. 277 3. Transit to the corresponding state. 279 4. If the current state is in 'extractor', extract the corresponding 280 data, and then go back to step 2. 282 5. If the current state is in 'middle', go back to step 2. 284 6. If there is no possible transition and arrived at 'accepter' 285 state, the policy has no grammar error. Otherwise, there is a 286 grammar error, so stop the process with failure. 288 4.2.2. Example Scenario for Data Extractor 290 291 block_web 292 293 Son's_PC 294 malicious_websites 295 296 block 297 299 Figure 3: The Example of High-level Policy 301 +----------+ 302 | accepter | 303 +----------+ 304 | ^ 305 | | 306 v | 307 +------------------------------------------------------+ 308 | middle 1 | 309 +------------------------------------------------------+ 310 | ^ | ^ | ^ 311 | | | | | | 312 v | v | v | 313 +-------------+ +----------------------+ +-------------+ 314 | extractor 1 | | middle 2 | | extractor 4 | 315 +-------------+ +----------------------+ +-------------+ 316 block_web | ^ | ^ block 317 | | | | 318 v | v | 319 +-------------+ +-------------+ 320 | extractor 2 | | extractor 3 | 321 +-------------+ +-------------+ 322 Son's_PC malicious 323 _websites 325 Figure 4: The Example of Data Extractor 327 To explain the Data Extractor process by referring to an example 328 scenario, assume that Security Controller received a high-level 329 policy for a web-filtering as shown in Figure 3. Then we can 330 construct DFA-based Data Extractor by using the design as shown in 331 Figure 2. Figure 4 shows the architecture of Data Extractor that is 332 based on the architecture in Figure 2 along with the input high-level 333 policy in Figure 3. Data Extractor can automatically extract all of 334 data in the high-level policy according to the following process: 336 1. Start from the 'accepter' state. 338 2. Read the first opening tag called '', and transit to the 339 'middle 1' state. 341 3. Read the second opening tag called '', and transit to the 342 'extractor 1' state. 344 4. The current state is an 'extractor' state. Extract the data of 345 'name' field called 'block_web'. 347 5. Read the second closing tag called '', and go back to the 348 'middle 1' state. 350 6. Read the third opening tag called '', and transit to the 351 'middle 2' state. 353 7. Read the fourth opening tag called '', and transit to the 354 'extractor 2' state. 356 8. The current state is an 'extractor' state. Extract the data of 357 'src' field called 'Son's_PC'. 359 9. Read the fourth closing tag called '', and go back to the 360 'middle 2' state. 362 10. Read the fifth opening tag called '', and transit to the 363 'extractor 3' state. 365 11. The current state is an 'extractor' state. Extract the data of 366 'dest' field called 'malicious_websites'. 368 12. Read the fifth closing tag called '', and go back to the 369 'middle 2' state. 371 13. Read the third closing tag called '', and go back to the 372 'middle 1' state. 374 14. Read the sixth opening tag called '', and transit to the 375 'extractor 4' state. 377 15. The current state is an 'extractor' state. Extract the data of 378 'action' field called 'block'. 380 16. Read the sixth closing tag called '', and go back to 381 the 'middle 1' state. 383 17. Read the first closing tag called '', and go back to the 384 'accepter' state. 386 18. There is no further possible transition, and the state is 387 finally on 'accepter' state. There is no grammar error in 388 Figure 3 so the scanning for data extraction is finished. 390 The above process is constructed by an extracting algorithm. After 391 finishing all the steps of the above process, Data Extractor can 392 extract all of data in Figure 3, 'block_web', 'Son's_PC', 393 'malicious', and 'block'. 395 Since the translator is modularized into a DFA structure, a visual 396 understanding is feasible. Also, the performance of Data Extractor 397 is excellent compared to one-to-one searching of data for a 398 particular field. In addition, the management is efficient because 399 the DFA completely follows the hierarchy of Consumer-Facing 400 Interface. If I2NSF User wants to modify the data model of a high- 401 level policy, it only needs to change the connection of the relevant 402 DFA node. 404 4.3. Data Converter 406 4.3.1. Role of Data Converter 408 Every NSF has its own unique capabilities. The capabilities of an 409 NSF are registered into Security Controller by a Developer's 410 Management System, which manages the NSF, via Registration Interface. 411 Therefore, Security Controller already has all information about the 412 capabilities of NSFs. This means that Security Controller can find 413 target NSFs with only the data (e.g., subject and object for a 414 security policy) of the high-level policy by comparing the extracted 415 data with all capabilities of each NSF. This search process for 416 appropriate NSFs is called by policy provisioning, and it eliminates 417 the need for I2NSF User to specify the target NSFs explicitly in a 418 high-level security policy. 420 Data Converter selects target NSFs and converts the extracted data 421 into the capabilities of selected NSFs. If Security Controller uses 422 this data convertor, it can provide the policy provisioning function 423 to I2NSF User automatically. Thus, the translator design provides 424 big benefits to the I2NSF Framework. 426 4.3.2. NSF Database 428 The NSF Database contains all the information needed to convert high- 429 level policy data to low-level policy data. The contents of NSF 430 Database are classified as the following two: "endpoint information" 431 and "NSF capability information". 433 The first is "endpoint information". Endpoint information is 434 necessary to convert an abstract high-level policy data such as 435 Son's_PC, malicious to a specific low-level policy data such as 436 10.0.0.1, illegal.com. In the high-level policy, the range of 437 endpoints for applying security policy MUST be provided abstractly. 438 Thus, endpoint information is needed to specify the abstracted high- 439 level policy data. Endpoint information is provided by I2NSF User as 440 the high-level policy through Consumer-Facing Interface, and Security 441 Controller builds NSF Database based on received information. 443 The second is "NSF capability information". Since capability is 444 information that allows NSF to know what features it can support, NSF 445 capability information is used in policy provisioning process to 446 search the appropriate NSFs through the security policy. NSF 447 capability information is provided by Developer's Management System 448 (DMS) through Registration Interface, and Security Controller builds 449 NSF Database based on received information. In addition, if the NSF 450 sends monitoring information such as initiating information to 451 Security Controller through NSF-Facing Interface, Security Controller 452 can modify NSF Database accordingly. 454 NSF Capability Information Endpoint Information 455 +-------------------+ has convert +------------------+ 456 | NSF +||---+ +-------||+ Endpoint | 457 +-------------------+ | | +------------------+ 458 | *nsf_id (INT) | | | | *end_id (INT) | 459 | nsf_name (STRING) | | | | keyword (STRING) | 460 | inbound (INT) | | | +------------------+ 461 | outbound (INT) | | | 462 | bandwidth (INT) | | | 463 | activated (BOOL) | | | 464 +-------------------+ | | 465 +---------------+ | 466 /|\ | 467 +--------------------+ has | 468 | Capability +||---+ | 469 +--------------------+ | | 470 | *capa_id (INT) | | | 471 | capa_name (STRING) | | | 472 | capa_index (INT) | | | 473 +--------------------+ | | 474 /|\ /|\ 475 +-----------------------+ 476 | Field | 477 +-----------------------+ 478 | *field_id (INT) | 479 | field_name (STRING) | 480 | field_index (INT) | 481 | mapped_data (STRING) | 482 +-----------------------+ 484 Figure 5: Entity-Relationship Diagram of NSF Database 486 Figure 5 shows an Entity-Relationship Diagram (ERD) of NSF Database 487 designed to include both endpoint information received from I2NSF 488 User and NSF capability information received from DMS. By designing 489 the NSF database based on the ERD, all the information necessary for 490 security policy translation can be stored, and the network system 491 administrator can manage the NSF database efficiently. 493 ERD was expressed by using Crow's Foot notation. Crow's Foot 494 notation represents a relationship between entities as a line and 495 represents the cardinality of the relationship as a symbol at both 496 ends of the line. Attributes prefixed with * are key values of each 497 entity. A link with two vertical lines represents one-to-one 498 mapping, and a bird-shaped link represents one-to-many mapping. An 499 NSF entity stores the NSF name (nsf_name), NSF specification 500 (inbound, outbound, bandwidth), and NSF activation (activated). A 501 Capability entity stores the capability name (capa_name) and the 502 index of the capability field in a Registration Interface Data Model 503 (capa_index). An Endpoint entity stores the keyword of abstract data 504 conversion from I2NSF User (keyword). A Field entity stores the 505 field name (field_name), the index of the field index in an NSF- 506 Facing Interface Data Model, and converted data by referring to the 507 Endpoint entity and a 'convert' relationship. 509 4.3.3. Data Conversion in Data Converter 511 High-level Low-level 512 Policy Data Policy Data 513 +---------------+ +------------------------------+ 514 | Rule Name | | Rule Name | 515 | +-----------+ | The Same value | +-------------------------+ | 516 | | block_web |-|------------------->|->| block_web | | 517 | +-----------+ | | +-------------------------+ | 518 | | | | 519 | Source | Conversion into | Source IPv4 | 520 | +-----------+ | User's IP address | +-------------------------+ | 521 | | Son's_PC |-|------------------->|->| [10.0.0.1, 10.0.0.3] | | 522 | +-----------+ | | +-------------------------+ | 523 | | | | 524 | Destination | Conversion into | URL Category | 525 | +-----------+ | malicious websites | +-------------------------+ | 526 | | malicious |-|------------------->|->| [harm.com, | | 527 | | _websites | | | | illegal.com] | | 528 | +-----------+ | | +-------------------------+ | 529 | | | | 530 | Action | Conversion into | Log Action Drop Action | 531 | +-----------+ | NSF Capability | +----------+ +----------+ | 532 | | block |-|------------------->|->| True | | True | | 533 | +-----------+ | | +----------+ +----------+ | 534 +---------------+ +------------------------------+ 536 Figure 6: Example of Data Conversion 538 Figure 6 shows an example for describing a data conversion in Data 539 Converter. High-level policy data MUST be converted into low-level 540 policy data which are compatible with NSFs. If a system 541 administrator attaches a database to Data Converter, it can convert 542 contents by referring to the database with SQL queries. Data 543 conversion in Figure 6 is based on the following list: 545 o 'Rule Name' field does NOT need the conversion. 547 o 'Source' field SHOULD be converted into a list of target IPv4 548 addresses. 550 o 'Destination' field SHOULD be converted into a URL category list 551 of malicious websites. 553 o 'Action' field SHOULD be converted into the corresponding 554 action(s) in NSF capabilities. 556 Figure 7 shows a mapping list of data fields between Consumer-Facing 557 Interface Data Model and NSF-Facing Interface Data Model. Figure 7 558 describes the process of passing the data value to the appropriate 559 data field of the Data Model in detail after the data conversion. 561 #policy name mapping 562 /consumer-facing/policy/policy-name 563 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 564 /system-policy-name 566 #rule name mapping 567 /consumer-facing/policy/rule/rule-name 568 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 569 /rules/rule-name 571 #start time mapping 572 /consumer-facing/policy 573 /rule/event/time-information/time/begin-time 574 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 575 /rules/time-zone/absolute-time-zone/start-time 577 #end time mapping 578 /consumer-facing/policy 579 /rule/event/time-information/time/end-time 580 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 581 /rules/time-zone/absolute-time-zone/end-time 583 #firewall-condition source target reference and mapping 584 /consumer-facing/policy/rule/condition 585 /firewall-condition/source-target/src-target 586 -> reference: /consumer-facing/policy 587 /endpoint-group/user-group/name 588 -> extract: /consumer-facing/policy 589 /endpoint-group/user-group/date 590 -> mapping: /nsf-facing/i2nsf-security-policy 591 /rule/date 592 -> extract: /consumer-facing/policy 593 /endpoint-group/user-group/ip-address 594 -> mapping: /nsf-facing/i2nsf-security-policy 595 /system-policy/rules 596 /condition-clause-container 597 /packet-security-ipv4-condition 598 /pkt-sec-ipv4-src/ipv4-address/ipv4 599 -> extract: /consumer-facing/policy 600 /endpoint-group/user-group/range-ip-address 601 /start-ip-address 602 -> mapping: /nsf-facing/i2nsf-security-policy 603 /system-policy/rules 604 /condition-clause-container 605 /packet-security-ipv4-condition 606 /pkt-sec-ipv4-src/range-ipv4-address 607 /start-ipv4-address 608 -> extract: /consumer-facing/policy 609 /endpoint-group/user-group/range-ip-address 610 /end-ip-address 611 -> mapping: /nsf-facing/i2nsf-security-policy 612 /system-policy/rules 613 /condition-clause-container 614 /packet-security-ipv4-condition 615 /pkt-sec-ipv4-src/range-ipv4-address 616 /end-ipv4-address 618 #firewall-condition destination target reference and mapping 619 /consumer-facing/policy/rule/condition 620 /firewall-condition/destination-target/dest-target 621 -> reference: /consumer-facing/policy 622 /endpoint-group/user-group/name 623 -> extract: /consumer-facing/policy 624 /endpoint-group/user-group/date 625 -> mapping: /nsf-facing/i2nsf-security-policy 626 /system-policy/rule/date 627 -> extract: /consumer-facing/policy 628 /endpoint-group/user-group/ip-address 629 -> mapping: /nsf-facing/i2nsf-security-policy 630 /system-policy/rules 631 /condition-clause-container 632 /packet-security-ipv4-condition 633 /pkt-sec-ipv4-dest/ipv4-address/ipv4 634 -> extract: /consumer-facing/policy 635 /endpoint-group/user-group 636 /range-ip-address/start-ip-address 637 -> mapping: /nsf-facing/i2nsf-security-policy 638 /system-policy/rules 639 /condition-clause-container 640 /packet-security-ipv4-condition 641 /pkt-sec-ipv4-dest/range-ipv4-address 642 /start-ipv4-address 643 -> extract: /consumer-facing/policy 644 /endpoint-group/user-group 645 /range-ip-address/end-ip-address 646 -> mapping: /nsf-facing/i2nsf-security-policy 647 /system-policy/rules 648 /condition-clause-container 649 /packet-security-ipv4-condition 650 /pkt-sec-ipv4-dest/range-ipv4-address 651 /end-ipv4-address 653 #ddos-condition source target reference and mapping 654 /consumer-facing/policy/rule/condition 655 /ddos-condition/source-target/src-target 656 -> reference: /consumer-facing/policy 657 /endpoint-group/device-group/name 658 -> extract: /consumer-facing/policy 659 /endpoint-group/device-group/date 660 -> mapping: /nsf-facing/i2nsf-security-policy/rule/date 661 -> extract: /consumer-facing/policy 662 /endpoint-group/device-group/ip-address 663 -> mapping: /nsf-facing/i2nsf-security-policy 664 /system-policy/rules 665 /condition-clause-container 666 /packet-security-ipv4-condition 667 /pkt-sec-ipv4-src/ipv4-address/ipv4 668 -> extract: /consumer-facing/policy 669 /endpoint-group/device-group 670 /range-ip-address/start-ip-address 671 -> mapping: /nsf-facing/i2nsf-security-policy 672 /system-policy/rules 673 /condition-clause-container 674 /packet-security-ipv4-condition 675 /pkt-sec-ipv4-src/range-ipv4-address 676 /start-ipv4-address 677 -> extract: /consumer-facing/policy 678 /endpoint-group/device-group 679 /range-ip-address/end-ip-address 680 -> mapping: /nsf-facing/i2nsf-security-policy 681 /system-policy/rules 682 /condition-clause-container 683 /packet-security-ipv4-condition 684 /pkt-sec-ipv4-src/range-ipv4-address 685 /end-ipv4-address 687 #ddos-condition destination target reference and mapping 688 /consumer-facing/policy/rule/condition 689 /ddos-condition/destination-target/dest-target 690 -> reference: /consumer-facing/policy 691 /endpoint-group/device-group/name 692 -> extract: /consumer-facing/policy 693 /endpoint-group/device-group/date 694 -> mapping: /nsf-facing/i2nsf-security-policy/rule/date 695 -> extract: /consumer-facing/policy 696 /endpoint-group/device-group/ip-address 697 -> mapping: /nsf-facing/i2nsf-security-policy 698 /system-policy/rules 699 /condition-clause-container 700 /packet-security-ipv4-condition 701 /pkt-sec-ipv4-dest/ipv4-address/ipv4 702 -> extract: /consumer-facing/policy 703 /endpoint-group/device-group 704 /range-ip-address/start-ip-address 705 -> mapping: /nsf-facing/i2nsf-security-policy 706 /system-policy/rules 707 /condition-clause-container 708 /packet-security-ipv4-condition 709 /pkt-sec-ipv4-dest/range-ipv4-address 710 /start-ipv4-address 711 -> extract: /consumer-facing/policy 712 /endpoint-group/device-group 713 /range-ip-address/end-ip-address 714 -> mapping: /nsf-facing/i2nsf-security-policy 715 /system-policy/rules 716 /condition-clause-container 717 /packet-security-ipv4-condition 718 /pkt-sec-ipv4-dest/range-ipv4-address 719 /end-ipv4-address 721 #ddos-condition packet per second mapping 722 /consumer-facing/policy/rule/condition 723 /ddos-condition/rate-limit/packet-per-second 724 -> mapping: /nsf-facing/i2nsf-security-policy 725 /system-policy/rules/condition-clause-container 726 /packet-security-ddos-condition/pkt-sec-alert-rate 728 #threat-prevention source target reference and mapping 729 /consumer-facing/policy/rule/condition 730 /custom-condition/source-target/src-target 731 -> reference: /consumer-facing/policy 732 /threat-prevention/payload-content/name 733 -> extract: /consumer-facing/policy 734 /threat-prevention/payload-content/date 735 -> mapping: /nsf-facing/i2nsf-security-policy 736 /system-policy/rules/date 737 -> extract: /consumer-facing/policy 738 /threat-prevention/payload-content/content 739 -> mapping: /nsf-facing/i2nsf-security-policy 740 /system-policy/rules 741 /condition-clause-container 742 /packet-security-payload-condition 743 /pkt-payload-content 745 #threat-prevention destination target reference and mapping 746 /consumer-facing/policy/rule/condition 747 /custom-condition/destination-target/dest-target 748 -> reference: /consumer-facing/policy 749 /threat-prevention/payload-content/name 750 -> extract: /consumer-facing/policy 751 /threat-prevention/payload-content/date 752 -> mapping: /nsf-facing/i2nsf-security-policy 753 /system-policy/rules/date 754 -> extract: /consumer-facing/policy 755 /threat-prevention/payload-content/content 756 -> mapping: /nsf-facing/i2nsf-security-policy 757 /system-policy/rules 758 /condition-clause-container 759 /packet-security-payload-condition 760 /pkt-payload-content 762 #threat-feed-condition source target reference and mapping 763 /consumer-facing/policy/rule/condition 764 /custom-condition/threat-feed-condition 765 /source-target/src-target 766 -> reference: /consumer-facing/policy 767 /threat-prevention/threat-feed-list/name 768 -> extract: /consumer-facing/policy 769 /threat-prevention/threat-feed-list/date 770 -> mapping: /nsf-facing/i2nsf-security-policy 771 /system-policy/rules/date 772 -> extract: /consumer-facing/policy 773 /threat-prevention/threat-feed-list 774 /threat-feed-server/ip-address 775 -> mapping: /nsf-facing/i2nsf-security-policy 776 /system-policy/rules 777 /condition-clause-container 778 /packet-security-ipv4-condition 779 /pkt-sec-ipv4-src/ipv4-address/ipv4 780 -> extract: /consumer-facing/policy 781 /threat-prevention/threat-feed-list 782 /threat-feed-server/range-ip-address 783 /start-ip-address 784 -> mapping: /nsf-facing/i2nsf-security-policy 785 /system-policy/rules 786 /condition-clause-container 787 /packet-security-ipv4-condition 788 /pkt-sec-ipv4-src/range-ipv4-address 789 /start-ipv4-address 790 -> extract: /consumer-facing/policy 791 /threat-prevention/threat-feed-list 792 /threat-feed-server/range-ip-address 793 /end-ip-address 794 -> mapping: /nsf-facing/i2nsf-security-policy 795 /system-policy/rules 796 /condition-clause-container 797 /packet-security-ipv4-condition 798 /pkt-sec-ipv4-src/range-ipv4-address 799 /end-ipv4-address 800 -> extract: /consumer-facing/policy 801 /threat-prevention/threat-feed-list 802 /threat-feed-server 803 /threat-feed-description 804 -> mapping: /nsf-facing/i2nsf-security-policy 805 /system-policy/rules 806 /condition-clause-container 807 /packet-security-ipv4-condition 808 /ipv4-description 810 #threat-feed-condition destination target reference and mapping 811 /consumer-facing/policy/rule/condition 812 /custom-condition/threat-feed-condition 813 /destination-target/dest-target 814 -> reference: /consumer-facing/policy 815 /threat-prevention/threat-feed-list/name 816 -> extract: /consumer-facing/policy 817 /threat-prevention/threat-feed-list/date 818 -> mapping: /nsf-facing/i2nsf-security-policy 819 /system-policy/rules/date 820 -> extract: /consumer-facing/policy 821 /threat-prevention/threat-feed-list 822 /threat-feed-server/ip-address 823 -> mapping: /nsf-facing/i2nsf-security-policy 824 /system-policy/rules 825 /condition-clause-container 826 /packet-security-ipv4-condition 827 /pkt-sec-ipv4-dest/ipv4-address/ipv4 828 -> extract: /consumer-facing/policy 829 /threat-prevention/threat-feed-list 830 /threat-feed-server/range-ip-address 831 /start-ip-address 832 -> mapping: /nsf-facing/i2nsf-security-policy 833 /system-policy/rules 834 /condition-clause-container 835 /packet-security-ipv4-condition 836 /pkt-sec-ipv4-dest/range-ipv4-address 837 /start-ipv4-address 838 -> extract: /consumer-facing/policy 839 /threat-prevention/threat-feed-list 840 /threat-feed-server/range-ip-address 841 /end-ip-address 842 -> mapping: /nsf-facing/i2nsf-security-policy 843 /system-policy/rules 844 /condition-clause-container 845 /packet-security-ipv4-condition 846 /pkt-sec-ipv4-dest/range-ipv4-address 847 /end-ipv4-address 848 -> extract: /consumer-facing/policy 849 /threat-prevention/threat-feed-list 850 /threat-feed-server 851 /threat-feed-description 852 -> mapping: /nsf-facing/i2nsf-security-policy 853 /system-policy/rules 854 /condition-clause-container 855 /packet-security-ipv4-condition 856 /ipv4-description 858 #rule action name mapping 859 /consumer-facing/policy/rule/action/name 860 -> mapping: /nsf-facing/i2nsf-security-policy 861 /system-policy/rules/action-clause-container 862 /packet-action/ingress-action 863 -> mapping: /nsf-facing/i2nsf-security-policy 864 /system-policy/rules/action-clause-container 865 /packet-action/egress-action 866 -> mapping: /nsf-facing/i2nsf-security-policy 867 /system-policy/rules/action-clause-container 868 /packet-action/log-action 869 -> mapping: /nsf-facing/i2nsf-security-policy 870 /system-policy/rules/action-clause-container 871 /advanced-action/content-security-control 872 -> mapping: /nsf-facing/i2nsf-security-policy 873 /system-policy/rules/action-clause-container 874 /advanced-action/attack-mitigation-control 876 #ipsec-method mapping 877 /consumer-facing/policy/rule/ipsec-method 878 -> mapping: /nsf-facing/i2nsf-ipsec 880 #policy domain name mapping 881 /consumer-facing/policy-domain/name 882 -> mapping: /nsf-facing/i2nsf-security-policy 883 /system-policy/rule-group/groups/group-name 885 Figure 7: Mapping Information for Data Conversion 887 4.3.4. Policy Provisioning 889 Log-keeper Low-level Web-filter 890 NSF Policy Data NSF 891 +-------------------+ +--------------------+ +-------------------+ 892 | Rule Name | | Rule Name | | Rule Name | 893 | +--------------+ | | +--------------+ | | +--------------+ | 894 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | | 895 | +--------------+ | | +--------------+ | | +--------------+ | 896 | | | | | | 897 | Source IPv4 | | Source IPv4 | | Source IPv4 | 898 | +--------------+ | | +--------------+ | | +--------------+ | 899 | | [10.0.0.1, |<-|<-|<-| [10.0.0.1, |->|->|->| [10.0.0.1, | | 900 | | 10.0.0.3] | | | | 10.0.0.3] | | | | 10.0.0.3] | | 901 | +--------------+ | | +--------------+ | | +--------------+ | 902 | | | | | | 903 | | | URL Category | | URL Category | 904 | | | +--------------+ | | +--------------+ | 905 | | | | [harm.com, |->|->|->| [harm.com, | | 906 | | | | illegal.com] | | | | illegal.com] | | 907 | | | +--------------+ | | +--------------+ | 908 | | | | | | 909 | Log Action | | Log Action | | | 910 | +--------------+ | | +--------------+ | | | 911 | | True |<-|<-|<-| True | | | | 912 | +--------------+ | | +--------------+ | | | 913 +-------------------+ | | | | 914 | Drop Action | | Drop Action | 915 | +--------------+ | | +--------------+ | 916 | | True |->|->|->| True | | 917 | +--------------+ | | +--------------+ | 918 +--------------------+ +-------------------+ 920 Figure 8: Example of Policy Provisioning 922 Generator searches for proper NSFs which can cover all of 923 capabilities in the high-level policy. Generator searches for target 924 NSFs by comparing only NSF capabilities which is registered by Vendor 925 Management System. This process is called by "policy provisioning" 926 because Generator finds proper NSFs by using only the policy. If 927 target NSFs are found by using other data which is not included in a 928 user's policy, it means that the user already knows the specific 929 knowledge of an NSF in the I2NSF Framework. Figure 8 shows an 930 example of policy provisioning. In this example, log-keeper NSF and 931 web-filter NSF are selected for covering capabilities in the security 932 policy. All of capabilities can be covered by two selected NSFs. 934 4.4. CFG-based Policy Generator 936 Generator makes low-level security policies for each target NSF with 937 the extracted data. We constructed Generator by using Context Free 938 Grammar (CFG). CFG is a set of production rules which can describe 939 all possible strings in a given formal language(e.g., programming 940 language). The low-level policy also has its own language based on a 941 YANG data model of NSF-Facing Interface. Thus, we can construct the 942 productions based on the YANG data model. The productions that makes 943 up the low-level security policy are categorized into two types, 944 'Content Production' and 'Structure Production'. 946 4.4.1. Content Production 948 Content Production is for injecting data into low-level policies to 949 be generated. A security manager(i.e., a person (or software) to 950 make productions for security policies) can construct Content 951 Productions in the form of an expression as the following 952 productions: 954 o [cont_prod] -> [cont_prod][cont_prod] (Where duplication is 955 allowed.) 957 o [cont_prod] -> [cont_data] 959 o [cont_data] -> data_1 | data_2 | ... | data_n 961 Square brackets mean non-terminal state. If there are no non- 962 terminal states, it means that the string is completely generated. 963 When the duplication of content tag is allowed, the security manager 964 adds the first production for a rule. If there is no need to allow 965 duplication, the first production can be skipped because it is an 966 optional production. 968 The second production is the main production for Content Production 969 because it generates the tag which contains data for low-level 970 policy. Last, the third production is for injecting data into a tag 971 which is generated by the second production. If data is changed for 972 an NSF, the security manager needs to change "only the third 973 production" for data mapping in each NSF. 975 For example, if the security manager wants to express a low-level 976 policy for source IP address, Content Production can be constructed 977 in the following productions: 979 o [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.) 981 o [cont_ipv4] -> [cont_ipv4_data] 982 o [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 984 4.4.2. Structure Production 986 Structure Production is for grouping other tags into a hierarchy. 987 The security manager can construct Structure Production in the form 988 of an expression as the following production: 990 o [struct_prod] -> [prod_1]...[prod_n] 992 Structure Production can be expressed as a single production. The 993 above production means to group other tags by the name of a tag which 994 is called by 'struct_tag'. [prod_x] is a state for generating a tag 995 which wants to be grouped by Structure Production. [prod_x] can be 996 both Content Production and Structure Production. For example, if 997 the security manager wants to express the low-level policy for the 998 I2NSF tag, which is grouping 'name' and 'rules', Structure Production 999 can be constructed as the following production where [cont_name] is 1000 the state for Content Production and [struct_rule] is the state for 1001 Structure Production. 1003 o [struct_i2nsf] -> [cont_name][struct_rules] 1005 4.4.3. Generator Construction 1007 The security manager can build a generator by combining the two 1008 productions which are described in Section 4.4.1 and Section 4.4.2. 1009 Figure 9 shows the CFG-based Generator construction of the web-filter 1010 NSF. It is constructed based on the NSF-Facing Interface Data Model 1011 in [nsf-facing-inf-dm]. According to Figure 9, the security manager 1012 can express productions for each clause as in following CFG: 1014 1. [cont_name] -> [cont_name_data] 1016 2. [cont_name_data] -> block_web 1018 3. [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication) 1020 4. [cont_ipv4] -> [cont_ipv4_data] 1022 5. [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 1024 6. [cont_url] -> [cont_url][cont_url] (Allow duplication) 1026 7. [cont_url] -> [cont_url_data] 1028 8. [cont_url_data] -> harm.com | illegal.com 1029 9. [cont_action] -> [cont_action_data] 1031 10. [cont_action_data] -> drop 1033 11. [struct_packet] -> [cont_ipv4] 1035 12. [struct_payload] -> [cont_url] 1037 13. [struct_cond] -> 1038 [struct_packet][struct_payload] 1040 14. [struct_rules] -> [struct_cond][cont_action] 1042 15. [struct_i2nsf] -> [cont_name][struct_rules] 1044 Then, Generator generates a low-level policy by using the above CFG. 1045 The low-level policy is generated by the following process: 1047 1. Start: [struct_i2nsf] 1049 2. Production 15: [cont_name][struct_rules] 1051 3. Production 1: [cont_name_data][struct_rules] 1054 4. Production 2: block_web[struct_rules] 1057 5. Production 14: block_web[struct_cond][cont_action] 1060 6. Production 13: block_web[struct_packet][struct_payload][cont_action] 1062 1064 7. Production 11: block_web[cont_ipv4][struct_payload] 1066 [cont_action] 1068 8. Production 3: block_web[cont_ipv4][cont_ipv4][struct_payload][cont_action] 1072 9. Production 4: block_web[cont_ipv4_data][cont_ipv4_dat 1074 a][struct_payload][cont_action] 1077 10. Production 5: block_web10.0.0.110.0.0.3[struct_payload][cont_action] 1081 11. Production 12: block_web10.0.0.110.0.0.3[cont_url][cont_action] 1086 12. Production 6: block_web10.0.0.110.0.0.3[cont_url][cont_url][cont_actio 1089 n] 1091 13. Production 7: block_web10.0.0.110.0.0.3[cont_url_data][cont_url_data]< 1094 /payload>[cont_action] 1096 14. Production 8: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action] 1101 15. Production 9: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action_data] 1106 16. Production 10: block_web10.0.0.110.0.0.3harm.comillegal.com< 1109 /condition>drop 1111 The last production has no non-terminal state, and the low-level 1112 policy is completely generated. Figure 10 shows the generated low- 1113 level policy where tab characters and newline characters are added. 1115 +-----------------------------------------------------+ 1116 | +----------+ +----------+ +----------+ +----------+ | 1117 Content | | Rule | | Source | | URL | | Drop | | 1118 Production | | Name | | IPv4 | | Category | | Action | | 1119 | +-----+----+ +-----+----+ +----+-----+ +----+-----+ | 1120 | | | | | | 1121 +--------------------+-----------+--------------------+ 1122 | | | | 1123 V V V V 1124 +-------+------------+-----------+------------+-------+ 1125 | | | | | | 1126 | | V V | | 1127 | | +----------+ +----------+ | | 1128 | | | Packet | | Payload | | | 1129 | | | Clause | | Clause | | | 1130 | | +-----+----+ +----+-----+ | | 1131 | | | | | | 1132 | | V V | | 1133 | | +---------------+ | | 1134 | | | Condition | | | 1135 Structure | | | Clause | | | 1136 Production | | +-------+-------+ | | 1137 | | | | | 1138 | | V V | 1139 | | +----------------------+ | 1140 | | | Rule Clause | | 1141 | | +-----------+----------+ | 1142 | | | | 1143 | V V | 1144 | +-----------------------------------------+ | 1145 | | I2NSF Clause | | 1146 | +--------------------+--------------------+ | 1147 | | | 1148 +--------------------------+--------------------------+ 1149 | 1150 V 1151 Low-Level Policy 1153 Figure 9: Generator Construction for Web-Filter NSF 1154 1155 block_web 1156 1157 1158 1159 10.0.0.1 1160 10.0.0.3 1161 1162 1163 harm.com 1164 illegal.com 1165 1166 1167 drop 1168 1169 1171 Figure 10: Example of Low-Level Policy 1173 5. Implementation Considerations 1175 The implementation considerations in this document include the 1176 following three: "data model auto-adaptation", "data conversion", and 1177 "policy provisioning". 1179 5.1. Data Model Auto-adaptation 1181 Security Controller which acts as the intermediary MUST process the 1182 data according to the data model of the connected interfaces. 1183 However, the data model can be changed flexibly depending on the 1184 situation, and Security Controller may adapt to the change. 1185 Therefore, Security Controller can be implemented for convenience so 1186 that the security policy translator can easily adapt to the change of 1187 the data model. 1189 The translator constructs and uses the DFA to adapt to Consumer- 1190 Facing Interface Data Model. In addition, the CFG is constructed and 1191 used to adapt to NSF-Facing Interface Data Model. Both the DFA and 1192 the CFG follow the same tree structure of YANG Data Model. 1194 The DFA starts at the node and expands operations by changing the 1195 state according to the input. Based on the YANG Data Model, a 1196 container node is defined as a middle state and a leaf node is 1197 defined as an extractor node. After that, if the nodes are connected 1198 in the same way as the hierarchical structure of the data model, 1199 Security Controller can automatically construct the DFA. The DFA can 1200 be conveniently built by investigating the link structure using the 1201 stack, starting with the root node. 1203 The CFG starts at the leaf nodes and is grouped into clauses until 1204 all the nodes are merged into one node. A leaf node is defined as 1205 the content production, and a container node is defined as the 1206 structure production. After that, if the nodes are connected in the 1207 same way as the hierarchy of the data model, Security Controller can 1208 automatically construct the CFG. The CFG can be conveniently 1209 constructed by investigating the link structure using the priority 1210 queue data, starting with the leaf nodes. 1212 5.2. Data Conversion 1214 Security Controller requires the ability to materialize the abstract 1215 data in the high-level security policy and forward it to NSFs. 1216 Security Controller can receive endpoint information as keywords 1217 through the high-level security policy. At this time, if the 1218 endpoint information corresponding to the keyword is mapped and the 1219 query is transmitted to the NSF Database, the NSF Database can be 1220 conveniently registered with necessary information for data 1221 conversion. When a policy tries to establish a policy through the 1222 keyword, Security Controller searches the details corresponding to 1223 the keyword registered in the NSF Database and converts the keywords 1224 into the appropriate and specified data. 1226 5.3. Policy Provisioning 1228 This document stated that policy provisioning function is necessary 1229 to enable users without expert security knowledge to create policies. 1230 Policy provisioning is determined by the capability of the NSF. If 1231 the NSF has information about the capability in the policy, the 1232 probability of selection increases. 1234 Most importantly, selected NSFs may be able to perform all 1235 capabilities in the security policy. This document recommends a 1236 study of policy provisioning algorithms that are highly efficient and 1237 can satisfy all capabilities in the security policy. 1239 6. Features of Policy Translator Design 1241 First, by showing a visualized translator structure, the security 1242 manager can handle various policy changes. Translator can be shown 1243 by visualizing DFA and Context-free Grammar so that the manager can 1244 easily understand the structure of Policy Translator. 1246 Second, if I2NSF User only keeps the hierarchy of the data model, 1247 I2NSF User can freely create high-level policies. In the case of 1248 DFA, data extraction can be performed in the same way even if the 1249 order of input is changed. The design of the policy translator is 1250 more flexible than the existing method that works by keeping the tag 1251 's position and order exactly. 1253 Third, the structure of Policy Translator can be updated even while 1254 Policy Translator is operating. Because Policy Translator is 1255 modularized, the translator can adapt to changes in the NSF 1256 capability while the I2NSF framework is running. The function of 1257 changing the translator's structure can be provided through 1258 Registration Interface. 1260 7. Security Considerations 1262 There is no security concern in the proposed security policy 1263 translator as long as the I2NSF interfaces (i.e., Consumer-Facing 1264 Interface, NSF-Facing Interface, and Registration Interface) are 1265 protected by secure communication channels. 1267 8. IANA Considerations 1269 This document does not require any IANA actions. 1271 9. Acknowledgments 1273 This work was supported by Institute of Information & Communications 1274 Technology Planning & Evaluation (IITP) grant funded by the Ministry 1275 of Science and ICT (MSIT), Korea, (R-20160222-002755, Cloud based 1276 Security Intelligence Technology Development for the Customized 1277 Security Service Provisioning). 1279 This work was supported in part by the MSIT under the Information 1280 Technology Research Center (ITRC) support program (IITP- 1281 2019-2017-0-01633) supervised by the IITP. 1283 10. References 1285 10.1. Normative References 1287 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1288 Network Configuration Protocol (NETCONF)", RFC 6020, 1289 October 2010. 1291 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1292 Bierman, "Network Configuration Protocol (NETCONF)", 1293 RFC 6241, June 2011. 1295 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1296 Protocol", RFC 8040, January 2017. 1298 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1299 Kumar, "Framework for Interface to Network Security 1300 Functions", RFC 8329, February 2018. 1302 10.2. Informative References 1304 [Automata] 1305 Peter, L., "Formal Languages and Automata, 6th Edition", 1306 January 2016. 1308 [consumer-facing-inf-dm] 1309 Jeong, J., Chung, C., Ahn, T., Kumar, R., and S. Hares, 1310 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 1311 ietf-i2nsf-consumer-facing-interface-dm-08 (work in 1312 progress), March 2020. 1314 [i2nsf-terminology] 1315 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1316 Birkholz, "Interface to Network Security Functions (I2NSF) 1317 Terminology", draft-ietf-i2nsf-terminology-08 (work in 1318 progress), July 2019. 1320 [nsf-facing-inf-dm] 1321 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, 1322 "I2NSF Network Security Function-Facing Interface YANG 1323 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-09 1324 (work in progress), May 2020. 1326 [registration-inf-dm] 1327 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 1328 Registration Interface YANG Data Model", draft-ietf-i2nsf- 1329 registration-interface-dm-08 (work in progress), March 1330 2020. 1332 [XML] W3C, "On Views and XML (Extensible Markup Language)", June 1333 1999. 1335 [XSLT] W3C, "Extensible Stylesheet Language Transformations 1336 (XSLT) Version 1.0", November 1999. 1338 Appendix A. Changes from draft-yang-i2nsf-security-policy- 1339 translation-06 1341 The following changes are made from draft-yang-i2nsf-security-policy- 1342 translation-06: 1344 o The version has a submission date update to maintain the active 1345 status of the draft. 1347 o The version updates the version numbers of the referenced drafts. 1349 Authors' Addresses 1351 Jaehoon Paul Jeong 1352 Department of Computer Science and Engineering 1353 Sungkyunkwan University 1354 2066 Seobu-Ro, Jangan-Gu 1355 Suwon, Gyeonggi-Do 16419 1356 Republic of Korea 1358 Phone: +82 31 299 4957 1359 Fax: +82 31 290 7996 1360 EMail: pauljeong@skku.edu 1361 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1363 Jinhyuk Yang 1364 Department of Electronic, Electrical and Computer Engineering 1365 Sungkyunkwan University 1366 2066 Seobu-Ro, Jangan-Gu 1367 Suwon, Gyeonggi-Do 16419 1368 Republic of Korea 1370 Phone: +82 10 8520 8039 1371 EMail: jin.hyuk@skku.edu 1373 Chaehong Chung 1374 Department of Electronic, Electrical and Computer Engineering 1375 Sungkyunkwan University 1376 2066 Seobu-Ro, Jangan-Gu 1377 Suwon, Gyeonggi-Do 16419 1378 Republic of Korea 1380 Phone: +82 31 299 4957 1381 EMail: darkhong@skku.edu 1382 Jinyong Tim Kim 1383 Department of Electronic, Electrical and Computer Engineering 1384 Sungkyunkwan University 1385 2066 Seobu-Ro, Jangan-Gu 1386 Suwon, Gyeonggi-Do 16419 1387 Republic of Korea 1389 Phone: +82 10 8273 0930 1390 EMail: timkim@skku.edu