idnits 2.17.1 draft-yang-i2nsf-security-policy-translation-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 148: '... an NSF, the NSF MUST receive at least...' RFC 2119 keyword, line 153: '...ntence, the user MUST know that the NS...' RFC 2119 keyword, line 161: '... policy is REQUIRED in I2NSF....' RFC 2119 keyword, line 436: '... security policy MUST be provided abst...' RFC 2119 keyword, line 538: '...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 4, 2019) is 1625 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: 2 errors (**), 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 7, 2020 J. Kim 6 Sungkyunkwan University 7 November 4, 2019 9 Security Policy Translation in Interface to Network Security Functions 10 draft-yang-i2nsf-security-policy-translation-05 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 7, 2020. 44 Copyright Notice 46 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 28 87 9.2. Informative References . . . . . . . . . . . . . . . . . 29 88 Appendix A. Changes from draft-yang-i2nsf-security-policy- 89 translation-04 . . . . . . . . . . . . . . . . . . . 30 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 92 1. Introduction 94 This document defines a scheme of a security policy translation in 95 Interface to Network Security Functions (I2NSF) Framework [RFC8329]. 96 First of all, this document explains the necessity of a security 97 policy translator (shortly called policy translator) in the I2NSF 98 framework. 100 The policy translator resides in Security Controller in the I2NSF 101 framework and translates a high-level security policy to a low-level 102 security policy for Network Security Functions (NSFs). A high-level 103 policy is specified by I2NSF User in the I2NSF framework and is 104 delivered to Security Controller via Consumer-Facing Interface 105 [consumer-facing-inf-dm]. It is translated into a low-level policy 106 by Policy Translator in Security Controller and is delivered to NSFs 107 to execute the rules corresponding to the low-level policy via NSF- 108 Facing Interface [nsf-facing-inf-dm]. 110 2. Terminology 112 This document uses the terminology specified in [i2nsf-terminology] 113 [RFC8329]. 115 3. Necessity for Policy Translator 117 Security Controller acts as a coordinator between I2NSF User and 118 NSFs. Also, Security Controller has capability information of NSFs 119 that are registered via Registration Interface [registration-inf-dm] 120 by Developer's Management System [RFC8329]. As a coordinator, 121 Security Controller needs to generate a low-level policy in the form 122 of security rules intended by the high-level policy, which can be 123 understood by the corresponding NSFs. 125 A high-level security policy is specified by RESTCONF/YANG 126 [RFC8040][RFC6020], and a low-level security policy is specified by 127 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level 128 security policy to the corresponding low-level security policy will 129 be able to rapidly elevate I2NSF in real-world deployment. A rule in 130 a high-level policy can include a broad target object, such as 131 employees in a company for a security service (e.g., firewall and web 132 filter). Such employees may be from human resource (HR) department, 133 software engineering department, and advertisement department. A 134 keyword of employee needs to be mapped to these employees from 135 various departments. This mapping needs to be handled by a policy 136 translator in a flexible way while understanding the intention of a 137 policy specification. Let us consider the following two policies: 139 o Block my son's computers from malicious websites. 141 o Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com 142 and illegal.com 144 The above two sentences are examples of policies for blocking 145 malicious websites. Both policies are for the same operation. 146 However, NSF cannot understand the first policy, because the policy 147 does not have any specified information for NSF. To set up the 148 policy at an NSF, the NSF MUST receive at least the source IP address 149 and website address for an operation. It means that the first 150 sentence is NOT compatible for an NSF policy. Conversely, when I2NSF 151 Users request a security policy to the system, they never make a 152 security policy like the second example. For generating a security 153 policy like the second sentence, the user MUST know that the NSF 154 needs to receive the specified information, source IP address and 155 website address. It means that the user understands the NSF 156 professionally, but there are not many professional users in a small 157 size of company or at a residential area. In conclusion, the I2NSF 158 User prefers to issue a security policy in the first sentence, but an 159 NSF will require the same policy as the second sentence with specific 160 information. Therefore, an advanced translation scheme of security 161 policy is REQUIRED in I2NSF. 163 This document proposes an approach using Automata theory [Automata] 164 for the policy translation, such as Deterministic Finite Automaton 165 (DFA) and Context Free Grammar (CFG). Note that Automata theory is 166 the foundation of programming language and compiler. Thus, with this 167 approach, I2NSF User can easily specify a high-level security policy 168 that will be enforced into the corresponding NSFs with a compatibly 169 low-level security policy with the help of Policy Translator. Also, 170 for easy management, a modularized translator structure is proposed. 172 4. Design of Policy Translator 174 Commonly used security policies are created as XML(Extensible Markup 175 Language) [XML] files. A popular way to change the format of an XML 176 file is to use an XSLT (Extensible Stylesheet Language 177 Transformation) [XSLT] document. XSLT is an XML-based language to 178 transform an input XML file into another output XML file. However, 179 the use of XSLT makes it difficult to manage the policy translator 180 and to handle the registration of new capabilities of NSFs. With the 181 necessity for a policy translator, this document describes a policy 182 translator based on Automata theory. 184 4.1. Overall Structure of Policy Translator 185 High-Level Policy 186 Security | 187 Controller V Consumer-Facing Interface 188 +------------------------+-------------------------+ 189 | Policy | | 190 | Translator | | 191 | +---------------------+----------------------+ | 192 | | | | | 193 | | +-------+--------+ | | 194 | | | DFA-based | | | 195 | | | Data Extractor | | | 196 | | +-------+--------+ | | 197 | | | Extracted Data from | | 198 | | V High-Level Policy | | 199 | | +-----+-----+ +--------+ | | 200 | | | Data | <-> | NSF DB | | | 201 | | | Converter | +--------+ | | 202 | | +-----+-----+ | | 203 | | | Required Data for | | 204 | | V Target NSFs | | 205 | | +--------+---------+ | | 206 | | | CFG-based | | | 207 | | | Policy Generator | | | 208 | | +--------+---------+ | | 209 | | | | | 210 | +---------------------+----------------------+ | 211 | | | 212 +------------------------+-------------------------+ 213 | NSF-Facing Interface 214 V 215 Low-Level Policy 217 Figure 1: The Overall Design of Policy Translator 219 Figure 1 shows the overall design for Policy Translator in Security 220 Controller. There are three main components for Policy Translator: 221 Data Extractor, Data Converter, and Policy Generator. 223 Extractor is a DFA-based module for extracting data from a high-level 224 policy which I2NSF User delivered via Consumer-Facing Interface. 225 Data Converter converts the extracted data to the capabilities of 226 target NSFs for a low-level policy. It refers to an NSF Database 227 (DB) in order to convert an abstract subject or object into the 228 corresponding concrete subject or object (e.g., IP address and 229 website URL). Policy Generator generates a low-level policy which 230 will execute the NSF capabilities from Converter. 232 4.2. DFA-based Data Extractor 234 4.2.1. Design of DFA-based Data Extractor 236 +----------+ 237 | accepter | 238 +----------+ 239 | ^ 240 | | 241 v | 242 +------------------------------------------------------+ 243 | middle 1 | 244 +------------------------------------------------------+ 245 | ^ | ^ | ^ 246 | | | | ... | | 247 v | v | v | 249 ... ... ... 251 +-------------+ +-------------+ +-------------+ 252 | extractor 1 | | extractor 2 | ... | extractor m | 253 +-------------+ +-------------+ +-------------+ 254 data:1 data:2 data:m 256 Figure 2: DFA Architecture of Data Extractor 258 Figure 2 shows a design for Data Extractor in the policy translator. 259 If a high-level policy contains data along the hierarchical structure 260 of the standard Consumer-Facing Interface YANG data model 261 [consumer-facing-inf-dm], data can be easily extracted using the 262 state transition machine, such as DFA. The extracted data can be 263 processed and used by an NSF to understand it. Extractor can be 264 constructed by designing a DFA with the same hierarchical structure 265 as a YANG data model. 267 After constructing a DFA, Data Extractor can extract all of data in 268 the entered high-level policy by using state transitions. Also, the 269 DFA can easily detect the grammar errors of the high-level policy. 270 The extracting algorithm of Data Extractor is as follows: 272 1. Start from the 'accepter' state. 274 2. Read the next tag from the high-level policy. 276 3. Transit to the corresponding state. 278 4. If the current state is in 'extractor', extract the corresponding 279 data, and then go back to step 2. 281 5. If the current state is in 'middle', go back to step 2. 283 6. If there is no possible transition and arrived at 'accepter' 284 state, the policy has no grammar error. Otherwise, there is a 285 grammar error, so stop the process with failure. 287 4.2.2. Example Scenario for Data Extractor 289 290 block_web 291 292 Son's_PC 293 malicious_websites 294 295 block 296 298 Figure 3: The Example of High-level Policy 300 +----------+ 301 | accepter | 302 +----------+ 303 | ^ 304 | | 305 v | 306 +------------------------------------------------------+ 307 | middle 1 | 308 +------------------------------------------------------+ 309 | ^ | ^ | ^ 310 | | | | | | 311 v | v | v | 312 +-------------+ +----------------------+ +-------------+ 313 | extractor 1 | | middle 2 | | extractor 4 | 314 +-------------+ +----------------------+ +-------------+ 315 block_web | ^ | ^ block 316 | | | | 317 v | v | 318 +-------------+ +-------------+ 319 | extractor 2 | | extractor 3 | 320 +-------------+ +-------------+ 321 Son's_PC malicious 322 _websites 324 Figure 4: The Example of Data Extractor 326 To explain the Data Extractor process by referring to an example 327 scenario, assume that Security Controller received a high-level 328 policy for a web-filtering as shown in Figure 3. Then we can 329 construct DFA-based Data Extractor by using the design as shown in 330 Figure 2. Figure 4 shows the architecture of Data Extractor that is 331 based on the architecture in Figure 2 along with the input high-level 332 policy in Figure 3. Data Extractor can automatically extract all of 333 data in the high-level policy according to the following process: 335 1. Start from the 'accepter' state. 337 2. Read the first opening tag called '', and transit to the 338 'middle 1' state. 340 3. Read the second opening tag called '', and transit to the 341 'extractor 1' state. 343 4. The current state is an 'extractor' state. Extract the data of 344 'name' field called 'block_web'. 346 5. Read the second closing tag called '', and go back to the 347 'middle 1' state. 349 6. Read the third opening tag called '', and transit to the 350 'middle 2' state. 352 7. Read the fourth opening tag called '', and transit to the 353 'extractor 2' state. 355 8. The current state is an 'extractor' state. Extract the data of 356 'src' field called 'Son's_PC'. 358 9. Read the fourth closing tag called '', and go back to the 359 'middle 2' state. 361 10. Read the fifth opening tag called '', and transit to the 362 'extractor 3' state. 364 11. The current state is an 'extractor' state. Extract the data of 365 'dest' field called 'malicious_websites'. 367 12. Read the fifth closing tag called '', and go back to the 368 'middle 2' state. 370 13. Read the third closing tag called '', and go back to the 371 'middle 1' state. 373 14. Read the sixth opening tag called '', and transit to the 374 'extractor 4' state. 376 15. The current state is an 'extractor' state. Extract the data of 377 'action' field called 'block'. 379 16. Read the sixth closing tag called '', and go back to 380 the 'middle 1' state. 382 17. Read the first closing tag called '', and go back to the 383 'accepter' state. 385 18. There is no further possible transition, and the state is 386 finally on 'accepter' state. There is no grammar error in 387 Figure 3 so the scanning for data extraction is finished. 389 The above process is constructed by an extracting algorithm. After 390 finishing all the steps of the above process, Data Extractor can 391 extract all of data in Figure 3, 'block_web', 'Son's_PC', 392 'malicious', and 'block'. 394 Since the translator is modularized into a DFA structure, a visual 395 understanding is feasible. Also, the performance of Data Extractor 396 is excellent compared to one-to-one searching of data for a 397 particular field. In addition, the management is efficient because 398 the DFA completely follows the hierarchy of Consumer-Facing 399 Interface. If I2NSF User wants to modify the data model of a high- 400 level policy, it only needs to change the connection of the relevant 401 DFA node. 403 4.3. Data Converter 405 4.3.1. Role of Data Converter 407 Every NSF has its own unique capabilities. The capabilities of an 408 NSF are registered into Security Controller by a Developer's 409 Management System, which manages the NSF, via Registration Interface. 410 Therefore, Security Controller already has all information about the 411 capabilities of NSFs. This means that Security Controller can find 412 target NSFs with only the data (e.g., subject and object for a 413 security policy) of the high-level policy by comparing the extracted 414 data with all capabilities of each NSF. This search process for 415 appropriate NSFs is called by policy provisioning, and it eliminates 416 the need for I2NSF User to specify the target NSFs explicitly in a 417 high-level security policy. 419 Data Converter selects target NSFs and converts the extracted data 420 into the capabilities of selected NSFs. If Security Controller uses 421 this data convertor, it can provide the policy provisioning function 422 to I2NSF User automatically. Thus, the translator design provides 423 big benefits to the I2NSF Framework. 425 4.3.2. NSF Database 427 The NSF Database contains all the information needed to convert high- 428 level policy data to low-level policy data. The contents of NSF 429 Database are classified as the following two: "endpoint information" 430 and "NSF capability information". 432 The first is "endpoint information". Endpoint information is 433 necessary to convert an abstract high-level policy data such as 434 Son's_PC, malicious to a specific low-level policy data such as 435 10.0.0.1, illegal.com. In the high-level policy, the range of 436 endpoints for applying security policy MUST be provided abstractly. 437 Thus, endpoint information is needed to specify the abstracted high- 438 level policy data. Endpoint information is provided by I2NSF User as 439 the high-level policy through Consumer-Facing Interface, and Security 440 Controller builds NSF Database based on received information. 442 The second is "NSF capability information". Since capability is 443 information that allows NSF to know what features it can support, NSF 444 capability information is used in policy provisioning process to 445 search the appropriate NSFs through the security policy. NSF 446 capability information is provided by Developer's Management System 447 (DMS) through Registration Interface, and Security Controller builds 448 NSF Database based on received information. In addition, if the NSF 449 sends monitoring information such as initiating information to 450 Security Controller through NSF-Facing Interface, Security Controller 451 can modify NSF Database accordingly. 453 NSF Capability Information Endpoint Information 454 +-------------------+ has convert +------------------+ 455 | NSF +||---+ +-------||+ Endpoint | 456 +-------------------+ | | +------------------+ 457 | *nsf_id (INT) | | | | *end_id (INT) | 458 | nsf_name (STRING) | | | | keyword (STRING) | 459 | inbound (INT) | | | +------------------+ 460 | outbound (INT) | | | 461 | bandwidth (INT) | | | 462 | activated (BOOL) | | | 463 +-------------------+ | | 464 +---------------+ | 465 /|\ | 466 +--------------------+ has | 467 | Capability +||---+ | 468 +--------------------+ | | 469 | *capa_id (INT) | | | 470 | capa_name (STRING) | | | 471 | capa_index (INT) | | | 472 +--------------------+ | | 473 /|\ /|\ 474 +-----------------------+ 475 | Field | 476 +-----------------------+ 477 | *field_id (INT) | 478 | field_name (STRING) | 479 | field_index (INT) | 480 | mapped_data (STRING) | 481 +-----------------------+ 483 Figure 5: Entity-Relationship Diagram of NSF Database 485 Figure 5 shows an Entity-Relationship Diagram (ERD) of NSF Database 486 designed to include both endpoint information received from I2NSF 487 User and NSF capability information received from DMS. By designing 488 the NSF database based on the ERD, all the information necessary for 489 security policy translation can be stored, and the network system 490 administrator can manage the NSF database efficiently. 492 ERD was expressed by using Crow's Foot notation. Crow's Foot 493 notation represents a relationship between entities as a line and 494 represents the cardinality of the relationship as a symbol at both 495 ends of the line. Attributes prefixed with * are key values of each 496 entity. A link with two vertical lines represents one-to-one 497 mapping, and a bird-shaped link represents one-to-many mapping. An 498 NSF entity stores the NSF name (nsf_name), NSF specification 499 (inbound, outbound, bandwidth), and NSF activation (activated). A 500 Capability entity stores the capability name (capa_name) and the 501 index of the capability field in a Registration Interface Data Model 502 (capa_index). An Endpoint entity stores the keyword of abstract data 503 conversion from I2NSF User (keyword). A Field entity stores the 504 field name (field_name), the index of the field index in an NSF- 505 Facing Interface Data Model, and converted data by referring to the 506 Endpoint entity and a 'convert' relationship. 508 4.3.3. Data Conversion in Data Converter 510 High-level Low-level 511 Policy Data Policy Data 512 +---------------+ +------------------------------+ 513 | Rule Name | | Rule Name | 514 | +-----------+ | The Same value | +-------------------------+ | 515 | | block_web |-|------------------->|->| block_web | | 516 | +-----------+ | | +-------------------------+ | 517 | | | | 518 | Source | Conversion into | Source IPv4 | 519 | +-----------+ | User's IP address | +-------------------------+ | 520 | | Son's_PC |-|------------------->|->| [10.0.0.1, 10.0.0.3] | | 521 | +-----------+ | | +-------------------------+ | 522 | | | | 523 | Destination | Conversion into | URL Category | 524 | +-----------+ | malicious websites | +-------------------------+ | 525 | | malicious |-|------------------->|->| [harm.com, | | 526 | | _websites | | | | illegal.com] | | 527 | +-----------+ | | +-------------------------+ | 528 | | | | 529 | Action | Conversion into | Log Action Drop Action | 530 | +-----------+ | NSF Capability | +----------+ +----------+ | 531 | | block |-|------------------->|->| True | | True | | 532 | +-----------+ | | +----------+ +----------+ | 533 +---------------+ +------------------------------+ 535 Figure 6: Example of Data Conversion 537 Figure 6 shows an example for describing a data conversion in Data 538 Converter. High-level policy data MUST be converted into low-level 539 policy data which are compatible with NSFs. If a system 540 administrator attaches a database to Data Converter, it can convert 541 contents by referring to the database with SQL queries. Data 542 conversion in Figure 6 is based on the following list: 544 o 'Rule Name' field does NOT need the conversion. 546 o 'Source' field SHOULD be converted into a list of target IPv4 547 addresses. 549 o 'Destination' field SHOULD be converted into a URL category list 550 of malicious websites. 552 o 'Action' field SHOULD be converted into the corresponding 553 action(s) in NSF capabilities. 555 Figure 7 shows a mapping list of data fields between Consumer-Facing 556 Interface Data Model and NSF-Facing Interface Data Model. Figure 7 557 describes the process of passing the data value to the appropriate 558 data field of the Data Model in detail after the data conversion. 560 #policy name mapping 561 /consumer-facing/policy/policy-name 562 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 563 /system-policy-name 565 #rule name mapping 566 /consumer-facing/policy/rule/rule-name 567 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 568 /rules/rule-name 570 #start time mapping 571 /consumer-facing/policy 572 /rule/event/time-information/time/begin-time 573 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 574 /rules/time-zone/absolute-time-zone/start-time 576 #end time mapping 577 /consumer-facing/policy 578 /rule/event/time-information/time/end-time 579 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 580 /rules/time-zone/absolute-time-zone/end-time 582 #firewall-condition source target reference and mapping 583 /consumer-facing/policy/rule/condition 584 /firewall-condition/source-target/src-target 585 -> reference: /consumer-facing/policy 586 /endpoint-group/user-group/name 587 -> extract: /consumer-facing/policy 588 /endpoint-group/user-group/date 589 -> mapping: /nsf-facing/i2nsf-security-policy 590 /rule/date 591 -> extract: /consumer-facing/policy 592 /endpoint-group/user-group/ip-address 593 -> mapping: /nsf-facing/i2nsf-security-policy 594 /system-policy/rules 595 /condition-clause-container 596 /packet-security-ipv4-condition 597 /pkt-sec-ipv4-src/ipv4-address/ipv4 598 -> extract: /consumer-facing/policy 599 /endpoint-group/user-group/range-ip-address 600 /start-ip-address 601 -> mapping: /nsf-facing/i2nsf-security-policy 602 /system-policy/rules 603 /condition-clause-container 604 /packet-security-ipv4-condition 605 /pkt-sec-ipv4-src/range-ipv4-address 606 /start-ipv4-address 607 -> extract: /consumer-facing/policy 608 /endpoint-group/user-group/range-ip-address 609 /end-ip-address 610 -> mapping: /nsf-facing/i2nsf-security-policy 611 /system-policy/rules 612 /condition-clause-container 613 /packet-security-ipv4-condition 614 /pkt-sec-ipv4-src/range-ipv4-address 615 /end-ipv4-address 617 #firewall-condition destination target reference and mapping 618 /consumer-facing/policy/rule/condition 619 /firewall-condition/destination-target/dest-target 620 -> reference: /consumer-facing/policy 621 /endpoint-group/user-group/name 622 -> extract: /consumer-facing/policy 623 /endpoint-group/user-group/date 624 -> mapping: /nsf-facing/i2nsf-security-policy 625 /system-policy/rule/date 626 -> extract: /consumer-facing/policy 627 /endpoint-group/user-group/ip-address 628 -> mapping: /nsf-facing/i2nsf-security-policy 629 /system-policy/rules 630 /condition-clause-container 631 /packet-security-ipv4-condition 632 /pkt-sec-ipv4-dest/ipv4-address/ipv4 633 -> extract: /consumer-facing/policy 634 /endpoint-group/user-group 635 /range-ip-address/start-ip-address 636 -> mapping: /nsf-facing/i2nsf-security-policy 637 /system-policy/rules 638 /condition-clause-container 639 /packet-security-ipv4-condition 640 /pkt-sec-ipv4-dest/range-ipv4-address 641 /start-ipv4-address 642 -> extract: /consumer-facing/policy 643 /endpoint-group/user-group 644 /range-ip-address/end-ip-address 645 -> mapping: /nsf-facing/i2nsf-security-policy 646 /system-policy/rules 647 /condition-clause-container 648 /packet-security-ipv4-condition 649 /pkt-sec-ipv4-dest/range-ipv4-address 650 /end-ipv4-address 652 #ddos-condition source target reference and mapping 653 /consumer-facing/policy/rule/condition 654 /ddos-condition/source-target/src-target 655 -> reference: /consumer-facing/policy 656 /endpoint-group/device-group/name 657 -> extract: /consumer-facing/policy 658 /endpoint-group/device-group/date 659 -> mapping: /nsf-facing/i2nsf-security-policy/rule/date 660 -> extract: /consumer-facing/policy 661 /endpoint-group/device-group/ip-address 662 -> mapping: /nsf-facing/i2nsf-security-policy 663 /system-policy/rules 664 /condition-clause-container 665 /packet-security-ipv4-condition 666 /pkt-sec-ipv4-src/ipv4-address/ipv4 667 -> extract: /consumer-facing/policy 668 /endpoint-group/device-group 669 /range-ip-address/start-ip-address 670 -> mapping: /nsf-facing/i2nsf-security-policy 671 /system-policy/rules 672 /condition-clause-container 673 /packet-security-ipv4-condition 674 /pkt-sec-ipv4-src/range-ipv4-address 675 /start-ipv4-address 676 -> extract: /consumer-facing/policy 677 /endpoint-group/device-group 678 /range-ip-address/end-ip-address 679 -> mapping: /nsf-facing/i2nsf-security-policy 680 /system-policy/rules 681 /condition-clause-container 682 /packet-security-ipv4-condition 683 /pkt-sec-ipv4-src/range-ipv4-address 684 /end-ipv4-address 686 #ddos-condition destination target reference and mapping 687 /consumer-facing/policy/rule/condition 688 /ddos-condition/destination-target/dest-target 689 -> reference: /consumer-facing/policy 690 /endpoint-group/device-group/name 691 -> extract: /consumer-facing/policy 692 /endpoint-group/device-group/date 693 -> mapping: /nsf-facing/i2nsf-security-policy/rule/date 694 -> extract: /consumer-facing/policy 695 /endpoint-group/device-group/ip-address 696 -> mapping: /nsf-facing/i2nsf-security-policy 697 /system-policy/rules 698 /condition-clause-container 699 /packet-security-ipv4-condition 700 /pkt-sec-ipv4-dest/ipv4-address/ipv4 701 -> extract: /consumer-facing/policy 702 /endpoint-group/device-group 703 /range-ip-address/start-ip-address 704 -> mapping: /nsf-facing/i2nsf-security-policy 705 /system-policy/rules 706 /condition-clause-container 707 /packet-security-ipv4-condition 708 /pkt-sec-ipv4-dest/range-ipv4-address 709 /start-ipv4-address 710 -> extract: /consumer-facing/policy 711 /endpoint-group/device-group 712 /range-ip-address/end-ip-address 713 -> mapping: /nsf-facing/i2nsf-security-policy 714 /system-policy/rules 715 /condition-clause-container 716 /packet-security-ipv4-condition 717 /pkt-sec-ipv4-dest/range-ipv4-address 718 /end-ipv4-address 720 #ddos-condition packet per second mapping 721 /consumer-facing/policy/rule/condition 722 /ddos-condition/rate-limit/packet-per-second 723 -> mapping: /nsf-facing/i2nsf-security-policy 724 /system-policy/rules/condition-clause-container 725 /packet-security-ddos-condition/pkt-sec-alert-rate 727 #threat-prevention source target reference and mapping 728 /consumer-facing/policy/rule/condition 729 /custom-condition/source-target/src-target 730 -> reference: /consumer-facing/policy 731 /threat-prevention/payload-content/name 732 -> extract: /consumer-facing/policy 733 /threat-prevention/payload-content/date 734 -> mapping: /nsf-facing/i2nsf-security-policy 735 /system-policy/rules/date 736 -> extract: /consumer-facing/policy 737 /threat-prevention/payload-content/content 738 -> mapping: /nsf-facing/i2nsf-security-policy 739 /system-policy/rules 740 /condition-clause-container 741 /packet-security-payload-condition 742 /pkt-payload-content 744 #threat-prevention destination target reference and mapping 745 /consumer-facing/policy/rule/condition 746 /custom-condition/destination-target/dest-target 747 -> reference: /consumer-facing/policy 748 /threat-prevention/payload-content/name 749 -> extract: /consumer-facing/policy 750 /threat-prevention/payload-content/date 751 -> mapping: /nsf-facing/i2nsf-security-policy 752 /system-policy/rules/date 753 -> extract: /consumer-facing/policy 754 /threat-prevention/payload-content/content 755 -> mapping: /nsf-facing/i2nsf-security-policy 756 /system-policy/rules 757 /condition-clause-container 758 /packet-security-payload-condition 759 /pkt-payload-content 761 #threat-feed-condition source target reference and mapping 762 /consumer-facing/policy/rule/condition 763 /custom-condition/threat-feed-condition 764 /source-target/src-target 765 -> reference: /consumer-facing/policy 766 /threat-prevention/threat-feed-list/name 767 -> extract: /consumer-facing/policy 768 /threat-prevention/threat-feed-list/date 769 -> mapping: /nsf-facing/i2nsf-security-policy 770 /system-policy/rules/date 771 -> extract: /consumer-facing/policy 772 /threat-prevention/threat-feed-list 773 /threat-feed-server/ip-address 774 -> mapping: /nsf-facing/i2nsf-security-policy 775 /system-policy/rules 776 /condition-clause-container 777 /packet-security-ipv4-condition 778 /pkt-sec-ipv4-src/ipv4-address/ipv4 779 -> extract: /consumer-facing/policy 780 /threat-prevention/threat-feed-list 781 /threat-feed-server/range-ip-address 782 /start-ip-address 783 -> mapping: /nsf-facing/i2nsf-security-policy 784 /system-policy/rules 785 /condition-clause-container 786 /packet-security-ipv4-condition 787 /pkt-sec-ipv4-src/range-ipv4-address 788 /start-ipv4-address 789 -> extract: /consumer-facing/policy 790 /threat-prevention/threat-feed-list 791 /threat-feed-server/range-ip-address 792 /end-ip-address 793 -> mapping: /nsf-facing/i2nsf-security-policy 794 /system-policy/rules 795 /condition-clause-container 796 /packet-security-ipv4-condition 797 /pkt-sec-ipv4-src/range-ipv4-address 798 /end-ipv4-address 799 -> extract: /consumer-facing/policy 800 /threat-prevention/threat-feed-list 801 /threat-feed-server 802 /threat-feed-description 803 -> mapping: /nsf-facing/i2nsf-security-policy 804 /system-policy/rules 805 /condition-clause-container 806 /packet-security-ipv4-condition 807 /ipv4-description 809 #threat-feed-condition destination target reference and mapping 810 /consumer-facing/policy/rule/condition 811 /custom-condition/threat-feed-condition 812 /destination-target/dest-target 813 -> reference: /consumer-facing/policy 814 /threat-prevention/threat-feed-list/name 815 -> extract: /consumer-facing/policy 816 /threat-prevention/threat-feed-list/date 817 -> mapping: /nsf-facing/i2nsf-security-policy 818 /system-policy/rules/date 819 -> extract: /consumer-facing/policy 820 /threat-prevention/threat-feed-list 821 /threat-feed-server/ip-address 822 -> mapping: /nsf-facing/i2nsf-security-policy 823 /system-policy/rules 824 /condition-clause-container 825 /packet-security-ipv4-condition 826 /pkt-sec-ipv4-dest/ipv4-address/ipv4 827 -> extract: /consumer-facing/policy 828 /threat-prevention/threat-feed-list 829 /threat-feed-server/range-ip-address 830 /start-ip-address 831 -> mapping: /nsf-facing/i2nsf-security-policy 832 /system-policy/rules 833 /condition-clause-container 834 /packet-security-ipv4-condition 835 /pkt-sec-ipv4-dest/range-ipv4-address 836 /start-ipv4-address 837 -> extract: /consumer-facing/policy 838 /threat-prevention/threat-feed-list 839 /threat-feed-server/range-ip-address 840 /end-ip-address 841 -> mapping: /nsf-facing/i2nsf-security-policy 842 /system-policy/rules 843 /condition-clause-container 844 /packet-security-ipv4-condition 845 /pkt-sec-ipv4-dest/range-ipv4-address 846 /end-ipv4-address 847 -> extract: /consumer-facing/policy 848 /threat-prevention/threat-feed-list 849 /threat-feed-server 850 /threat-feed-description 851 -> mapping: /nsf-facing/i2nsf-security-policy 852 /system-policy/rules 853 /condition-clause-container 854 /packet-security-ipv4-condition 855 /ipv4-description 857 #rule action name mapping 858 /consumer-facing/policy/rule/action/name 859 -> mapping: /nsf-facing/i2nsf-security-policy 860 /system-policy/rules/action-clause-container 861 /packet-action/ingress-action 862 -> mapping: /nsf-facing/i2nsf-security-policy 863 /system-policy/rules/action-clause-container 864 /packet-action/egress-action 865 -> mapping: /nsf-facing/i2nsf-security-policy 866 /system-policy/rules/action-clause-container 867 /packet-action/log-action 868 -> mapping: /nsf-facing/i2nsf-security-policy 869 /system-policy/rules/action-clause-container 870 /advanced-action/content-security-control 871 -> mapping: /nsf-facing/i2nsf-security-policy 872 /system-policy/rules/action-clause-container 873 /advanced-action/attack-mitigation-control 875 #ipsec-method mapping 876 /consumer-facing/policy/rule/ipsec-method 877 -> mapping: /nsf-facing/i2nsf-ipsec 879 #policy domain name mapping 880 /consumer-facing/policy-domain/name 881 -> mapping: /nsf-facing/i2nsf-security-policy 882 /system-policy/rule-group/groups/group-name 884 Figure 7: Mapping Information for Data Conversion 886 4.3.4. Policy Provisioning 888 Log-keeper Low-level Web-filter 889 NSF Policy Data NSF 890 +-------------------+ +--------------------+ +-------------------+ 891 | Rule Name | | Rule Name | | Rule Name | 892 | +--------------+ | | +--------------+ | | +--------------+ | 893 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | | 894 | +--------------+ | | +--------------+ | | +--------------+ | 895 | | | | | | 896 | Source IPv4 | | Source IPv4 | | Source IPv4 | 897 | +--------------+ | | +--------------+ | | +--------------+ | 898 | | [10.0.0.1, |<-|<-|<-| [10.0.0.1, |->|->|->| [10.0.0.1, | | 899 | | 10.0.0.3] | | | | 10.0.0.3] | | | | 10.0.0.3] | | 900 | +--------------+ | | +--------------+ | | +--------------+ | 901 | | | | | | 902 | | | URL Category | | URL Category | 903 | | | +--------------+ | | +--------------+ | 904 | | | | [harm.com, |->|->|->| [harm.com, | | 905 | | | | illegal.com] | | | | illegal.com] | | 906 | | | +--------------+ | | +--------------+ | 907 | | | | | | 908 | Log Action | | Log Action | | | 909 | +--------------+ | | +--------------+ | | | 910 | | True |<-|<-|<-| True | | | | 911 | +--------------+ | | +--------------+ | | | 912 +-------------------+ | | | | 913 | Drop Action | | Drop Action | 914 | +--------------+ | | +--------------+ | 915 | | True |->|->|->| True | | 916 | +--------------+ | | +--------------+ | 917 +--------------------+ +-------------------+ 919 Figure 8: Example of Policy Provisioning 921 Generator searches for proper NSFs which can cover all of 922 capabilities in the high-level policy. Generator searches for target 923 NSFs by comparing only NSF capabilities which is registered by Vendor 924 Management System. This process is called by "policy provisioning" 925 because Generator finds proper NSFs by using only the policy. If 926 target NSFs are found by using other data which is not included in a 927 user's policy, it means that the user already knows the specific 928 knowledge of an NSF in the I2NSF Framework. Figure 8 shows an 929 example of policy provisioning. In this example, log-keeper NSF and 930 web-filter NSF are selected for covering capabilities in the security 931 policy. All of capabilities can be covered by two selected NSFs. 933 4.4. CFG-based Policy Generator 935 Generator makes low-level security policies for each target NSF with 936 the extracted data. We constructed Generator by using Context Free 937 Grammar (CFG). CFG is a set of production rules which can describe 938 all possible strings in a given formal language(e.g., programming 939 language). The low-level policy also has its own language based on a 940 YANG data model of NSF-Facing Interface. Thus, we can construct the 941 productions based on the YANG data model. The productions that makes 942 up the low-level security policy are categorized into two types, 943 'Content Production' and 'Structure Production'. 945 4.4.1. Content Production 947 Content Production is for injecting data into low-level policies to 948 be generated. A security manager(i.e., a person (or software) to 949 make productions for security policies) can construct Content 950 Productions in the form of an expression as the following 951 productions: 953 o [cont_prod] -> [cont_prod][cont_prod] (Where duplication is 954 allowed.) 956 o [cont_prod] -> [cont_data] 958 o [cont_data] -> data_1 | data_2 | ... | data_n 960 Square brackets mean non-terminal state. If there are no non- 961 terminal states, it means that the string is completely generated. 962 When the duplication of content tag is allowed, the security manager 963 adds the first production for a rule. If there is no need to allow 964 duplication, the first production can be skipped because it is an 965 optional production. 967 The second production is the main production for Content Production 968 because it generates the tag which contains data for low-level 969 policy. Last, the third production is for injecting data into a tag 970 which is generated by the second production. If data is changed for 971 an NSF, the security manager needs to change "only the third 972 production" for data mapping in each NSF. 974 For example, if the security manager wants to express a low-level 975 policy for source IP address, Content Production can be constructed 976 in the following productions: 978 o [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.) 980 o [cont_ipv4] -> [cont_ipv4_data] 981 o [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 983 4.4.2. Structure Production 985 Structure Production is for grouping other tags into a hierarchy. 986 The security manager can construct Structure Production in the form 987 of an expression as the following production: 989 o [struct_prod] -> [prod_1]...[prod_n] 991 Structure Production can be expressed as a single production. The 992 above production means to group other tags by the name of a tag which 993 is called by 'struct_tag'. [prod_x] is a state for generating a tag 994 which wants to be grouped by Structure Production. [prod_x] can be 995 both Content Production and Structure Production. For example, if 996 the security manager wants to express the low-level policy for the 997 I2NSF tag, which is grouping 'name' and 'rules', Structure Production 998 can be constructed as the following production where [cont_name] is 999 the state for Content Production and [struct_rule] is the state for 1000 Structure Production. 1002 o [struct_i2nsf] -> [cont_name][struct_rules] 1004 4.4.3. Generator Construction 1006 The security manager can build a generator by combining the two 1007 productions which are described in Section 4.4.1 and Section 4.4.2. 1008 Figure 9 shows the CFG-based Generator construction of the web-filter 1009 NSF. It is constructed based on the NSF-Facing Interface Data Model 1010 in [nsf-facing-inf-dm]. According to Figure 9, the security manager 1011 can express productions for each clause as in following CFG: 1013 1. [cont_name] -> [cont_name_data] 1015 2. [cont_name_data] -> block_web 1017 3. [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication) 1019 4. [cont_ipv4] -> [cont_ipv4_data] 1021 5. [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 1023 6. [cont_url] -> [cont_url][cont_url] (Allow duplication) 1025 7. [cont_url] -> [cont_url_data] 1027 8. [cont_url_data] -> harm.com | illegal.com 1028 9. [cont_action] -> [cont_action_data] 1030 10. [cont_action_data] -> drop 1032 11. [struct_packet] -> [cont_ipv4] 1034 12. [struct_payload] -> [cont_url] 1036 13. [struct_cond] -> 1037 [struct_packet][struct_payload] 1039 14. [struct_rules] -> [struct_cond][cont_action] 1041 15. [struct_i2nsf] -> [cont_name][struct_rules] 1043 Then, Generator generates a low-level policy by using the above CFG. 1044 The low-level policy is generated by the following process: 1046 1. Start: [struct_i2nsf] 1048 2. Production 15: [cont_name][struct_rules] 1050 3. Production 1: [cont_name_data][struct_rules] 1053 4. Production 2: block_web[struct_rules] 1056 5. Production 14: block_web[struct_cond][cont_action] 1059 6. Production 13: block_web[struct_packet][struct_payload][cont_action] 1061 1063 7. Production 11: block_web[cont_ipv4][struct_payload] 1065 [cont_action] 1067 8. Production 3: block_web[cont_ipv4][cont_ipv4][struct_payload][cont_action] 1071 9. Production 4: block_web[cont_ipv4_data][cont_ipv4_dat 1073 a][struct_payload][cont_action] 1076 10. Production 5: block_web10.0.0.110.0.0.3[struct_payload][cont_action] 1080 11. Production 12: block_web10.0.0.110.0.0.3[cont_url][cont_action] 1085 12. Production 6: block_web10.0.0.110.0.0.3[cont_url][cont_url][cont_actio 1088 n] 1090 13. Production 7: block_web10.0.0.110.0.0.3[cont_url_data][cont_url_data]< 1093 /payload>[cont_action] 1095 14. Production 8: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action] 1100 15. Production 9: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action_data] 1105 16. Production 10: block_web10.0.0.110.0.0.3harm.comillegal.com< 1108 /condition>drop 1110 The last production has no non-terminal state, and the low-level 1111 policy is completely generated. Figure 10 shows the generated low- 1112 level policy where tab characters and newline characters are added. 1114 +-----------------------------------------------------+ 1115 | +----------+ +----------+ +----------+ +----------+ | 1116 Content | | Rule | | Source | | URL | | Drop | | 1117 Production | | Name | | IPv4 | | Category | | Action | | 1118 | +-----+----+ +-----+----+ +----+-----+ +----+-----+ | 1119 | | | | | | 1120 +--------------------+-----------+--------------------+ 1121 | | | | 1122 V V V V 1123 +-------+------------+-----------+------------+-------+ 1124 | | | | | | 1125 | | V V | | 1126 | | +----------+ +----------+ | | 1127 | | | Packet | | Payload | | | 1128 | | | Clause | | Clause | | | 1129 | | +-----+----+ +----+-----+ | | 1130 | | | | | | 1131 | | V V | | 1132 | | +---------------+ | | 1133 | | | Condition | | | 1134 Structure | | | Clause | | | 1135 Production | | +-------+-------+ | | 1136 | | | | | 1137 | | V V | 1138 | | +----------------------+ | 1139 | | | Rule Clause | | 1140 | | +-----------+----------+ | 1141 | | | | 1142 | V V | 1143 | +-----------------------------------------+ | 1144 | | I2NSF Clause | | 1145 | +--------------------+--------------------+ | 1146 | | | 1147 +--------------------------+--------------------------+ 1148 | 1149 V 1150 Low-Level Policy 1152 Figure 9: Generator Construction for Web-Filter NSF 1153 1154 block_web 1155 1156 1157 1158 10.0.0.1 1159 10.0.0.3 1160 1161 1162 harm.com 1163 illegal.com 1164 1165 1166 drop 1167 1168 1170 Figure 10: Example of Low-Level Policy 1172 5. Implementation Considerations 1174 The implementation considerations in this document include the 1175 following three: "data model auto-adaptation", "data conversion", and 1176 "policy provisioning". 1178 5.1. Data Model Auto-adaptation 1180 Security Controller which acts as the intermediary MUST process the 1181 data according to the data model of the connected interfaces. 1182 However, the data model can be changed flexibly depending on the 1183 situation, and Security Controller may adapt to the change. 1184 Therefore, Security Controller can be implemented for convenience so 1185 that the security policy translator can easily adapt to the change of 1186 the data model. 1188 The translator constructs and uses the DFA to adapt to Consumer- 1189 Facing Interface Data Model. In addition, the CFG is constructed and 1190 used to adapt to NSF-Facing Interface Data Model. Both the DFA and 1191 the CFG follow the same tree structure of YANG Data Model. 1193 The DFA starts at the node and expands operations by changing the 1194 state according to the input. Based on the YANG Data Model, a 1195 container node is defined as a middle state and a leaf node is 1196 defined as an extractor node. After that, if the nodes are connected 1197 in the same way as the hierarchical structure of the data model, 1198 Security Controller can automatically construct the DFA. The DFA can 1199 be conveniently built by investigating the link structure using the 1200 stack, starting with the root node. 1202 The CFG starts at the leaf nodes and is grouped into clauses until 1203 all the nodes are merged into one node. A leaf node is defined as 1204 the content production, and a container node is defined as the 1205 structure production. After that, if the nodes are connected in the 1206 same way as the hierarchy of the data model, Security Controller can 1207 automatically construct the CFG. The CFG can be conveniently 1208 constructed by investigating the link structure using the priority 1209 queue data, starting with the leaf nodes. 1211 5.2. Data Conversion 1213 Security Controller requires the ability to materialize the abstract 1214 data in the high-level security policy and forward it to NSFs. 1215 Security Controller can receive endpoint information as keywords 1216 through the high-level security policy. At this time, if the 1217 endpoint information corresponding to the keyword is mapped and the 1218 query is transmitted to the NSF Database, the NSF Database can be 1219 conveniently registered with necessary information for data 1220 conversion. When a policy tries to establish a policy through the 1221 keyword, Security Controller searches the details corresponding to 1222 the keyword registered in the NSF Database and converts the keywords 1223 into the appropriate and specified data. 1225 5.3. Policy Provisioning 1227 This document stated that policy provisioning function is necessary 1228 to enable users without expert security knowledge to create policies. 1229 Policy provisioning is determined by the capability of the NSF. If 1230 the NSF has information about the capability in the policy, the 1231 probability of selection increases. 1233 Most importantly, selected NSFs may be able to perform all 1234 capabilities in the security policy. This document recommends a 1235 study of policy provisioning algorithms that are highly efficient and 1236 can satisfy all capabilities in the security policy. 1238 6. Features of Policy Translator Design 1240 First, by showing a visualized translator structure, the security 1241 manager can handle various policy changes. Translator can be shown 1242 by visualizing DFA and Context-free Grammar so that the manager can 1243 easily understand the structure of Policy Translator. 1245 Second, if I2NSF User only keeps the hierarchy of the data model, 1246 I2NSF User can freely create high-level policies. In the case of 1247 DFA, data extraction can be performed in the same way even if the 1248 order of input is changed. The design of the policy translator is 1249 more flexible than the existing method that works by keeping the tag 1250 's position and order exactly. 1252 Third, the structure of Policy Translator can be updated even while 1253 Policy Translator is operating. Because Policy Translator is 1254 modularized, the translator can adapt to changes in the NSF 1255 capability while the I2NSF framework is running. The function of 1256 changing the translator's structure can be provided through 1257 Registration Interface. 1259 7. Security Considerations 1261 There is no security concern in the proposed security policy 1262 translator as long as the I2NSF interfaces (i.e., Consumer-Facing 1263 Interface, NSF-Facing Interface, and Registration Interface) are 1264 protected by secure communication channels. 1266 8. Acknowledgments 1268 This work was supported by Institute of Information & Communications 1269 Technology Planning & Evaluation (IITP) grant funded by the Ministry 1270 of Science and ICT (MSIT), Korea, (R-20160222-002755, Cloud based 1271 Security Intelligence Technology Development for the Customized 1272 Security Service Provisioning). 1274 This work was supported in part by the MSIT under the Information 1275 Technology Research Center (ITRC) support program (IITP- 1276 2019-2017-0-01633) supervised by the IITP. 1278 9. References 1280 9.1. Normative References 1282 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1283 Network Configuration Protocol (NETCONF)", RFC 6020, 1284 October 2010. 1286 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1287 Bierman, "Network Configuration Protocol (NETCONF)", 1288 RFC 6241, June 2011. 1290 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1291 Protocol", RFC 8040, January 2017. 1293 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1294 Kumar, "Framework for Interface to Network Security 1295 Functions", RFC 8329, February 2018. 1297 9.2. Informative References 1299 [Automata] 1300 Peter, L., "Formal Languages and Automata, 6th Edition", 1301 January 2016. 1303 [consumer-facing-inf-dm] 1304 Jeong, J., Chung, C., Ahn, T., Kumar, R., and S. Hares, 1305 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 1306 ietf-i2nsf-consumer-facing-interface-dm-07 (work in 1307 progress), November 2019. 1309 [i2nsf-terminology] 1310 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1311 Birkholz, "Interface to Network Security Functions (I2NSF) 1312 Terminology", draft-ietf-i2nsf-terminology-08 (work in 1313 progress), July 2019. 1315 [nsf-facing-inf-dm] 1316 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, 1317 "I2NSF Network Security Function-Facing Interface YANG 1318 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-08 1319 (work in progress), November 2019. 1321 [registration-inf-dm] 1322 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 1323 Registration Interface YANG Data Model", draft-ietf-i2nsf- 1324 registration-interface-dm-05 (work in progress), July 1325 2019. 1327 [XML] W3C, "On Views and XML (Extensible Markup Language)", June 1328 1999. 1330 [XSLT] W3C, "Extensible Stylesheet Language Transformations 1331 (XSLT) Version 1.0", November 1999. 1333 Appendix A. Changes from draft-yang-i2nsf-security-policy- 1334 translation-04 1336 The following changes are made from draft-yang-i2nsf-security-policy- 1337 translation-04: 1339 o In Figure 7, the mapping information between the data models of 1340 the Consumer-Facing Interface and the NSF-Facing Interface for 1341 data conversion is annotated with comments. 1343 Authors' Addresses 1345 Jaehoon Paul Jeong 1346 Department of Computer Science and Engineering 1347 Sungkyunkwan University 1348 2066 Seobu-Ro, Jangan-Gu 1349 Suwon, Gyeonggi-Do 16419 1350 Republic of Korea 1352 Phone: +82 31 299 4957 1353 Fax: +82 31 290 7996 1354 EMail: pauljeong@skku.edu 1355 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1357 Jinhyuk Yang 1358 Department of Electronic, Electrical and Computer Engineering 1359 Sungkyunkwan University 1360 2066 Seobu-Ro, Jangan-Gu 1361 Suwon, Gyeonggi-Do 16419 1362 Republic of Korea 1364 Phone: +82 10 8520 8039 1365 EMail: jin.hyuk@skku.edu 1367 Chaehong Chung 1368 Department of Electronic, Electrical and Computer Engineering 1369 Sungkyunkwan University 1370 2066 Seobu-Ro, Jangan-Gu 1371 Suwon, Gyeonggi-Do 16419 1372 Republic of Korea 1374 Phone: +82 31 299 4957 1375 EMail: darkhong@skku.edu 1376 Jinyong Tim Kim 1377 Department of Electronic, Electrical and Computer Engineering 1378 Sungkyunkwan University 1379 2066 Seobu-Ro, Jangan-Gu 1380 Suwon, Gyeonggi-Do 16419 1381 Republic of Korea 1383 Phone: +82 10 8273 0930 1384 EMail: timkim@skku.edu