idnits 2.17.1 draft-xie-i2nsf-demo-outline-design-00.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 Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 309 has weird spacing: '...forming ass...' == Line 757 has weird spacing: '... ufw allow|...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 29, 2015) is 3278 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: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'I-D.dunbar-i2nsf-problem-statement' on line 842 looks like a reference -- Missing reference section? 'RFC2119' on line 812 looks like a reference -- Missing reference section? 'RFC4741' on line 815 looks like a reference -- Missing reference section? 'RFC5277' on line 818 looks like a reference -- Missing reference section? 'RFC6020' on line 821 looks like a reference -- Missing reference section? 'INCITS359 RBAC' on line 827 looks like a reference -- Missing reference section? 'I-D.zarny-i2nsf-data-center-use-cases' on line 831 looks like a reference -- Missing reference section? 'I-D.qi-i2nsf-access-network-usecase' on line 834 looks like a reference -- Missing reference section? 'I-D.pastor-i2nsf-access-usecases' on line 838 looks like a reference -- Missing reference section? 'I-D.xia-i2nsf-capability-interface-im' on line 846 looks like a reference -- Missing reference section? 'I-D.strassner-i2nfs-info-model' on line 850 looks like a reference -- Missing reference section? 'I-D.xia-i2nsf-service-interface-dm' on line 854 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 I2NSF 2 Internet Draft Y. Xie 3 Intended status: Informational L. Xia 4 J. Wu 5 Huawei 7 Expires: October 29 2015 April 29, 2015 9 Interface to Network Security Functions Demo Outline Design 10 draft-xie-i2nsf-demo-outline-design-00.txt 12 Abstract 14 This document describes the outline design of an Interface to 15 network Security Functions (I2NSF) demo, aim to enhance 16 understanding of the I2NSF architecture and justify its feasibility. 17 The I2NSF demo enables the interaction between I2NSF client, I2NSF 18 controller and NSF/vNSF by using NETCONF protocol and YANG model. 19 The advantage of it is to ensure that such demo outline design will 20 be able to share and reuse consensually designed functions, thereby 21 increasing interoperability. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on October 29, 2015. 46 `Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with 56 respect to this document. Code Components extracted from this 57 document must include Simplified BSD License text as described in 58 Section 4.e of the Trust Legal Provisions and are provided without 59 warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction ................................................ 3 64 2. Conventions used in this document ........................... 3 65 2.1. Terminology ............................................ 3 66 3. Design of the I2NSF Demo .................................... 4 67 3.1. Overall architecture description ....................... 4 68 3.1.1. I2NSF Workflow .................................... 6 69 3.2. I2NSF Client ........................................... 8 70 3.2.1. I2NSF Service API Format .......................... 9 71 3.2.2. I2NSF Client Sub-module Design .................... 9 72 3.3. I2NSF Controller ....................................... 11 73 3.3.1. Service-oriented I2NSF Agent ...................... 11 74 3.3.2. Service2Functional Translator ..................... 12 75 3.3.2.1. Data in the database ......................... 12 76 3.3.2.2. Service2Functional KEY Mapping ............... 13 77 3.3.2.3. Service2Functional Value Mapping ............. 13 78 3.3.3. Functional-oriented I2NSF Client .................. 13 79 3.4. NSF/vNSF ............................................... 15 80 3.4.1. Functional-oriented I2NSF Agent ................... 15 81 3.4.2. Functional2Vendor Translator ...................... 16 82 3.4.3. Vendor Specific Command ........................... 18 83 4. Transport Protocol .......................................... 18 84 4.1. Protocol between Client, Controller, and NSF/vNSF ...... 18 85 5. YANG model .................................................. 18 86 6. Security Considerations ..................................... 18 87 7. IANA Considerations ......................................... 18 88 8. References .................................................. 19 89 8.1. Normative References ................................... 19 90 8.2. Informative References ................................. 19 91 9. Acknowledgments ............................................. 20 93 1. Introduction 95 A standard interface to express, monitor, and manage security 96 policies for physical and virtual distributed security functions 97 that may be running on different premises is increasingly demanded 98 by Enterprises, residential, and mobile customers. The Interface to 99 Network Security Functions (I2NSF) whose ultimate goal is to 100 establish how to communicate with vNSF and how to get performance 101 data or report out of vNSF well satisfies the demands. 103 Derived from [I-D.dunbar-i2nsf-problem-statement], it should have 104 two types of I2NSF interface to consider: first, interface between 105 I2NSF user/client and network controller (Service-oriented API), 106 second, north-bound interface (Functional-oriented API) provided by 107 the network security functions (NSFs) [I-D.xia-i2nsf-capability- 108 interface-im]. 110 This draft is focused on the outline design of an I2NSF demo 111 including the design of I2NSF client, I2NSF controller and NSF/vNSF. 112 NETCONF protocol and YANG model are used for the I2NSF demo 113 realization. The demo aims to enhance understanding of the I2NSF 114 architecture and justify its feasibility. Section 3 describes 115 outline design of I2NSF demo. Section 4 describes protocol between 116 Client, Controller, and NSF/vNSF. Section 5 gives an example 117 definition of the Service-oriented API and Functional-oriented API 118 by YANG model. 120 2. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC-2119 [RFC2119]. 126 2.1. Terminology 128 I2NSF - Interface to Network Security Functions 130 NETCONF - Network Configuration Protocol 132 YANG - a data modeling language for the NETCONF network 133 configuration protocol 135 RPC - Remote Procedure Control 137 SSH - Secure Shell 139 NSF - Network Security Function 140 vNSF - virtual Network Security Function 142 DB - Database 144 FW - Firewall 146 Shorewall - It is an open source firewall tool for Linux that builds 147 upon the Netfilter (iptables / ipchains) system built into the Linux 148 kernel 150 UFW - Uncomplicated Firewall 152 VM - Virtual Machine 154 3. Design of the I2NSF Demo 156 This section describes the design of the I2NSF demo. It first 157 provides an architectural overview of the demo. Then, specific 158 design of Client, Controller and NSF/vNSF is presented. 160 3.1. Overall architecture description 161 +-----------------------+ 162 | | 163 | I2NSF Client | 164 | | 165 +-----------------------+ 166 | Service-Oriented 167 | interface 168 | 169 NETCONF | 170 +-------------------------+ 171 |I2NSF Controller | 172 |+---------------+ | 173 ||Service-oriente| | 174 || d I2NSF Agent | | 175 || | | 176 |+---------------+ | 177 |+---------------+ +--+| 178 ||Service2Functio| | || 179 ||nal Translator |<-->|DB|| 180 || | | || 181 |+---------------+ +--+| 182 |+---------------+ | 183 ||Functional-orie| | 184 || nted I2NSF | | 185 || Client | | 186 |+---------------+ | 187 | | 188 +-------------------------+ 189 | 190 | 191 | 192 ---------------------------------------- 193 |Functional- |Functional- 194 | Oriented | Oriented 195 | interface | interface 196 NETCONF | NETCONF | 197 +---------------------------+ +---------------------------+ 198 |Uncomplicated FW | |Shorewall | 199 |+---------------+ | |+---------------+ | 200 ||Functional-orie| | ||Functional-orie| | 201 || nted I2NSF | | || nted I2NSF | | 202 || Agent | | || Agent | | 203 |+---------------+ | |+---------------+ | 204 |+---------------+ +----+| |+---------------+ +----+| 205 ||Functional2Vend| | || ||Functional2Vend| | || 206 || or Translator |<-->|Dict|| || or Translator |<-->|Dict|| 207 || | | || || | | || 208 |+---------------+ +----+| |+---------------+ +----+| 209 |+---------------+ | |+---------------+ | 210 ||Vendor Specific| | ||Vendor Specific| | 211 || Command | | || Command | | 212 || | | || | | 213 |+---------------+ | |+---------------+ | 214 | | | | 215 +---------------------------+ +---------------------------+ 216 Figure 1. Overall Architecture 218 The I2NSF demo architecture and its basic functions are as follows: 220 1) Input configuration policy in the command line module of I2NSF 221 Client; 223 2) I2NSF Service API parameters are composed according to YANG model; 225 3) Represent the composed I2NSF Service API parameters by XML; 227 4) Reliable and ordered data transmission supported by NETCONF 228 protocol; 230 5) Receive data in NETCONF module of I2NSF Controller; 232 6) Transform Service API into Functional API in adapter module of 233 I2NSF Controller; 234 7) Construct YANG model with Functional API parameters, and transmit 235 the data by NETCONF protocol; 237 8) Receive data in NETCONF module of NSF/vNSF; 239 9) Fetch I2NSF Functional API parameter values in YANG model deposed 240 module of NSF/vNSF; 242 10) Match API KEY with different vendor FW KEY in KEY mapping module 243 (aka Dict) of NSF/vNSF; 245 11) IP address mapping and MAC address mapping in Value mapping 246 module of NSF/vNSF; 248 12) Different vendor FW parameters are assembled into command line 249 form in command assembling module of NSF/vNSF; 251 13) Send Vendor specific command in sequence in command send module 252 of NSF/vNSF; 254 3.1.1. I2NSF Workflow 256 + 257 Client + Controller 258 + 259 + 260 + 261 Terminal Command Encapsulate + YANG model 262 send parsing into YANG + parsing 263 message model + 264 + 265 | | | + | 266 | | | + | 267 | | | + | 268 |------------->| | + | 269 | | | + | 270 | | | + | 271 | |------------->| + | 272 | | | + | 273 | | | By netconf | 274 | | |------------->| 275 | | | + | 276 | | | + | 277 | | | + | 278 | | | + | 279 | | | + | 280 + 281 + 282 Controller + NSF/vNSF 283 + 284 + 285 + 286 YANG Semantics Parameters YANG model + YANG model 287 model reading mapping encapsulating + parsing 288 parsing + 289 + 290 | | | | + | 291 | | | | + | 292 | | | | + | 293 |------------->| | | + | 294 | | | | + | 295 | | | | + | 296 | |------------->| | + | 297 | | | | + | 298 | | | | + | 299 | | |------------->| + | 300 | | | | + | 301 | | | | By netconf | 302 | | | |------------->| 303 | | | | + | 304 | | | | + | 305 + 306 NSF/vNSF 308 YANG Semantics Parameter FW command FW command 309 model reading transforming assembling sending 310 parsing 312 | | | | | 313 | | | | | 314 | | | | | 315 |------------->| | | | 316 | | | | | 317 | | | | | 318 | |------------->| | | 319 | | | | | 320 | | | | | 321 | | |------------->| | 322 | | | | | 323 | | | | | 324 | | | |------------->| 325 | | | | | 326 | | | | | 327 Figure 2. I2NSF Workflow 329 3.2. I2NSF Client 331 +--------------------------------------+ 332 | I2NSF Client | 333 | | 334 | +-------------+ +-------------+ | 335 | |Command line | |Command line | | 336 | | input | | display | | 337 | +-------------+ +-------------+ | 338 | | | | 339 | +-------------+ +-------------+ | 340 | | Semantics | | Contents | | 341 | | reading | | translation | | 342 | +-------------+ +-------------+ | 343 | | | | 344 | +-------------+ +-------------+ | 345 | |YANG modeling| |YANG modeling| | 346 | | language | | language | | 347 | | composed | | decomposed | | 348 | +-------------+ +-------------+ | 349 | | | | 350 | +----------------+ | 351 | | NETCONF | | 352 | +----------------+ | 353 | | | 354 +------------------|-------------------+ 355 | NETCONF 356 Figure 3. I2NSF Client Modules 358 I2NSF Client consists of seven modules: 360 1) Command line input module; 362 2) Semantics reading module; 364 3) YANG modeling language composed module; 366 4) YANG modeling language decomposed module; 368 5) Contents translation module; 370 6) Command line display module; 372 7) NETCONF module; 374 3.2.1. I2NSF Service API Format 376 A policy rule can be described as: 378 . 380 is used to uniquely identify tenant that has parameters 381 such as tenant_name and tenant_ID. The default value is NULL 383 has parameters such as Device(s), Place(s), User(s). 385 is the role of user. 387 are selected traffics that network behaviors enforced on. 389 are network behaviors enforced on selected traffic. 391 means condition for action, with parameters such as Rate, 392 Time, Timeout, Throughput, State. 394 Therein, 396 Example 1: John_0001 is allowed to access rtsp://video- 397 server/mrbean.ts. 399 = NULL 401 = John_0001 403 = marketing 405 = rtsp://video-server/mrbean.ts 407 = allow 409 = NULL 411 3.2.2. I2NSF Client Sub-module Design 413 1) Command line input module is responsible for receiving input 414 command. 416 Input: John_0001 is allowed to access rtsp://video-server/mrbean.ts 418 2) Semantics reading module is responsible for analyzing commands 419 and fetching I2NSF Service API parameter values. 421 Output: 423 = NULL 425 user_group.user.user_name= John_0001 427 role = marketing 429 object.url_group.url = rtsp://video-server/mrbean.ts 431 action = allow 433 condition = NULL 435 3) YANG modeling language composed module is responsible for 436 encapsulating I2NSF Service API parameter types and values into YANG 437 model. 439 Input: 441 = NULL 443 user_group.user.user_name= John_0001 445 role = marketing 447 object.url_group.url = rtsp://video-server/mrbean.ts 449 action = allow 451 condition = NULL 453 Output: 455 456 457 458 John_0001 459 460 461 marketing 462 463 464 rtsp://video-server/mrbean.ts 465 466 467 allow 468 469 ...... 471 4) YANG modeling language decomposed module is responsible for 472 parsing YANG model and fetching I2NSF Service API parameter types 473 and values. 475 5) Contents translation module is responsible for translating I2NSF 476 Service API parameter types and values into readable contents to 477 display. 479 6) Command line display module is responsible for displaying data 480 information from I2NSF Controller. 482 7) NETCONF module is responsible for communicating between Client 483 and Controller. 485 3.3. I2NSF Controller 487 I2NSF Controller consists of Service-oriented I2NSF Agent, 488 Service2Functional Translator, Functional-oriented I2NSF Client. 490 3.3.1. Service-oriented I2NSF Agent 492 Service-oriented I2NSF Agent consists of NETCONF module, YANG model 493 decomposed and composed modules. 495 NETCONF module is responsible for communicating with I2NSF Client. 497 YANG modeling language decomposed module parse YANG model into pairs. It can map YANG model into Service2Functional KEY. 500 Input: 502 503 504 505 John_0001 506 507 508 marketing 509 510 511 rtsp://video-server/mrbean.ts 512 513 514 allow 515 516 ...... 518 Output: 520 = NULL 522 user_group.user.user_name= John_0001 524 role = marketing 526 object.url_group.url = rtsp://video-server/mrbean.ts 528 action = allow 530 condition = NULL 532 YANG modeling language composed module encapsulate 533 pairs into YANG model. It maps Service2Functional KEY into YANG 534 model. 536 3.3.2. Service2Functional Translator 538 Service2Functional Translator does the mapping between YANG model 539 and Functional API according to the database, which means the 540 mapping between Client command and Functional API. It consists of 541 Service2Functional KEY mapping and Service2Functional Value mapping. 543 3.3.2.1. Data in the database 545 SRC_DB: "John_0001"---"192.168.1.100" 547 ACT_DB: "allow"---"permit", "deny"---"deny" 548 PROTO_DB: "rtsp://video-server/mrbean.ts"---"tcp", "rtsp://video- 549 server/france24.ts"---"tcp", "rtsp://video- 550 server/mrbean.ts,rtsp://video-server/france24.ts"---"tcp" 552 PORT_DB: "rtsp://video-server/mrbean.ts"---"554", "rtsp://video- 553 server/france24.ts"---"8554", "rtsp://video- 554 server/mrbean.ts,rtsp://video-server/france24.ts"---"554","8554" 556 DEST_DB: "rtsp://video-server/mrbean.ts"---"100.1.1.100", 557 "rtsp://video-server/france24.ts"---"100.1.1.100", "rtsp://video- 558 server/mrbean.ts,rtsp://video-server/france24.ts"---"100.1.1.100" 560 3.3.2.2. Service2Functional KEY Mapping 562 KEY lexicon deposits the correspondence between Service API and 563 Functional API. 565 Example 1: 567 569 user_group.user.user_name objects.address_group.address.src.src_ip_addr 571 object.url_group.url objects.address_group.address.dst.dst_ip_addr 573 objects.service.protocol 575 objects.service.port 577 action actions 579 3.3.2.3. Service2Functional Value Mapping 581 ValueDB deposit actual value in the network corresponding to value 582 in Service API, such as IP/MAC/URL address, protocol+ port number 583 and so on. 585 For example: 587 objects.address_group.address.src.src_ip_addr =192.168.1.1 589 3.3.3. Functional-oriented I2NSF Client 591 Functional-oriented I2NSF Client consists of YANG modeling language 592 composed module, NETCONF module, and YANG modeling language 593 decomposed module. 595 YANG modeling language composed module encapsulates actual value in 596 the network into YANG model, and then transports it to NSF/vNSF by 597 NETCONF. 599 Input 601 objects.address_group.address.src.src_ip_addr=192.168.1.1 603 objects.address_group.address.dst.dst_ip_addr=100.1.1.100 605 objects.service.protocol=tcp 607 objects.service.port=554 609 actions=permit 611 Output 613 614 615
616 617 192.168.1.1 618 619 620 100.1.1.100 621 622
623 624 625 tcp 626 554 627 628 629 permit 630 ...... 632 NETCONF module is responsible for communicating with NSF/vNSF. 634 3.4. NSF/vNSF 636 NSF/vNSF consists of Functional-oriented I2NSF Agent, 637 Functional2Vendor Translator and Vendor Specific Command. 639 3.4.1. Functional-oriented I2NSF Agent 641 Functional-oriented I2NSF Agent is responsible for communicating 642 with I2NSF Controller and the protocol used is NETCONF. It consists 643 of NETCONF module, YANG modeling language decomposed and composed 644 modules. 646 YANG modeling language decomposed module parses YANG model into pairs. 649 Input: 651 652 653
654 655 192.168.1.1 656 657 658 100.1.1.100 659 660
661 662 663 tcp 664 554 665 666 667 permit 668 ...... 670 Output: 672 674 ...... 676 YANG modeling language composed module encapsulates the 677 pairs into YANG model. 679 3.4.2. Functional2Vendor Translator 681 As the core part of the NSF/vNSF, Functional2Vendor Translator 682 comprises a) lexicon module, b) key mapping module, c) value mapping 683 module, d) command assembling module and e) message parsing module. 685 Lexicon module deposits the correspondence between the keys of YANG 686 model and the keys ruled by the specific FW syntax. 688 Example 1: Shorewall lexicon 690 692 objects.address_group.address.src.src_ip_addr SOURCE 694 objects.address_group.address.dst.dst_ip_addr DEST 696 Example 2: UFW lexicon 698 700 objects.address_group.address.src.src_ip_addr from 702 objects.address_group.address.dst.dst_ip_addr to 704 Key mapping module is responsible for the translation between the 705 keys of YANG model and the keys ruled by the FW according to the 706 lexicon module. 708 Input: 710 713 ...... 715 Output: 717 719 ...... 721 Value mapping module is responsible for the translation between the 722 values of YANG model and the values ruled by the FW. 724 For example: (Shorewall) 726 Input: 728 730 ...... 732 Output 734 736 ...... 738 Command assembling module assembles different vendors FW values into 739 command line form. 741 Shorewall command assembling format: 743 #ACTION SOURCE DEST PROTO DEST PORT(S) 745 Input 747 749 ...... 751 Output (Shorewall) 753 ACCEPT cli:192.168.1.100 ser:100.1.1.100 tcp 554 755 UFW command assembling format: 757 ufw allow|deny|reject|logging|show [proto protocol] [from ADDRESS 758 [port PORT]] [to ADDRESS [port PORT]] 760 Output (UFW): 762 ufw route allow in on eth1 out on eth2 from 192.168.1.100 to 763 100.1.1.100 port 554 proto tcp 765 Message parsing module parses the upward report commands of 766 different vendors FW into pairs. 768 3.4.3. Vendor Specific Command 770 Vendor Specific Command is responsible for communicating with FW 771 configuration policy executive layer, including the sending down 772 commands and upward report commands. 774 4. Transport Protocol 776 4.1. Protocol between Client, Controller, and NSF/vNSF 778 As shown in Figure 1, Service-oriented API connects I2NSF Client 779 with I2NSF Controller Functional-oriented API connects I2NSF 780 Controller with NSF/vNSF. 782 The protocol used in Service-oriented API and Functional-oriented 783 API is NETCONF whose protocol stack has four layers: Content, 784 Operations, RPC, and Transport [RFC4741]. The set of operations 785 includes , , , etc. The configuration 786 data and state data are separated and both of them are expressed by 787 XML. NETCONF protocol is connection-oriented and the connection 788 should provide reliable, ordered transmission. NETCONF provides the 789 fundamental programming features for comfortable and robust 790 automation of network services. 792 5. YANG model 794 YANG is a full, formal contract language with rich syntax and 795 semantics to build applications on. YANG is a NETCONF data modeling 796 language which is able to model configuration data, state data, 797 operations, and notifications. YANG definitions can directly map to 798 XML content. 800 6. Security Considerations 802 TBD 804 7. IANA Considerations 806 TBD 808 8. References 810 8.1. Normative References 812 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, March 1997. 815 [RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, 816 December 2006. 818 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", 819 RFC 5277, July 2008. 821 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 822 Network Configuration Protocol (NETCONF)", RFC 6020, 823 October 2010. 825 8.2. Informative References 827 [INCITS359 RBAC] NIST/INCITS, "American National Standard for 828 Information Technology - Role Based Access Control", 829 INCITS 359, April, 2003 831 [I-D.zarny-i2nsf-data-center-use-cases] Zarny, M., et.al., "I2NSF 832 Data Center Use Cases", Work in Progress, October 2014. 834 [I-D.qi-i2nsf-access-network-usecase] Qi, M., et.al., "Integrated 835 Security with Access Network Use Case", Work in Progress, 836 October, 2014. 838 [I-D.pastor-i2nsf-access-usecases] Pastor, A., et.al., "Access Use 839 Cases for an Open OAM Interface to Virtualized Security 840 Services", Work in Progress, October, 2014. 842 [I-D.dunbar-i2nsf-problem-statement] Dunbar, L., et.al., "Interface 843 to Network Security Functions Problem Statement", Work in 844 Progress, September, 2014. 846 [I-D.xia-i2nsf-capability-interface-im] Liang Xia, "Information 847 Model of Interface to Network Security Functions 848 Capability Interface", Work in Progress, January, 2015. 850 [I-D.strassner-i2nfs-info-model] Strassner, et.al., "Interface to 851 Network Security Functions Information Model", February, 852 2015. 854 [I-D.xia-i2nsf-service-interface-dm] Liang Xia, et.al., "Data Model 855 of Interface to Network Security Functions Service 856 Interface", February, 2015. 858 9. Acknowledgments 860 This document was prepared using 2-Word-v2.0.template.dot. 862 Authors' Addresses 864 Yuming Xie 865 Huawei Technologies 866 Email: yuming.xie@huawei.com 868 Liang Xia (Frank) 869 Huawei Technologies 870 Email: Frank.xialiang@huawei.com 872 Jun Wu 873 Huawei Technologies 874 Email: junwu.wu@huawei.com