idnits 2.17.1 draft-hyun-i2nsf-registration-interface-dm-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 244 has weird spacing: '...address inet:...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hyun 3 Internet-Draft Chosun University 4 Intended status: Standards Track J. Jeong 5 Expires: January 3, 2019 T. Roh 6 S. Wi 7 Sungkyunkwan University 8 J. Park 9 ETRI 10 July 2, 2018 12 I2NSF Registration Interface YANG Data Model 13 draft-hyun-i2nsf-registration-interface-dm-04 15 Abstract 17 This document describes an YANG data model for I2NSF registration 18 interface between Security Controller and Developer's Management 19 System. The data model is required for NSF instance registration and 20 dynamic life cycle management of NSF instances. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 3, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 60 4. High-Level YANG . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Registration Interface . . . . . . . . . . . . . . . . . 4 62 4.2. Registration Request . . . . . . . . . . . . . . . . . . 4 63 4.3. Instance Management Request . . . . . . . . . . . . . . . 5 64 4.4. NSF Capability Information . . . . . . . . . . . . . . . 5 65 4.5. NSF Access Information . . . . . . . . . . . . . . . . . 6 66 4.6. NSF Performance Capability . . . . . . . . . . . . . . . 6 67 4.7. Role-Based ACL(Access Control List) . . . . . . . . . . . 6 68 5. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. XML Example of Registration Interface Data Model . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 74 8.2. Informative References . . . . . . . . . . . . . . . . . 14 75 Appendix A. Changes from draft-hyun-i2nsf-registration- 76 interface-dm-03 . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 79 1. Introduction 81 This document provides a YANG [RFC6020] data model that defines the 82 required data for the registration interface between Security 83 Controller and Developer's Management System to dynamically manage a 84 pool of NSF instances. This document defines a YANG data model based 85 on the [i2nsf-reg-inf-im]. The terms used in this document are 86 defined in [i2nsf-terminology]. 88 2. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 3. Terminology 96 This document uses the terminology described in [i2nsf-terminology], 97 [capability-im], [RFC8329], [nsf-triggered-steering], 98 [supa-policy-data-model], and [supa-policy-info-model]. 100 o Network Security Function (NSF): A function that is responsible 101 for specific treatment of received packets. A Network Security 102 Function can act at various layers of a protocol stack (e.g., at 103 the network layer or other OSI layers). Sample Network Security 104 Service Functions are as follows: Firewall, Intrusion Prevention/ 105 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 106 Application Visibility and Control (AVC), network virus and 107 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 108 Denial of Service (DDoS) mitigation and TLS proxy. 109 [nsf-triggered-steering] 111 o Advanced Inspection/Action: As like the I2NSF information model 112 for NSF facing interface [capability-im], Advanced Inspection/ 113 Action means that a security function calls another security 114 function for further inspection based on its own inspection 115 result. [nsf-triggered-steering] 117 o Network Security Function Profile (NSF Capability Information): 118 NSF Capability Information specifies the inspection capabilities 119 of the associated NSF instance. Each NSF instance has its own NSF 120 Capability Information to specify the type of security service it 121 provides and its resource capacity etc. [nsf-triggered-steering] 123 o Data Model: A data model is a representation of concepts of 124 interest to an environment in a form that is dependent on data 125 repository, data definition language, query language, 126 implementation language, and protocol. [supa-policy-info-model] 128 o Information Model: An information model is a representation of 129 concepts of interest to an environment in a form that is 130 independent of data repository, data definition language, query 131 language, implementation language, and protocol. 132 [supa-policy-info-model] 134 3.1. Tree Diagrams 136 A simplified graphical representation of the data model is used in 137 this document. The meaning of the symbols in these diagrams 138 [i2rs-rib-data-model] is as follows: 140 Brackets "[" and "]" enclose list keys. 142 Abbreviations before data node names: "rw" means configuration 143 (read-write) and "ro" state data (read-only). 145 Symbols after data node names: "?" means an optional node and "*" 146 denotes a "list" and "leaf-list". 148 Parentheses enclose choice and case nodes, and case nodes are also 149 marked with a colon (":"). 151 Ellipsis ("...") stands for contents of subtrees that are not 152 shown. 154 4. High-Level YANG 156 This section provides an overview of the high level YANG. 158 4.1. Registration Interface 160 module : ietf-i2nsf-regs-interface-model 161 +--rw regs-req 162 | uses i2nsf-regs-req 163 +--rw instance-mgnt-req 164 | uses i2nsf-instance-mgnt-req 166 Figure 1: High-Level YANG of I2NSF Registration Interface 168 Each of these sections mirror sections of [i2nsf-reg-inf-im]. 170 4.2. Registration Request 172 This section expands the i2nsf-regs-req in Figure 1. 174 Registration Request 175 +--rw i2nsf-regs-req 176 +--rw nsf-capability-information 177 | uses i2nsf-nsf-capability-information 178 +--rw nsf-access-info 179 | uses i2nsf-nsf-access-info 181 Figure 2: High-Level YANG of I2NSF Registration Request 183 Registration Request contains the capability information of newly 184 created NSF to notify its capability to Security Controller. The 185 request also contains Network Access Information so that the Security 186 Controller can access the NSF. 188 4.3. Instance Management Request 190 This section expands the i2nsf-instance-mgnt-req in Figure 1. 192 Instance Management Request 193 +--rw i2nsf-instance-mgnt-req 194 +--rw req-level uint16 195 +--rw req-id uint64 196 +--rw (req-type)? 197 +--rw (instanciation-request) 198 +--rw in-nsf-capability-information 199 | uses i2nsf-nsf-capability-information 200 +--rw (deinstanciation-request) 201 +--rw de-nsf-access-info 202 | uses i2nsf-nsf-access-info 203 +--rw (reinstanciation-request) 204 +--rw re-nsf-capability-information 205 | uses i2nsf-nsf-capability-information 207 Figure 3: High-Level YANG of I2NSF Instance Mgnt Request 209 Instance management request consists of two types: instanciation- 210 request, deinstanciation-request, and reinstanciation-request. The 211 instanciation-request is used to request generation of a new NSF 212 instance with NSF Capability Information which specifies required NSF 213 capability information. The deinstanciation-request is used to 214 remove an existing NSF with NSF Access Information. The 215 reinstanciation nsf request is used to updating a existing NSf 216 information with NSF capabilities. 218 4.4. NSF Capability Information 220 This section expands the i2nsf-nsf-capability-information in Figure 2 221 and Figure 3. 223 NSF Capability Information 224 +--rw i2nsf-nsf-capability-information 225 +--rw i2nsf-capability 226 | uses ietf-i2nsf-capability 227 +--rw performance-capability 228 | uses i2nsf-nsf-performance-caps 230 Figure 4: High-Level YANG of I2NSF NSF Capability Information 232 In Figure 4, ietf-i2nsf-capability refers module ietf-i2nsf- 233 capability in [i2nsf-capability-dm]. We add the performance 234 capability because it is absent in [i2nsf-capability-dm] and 235 [netmod-acl-model] 237 4.5. NSF Access Information 239 This section expands the i2nsf-nsf-access-info in Figure 2 and 240 Figure 3. 242 NSF Access Information 243 +--rw i2nsf-nsf-access-info 244 +--rw nsf-address inet:ipv4-address 245 +--rw nsf-port-address inet:port-number 247 Figure 5: High-Level YANG of I2NSF NSF Access Informantion 249 This information is used by other components to access an NSF. 251 4.6. NSF Performance Capability 253 This section expands the i2nsf-nsf-performance-caps in Figure 4. 255 NSF Performance Capability 256 +--rw i2nsf-nsf-performance-caps 257 +--rw processing 258 | +--rw processing-average uint16 259 | +--rw processing-peak uint16 260 +--rw bandwidth 261 | +--rw outbound 262 | | +--rw outbound-average uint16 263 | | +--rw outbound-peak uint16 264 | +--rw inbound 265 | | +--rw inbound-average uint16 266 | | +--rw inbound-peak uint16 268 Figure 6: High-Level YANG of I2NSF NSF Performance Capability 270 When the Security Controller requests the Developer Management System 271 to create a new NSF instance, the performance capability is used to 272 specify the performance requirements of the new instance. 274 4.7. Role-Based ACL(Access Control List) 276 This section expands the ietf-netmod-acl-model in [netmod-acl-model]. 278 Role-Based ACL 279 +--rw role-based-acl 280 uses ietf-netmod-acl-model 282 Figure 7: Role-Based ACL 284 In [netmod-acl-model], ietf-netmod-acl-model refers module ietf- 285 netmod-acl-model in [netmod-acl-model]. We add the role-based ACL 286 because it is absent in [i2nsf-capability-dm]. 288 5. YANG Modules 290 This section introduces a YANG module for the information model of 291 the required data for the registration interface between Security 292 Controller and Developer's Management System, as defined in the 293 [i2nsf-reg-inf-im]. 295 file "ietf-i2nsf-regs-interface@2018-07-02.yang" 296 module ietf-i2nsf-regs-interface { 297 namespace 298 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-regs-interface"; 299 prefix 300 regs-interface; 301 import ietf-inet-types{ 302 prefix inet; 303 } 305 organization 306 "IETF I2NSF (Interface to Network Security Functions) 307 Working Group"; 309 contact 310 "WG Web: 311 WG List: 313 WG Chair: Adrian Farrel 314 316 WG Chair: Linda Dunbar 317 319 Editor: Sangwon Hyun 320 322 Editor: Taekyun Roh 323 325 Editor: Sarang Wi 326 328 Editor: Jaehoon Paul Jeong 329 331 Editor: Jung-Soo Park 332 "; 334 description 335 "It defines a YANG data module for Registration Interface."; 336 revision "2018-07-02"{ 337 description "The second revision"; 338 reference 339 "draft-hares-i2nsf-capability-data-model-07 340 draft-hyun-i2nsf-registration-interface-im-05"; 341 } 342 list interface-container{ 343 key "interface-name"; 344 description 345 "i2nsf-reg-interface-container"; 346 leaf interface-name{ 347 type string; 348 description 349 "interface name"; 350 } 351 container i2nsf-regs-req { 352 description 353 "The capability information of newly 354 created NSF to notify its 355 capability to Security Controller"; 356 container nsf-capability-information { 357 description 358 "nsf-capability-information"; 359 uses i2nsf-nsf-capability-information; 360 } 361 container nsf-access-info { 362 description 363 "nsf-access-info"; 364 uses i2nsf-nsf-access-info; 365 } 366 container ietf-netmod-acl-model{ 367 description 368 "netmod-acl-model"; 369 uses ietf-netmod-acl-model; 370 } 371 } 372 container i2nsf-instance-mgnt-req { 373 description 374 "Required information for instanciation-request, 375 deinstanciation-request and reinstanciation-request"; 376 leaf req-level { 377 type uint16; 378 description 379 "req-level"; 380 } 381 leaf req-id { 382 type uint64; 383 mandatory true; 384 description 385 "req-id"; 386 } 387 choice req-type { 388 description 389 "req-type"; 390 case instanciation-request { 391 description 392 "instanciation-request"; 393 container in-nsf-capability-information { 394 description 395 "nsf-capability-information"; 396 uses i2nsf-nsf-capability-information; 397 } 398 } 399 case deinstanciation-request { 400 description 401 "deinstanciation-request"; 402 container de-nsf-access-info { 403 description 404 "nsf-access-info"; 405 uses i2nsf-nsf-access-info; 406 } 407 } 408 case reinstanciation-request { 409 description 410 "reinstanciation nsf's information"; 411 container re-nsf-capability-information { 412 description 413 "nsf-capability-information"; 414 uses i2nsf-nsf-capability-information; 415 } 416 } 417 } 418 } 419 } 420 grouping i2nsf-nsf-performance-caps { 421 description 422 "NSF performance capailities"; 423 container processing{ 424 description 425 "processing info"; 426 leaf processing-average{ 427 type uint16; 428 description 429 "processing-average"; 430 } 431 leaf processing-peak{ 432 type uint16; 433 description 434 "processing peak"; 435 } 436 } 437 container bandwidth{ 438 description 439 "bandwidth info"; 440 container inbound{ 441 description 442 "inbound"; 443 leaf inbound-average{ 444 type uint16; 445 description 446 "inbound-average"; 447 } 448 leaf inbound-peak{ 449 type uint16; 450 description 451 "inbound-peak"; 452 } 453 } 454 container outbound{ 455 description 456 "outbound"; 457 leaf outbound-average{ 458 type uint16; 459 description 460 "outbound-average"; 461 } 462 leaf outbound-peak{ 463 type uint16; 464 description 465 "outbound-peak"; 466 } 467 } 468 } 469 } 470 grouping i2nsf-nsf-capability-information { 471 description 472 "Detail information of an NSF"; 473 container performance-capability { 474 uses i2nsf-nsf-performance-caps; 475 description 476 "performance-capability"; 477 } 478 container i2nsf-capability { 479 description 480 "It refers draft-hares-i2nsf-capability-data-model-07.txt 481 later"; 482 } 483 } 484 grouping ietf-netmod-acl-model { 485 description 486 "Detail information"; 487 container role-based-acl { 488 description 489 "It refers draft-ietf-netmod-acl-model-15.txt 490 later"; 491 } 492 } 493 grouping i2nsf-nsf-access-info { 494 description 495 "NSF access information"; 496 leaf nsf-address { 497 type inet:ipv4-address; 498 mandatory true; 499 description 500 "nsf-address"; 501 } 502 leaf nsf-port-address { 503 type inet:port-number; 504 description 505 "nsf-port-address"; 506 } 507 } 508 } 510 512 Figure 8: Data Model of I2NSF Registration Interface 514 5.1. XML Example of Registration Interface Data Model 516 Requirement: Registering the IDS NSF with VoIP/VoLTE security 517 capability using Registration interface. 519 Here is the configuration xml for this Registration Interface: 521 522 523 524 525 526 527 528 529 530 531 532 1 533 534 535 536 true 537 538 ids-service 539 540 541 542 true 543 544 545 ips-service 546 547 548 549 550 551 552 553 554 555 1000 556 5000 557 558 559 560 1000 561 5000 563 564 565 1000 566 5000 567 568 569 570 571 572 10.0.0.1 573 145 574 575 576 577 578 580 Figure 9: Registration Interface example 582 6. Security Considerations 584 The information model of the registration interface is based on the 585 I2NSF framework without any architectural changes. Thus, this 586 document shares the security considerations of the I2NSF framwork 587 architecture that are specified in [RFC8329] for the purpose of 588 achieving secure communication among components in the proposed 589 architecture. 591 7. Acknowledgments 593 This work was supported by Institute for Information & communications 594 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 595 (No.R-20160222-002755, Cloud based Security Intelligence Technology 596 Development for the Customized Security Service Provisioning). 598 8. References 600 8.1. Normative References 602 [RFC2119] Bradner, S., "Key words for use in RFCs toIndicate 603 Requirement Levels", RFC 2119, March 1997. 605 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 606 Network Configuration Protocol (NETCONF)", RFC 6020, 607 October 2010. 609 8.2. Informative References 611 [capability-im] 612 Xia, L., Strassner, J., Basile, C., and D. Lopez, 613 "Information Model of NSFs Capabilities", draft-i2nsf- 614 capability-00 (work in progress), September 2017. 616 [i2nsf-capability-dm] 617 Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, 618 "I2NSF Capability YANG Data Model", draft-hares-i2nsf- 619 capability-data-model-07 (work in progress), March 2018. 621 [i2nsf-reg-inf-im] 622 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 623 Registration Interface Information Model", draft-hyun- 624 i2nsf-registration-interface-im-04 (work in progress), 625 October 2017. 627 [i2nsf-terminology] 628 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 629 Birkholz, "Interface to Network Security Functions (I2NSF) 630 Terminology", draft-ietf-i2nsf-terminology-05 (work in 631 progress), January 2018. 633 [i2rs-rib-data-model] 634 Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 635 S., and N. Bahadur, "A YANG Data Model for Routing 636 Information Base (RIB)", draft-ietf-i2rs-rib-data-model-10 637 (work in progress), February 2018. 639 [netmod-acl-model] 640 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 641 "Network Access Control List (ACL) YANG Data Model", 642 draft-ietf-netmod-acl-model-16 (work in progress), 643 February 2018. 645 [nsf-triggered-steering] 646 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 647 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 648 i2nsf-nsf-triggered-steering-05 (work in progress), March 649 2018. 651 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 652 Kumar, "Framework for Interface to Network Security 653 Functions", RFC 8329, February 2018. 655 [supa-policy-data-model] 656 Halpern, J., Strassner, J., and S. van der Meer, "Generic 657 Policy Data Model for Simplified Use of Policy 658 Abstractions (SUPA)", draft-ietf-supa-generic-policy-data- 659 model-04 (work in progress), June 2017. 661 [supa-policy-info-model] 662 Strassner, J., Halpern, J., and S. van der Meer, "Generic 663 Policy Information Model for Simplified Use of Policy 664 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 665 model-03 (work in progress), May 2017. 667 Appendix A. Changes from draft-hyun-i2nsf-registration-interface-dm-03 669 The following changes are made from draft-hyun-i2nsf-registration- 670 interface-dm-03: 672 o We added Re-instantiation item. 674 o The references were updated to reflect the latest documents. 676 Authors' Addresses 678 Sangwon Hyun 679 Department of Computer Engineering 680 Chosun University 681 309, Pilmun-daero, Dong-gu 682 Gwangju, Jeollanam-do 61452 683 Republic of Korea 685 EMail: shyun@chosun.ac.kr 687 Jaehoon Paul Jeong 688 Department of Software 689 Sungkyunkwan University 690 2066 Seobu-Ro, Jangan-Gu 691 Suwon, Gyeonggi-Do 16419 692 Republic of Korea 694 Phone: +82 31 299 4957 695 Fax: +82 31 290 7996 696 EMail: pauljeong@skku.edu 697 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 699 Taekyun Roh 700 Electrical Computer Engineering 701 Sungkyunkwan University 702 2066 Seobu-Ro, Jangan-Gu 703 Suwon, Gyeonggi-Do 16419 704 Republic of Korea 706 Phone: +82 31 290 7222 707 Fax: +82 31 299 6673 708 EMail: tkroh0198@skku.edu 709 URI: http://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57 710 Sarang Wi 711 Electrical Computer Engineering 712 Sungkyunkwan University 713 2066 Seobu-Ro, Jangan-Gu 714 Suwon, Gyeonggi-Do 16419 715 Republic of Korea 717 Phone: +82 31 290 7222 718 Fax: +82 31 299 6673 719 EMail: dnl9795@skku.edu 720 URI: http://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57 722 Jung-Soo Park 723 Electronics and Telecommunications Research Institute 724 218 Gajeong-Ro, Yuseong-Gu 725 Daejeon 305-700 726 Republic of Korea 728 Phone: +82 42 860 6514 729 EMail: pjs@etri.re.kr