idnits 2.17.1 draft-yang-i2nsf-security-policy-translation-09.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 457: '... security policy MUST be provided abst...' RFC 2119 keyword, line 559: '...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 August 2021) is 978 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-13 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-12 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-10 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: 22 February 2022 C. Chung 6 Sungkyunkwan University 7 21 August 2021 9 Security Policy Translation in Interface to Network Security Functions 10 draft-yang-i2nsf-security-policy-translation-09 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 22 February 2022. 44 Copyright Notice 46 Copyright (c) 2021 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 Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . 10 69 4.3.1. Role of Data Converter . . . . . . . . . . . . . . . 10 70 4.3.2. NSF Database . . . . . . . . . . . . . . . . . . . . 10 71 4.3.3. Data Conversion in Data Converter . . . . . . . . . . 12 72 4.3.4. Data Model Mapper . . . . . . . . . . . . . . . . . . 13 73 4.3.5. Policy Provisioning . . . . . . . . . . . . . . . . . 18 74 4.4. CFG-based Policy Generator . . . . . . . . . . . . . . . 20 75 4.4.1. Content Production . . . . . . . . . . . . . . . . . 20 76 4.4.2. Structure Production . . . . . . . . . . . . . . . . 21 77 4.4.3. Generator Construction . . . . . . . . . . . . . . . 21 78 5. Implementation Considerations . . . . . . . . . . . . . . . . 25 79 5.1. Data Model Auto-adaptation . . . . . . . . . . . . . . . 25 80 5.2. Data Conversion . . . . . . . . . . . . . . . . . . . . . 26 81 5.3. Policy Provisioning . . . . . . . . . . . . . . . . . . . 26 82 6. Features of Security Policy Translator Design . . . . . . . . 26 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 88 10.2. Informative References . . . . . . . . . . . . . . . . . 28 89 Appendix A. Changes from 90 draft-yang-i2nsf-security-policy-translation-08 . . . . . 29 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 311 312 block_web 313 314 Son's_PC 315 malicious_websites 316 317 block 318 320 Figure 3: The Example of High-level Policy 321 +----------+ 322 | accepter | 323 +----------+ 324 | ^ 325 | | 326 v | 327 +------------------------------------------------------+ 328 | middle 1 | 329 +------------------------------------------------------+ 330 | ^ | ^ | ^ 331 | | | | | | 332 v | v | v | 333 +-------------+ +----------------------+ +-------------+ 334 | extractor 1 | | middle 2 | | extractor 4 | 335 +-------------+ +----------------------+ +-------------+ 336 block_web | ^ | ^ block 337 | | | | 338 v | v | 339 +-------------+ +-------------+ 340 | extractor 2 | | extractor 3 | 341 +-------------+ +-------------+ 342 Son's_PC malicious 343 _websites 345 Figure 4: The Example of Data Extractor 347 To explain the Data Extractor process by referring to an example 348 scenario, assume that Security Controller received a high-level 349 policy for a web-filtering as shown in Figure 3. Then we can 350 construct DFA-based Data Extractor by using the design as shown in 351 Figure 2. Figure 4 shows the architecture of Data Extractor that is 352 based on the architecture in Figure 2 along with the input high-level 353 policy in Figure 3. Data Extractor can automatically extract all of 354 data in the high-level policy according to the following process: 356 1. Start from the 'accepter' state. 358 2. Read the first opening tag called '', and transit to the 359 'middle 1' state. 361 3. Read the second opening tag called '', and transit to the 362 'extractor 1' state. 364 4. The current state is an 'extractor' state. Extract the data of 365 'name' field called 'block_web'. 367 5. Read the second closing tag called '', and go back to the 368 'middle 1' state. 370 6. Read the third opening tag called '', and transit to the 371 'middle 2' state. 373 7. Read the fourth opening tag called '', and transit to the 374 'extractor 2' state. 376 8. The current state is an 'extractor' state. Extract the data of 377 'src' field called 'Son's_PC'. 379 9. Read the fourth closing tag called '', and go back to the 380 'middle 2' state. 382 10. Read the fifth opening tag called '', and transit to the 383 'extractor 3' state. 385 11. The current state is an 'extractor' state. Extract the data of 386 'dest' field called 'malicious_websites'. 388 12. Read the fifth closing tag called '', and go back to the 389 'middle 2' state. 391 13. Read the third closing tag called '', and go back to the 392 'middle 1' state. 394 14. Read the sixth opening tag called '', and transit to the 395 'extractor 4' state. 397 15. The current state is an 'extractor' state. Extract the data of 398 'action' field called 'block'. 400 16. Read the sixth closing tag called '', and go back to 401 the 'middle 1' state. 403 17. Read the first closing tag called '', and go back to the 404 'accepter' state. 406 18. There is no further possible transition, and the state is 407 finally on 'accepter' state. There is no grammar error in 408 Figure 3 so the scanning for data extraction is finished. 410 The above process is constructed by an extracting algorithm. After 411 finishing all the steps of the above process, Data Extractor can 412 extract all of data in Figure 3, 'block_web', 'Son's_PC', 413 'malicious', and 'block'. 415 Since the translator is modularized into a DFA structure, a visual 416 understanding is feasible. Also, the performance of Data Extractor 417 is excellent compared to one-to-one searching of data for a 418 particular field. In addition, the management is efficient because 419 the DFA completely follows the hierarchy of Consumer-Facing 420 Interface. If I2NSF User wants to modify the data model of a high- 421 level policy, it only needs to change the connection of the relevant 422 DFA node. 424 4.3. Data Converter 426 4.3.1. Role of Data Converter 428 Every NSF has its own unique capabilities. The capabilities of an 429 NSF are registered into Security Controller by a Developer's 430 Management System, which manages the NSF, via Registration Interface. 431 Therefore, Security Controller already has all information about the 432 capabilities of NSFs. This means that Security Controller can find 433 target NSFs with only the data (e.g., subject and object for a 434 security policy) of the high-level policy by comparing the extracted 435 data with all capabilities of each NSF. This search process for 436 appropriate NSFs is called by policy provisioning, and it eliminates 437 the need for I2NSF User to specify the target NSFs explicitly in a 438 high-level security policy. 440 Data Converter selects target NSFs and converts the extracted data 441 into the capabilities of selected NSFs. If Security Controller uses 442 this data convertor, it can provide the policy provisioning function 443 to I2NSF User automatically. Thus, the translator design provides 444 big benefits to the I2NSF Framework. 446 4.3.2. NSF Database 448 The NSF Database contains all the information needed to convert high- 449 level policy data to low-level policy data. The contents of NSF 450 Database are classified as the following two: "endpoint information" 451 and "NSF capability information". 453 The first is "endpoint information". Endpoint information is 454 necessary to convert an abstract high-level policy data such as 455 Son's_PC, malicious to a specific low-level policy data such as 456 10.0.0.1, illegal.com. In the high-level policy, the range of 457 endpoints for applying security policy MUST be provided abstractly. 458 Thus, endpoint information is needed to specify the abstracted high- 459 level policy data. Endpoint information is provided by I2NSF User as 460 the high-level policy through Consumer-Facing Interface, and Security 461 Controller builds NSF Database based on received information. 463 The second is "NSF capability information". Since capability is 464 information that allows NSF to know what features it can support, NSF 465 capability information is used in policy provisioning process to 466 search the appropriate NSFs through the security policy. NSF 467 capability information is provided by Developer's Management System 468 (DMS) through Registration Interface, and Security Controller builds 469 NSF Database based on received information. In addition, if the NSF 470 sends monitoring information such as initiating information to 471 Security Controller through NSF-Facing Interface, Security Controller 472 can modify NSF Database accordingly. 474 NSF Capability Information Endpoint Information 475 +-------------------+ has convert +------------------+ 476 | NSF +||---+ +-------||+ Endpoint | 477 +-------------------+ | | +------------------+ 478 | *nsf_id (INT) | | | | *end_id (INT) | 479 | nsf_name (STRING)| | | | keyword (STRING) | 480 | inbound (INT) | | | +------------------+ 481 | outbound (INT) | | | 482 | bandwidth (INT) | | | 483 | activated (BOOL) | | | 484 +-------------------+ | | 485 +---------------+ | +---------------------+ 486 /|\ +------||+ Mapping Information | 487 +--------------------+ has | +---------------------+ 488 | Capability +||---+ | | *element_id (INT) | 489 +--------------------+ | | | element_name(STR) | 490 | *capa_id (INT) | | | | element_map (STR) | 491 | capa_name (STRING)| | | +---------------------+ 492 | capa_index (INT) | | | 493 +--------------------+ | | 494 /|\ /|\ 495 +-----------------------+ 496 | Field | 497 +-----------------------+ 498 | *field_id (INT) | 499 | field_name (STRING) | 500 | field_index (INT) | 501 | mapped_data (STRING) | 502 +-----------------------+ 504 Figure 5: Entity-Relationship Diagram of NSF Database 506 Figure 5 shows an Entity-Relationship Diagram (ERD) of NSF Database 507 designed to include both endpoint information received from I2NSF 508 User and NSF capability information received from DMS. By designing 509 the NSF database based on the ERD, all the information necessary for 510 security policy translation can be stored, and the network system 511 administrator can manage the NSF database efficiently. 513 ERD was expressed by using Crow's Foot notation. Crow's Foot 514 notation represents a relationship between entities as a line and 515 represents the cardinality of the relationship as a symbol at both 516 ends of the line. Attributes prefixed with * are key values of each 517 entity. A link with two vertical lines represents one-to-one 518 mapping, and a bird-shaped link represents one-to-many mapping. An 519 NSF entity stores the NSF name (nsf_name), NSF specification 520 (inbound, outbound, bandwidth), and NSF activation (activated). A 521 Capability entity stores the capability name (capa_name) and the 522 index of the capability field in a Registration Interface Data Model 523 (capa_index). An Endpoint entity stores the keyword of abstract data 524 conversion from I2NSF User (keyword). A Field entity stores the 525 field name (field_name), the index of the field index in an NSF- 526 Facing Interface Data Model, and converted data by referring to the 527 Endpoint entity and a 'convert' relationship. 529 4.3.3. Data Conversion in Data Converter 531 High-level Low-level 532 Policy Data Policy Data 533 +---------------+ +------------------------------+ 534 | Rule Name | | Rule Name | 535 | +-----------+ | The Same value | +-------------------------+ | 536 | | block_web |-|------------------->|->| block_web | | 537 | +-----------+ | | +-------------------------+ | 538 | | | | 539 | Source | Conversion into | Source IPv4 | 540 | +-----------+ | User's IP address | +-------------------------+ | 541 | | Son's_PC |-|------------------->|->| [10.0.0.1, 10.0.0.3] | | 542 | +-----------+ | | +-------------------------+ | 543 | | | | 544 | Destination | Conversion into | URL Category | 545 | +-----------+ | malicious websites | +-------------------------+ | 546 | | malicious |-|------------------->|->| [harm.com, | | 547 | | _websites | | | | illegal.com] | | 548 | +-----------+ | | +-------------------------+ | 549 | | | | 550 | Action | Conversion into | Log Action Drop Action | 551 | +-----------+ | NSF Capability | +----------+ +----------+ | 552 | | block |-|------------------->|->| True | | True | | 553 | +-----------+ | | +----------+ +----------+ | 554 +---------------+ +------------------------------+ 556 Figure 6: Example of Data Conversion 558 Figure 6 shows an example for describing a data conversion in Data 559 Converter. High-level policy data MUST be converted into low-level 560 policy data which are compatible with NSFs. If a system 561 administrator attaches a database to Data Converter, it can convert 562 contents by referring to the database with SQL queries. Data 563 conversion in Figure 6 is based on the following list: 565 * 'Rule Name' field does NOT need the conversion. 567 * 'Source' field SHOULD be converted into a list of target IPv4 568 addresses. 570 * 'Destination' field SHOULD be converted into a URL category list 571 of malicious websites. 573 * 'Action' field SHOULD be converted into the corresponding 574 action(s) in NSF capabilities. 576 4.3.4. Data Model Mapper 578 When translating a policy, the mapping between each element of the 579 data models are necessary to properly convert the data. The Data 580 Model Mapper create a mapping model between the elements in Consumer- 581 Facing Interface Data Model and NSF-Facing Interface Data Model. 582 Each element in the Consumer-Facing Interface Policy Data Model has 583 at least one or more corresponding element in NSF-Facing Interface 584 Data Model. 586 Figure 7 shows a mapping list of data fields between Consumer-Facing 587 Interface Data Model and NSF-Facing Interface Data Model. Figure 7 588 describes the process of passing the data value to the appropriate 589 data field of the Data Model in detail after the data conversion. 591 #policy name mapping 592 /consumer-facing/i2nsf-cfi-policy/policy-name 593 -> mapping: /nsf-facing/i2nsf-security-policy 594 /system-policy-name 596 #rule name mapping 597 /consumer-facing/i2nsf-cfi-policy/rules/rule-name 598 -> mapping: /nsf-facing/i2nsf-security-policy 599 /rules/rule-name 601 #start time mapping 602 /consumer-facing/i2nsf-cfi-policy/ 603 /rules/event/time/start-date-time 604 -> mapping: /nsf-facing/i2nsf-security-policy 605 /rules/event/time/start-date-time 607 #end time mapping 608 /consumer-facing/i2nsf-cfi-policy/ 609 /rules/event/time/end-date-time 610 -> mapping: /nsf-facing/i2nsf-security-policy 611 /rules/event/time/end-date-time 613 /consumer-facing/i2nsf-cfi-policy/ 614 /rules/event/time/period/day 615 -> mapping: /nsf-facing/i2nsf-security-policy 616 /rules/event/time/period/day 618 /consumer-facing/i2nsf-cfi-policy/ 619 /rules/event/time/period/date 620 -> mapping: /nsf-facing/i2nsf-security-policy 621 /rules/event/time/period/date 623 /consumer-facing/i2nsf-cfi-policy/ 624 /rules/event/time/period/month 625 -> mapping: /nsf-facing/i2nsf-security-policy 626 /rules/event/time/period/month 628 /consumer-facing/i2nsf-cfi-policy/ 629 /rules/event/time/frequency 630 -> mapping: /nsf-facing/i2nsf-security-policy 631 /rules/event/time/frequency 633 #firewall-condition source target reference and mapping 634 /consumer-facing/i2nsf-cfi-policy/rules/condition 635 /firewall-condition/source 636 -> reference: /consumer-facing/policy 637 /endpoint-group/user-group/name 638 -> reference: /consumer-facing/policy 639 /endpoint-group/device-group/name 640 -> extract: /consumer-facing/policy 641 /endpoint-group/user-group/ip-address 642 -> mapping: /nsf-facing/i2nsf-security-policy 643 /rules/condition/ipv4 644 /source-address 645 -> mapping: /nsf-facing/i2nsf-security-policy 646 /rules/condition/ipv6 647 /source-address 649 #firewall-condition destination target reference and mapping 650 /consumer-facing/i2nsf-cfi-policy/rule/condition 651 /firewall-condition/destination 652 -> reference: /consumer-facing/policy 653 /endpoint-group/user-group/name 654 -> reference: /consumer-facing/policy 655 /endpoint-group/device-group/name 656 -> extract: /consumer-facing/policy 657 /endpoint-group/user-group/ip-address 658 -> mapping: /nsf-facing/i2nsf-security-policy 659 /rules/condition/ipv4 660 /destination-address 661 -> mapping: /nsf-facing/i2nsf-security-policy 662 /rules/condition/ipv6 663 /destination-address 665 #ddos-condition threshold mapping 666 /consumer-facing/i2nsf-cfi-policy/rules/condition 667 /ddos-condition/packet-rate-threshold 668 -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition 669 /ddos/alert-packet-rate 671 /consumer-facing/i2nsf-cfi-policy/rules/condition 672 /ddos-condition/packet-byte-threshold 673 -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition 674 /ddos/alert-byte-rate 676 /consumer-facing/i2nsf-cfi-policy/rules/condition 677 /ddos-condition/flow-rate-threshold 678 -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition 679 /ddos/alert-flow-rate 681 #payload-condition mapping 682 /consumer-facing/i2nsf-cfi-policy/rules/condition 683 /payload/content 684 -> reference: /consumer-facing/policy 685 /threat-prevention/payload-content/name 686 -> extract: /consumer-facing/policy 687 /threat-prevention/payload-content/content 688 -> mapping: /nsf-facing/i2nsf-security-policy 689 /rules/condition/payload 690 /payload-content 692 #voice-condition mapping 693 /consumer-facing/i2nsf-cfi-policy/rules/condition 694 /voice/source-id 695 -> mapping: /nsf-facing/i2nsf-security-policy 696 /rules/condition/voice 697 /source-voice-id 699 /consumer-facing/i2nsf-cfi-policy/rules/condition 700 /voice/destination-id 701 -> mapping: /nsf-facing/i2nsf-security-policy 702 /rules/condition/voice 703 /destination-voice-id 705 /consumer-facing/i2nsf-cfi-policy/rules/condition 706 /voice/user-agent 707 -> mapping: /nsf-facing/i2nsf-security-policy 708 /rules/condition/voice 709 /user-agent 711 #payload-condition mapping 712 /consumer-facing/i2nsf-cfi-policy/rules/condition 713 /url 714 -> reference: /consumer-facing/policy 715 /url-group/name 716 -> extract: /consumer-facing/policy 717 /threat-prevention/payload-content/pre-defined 718 -> mapping: /nsf-facing/i2nsf-security-policy 719 /rules/condition/url 720 /pre-defined-category 721 -> extract: /consumer-facing/policy 722 /threat-prevention/payload-content/user-defined 723 -> mapping: /nsf-facing/i2nsf-security-policy 724 /rules/condition/url 725 /user-defined-category 727 #rule action name mapping 728 /consumer-facing/i2nsf-cfi-policy/rules/action/name 729 -> mapping: /nsf-facing/i2nsf-security-policy 730 /rules/action-clause-container 731 /packet-action/ingress-action 732 -> mapping: /nsf-facing/i2nsf-security-policy 733 /rules/action-clause-container 734 /packet-action/egress-action 735 -> mapping: /nsf-facing/i2nsf-security-policy 736 /rules/action-clause-container 737 /packet-action/log-action 738 -> mapping: /nsf-facing/i2nsf-security-policy 739 /rules/action-clause-container 740 /advanced-action/content-security-control 741 -> mapping: /nsf-facing/i2nsf-security-policy 742 /rules/action-clause-container 743 /advanced-action/attack-mitigation-control 745 Figure 7: Mapping Information for Data Conversion 747 The mapping list shown in the Figure 7 shows all mapped components. 748 This data list should be saved into the NSF Database to provide the 749 mapping information for converting the data. It is important to 750 produce the list automatically as the Consumer-Facing Interface and 751 NSF-Facing Interface can be extended anytime by vendors according to 752 the provided NSF. The Data Model Mapper in Security Policy 753 Translator should be used to produce the mapping model information 754 automatically. 756 Consumer-Facing Interface NSF-Facing Interface 757 YANG Data Model YANG Data Model 758 | | 759 V V 760 +---------+-------------------------------+------+ 761 | | Data Model Mapper | | 762 | | | | 763 | | +-------------------------+ | | 764 | +->| Convert as a Tree Graph |<-+ | 765 | +------------+------------+ | 766 | | | 767 | v | 768 | +----------------------------+ | 769 | | Calculate each element | | 770 | | Tree Edit Distance | | 771 | | between the CFI and NFI | | 772 | +--------------+-------------+ | 773 | | | 774 | v | 775 | +-------------------------+ | 776 | | Get the elements with | | 777 | | smallest distance as | | 778 | | the candidates | | 779 | +-------------------------+ | 780 | | | 781 +-------------------------+----------------------+ 782 | 783 V 784 Data Model Mapping Information 786 Note 787 CFI: Consumer-Facing Interface 788 NFI: NSF-Facing Interface 790 Figure 8: Data Model Mapping 792 Figure 8 shows the mapping for I2NSF Security Policy Translator. The 793 mapper uses the Consumer-Facing Interface and NSF-Facing Interface 794 YANG Data Model as inputs. The process the Data Model and converts 795 it into a Tree Graph. Tree Graph is used to proces the Data Model as 796 a Tree instead of individual elements. Then the Data Model Mapper 797 calculates the Tree Edit Distance between each element in Consumer- 798 Facing Interface and each element in NSF-Facing Interface. The Tree 799 Edit Distance can be calculated with an algorithm, e.g., Zhang-Shasha 800 algorithm [Zhang-Shasha], with the calculation should start from the 801 root of the tree. 803 The Zhang-Shasha calculates the distance by three operations: 805 * Insert: Inserting a node or element 807 * Delete: Deleting a node or element 809 * Change: Change the label of a node or element to another 811 The insert and delete operations are a simple of adding/deleting a 812 node or element with the length of the label of the node. The change 813 operation must be calculated between the label of the element to 814 produce the distance. There are methods to calculate this, such as 815 Levenshtein Distance, Cosine Similarity, or Sequence Matching. For 816 this data model mapper, cosine similarity should be the best choice 817 as it measures the similarity between words. The data models have 818 similarity between words and it can helps in calculating as minimum 819 distance as possible. 821 When the minimum distance is obtained, the NSF-Facing Interface 822 element is saved as the candidates for mapping the Consumer-Facing 823 Interface element. This information should be saved to the NSF 824 Database for the Data Converter. 826 Do note that the proper mapping can be achieved because the 827 similarity between the Consumer-Facing Interface and NSF-Facing 828 Interface. An extension created for the Consumer-Facing Interface 829 and NSF-Facing Interface should keep the close similarity 830 relationship between the data models to be able to produce the 831 mapping model information automatically. 833 4.3.5. Policy Provisioning 834 Log-keeper Low-level Web-filter 835 NSF Policy Data NSF 836 +-------------------+ +--------------------+ +-------------------+ 837 | Rule Name | | Rule Name | | Rule Name | 838 | +--------------+ | | +--------------+ | | +--------------+ | 839 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | | 840 | +--------------+ | | +--------------+ | | +--------------+ | 841 | | | | | | 842 | Source IPv4 | | Source IPv4 | | Source IPv4 | 843 | +--------------+ | | +--------------+ | | +--------------+ | 844 | | [10.0.0.1, |<-|<-|<-| [10.0.0.1, |->|->|->| [10.0.0.1, | | 845 | | 10.0.0.3] | | | | 10.0.0.3] | | | | 10.0.0.3] | | 846 | +--------------+ | | +--------------+ | | +--------------+ | 847 | | | | | | 848 | | | URL Category | | URL Category | 849 | | | +--------------+ | | +--------------+ | 850 | | | | [harm.com, |->|->|->| [harm.com, | | 851 | | | | illegal.com] | | | | illegal.com] | | 852 | | | +--------------+ | | +--------------+ | 853 | | | | | | 854 | Log Action | | Log Action | | | 855 | +--------------+ | | +--------------+ | | | 856 | | True |<-|<-|<-| True | | | | 857 | +--------------+ | | +--------------+ | | | 858 +-------------------+ | | | | 859 | Drop Action | | Drop Action | 860 | +--------------+ | | +--------------+ | 861 | | True |->|->|->| True | | 862 | +--------------+ | | +--------------+ | 863 +--------------------+ +-------------------+ 865 Figure 9: Example of Policy Provisioning 867 Generator searches for proper NSFs which can cover all of 868 capabilities in the high-level policy. Generator searches for target 869 NSFs by comparing only NSF capabilities which is registered by Vendor 870 Management System. This process is called by "policy provisioning" 871 because Generator finds proper NSFs by using only the policy. If 872 target NSFs are found by using other data which is not included in a 873 user's policy, it means that the user already knows the specific 874 knowledge of an NSF in the I2NSF Framework. Figure 9 shows an 875 example of policy provisioning. In this example, log-keeper NSF and 876 web-filter NSF are selected for covering capabilities in the security 877 policy. All of capabilities can be covered by two selected NSFs. 879 4.4. CFG-based Policy Generator 881 Generator makes low-level security policies for each target NSF with 882 the extracted data. We constructed Generator by using Context Free 883 Grammar (CFG). CFG is a set of production rules which can describe 884 all possible strings in a given formal language(e.g., programming 885 language). The low-level policy also has its own language based on a 886 YANG data model of NSF-Facing Interface. Thus, we can construct the 887 productions based on the YANG data model. The productions that makes 888 up the low-level security policy are categorized into two types, 889 'Content Production' and 'Structure Production'. 891 4.4.1. Content Production 893 Content Production is for injecting data into low-level policies to 894 be generated. A security manager(i.e., a person (or software) to 895 make productions for security policies) can construct Content 896 Productions in the form of an expression as the following 897 productions: 899 * [cont_prod] -> [cont_prod][cont_prod] (Where duplication is 900 allowed.) 902 * [cont_prod] -> [cont_data] 904 * [cont_data] -> data_1 | data_2 | ... | data_n 906 Square brackets mean non-terminal state. If there are no non- 907 terminal states, it means that the string is completely generated. 908 When the duplication of content tag is allowed, the security manager 909 adds the first production for a rule. If there is no need to allow 910 duplication, the first production can be skipped because it is an 911 optional production. 913 The second production is the main production for Content Production 914 because it generates the tag which contains data for low-level 915 policy. Last, the third production is for injecting data into a tag 916 which is generated by the second production. If data is changed for 917 an NSF, the security manager needs to change "only the third 918 production" for data mapping in each NSF. 920 For example, if the security manager wants to express a low-level 921 policy for source IP address, Content Production can be constructed 922 in the following productions: 924 * [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.) 925 * [cont_ipv4] -> [cont_ipv4_data] 927 * [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 929 4.4.2. Structure Production 931 Structure Production is for grouping other tags into a hierarchy. 932 The security manager can construct Structure Production in the form 933 of an expression as the following production: 935 * [struct_prod] -> [prod_1]...[prod_n] 937 Structure Production can be expressed as a single production. The 938 above production means to group other tags by the name of a tag which 939 is called by 'struct_tag'. [prod_x] is a state for generating a tag 940 which wants to be grouped by Structure Production. [prod_x] can be 941 both Content Production and Structure Production. For example, if 942 the security manager wants to express the low-level policy for the 943 I2NSF tag, which is grouping 'name' and 'rules', Structure Production 944 can be constructed as the following production where [cont_name] is 945 the state for Content Production and [struct_rule] is the state for 946 Structure Production. 948 * [struct_i2nsf] -> [cont_name][struct_rules] 950 4.4.3. Generator Construction 952 The security manager can build a generator by combining the two 953 productions which are described in Section 4.4.1 and Section 4.4.2. 954 Figure 10 shows the CFG-based Generator construction of the web- 955 filter NSF. It is constructed based on the NSF-Facing Interface Data 956 Model in [I-D.ietf-i2nsf-nsf-facing-interface-dm]. According to 957 Figure 10, the security manager can express productions for each 958 clause as in following CFG: 960 1. [cont_name] -> [cont_name_data] 962 2. [cont_name_data] -> block_web 964 3. [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication) 966 4. [cont_ipv4] -> [cont_ipv4_data] 968 5. [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3 970 6. [cont_url] -> [cont_url][cont_url] (Allow duplication) 972 7. [cont_url] -> [cont_url_data] 973 8. [cont_url_data] -> harm.com | illegal.com 975 9. [cont_action] -> [cont_action_data] 977 10. [cont_action_data] -> drop 979 11. [struct_packet] -> [cont_ipv4] 981 12. [struct_payload] -> [cont_url] 983 13. [struct_cond] -> 984 [struct_packet][struct_payload] 986 14. [struct_rules] -> [struct_cond][cont_action] 988 15. [struct_i2nsf] -> [cont_name][struct_rules] 990 Then, Generator generates a low-level policy by using the above CFG. 991 The low-level policy is generated by the following process: 993 1. Start: [struct_i2nsf] 995 2. Production 15: [cont_name][struct_rules] 997 3. Production 1: [cont_name_data][struct_rules] 1000 4. Production 2: block_web[struct_rules] 1003 5. Production 14: block_web[struct_cond][cont_action] 1006 6. Production 13: block_web[struct_packet][struct_payload][cont_action] 1008 1010 7. Production 11: block_web[cont_ipv4][struct_payload] 1012 [cont_action] 1014 8. Production 3: block_web[cont_ipv4][cont_ipv4][struct_payload][cont_action] 1018 9. Production 4: block_web[cont_ipv4_data][cont_ipv4_dat 1020 a][struct_payload][cont_action] 1023 10. Production 5: block_web10.0.0.110.0.0.3[struct_payload][cont_action] 1027 11. Production 12: block_web10.0.0.110.0.0.3[cont_url][cont_action] 1032 12. Production 6: block_web10.0.0.110.0.0.3[cont_url][cont_url][cont_actio 1035 n] 1037 13. Production 7: block_web10.0.0.110.0.0.3[cont_url_data][cont_url_data]< 1040 /payload>[cont_action] 1042 14. Production 8: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action] 1047 15. Production 9: block_web10.0.0.110.0.0.3harm.comillegal.com[cont_action_data] 1052 16. Production 10: block_web10.0.0.110.0.0.3harm.comillegal.com< 1055 /condition>drop 1057 The last production has no non-terminal state, and the low-level 1058 policy is completely generated. Figure 11 shows the generated low- 1059 level policy where tab characters and newline characters are added. 1061 +-----------------------------------------------------+ 1062 | +----------+ +----------+ +----------+ +----------+ | 1063 Content | | Rule | | Source | | URL | | Drop | | 1064 Production | | Name | | IPv4 | | Category | | Action | | 1065 | +-----+----+ +-----+----+ +----+-----+ +----+-----+ | 1066 | | | | | | 1067 +--------------------+-----------+--------------------+ 1068 | | | | 1069 V V V V 1070 +-------+------------+-----------+------------+-------+ 1071 | | | | | | 1072 | | V V | | 1073 | | +----------+ +----------+ | | 1074 | | | Packet | | Payload | | | 1075 | | | Clause | | Clause | | | 1076 | | +-----+----+ +----+-----+ | | 1077 | | | | | | 1078 | | V V | | 1079 | | +---------------+ | | 1080 | | | Condition | | | 1081 Structure | | | Clause | | | 1082 Production | | +-------+-------+ | | 1083 | | | | | 1084 | | V V | 1085 | | +----------------------+ | 1086 | | | Rule Clause | | 1087 | | +-----------+----------+ | 1088 | | | | 1089 | V V | 1090 | +-----------------------------------------+ | 1091 | | I2NSF Clause | | 1092 | +--------------------+--------------------+ | 1093 | | | 1094 +--------------------------+--------------------------+ 1095 | 1096 V 1097 Low-Level Policy 1099 Figure 10: Generator Construction for Web-Filter NSF 1100 1101 block_web 1102 1103 1104 1105 10.0.0.1 1106 10.0.0.3 1107 1108 1109 harm.com 1110 illegal.com 1111 1112 1113 drop 1114 1115 1117 Figure 11: Example of Low-Level Policy 1119 5. Implementation Considerations 1121 The implementation considerations in this document include the 1122 following three: "data model auto-adaptation", "data conversion", and 1123 "policy provisioning". 1125 5.1. Data Model Auto-adaptation 1127 Security Controller which acts as the intermediary MUST process the 1128 data according to the data model of the connected interfaces. 1129 However, the data model can be changed flexibly depending on the 1130 situation, and Security Controller may adapt to the change. 1131 Therefore, Security Controller can be implemented for convenience so 1132 that the security policy translator can easily adapt to the change of 1133 the data model. 1135 The translator constructs and uses the DFA to adapt to Consumer- 1136 Facing Interface Data Model. In addition, the CFG is constructed and 1137 used to adapt to NSF-Facing Interface Data Model. Both the DFA and 1138 the CFG follow the same tree structure of YANG Data Model. 1140 The DFA starts at the node and expands operations by changing the 1141 state according to the input. Based on the YANG Data Model, a 1142 container node is defined as a middle state and a leaf node is 1143 defined as an extractor node. After that, if the nodes are connected 1144 in the same way as the hierarchical structure of the data model, 1145 Security Controller can automatically construct the DFA. The DFA can 1146 be conveniently built by investigating the link structure using the 1147 stack, starting with the root node. 1149 The CFG starts at the leaf nodes and is grouped into clauses until 1150 all the nodes are merged into one node. A leaf node is defined as 1151 the content production, and a container node is defined as the 1152 structure production. After that, if the nodes are connected in the 1153 same way as the hierarchy of the data model, Security Controller can 1154 automatically construct the CFG. The CFG can be conveniently 1155 constructed by investigating the link structure using the priority 1156 queue data, starting with the leaf nodes. 1158 5.2. Data Conversion 1160 Security Controller requires the ability to materialize the abstract 1161 data in the high-level security policy and forward it to NSFs. 1162 Security Controller can receive endpoint information as keywords 1163 through the high-level security policy. At this time, if the 1164 endpoint information corresponding to the keyword is mapped and the 1165 query is transmitted to the NSF Database, the NSF Database can be 1166 conveniently registered with necessary information for data 1167 conversion. When a policy tries to establish a policy through the 1168 keyword, Security Controller searches the details corresponding to 1169 the keyword registered in the NSF Database and converts the keywords 1170 into the appropriate and specified data. 1172 5.3. Policy Provisioning 1174 This document stated that policy provisioning function is necessary 1175 to enable users without expert security knowledge to create policies. 1176 Policy provisioning is determined by the capability of the NSF. If 1177 the NSF has information about the capability in the policy, the 1178 probability of selection increases. 1180 Most importantly, selected NSFs may be able to perform all 1181 capabilities in the security policy. This document recommends a 1182 study of policy provisioning algorithms that are highly efficient and 1183 can satisfy all capabilities in the security policy. 1185 6. Features of Security Policy Translator Design 1187 First, by showing a visualized translator structure, the security 1188 manager can handle various policy changes. Translator can be shown 1189 by visualizing DFA and Context-free Grammar so that the manager can 1190 easily understand the structure of Security Policy Translator. 1192 Second, if I2NSF User only keeps the hierarchy of the data model, 1193 I2NSF User can freely create high-level policies. In the case of 1194 DFA, data extraction can be performed in the same way even if the 1195 order of input is changed. The design of the security policy 1196 translator is more flexible than the existing method that works by 1197 keeping the tag 's position and order exactly. 1199 Third, the structure of Security Policy Translator can be updated 1200 even while Security Policy Translator is operating. Because Security 1201 Policy Translator is modularized, the translator can adapt to changes 1202 in the NSF capability while the I2NSF framework is running. The 1203 function of changing the translator's structure can be provided 1204 through Registration Interface. 1206 7. Security Considerations 1208 There is no security concern in the proposed security policy 1209 translator as long as the I2NSF interfaces (i.e., Consumer-Facing 1210 Interface, NSF-Facing Interface, and Registration Interface) are 1211 protected by secure communication channels. 1213 8. IANA Considerations 1215 This document does not require any IANA actions. 1217 9. Acknowledgments 1219 This work was supported by Institute of Information & Communications 1220 Technology Planning & Evaluation (IITP) grant funded by the Ministry 1221 of Science and ICT (MSIT), Korea, (R-20160222-002755, Cloud based 1222 Security Intelligence Technology Development for the Customized 1223 Security Service Provisioning). This work was supported in part by 1224 the IITP (2020-0-00395, Standard Development of Blockchain based 1225 Network Management Automation Technology). This work was supported 1226 in part by the MSIT under the Information Technology Research Center 1227 (ITRC) support program (IITP-2021-2017-0-01633) supervised by the 1228 IITP. 1230 10. References 1232 10.1. Normative References 1234 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1235 the Network Configuration Protocol (NETCONF)", RFC 6020, 1236 DOI 10.17487/RFC6020, October 2010, 1237 . 1239 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1240 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1241 . 1243 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1244 and A. Bierman, Ed., "Network Configuration Protocol 1245 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1246 . 1248 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1249 Kumar, "Framework for Interface to Network Security 1250 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 1251 . 1253 10.2. Informative References 1255 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 1256 Jeong, J. (., Chung, C., Ahn, T., Kumar, R., and S. Hares, 1257 "I2NSF Consumer-Facing Interface YANG Data Model", Work in 1258 Progress, Internet-Draft, draft-ietf-i2nsf-consumer- 1259 facing-interface-dm-13, 8 March 2021, 1260 . 1263 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 1264 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 1265 "I2NSF Network Security Function-Facing Interface YANG 1266 Data Model", Work in Progress, Internet-Draft, draft-ietf- 1267 i2nsf-nsf-facing-interface-dm-12, 8 March 2021, 1268 . 1271 [I-D.ietf-i2nsf-registration-interface-dm] 1272 Hyun, S., Jeong, J. P., Roh, T., Wi, S., and J. Park, 1273 "I2NSF Registration Interface YANG Data Model", Work in 1274 Progress, Internet-Draft, draft-ietf-i2nsf-registration- 1275 interface-dm-10, 21 February 2021, 1276 . 1279 [Automata] Peter, L., "Formal Languages and Automata, 6th Edition", 1280 January 2016. 1282 [Zhang-Shasha] 1283 Zhang, K. and D. Shasha, "Simple Fast Algorithms for the 1284 Editing Distance Between Trees and Related Problems", SIAM 1285 J. Comput. https://www.researchgate.net/publication/220618 1286 233_Simple_Fast_Algorithms_for_the_Editing_Distance_Betwee 1287 n_Trees_and_Related_Problems, 1989. 1289 [XML] W3C, "On Views and XML (Extensible Markup Language)", June 1290 1999. 1292 [XSLT] W3C, "Extensible Stylesheet Language Transformations 1293 (XSLT) Version 1.0", November 1999. 1295 Appendix A. Changes from draft-yang-i2nsf-security-policy- 1296 translation-08 1298 The following changes are made from draft-yang-i2nsf-security-policy- 1299 translation-08: 1301 * The version adds a Data Model Mapper section as Section 5. In 1302 this section, the implementation considerations include the 1303 following three: "data model auto-adaptation", "data conversion", 1304 and "policy provisioning". 1306 * This version describes the mapping with the updated data models of 1307 Consumer-Facing Interface and NSF-Facing Interface. 1309 Authors' Addresses 1311 Jaehoon (Paul) Jeong 1312 Department of Computer Science and Engineering 1313 Sungkyunkwan University 1314 2066 Seobu-Ro, Jangan-Gu 1315 Suwon 1316 Gyeonggi-Do 1317 16419 1318 Republic of Korea 1320 Phone: +82 31 299 4957 1321 Email: pauljeong@skku.edu 1322 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1324 Patrick Lingga 1325 Department of Electronic, Electrical and Computer Engineering 1326 Sungkyunkwan University 1327 2066 Seobu-Ro, Jangan-Gu 1328 Suwon 1329 Gyeonggi-Do 1330 16419 1331 Republic of Korea 1333 Phone: +82 31 299 4957 1334 Email: patricklink@skku.edu 1336 Jinhyuk Yang 1337 Department of Electronic, Electrical and Computer Engineering 1338 Sungkyunkwan University 1339 2066 Seobu-Ro, Jangan-Gu 1340 Suwon 1341 Gyeonggi-Do 1342 16419 1343 Republic of Korea 1345 Phone: +82 10 8520 8039 1346 Email: jin.hyuk@skku.edu 1348 Chaehong Chung 1349 Department of Electronic, Electrical and Computer Engineering 1350 Sungkyunkwan University 1351 2066 Seobu-Ro, Jangan-Gu 1352 Suwon 1353 Gyeonggi-Do 1354 16419 1355 Republic of Korea 1357 Phone: +82 31 299 4957 1358 Email: darkhong@skku.edu