idnits 2.17.1 draft-yang-i2nsf-security-policy-translation-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 151: '... an NSF, the NSF MUST receive at least...' RFC 2119 keyword, line 156: '...ntence, the user MUST know that the NS...' RFC 2119 keyword, line 164: '... policy is REQUIRED in I2NSF....' RFC 2119 keyword, line 528: '... security policy MUST be provided abst...' RFC 2119 keyword, line 638: '...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 (21 February 2022) is 792 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: 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 == Outdated reference: A later version (-31) exists of draft-ietf-i2nsf-consumer-facing-interface-dm-16 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-20 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-14 Summary: 2 errors (**), 0 flaws (~~), 5 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 P. Lingga 4 Intended status: Standards Track J. Yang 5 Expires: 25 August 2022 C. Chung 6 Sungkyunkwan University 7 21 February 2022 9 Security Policy Translation in Interface to Network Security Functions 10 draft-yang-i2nsf-security-policy-translation-10 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 25 August 2022. 44 Copyright Notice 46 Copyright (c) 2022 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Necessity for Security Policy Translator . . . . . . . . . . 3 63 4. Design of Security Policy Translator . . . . . . . . . . . . 4 64 4.1. Overall Structure of Security Policy Translator . . . . . 5 65 4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . 6 66 4.2.1. Design of DFA-based Data Extractor . . . . . . . . . 6 67 4.2.2. Example Scenario for Data Extractor . . . . . . . . . 7 68 4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . 12 69 4.3.1. Role of Data Converter . . . . . . . . . . . . . . . 12 70 4.3.2. NSF Database . . . . . . . . . . . . . . . . . . . . 13 71 4.3.3. Data Conversion in Data Converter . . . . . . . . . . 15 72 4.3.4. Data Model Mapper . . . . . . . . . . . . . . . . . . 16 73 4.3.5. Policy Provisioning . . . . . . . . . . . . . . . . . 23 74 4.4. CFG-based Policy Generator . . . . . . . . . . . . . . . 25 75 4.4.1. Content Production . . . . . . . . . . . . . . . . . 25 76 4.4.2. Structure Production . . . . . . . . . . . . . . . . 26 77 4.4.3. Generator Construction . . . . . . . . . . . . . . . 26 78 5. Implementation Considerations . . . . . . . . . . . . . . . . 32 79 5.1. Data Model Auto-adaptation . . . . . . . . . . . . . . . 32 80 5.2. Data Conversion . . . . . . . . . . . . . . . . . . . . . 33 81 5.3. Policy Provisioning . . . . . . . . . . . . . . . . . . . 33 82 6. Features of Security Policy Translator Design . . . . . . . . 33 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 88 10.2. Informative References . . . . . . . . . . . . . . . . . 35 89 Appendix A. Changes from 90 draft-yang-i2nsf-security-policy-translation-09 . . . . . 36 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 93 1. Introduction 95 This document defines a scheme of a security policy translation in 96 Interface to Network Security Functions (I2NSF) Framework [RFC8329]. 97 First of all, this document explains the necessity of a security 98 policy translator (shortly called policy translator) in the I2NSF 99 framework. 101 The policy translator resides in Security Controller in the I2NSF 102 framework and translates a high-level security policy to a low-level 103 security policy for Network Security Functions (NSFs). A high-level 104 policy is specified by I2NSF User in the I2NSF framework and is 105 delivered to Security Controller via Consumer-Facing Interface 106 [I-D.ietf-i2nsf-consumer-facing-interface-dm]. It is translated into 107 a low-level policy by Policy Translator in Security Controller and is 108 delivered to NSFs to execute the rules corresponding to the low-level 109 policy via NSF-Facing Interface 110 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 112 2. Terminology 114 This document uses the terminology specified in [RFC8329]. 116 3. Necessity for Security Policy Translator 118 Security Controller acts as a coordinator between I2NSF User and 119 NSFs. Also, Security Controller has capability information of NSFs 120 that are registered via Registration Interface 121 [I-D.ietf-i2nsf-registration-interface-dm] by Developer's Management 122 System [RFC8329]. As a coordinator, Security Controller needs to 123 generate a low-level policy in the form of security rules intended by 124 the high-level policy, which can be understood by the corresponding 125 NSFs. 127 A high-level security policy is specified by RESTCONF/YANG 128 [RFC8040][RFC6020], and a low-level security policy is specified by 129 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level 130 security policy to the corresponding low-level security policy will 131 be able to rapidly elevate I2NSF in real-world deployment. A rule in 132 a high-level policy can include a broad target object, such as 133 employees in a company for a security service (e.g., firewall and web 134 filter). Such employees may be from human resource (HR) department, 135 software engineering department, and advertisement department. A 136 keyword of employee needs to be mapped to these employees from 137 various departments. This mapping needs to be handled by a security 138 policy translator in a flexible way while understanding the intention 139 of a policy specification. Let us consider the following two 140 policies: 142 * Block my son's computers from malicious websites. 144 * Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com 145 and illegal.com 147 The above two sentences are examples of policies for blocking 148 malicious websites. Both policies are for the same operation. 149 However, NSF cannot understand the first policy, because the policy 150 does not have any specified information for NSF. To set up the 151 policy at an NSF, the NSF MUST receive at least the source IP address 152 and website address for an operation. It means that the first 153 sentence is NOT compatible for an NSF policy. Conversely, when I2NSF 154 Users request a security policy to the system, they never make a 155 security policy like the second example. For generating a security 156 policy like the second sentence, the user MUST know that the NSF 157 needs to receive the specified information, source IP address and 158 website address. It means that the user understands the NSF 159 professionally, but there are not many professional users in a small 160 size of company or at a residential area. In conclusion, the I2NSF 161 User prefers to issue a security policy in the first sentence, but an 162 NSF will require the same policy as the second sentence with specific 163 information. Therefore, an advanced translation scheme of security 164 policy is REQUIRED in I2NSF. 166 This document proposes an approach using Automata theory [Automata] 167 for the policy translation, such as Deterministic Finite Automaton 168 (DFA) and Context Free Grammar (CFG). Note that Automata theory is 169 the foundation of programming language and compiler. Thus, with this 170 approach, I2NSF User can easily specify a high-level security policy 171 that will be enforced into the corresponding NSFs with a compatibly 172 low-level security policy with the help of Security Policy 173 Translator. Also, for easy management, a modularized translator 174 structure is proposed. 176 4. Design of Security Policy Translator 178 Commonly used security policies are created as XML(Extensible Markup 179 Language) [XML] files. A popular way to change the format of an XML 180 file is to use an XSLT (Extensible Stylesheet Language 181 Transformation) [XSLT] document. XSLT is an XML-based language to 182 transform an input XML file into another output XML file. However, 183 the use of XSLT makes it difficult to manage the security policy 184 translator and to handle the registration of new capabilities of 185 NSFs. With the necessity for a security policy translator, this 186 document describes a security policy translator based on Automata 187 theory. 189 4.1. Overall Structure of Security Policy Translator 191 +--------------------------------------------------+ 192 | I2NSF User | 193 +------------------------+-------------------------+ 194 | Consumer-Facing Interface 195 | 196 High-level Security Policy 197 | 198 Security Controller V 199 +------------------------+--------------------------------+ 200 | Security Policy | | 201 | Translator V | 202 | +---------------------+----------------------------++ | 203 | | | | | 204 | | V | | 205 | | +-------+--------+ +----------+ | | 206 | | | DFA-based | |Data Model| | | 207 | | | Data Extractor | | Mapper | | | 208 | | +-------+--------+ +----------+ | | 209 | | Extracted Data from | Mapping | | | 210 | | High-Level Policy V Model V | | 211 | | +-----+-----+ +--------+ | | 212 | | | Data |<--------->| NSF DB | | | 213 | | | Converter | +--------+ | | 214 | | +-----+-----+ | | 215 | | | Required Data for | | 216 | | V Target NSFs | | 217 | | +--------+---------+ | | 218 | | | CFG-based | | | 219 | | | Policy Generator | | | 220 | | +--------+---------+ | | 221 | | | | | 222 | | V | | 223 | +---------------------+-----------------------------+ | 224 | | | 225 | V | 226 +------------------------+--------------------------------+ 227 | NSF-Facing Interface 228 | 229 Low-level Security Policy 230 | 231 V 232 +------------------------+-------------------------+ 233 | NSF(s) | 234 +--------------------------------------------------+ 236 Figure 1: The Overall Design of Security Policy Translator 238 Figure 1 shows the overall design for Security Policy Translator in 239 Security Controller. There are four main components for Security 240 Policy Translator: Data Extractor, Data Converter, Policy Generator, 241 and Data Model Mapper. 243 Extractor is a DFA-based module for extracting data from a high-level 244 policy which I2NSF User delivered via Consumer-Facing Interface. 245 Data Model Mapper creates a mapping model for mapping the elements 246 between Consumer-Facing Interface and NSF-Facing Interface. Data 247 Converter converts the extracted data to the capabilities of target 248 NSFs for a low-level policy. It refers to an NSF Database (DB) in 249 order to convert an abstract subject or object into the corresponding 250 concrete subject or object (e.g., IP address and website URL). 251 Policy Generator generates a low-level policy which will execute the 252 NSF capabilities from Converter. 254 4.2. DFA-based Data Extractor 256 4.2.1. Design of DFA-based Data Extractor 258 +----------+ 259 | accepter | 260 +----------+ 261 | ^ 262 | | 263 v | 264 +------------------------------------------------------+ 265 | middle 1 | 266 +------------------------------------------------------+ 267 | ^ | ^ | ^ 268 | | | | ... | | 269 v | v | v | 271 ... ... ... 273 +-------------+ +-------------+ +-------------+ 274 | extractor 1 | | extractor 2 | ... | extractor m | 275 +-------------+ +-------------+ +-------------+ 276 data:1 data:2 data:m 278 Figure 2: DFA Architecture of Data Extractor 280 Figure 2 shows a design for Data Extractor in the security policy 281 translator. If a high-level policy contains data along the 282 hierarchical structure of the standard Consumer-Facing Interface YANG 283 data model [I-D.ietf-i2nsf-consumer-facing-interface-dm], data can be 284 easily extracted using the state transition machine, such as DFA. 285 The extracted data can be processed and used by an NSF to understand 286 it. Extractor can be constructed by designing a DFA with the same 287 hierarchical structure as a YANG data model. 289 After constructing a DFA, Data Extractor can extract all of data in 290 the entered high-level policy by using state transitions. Also, the 291 DFA can easily detect the grammar errors of the high-level policy. 292 The extracting algorithm of Data Extractor is as follows: 294 1. Start from the 'accepter' state. 296 2. Read the next tag from the high-level policy. 298 3. Transit to the corresponding state. 300 4. If the current state is in 'extractor', extract the corresponding 301 data, and then go back to step 2. 303 5. If the current state is in 'middle', go back to step 2. 305 6. If there is no possible transition and arrived at 'accepter' 306 state, the policy has no grammar error. Otherwise, there is a 307 grammar error, so stop the process with failure. 309 4.2.2. Example Scenario for Data Extractor 310 312 block_web_security_policy 313 314 block_web 315 316 317 Son's_PC 318 319 320 malicious_websites 321 322 323 324 325 drop 326 327 328 329 331 Figure 3: The Example of High-level Policy 332 +----------+ 333 | accepter | 334 +----------+ 335 | ^ 336 | | 337 v | 338 +------------------------------------------------------+ 339 | middle 1 | 340 +------------------------------------------------------+ 341 | ^ | ^ 342 | | | | 343 v | | | 344 +-------------+ | | 345 | extractor 1 | | | 346 +-------------+ | | 347 block_web_security | | 348 _policy v | 349 +------------------------------------------------------+ 350 | middle 2 | 351 +------------------------------------------------------+ 352 | ^ | ^ | ^ 353 | | | | | | 354 v | v | v | 355 +-------------+ +--------------------------+ +-------------+ 356 | extractor 2 | | middle 3 | | middle 6 | 357 +-------------+ +--------------------------+ +-------------+ 358 block_web | ^ | ^ | ^ 359 | | | | conition> | | 361 | | | | | | 362 | | condition> | | action>| | action> 364 v | v | v | 365 +-------------+ +-------------+ +-------------+ 366 | middle 4 | | middle 5 | | middle 7 | 367 +-------------+ +-------------+ +-------------+ 368 | ^ | ^ | ^ 369 | | | | 370 | | name>| | name> | | 371 v | v | v | 372 +-------------+ +-------------+ +-------------+ 373 | extractor 3 | | extractor 4 | | extractor 5 | 374 +-------------+ +-------------+ +-------------+ 375 Son's_PC malicious_websites drop 377 Figure 4: The Example of Data Extractor 379 To explain the Data Extractor process by referring to an example 380 scenario, assume that Security Controller received a high-level 381 policy for a web-filtering as shown in Figure 3. Then we can 382 construct DFA-based Data Extractor by using the design as shown in 383 Figure 2. Figure 4 shows the architecture of Data Extractor that is 384 based on the architecture in Figure 2 along with the input high-level 385 policy in Figure 3. Data Extractor can automatically extract all of 386 data in the high-level policy according to the following process: 388 1. Start from the 'accepter' state. 390 2. Read the first opening tag called '', and 391 transit to the 'middle 1' state. 393 3. Read the second opening tag called '', and transit to the 394 'extractor 1' state. 396 4. The current state is an 'extractor' state. Extract the data of 397 'name' field called 'block_web_security_policy'. 399 5. Read the second closing tag called '', and go back to the 400 'middle 1' state. 402 6. Read the third opening tag called '', and transit to the 403 'middle 2' state. 405 7. Read the fourth opening tag called '', and transit to the 406 'extractor 2' state. 408 8. The current state is an 'extractor' state. Extract the data of 409 'name' field called 'block_web'. 411 9. Read the fourth closing tag called '', and go back to the 412 'middle 2' state. 414 10. Read the fifth opening tag called '', and transit to 415 the 'middle 3' state. 417 11. Read the sixth opening tag called '', and 418 transit to the 'middle 4' state. 420 12. Read the seventh opening tag called '', and transit to 421 the 'extractor 3' state. 423 13. The current state is an 'extractor' state. Extract the data of 424 'source' field called 'Son's_PC'. 426 14. Read the seventh closing tag called '', and go back to 427 the 'middle 4' state. 429 15. Read the sixth closing tag called '', and 430 go back to the 'middle 3' state. 432 16. Read the eight opening tag called '', and transit 433 to the 'middle 5' state. 435 17. Read the ninth opening tag called '', and transit to 436 the 'extractor 4' state. 438 18. The current state is an 'extractor' state. Extract the data of 439 'url-name' field called 'malicious_websites'. 441 19. Read the ninth closing tag called '', and go back to 442 the 'middle 5' state. 444 20. Read the eight closing tag called '', and go 445 back to the 'middle 3' state. 447 21. Read the fifth closing tag called '', and go back to 448 the 'middle 2' state. 450 22. Read the tenth opening tag called '', and transit to 451 the 'middle 6' state. 453 23. Read the eleventh opening tag called '', and 454 transit to the 'middle 7' state. 456 24. Read the twelfth opening tag called '', and transit to 457 the 'extractor 5' state. 459 25. The current state is an 'extractor' state. Extract the data of 460 'action' field called 'drop'. 462 26. Read the twelfth closing tag called '', and go back to 463 the 'middle 7' state. 465 27. Read the eleventh closing tag called '', and go 466 back to the 'middle 6' state. 468 28. Read the tenth closing tag called '', and go back to 469 the 'middle 2' state. 471 29. Read the third closing tag called '', and go back to the 472 'middle 2' state. 474 30. Read the first closing tag called '', and go 475 back to the 'accepter' state. 477 31. There is no further possible transition, and the state is 478 finally on 'accepter' state. There is no grammar error in 479 Figure 3 so the scanning for data extraction is finished. 481 The above process is constructed by an extracting algorithm. After 482 finishing all the steps of the above process, Data Extractor can 483 extract all of data in Figure 3, 'block_web_security_policy', 484 'block_malicious', 'Son's_PC', 'malicious_websites', and 'drop'. 486 Since the translator is modularized into a DFA structure, a visual 487 understanding is feasible. Also, the performance of Data Extractor 488 is excellent compared to one-to-one searching of data for a 489 particular field. In addition, the management is efficient because 490 the DFA completely follows the hierarchy of Consumer-Facing 491 Interface. If I2NSF User wants to modify the data model of a high- 492 level policy, it only needs to change the connection of the relevant 493 DFA node. 495 4.3. Data Converter 497 4.3.1. Role of Data Converter 499 Every NSF has its own unique capabilities. The capabilities of an 500 NSF are registered into Security Controller by a Developer's 501 Management System, which manages the NSF, via Registration Interface. 502 Therefore, Security Controller already has all information about the 503 capabilities of NSFs. This means that Security Controller can find 504 target NSFs with only the data (e.g., subject and object for a 505 security policy) of the high-level policy by comparing the extracted 506 data with all capabilities of each NSF. This search process for 507 appropriate NSFs is called by policy provisioning, and it eliminates 508 the need for I2NSF User to specify the target NSFs explicitly in a 509 high-level security policy. 511 Data Converter selects target NSFs and converts the extracted data 512 into the capabilities of selected NSFs. If Security Controller uses 513 this data convertor, it can provide the policy provisioning function 514 to I2NSF User automatically. Thus, the translator design provides 515 big benefits to the I2NSF Framework. 517 4.3.2. NSF Database 519 The NSF Database contains all the information needed to convert high- 520 level policy data to low-level policy data. The contents of NSF 521 Database are classified as the following two: "endpoint information" 522 and "NSF capability information". 524 The first is "endpoint information". Endpoint information is 525 necessary to convert an abstract high-level policy data such as 526 Son's_PC, malicious to a specific low-level policy data such as 527 10.0.0.1, illegal.com. In the high-level policy, the range of 528 endpoints for applying security policy MUST be provided abstractly. 529 Thus, endpoint information is needed to specify the abstracted high- 530 level policy data. Endpoint information is provided by I2NSF User as 531 the high-level policy through Consumer-Facing Interface, and Security 532 Controller builds NSF Database based on received information. 534 The second is "NSF capability information". Since capability is 535 information that allows NSF to know what features it can support, NSF 536 capability information is used in policy provisioning process to 537 search the appropriate NSFs through the security policy. NSF 538 capability information is provided by Developer's Management System 539 (DMS) through Registration Interface, and Security Controller builds 540 NSF Database based on received information. In addition, if the NSF 541 sends monitoring information such as initiating information to 542 Security Controller through NSF-Facing Interface, Security Controller 543 can modify NSF Database accordingly. 545 NSF Capability Information Endpoint Information 546 +-------------------+ has convert +------------------+ 547 | NSF +||---+ +-------||+ Endpoint | 548 +-------------------+ | | +------------------+ 549 | *nsf_id (INT) | | | | *end_id (INT) | 550 | nsf_name (STRING)| | | | keyword (STRING) | 551 | inbound (INT) | | | +------------------+ 552 | outbound (INT) | | | 553 | bandwidth (INT) | | | 554 | activated (BOOL) | | | 555 +-------------------+ | | 556 +---------------+ | +---------------------+ 557 /|\ +------||+ Mapping Information | 558 +--------------------+ has | +---------------------+ 559 | Capability +||---+ | | *element_id (INT) | 560 +--------------------+ | | | element_name(STR) | 561 | *capa_id (INT) | | | | element_map (STR) | 562 | capa_name (STRING)| | | +---------------------+ 563 | capa_index (INT) | | | 564 +--------------------+ | | 565 /|\ /|\ 566 +-----------------------+ 567 | Field | 568 +-----------------------+ 569 | *field_id (INT) | 570 | field_name (STRING) | 571 | field_index (INT) | 572 | mapped_data (STRING) | 573 +-----------------------+ 575 Figure 5: Entity-Relationship Diagram of NSF Database 577 Figure 5 shows an Entity-Relationship Diagram (ERD) of NSF Database 578 designed to include both endpoint information received from I2NSF 579 User and NSF capability information received from DMS. By designing 580 the NSF database based on the ERD, all the information necessary for 581 security policy translation can be stored, and the network system 582 administrator can manage the NSF database efficiently. 584 ERD was expressed by using Crow's Foot notation. Crow's Foot 585 notation represents a relationship between entities as a line and 586 represents the cardinality of the relationship as a symbol at both 587 ends of the line. Attributes prefixed with * are key values of each 588 entity. A link with two vertical lines represents one-to-one 589 mapping, and a bird-shaped link represents one-to-many mapping. An 590 NSF entity stores the NSF name (nsf_name), NSF specification 591 (inbound, outbound, bandwidth), and NSF activation (activated). A 592 Capability entity stores the capability name (capa_name) and the 593 index of the capability field in a Registration Interface Data Model 594 (capa_index). An Endpoint entity stores the keyword of abstract data 595 conversion from I2NSF User (keyword). A Field entity stores the 596 field name (field_name), the index of the field index in an NSF- 597 Facing Interface Data Model, and converted data by referring to the 598 Endpoint entity and a 'convert' relationship. 600 4.3.3. Data Conversion in Data Converter 602 High-level Low-level 603 Policy Data Policy Data 604 +---------------+ +------------------------------+ 605 | Policy Name | | Policy Name | 606 | +-----------+ | The same value | +-------------------------+ | 607 | | block_web |-|------------------->|->|block_web_security_policy| | 608 | | _security | | | +-------------------------+ | 609 | | _policy | | | | 610 | +-----------+ | | | 611 | | | | 612 | Rule Name | | Rule Name | 613 | +-----------+ | The same value | +-------------------------+ | 614 | | block_web |-|------------------->|->| block_web | | 615 | +-----------+ | | +-------------------------+ | 616 | | | | 617 | Source | Conversion into | Source IPv4 Range | 618 | +-----------+ | User's IP address | +-------------------------+ | 619 | | Son's_PC |-|------------------->|->| Start: 10.0.0.1 | | 620 | |-----------+ | | | End : 10.0.0.3 | | 621 | | | +-------------------------+ | 622 | | | | 623 | URL Name | Conversion into | URL - User Defined | 624 | +-----------+ | malicious websites | +-------------------------+ | 625 | | malicious |-|------------------->|->| [harm.com, | | 626 | | _websites | | | | illegal.com] | | 627 | +-----------+ | | +-------------------------+ | 628 | | | | 629 | Action | Conversion into | Action | 630 | +-----------+ | NSF Capability | +-----------+ | 631 | | drop |-|------------------->|->|drop/reject| | 632 | +-----------+ | | +-----------+ | 633 +---------------+ +------------------------------+ 635 Figure 6: Example of Data Conversion 637 Figure 6 shows an example for describing a data conversion in Data 638 Converter. High-level policy data MUST be converted into low-level 639 policy data which are compatible with NSFs. If a system 640 administrator attaches a database to Data Converter, it can convert 641 contents by referring to the database with SQL queries. Data 642 conversion in Figure 6 is based on the following list: 644 * 'Policy Name' and 'Rule Name' fields do NOT need the conversion. 646 * 'Source' field SHOULD be converted into a range (start and end) of 647 IPv4 addresses. 649 * 'URL Name' field SHOULD be converted into a URL list of malicious 650 websites. 652 * 'Action' field SHOULD be converted into the corresponding 653 action(s) in NSF capabilities. 655 4.3.4. Data Model Mapper 657 When translating a policy, the mapping between each element of the 658 data models are necessary to properly convert the data. The Data 659 Model Mapper create a mapping model between the elements in Consumer- 660 Facing Interface Data Model and NSF-Facing Interface Data Model. 661 Each element in the Consumer-Facing Interface Policy Data Model has 662 at least one or more corresponding element in NSF-Facing Interface 663 Data Model. 665 Figure 7 shows a mapping list of data fields between Consumer-Facing 666 Interface Data Model and NSF-Facing Interface Data Model. Figure 7 667 describes the process of passing the data value to the appropriate 668 data field of the Data Model in detail after the data conversion. 670 #policy name mapping 671 /consumer-facing/i2nsf-cfi-policy/name 672 -> mapping: /nsf-facing/i2nsf-security-policy 673 /name 675 #rule name mapping 676 /consumer-facing/i2nsf-cfi-policy/rules/name 677 -> mapping: /nsf-facing/i2nsf-security-policy 678 /rules/name 680 #time mapping 681 /consumer-facing/i2nsf-cfi-policy/ 682 /rules/event/time/start-date-time 683 -> mapping: /nsf-facing/i2nsf-security-policy 684 /rules/event/time/start-date-time 686 /consumer-facing/i2nsf-cfi-policy/ 687 /rules/event/time/end-date-time 688 -> mapping: /nsf-facing/i2nsf-security-policy 689 /rules/event/time/end-date-time 691 /consumer-facing/i2nsf-cfi-policy/ 692 /rules/event/time/period/day 693 -> mapping: /nsf-facing/i2nsf-security-policy 694 /rules/event/time/period/day 696 /consumer-facing/i2nsf-cfi-policy/ 697 /rules/event/time/period/date 698 -> mapping: /nsf-facing/i2nsf-security-policy 699 /rules/event/time/period/date 701 /consumer-facing/i2nsf-cfi-policy/ 702 /rules/event/time/period/month 703 -> mapping: /nsf-facing/i2nsf-security-policy 704 /rules/event/time/period/month 706 /consumer-facing/i2nsf-cfi-policy/ 707 /rules/event/time/frequency 708 -> mapping: /nsf-facing/i2nsf-security-policy 709 /rules/event/time/frequency 711 #firewall-condition source target reference and mapping 712 /consumer-facing/i2nsf-cfi-policy/rules/condition 713 /firewall-condition/source 714 -> reference: /consumer-facing/policy 715 /endpoint-group/user-group/name 716 -> reference: /consumer-facing/policy 717 /endpoint-group/device-group/name 718 -> extract: /consumer-facing/policy 719 /endpoint-group/user-group/mac-address 720 -> mapping: /nsf-facing/i2nsf-security-policy 721 /rules/condition/ethernet 722 /source-mac-address 723 -> extract: /consumer-facing/policy 724 /endpoint-group/user-group/ip-address 725 -> mapping: /nsf-facing/i2nsf-security-policy 726 /rules/condition/ipv4 727 /source-ipv4-network 728 -> mapping: /nsf-facing/i2nsf-security-policy 729 /rules/condition/ipv4 730 /source-ipv4-range 731 -> mapping: /nsf-facing/i2nsf-security-policy 732 /rules/condition/ipv6 733 /source-ipv6-network 735 -> mapping: /nsf-facing/i2nsf-security-policy 736 /rules/condition/ipv6 737 /source-ipv6-range 739 #firewall-condition destination target reference and mapping 740 /consumer-facing/i2nsf-cfi-policy/rule/condition 741 /firewall-condition/destination 742 -> reference: /consumer-facing/policy 743 /endpoint-group/user-group/name 744 -> reference: /consumer-facing/policy 745 /endpoint-group/device-group/name 746 -> extract: /consumer-facing/policy 747 /endpoint-group/user-group/mac-address 748 -> mapping: /nsf-facing/i2nsf-security-policy 749 /rules/condition/ethernet 750 /destination-mac-address 751 -> extract: /consumer-facing/policy 752 /endpoint-group/user-group/ip-address 753 -> mapping: /nsf-facing/i2nsf-security-policy 754 /rules/condition/ipv4 755 /destination-ipv4-network 756 -> mapping: /nsf-facing/i2nsf-security-policy 757 /rules/condition/ipv4 758 /destination-ipv4-range 759 -> mapping: /nsf-facing/i2nsf-security-policy 760 /rules/condition/ipv6 761 /destination-ipv6-network 762 -> mapping: /nsf-facing/i2nsf-security-policy 763 /rules/condition/ipv6 764 /destination-ipv6-range 766 #ddos-condition threshold mapping 767 /consumer-facing/i2nsf-cfi-policy/rules/condition 768 /ddos-condition/packet-rate-threshold 769 -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition 770 /ddos/alert-packet-rate 772 /consumer-facing/i2nsf-cfi-policy/rules/condition 773 /ddos-condition/packet-byte-threshold 774 -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition 775 /ddos/alert-byte-rate 777 /consumer-facing/i2nsf-cfi-policy/rules/condition 778 /ddos-condition/flow-rate-threshold 779 -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition 780 /ddos/alert-flow-rate 782 #payload-condition mapping 783 /consumer-facing/i2nsf-cfi-policy/rules/condition 784 /payload-condition/content 785 -> reference: /consumer-facing/i2nsf-cfi-policy 786 /threat-prevention/payload-content/name 787 -> extract: /consumer-facing/i2nsf-cfi-policy 788 /threat-prevention/payload-content/content 789 -> mapping: /nsf-facing/i2nsf-security-policy 790 /rules/condition/payload/content 792 #voice-condition mapping 793 /consumer-facing/i2nsf-cfi-policy/rules/condition 794 /voice-condition/source-id 795 -> mapping: /nsf-facing/i2nsf-security-policy 796 /rules/condition/voice 797 /source-voice-id 799 /consumer-facing/i2nsf-cfi-policy/rules/condition 800 /voice-condition/destination-id 801 -> mapping: /nsf-facing/i2nsf-security-policy 802 /rules/condition/voice 803 /destination-voice-id 805 /consumer-facing/i2nsf-cfi-policy/rules/condition 806 /voice-condition/user-agent 807 -> mapping: /nsf-facing/i2nsf-security-policy 808 /rules/condition/voice 809 /user-agent 811 #geographic-location mapping 812 /consumer-facing/i2nsf-cfi-policy/rules/condition/context 813 /geographic-location/source 814 -> reference: /consumer-facing/i2nsf-cfi-policy 815 /endpoint-groups/location-group/name 816 -> extract: /consumer-facing/i2nsf-cfi-policy 817 /endpoint-groups/location-group 818 /geo-ip-ipv4/ipv4-address 819 -> mapping: /nsf-facing/i2nsf-security-policy 820 /rules/condition/ipv4 821 /source-ipv4-network 822 -> mapping: /nsf-facing/i2nsf-security-policy 823 /rules/condition/ipv4 824 /source-ipv4-range 825 -> extract: /consumer-facing/i2nsf-cfi-policy 826 /endpoint-groups/location-group 827 /continent 828 -> mapping: /nsf-facing/i2nsf-security-policy 829 /rules/condition/context 830 /geographic-location/source 832 /consumer-facing/i2nsf-cfi-policy/rules/condition/context 833 /geographic-location/destination 834 -> reference: /consumer-facing/i2nsf-cfi-policy 835 /endpoint-groups/location-group/name 836 -> extract: /consumer-facing/i2nsf-cfi-policy 837 /endpoint-groups/location-group 838 /geo-ip-ipv4/ipv4-address 839 -> mapping: /nsf-facing/i2nsf-security-policy 840 /rules/condition/ipv4 841 /destination-ipv4-network 842 -> mapping: /nsf-facing/i2nsf-security-policy 843 /rules/condition/ipv4 844 /destination-ipv4-range 845 -> extract: /consumer-facing/i2nsf-cfi-policy 846 /endpoint-groups/location-group 847 /continent 848 -> mapping: /nsf-facing/i2nsf-security-policy 849 /rules/condition/context 850 /geographic-location/destination 852 #url-condition mapping 853 /consumer-facing/i2nsf-cfi-policy/rules/condition 854 /url-condition/url-name 855 -> reference: /consumer-facing/i2nsf-cfi-policy 856 /endpoint-groups/url-group/name 857 -> extract: /consumer-facing/i2nsf-cfi-policy 858 /endpoint-groups/url-group/url 859 -> mapping: /nsf-facing/i2nsf-security-policy 860 /rules/condition/url-category 861 /pre-defined 862 -> mapping: /nsf-facing/i2nsf-security-policy 863 /rules/condition/url-category 864 /user-defined 866 #rule action name mapping 867 /consumer-facing/i2nsf-cfi-policy/rules/actions/primary-action 868 -> mapping: /nsf-facing/i2nsf-security-policy 869 /rules/action 870 /packet-action/ingress-action 871 -> mapping: /nsf-facing/i2nsf-security-policy 872 /rules/action 873 /packet-action/egress-action 874 -> mapping: /nsf-facing/i2nsf-security-policy 875 /rules/action 876 /advanced-action/content-security-control 877 -> mapping: /nsf-facing/i2nsf-security-policy 878 /rules/action 879 /advanced-action/attack-mitigation-control 881 /consumer-facing/i2nsf-cfi-policy/rules/actions/secondary-action 882 -> mapping: /nsf-facing/i2nsf-security-policy 883 /rules/action/packet-action/log-action 885 Figure 7: Mapping Information for Data Conversion 887 The mapping list shown in the Figure 7 shows all mapped components. 888 This data list should be saved into the NSF Database to provide the 889 mapping information for converting the data. It is important to 890 produce the list automatically as the Consumer-Facing Interface and 891 NSF-Facing Interface can be extended anytime by vendors according to 892 the provided NSF. The Data Model Mapper in Security Policy 893 Translator should be used to produce the mapping model information 894 automatically. 896 Consumer-Facing Interface NSF-Facing Interface 897 YANG Data Model YANG Data Model 898 | | 899 V V 900 +---------+-------------------------------+------+ 901 | | Data Model Mapper | | 902 | | | | 903 | | +-------------------------+ | | 904 | +->| Convert as a Tree Graph |<-+ | 905 | +------------+------------+ | 906 | | | 907 | v | 908 | +----------------------------+ | 909 | | Calculate each element | | 910 | | Tree Edit Distance | | 911 | | between the CFI and NFI | | 912 | +--------------+-------------+ | 913 | | | 914 | v | 915 | +-------------------------+ | 916 | | Get the elements with | | 917 | | smallest distance as | | 918 | | the candidates | | 919 | +-------------------------+ | 920 | | | 921 +-------------------------+----------------------+ 922 | 923 V 924 Data Model Mapping Information 926 Note 927 CFI: Consumer-Facing Interface 928 NFI: NSF-Facing Interface 930 Figure 8: Data Model Mapping 932 Figure 8 shows the mapping for I2NSF Security Policy Translator. The 933 mapper uses the Consumer-Facing Interface and NSF-Facing Interface 934 YANG Data Model as inputs. The process the Data Model and converts 935 it into a Tree Graph. Tree Graph is used to proces the Data Model as 936 a Tree instead of individual elements. Then the Data Model Mapper 937 calculates the Tree Edit Distance between each element in Consumer- 938 Facing Interface and each element in NSF-Facing Interface. The Tree 939 Edit Distance can be calculated with an algorithm, e.g., Zhang-Shasha 940 algorithm [Zhang-Shasha], with the calculation should start from the 941 root of the tree. 943 The Zhang-Shasha calculates the distance by three operations: 945 * Insert: Inserting a node or element 947 * Delete: Deleting a node or element 949 * Change: Change the label of a node or element to another 951 The insert and delete operations are a simple of adding/deleting a 952 node or element with the length of the label of the node. The change 953 operation must be calculated between the label of the element to 954 produce the distance. There are methods to calculate this, such as 955 Levenshtein Distance, Cosine Similarity, or Sequence Matching. For 956 this data model mapper, cosine similarity should be the best choice 957 as it measures the similarity between words. The data models have 958 similarity between words and it can helps in calculating as minimum 959 distance as possible. 961 When the minimum distance is obtained, the NSF-Facing Interface 962 element is saved as the candidates for mapping the Consumer-Facing 963 Interface element. This information should be saved to the NSF 964 Database for the Data Converter. 966 Do note that the proper mapping can be achieved because the 967 similarity between the Consumer-Facing Interface and NSF-Facing 968 Interface. An extension created for the Consumer-Facing Interface 969 and NSF-Facing Interface should keep the close similarity 970 relationship between the data models to be able to produce the 971 mapping model information automatically. 973 4.3.5. Policy Provisioning 974 Log-keeper Low-level Web-filter 975 NSF Policy Data NSF 976 +-------------------+ +--------------------+ +-------------------+ 977 | Policy Name | | Policy Name | | Policy Name | 978 | +--------------+ | | +--------------+ | | +--------------+ | 979 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | | 980 | | _security | | | | _security | | | | _security | | 981 | | _policy | | | | _policy | | | | _policy | | 982 | +--------------+ | | +--------------+ | | +--------------+ | 983 | | | | | | 984 | Rule Name | | Rule Name | | Rule Name | 985 | +--------------+ | | +--------------+ | | +--------------+ | 986 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | | 987 | +--------------+ | | +--------------+ | | +--------------+ | 988 | | | | | | 989 | Source IPv4 | | Source IPv4 | | Source IPv4 | 990 | +--------------+ | | +--------------+ | | +--------------+ | 991 | |Start:10.0.0.1|<-|<-|<-|Start:10.0.0.1|->|->|->|Start:10.0.0.1| | 992 | |End :10.0.0.3| | | |End :10.0.0.3| | | |End :10.0.0.3| | 993 | +--------------+ | | +--------------+ | | +--------------+ | 994 | | | | | | 995 | | | URL - User Defined | | URL - User Defined| 996 | | | +--------------+ | | +--------------+ | 997 | | | | [harm.com, |->|->|->| [harm.com, | | 998 | | | | illegal.com] | | | | illegal.com] | | 999 | | | +--------------+ | | +--------------+ | 1000 | | | | | | 1001 | Log Action | | Log Action | | | 1002 | +--------------+ | | +--------------+ | | | 1003 | | True |<-|<-|<-| True | | | | 1004 | +--------------+ | | +--------------+ | | | 1005 +-------------------+ | | | | 1006 | Action | | Action | 1007 | +--------------+ | | +--------------+ | 1008 | | Drop |->|->|->| Drop/Reject | | 1009 | +--------------+ | | +--------------+ | 1010 +--------------------+ +-------------------+ 1012 Figure 9: Example of Policy Provisioning 1014 Generator searches for proper NSFs which can cover all of 1015 capabilities in the high-level policy. Generator searches for target 1016 NSFs by comparing only NSF capabilities which is registered by Vendor 1017 Management System. This process is called by "policy provisioning" 1018 because Generator finds proper NSFs by using only the policy. If 1019 target NSFs are found by using other data which is not included in a 1020 user's policy, it means that the user already knows the specific 1021 knowledge of an NSF in the I2NSF Framework. Figure 9 shows an 1022 example of policy provisioning. In this example, log-keeper NSF and 1023 web-filter NSF are selected for covering capabilities in the security 1024 policy. All of capabilities can be covered by two selected NSFs. 1026 4.4. CFG-based Policy Generator 1028 Generator makes low-level security policies for each target NSF with 1029 the extracted data. We constructed Generator by using Context Free 1030 Grammar (CFG). CFG is a set of production rules which can describe 1031 all possible strings in a given formal language(e.g., programming 1032 language). The low-level policy also has its own language based on a 1033 YANG data model of NSF-Facing Interface. Thus, we can construct the 1034 productions based on the YANG data model. The productions that makes 1035 up the low-level security policy are categorized into two types, 1036 'Content Production' and 'Structure Production'. 1038 4.4.1. Content Production 1040 Content Production is for injecting data into low-level policies to 1041 be generated. A security manager(i.e., a person (or software) to 1042 make productions for security policies) can construct Content 1043 Productions in the form of an expression as the following 1044 productions: 1046 * [cont_prod] -> [cont_prod][cont_prod] (Where duplication is 1047 allowed.) 1049 * [cont_prod] -> [cont_data] 1051 * [cont_data] -> data_1 | data_2 | ... | data_n 1053 Square brackets mean non-terminal state. If there are no non- 1054 terminal states, it means that the string is completely generated. 1055 When the duplication of content tag is allowed, the security manager 1056 adds the first production for a rule. If there is no need to allow 1057 duplication, the first production can be skipped because it is an 1058 optional production. 1060 The second production is the main production for Content Production 1061 because it generates the tag which contains data for low-level 1062 policy. Last, the third production is for injecting data into a tag 1063 which is generated by the second production. If data is changed for 1064 an NSF, the security manager needs to change "only the third 1065 production" for data mapping in each NSF. 1067 For example, if the security manager wants to express a low-level 1068 policy for URL, Content Production can be constructed in the 1069 following productions: 1071 * [cont_url] -> [cont_url][cont_url] (Allow duplication) 1073 * [cont_url] -> [cont_url_data] 1075 * [cont_url_data] -> harm.com | illegal.com 1077 4.4.2. Structure Production 1079 Structure Production is for grouping other tags into a hierarchy. 1080 The security manager can construct Structure Production in the form 1081 of an expression as the following production: 1083 * [struct_prod] -> [prod_1]...[prod_n] 1085 Structure Production can be expressed as a single production. The 1086 above production means to group other tags by the name of a tag which 1087 is called by 'struct_tag'. [prod_x] is a state for generating a tag 1088 which wants to be grouped by Structure Production. [prod_x] can be 1089 both Content Production and Structure Production. For example, if 1090 the security manager wants to express the low-level policy for the 1091 I2NSF tag, which is grouping 'name' and 'rules', Structure Production 1092 can be constructed as the following production where [cont_name] is 1093 the state for Content Production and [struct_rule] is the state for 1094 Structure Production. 1096 * [struct_i2nsf] -> [cont_name][struct_rules] 1099 4.4.3. Generator Construction 1101 The security manager can build a generator by combining the two 1102 productions which are described in Section 4.4.1 and Section 4.4.2. 1103 Figure 10 shows the CFG-based Generator construction of the web- 1104 filter NSF. It is constructed based on the NSF-Facing Interface Data 1105 Model in [I-D.ietf-i2nsf-nsf-facing-interface-dm]. According to 1106 Figure 10, the security manager can express productions for each 1107 clause as in following CFG: 1109 1. [cont_policy_name] -> [cont_policy_name_data] 1111 2. [cont_policy_name_data] -> block_web_security_policy 1113 3. [cont_rule_name] -> [cont_rule_name_data] 1114 4. [cont_rule_name_data] -> block_web 1116 5. [cont_ipv4_start] -> [cont_ipv4_start_data] 1118 6. [cont_ipv4_start_data] -> 10.0.0.1 1120 7. [cont_ipv4_end] -> [cont_ipv4_end_data] 1122 8. [cont_ipv4_end_data] -> 10.0.0.3 1124 9. [cont_url] -> [cont_url][cont_url] (Allow duplication) 1126 10. [cont_url] -> [cont_url_data] 1128 11. [cont_url_data] -> harm.com | illegal.com 1130 12. [cont_action] -> [cont_action_data] 1133 13. [cont_action_data] -> drop 1135 14. [struct_src_ipv4_range] -> [cont_ipv4_start][cont_ipv4_end] 1138 15. [struct_ipv4] -> [struct_src_ipv4_range] 1140 16. [struct_url] -> [cont_url] 1142 17. [struct_cond] -> 1143 [struct_ipv4][struct_url] 1145 18. [struct_action] -> [cont_action] 1147 19. [struct_rules] -> 1148 [cont_rule_name][struct_cond][struct_action] 1150 20. [struct_i2nsf] -> [cont_policy_name][struct_rules] 1153 Then, Generator generates a low-level policy by using the above CFG. 1154 The low-level policy is generated by the following process: 1156 1. Start: [struct_i2nsf] 1158 2. Production 20: [cont_policy_name][struct_rules] 1161 3. Production 1: [cont_policy_name_dat 1162 a][struct_rules] 1164 4. Production 2: block_web_security_po 1165 licy[struct_rules] 1167 5. Production 19: block_web_security_p 1168 olicy[cont_rule_name][struct_cond][struct_action]< 1169 /rules> 1171 6. Production 3: block_web_security_po 1172 licy[cont_rule_name_data][struct_cond 1173 ][struct_action] 1175 7. Production 4: block_web_security_po 1176 licyblock_web[struct_cond][struct_act 1177 ion] 1179 8. Production 17: block_web_security_p 1180 olicyblock_web[struct_ipv4 1181 ][struct_url][struct_action] 1184 9. Production 15: block_web_security_p 1185 olicyblock_web[struc 1186 t_src_ipv4_range][struct_url][struct_action]< 1187 /rules> 1189 10. Production 14: block_web_security_p 1190 olicyblock_web[cont_ipv4_start][cont_ipv4_end][struct_url][struct_action] 1195 11. Production 5: block_web_security_po 1196 licyblock_web[cont_ipv4_start_data][cont_ipv4_end] 1198 [struct_url][struct_actio 1199 n] 1201 12. Production 6: block_web_security_po 1202 licyblock_web10.0.0.1[cont_ipv4_end][struct_url][struct_action] 1207 13. Production 7: block_web_security_po 1208 licyblock_web10.0.0.1[cont_ipv4_end_data][struct_url][struct_act 1211 ion] 1213 14. Production 8: block_web_security_po 1214 licyblock_web10.0.0.110.0.0.3[struct_url][struct_action] 1219 15. Production 16: block_web_security_p 1220 olicyblock_web10.0.0.110.0.0.3[cont_url][struct_action] 1226 16. Production 9: block_web_security_po 1227 licyblock_web10.0.0.110.0.0.3[cont_url][cont_url][struct_action] 1233 17. Production 10: block_web_security_p 1234 olicyblock_web10.0.0.110.0.0.3[cont_url_data][cont_url_data][struct_action] 1242 18. Production 11: block_web_security_p 1243 olicyblock_web10.0.0.110.0.0.3harm.comillegal.com[struct_action] 1250 19. Production 18: block_web_security_p 1251 olicyblock_web10.0.0.110.0.0.3harm.comillegal.com< 1255 /condition>[cont_action] 1258 20. Production 12: block_web_security_p 1259 olicyblock_web10.0.0.110.0.0.3harm.comillegal.com[cont_action_data] 1267 21. Production 13: block_web_security_p 1268 olicyblock_web10.0.0.110.0.0.3harm.comillegal.comdrop 1275 The last production has no non-terminal state, and the low-level 1276 policy is completely generated. Figure 11 shows the generated low- 1277 level policy where tab characters and newline characters are added. 1279 +-------------------------------------------------------------------+ 1280 | Content Production | 1281 | | 1282 | +----------+ +----------+ +----------+ +----------+ +----------+ | 1283 | | Policy | | Rule | | Source | | URL User | | Drop | | 1284 | | Name | | Name | | Address | | Defined | | | | 1285 | +-----+----+ +-----+----+ +-----+----+ +----+-----+ +----+-----+ | 1286 | | | | | | | 1287 +---------------------------------+-----------+---------------------+ 1288 | | | | | 1289 V V V V V 1290 +---------------------+------------+-----------+------------+-------+ 1291 | | | | | | | 1292 | | | V V | | 1293 | | | +----------+ +----------+ | | 1294 | | | | IPv4 | | URL | | | 1295 | | | | Clause | | Clause | | | 1296 | | | +-----+----+ +----+-----+ | | 1297 | | | | | | | 1298 | | | V V | | 1299 | | | +---------------+ +----------+ | 1300 | | | | Condition | | Action | | 1301 | | | | Clause | | Clause | | 1302 | | | +-------+-------+ +-----+----+ | 1303 | | | | | | 1304 | | V V V | 1305 | | +-----------------------------------------+ | 1306 | | | Rule Clause | | 1307 | | +-----------------------------------------+ | 1308 | | | | 1309 | V V | 1310 | +----------------------------------------------------------+ | 1311 | | I2NSF Security Policy Clause | | 1312 | +-----------------------------------+----------------------+ | 1313 | | | 1314 | Structure Production | | 1315 +--------------------------------------+----------------------------+ 1316 | 1317 V 1318 Low-Level Policy 1320 Figure 10: Generator Construction for Web-Filter NSF 1322 1323 block_web_security_policy 1324 1325 block_web 1326 1327 1328 1329 10.0.0.1 1330 10.0.0.3 1331 1332 1333 1334 harm.com 1335 illegal.com 1336 1337 1338 1339 drop 1340 1341 1342 1344 Figure 11: Example of Low-Level Policy 1346 5. Implementation Considerations 1348 The implementation considerations in this document include the 1349 following three: "data model auto-adaptation", "data conversion", and 1350 "policy provisioning". 1352 5.1. Data Model Auto-adaptation 1354 Security Controller which acts as the intermediary MUST process the 1355 data according to the data model of the connected interfaces. 1356 However, the data model can be changed flexibly depending on the 1357 situation, and Security Controller may adapt to the change. 1358 Therefore, Security Controller can be implemented for convenience so 1359 that the security policy translator can easily adapt to the change of 1360 the data model. 1362 The translator constructs and uses the DFA to adapt to Consumer- 1363 Facing Interface Data Model. In addition, the CFG is constructed and 1364 used to adapt to NSF-Facing Interface Data Model. Both the DFA and 1365 the CFG follow the same tree structure of YANG Data Model. 1367 The DFA starts at the node and expands operations by changing the 1368 state according to the input. Based on the YANG Data Model, a 1369 container node is defined as a middle state and a leaf node is 1370 defined as an extractor node. After that, if the nodes are connected 1371 in the same way as the hierarchical structure of the data model, 1372 Security Controller can automatically construct the DFA. The DFA can 1373 be conveniently built by investigating the link structure using the 1374 stack, starting with the root node. 1376 The CFG starts at the leaf nodes and is grouped into clauses until 1377 all the nodes are merged into one node. A leaf node is defined as 1378 the content production, and a container node is defined as the 1379 structure production. After that, if the nodes are connected in the 1380 same way as the hierarchy of the data model, Security Controller can 1381 automatically construct the CFG. The CFG can be conveniently 1382 constructed by investigating the link structure using the priority 1383 queue data, starting with the leaf nodes. 1385 5.2. Data Conversion 1387 Security Controller requires the ability to materialize the abstract 1388 data in the high-level security policy and forward it to NSFs. 1389 Security Controller can receive endpoint information as keywords 1390 through the high-level security policy. At this time, if the 1391 endpoint information corresponding to the keyword is mapped and the 1392 query is transmitted to the NSF Database, the NSF Database can be 1393 conveniently registered with necessary information for data 1394 conversion. When a policy tries to establish a policy through the 1395 keyword, Security Controller searches the details corresponding to 1396 the keyword registered in the NSF Database and converts the keywords 1397 into the appropriate and specified data. 1399 5.3. Policy Provisioning 1401 This document stated that policy provisioning function is necessary 1402 to enable users without expert security knowledge to create policies. 1403 Policy provisioning is determined by the capability of the NSF. If 1404 the NSF has information about the capability in the policy, the 1405 probability of selection increases. 1407 Most importantly, selected NSFs may be able to perform all 1408 capabilities in the security policy. This document recommends a 1409 study of policy provisioning algorithms that are highly efficient and 1410 can satisfy all capabilities in the security policy. 1412 6. Features of Security Policy Translator Design 1414 First, by showing a visualized translator structure, the security 1415 manager can handle various policy changes. Translator can be shown 1416 by visualizing DFA and Context-free Grammar so that the manager can 1417 easily understand the structure of Security Policy Translator. 1419 Second, if I2NSF User only keeps the hierarchy of the data model, 1420 I2NSF User can freely create high-level policies. In the case of 1421 DFA, data extraction can be performed in the same way even if the 1422 order of input is changed. The design of the security policy 1423 translator is more flexible than the existing method that works by 1424 keeping the tag's position and order exactly. 1426 Third, the structure of Security Policy Translator can be updated 1427 even while Security Policy Translator is operating. Because Security 1428 Policy Translator is modularized, the translator can adapt to changes 1429 in the NSF capability while the I2NSF framework is running. The 1430 function of changing the translator's structure can be provided 1431 through Registration Interface. 1433 7. Security Considerations 1435 There is no security concern in the proposed security policy 1436 translator as long as the I2NSF interfaces (i.e., Consumer-Facing 1437 Interface, NSF-Facing Interface, and Registration Interface) are 1438 protected by secure communication channels. 1440 8. IANA Considerations 1442 This document does not require any IANA actions. 1444 9. Acknowledgments 1446 This work was supported by Institute of Information & Communications 1447 Technology Planning & Evaluation (IITP) grant funded by the Ministry 1448 of Science and ICT (MSIT), Korea, (R-20160222-002755, Cloud based 1449 Security Intelligence Technology Development for the Customized 1450 Security Service Provisioning). This work was supported in part by 1451 the IITP (2020-0-00395, Standard Development of Blockchain based 1452 Network Management Automation Technology). This work was supported 1453 in part by the MSIT under the Information Technology Research Center 1454 (ITRC) support program (IITP-2021-2017-0-01633) supervised by the 1455 IITP. 1457 10. References 1459 10.1. Normative References 1461 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1462 the Network Configuration Protocol (NETCONF)", RFC 6020, 1463 DOI 10.17487/RFC6020, October 2010, 1464 . 1466 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1467 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1468 . 1470 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1471 and A. Bierman, Ed., "Network Configuration Protocol 1472 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1473 . 1475 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1476 Kumar, "Framework for Interface to Network Security 1477 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 1478 . 1480 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 1481 Jeong, J. (., Chung, C., Ahn, T., Kumar, R., and S. Hares, 1482 "I2NSF Consumer-Facing Interface YANG Data Model", Work in 1483 Progress, Internet-Draft, draft-ietf-i2nsf-consumer- 1484 facing-interface-dm-16, 28 January 2022, 1485 . 1488 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 1489 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 1490 "I2NSF Network Security Function-Facing Interface YANG 1491 Data Model", Work in Progress, Internet-Draft, draft-ietf- 1492 i2nsf-nsf-facing-interface-dm-20, 31 January 2022, 1493 . 1496 [I-D.ietf-i2nsf-registration-interface-dm] 1497 Hyun, S., Jeong, J. (., Roh, T., Wi, S., and J. Park, 1498 "I2NSF Registration Interface YANG Data Model", Work in 1499 Progress, Internet-Draft, draft-ietf-i2nsf-registration- 1500 interface-dm-14, 28 January 2022, 1501 . 1504 10.2. Informative References 1506 [Automata] Peter, L., "Formal Languages and Automata, 6th Edition", 1507 January 2016. 1509 [Zhang-Shasha] 1510 Zhang, K. and D. Shasha, "Simple Fast Algorithms for the 1511 Editing Distance Between Trees and Related Problems", SIAM 1512 J. Comput. https://www.researchgate.net/publication/220618 1513 233_Simple_Fast_Algorithms_for_the_Editing_Distance_Betwee 1514 n_Trees_and_Related_Problems, 1989. 1516 [XML] W3C, "On Views and XML (Extensible Markup Language)", June 1517 1999. 1519 [XSLT] W3C, "Extensible Stylesheet Language Transformations 1520 (XSLT) Version 1.0", November 1999. 1522 Appendix A. Changes from draft-yang-i2nsf-security-policy- 1523 translation-09 1525 The following changes are made from draft-yang-i2nsf-security-policy- 1526 translation-09: 1528 * This version describes the mapping with the updated data models of 1529 Consumer-Facing Interface (version 16) and NSF-Facing Interface 1530 (version 21). 1532 Authors' Addresses 1534 Jaehoon (Paul) Jeong 1535 Department of Computer Science and Engineering 1536 Sungkyunkwan University 1537 2066 Seobu-Ro, Jangan-Gu 1538 Suwon 1539 Gyeonggi-Do 1540 16419 1541 Republic of Korea 1542 Phone: +82 31 299 4957 1543 Email: pauljeong@skku.edu 1544 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1546 Patrick Lingga 1547 Department of Electronic, Electrical and Computer Engineering 1548 Sungkyunkwan University 1549 2066 Seobu-Ro, Jangan-Gu 1550 Suwon 1551 Gyeonggi-Do 1552 16419 1553 Republic of Korea 1554 Phone: +82 31 299 4957 1555 Email: patricklink@skku.edu 1556 Jinhyuk Yang 1557 Department of Electronic, Electrical and Computer Engineering 1558 Sungkyunkwan University 1559 2066 Seobu-Ro, Jangan-Gu 1560 Suwon 1561 Gyeonggi-Do 1562 16419 1563 Republic of Korea 1564 Phone: +82 10 8520 8039 1565 Email: jin.hyuk@skku.edu 1567 Chaehong Chung 1568 Department of Electronic, Electrical and Computer Engineering 1569 Sungkyunkwan University 1570 2066 Seobu-Ro, Jangan-Gu 1571 Suwon 1572 Gyeonggi-Do 1573 16419 1574 Republic of Korea 1575 Phone: +82 31 299 4957 1576 Email: darkhong@skku.edu