idnits 2.17.1 draft-hyun-i2nsf-registration-interface-dm-03.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 238 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 (March 5, 2018) is 2215 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 J. Jeong 4 Intended status: Standards Track T. Roh 5 Expires: September 6, 2018 S. Wi 6 Sungkyunkwan University 7 J. Park 8 ETRI 9 March 5, 2018 11 I2NSF Registration Interface YANG Data Model 12 draft-hyun-i2nsf-registration-interface-dm-03 14 Abstract 16 This document describes an YANG data model for I2NSF registration 17 interface between Security Controller and Developer's Management 18 System. The data model is required for NSF instance registration and 19 dynamic life cycle management of NSF instances. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 6, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 59 4. High-Level YANG . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Registration Interface . . . . . . . . . . . . . . . . . 4 61 4.2. Registration Request . . . . . . . . . . . . . . . . . . 4 62 4.3. Instance Management Request . . . . . . . . . . . . . . . 5 63 4.4. NSF Capability Information . . . . . . . . . . . . . . . 5 64 4.5. NSF Access Information . . . . . . . . . . . . . . . . . 6 65 4.6. NSF Performance Capability . . . . . . . . . . . . . . . 6 66 4.7. Role-Based ACL(Access Control List) . . . . . . . . . . . 6 67 5. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. XML Example of Registration Interface Data Model . . . . 11 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 73 8.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Appendix A. Changes from draft-hyun-i2nsf-registration- 75 interface-dm-02 . . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 This document provides a YANG [RFC6020] data model that defines the 81 required data for the registration interface between Security 82 Controller and Developer's Management System to dynamically manage a 83 pool of NSF instances. This document defines a YANG data model based 84 on the [i2nsf-reg-inf-im]. The terms used in this document are 85 defined in [i2nsf-terminology]. 87 2. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Terminology 95 This document uses the terminology described in [i2nsf-terminology], 96 [capability-im], [RFC8329], [nsf-triggered-steering], 97 [supa-policy-data-model], and [supa-policy-info-model]. 99 o Network Security Function (NSF): A function that is responsible 100 for specific treatment of received packets. A Network Security 101 Function can act at various layers of a protocol stack (e.g., at 102 the network layer or other OSI layers). Sample Network Security 103 Service Functions are as follows: Firewall, Intrusion Prevention/ 104 Detection System (IPS/IDS), Deep Packet Inspection (DPI), 105 Application Visibility and Control (AVC), network virus and 106 malware scanning, sandbox, Data Loss Prevention (DLP), Distributed 107 Denial of Service (DDoS) mitigation and TLS proxy. 108 [nsf-triggered-steering] 110 o Advanced Inspection/Action: As like the I2NSF information model 111 for NSF facing interface [capability-im], Advanced Inspection/ 112 Action means that a security function calls another security 113 function for further inspection based on its own inspection 114 result. [nsf-triggered-steering] 116 o Network Security Function Profile (NSF Capability Information): 117 NSF Capability Information specifies the inspection capabilities 118 of the associated NSF instance. Each NSF instance has its own NSF 119 Capability Information to specify the type of security service it 120 provides and its resource capacity etc. [nsf-triggered-steering] 122 o Data Model: A data model is a representation of concepts of 123 interest to an environment in a form that is dependent on data 124 repository, data definition language, query language, 125 implementation language, and protocol. [supa-policy-info-model] 127 o Information Model: An information model is a representation of 128 concepts of interest to an environment in a form that is 129 independent of data repository, data definition language, query 130 language, implementation language, and protocol. 131 [supa-policy-info-model] 133 3.1. Tree Diagrams 135 A simplified graphical representation of the data model is used in 136 this document. The meaning of the symbols in these diagrams 137 [i2rs-rib-data-model] is as follows: 139 Brackets "[" and "]" enclose list keys. 141 Abbreviations before data node names: "rw" means configuration 142 (read-write) and "ro" state data (read-only). 144 Symbols after data node names: "?" means an optional node and "*" 145 denotes a "list" and "leaf-list". 147 Parentheses enclose choice and case nodes, and case nodes are also 148 marked with a colon (":"). 150 Ellipsis ("...") stands for contents of subtrees that are not 151 shown. 153 4. High-Level YANG 155 This section provides an overview of the high level YANG. 157 4.1. Registration Interface 159 module : ietf-i2nsf-regs-interface-model 160 +--rw regs-req 161 | uses i2nsf-regs-req 162 +--rw instance-mgnt-req 163 | uses i2nsf-instance-mgnt-req 165 Figure 1: High-Level YANG of I2NSF Registration Interface 167 Each of these sections mirror sections of [i2nsf-reg-inf-im]. 169 4.2. Registration Request 171 This section expands the i2nsf-regs-req in Figure 1. 173 Registration Request 174 +--rw i2nsf-regs-req 175 +--rw nsf-capability-information 176 | uses i2nsf-nsf-capability-information 177 +--rw nsf-access-info 178 | uses i2nsf-nsf-access-info 180 Figure 2: High-Level YANG of I2NSF Registration Request 182 Registration Request contains the capability information of newly 183 created NSF to notify its capability to Security Controller. The 184 request also contains Network Access Information so that the Security 185 Controller can access the NSF. 187 4.3. Instance Management Request 189 This section expands the i2nsf-instance-mgnt-req in Figure 1. 191 Instance Management Request 192 +--rw i2nsf-instance-mgnt-req 193 +--rw req-level uint16 194 +--rw req-id uint64 195 +--rw (req-type)? 196 +--rw (instanciation-request) 197 +--rw nsf-capability-information 198 | uses i2nsf-nsf-capability-information 199 +--rw (deinstanciation-request) 200 +--rw nsf-access-info 201 | uses i2nsf-nsf-access-info 203 Figure 3: High-Level YANG of I2NSF Instance Mgnt Request 205 Instance management request consists of two types: instanciation- 206 request and deinstanciation-request. The instanciation-request is 207 used to request generation of a new NSF instance with NSF Capability 208 Information which specifies required NSF capability information. The 209 deinstanciation-request is used to remove an existing NSF with NSF 210 Access Information. 212 4.4. NSF Capability Information 214 This section expands the i2nsf-nsf-capability-information in Figure 2 215 and Figure 3. 217 NSF Capability Information 218 +--rw i2nsf-nsf-capability-information 219 +--rw i2nsf-capability 220 | uses ietf-i2nsf-capability 221 +--rw performance-capability 222 | uses i2nsf-nsf-performance-caps 224 Figure 4: High-Level YANG of I2NSF NSF Capability Information 226 In Figure 4, ietf-i2nsf-capability refers module ietf-i2nsf- 227 capability in [i2nsf-capability-dm]. We add the performance 228 capability because it is absent in [i2nsf-capability-dm] and 229 [netmod-acl-model] 231 4.5. NSF Access Information 233 This section expands the i2nsf-nsf-access-info in Figure 2 and 234 Figure 3. 236 NSF Access Information 237 +--rw i2nsf-nsf-access-info 238 +--rw nsf-address inet:ipv4-address 239 +--rw nsf-port-address inet:port-number 241 Figure 5: High-Level YANG of I2NSF NSF Access Informantion 243 This information is used by other components to access an NSF. 245 4.6. NSF Performance Capability 247 This section expands the i2nsf-nsf-performance-caps in Figure 4. 249 NSF Performance Capability 250 +--rw i2nsf-nsf-performance-caps 251 +--rw processing 252 | +--rw processing-average uint16 253 | +--rw processing-peak uint16 254 +--rw bandwidth 255 | +--rw outbound 256 | | +--rw outbound-average uint16 257 | | +--rw outbound-peak uint16 258 | +--rw inbound 259 | | +--rw inbound-average uint16 260 | | +--rw inbound-peak uint16 262 Figure 6: High-Level YANG of I2NSF NSF Performance Capability 264 When the Security Controller requests the Developer Management System 265 to create a new NSF instance, the performance capability is used to 266 specify the performance requirements of the new instance. 268 4.7. Role-Based ACL(Access Control List) 270 This section expands the ietf-netmod-acl-model in [netmod-acl-model]. 272 Role-Based ACL 273 +--rw role-based-acl 274 uses ietf-netmod-acl-model 276 Figure 7: Role-Based ACL 278 In [netmod-acl-model], ietf-netmod-acl-model refers module ietf- 279 netmod-acl-model in [netmod-acl-model]. We add the role-based ACL 280 because it is absent in [i2nsf-capability-dm]. 282 5. YANG Modules 284 This section introduces a YANG module for the information model of 285 the required data for the registration interface between Security 286 Controller and Developer's Management System, as defined in the 287 [i2nsf-reg-inf-im]. 289 file "ietf-i2nsf-regs-interface@2018-03-05.yang" 290 module ietf-i2nsf-regs-interface { 291 namespace 292 "urn:ietf:params:xml:ns:yang:ietf-i2nsf-regs-interface"; 293 prefix 294 regs-interface; 296 import ietf-inet-types{ 297 prefix inet; 298 } 300 organization 301 "IETF I2NSF (Interface to Network Security Functions) 302 Working Group"; 304 contact 305 "WG Web: 306 WG List: 308 WG Chair: Adrian Farrel 309 311 WG Chair: Linda Dunbar 312 314 Editor: Sangwon Hyun 315 317 Editor: Taekyun Roh 318 320 Editor: Sarang Wi 321 323 Editor: Jaehoon Paul Jeong 324 325 Editor: Jung-Soo Park 326 "; 328 description 329 "It defines a YANG data module for Registration Interface."; 330 revision "2018-03-05"{ 331 description "The second revision"; 332 reference 333 "draft-hares-i2nsf-capability-data-model-03 334 draft-hyun-i2nsf-registration-interface-im-04"; 335 } 337 grouping i2nsf-nsf-performance-caps { 338 description 339 "NSF performance capailities"; 340 container processing{ 341 description 342 "processing info"; 343 leaf processing-average{ 344 type uint16; 345 description 346 "processing-average"; 347 } 348 leaf processing-peak{ 349 type uint16; 350 description 351 "processing peak"; 352 } 353 } 355 container bandwidth{ 356 description 357 "bandwidth info"; 358 container inbound{ 359 description 360 "inbound"; 361 leaf inbound-average{ 362 type uint16; 363 description 364 "inbound-average"; 365 } 366 leaf inbound-peak{ 367 type uint16; 368 description 369 "inbound-peak"; 370 } 371 } 372 container outbound{ 373 description 374 "outbound"; 375 leaf outbound-average{ 376 type uint16; 377 description 378 "outbound-average"; 379 } 380 leaf outbound-peak{ 381 type uint16; 382 description 383 "outbound-peak"; 384 } 385 } 386 } 387 } 389 grouping i2nsf-nsf-capability-information { 390 description 391 "Detail information of an NSF"; 392 container performance-capability { 393 uses i2nsf-nsf-performance-caps; 394 description 395 "performance-capability"; 396 } 398 container i2nsf-capability { 399 description 400 "It refers draft-hares-i2nsf-capability-data-model-04.txt 401 later"; 402 } 403 } 405 grouping ietf-netmod-acl-model { 406 description 407 "Detail information"; 408 container role-based-acl { 409 description 410 "It refers draft-ietf-netmod-acl-model-15.txt 411 later"; 412 } 413 } 415 grouping i2nsf-nsf-access-info { 416 description 417 "NSF access information"; 418 leaf nsf-address { 419 type inet:ipv4-address; 420 mandatory true; 421 description 422 "nsf-address"; 423 } 425 leaf nsf-port-address { 426 type inet:port-number; 427 description 428 "nsf-port-address"; 429 } 430 } 432 grouping i2nsf-regs-req { 433 description 434 "The capability information of newly 435 created NSF to notify its 436 capability to Security Controller"; 437 container nsf-capability-information { 438 description 439 "nsf-capability-information"; 440 uses i2nsf-nsf-capability-information; 441 } 443 container nsf-access-info { 444 description 445 "nsf-access-info"; 446 uses i2nsf-nsf-access-info; 447 } 448 } 450 grouping i2nsf-instance-mgnt-req { 451 description 452 "Required information for instanceiation-request and 453 deinstanciation-request"; 454 leaf req-level { 455 type uint16; 456 description 457 "req-level"; 458 } 460 leaf req-id { 461 type uint64; 462 mandatory true; 463 description 464 "req-id"; 465 } 467 choice req-type { 468 description 469 "req-type"; 470 case instanciation-request { 471 description 472 "instanciation-request"; 473 container nsf-capability-information { 474 description 475 "nsf-capability-information"; 476 uses i2nsf-nsf-capability-information; 477 } 478 } 480 case deinstanciation-request { 481 description 482 "deinstanciation-request"; 483 container nsf-access-info { 484 description 485 "nsf-access-info"; 486 uses i2nsf-nsf-access-info; 487 } 488 } 489 } 490 } 491 } 493 495 Figure 8: Data Model of I2NSF Registration Interface 497 5.1. XML Example of Registration Interface Data Model 499 Requirement: Registering the IDS NSF with VoIP/VoLTE security 500 capability using Registration interface. 502 Here is the configuration xml for this Registration Interface: 504 505 506 507 508 509 510 511 512 513 514 515 1 516 517 518 519 true 520 521 ids-service 522 523 524 525 true 526 527 528 ips-service 529 530 531 532 533 534 535 536 537 538 1000 539 5000 540 541 542 543 1000 544 5000 545 546 547 1000 548 5000 549 550 551 552 553 554 10.0.0.1 555 145 556 557 558 559 560 562 Figure 9: Registration Interface example 564 6. Security Considerations 566 The information model of the registration interface is based on the 567 I2NSF framework without any architectural changes. Thus, this 568 document shares the security considerations of the I2NSF framwork 569 architecture that are specified in [RFC8329] for the purpose of 570 achieving secure communication among components in the proposed 571 architecture. 573 7. Acknowledgments 575 This work was supported by Institute for Information & communications 576 Technology Promotion(IITP) grant funded by the Korea government(MSIP) 577 (No.R-20160222-002755, Cloud based Security Intelligence Technology 578 Development for the Customized Security Service Provisioning). 580 8. References 582 8.1. Normative References 584 [RFC2119] Bradner, S., "Key words for use in RFCs toIndicate 585 Requirement Levels", RFC 2119, March 1997. 587 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 588 Network Configuration Protocol (NETCONF)", RFC 6020, 589 October 2010. 591 8.2. Informative References 593 [capability-im] 594 Xia, L., Strassner, J., Basile, C., and D. Lopez, 595 "Information Model of NSFs Capabilities", draft-i2nsf- 596 capability-00 (work in progress), September 2017. 598 [i2nsf-capability-dm] 599 Hares, S., Jeong, J., Kim, J., Moskowitz, R., and Q. Lin, 600 "I2NSF Capability YANG Data Model", draft-hares-i2nsf- 601 capability-data-model-06 (work in progress), March 2018. 603 [i2nsf-reg-inf-im] 604 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF 605 Registration Interface Information Model", draft-hyun- 606 i2nsf-registration-interface-im-04 (work in progress), 607 October 2017. 609 [i2nsf-terminology] 610 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 611 Birkholz, "Interface to Network Security Functions (I2NSF) 612 Terminology", draft-ietf-i2nsf-terminology-05 (work in 613 progress), January 2018. 615 [i2rs-rib-data-model] 616 Wang, L., Chen, M., Dass, A., Ananthakrishnan, H., Kini, 617 S., and N. Bahadur, "A YANG Data Model for Routing 618 Information Base (RIB)", draft-ietf-i2rs-rib-data-model-10 619 (work in progress), February 2018. 621 [netmod-acl-model] 622 Jethanandani, M., Huang, L., Agarwal, S., and D. Blair, 623 "Network Access Control List (ACL) YANG Data Model", 624 draft-ietf-netmod-acl-model-16 (work in progress), 625 February 2018. 627 [nsf-triggered-steering] 628 Hyun, S., Jeong, J., Park, J., and S. Hares, "Service 629 Function Chaining-Enabled I2NSF Architecture", draft-hyun- 630 i2nsf-nsf-triggered-steering-05 (work in progress), March 631 2018. 633 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R. 634 Kumar, "Framework for Interface to Network Security 635 Functions", RFC 8329, February 2018. 637 [supa-policy-data-model] 638 Halpern, J., Strassner, J., and S. van der Meer, "Generic 639 Policy Data Model for Simplified Use of Policy 640 Abstractions (SUPA)", draft-ietf-supa-generic-policy-data- 641 model-04 (work in progress), June 2017. 643 [supa-policy-info-model] 644 Strassner, J., Halpern, J., and S. van der Meer, "Generic 645 Policy Information Model for Simplified Use of Policy 646 Abstractions (SUPA)", draft-ietf-supa-generic-policy-info- 647 model-03 (work in progress), May 2017. 649 Appendix A. Changes from draft-hyun-i2nsf-registration-interface-dm-02 651 The following changes are made from draft-hyun-i2nsf-registration- 652 interface-dm-02: 654 o We updated the name of NSF profile to NSF capability information 655 and contents. 657 o We added role-based ACL. 659 o The description of a YANG data module for Registration Interface 660 was updated. 662 o The references were updated to reflect the latest documents. 664 Authors' Addresses 666 Sangwon Hyun 667 Department of Software 668 Sungkyunkwan University 669 2066 Seobu-Ro, Jangan-Gu 670 Suwon, Gyeonggi-Do 16419 671 Republic of Korea 673 Phone: +82 31 290 7222 674 Fax: +82 31 299 6673 675 EMail: swhyun77@skku.edu 676 URI: http://imtl.skku.ac.kr/ 678 Jaehoon Paul Jeong 679 Department of Software 680 Sungkyunkwan University 681 2066 Seobu-Ro, Jangan-Gu 682 Suwon, Gyeonggi-Do 16419 683 Republic of Korea 685 Phone: +82 31 299 4957 686 Fax: +82 31 290 7996 687 EMail: pauljeong@skku.edu 688 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php 689 Taekyun Roh 690 Electrical Computer Engineering 691 Sungkyunkwan University 692 2066 Seobu-Ro, Jangan-Gu 693 Suwon, Gyeonggi-Do 16419 694 Republic of Korea 696 Phone: +82 31 290 7222 697 Fax: +82 31 299 6673 698 EMail: tkroh0198@skku.edu 699 URI: http://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57 701 Sarang Wi 702 Electrical Computer Engineering 703 Sungkyunkwan University 704 2066 Seobu-Ro, Jangan-Gu 705 Suwon, Gyeonggi-Do 16419 706 Republic of Korea 708 Phone: +82 31 290 7222 709 Fax: +82 31 299 6673 710 EMail: dnl9795@skku.edu 711 URI: http://imtl.skku.ac.kr/xe/index.php?mid=board_YoKq57 713 Jung-Soo Park 714 Electronics and Telecommunications Research Institute 715 218 Gajeong-Ro, Yuseong-Gu 716 Daejeon 305-700 717 Republic of Korea 719 Phone: +82 42 860 6514 720 EMail: pjs@etri.re.kr