idnits 2.17.1 draft-yang-i2nsf-security-policy-translation-04.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 (July 24, 2019) is 1709 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 8329 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: Standards Track C. Chung 5 Expires: January 25, 2020 J. Kim 6 Sungkyunkwan University 7 July 24, 2019 9 Security Policy Translation in Interface to Network Security Functions 10 draft-yang-i2nsf-security-policy-translation-04 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 the Consumer-Facing Inteface YANG data model 22 and a low-level security policy based on the NSF-Facing Interface 23 YANG data model. Also, it describes an architecture of a security 24 policy translator along with an NSF database, and the process of 25 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 January 25, 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 . . . . . . . . . . . . . . . . . 19 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-03 . . . . . . . . . . . . . . . . . . . 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 /consumer-facing/policy/policy-name 561 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 562 /system-policy-name 564 /consumer-facing/policy/rule/rule-name 565 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 566 /rules/rule-name 568 /consumer-facing/policy 569 /rule/event/time-information/time/begin-time 570 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 571 /rules/time-zone/absolute-time-zone/start-time 573 /consumer-facing/policy 574 /rule/event/time-information/time/end-time 575 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy 576 /rules/time-zone/absolute-time-zone/end-time 578 /consumer-facing/policy/rule/condition 579 /firewall-condition/source-target/src-target 580 -> reference: /consumer-facing/policy 581 /endpoint-group/user-group/name 582 -> extract: /consumer-facing/policy 583 /endpoint-group/user-group/date 584 -> mapping: /nsf-facing/i2nsf-security-policy 585 /rule/date 586 -> extract: /consumer-facing/policy 587 /endpoint-group/user-group/ip-address 588 -> mapping: /nsf-facing/i2nsf-security-policy 589 /system-policy/rules 590 /condition-clause-container 591 /packet-security-ipv4-condition 592 /pkt-sec-ipv4-src/ipv4-address/ipv4 593 -> extract: /consumer-facing/policy 594 /endpoint-group/user-group/range-ip-address 595 /start-ip-address 596 -> mapping: /nsf-facing/i2nsf-security-policy 597 /system-policy/rules 598 /condition-clause-container 599 /packet-security-ipv4-condition 600 /pkt-sec-ipv4-src/range-ipv4-address 601 /start-ipv4-address 602 -> extract: /consumer-facing/policy 603 /endpoint-group/user-group/range-ip-address 604 /end-ip-address 605 -> mapping: /nsf-facing/i2nsf-security-policy 606 /system-policy/rules 607 /condition-clause-container 608 /packet-security-ipv4-condition 609 /pkt-sec-ipv4-src/range-ipv4-address 610 /end-ipv4-address 612 /consumer-facing/policy/rule/condition 613 /firewall-condition/destination-target/dest-target 614 -> reference: /consumer-facing/policy 615 /endpoint-group/user-group/name 616 -> extract: /consumer-facing/policy 617 /endpoint-group/user-group/date 618 -> mapping: /nsf-facing/i2nsf-security-policy 619 /system-policy/rule/date 620 -> extract: /consumer-facing/policy 621 /endpoint-group/user-group/ip-address 622 -> mapping: /nsf-facing/i2nsf-security-policy 623 /system-policy/rules 624 /condition-clause-container 625 /packet-security-ipv4-condition 626 /pkt-sec-ipv4-dest/ipv4-address/ipv4 627 -> extract: /consumer-facing/policy 628 /endpoint-group/user-group 629 /range-ip-address/start-ip-address 630 -> mapping: /nsf-facing/i2nsf-security-policy 631 /system-policy/rules 632 /condition-clause-container 633 /packet-security-ipv4-condition 634 /pkt-sec-ipv4-dest/range-ipv4-address 635 /start-ipv4-address 636 -> extract: /consumer-facing/policy 637 /endpoint-group/user-group 638 /range-ip-address/end-ip-address 639 -> mapping: /nsf-facing/i2nsf-security-policy 640 /system-policy/rules 641 /condition-clause-container 642 /packet-security-ipv4-condition 643 /pkt-sec-ipv4-dest/range-ipv4-address 644 /end-ipv4-address 646 /consumer-facing/policy/rule/condition 647 /ddos-condition/source-target/src-target 648 -> reference: /consumer-facing/policy 649 /endpoint-group/device-group/name 650 -> extract: /consumer-facing/policy 651 /endpoint-group/device-group/date 652 -> mapping: /nsf-facing/i2nsf-security-policy/rule/date 653 -> extract: /consumer-facing/policy 654 /endpoint-group/device-group/ip-address 655 -> mapping: /nsf-facing/i2nsf-security-policy 656 /system-policy/rules 657 /condition-clause-container 658 /packet-security-ipv4-condition 659 /pkt-sec-ipv4-src/ipv4-address/ipv4 660 -> extract: /consumer-facing/policy 661 /endpoint-group/device-group 662 /range-ip-address/start-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/range-ipv4-address 668 /start-ipv4-address 669 -> extract: /consumer-facing/policy 670 /endpoint-group/device-group 671 /range-ip-address/end-ip-address 672 -> mapping: /nsf-facing/i2nsf-security-policy 673 /system-policy/rules 674 /condition-clause-container 675 /packet-security-ipv4-condition 676 /pkt-sec-ipv4-src/range-ipv4-address 677 /end-ipv4-address 679 /consumer-facing/policy/rule/condition 680 /ddos-condition/destination-target/dest-target 681 -> reference: /consumer-facing/policy 682 /endpoint-group/device-group/name 683 -> extract: /consumer-facing/policy 684 /endpoint-group/device-group/date 685 -> mapping: /nsf-facing/i2nsf-security-policy/rule/date 686 -> extract: /consumer-facing/policy 687 /endpoint-group/device-group/ip-address 688 -> mapping: /nsf-facing/i2nsf-security-policy 689 /system-policy/rules 690 /condition-clause-container 691 /packet-security-ipv4-condition 692 /pkt-sec-ipv4-dest/ipv4-address/ipv4 693 -> extract: /consumer-facing/policy 694 /endpoint-group/device-group 695 /range-ip-address/start-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/range-ipv4-address 701 /start-ipv4-address 702 -> extract: /consumer-facing/policy 703 /endpoint-group/device-group 704 /range-ip-address/end-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 /end-ipv4-address 712 /consumer-facing/policy/rule/condition 713 /ddos-condition/rate-limit/packet-per-second 714 -> mapping: /nsf-facing/i2nsf-security-policy 715 /system-policy/rules/condition-clause-container 716 /packet-security-ddos-condition/pkt-sec-alert-rate 718 /consumer-facing/policy/rule/condition 719 /custom-condition/source-target/src-target 720 -> reference: /consumer-facing/policy 721 /threat-prevention/payload-content/name 722 -> extract: /consumer-facing/policy 723 /threat-prevention/payload-content/date 724 -> mapping: /nsf-facing/i2nsf-security-policy 725 /system-policy/rules/date 726 -> extract: /consumer-facing/policy 727 /threat-prevention/payload-content/content 728 -> mapping: /nsf-facing/i2nsf-security-policy 729 /system-policy/rules 730 /condition-clause-container 731 /packet-security-payload-condition 732 /pkt-payload-content 734 /consumer-facing/policy/rule/condition 735 /custom-condition/destination-target/dest-target 736 -> reference: /consumer-facing/policy 737 /threat-prevention/payload-content/name 738 -> extract: /consumer-facing/policy 739 /threat-prevention/payload-content/date 740 -> mapping: /nsf-facing/i2nsf-security-policy 741 /system-policy/rules/date 743 -> extract: /consumer-facing/policy 744 /threat-prevention/payload-content/content 745 -> mapping: /nsf-facing/i2nsf-security-policy 746 /system-policy/rules 747 /condition-clause-container 748 /packet-security-payload-condition 749 /pkt-payload-content 751 /consumer-facing/policy/rule/condition 752 /custom-condition/threat-feed-condition 753 /source-target/src-target 754 -> reference: /consumer-facing/policy 755 /threat-prevention/threat-feed-list/name 756 -> extract: /consumer-facing/policy 757 /threat-prevention/threat-feed-list/date 758 -> mapping: /nsf-facing/i2nsf-security-policy 759 /system-policy/rules/date 760 -> extract: /consumer-facing/policy 761 /threat-prevention/threat-feed-list 762 /threat-feed-server/ip-address 763 -> mapping: /nsf-facing/i2nsf-security-policy 764 /system-policy/rules 765 /condition-clause-container 766 /packet-security-ipv4-condition 767 /pkt-sec-ipv4-src/ipv4-address/ipv4 768 -> extract: /consumer-facing/policy 769 /threat-prevention/threat-feed-list 770 /threat-feed-server/range-ip-address 771 /start-ip-address 772 -> mapping: /nsf-facing/i2nsf-security-policy 773 /system-policy/rules 774 /condition-clause-container 775 /packet-security-ipv4-condition 776 /pkt-sec-ipv4-src/range-ipv4-address 777 /start-ipv4-address 778 -> extract: /consumer-facing/policy 779 /threat-prevention/threat-feed-list 780 /threat-feed-server/range-ip-address 781 /end-ip-address 782 -> mapping: /nsf-facing/i2nsf-security-policy 783 /system-policy/rules 784 /condition-clause-container 785 /packet-security-ipv4-condition 786 /pkt-sec-ipv4-src/range-ipv4-address 787 /end-ipv4-address 788 -> extract: /consumer-facing/policy 789 /threat-prevention/threat-feed-list 790 /threat-feed-server 791 /threat-feed-description 792 -> mapping: /nsf-facing/i2nsf-security-policy 793 /system-policy/rules 794 /condition-clause-container 795 /packet-security-ipv4-condition 796 /ipv4-description 798 /consumer-facing/policy/rule/condition 799 /custom-condition/threat-feed-condition 800 /destination-target/dest-target 801 -> reference: /consumer-facing/policy 802 /threat-prevention/threat-feed-list/name 803 -> extract: /consumer-facing/policy 804 /threat-prevention/threat-feed-list/date 805 -> mapping: /nsf-facing/i2nsf-security-policy 806 /system-policy/rules/date 807 -> extract: /consumer-facing/policy 808 /threat-prevention/threat-feed-list 809 /threat-feed-server/ip-address 810 -> mapping: /nsf-facing/i2nsf-security-policy 811 /system-policy/rules 812 /condition-clause-container 813 /packet-security-ipv4-condition 814 /pkt-sec-ipv4-dest/ipv4-address/ipv4 815 -> extract: /consumer-facing/policy 816 /threat-prevention/threat-feed-list 817 /threat-feed-server/range-ip-address 818 /start-ip-address 819 -> mapping: /nsf-facing/i2nsf-security-policy 820 /system-policy/rules 821 /condition-clause-container 822 /packet-security-ipv4-condition 823 /pkt-sec-ipv4-dest/range-ipv4-address 824 /start-ipv4-address 825 -> extract: /consumer-facing/policy 826 /threat-prevention/threat-feed-list 827 /threat-feed-server/range-ip-address 828 /end-ip-address 829 -> mapping: /nsf-facing/i2nsf-security-policy 830 /system-policy/rules 831 /condition-clause-container 832 /packet-security-ipv4-condition 833 /pkt-sec-ipv4-dest/range-ipv4-address 834 /end-ipv4-address 835 -> extract: /consumer-facing/policy 836 /threat-prevention/threat-feed-list 837 /threat-feed-server 838 /threat-feed-description 840 -> mapping: /nsf-facing/i2nsf-security-policy 841 /system-policy/rules 842 /condition-clause-container 843 /packet-security-ipv4-condition 844 /ipv4-description 846 /consumer-facing/policy/rule/action/name 847 -> mapping: /nsf-facing/i2nsf-security-policy 848 /system-policy/rules/action-clause-container 849 /packet-action/ingress-action 850 -> mapping: /nsf-facing/i2nsf-security-policy 851 /system-policy/rules/action-clause-container 852 /packet-action/egress-action 853 -> mapping: /nsf-facing/i2nsf-security-policy 854 /system-policy/rules/action-clause-container 855 /packet-action/log-action 856 -> mapping: /nsf-facing/i2nsf-security-policy 857 /system-policy/rules/action-clause-container 858 /advanced-action/content-security-control 859 -> mapping: /nsf-facing/i2nsf-security-policy 860 /system-policy/rules/action-clause-container 861 /advanced-action/attack-mitigation-control 863 /consumer-facing/policy/rule/ipsec-method 864 -> mapping: /nsf-facing/i2nsf-ipsec 866 /consumer-facing/policy-domain/name 867 -> mapping: /nsf-facing/i2nsf-security-policy 868 /system-policy/rule-group/groups/group-name 870 Figure 7: Mapping Information for Data Conversion 872 4.3.4. Policy Provisioning 873 Log-keeper Low-level Web-filter 874 NSF Policy Data NSF 875 +-------------------+ +--------------------+ +-------------------+ 876 | Rule Name | | Rule Name | | Rule Name | 877 | +--------------+ | | +--------------+ | | +--------------+ | 878 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | | 879 | +--------------+ | | +--------------+ | | +--------------+ | 880 | | | | | | 881 | Source IPv4 | | Source IPv4 | | Source IPv4 | 882 | +--------------+ | | +--------------+ | | +--------------+ | 883 | | [10.0.0.1, |<-|<-|<-| [10.0.0.1, |->|->|->| [10.0.0.1, | | 884 | | 10.0.0.3] | | | | 10.0.0.3] | | | | 10.0.0.3] | | 885 | +--------------+ | | +--------------+ | | +--------------+ | 886 | | | | | | 887 | | | URL Category | | URL Category | 888 | | | +--------------+ | | +--------------+ | 889 | | | | [harm.com, |->|->|->| [harm.com, | | 890 | | | | illegal.com] | | | | illegal.com] | | 891 | | | +--------------+ | | +--------------+ | 892 | | | | | | 893 | Log Action | | Log Action | | | 894 | +--------------+ | | +--------------+ | | | 895 | | True |<-|<-|<-| True | | | | 896 | +--------------+ | | +--------------+ | | | 897 +-------------------+ | | | | 898 | Drop Action | | Drop Action | 899 | +--------------+ | | +--------------+ | 900 | | True |->|->|->| True | | 901 | +--------------+ | | +--------------+ | 902 +--------------------+ +-------------------+ 904 Figure 8: Example of Policy Provisioning 906 Generator searches for proper NSFs which can cover all of 907 capabilities in the high-level policy. Generator searches for target 908 NSFs by comparing only NSF capabilities which is registered by Vendor 909 Management System. This process is called by "policy provisioning" 910 because Generator finds proper NSFs by using only the policy. If 911 target NSFs are found by using other data which is not included in a 912 user's policy, it means that the user already knows the specific 913 knowledge of an NSF in the I2NSF Framework. Figure 8 shows an 914 example of policy provisioning. In this example, log-keeper NSF and 915 web-filter NSF are selected for covering capabilities in the security 916 policy. All of capabilities can be covered by two selected NSFs. 918 4.4. CFG-based Policy Generator 920 Generator makes low-level security policies for each target NSF with 921 the extracted data. We constructed Generator by using Context Free 922 Grammar (CFG). CFG is a set of production rules which can describe 923 all possible strings in a given formal language(e.g., programming 924 language). The low-level policy also has its own language based on a 925 YANG data model of NSF-Facing Interface. Thus, we can construct the 926 productions based on the YANG data model. The productions that makes 927 up the low-level security policy are categorized into two types, 928 'Content Production' and 'Structure Production'. 930 4.4.1. Content Production 932 Content Production is for injecting data into low-level policies to 933 be generated. A security manager(i.e., a person (or software) to 934 make productions for security policies) can construct Content 935 Productions in the form of an expression as the following 936 productions: 938 o [cont_prod] -> [cont_prod][cont_prod] (Where duplication is 939 allowed.) 941 o [cont_prod] -> [cont_data] 943 o [cont_data] -> data_1 | data_2 | ... | data_n 945 Square brackets mean non-terminal state. If there are no non- 946 terminal states, it means that the string is completely generated. 947 When the duplication of content tag is allowed, the security manager 948 adds the first production for a rule. If there is no need to allow 949 duplication, the first production can be skipped because it is an 950 optional production. 952 The second production is the main production for Content Production 953 because it generates the tag which contains data for low-level 954 policy. Last, the third production is for injecting data into a tag 955 which is generated by the second production. If data is changed for 956 an NSF, the security manager needs to change "only the third 957 production" for data mapping in each NSF. 959 For example, if the security manager wants to express a low-level 960 policy for source IP address, Content Production can be constructed 961 in the following productions: 963 o [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.) 965 o [cont_ipv4] -> [cont_ipv4_data] 966 o [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 968 4.4.2. Structure Production 970 Structure Production is for grouping other tags into a hierarchy. 971 The security manager can construct Structure Production in the form 972 of an expression as the following production: 974 o [struct_prod] -> [prod_1]...[prod_n] 976 Structure Production can be expressed as a single production. The 977 above production means to group other tags by the name of a tag which 978 is called by 'struct_tag'. [prod_x] is a state for generating a tag 979 which wants to be grouped by Structure Production. [prod_x] can be 980 both Content Production and Structure Production. For example, if 981 the security manager wants to express the low-level policy for the 982 I2NSF tag, which is grouping 'name' and 'rules', Structure Production 983 can be constructed as the following production where [cont_name] is 984 the state for Content Production and [struct_rule] is the state for 985 Structure Production. 987 o [struct_i2nsf] -> [cont_name][struct_rules] 989 4.4.3. Generator Construction 991 The security manager can build a generator by combining the two 992 productions which are described in Section 4.4.1 and Section 4.4.2. 993 Figure 9 shows the CFG-based Generator construction of the web-filter 994 NSF. It is constructed based on the NSF-Facing Interface Data Model 995 in [nsf-facing-inf-dm]. According to Figure 9, the security manager 996 can express productions for each clause as in following CFG: 998 1. [cont_name] -> [cont_name_data] 1000 2. [cont_name_data] -> block_web 1002 3. [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication) 1004 4. [cont_ipv4] -> [cont_ipv4_data] 1006 5. [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 1008 6. [cont_url] -> [cont_url][cont_url] (Allow duplication) 1010 7. [cont_url] -> [cont_url_data] 1012 8. [cont_url_data] -> harm.com | illegal.com 1013 9. [cont_action] -> [cont_action_data] 1015 10. [cont_action_data] -> drop 1017 11. [struct_packet] -> [cont_ipv4] 1019 12. [struct_payload] -> [cont_url] 1021 13. [struct_cond] -> 1022 [struct_packet][struct_payload] 1024 14. [struct_rules] -> [struct_cond][cont_action] 1026 15. [struct_i2nsf] -> [cont_name][struct_rules] 1028 Then, Generator generates a low-level policy by using the above CFG. 1029 The low-level policy is generated by the following process: 1031 1. Start: [struct_i2nsf] 1033 2. Production 15: [cont_name][struct_rules] 1035 3. Production 1: [cont_name_data][struct_rules] 1038 4. Production 2: block_web[struct_rules] 1041 5. Production 14: block_web[struct_cond][cont_action] 1044 6. Production 13: block_web[struct_packet][struct_payload][cont_action] 1046 1048 7. Production 11: block_web[cont_ipv4][struct_payload] 1050 [cont_action] 1052 8. Production 3: block_web[cont_ipv4][cont_ipv4][struct_payload][cont_action] 1056 9. Production 4: block_web[cont_ipv4_data][cont_ipv4_dat 1058 a][struct_payload][cont_action] 1061 10. Production 5: block_web10.0.0.110.0.0.3[struct_payload][cont_action] 1065 11. Production 12: block_web10.0.0.110.0.0.3[cont_url][cont_action] 1070 12. Production 6: block_web10.0.0.110.0.0.3[cont_url][cont_url][cont_actio 1073 n] 1075 13. Production 7: block_web10.0.0.110.0.0.3[cont_url_data][cont_url_data]< 1078 /payload>[cont_action] 1080 14. Production 8: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action] 1085 15. Production 9: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action_data] 1090 16. Production 10: block_web10.0.0.110.0.0.3harm.comillegal.com< 1093 /condition>drop 1095 The last production has no non-terminal state, and the low-level 1096 policy is completely generated. Figure 10 shows the generated low- 1097 level policy where tab characters and newline characters are added. 1099 +-----------------------------------------------------+ 1100 | +----------+ +----------+ +----------+ +----------+ | 1101 Content | | Rule | | Source | | URL | | Drop | | 1102 Production | | Name | | IPv4 | | Category | | Action | | 1103 | +-----+----+ +-----+----+ +----+-----+ +----+-----+ | 1104 | | | | | | 1105 +--------------------+-----------+--------------------+ 1106 | | | | 1107 V V V V 1108 +-------+------------+-----------+------------+-------+ 1109 | | | | | | 1110 | | V V | | 1111 | | +----------+ +----------+ | | 1112 | | | Packet | | Payload | | | 1113 | | | Clause | | Clause | | | 1114 | | +-----+----+ +----+-----+ | | 1115 | | | | | | 1116 | | V V | | 1117 | | +---------------+ | | 1118 | | | Condition | | | 1119 Structure | | | Clause | | | 1120 Production | | +-------+-------+ | | 1121 | | | | | 1122 | | V V | 1123 | | +----------------------+ | 1124 | | | Rule Clause | | 1125 | | +-----------+----------+ | 1126 | | | | 1127 | V V | 1128 | +-----------------------------------------+ | 1129 | | I2NSF Clause | | 1130 | +--------------------+--------------------+ | 1131 | | | 1132 +--------------------------+--------------------------+ 1133 | 1134 V 1135 Low-Level Policy 1137 Figure 9: Generator Construction for Web-Filter NSF 1138 1139 block_web 1140 1141 1142 1143 10.0.0.1 1144 10.0.0.3 1145 1146 1147 harm.com 1148 illegal.com 1149 1150 1151 drop 1152 1153 1155 Figure 10: Example of Low-Level Policy 1157 5. Implementation Considerations 1159 The implementation considerations in this document include the 1160 following three: "data model auto-adaptation", "data conversion", and 1161 "policy provisioning". 1163 5.1. Data Model Auto-adaptation 1165 Security Controller which acts as the intermediary MUST process the 1166 data according to the data model of the connected interfaces. 1167 However, the data model can be changed flexibly depending on the 1168 situation, and Security Controller may adapt to the change. 1169 Therefore, Security Controller can be implemented for convenience so 1170 that the security policy translator can easily adapt to the change of 1171 the data model. 1173 The translator constructs and uses the DFA to adapt to Consumer- 1174 Facing Interface Data Model. In addition, the CFG is constructed and 1175 used to adapt to NSF-Facing Interface Data Model. Both the DFA and 1176 the CFG follow the same tree structure of YANG Data Model. 1178 The DFA starts at the node and expands operations by changing the 1179 state according to the input. Based on the YANG Data Model, a 1180 container node is defined as a middle state and a leaf node is 1181 defined as an extractor node. After that, if the nodes are connected 1182 in the same way as the hierarchical structure of the data model, 1183 Security Controller can automatically construct the DFA. The DFA can 1184 be conveniently built by investigating the link structure using the 1185 stack, starting with the root node. 1187 The CFG starts at the leaf nodes and is grouped into clauses until 1188 all the nodes are merged into one node. A leaf node is defined as 1189 the content production, and a container node is defined as the 1190 structure production. After that, if the nodes are connected in the 1191 same way as the hierarchy of the data model, Security Controller can 1192 automatically construct the CFG. The CFG can be conveniently 1193 constructed by investigating the link structure using the priority 1194 queue data, starting with the leaf nodes. 1196 5.2. Data Conversion 1198 Security Controller requires the ability to materialize the abstract 1199 data in the high-level security policy and forward it to NSFs. 1200 Security Controller can receive endpoint information as keywords 1201 through the high-level security policy. At this time, if the 1202 endpoint information corresponding to the keyword is mapped and the 1203 query is transmitted to the NSF Database, the NSF Database can be 1204 conveniently registered with necessary information for data 1205 conversion. When a policy tries to establish a policy through the 1206 keyword, Security Controller searches the details corresponding to 1207 the keyword registered in the NSF Database and converts the keywords 1208 into the appropriate and specified data. 1210 5.3. Policy Provisioning 1212 This document stated that policy provisioning function is necessary 1213 to enable users without expert security knowledge to create policies. 1214 Policy provisioning is determined by the capability of the NSF. If 1215 the NSF has information about the capability in the policy, the 1216 probability of selection increases. 1218 Most importantly, selected NSFs may be able to perform all 1219 capabilities in the security policy. This document recommends a 1220 study of policy provisioning algorithms that are highly efficient and 1221 can satisfy all capabilities in the security policy. 1223 6. Features of Policy Translator Design 1225 First, by showing a visualized translator structure, the security 1226 manager can handle various policy changes. Translator can be shown 1227 by visualizing DFA and Context-free Grammar so that the manager can 1228 easily understand the structure of Policy Translator. 1230 Second, if I2NSF User only keeps the hierarchy of the data model, 1231 I2NSF User can freely create high-level policies. In the case of 1232 DFA, data extraction can be performed in the same way even if the 1233 order of input is changed. The design of the policy translator is 1234 more flexible than the existing method that works by keeping the tag 1235 's position and order exactly. 1237 Third, the structure of Policy Translator can be updated even while 1238 Policy Translator is operating. Because Policy Translator is 1239 modularized, the translator can adapt to changes in the NSF 1240 capability while the I2NSF framework is running. The function of 1241 changing the translator's structure can be provided through 1242 Registration Interface. 1244 7. Security Considerations 1246 There is no security concern in the proposed security policy 1247 translator as long as the I2NSF interfaces (i.e., Consumer-Facing 1248 Interface, NSF-Facing Interface, and Registration Interface) are 1249 protected by secure communication channels. 1251 8. Acknowledgments 1253 This work was supported by Institute of Information & Communications 1254 Technology Planning & Evaluation (IITP) grant funded by the Korea 1255 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based 1256 Security Intelligence Technology Development for the Customized 1257 Security Service Provisioning). 1259 This work was supported in part by the MSIT under the ITRC 1260 (Information Technology Research Center) support program (IITP- 1261 2018-2017-0-01633) supervised by the IITP. 1263 9. References 1265 9.1. Normative References 1267 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1268 Network Configuration Protocol (NETCONF)", RFC 6020, 1269 October 2010. 1271 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1272 Bierman, "Network Configuration Protocol (NETCONF)", 1273 RFC 6241, June 2011. 1275 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1276 Protocol", RFC 8040, January 2017. 1278 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1279 Kumar, "Framework for Interface to Network Security 1280 Functions", RFC 8329, February 2018. 1282 9.2. Informative References 1284 [Automata] 1285 Peter, L., "Formal Languages and Automata, 6th Edition", 1286 January 2016. 1288 [consumer-facing-inf-dm] 1289 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares, 1290 "I2NSF Consumer-Facing Interface YANG Data Model", draft- 1291 ietf-i2nsf-consumer-facing-interface-dm-06 (work in 1292 progress), July 2019. 1294 [i2nsf-terminology] 1295 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 1296 Birkholz, "Interface to Network Security Functions (I2NSF) 1297 Terminology", draft-ietf-i2nsf-terminology-08 (work in 1298 progress), July 2019. 1300 [nsf-facing-inf-dm] 1301 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin, 1302 "I2NSF Network Security Function-Facing Interface YANG 1303 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-07 1304 (work in progress), July 2019. 1306 [registration-inf-dm] 1307 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 1308 Registration Interface YANG Data Model", draft-ietf-i2nsf- 1309 registration-interface-dm-05 (work in progress), July 1310 2019. 1312 [XML] W3C, "On Views and XML (Extensible Markup Language)", June 1313 1999. 1315 [XSLT] W3C, "Extensible Stylesheet Language Transformations 1316 (XSLT) Version 1.0", November 1999. 1318 Appendix A. Changes from draft-yang-i2nsf-security-policy- 1319 translation-03 1321 The following changes are made from draft-yang-i2nsf-security-policy- 1322 translation-03: 1324 o In Section 4.3.2, an Entity-Relationship Diagram (ERD) is added 1325 for describing the architecture of NSF Database. It describes the 1326 design of the NSF Database. 1328 o In Section 4.3.3, a mapping list between Consumer-Facing Interface 1329 Data Model and NSF-Facing Interface Data Model is added for 1330 describing the data mapping process in detail after the data 1331 conversion. This section provides guidelines of data converter 1332 for a security policy translator developer. Also, this mapping 1333 helps this document to be useful as a standard document. 1335 Authors' Addresses 1337 Jaehoon Paul Jeong 1338 Department of Computer Science and Engineering 1339 Sungkyunkwan University 1340 2066 Seobu-Ro, Jangan-Gu 1341 Suwon, Gyeonggi-Do 16419 1342 Republic of Korea 1344 Phone: +82 31 299 4957 1345 Fax: +82 31 290 7996 1346 EMail: pauljeong@skku.edu 1347 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1349 Jinhyuk Yang 1350 Department of Electronic, Electrical and Computer Engineering 1351 Sungkyunkwan University 1352 2066 Seobu-Ro, Jangan-Gu 1353 Suwon, Gyeonggi-Do 16419 1354 Republic of Korea 1356 Phone: +82 10 8520 8039 1357 EMail: jin.hyuk@skku.edu 1358 Chaehong Chung 1359 Department of Electronic, Electrical and Computer Engineering 1360 Sungkyunkwan University 1361 2066 Seobu-Ro, Jangan-Gu 1362 Suwon, Gyeonggi-Do 16419 1363 Republic of Korea 1365 Phone: +82 10 8541 7158 1366 EMail: darkhong@skku.edu 1368 Jinyong Tim Kim 1369 Department of Electronic, Electrical and Computer Engineering 1370 Sungkyunkwan University 1371 2066 Seobu-Ro, Jangan-Gu 1372 Suwon, Gyeonggi-Do 16419 1373 Republic of Korea 1375 Phone: +82 10 8273 0930 1376 EMail: timkim@skku.edu