idnits 2.17.1 draft-yang-i2nsf-security-policy-translation-11.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 4 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 159: '... an NSF, the NSF MUST receive at least...' RFC 2119 keyword, line 164: '...ntence, the user MUST know that the NS...' RFC 2119 keyword, line 172: '... policy is REQUIRED in I2NSF....' RFC 2119 keyword, line 1053: '... security policy MUST be provided abst...' RFC 2119 keyword, line 1163: '...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 == Line 404 has weird spacing: '...w start ine...' == Line 411 has weird spacing: '...w start ine...' == Line 427 has weird spacing: '...w start ine...' == Line 434 has weird spacing: '...w start ine...' == Line 446 has weird spacing: '...er-port inet:...' == (23 more instances...) -- The document date (28 April 2022) is 729 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-18 == Outdated reference: A later version (-29) exists of draft-ietf-i2nsf-nsf-facing-interface-dm-26 == Outdated reference: A later version (-26) exists of draft-ietf-i2nsf-registration-interface-dm-16 == Outdated reference: A later version (-32) exists of draft-ietf-i2nsf-capability-data-model-30 Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group J. Jeong, Ed. 3 Internet-Draft P. Lingga 4 Intended status: Standards Track J. Yang 5 Expires: 30 October 2022 J. Kim 6 Sungkyunkwan University 7 28 April 2022 9 Guidelines for Security Policy Translation in Interface to Network 10 Security Functions 11 draft-yang-i2nsf-security-policy-translation-11 13 Abstract 15 This document proposes the guidelines for security policy translation 16 in Interface to Network Security Functions (I2NSF) Framework. When 17 I2NSF User delivers a high-level security policy for a security 18 service, Security Policy Translator in Security Controller translates 19 it into a low-level security policy for Network Security Functions 20 (NSFs). For this security policy translation, this document 21 specifies the relation between a high-level security policy based on 22 the Consumer-Facing Interface YANG data model and a low-level 23 security policy based on the NSF-Facing Interface YANG data model. 24 Also, it describes an architecture of a security policy translator 25 along with an NSF database, and the process of security policy 26 translation with the NSF database. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 30 October 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Necessity for Security Policy Translator . . . . . . . . . . 3 64 4. Relation between Consumer-Facing Interface and NSF-Facing 65 Interface YANG Data Models . . . . . . . . . . . . . . . 4 66 4.1. The CFI and NFI Top-Level YANG Trees Comparison . . . . . 5 67 4.2. The CFI and NFI Rule-Level YANG Trees Comparison . . . . 6 68 4.2.1. The CFI and NFI Event YANG Data Models Comparison . . 7 69 4.2.2. The CFI and NFI Condition YANG Data Models 70 Comparison . . . . . . . . . . . . . . . . . . . . . 7 71 4.2.3. The CFI and NFI Action YANG Data Models Comparison . 14 72 5. Design of Security Policy Translator . . . . . . . . . . . . 16 73 5.1. Overall Structure of Security Policy Translator . . . . . 16 74 5.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . 18 75 5.2.1. Design of DFA-based Data Extractor . . . . . . . . . 18 76 5.2.2. Example Scenario for Data Extractor . . . . . . . . . 19 77 5.3. Data Converter . . . . . . . . . . . . . . . . . . . . . 24 78 5.3.1. Role of Data Converter . . . . . . . . . . . . . . . 24 79 5.3.2. NSF Database . . . . . . . . . . . . . . . . . . . . 25 80 5.3.3. Data Conversion in Data Converter . . . . . . . . . . 27 81 5.3.4. Data Model Mapper . . . . . . . . . . . . . . . . . . 28 82 5.3.5. Policy Provisioning . . . . . . . . . . . . . . . . . 31 83 5.4. Policy Generator . . . . . . . . . . . . . . . . . . . . 33 84 6. Implementation Considerations . . . . . . . . . . . . . . . . 34 85 6.1. Data Model Auto-adaptation . . . . . . . . . . . . . . . 35 86 6.2. Data Conversion . . . . . . . . . . . . . . . . . . . . . 35 87 6.3. Policy Provisioning . . . . . . . . . . . . . . . . . . . 36 88 7. Features of Security Policy Translator Design . . . . . . . . 36 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 37 93 10.2. Informative References . . . . . . . . . . . . . . . . . 38 94 Appendix A. Mapping Information for Data Conversion . . . . . . 38 95 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 43 96 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 43 97 Appendix D. Changes from 98 draft-yang-i2nsf-security-policy-translation-10 . . . . . 44 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 101 1. Introduction 103 This document proposes the guidelines for security policy translation 104 in Interface to Network Security Functions (I2NSF) Framework 105 [RFC8329]. First of all, this document explains the necessity of a 106 security policy translator (shortly called policy translator) in the 107 I2NSF framework. 109 The policy translator resides in Security Controller in the I2NSF 110 framework and translates a high-level security policy to a low-level 111 security policy for Network Security Functions (NSFs). A high-level 112 policy is specified by I2NSF User in the I2NSF framework and is 113 delivered to Security Controller via Consumer-Facing Interface 114 [I-D.ietf-i2nsf-consumer-facing-interface-dm]. It is translated into 115 a low-level policy by Policy Translator in Security Controller and is 116 delivered to NSFs to execute the rules corresponding to the low-level 117 policy via NSF-Facing Interface 118 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 120 2. Terminology 122 This document uses the terminology specified in [RFC8329]. 124 3. Necessity for Security Policy Translator 126 Security Controller acts as a coordinator between I2NSF User and 127 NSFs. Also, Security Controller has capability information of NSFs 128 that are registered via Registration Interface 129 [I-D.ietf-i2nsf-registration-interface-dm] by Developer's Management 130 System [RFC8329]. As a coordinator, Security Controller needs to 131 generate a low-level policy in the form of security rules intended by 132 the high-level policy, which can be understood by the corresponding 133 NSFs. 135 A high-level security policy is specified by RESTCONF/YANG 136 [RFC8040][RFC6020], and a low-level security policy is specified by 137 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level 138 security policy to the corresponding low-level security policy will 139 be able to rapidly elevate I2NSF in real-world deployment. A rule in 140 a high-level policy can include a broad target object, such as 141 employees in a company for a security service (e.g., firewall and web 142 filter). Such employees may be from human resource (HR) department, 143 software engineering department, and advertisement department. A 144 keyword of employee needs to be mapped to these employees from 145 various departments. This mapping needs to be handled by a security 146 policy translator in a flexible way while understanding the intention 147 of a policy specification. Let us consider the following two 148 policies: 150 * Block my son's computers from malicious websites. 152 * Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com 153 and illegal.com 155 The above two sentences are examples of policies for blocking 156 malicious websites. Both policies are for the same operation. 157 However, NSF cannot understand the first policy, because the policy 158 does not have any specified information for NSF. To set up the 159 policy at an NSF, the NSF MUST receive at least the source IP address 160 and website address for an operation. It means that the first 161 sentence is NOT compatible for an NSF policy. Conversely, when I2NSF 162 Users request a security policy to the system, they never make a 163 security policy like the second example. For generating a security 164 policy like the second sentence, the user MUST know that the NSF 165 needs to receive the specified information, source IP address and 166 website address. It means that the user understands the NSF 167 professionally, but there are not many professional users in a small 168 size of company or at a residential area. In conclusion, the I2NSF 169 User prefers to issue a security policy in the first sentence, but an 170 NSF will require the same policy as the second sentence with specific 171 information. Therefore, an advanced translation scheme of security 172 policy is REQUIRED in I2NSF. 174 This document proposes an approach using Automata theory [Automata] 175 for the policy translation, such as Deterministic Finite Automaton 176 (DFA). Note that Automata theory is the foundation of programming 177 language and compiler. Thus, with this approach, I2NSF User can 178 easily specify a high-level security policy that will be enforced 179 into the corresponding NSFs with a compatibly low-level security 180 policy with the help of Security Policy Translator. Also, for easy 181 management, a modularized translator structure is proposed. 183 4. Relation between Consumer-Facing Interface and NSF-Facing Interface 184 YANG Data Models 186 The Consumer-Facing Interface (CFI) YANG data model 187 [I-D.ietf-i2nsf-consumer-facing-interface-dm] and NSF-Facing 188 Interface (NFI) YANG data model 189 [I-D.ietf-i2nsf-nsf-facing-interface-dm] are two data models designed 190 with different objectives in mind. The CFI is designed to be used by 191 someone with little knowledge of network security can configure the 192 NSFs by specifying the required information, their data types, and 193 encoding schemes as a high-level policy. The NFI is designed to 194 provide detailed security policy configuration for the NSFs as a low- 195 level policy that can be used by the NSFs to deploy security 196 services. But even with the distinct objectives for the data models, 197 the attributes between the two data models are constructed to have a 198 relation for the purpose of automation. Thus, this section provides 199 the information of the relationship between the attributes in the CFI 200 and NFI YANG data model. 202 4.1. The CFI and NFI Top-Level YANG Trees Comparison 204 Consumer-Facing Interface (CFI): 205 module: ietf-i2nsf-cfi-policy 206 +--rw i2nsf-cfi-policy* [name] 207 +--rw name string 208 +--rw language? string 209 +--rw resolution-strategy? identityref 210 +--rw rules* [name] 211 | ... 212 +--rw endpoint-groups 213 | ... 214 +--rw threat-prevention 215 ... 217 NSF-Facing Interface (NFI): 218 module: ietf-i2nsf-policy-rule-for-nsf 219 +--rw i2nsf-security-policy* [name] 220 +--rw name string 221 +--rw language? string 222 +--rw priority-usage? identityref 223 +--rw resolution-strategy? identityref 224 +--rw default-action? identityref 225 +--rw rules* [name] 226 | ... 227 +--rw rule-group 228 ... 230 Figure 1: The CFI and NFI Top-Level YANG Trees 232 Figure 1 shows the top-level of the CFI and NFI YANG Trees. The CFI 233 and NFI top-level provides the basic security policy information such 234 as name of a policy, language tag, and resolution-strategy. Both 235 data models also provide list of rules to be executed to perform the 236 network security services. 238 The differences of the top-level data models are default action and 239 priority usage are not provided in CFI YANG data model. This is 240 because the philosophy of CFI, i.e., To make CFI as simple as 241 possible for the user. But this attributes can be given by the 242 Security Controller with a default value in the translation process. 243 Another important distinct point is CFI YANG data model also provides 244 endpoint groups and threat prevention to register high-level 245 information (e.g., mapping a user to an IP address) to the database 246 for high-level configuration that can be used to translate the high- 247 level policy into the low-level policy. 249 4.2. The CFI and NFI Rule-Level YANG Trees Comparison 251 Consumer-Facing Interface (CFI): 252 +--rw rules* [name] 253 | +--rw name string 254 | +--rw priority? uint8 255 | +--rw event 256 | | ... 257 | +--rw condition 258 | | ... 259 | +--rw actions 260 | ... 262 NSF-Facing Interface (NFI): 263 +--rw rules* [name] 264 | +--rw name string 265 | +--rw description? string 266 | +--rw priority? uint8 267 | +--rw enable? boolean 268 | +--rw long-connection 269 | | +--rw enable? boolean 270 | | +--rw duration? uint32 271 | +--rw event 272 | | ... 273 | +--rw condition 274 | | ... 275 | +--rw action 276 | ... 278 Figure 2: The CFI and NFI Rule-Level YANG Trees 280 Figure 2 shows the rule-level YANG trees of the CFI and NFI YANG 281 Trees. Similarly to the top-level YANG data model, the long- 282 connection is not provided in the CFI YANG data model to simplify the 283 data model for the user configuration. This value can also be added 284 using a default value in the Security Controller for the low-level 285 security policy. 287 In term of similarity, the CFI and NFI YANG data model provides the 288 basic rule information such as the unique name the priority value for 289 the rules. Both data models utilize the Event-Condition-Action (ECA) 290 policy rule described in Section 3.1 of the 291 [I-D.ietf-i2nsf-capability-data-model]. 293 4.2.1. The CFI and NFI Event YANG Data Models Comparison 295 Consumer-Facing Interface (CFI): 296 | +--rw event 297 | | +--rw system-event* identityref 298 | | +--rw system-alarm* identityref 300 NSF-Facing Interface (NFI): 301 | +--rw event 302 | | +--rw description? string 303 | | +--rw system-event* identityref 304 | | +--rw system-alarm* identityref 306 Figure 3: The CFI and NFI Event YANG Trees 308 As shown in Figure 3, CFI and NFI YANG data models have the almost 309 same structures for Event except for description in NFI. The 310 description is optional because it contains human-readable text for 311 the description of an event. 313 4.2.2. The CFI and NFI Condition YANG Data Models Comparison 315 Consumer-Facing Interface (CFI): 316 | +--rw condition 317 | | +--rw firewall 318 | | | +--rw source* union 319 | | | +--rw destination* union 320 | | | +--rw transport-layer-protocol? identityref 321 | | | +--rw range-port-number 322 | | | | +--rw start-port-number? inet:port-number 323 | | | | +--rw end-port-number? inet:port-number 324 | | | +--rw icmp 325 | | | +--rw message* identityref 326 | | +--rw ddos 327 | | | +--rw rate-limit 328 | | | +--rw packet-rate-threshold? uint64 329 | | | +--rw byte-rate-threshold? uint64 330 | | | +--rw flow-rate-threshold? uint64 331 | | +--rw anti-virus 332 | | | +--rw exception-files* string 333 | | +--rw payload 334 | | | +--rw content* 335 -> /i2nsf-cfi-policy/threat-prevention/payload-content/name 336 | | +--rw url-category 337 | | | +--rw url-name? 338 -> /i2nsf-cfi-policy/endpoint-groups/url-group/name 339 | | +--rw voice 340 | | | +--rw source-id* string 341 | | | +--rw destination-id* string 342 | | | +--rw user-agent* string 343 | | +--rw context 344 | | | +--rw time 345 | | | | +--rw start-date-time? yang:date-and-time 346 | | | | +--rw end-date-time? yang:date-and-time 347 | | | | +--rw period 348 | | | | | +--rw start-time? time 349 | | | | | +--rw end-time? time 350 | | | | | +--rw day* day 351 | | | | | +--rw date* int32 352 | | | | | +--rw month* string 353 | | | | +--rw frequency? enumeration 354 | | | +--rw application 355 | | | | +--rw protocol* identityref 356 | | | +--rw device-type 357 | | | | +--rw device* identityref 358 | | | +--rw users 359 | | | | +--rw user* [id] 360 | | | | | +--rw id uint32 361 | | | | | +--rw name? string 362 | | | | +--rw group* [id] 363 | | | | +--rw id uint32 364 | | | | +--rw name? string 365 | | | +--rw geographic-location 366 | | | +--rw source* 367 -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 368 | | | +--rw destination* 369 -> /i2nsf-cfi-policy/endpoint-groups/location-group/name 370 | | +--rw threat-feed 371 | | +--rw name* 372 -> /i2nsf-cfi-policy/threat-prevention/threat-feed-list/name 374 NSF-Facing Interface: 375 | +--rw condition 376 | | +--rw description? string 377 | | +--rw layer-2* [destination-mac-address source-mac-address 378 ethertype] 379 | | | +--rw description? string 380 | | | +--rw destination-mac-address yang:mac-address 381 | | | +--rw destination-mac-address-mask? yang:mac-address 382 | | | +--rw source-mac-address yang:mac-address 383 | | | +--rw source-mac-address-mask? yang:mac-address 384 | | | +--rw ethertype eth:ethertype 385 | | +--rw (layer-3)? 386 | | | +--:(ipv4) 387 | | | | +--rw ipv4 388 | | | | +--rw description? string 389 | | | | +--rw dscp? inet:dscp 390 | | | | +--rw ecn? uint8 391 | | | | +--rw length? uint16 392 | | | | +--rw ttl? uint8 393 | | | | +--rw protocol? uint8 394 | | | | +--rw ihl? uint8 395 | | | | +--rw flags? bits 396 | | | | +--rw offset? uint16 397 | | | | +--rw identification? uint16 398 | | | | +--rw (destination-network)? 399 | | | | | +--:(destination-ipv4-network) 400 | | | | | | +--rw destination-ipv4-network? 401 inet:ipv4-prefix 402 | | | | | +--:(destination-ipv4-range) 403 | | | | | +--rw destination-ipv4-range* [start end] 404 | | | | | +--rw start inet:ipv4-address-no-zone 405 | | | | | +--rw end inet:ipv4-address-no-zone 406 | | | | +--rw (source-network)? 407 | | | | +--:(source-ipv4-network) 408 | | | | | +--rw source-ipv4-network? inet:ipv4-prefix 409 | | | | +--:(source-ipv4-range) 410 | | | | +--rw source-ipv4-range* [start end] 411 | | | | +--rw start inet:ipv4-address-no-zone 412 | | | | +--rw end inet:ipv4-address-no-zone 413 | | | +--:(ipv6) 414 | | | +--rw ipv6 415 | | | +--rw description? string 416 | | | +--rw dscp? inet:dscp 417 | | | +--rw ecn? uint8 418 | | | +--rw length? uint16 419 | | | +--rw ttl? uint8 420 | | | +--rw protocol? uint8 421 | | | +--rw (destination-network)? 422 | | | | +--:(destination-ipv6-network) 423 | | | | | +--rw destination-ipv6-network? 424 inet:ipv6-prefix 425 | | | | +--:(destination-ipv6-range) 426 | | | | +--rw destination-ipv6-range* [start end] 427 | | | | +--rw start inet:ipv6-address-no-zone 428 | | | | +--rw end inet:ipv6-address-no-zone 429 | | | +--rw (source-network)? 430 | | | | +--:(source-ipv6-network) 431 | | | | | +--rw source-ipv6-network? inet:ipv6-prefix 432 | | | | +--:(source-ipv6-range) 433 | | | | +--rw source-ipv6-range* [start end] 434 | | | | +--rw start inet:ipv6-address-no-zone 435 | | | | +--rw end inet:ipv6-address-no-zone 436 | | | +--rw flow-label? inet:ipv6-flow-label 437 | | +--rw (layer-4)? 438 | | | +--:(tcp) 439 | | | | +--rw tcp 440 | | | | +--rw description? string 441 | | | | +--rw source-port-number 442 | | | | | +--rw (source-port)? 443 | | | | | +--:(range-or-operator) 444 | | | | | | +--rw (port-range-or-operator)? 445 | | | | | | +--:(range) 446 | | | | | | | +--rw lower-port inet:port-number 447 | | | | | | | +--rw upper-port inet:port-number 448 | | | | | | +--:(operator) 449 | | | | | | +--rw operator? operator 450 | | | | | | +--rw port inet:port-number 451 | | | | | +--:(port-list) 452 | | | | | +--rw port-numbers* [start end] 453 | | | | | +--rw start inet:port-number 454 | | | | | +--rw end inet:port-number 455 | | | | +--rw destination-port-number 456 | | | | | +--rw (destination-port)? 457 | | | | | +--:(range-or-operator) 458 | | | | | | +--rw (port-range-or-operator)? 459 | | | | | | +--:(range) 460 | | | | | | | +--rw lower-port inet:port-number 461 | | | | | | | +--rw upper-port inet:port-number 462 | | | | | | +--:(operator) 463 | | | | | | +--rw operator? operator 464 | | | | | | +--rw port inet:port-number 465 | | | | | +--:(port-list) 466 | | | | | +--rw port-numbers* [start end] 467 | | | | | +--rw start inet:port-number 468 | | | | | +--rw end inet:port-number 469 | | | | +--rw sequence-number? uint32 470 | | | | +--rw acknowledgement-number? uint32 471 | | | | +--rw data-offset? uint8 472 | | | | +--rw reserved? uint8 473 | | | | +--rw flags? bits 474 | | | | +--rw window-size? uint16 475 | | | | +--rw urgent-pointer? uint16 476 | | | | +--rw options? binary 477 | | | +--:(udp) 478 | | | | +--rw udp 479 | | | | +--rw description? string 480 | | | | +--rw source-port-number 481 | | | | | +--rw (source-port)? 482 | | | | | +--:(range-or-operator) 483 | | | | | | +--rw (port-range-or-operator)? 484 | | | | | | +--:(range) 485 | | | | | | | +--rw lower-port inet:port-number 486 | | | | | | | +--rw upper-port inet:port-number 487 | | | | | | +--:(operator) 488 | | | | | | +--rw operator? operator 489 | | | | | | +--rw port inet:port-number 490 | | | | | +--:(port-list) 491 | | | | | +--rw port-numbers* [start end] 492 | | | | | +--rw start inet:port-number 493 | | | | | +--rw end inet:port-number 494 | | | | +--rw destination-port-number 495 | | | | | +--rw (destination-port)? 496 | | | | | +--:(range-or-operator) 497 | | | | | | +--rw (port-range-or-operator)? 498 | | | | | | +--:(range) 499 | | | | | | | +--rw lower-port inet:port-number 500 | | | | | | | +--rw upper-port inet:port-number 501 | | | | | | +--:(operator) 502 | | | | | | +--rw operator? operator 503 | | | | | | +--rw port inet:port-number 504 | | | | | +--:(port-list) 505 | | | | | +--rw port-numbers* [start end] 506 | | | | | +--rw start inet:port-number 507 | | | | | +--rw end inet:port-number 508 | | | | +--rw length? uint16 509 | | | +--:(sctp) 510 | | | | +--rw sctp 511 | | | | +--rw description? string 512 | | | | +--rw source-port-number 513 | | | | | +--rw (source-port)? 514 | | | | | +--:(range-or-operator) 515 | | | | | | +--rw (port-range-or-operator)? 516 | | | | | | +--:(range) 517 | | | | | | | +--rw lower-port inet:port-number 518 | | | | | | | +--rw upper-port inet:port-number 519 | | | | | | +--:(operator) 520 | | | | | | +--rw operator? operator 521 | | | | | | +--rw port inet:port-number 522 | | | | | +--:(port-list) 523 | | | | | +--rw port-numbers* [start end] 524 | | | | | +--rw start inet:port-number 525 | | | | | +--rw end inet:port-number 526 | | | | +--rw destination-port-number 527 | | | | | +--rw (destination-port)? 528 | | | | | +--:(range-or-operator) 529 | | | | | | +--rw (port-range-or-operator)? 530 | | | | | | +--:(range) 531 | | | | | | | +--rw lower-port inet:port-number 532 | | | | | | | +--rw upper-port inet:port-number 533 | | | | | | +--:(operator) 534 | | | | | | +--rw operator? operator 535 | | | | | | +--rw port inet:port-number 536 | | | | | +--:(port-list) 537 | | | | | +--rw port-numbers* [start end] 538 | | | | | +--rw start inet:port-number 539 | | | | | +--rw end inet:port-number 540 | | | | +--rw chunk-type* uint8 541 | | | | +--rw chunk-length? uint16 542 | | | +--:(dccp) 543 | | | | +--rw dccp 544 | | | | +--rw description? string 545 | | | | +--rw source-port-number 546 | | | | | +--rw (source-port)? 547 | | | | | +--:(range-or-operator) 548 | | | | | | +--rw (port-range-or-operator)? 549 | | | | | | +--:(range) 550 | | | | | | | +--rw lower-port inet:port-number 551 | | | | | | | +--rw upper-port inet:port-number 552 | | | | | | +--:(operator) 553 | | | | | | +--rw operator? operator 554 | | | | | | +--rw port inet:port-number 555 | | | | | +--:(port-list) 556 | | | | | +--rw port-numbers* [start end] 557 | | | | | +--rw start inet:port-number 558 | | | | | +--rw end inet:port-number 559 | | | | +--rw destination-port-number 560 | | | | | +--rw (destination-port)? 561 | | | | | +--:(range-or-operator) 562 | | | | | | +--rw (port-range-or-operator)? 563 | | | | | | +--:(range) 564 | | | | | | | +--rw lower-port inet:port-number 565 | | | | | | | +--rw upper-port inet:port-number 566 | | | | | | +--:(operator) 567 | | | | | | +--rw operator? operator 568 | | | | | | +--rw port inet:port-number 569 | | | | | +--:(port-list) 570 | | | | | +--rw port-numbers* [start end] 571 | | | | | +--rw start inet:port-number 572 | | | | | +--rw end inet:port-number 573 | | | | +--rw service-code* uint32 574 | | | | +--rw type* uint8 575 | | | | +--rw data-offset? uint8 576 | | | +--:(icmp) 577 | | | +--rw icmp 578 | | | +--rw description? string 579 | | | +--rw version? enumeration 580 | | | +--rw type? uint8 581 | | | +--rw code? uint8 582 | | | +--rw rest-of-header? binary 583 | | +--rw url-category 584 | | | +--rw description? string 585 | | | +--rw pre-defined* string 586 | | | +--rw user-defined* string 587 | | +--rw voice 588 | | | +--rw description? string 589 | | | +--rw source-voice-id* string 590 | | | +--rw destination-voice-id* string 591 | | | +--rw user-agent* string 592 | | +--rw ddos 593 | | | +--rw description? string 594 | | | +--rw alert-packet-rate? uint32 595 | | | +--rw alert-flow-rate? uint32 596 | | | +--rw alert-byte-rate? uint32 597 | | +--rw anti-virus 598 | | | +--rw profile* string 599 | | | +--rw exception-files* string 600 | | +--rw payload 601 | | | +--rw description? string 602 | | | +--rw content* binary 603 | | +--rw context 604 | | +--rw description? string 605 | | +--rw time 606 | | | +--rw start-date-time? yang:date-and-time 607 | | | +--rw end-date-time? yang:date-and-time 608 | | | +--rw period 609 | | | | +--rw start-time? time 610 | | | | +--rw end-time? time 611 | | | | +--rw day* day 612 | | | | +--rw date* int8 613 | | | | +--rw month* string 614 | | | +--rw frequency? enumeration 615 | | +--rw application 616 | | | +--rw description? string 617 | | | +--rw protocol* identityref 618 | | +--rw device-type 619 | | | +--rw description? string 620 | | | +--rw device* identityref 621 | | +--rw users 622 | | | +--rw description? string 623 | | | +--rw user* [id] 624 | | | | +--rw id uint32 625 | | | | +--rw name? string 626 | | | +--rw group* [id] 627 | | | +--rw id uint32 628 | | | +--rw name? string 629 | | +--rw geographic-location 630 | | +--rw description? string 631 | | +--rw source* string 632 | | +--rw destination* string 634 Figure 4: The CFI and NFI Condition YANG Trees 636 Figure 4 shows CFI and NFI Condition YANG Trees. It shows a 637 different way to manipulate the Access Control Lists (ACLs) for the 638 CFI and NFI YANG data models. The CFI aims at an easy security 639 policy configuration, thus only provides a simple and most often 640 needed fields in ACls, i.e., source and destination address (IPv4 or 641 IPv6), type of transport protocol, source and destination port 642 numbers, type of application protocol, and ICMP type and code. 643 While, the NFI imports from [RFC8519] to provide a detailed 644 configuration of packet header. 646 Additionally, both data models provide configuration for advanced 647 network security functions such as DDoS, Antivirus, Payload (DPI), 648 URL Filtering, and Voice Filtering conditions. The difference is 649 that in CFI some of the information (name, value) for configuration 650 is saved into a database in Security Controller for easy 651 configuration. The configuration can be done by using the key name 652 that holds the corresponding value. 654 The YANG data models also has context condition that can be one to 655 one mapped, such as time condition to define the active period of a 656 rule or geographic location condition to filter traffic from/to a 657 certain region that can be mapped into the source and destination IP 658 (IPv4 or IPv6) addresses based on the database provided. 660 4.2.3. The CFI and NFI Action YANG Data Models Comparison 661 Consumer-Facing Interface (CFI): 662 +--rw actions 663 | +--rw primary-action 664 | | +--rw action? identityref 665 | +--rw secondary-action 666 | +--rw log-action? identityref 668 NSF-Facing Interface (NFI): 669 | +--rw action 670 | +--rw description? string 671 | +--rw packet-action 672 | | +--rw ingress-action? identityref 673 | | +--rw egress-action? identityref 674 | | +--rw log-action? identityref 675 | +--rw flow-action 676 | | +--rw ingress-action? identityref 677 | | +--rw egress-action? identityref 678 | | +--rw log-action? identityref 679 | +--rw advanced-action 680 | +--rw content-security-control* identityref 681 | +--rw attack-mitigation-control* identityref 683 Figure 5: The CFI and NFI Action YANG Trees 685 Figure 4 shows CFI and NFI Action YANG Trees. The action in CFI YANG 686 data model is separated into primary-action and secondary-action. 687 Primary action is the Ingress and Egress action (i.e., pass, drop, 688 reject, rate-limit, mirror, invoke-signaling, tunnel-encapsulation, 689 forwarding, and transformation) in the NFI YANG data model. The 690 secondary-action is the log-action to log the rule that has been 691 triggered by a packet/flow or log the packet/flow that triggered the 692 rule. The NFI also can specify the action as packet or flow action 693 depending on the capability of the NSF. 695 In NFI YANG data model, the advanced action is used to activate the 696 Service Function Chaining (SFC) to apply multiple NSFs on network 697 traffics. This does not exist in CFI as the CFI is used to provide a 698 high-level action. The action of a certain policy in CFI may require 699 multiple NSFs (e.g., a URL filtering with firewall) as a single NSF 700 may not have the capability to handle the security policy. Thus, the 701 SFC of those NSFs is handled by NFI. 703 5. Design of Security Policy Translator 705 Commonly used security policies are created as XML (Extensible Markup 706 Language) [XML] files. A popular way to change the format of an XML 707 file is to use an XSLT (Extensible Stylesheet Language 708 Transformation) [XSLT] document. XSLT is an XML-based language to 709 transform an input XML file into another output XML file. However, 710 the use of XSLT makes it difficult to manage the security policy 711 translator and to handle the registration of new capabilities of 712 NSFs. With the necessity for a security policy translator, this 713 document describes a security policy translator based on Automata 714 theory. 716 5.1. Overall Structure of Security Policy Translator 717 +--------------------------------------------------+ 718 | I2NSF User | 719 +------------------------+-------------------------+ 720 | Consumer-Facing Interface 721 | 722 High-level Security Policy 723 | 724 Security Controller V 725 +------------------------+--------------------------------+ 726 | Security Policy | | 727 | Translator V | 728 | +---------------------+----------------------------++ | 729 | | | | | 730 | | V | | 731 | | +-------+--------+ +----------+ | | 732 | | | DFA-based | |Data Model| | | 733 | | | Data Extractor | | Mapper | | | 734 | | +-------+--------+ +----------+ | | 735 | | Extracted Data from | Mapping | | | 736 | | High-Level Policy V Model V | | 737 | | +-----+-----+ +--------+ | | 738 | | | Data |<--------->| NSF DB | | | 739 | | | Converter | +--------+ | | 740 | | +-----+-----+ | | 741 | | | Required Data for | | 742 | | V Target NSFs | | 743 | | +--------+---------+ | | 744 | | | Policy Generator | | | 745 | | +--------+---------+ | | 746 | | | | | 747 | | V | | 748 | +---------------------+-----------------------------+ | 749 | | | 750 | V | 751 +------------------------+--------------------------------+ 752 | NSF-Facing Interface 753 | 754 Low-level Security Policy 755 | 756 V 757 +------------------------+-------------------------+ 758 | NSF(s) | 759 +--------------------------------------------------+ 761 Figure 6: The Overall Design of Security Policy Translator 763 Figure 6 shows the overall design for Security Policy Translator in 764 Security Controller. There are four main components for Security 765 Policy Translator: Data Extractor, Data Converter, Policy Generator, 766 and Data Model Mapper. 768 Extractor is a DFA-based module for extracting data from a high-level 769 policy which I2NSF User delivered via Consumer-Facing Interface. 770 Data Model Mapper creates a mapping model for mapping the elements 771 between Consumer-Facing Interface and NSF-Facing Interface. Data 772 Converter converts the extracted data to the capabilities of target 773 NSFs for a low-level policy. It refers to an NSF Database (DB) in 774 order to convert an abstract subject or object into the corresponding 775 concrete subject or object (e.g., IP address and website URL). 776 Policy Generator generates a low-level policy which will execute the 777 NSF capabilities from Converter. 779 5.2. DFA-based Data Extractor 781 5.2.1. Design of DFA-based Data Extractor 783 +----------+ 784 | accepter | 785 +----------+ 786 | ^ 787 | | 788 v | 789 +------------------------------------------------------+ 790 | middle 1 | 791 +------------------------------------------------------+ 792 | ^ | ^ | ^ 793 | | | | ... | | 794 v | v | v | 796 ... ... ... 798 +-------------+ +-------------+ +-------------+ 799 | extractor 1 | | extractor 2 | ... | extractor m | 800 +-------------+ +-------------+ +-------------+ 801 data:1 data:2 data:m 803 Figure 7: DFA Architecture of Data Extractor 805 Figure 7 shows a design for Data Extractor in the security policy 806 translator. If a high-level policy contains data along the 807 hierarchical structure of the standard Consumer-Facing Interface YANG 808 data model [I-D.ietf-i2nsf-consumer-facing-interface-dm], data can be 809 easily extracted using the state transition machine, such as DFA. 810 The extracted data can be processed and used by an NSF to understand 811 it. Extractor can be constructed by designing a DFA with the same 812 hierarchical structure as a YANG data model. 814 After constructing a DFA, Data Extractor can extract all of data in 815 the entered high-level policy by using state transitions. Also, the 816 DFA can easily detect the grammar errors of the high-level policy. 817 The extracting algorithm of Data Extractor is as follows: 819 1. Start from the 'accepter' state. 821 2. Read the next tag from the high-level policy. 823 3. Transit to the corresponding state. 825 4. If the current state is in 'extractor', extract the corresponding 826 data, and then go back to step 2. 828 5. If the current state is in 'middle', go back to step 2. 830 6. If there is no possible transition and arrived at 'accepter' 831 state, the policy has no grammar error. Otherwise, there is a 832 grammar error, so stop the process with failure. 834 5.2.2. Example Scenario for Data Extractor 835 837 block_web_security_policy 838 839 block_web 840 841 842 Son's_PC 843 844 845 malicious_websites 846 847 848 849 850 drop 851 852 853 854 856 Figure 8: The Example of High-level Policy 857 +----------+ 858 | accepter | 859 +----------+ 860 | ^ 861 | | 862 v | 863 +------------------------------------------------------+ 864 | middle 1 | 865 +------------------------------------------------------+ 866 | ^ | ^ 867 | | | | 868 v | | | 869 +-------------+ | | 870 | extractor 1 | | | 871 +-------------+ | | 872 block_web_security | | 873 _policy v | 874 +------------------------------------------------------+ 875 | middle 2 | 876 +------------------------------------------------------+ 877 | ^ | ^ | ^ 878 | | | | | | 879 v | v | v | 880 +-------------+ +--------------------------+ +-------------+ 881 | extractor 2 | | middle 3 | | middle 6 | 882 +-------------+ +--------------------------+ +-------------+ 883 block_web | ^ | ^ | ^ 884 | | | | conition> | | 886 | | | | | | 887 | | condition> | | action>| | action> 889 v | v | v | 890 +-------------+ +-------------+ +-------------+ 891 | middle 4 | | middle 5 | | middle 7 | 892 +-------------+ +-------------+ +-------------+ 893 | ^ | ^ | ^ 894 | | | | 895 | | name>| | name> | | 896 v | v | v | 897 +-------------+ +-------------+ +-------------+ 898 | extractor 3 | | extractor 4 | | extractor 5 | 899 +-------------+ +-------------+ +-------------+ 900 Son's_PC malicious_websites drop 902 Figure 9: The Example of Data Extractor 904 To explain the Data Extractor process by referring to an example 905 scenario, assume that Security Controller received a high-level 906 policy for a web-filtering as shown in Figure 8. Then we can 907 construct DFA-based Data Extractor by using the design as shown in 908 Figure 7. Figure 9 shows the architecture of Data Extractor that is 909 based on the architecture in Figure 7 along with the input high-level 910 policy in Figure 8. Data Extractor can automatically extract all of 911 data in the high-level policy according to the following process: 913 1. Start from the 'accepter' state. 915 2. Read the first opening tag called '', and 916 transit to the 'middle 1' state. 918 3. Read the second opening tag called '', and transit to the 919 'extractor 1' state. 921 4. The current state is an 'extractor' state. Extract the data of 922 'name' field called 'block_web_security_policy'. 924 5. Read the second closing tag called '', and go back to the 925 'middle 1' state. 927 6. Read the third opening tag called '', and transit to the 928 'middle 2' state. 930 7. Read the fourth opening tag called '', and transit to the 931 'extractor 2' state. 933 8. The current state is an 'extractor' state. Extract the data of 934 'name' field called 'block_web'. 936 9. Read the fourth closing tag called '', and go back to the 937 'middle 2' state. 939 10. Read the fifth opening tag called '', and transit to 940 the 'middle 3' state. 942 11. Read the sixth opening tag called '', and 943 transit to the 'middle 4' state. 945 12. Read the seventh opening tag called '', and transit to 946 the 'extractor 3' state. 948 13. The current state is an 'extractor' state. Extract the data of 949 'source' field called 'Son's_PC'. 951 14. Read the seventh closing tag called '', and go back to 952 the 'middle 4' state. 954 15. Read the sixth closing tag called '', and 955 go back to the 'middle 3' state. 957 16. Read the eight opening tag called '', and transit 958 to the 'middle 5' state. 960 17. Read the ninth opening tag called '', and transit to 961 the 'extractor 4' state. 963 18. The current state is an 'extractor' state. Extract the data of 964 'url-name' field called 'malicious_websites'. 966 19. Read the ninth closing tag called '', and go back to 967 the 'middle 5' state. 969 20. Read the eight closing tag called '', and go 970 back to the 'middle 3' state. 972 21. Read the fifth closing tag called '', and go back to 973 the 'middle 2' state. 975 22. Read the tenth opening tag called '', and transit to 976 the 'middle 6' state. 978 23. Read the eleventh opening tag called '', and 979 transit to the 'middle 7' state. 981 24. Read the twelfth opening tag called '', and transit to 982 the 'extractor 5' state. 984 25. The current state is an 'extractor' state. Extract the data of 985 'action' field called 'drop'. 987 26. Read the twelfth closing tag called '', and go back to 988 the 'middle 7' state. 990 27. Read the eleventh closing tag called '', and go 991 back to the 'middle 6' state. 993 28. Read the tenth closing tag called '', and go back to 994 the 'middle 2' state. 996 29. Read the third closing tag called '', and go back to the 997 'middle 2' state. 999 30. Read the first closing tag called '', and go 1000 back to the 'accepter' state. 1002 31. There is no further possible transition, and the state is 1003 finally on 'accepter' state. There is no grammar error in 1004 Figure 8 so the scanning for data extraction is finished. 1006 The above process is constructed by an extracting algorithm. After 1007 finishing all the steps of the above process, Data Extractor can 1008 extract all of data in Figure 8, 'block_web_security_policy', 1009 'block_malicious', 'Son's_PC', 'malicious_websites', and 'drop'. 1011 Since the translator is modularized into a DFA structure, a visual 1012 understanding is feasible. Also, the performance of Data Extractor 1013 is excellent compared to one-to-one searching of data for a 1014 particular field. In addition, the management is efficient because 1015 the DFA completely follows the hierarchy of Consumer-Facing 1016 Interface. If I2NSF User wants to modify the data model of a high- 1017 level policy, it only needs to change the connection of the relevant 1018 DFA node. 1020 5.3. Data Converter 1022 5.3.1. Role of Data Converter 1024 Every NSF has its own unique capabilities. The capabilities of an 1025 NSF are registered into Security Controller by a Developer's 1026 Management System, which manages the NSF, via Registration Interface. 1027 Therefore, Security Controller already has all information about the 1028 capabilities of NSFs. This means that Security Controller can find 1029 target NSFs with only the data (e.g., subject and object for a 1030 security policy) of the high-level policy by comparing the extracted 1031 data with all capabilities of each NSF. This search process for 1032 appropriate NSFs is called by policy provisioning, and it eliminates 1033 the need for I2NSF User to specify the target NSFs explicitly in a 1034 high-level security policy. 1036 Data Converter selects target NSFs and converts the extracted data 1037 into the capabilities of selected NSFs. If Security Controller uses 1038 this data convertor, it can provide the policy provisioning function 1039 to I2NSF User automatically. Thus, the translator design provides 1040 big benefits to the I2NSF Framework. 1042 5.3.2. NSF Database 1044 The NSF Database contains all the information needed to convert high- 1045 level policy data to low-level policy data. The contents of NSF 1046 Database are classified as the following two: "endpoint information" 1047 and "NSF capability information". 1049 The first is "endpoint information". Endpoint information is 1050 necessary to convert an abstract high-level policy data such as 1051 Son's_PC, malicious to a specific low-level policy data such as 1052 10.0.0.1, illegal.com. In the high-level policy, the range of 1053 endpoints for applying security policy MUST be provided abstractly. 1054 Thus, endpoint information is needed to specify the abstracted high- 1055 level policy data. Endpoint information is provided by I2NSF User as 1056 the high-level policy through Consumer-Facing Interface, and Security 1057 Controller builds NSF Database based on received information. 1059 The second is "NSF capability information". Since capability is 1060 information that allows NSF to know what features it can support, NSF 1061 capability information is used in policy provisioning process to 1062 search the appropriate NSFs through the security policy. NSF 1063 capability information is provided by Developer's Management System 1064 (DMS) through Registration Interface, and Security Controller builds 1065 NSF Database based on received information. In addition, if the NSF 1066 sends monitoring information such as initiating information to 1067 Security Controller through NSF-Facing Interface, Security Controller 1068 can modify NSF Database accordingly. 1070 NSF Capability Information Endpoint Information 1071 +-------------------+ has convert +------------------+ 1072 | NSF +||---+ +-------||+ Endpoint | 1073 +-------------------+ | | +------------------+ 1074 | *nsf_id (INT) | | | | *end_id (INT) | 1075 | nsf_name (STRING)| | | | keyword (STRING) | 1076 | inbound (INT) | | | +------------------+ 1077 | outbound (INT) | | | 1078 | bandwidth (INT) | | | 1079 | activated (BOOL) | | | 1080 +-------------------+ | | 1081 +---------------+ | +---------------------+ 1082 /|\ +------||+ Mapping Information | 1083 +--------------------+ has | +---------------------+ 1084 | Capability +||---+ | | *element_id (INT) | 1085 +--------------------+ | | | element_name(STR) | 1086 | *capa_id (INT) | | | | element_map (STR) | 1087 | capa_name (STRING)| | | +---------------------+ 1088 | capa_index (INT) | | | 1089 +--------------------+ | | 1090 /|\ /|\ 1091 +-----------------------+ 1092 | Field | 1093 +-----------------------+ 1094 | *field_id (INT) | 1095 | field_name (STRING) | 1096 | field_index (INT) | 1097 | mapped_data (STRING) | 1098 +-----------------------+ 1100 Figure 10: Entity-Relationship Diagram of NSF Database 1102 Figure 10 shows an Entity-Relationship Diagram (ERD) of NSF Database 1103 designed to include both endpoint information received from I2NSF 1104 User and NSF capability information received from DMS. By designing 1105 the NSF database based on the ERD, all the information necessary for 1106 security policy translation can be stored, and the network system 1107 administrator can manage the NSF database efficiently. 1109 ERD was expressed by using Crow's Foot notation. Crow's Foot 1110 notation represents a relationship between entities as a line and 1111 represents the cardinality of the relationship as a symbol at both 1112 ends of the line. Attributes prefixed with * are key values of each 1113 entity. A link with two vertical lines represents one-to-one 1114 mapping, and a bird-shaped link represents one-to-many mapping. An 1115 NSF entity stores the NSF name (nsf_name), NSF specification 1116 (inbound, outbound, bandwidth), and NSF activation (activated). A 1117 Capability entity stores the capability name (capa_name) and the 1118 index of the capability field in a Registration Interface YANG data 1119 model (capa_index). An Endpoint entity stores the keyword of 1120 abstract data conversion from I2NSF User (keyword). A Field entity 1121 stores the field name (field_name), the index of the field index in 1122 an NSF-Facing Interface YANG data model, and converted data by 1123 referring to the Endpoint entity and a 'convert' relationship. 1125 5.3.3. Data Conversion in Data Converter 1127 High-level Low-level 1128 Policy Data Policy Data 1129 +---------------+ +------------------------------+ 1130 | Policy Name | | Policy Name | 1131 | +-----------+ | The same value | +-------------------------+ | 1132 | | block_web |-|------------------->|->|block_web_security_policy| | 1133 | | _security | | | +-------------------------+ | 1134 | | _policy | | | | 1135 | +-----------+ | | | 1136 | | | | 1137 | Rule Name | | Rule Name | 1138 | +-----------+ | The same value | +-------------------------+ | 1139 | | block_web |-|------------------->|->| block_web | | 1140 | +-----------+ | | +-------------------------+ | 1141 | | | | 1142 | Source | Conversion into | Source IPv4 Range | 1143 | +-----------+ | User's IP address | +-------------------------+ | 1144 | | Son's_PC |-|------------------->|->| Start: 10.0.0.1 | | 1145 | |-----------+ | | | End : 10.0.0.3 | | 1146 | | | +-------------------------+ | 1147 | | | | 1148 | URL Name | Conversion into | URL - User Defined | 1149 | +-----------+ | malicious websites | +-------------------------+ | 1150 | | malicious |-|------------------->|->| [harm.com, | | 1151 | | _websites | | | | illegal.com] | | 1152 | +-----------+ | | +-------------------------+ | 1153 | | | | 1154 | Action | Conversion into | Action | 1155 | +-----------+ | NSF Capability | +-----------+ | 1156 | | drop |-|------------------->|->|drop/reject| | 1157 | +-----------+ | | +-----------+ | 1158 +---------------+ +------------------------------+ 1160 Figure 11: Example of Data Conversion 1162 Figure 11 shows an example for describing a data conversion in Data 1163 Converter. High-level policy data MUST be converted into low-level 1164 policy data which are compatible with NSFs. If a system 1165 administrator attaches a database to Data Converter, it can convert 1166 contents by referring to the database with SQL queries. Data 1167 conversion in Figure 11 is based on the following list: 1169 * 'Policy Name' and 'Rule Name' fields do NOT need the conversion. 1171 * 'Source' field SHOULD be converted into a range (start and end) of 1172 IPv4 addresses. 1174 * 'URL Name' field SHOULD be converted into a URL list of malicious 1175 websites. 1177 * 'Action' field SHOULD be converted into the corresponding 1178 action(s) in NSF capabilities. 1180 5.3.4. Data Model Mapper 1182 When translating a policy, the mapping between each element of the 1183 data models are necessary to properly convert the data. The Data 1184 Model Mapper create a mapping model between the elements in Consumer- 1185 Facing Interface YANG data model and NSF-Facing Interface YANG data 1186 model. Each element in the Consumer-Facing Interface Policy Data 1187 Model has at least one or more corresponding element in NSF-Facing 1188 Interface Data Model. 1190 Consumer-Facing Interface NSF-Facing Interface 1191 YANG data model YANG data model 1192 | | 1193 V V 1194 +---------+-------------------------------+------+ 1195 | | Data Model Mapper | | 1196 | | | | 1197 | | +-------------------------+ | | 1198 | +->| Convert as a Tree Graph |<-+ | 1199 | +------------+------------+ | 1200 | | | 1201 | v | 1202 | +----------------------------+ | 1203 | | Calculate each element | | 1204 | | Tree Edit Distance | | 1205 | | between the CFI and NFI | | 1206 | +--------------+-------------+ | 1207 | | | 1208 | v | 1209 | +-------------------------+ | 1210 | | Get the elements with | | 1211 | | smallest distance as | | 1212 | | the candidates | | 1213 | +-------------------------+ | 1214 | | | 1215 +-------------------------+----------------------+ 1216 | 1217 V 1218 Data Model Mapping Information 1220 Note 1221 CFI: Consumer-Facing Interface 1222 NFI: NSF-Facing Interface 1224 Figure 12: Data Model Mapping 1226 Figure 12 shows the automatic mapping method for I2NSF Security 1227 Policy Translator. The automatic mapping is helpful as the CFI and 1228 NFI YANG data models can be extended. The automatic mapper uses the 1229 CFI and NFI YANG data models as inputs. The process the Data Model 1230 and converts it into a Tree Graph. Tree Graph is used to proces the 1231 Data Model as a Tree instead of individual elements. Then the Data 1232 Model Mapper calculates the Tree Edit Distance between each element 1233 in Consumer-Facing Interface and each element in NSF-Facing 1234 Interface. The Tree Edit Distance can be calculated with an 1235 algorithm, e.g., Zhang-Shasha algorithm [Zhang-Shasha], with the 1236 calculation should start from the root of the tree. 1238 The Zhang-Shasha calculates the distance by three operations: 1240 * Insert: Inserting a node or element 1242 * Delete: Deleting a node or element 1244 * Change: Change the label of a node or element to another 1246 The insert and delete operations are a simple of adding/deleting a 1247 node or element with the length of the label of the node. The change 1248 operation must be calculated between the label of the element to 1249 produce the distance. There are methods to calculate this, such as 1250 Levenshtein Distance, Cosine Similarity, or Sequence Matching. For 1251 this data model mapper, cosine similarity should be the best choice 1252 as it measures the similarity between words. The data models have 1253 similarity between words and it can helps in calculating as minimum 1254 distance as possible. 1256 When the minimum distance is obtained, the NSF-Facing Interface 1257 element is saved as the candidates for mapping the Consumer-Facing 1258 Interface element. This information should be saved to the NSF 1259 Database for the Data Converter. 1261 Do note that the proper mapping can be achieved because the 1262 similarity between the Consumer-Facing Interface and NSF-Facing 1263 Interface. An extension created for the Consumer-Facing Interface 1264 and NSF-Facing Interface should keep the close similarity 1265 relationship between the data models to be able to produce the 1266 mapping model information automatically. 1268 The proper mapping between CFI YANG data model and NFI YANG data 1269 model provided in [I-D.ietf-i2nsf-consumer-facing-interface-dm] and 1270 [I-D.ietf-i2nsf-nsf-facing-interface-dm], respectively, can be seen 1271 in Appendix A. 1273 5.3.4.1. Handling of Default Values for a Low-level Security Policy 1275 Attributes in NFI YANG data model provide detailed configuration for 1276 NSFs to handle thorough examination for security services in a 1277 network. Some of the attributes in the NFI YANG data model can be 1278 given directly after the mapping translation from a high-level 1279 policy. But the CFI YANG data model is designed to be used easily by 1280 an I2NSF User, hence some attributes cannot be mapped directly to the 1281 attributes in the NFI YANG data model. 1283 To accommodate such attributes that cannot be given by the direct 1284 translation from the CFI YANG data model, default values can be used. 1285 For example, the attribute "default-action" in the NFI YANG data 1286 model cannot be configured by the CFI YANG data model. A firewall 1287 usually drops packets by default to make sure that only permitted 1288 packets are allowed to pass through to the network. So, the default 1289 value for the attribute "default-action" will be a "drop" action. 1290 This can be done in the implementation of the translation so that the 1291 attribute can be given a default value. 1293 The default value for different NSFs can be different depending on 1294 the type of service it offers. A typical firewall may use the 1295 default-value "drop" for the "default-action" attribute, but an 1296 antivirus may use a default-value "pass" for "default-action" to make 1297 sure that only the detected viruses are blocked. Other types of 1298 firewalls may also use different default values for the "default- 1299 action". Thus, the actual default values that are given to the NSFs 1300 are out of the scope of this document. 1302 5.3.5. Policy Provisioning 1303 Log-keeper Low-level Web-filter 1304 NSF Policy Data NSF 1305 +-------------------+ +--------------------+ +-------------------+ 1306 | Policy Name | | Policy Name | | Policy Name | 1307 | +--------------+ | | +--------------+ | | +--------------+ | 1308 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | | 1309 | | _security | | | | _security | | | | _security | | 1310 | | _policy | | | | _policy | | | | _policy | | 1311 | +--------------+ | | +--------------+ | | +--------------+ | 1312 | | | | | | 1313 | Rule Name | | Rule Name | | Rule Name | 1314 | +--------------+ | | +--------------+ | | +--------------+ | 1315 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | | 1316 | +--------------+ | | +--------------+ | | +--------------+ | 1317 | | | | | | 1318 | Source IPv4 | | Source IPv4 | | Source IPv4 | 1319 | +--------------+ | | +--------------+ | | +--------------+ | 1320 | |Start:10.0.0.1|<-|<-|<-|Start:10.0.0.1|->|->|->|Start:10.0.0.1| | 1321 | |End :10.0.0.3| | | |End :10.0.0.3| | | |End :10.0.0.3| | 1322 | +--------------+ | | +--------------+ | | +--------------+ | 1323 | | | | | | 1324 | | | URL - User Defined | | URL - User Defined| 1325 | | | +--------------+ | | +--------------+ | 1326 | | | | [harm.com, |->|->|->| [harm.com, | | 1327 | | | | illegal.com] | | | | illegal.com] | | 1328 | | | +--------------+ | | +--------------+ | 1329 | | | | | | 1330 | Log Action | | Log Action | | | 1331 | +--------------+ | | +--------------+ | | | 1332 | | True |<-|<-|<-| True | | | | 1333 | +--------------+ | | +--------------+ | | | 1334 +-------------------+ | | | | 1335 | Action | | Action | 1336 | +--------------+ | | +--------------+ | 1337 | | Drop |->|->|->| Drop/Reject | | 1338 | +--------------+ | | +--------------+ | 1339 +--------------------+ +-------------------+ 1341 Figure 13: Example of Policy Provisioning 1343 Generator searches for proper NSFs which can cover all of 1344 capabilities in the high-level policy. Generator searches for target 1345 NSFs by comparing only NSF capabilities which is registered by Vendor 1346 Management System. This process is called by "policy provisioning" 1347 because Generator finds proper NSFs by using only the policy. If 1348 target NSFs are found by using other data which is not included in a 1349 user's policy, it means that the user already knows the specific 1350 knowledge of an NSF in the I2NSF Framework. Figure 13 shows an 1351 example of policy provisioning. In this example, log-keeper NSF and 1352 web-filter NSF are selected for covering capabilities in the security 1353 policy. All of capabilities can be covered by two selected NSFs. 1355 5.4. Policy Generator 1357 Generator makes low-level security policies for each target NSF with 1358 the extracted data. The low-level security policy can be produced in 1359 the form of XML or JSON. Libray such as PyangBind [PyangBind] for 1360 Python can be used to parse the NFI YANG data model to produce an XML 1361 or JSON form automatically. 1363 +----------------------------------------------------------+ 1364 | Policy Generator | 1365 | | 1366 | +------------+ +-----------+ +-------------+ | 1367 | | Low-level | Pair | Low-Level | | NFI YANG | | 1368 | | Attributes |<---->| Data | | Data Model | | 1369 | +-----+------+ +-----+-----+ +-------+-----+ | 1370 | | | | | 1371 | | | | | 1372 | +---------+---------+ | | 1373 | | | | 1374 | | | | 1375 | v v | 1376 | +---------------+ +------------+ | 1377 | | NFI Python |<------------| PyangBind | | 1378 | | Class | +------------+ | 1379 | +-------+-------+ | 1380 | | | 1381 | | | 1382 | v | 1383 | +---------------+ | 1384 | | Low-level | | 1385 | | Policy | | 1386 | | (XML or JSON) | | 1387 | +---------------+ | 1388 | | 1389 +----------------------------------------------------------+ 1391 Figure 14: Policy Generator Architecture 1393 Figure 14 shows the architecture of the Policy Generator. First, 1394 PyangBind library generates a Python class hierarchy from an input of 1395 the NFI YANG data model. This allows low-level data instances from 1396 the Data Converter (Section 5.3) to be inserted into the NFI Python 1397 Class. To get the appropriate attributes, the low-level data is 1398 paired with the attributes received from the Data Model Mapper 1399 (Section 5.3.4). The filled entry can then be encoded into an XML or 1400 JSON form automatically by PyangBind. 1402 Figure 15 shows an XML example of a low-level policy generated by the 1403 translator. 1405 1406 block_web_security_policy 1407 1408 block_web 1409 1410 1411 1412 10.0.0.1 1413 10.0.0.3 1414 1415 1416 1417 harm.com 1418 illegal.com 1419 1420 1421 1422 drop 1423 1424 1425 1427 Figure 15: Example of Low-Level Policy 1429 6. Implementation Considerations 1431 The implementation considerations in this document include the 1432 following three: "data model auto-adaptation", "data conversion", and 1433 "policy provisioning". 1435 6.1. Data Model Auto-adaptation 1437 Security Controller which acts as an intermediary entity MUST process 1438 the data according to the data model of the connected interfaces. 1439 However, the data model can be changed flexibly depending on the 1440 situation, and Security Controller may adapt to the change of the 1441 data model. Therefore, Security Controller can be implemented for 1442 convenience so that the security policy translator can easily adapt 1443 to the change of the data model. 1445 The translator constructs and uses the DFA to adapt to the Consumer- 1446 Facing Interface Data Model. The DFA starts from the root node of 1447 the YANG tree and expands operations by changing the state according 1448 to the input. Based on the YANG data model, a container node is 1449 defined as a middle state and a leaf node is defined as an extractor 1450 node. After that, if the nodes are connected in the same way as the 1451 hierarchical structure of the data model, Security Controller can 1452 automatically construct the DFA. Therefore, the DFA can be 1453 conveniently built by investigating the link structure using the 1454 stack through a Depth-First Search, starting from the root node. 1456 The Policy Generator uses PyangBind to construct the hierarchy of the 1457 NFI YANG data model into a Python class. This allows an XML or JSON 1458 form to be generated automatically even with updates of the NFI YANG 1459 data model. Thus, the security policy translator is able to auto- 1460 adapt to the NFI YANG data model. 1462 6.2. Data Conversion 1464 Security Controller requires the ability to materialize the abstract 1465 data in the high-level security policy and forward it to NSFs. 1466 Security Controller can receive endpoint information as keywords 1467 through the high-level security policy. At this time, if the 1468 endpoint information corresponding to the keyword is mapped and the 1469 query is transmitted to the NSF Database, the NSF Database can be 1470 conveniently registered with necessary information for data 1471 conversion. When a policy tries to establish a policy through the 1472 keyword, Security Controller searches for the details corresponding 1473 to the keyword registered in the NSF Database and converts the 1474 keyword into appropriate and specific data. 1476 6.3. Policy Provisioning 1478 This document states that a policy provisioning function is necessary 1479 to enable an I2NSF User without expert security knowledge to create 1480 policies. Policy provisioning is determined by the capability of the 1481 NSF. If the information about an NSF's capability for a policy is 1482 available to Security Controller, the probability of the selection of 1483 an appropriate NSF may increase. 1485 Most importantly, selected NSFs may be able to perform all 1486 capabilities in the security policy. This document recommends the 1487 study of policy provisioning algorithms that are highly efficient and 1488 can satisfy all capabilities in the security policy. 1490 7. Features of Security Policy Translator Design 1492 First, by showing a visualized translator structure, the security 1493 manager can handle various policy changes. Translator can be shown 1494 by visualizing DFA so that the manager can easily understand the 1495 structure of Security Policy Translator. 1497 Second, if it only keeps the hierarchy of the data model, an I2NSF 1498 User can freely create high-level policies. In the case of DFA, data 1499 extraction can be performed in the same way even if the order of 1500 input is changed. The design of the security policy translator is 1501 more flexible than the existing method that works by keeping the 1502 tag's position and order exactly. 1504 Third, the structure of Security Policy Translator can be updated 1505 even while Security Policy Translator is operating. Because Security 1506 Policy Translator is modularized, the translator can adapt to changes 1507 in an NSF's capabilities while the I2NSF framework is running. The 1508 function of changing the translator's structure can be provided 1509 through the Registration Interface 1510 [I-D.ietf-i2nsf-registration-interface-dm]. 1512 8. Security Considerations 1514 There is no security concern in the proposed security policy 1515 translator as long as the I2NSF interfaces (i.e., Consumer-Facing 1516 Interface, NSF-Facing Interface, and Registration Interface) are 1517 protected by secure communication channels. 1519 9. IANA Considerations 1521 This document does not require any IANA actions. 1523 10. References 1524 10.1. Normative References 1526 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1527 the Network Configuration Protocol (NETCONF)", RFC 6020, 1528 DOI 10.17487/RFC6020, October 2010, 1529 . 1531 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1532 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1533 . 1535 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1536 and A. Bierman, Ed., "Network Configuration Protocol 1537 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1538 . 1540 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 1541 Kumar, "Framework for Interface to Network Security 1542 Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018, 1543 . 1545 [I-D.ietf-i2nsf-consumer-facing-interface-dm] 1546 Jeong, J. (., Chung, C., Ahn, T., Kumar, R., and S. Hares, 1547 "I2NSF Consumer-Facing Interface YANG Data Model", Work in 1548 Progress, Internet-Draft, draft-ietf-i2nsf-consumer- 1549 facing-interface-dm-18, 13 April 2022, 1550 . 1553 [I-D.ietf-i2nsf-nsf-facing-interface-dm] 1554 Kim, J. (., Jeong, J. (., Park, J., Hares, S., and Q. Lin, 1555 "I2NSF Network Security Function-Facing Interface YANG 1556 Data Model", Work in Progress, Internet-Draft, draft-ietf- 1557 i2nsf-nsf-facing-interface-dm-26, 19 April 2022, 1558 . 1561 [I-D.ietf-i2nsf-registration-interface-dm] 1562 Hyun, S., Jeong, J. (., Roh, T., Wi, S., and J. Park, 1563 "I2NSF Registration Interface YANG Data Model", Work in 1564 Progress, Internet-Draft, draft-ietf-i2nsf-registration- 1565 interface-dm-16, 13 April 2022, 1566 . 1569 [I-D.ietf-i2nsf-capability-data-model] 1570 Hares, S., Jeong, J. (., Kim, J. (., Moskowitz, R., and Q. 1571 Lin, "I2NSF Capability YANG Data Model", Work in Progress, 1572 Internet-Draft, draft-ietf-i2nsf-capability-data-model-30, 1573 13 April 2022, . 1576 10.2. Informative References 1578 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1579 "YANG Data Model for Network Access Control Lists (ACLs)", 1580 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1581 . 1583 [Automata] Peter, L., "Formal Languages and Automata, 6th Edition", 1584 January 2016. 1586 [Zhang-Shasha] 1587 Zhang, K. and D. Shasha, "Simple Fast Algorithms for the 1588 Editing Distance Between Trees and Related Problems", SIAM 1589 J. Comput. https://www.researchgate.net/publication/220618 1590 233_Simple_Fast_Algorithms_for_the_Editing_Distance_Betwee 1591 n_Trees_and_Related_Problems, 1989. 1593 [PyangBind] 1594 Shakir, R., "PyangBind", 1595 PyangBind https://github.com/robshakir/pyangbind, 2018. 1597 [XML] W3C, "On Views and XML (Extensible Markup Language)", June 1598 1999. 1600 [XSLT] W3C, "Extensible Stylesheet Language Transformations 1601 (XSLT) Version 1.0", November 1999. 1603 Appendix A. Mapping Information for Data Conversion 1605 Figure 16 shows a mapping list of data fields between Consumer-Facing 1606 Interface YANG data model and NSF-Facing Interface YANG data model. 1607 Figure 16 describes the process of passing the data value to the 1608 appropriate data field of the Data Model in detail after the data 1609 conversion. 1611 #policy name mapping 1612 /consumer-facing/i2nsf-cfi-policy/name 1613 -> mapping: /nsf-facing/i2nsf-security-policy 1614 /name 1616 #rule name mapping 1617 /consumer-facing/i2nsf-cfi-policy/rules/name 1618 -> mapping: /nsf-facing/i2nsf-security-policy 1619 /rules/name 1621 #time mapping 1622 /consumer-facing/i2nsf-cfi-policy/ 1623 /rules/event/time/start-date-time 1624 -> mapping: /nsf-facing/i2nsf-security-policy 1625 /rules/event/time/start-date-time 1627 /consumer-facing/i2nsf-cfi-policy/ 1628 /rules/event/time/end-date-time 1629 -> mapping: /nsf-facing/i2nsf-security-policy 1630 /rules/event/time/end-date-time 1632 /consumer-facing/i2nsf-cfi-policy/ 1633 /rules/event/time/period/day 1634 -> mapping: /nsf-facing/i2nsf-security-policy 1635 /rules/event/time/period/day 1637 /consumer-facing/i2nsf-cfi-policy/ 1638 /rules/event/time/period/date 1639 -> mapping: /nsf-facing/i2nsf-security-policy 1640 /rules/event/time/period/date 1642 /consumer-facing/i2nsf-cfi-policy/ 1643 /rules/event/time/period/month 1644 -> mapping: /nsf-facing/i2nsf-security-policy 1645 /rules/event/time/period/month 1647 /consumer-facing/i2nsf-cfi-policy/ 1648 /rules/event/time/frequency 1649 -> mapping: /nsf-facing/i2nsf-security-policy 1650 /rules/event/time/frequency 1652 #firewall-condition source target reference and mapping 1653 /consumer-facing/i2nsf-cfi-policy/rules/condition 1654 /firewall-condition/source 1655 -> reference: /consumer-facing/policy 1656 /endpoint-group/user-group/name 1657 -> reference: /consumer-facing/policy 1658 /endpoint-group/device-group/name 1659 -> extract: /consumer-facing/policy 1660 /endpoint-group/user-group/mac-address 1661 -> mapping: /nsf-facing/i2nsf-security-policy 1662 /rules/condition/ethernet 1663 /source-mac-address 1664 -> extract: /consumer-facing/policy 1665 /endpoint-group/user-group/ip-address 1666 -> mapping: /nsf-facing/i2nsf-security-policy 1667 /rules/condition/ipv4 1668 /source-ipv4-network 1670 -> mapping: /nsf-facing/i2nsf-security-policy 1671 /rules/condition/ipv4 1672 /source-ipv4-range 1673 -> mapping: /nsf-facing/i2nsf-security-policy 1674 /rules/condition/ipv6 1675 /source-ipv6-network 1676 -> mapping: /nsf-facing/i2nsf-security-policy 1677 /rules/condition/ipv6 1678 /source-ipv6-range 1680 #firewall-condition destination target reference and mapping 1681 /consumer-facing/i2nsf-cfi-policy/rule/condition 1682 /firewall-condition/destination 1683 -> reference: /consumer-facing/policy 1684 /endpoint-group/user-group/name 1685 -> reference: /consumer-facing/policy 1686 /endpoint-group/device-group/name 1687 -> extract: /consumer-facing/policy 1688 /endpoint-group/user-group/mac-address 1689 -> mapping: /nsf-facing/i2nsf-security-policy 1690 /rules/condition/ethernet 1691 /destination-mac-address 1692 -> extract: /consumer-facing/policy 1693 /endpoint-group/user-group/ip-address 1694 -> mapping: /nsf-facing/i2nsf-security-policy 1695 /rules/condition/ipv4 1696 /destination-ipv4-network 1697 -> mapping: /nsf-facing/i2nsf-security-policy 1698 /rules/condition/ipv4 1699 /destination-ipv4-range 1700 -> mapping: /nsf-facing/i2nsf-security-policy 1701 /rules/condition/ipv6 1702 /destination-ipv6-network 1703 -> mapping: /nsf-facing/i2nsf-security-policy 1704 /rules/condition/ipv6 1705 /destination-ipv6-range 1707 #ddos-condition threshold mapping 1708 /consumer-facing/i2nsf-cfi-policy/rules/condition 1709 /ddos-condition/packet-rate-threshold 1710 -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition 1711 /ddos/alert-packet-rate 1713 /consumer-facing/i2nsf-cfi-policy/rules/condition 1714 /ddos-condition/packet-byte-threshold 1715 -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition 1716 /ddos/alert-byte-rate 1718 /consumer-facing/i2nsf-cfi-policy/rules/condition 1719 /ddos-condition/flow-rate-threshold 1720 -> mapping: /nsf-facing/i2nsf-security-policy/rules/condition 1721 /ddos/alert-flow-rate 1723 #payload-condition mapping 1724 /consumer-facing/i2nsf-cfi-policy/rules/condition 1725 /payload-condition/content 1726 -> reference: /consumer-facing/i2nsf-cfi-policy 1727 /threat-prevention/payload-content/name 1728 -> extract: /consumer-facing/i2nsf-cfi-policy 1729 /threat-prevention/payload-content/content 1730 -> mapping: /nsf-facing/i2nsf-security-policy 1731 /rules/condition/payload/content 1733 #voice-condition mapping 1734 /consumer-facing/i2nsf-cfi-policy/rules/condition 1735 /voice-condition/source-id 1736 -> mapping: /nsf-facing/i2nsf-security-policy 1737 /rules/condition/voice 1738 /source-voice-id 1740 /consumer-facing/i2nsf-cfi-policy/rules/condition 1741 /voice-condition/destination-id 1742 -> mapping: /nsf-facing/i2nsf-security-policy 1743 /rules/condition/voice 1744 /destination-voice-id 1746 /consumer-facing/i2nsf-cfi-policy/rules/condition 1747 /voice-condition/user-agent 1748 -> mapping: /nsf-facing/i2nsf-security-policy 1749 /rules/condition/voice 1750 /user-agent 1752 #geographic-location mapping 1753 /consumer-facing/i2nsf-cfi-policy/rules/condition/context 1754 /geographic-location/source 1755 -> reference: /consumer-facing/i2nsf-cfi-policy 1756 /endpoint-groups/location-group/name 1757 -> extract: /consumer-facing/i2nsf-cfi-policy 1758 /endpoint-groups/location-group 1759 /geo-ip-ipv4/ipv4-address 1760 -> mapping: /nsf-facing/i2nsf-security-policy 1761 /rules/condition/ipv4 1762 /source-ipv4-network 1763 -> mapping: /nsf-facing/i2nsf-security-policy 1764 /rules/condition/ipv4 1765 /source-ipv4-range 1767 -> extract: /consumer-facing/i2nsf-cfi-policy 1768 /endpoint-groups/location-group 1769 /continent 1770 -> mapping: /nsf-facing/i2nsf-security-policy 1771 /rules/condition/context 1772 /geographic-location/source 1774 /consumer-facing/i2nsf-cfi-policy/rules/condition/context 1775 /geographic-location/destination 1776 -> reference: /consumer-facing/i2nsf-cfi-policy 1777 /endpoint-groups/location-group/name 1778 -> extract: /consumer-facing/i2nsf-cfi-policy 1779 /endpoint-groups/location-group 1780 /geo-ip-ipv4/ipv4-address 1781 -> mapping: /nsf-facing/i2nsf-security-policy 1782 /rules/condition/ipv4 1783 /destination-ipv4-network 1784 -> mapping: /nsf-facing/i2nsf-security-policy 1785 /rules/condition/ipv4 1786 /destination-ipv4-range 1787 -> extract: /consumer-facing/i2nsf-cfi-policy 1788 /endpoint-groups/location-group 1789 /continent 1790 -> mapping: /nsf-facing/i2nsf-security-policy 1791 /rules/condition/context 1792 /geographic-location/destination 1794 #url-condition mapping 1795 /consumer-facing/i2nsf-cfi-policy/rules/condition 1796 /url-condition/url-name 1797 -> reference: /consumer-facing/i2nsf-cfi-policy 1798 /endpoint-groups/url-group/name 1799 -> extract: /consumer-facing/i2nsf-cfi-policy 1800 /endpoint-groups/url-group/url 1801 -> mapping: /nsf-facing/i2nsf-security-policy 1802 /rules/condition/url-category 1803 /pre-defined 1804 -> mapping: /nsf-facing/i2nsf-security-policy 1805 /rules/condition/url-category 1806 /user-defined 1808 #rule action name mapping 1809 /consumer-facing/i2nsf-cfi-policy/rules/actions/primary-action 1810 -> mapping: /nsf-facing/i2nsf-security-policy 1811 /rules/action 1812 /packet-action/ingress-action 1813 -> mapping: /nsf-facing/i2nsf-security-policy 1814 /rules/action 1815 /packet-action/egress-action 1816 -> mapping: /nsf-facing/i2nsf-security-policy 1817 /rules/action 1818 /advanced-action/content-security-control 1819 -> mapping: /nsf-facing/i2nsf-security-policy 1820 /rules/action 1821 /advanced-action/attack-mitigation-control 1823 /consumer-facing/i2nsf-cfi-policy/rules/actions/secondary-action 1824 -> mapping: /nsf-facing/i2nsf-security-policy 1825 /rules/action/packet-action/log-action 1827 Figure 16: Mapping Information for Data Conversion 1829 The mapping list shown in the Figure 16 shows all mapped components. 1830 This data list should be saved into the NSF Database to provide the 1831 mapping information for converting the data. It is important to 1832 produce the list automatically as the Consumer-Facing Interface and 1833 NSF-Facing Interface can be extended anytime by vendors according to 1834 the provided NSF. The Data Model Mapper in Security Policy 1835 Translator should be used to produce the mapping model information 1836 automatically. 1838 Appendix B. Acknowledgments 1840 This document is a product by the I2NSF Working Group (WG) including 1841 WG Chairs (i.e., Linda Dunbar and Yoav Nir) and Diego Lopez. This 1842 document took advantage of the review and comments from the following 1843 experts: Roman Danyliw and Tom Petch. The authors sincerely 1844 appreciate their sincere efforts and kind help. 1846 This work was supported by Institute of Information & Communications 1847 Technology Planning & Evaluation (IITP) grant funded by the Korea 1848 MSIT (Ministry of Science and ICT) (2020-0-00395, Standard 1849 Development of Blockchain based Network Management Automation 1850 Technology). This work was supported in part by the IITP 1851 (R-20160222-002755, Cloud based Security Intelligence Technology 1852 Development for the Customized Security Service Provisioning). This 1853 work was supported in part by the MSIT under the Information 1854 Technology Research Center (ITRC) support program (IITP- 1855 2022-2017-0-01633) supervised by the IITP. 1857 Appendix C. Contributors 1859 The following are co-authors of this document: 1861 Chaehong Chung - Department of Electrical and Computer Engineering, 1862 Sungkyunkwan University, 2066 Seobu-ro Jangan-gu, Suwon, Gyeonggi-do 1863 16419, Republic of Korea, EMail: darkhong@skku.edu 1865 Jung-Soo Park - Electronics and Telecommunications Research 1866 Institute, 218 Gajeong-Ro, Yuseong-Gu, Daejeon, 34129, Republic of 1867 Korea, EMail: pjs@etri.re.kr 1869 Younghan Kim - School of Electronic Engineering, Soongsil University, 1870 369, Sangdo-ro, Dongjak-gu, Seoul 06978, Republic of Korea, EMail: 1871 younghak@ssu.ac.kr 1873 Appendix D. Changes from draft-yang-i2nsf-security-policy- 1874 translation-10 1876 The following changes are made from draft-yang-i2nsf-security-policy- 1877 translation-10: 1879 * This version describes the mapping between the latest versions of 1880 the Consumer-Facing Interface YANG data model 1881 [I-D.ietf-i2nsf-consumer-facing-interface-dm] and the NSF-Facing 1882 Interface YANG data model 1883 [I-D.ietf-i2nsf-nsf-facing-interface-dm]. 1885 * The title of the document is updated to "Guidelines for Security 1886 Policy Translation in Interface to Network Security Functions". 1888 * Addition of new Section 4. Relation between Consumer-Facing 1889 Interface and NSF-Facing Interface Data Models. 1891 * Addition of new Section 5.3.4.1. Handling of Default Values for a 1892 Low-level Security Policy. 1894 * Movement of Mapping Information for Data Conversion into 1895 Appendix A (previously in Section 4.3.4). 1897 Authors' Addresses 1899 Jaehoon Paul Jeong (editor) 1900 Department of Computer Science and Engineering 1901 Sungkyunkwan University 1902 2066 Seobu-Ro, Jangan-Gu 1903 Suwon 1904 Gyeonggi-Do 1905 16419 1906 Republic of Korea 1907 Phone: +82 31 299 4957 1908 Email: pauljeong@skku.edu 1909 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 1911 Patrick Lingga 1912 Department of Electronic, Electrical and Computer Engineering 1913 Sungkyunkwan University 1914 2066 Seobu-Ro, Jangan-Gu 1915 Suwon 1916 Gyeonggi-Do 1917 16419 1918 Republic of Korea 1919 Phone: +82 31 299 4957 1920 Email: patricklink@skku.edu 1922 Jinhyuk Yang 1923 Department of Electronic, Electrical and Computer Engineering 1924 Sungkyunkwan University 1925 2066 Seobu-Ro, Jangan-Gu 1926 Suwon 1927 Gyeonggi-Do 1928 16419 1929 Republic of Korea 1930 Phone: +82 10 8520 8039 1931 Email: jin.hyuk@skku.edu 1933 Jeonghyeon Kim 1934 Department of Electronic, Electrical and Computer Engineering 1935 Sungkyunkwan University 1936 2066 Seobu-Ro, Jangan-Gu 1937 Suwon 1938 Gyeonggi-Do 1939 16419 1940 Republic of Korea 1941 Phone: +82 31 299 4957 1942 Email: jeonghyeon12@skku.edu