idnits 2.17.1 draft-merged-i2nsf-framework-02.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 3 instances of too long lines in the document, the longest one being 8 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 392 has weird spacing: '...| Layer heade...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 8, 2015) is 3245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I2NSF-Mobile' is mentioned on line 110, but not defined == Missing Reference: 'MPTCP' is mentioned on line 295, but not defined == Missing Reference: 'RFC3286' is mentioned on line 296, but not defined == Unused Reference: 'I2NSF-MOBILE' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'NW-2011' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'SC-MobileNetwork' is defined on line 694, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Lopez 2 Internet Draft Fortinet 3 Intended status: Informational D. Lopez 4 Expires: December 2015 Telefonica 5 L. Dunbar 6 Huawei 7 X. Zhuang 8 China Mobile 9 J. Parrott 10 BT 11 R Krishnan 12 Dell 13 S. Durbha 14 CableLabs 16 June 8, 2015 18 Framework for Interface to Network Security Functions 19 draft-merged-i2nsf-framework-02.txt 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 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. This document may not be modified, 28 and derivative works of it may not be created, except to publish it 29 as an RFC and to translate it into languages other than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on December 8, 2015. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Abstract 65 In the design of interfaces to allow for the provisioning of network 66 security functions (NSFs), a critical consideration is to prevent 67 the creation of implied constraints. 69 This document makes the recommendation that such interfaces be 70 designed from the paradigm of processing packets and flows on the 71 network. NSFs ultimately are packet-processing engines that inspect 72 packets traversing networks, either directly or in context to 73 sessions to which the packet is associated. This document serves as 74 the framework for detailed work items for I2NSF. 76 Table of Contents 78 1. Introduction...................................................3 79 2. Conventions used in this document..............................3 80 3. Interfaces to Flow-based NSFs..................................4 81 4. Reference Models in Managing NSFs..............................6 82 4.1. NSF Facing Interface......................................7 83 4.2. Client Facing Interface...................................7 84 4.3. Vendor Facing Interface...................................8 85 4.4. The network connecting the Security Controller and NSFs...8 86 4.5. Interface to vNSFs........................................9 87 5. Flow-based NSF Capability Characterization....................10 88 6. Security Policies Provisioning to NSFs........................13 89 6.1. Capability Layer Provisioning and Monitoring.............13 90 6.2. Service Layer Security Policy............................14 91 7. Capability Negotiation........................................15 92 8. Types of I2NSF clients........................................16 93 9. Manageability Considerations..................................16 94 10. Security Considerations......................................17 95 11. IANA Considerations..........................................17 96 12. References...................................................17 97 12.1. Normative References....................................17 98 12.2. Informative References..................................17 99 13. Acknowledgments..............................................18 101 1. Introduction 103 This document describes the framework for Interface to Network 104 Security Functions (I2NSF) and defines a reference model along with 105 functional components for I2NSF. It also describes how I2NSF 106 facilitates Software-defined network (SDN) and Network Function 107 Virtualization (NVF) control, while avoiding potential constraints 108 which could limit NSFs internal functions. 110 The I2NSF use cases ([I2NSF-ACCESS], [I2NSF-DC] and [I2NSF-Mobile]) 111 call for standard interfaces for customers to control and monitor 112 security functions hosted and managed by service providers. 114 [I2NSF-Problem] describes the motivation and the problem space for 115 Interface to Network Security Functions. 117 2. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC-2119 [RFC2119]. 123 In this document, these words will appear with that interpretation 124 only when in ALL CAPS. Lower case uses of these words are not to be 125 interpreted as carrying RFC-2119 significance. 127 BSS: Business Support System 129 Controller: used interchangeably with Service Provider Security 130 Controller or management system throughout this 131 document. 133 FW: Firewall 135 IDS: Intrusion Detection System 137 IPS: Intrusion Protection System 139 NSF: Network Security Functions, defined by [I2NSF-Problem] 141 OSS: Operation Support System 143 vNSF: refers to NSF being instantiated on Virtual Machines. 145 3. Interfaces to Flow-based NSFs 147 The emergence of SDN and NFV has resulted in the need to create 148 application programming interfaces (APIs) in support of dynamic 149 requests from various applications. Flow-based NSFs [I2NSF-Problem] 150 inspects packets in the order as they are received without 151 modification to the packets due to the inspection process. 153 The Interface to Flow-based NSFs can be generally grouped into three 154 types: 156 1) Configuration - deals with the management and configuration of 157 the forwarding functions of the NSF device itself, such as port, 158 addresses configurations. Configuration deals with attributes that 159 are don't change very much. 161 2) Signaling - which represents logging and query functions between 162 the NSF and external systems. Signaling API functions may also be 163 well defined by other protocols such as SYSLOG, DOTS, etc. 165 3) Provisioning - used to control the rules that govern how packets 166 are treated by the NSFs. Due to the lack of standards in the 167 definition and operation of these functions, much of the efforts 168 towards interface development will be in this area. 170 This draft proposes that a provisioning interface to NSFs can be 171 developed on a packet-based paradigm. While there are many 172 classifications of existing and emerging NSFs, a common trait shared 173 by them is in the processing of packets based on the content 174 (header/payload) and context (session state, authentication state, 175 etc) of received packets. 177 An important concept is the fact that attackers do not have 178 standards as to how to attack networks, so it is equally important 179 not to constrain NSF developers to offering a limited set of 180 security functions. Therefore, in constructing standards for 181 provisioning interfaces to NSFs, it is equally important to allow 182 support for vendor-specific functions, to allow the introduction of 183 NSFs that evolve to meet new threats. Proposed standards for 184 provisioning interfaces to NSFs should not: 186 - Narrowly define NSF categories, or their roles when implemented 187 within a network 189 - Attempt to impose functional requirements or constraints, either 190 directly or indirectly, upon NSF developers 192 - Be a limited lowest-common denominator approach, where interfaces 193 can only support a limited set of standardized functions, without 194 allowing for vendor-specific functions 196 - Be seen as endorsing a best-common-practice for the implementation 197 of NSFs 199 By using a packet-based approach to the design of such provisioning 200 interfaces, the goal is to create a workable interface to NSFs which 201 aid in their integration within SDN/NFV environments, while avoiding 202 potential constraints which could limit their functional 203 capabilities. 205 Even though security functions come in variety of form factors and 206 have different features, provisioning to Flow-based NSFs can be 207 categorized by 209 - Subject - Match values based on packet data Packet header or 210 Packet payload, 211 - Object - Match values based on context, e.g. State, time, geo- 212 location, etc., 213 - Action- Egress processing, such as Invoke signaling; Packet 214 forwarding and/or transformation; Possibility for SDN/NFV 215 integration, and 216 - Functional Profile - E.g. IPS:, signature file, Anti- 217 virus file, URL filtering file, etc. Integrated and one-pass 218 checks on the content of packets. 220 The functional profile or signature file is one of the key 221 properties that determine the effectiveness of the NSF, and is 222 mostly vendor specific today. 224 4. Reference Models in Managing NSFs 226 This document only focuses on the framework of provisioning and 227 monitoring of the flow-based NSFs. 229 The following figure shows various interfaces for managing the 230 provisioning & monitoring aspects of flow-based NSFs. 232 Client/AppGW 233 | 234 | Client Facing Interface 235 +-----+---------------+ 236 |Service Provider mgmt| +-------------+ 237 | Security Controller | < -------- > | Vendor | 238 +---------------------+ Vendor Facing| Sys | 239 | Interface +-------------+ 240 | 241 | NSF Facing Interface 242 | 243 +------------------------------------------------+ 244 | | 245 | | 246 +------+ +------+ +------+ +------+ 247 + NSF-1+ ------- + NSF-n+ +NSF-1 + ----- +NSF-m + . . . 248 +------+ +------+ +------+ +------+ 250 Vendor A Vendor B 252 Figure 1: Multiple Interfaces 254 4.1. NSF Facing Interface 256 This is the interface between the Service Provider's management 257 system (or Security Controller) and the NSFs that are selected to 258 enforce the desired network security. This interface is called 259 Capability Interface in the I2NSF context. 261 4.2. Client Facing Interface 263 This interface is for clients or Application Gateway to express 264 and monitor security policies for their specific flows. The Client 265 Facing interface is called Server Layer Interface in the I2NSF 266 context. 268 A single client layer policy may need multiple NSFs collectively 269 together to achieve the enforcement. 271 4.3. Vendor Facing Interface 273 When service providers have multiple types of security functions 274 provided by different vendors, it is necessary to have an 275 interface for vendors to register their NSFs indicating what level 276 can be provisioned or monitored for each of the categories listed 277 above. 279 The Registration Interface can be static or dynamic. When NSFs are 280 upgraded, vendors need to notify the service provider management 281 system or controller of the updated capabilities. 283 4.4. The network connecting the Security Controller and NSFs 285 Most NSFs are not directly attached to the Security Controller; it 286 is especially true when NSFs are distributed across the network. 287 The network that connects the Security Controller with the NSFs 288 can be the same network that carry the data traffic, or can be a 289 dedicated network for management purpose only. Either case, packet 290 loss could happen due to failure, congestion, or other reasons. 292 Therefore, the transport mechanism used to carry the control 293 messages and monitoring information should provide reliable 294 message delivery. Transport redundancy mechanisms such as 295 Multipath TCP (MPTCP) [MPTCP] and the Stream Control Transmission 296 Protocol (SCTP) [RFC3286] will need to be evaluated for 297 applicability. Latency requirements for control message delivery 298 must also be evaluated. 300 The connection between Security Controller and NSFs could be: 302 - Closed environments where there is only one administrative 303 domain. More permissive access controls and lighter validation 304 is needed inside the domain because of the protected 305 environment. 307 - Open environments where some NSFs (virtual or physical) can be 308 hosted in external administrative domains or reached via 309 external network domains. Then more restrictive security 310 controls are required over the I2NSF interface. The information 311 over the I2NSF interfaces must use trusted channels, such as 312 TLS, SASL, or the combination of the two. 314 Over the Open Environment, I2NSF needs to provide the identity 315 frameworks and federations models for authentication and 316 Authorization. 318 4.5. Interface to vNSFs 320 Even though there is no difference between virtual network 321 security functions (vNSF) and physical NSFs from policy 322 provisioning perspective, there are some unique characteristics in 323 interfacing to the vNSFs: 325 - There could be multiple instantiations of one single NSF being 326 distributed across network. When different instantiations are 327 visible to the Security Controller, different policies may be 328 applied to different instantiations of one single NSF. 329 - When multiple instantiations of one single NSF appear as one 330 single entity to the Security Controller, the policy 331 provisioning has to be sent to the NSF's sub-controller, which 332 in turn disseminate the polices to the corresponding 333 instantiations of the NSF, as shown in the figure below. See 334 Figure 2 below. 335 - Policies to one vNSF may need to be retrieved and move to 336 another vNSF of the same type when client flows are moved from 337 one vNSF to another. 338 - Multiple vNSFs may share the same physical platform 339 - There may be scenarios where multiple vNSFs collectively perform 340 the security policies needed. 342 +------------------------+ 343 | Security Controller | 344 +------------------------+ 345 ^ ^ 346 | | 347 +-----------+ +------------+ 348 | | 349 v v 350 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 351 | NSF-A +--------------+ | | NSF-B +--------------+ | 352 | |Sub Controller| | | |sub Controller| | 353 | +--------------+ | | +--------------+ | 354 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 355 | |+---------+ +---------+| | | |+---------+ +---------+| | 356 | || NSF-A#1 | ... | NSF-A#n|| | | || NSF-B#1| ... | NSF-B#m|| | 357 | |+---------+ +---------+| | | |+---------+ +---------+| | 358 | | NSF-A cluster | | | | NSF-B cluster | | 359 | + - - - - - - - - - - - - - + | | + - - - - - - - - - - - - - + | 360 + - - - - - - - - - - - - - - - + + - - - - - - - - - - - - - - - + 362 Figure 2: Cluster of NSF Instantiations Management 364 5. Flow-based NSF Capability Characterization 366 There are many types of flow-based NSFs. To prevent constraints on 367 NSF vendors' creativity and innovation, this document recommends the 368 Flow-based NSF interfaces to be designed from the paradigm of 369 processing packets on the network. Flow-based NSFs ultimately are 370 packet-processing engines that inspect packets traversing networks, 371 either directly or in context to sessions to which the packet is 372 associated. 374 Flow-based NSFs differ in the depth of packet header or payload they 375 can inspect, the various session/context states they can maintain, 376 the specific profiles and the actions they can apply. Accordingly, 377 the NSF capabilities are characterized by the level of packet 378 processing and context that a NSF supports, the profiles and the 379 actions that the NSF can apply. 381 Vendors can register their NSFs using the Subject-Object-Action- 382 Function categories described in Section 2, with detailed 383 specification of each category as shown in the table below: 385 +-----------------------------------------------------------+ 386 | Subject Capability Index | 387 +---------------+-------------------------------------------+ 388 | Layer 2 | Layer 2 header fields: | 389 | Header | Source/Destination/s-VID/c-VID/EtherType/.| 390 | | | 391 |---------------+-------------------------------------------+ 392 | Layer 3 | Layer header fields: | 393 | | protocol | 394 | IPv4 Header | port | 395 | | src port | 396 | | dscp | 397 | | length | 398 | | flags | 399 | | ttl | 400 | | | 401 | IPv6 Header | | 402 | | addr | 403 | | protocol/nh | 404 | | src port | 405 | | length | 406 | | traffic class | 407 | | hop limit | 408 | | flow label | 409 | | | 410 | TCP | Port | 411 | SCTP | syn | 412 | DCCP | ack | 413 | | fin | 414 | | rst | 415 | | ? psh | 416 | | ? urg | 417 | | ? window | 418 | | sockstress | 419 | UDP | | 420 | | flood abuse | 421 | | fragment abuse | 422 | | Port | 423 | HTTP layer | | 424 | | | hash collision | 425 | | | http - get flood | 426 | | | http - post flood | 427 | | | http - random/invalid url | 428 | | | http - slowloris | 429 | | | http - slow read | 430 | | | http - r-u-dead-yet (rudy) | 431 | | | http - malformed request | 432 | | | http - xss | 433 | | | https - ssl session exhaustion | 434 +---------------+----------+--------------------------------+ 435 | IETF PCP | Configurable | 436 | | Ports | 437 | | | 438 +---------------+-------------------------------------------+ 439 | IETF TRAM | profile | 440 | | | 441 | | | 442 |---------------+-------------------------------------------+ 444 +-----------------------------------------------------------+ 445 | Object (context) matching Capability Index | 446 +---------------+-------------------------------------------+ 447 | Session | Session state, | 448 | | bidirectional state | 449 | | | 450 +---------------+-------------------------------------------+ 451 | Time | time span | 452 | | days, minutes, seconds, | 453 | | Events | 454 +---------------+-------------------------------------------+ 455 | Events | Event URL, variables | 456 +---------------+-------------------------------------------+ 458 +-----------------------------------------------------------+ 459 | Action Capability Index | 460 +---------------+-------------------------------------------+ 461 | Ingress port | SFC header termination , | 462 +---------------+-------------------------------------------+ 463 | | Pass | 464 | Egress | Deny | 465 | | Mirror | 466 | | Functional call | 467 | | Encap various header | 468 +---------------+-------------------------------------------+ 470 +-----------------------------------------------------------+ 471 | Functional profile Index | 472 +---------------+-------------------------------------------+ 473 | Profile types | Name, type, or | 474 | Signature | Flexible Profile/signature URL | 475 | | Command for Controller to enable/disable | 476 | | | 477 +---------------+-------------------------------------------+ 479 6. Security Policies Provisioning to NSFs 481 +------------------------------------------+ 482 | App Gateway | 483 | (e.g. Video conference Ctrl | 484 | Admin, OSS/BSS, or Service Orchestration | 485 +---------------------+--------------------+ 486 I2NSF |Service Layer Security Policy 487 | 488 +--------------+----------------+ 489 | Security Controller | 490 +--------------+----------------+ 491 I2NSF |Capability Layer Security Policy 492 | 493 +------------------+ 494 | Adapter | 495 +------------------+ 496 | virtual/physical | 497 | NSFs | 498 +------------------+ 499 Figure 3: Multiple Layers of I2NSF interfaces 501 6.1. Capability Layer Provisioning and Monitoring 503 The Capability Layer is to express the explicit provisioning rules 504 to individual NSFs and methods to monitor the execution status of 505 those functions. 507 This requires the definition of an information model, along with one 508 or more data models, to express the provisioning rules, which are 509 derived from the client facing security policies. 511 This layer will leverage the existing protocols and data models 512 defined by I2RS, Netconf, and NETMOD. 514 [ACL-MODEL] is for expressing the Access Control List supported by 515 most routers/switches that forward packets based on packets' L2, L3, 516 or sometimes L4 headers. The actions for Access Control List include 517 Pass, Drop, or Redirect. 519 The functional profiles (or signatures) for NSFs are not present in 520 [ACL-MODEL] because the functional profiles are unique to specific 521 NSFs. Most vendors' IPS/IDS, and HoneyPot have their proprietary 522 functions/profiles. One of the goals of I2NSF is to have common 523 envelop format for exchanging or sharing profiles among different 524 organizations to achieve more effective protection against threats. 526 The "subject" of the policies not only includes the matching 527 criteria specified by [ACL-MODEL] but also the L4-L7 fields 528 depending on the NSF selected. 530 The I2NSF Capability Layer has to specify the "Object" (i.e. the 531 states/contexts surrounding the packets). 533 The I2NSF "actions" are similar to the actions specified by [ACL- 534 MODEL]. 536 This layer also includes the policy monitoring of the individual 537 NSFs and fault management of the policy execution. In NFV 538 environment, policy consistency among multiple security function 539 instances is very critical because security policies are no longer 540 maintained by one central security devices, but instead are enforced 541 by multiple security functions instantiated at various locations. 543 6.2. Service Layer Security Policy 545 This layer is for customers or Application Gateway to express & 546 monitor the needed security policies for their specific flows. 548 Customers may not have security skills. As such, they are not able 549 to express requirements or security policies that are precise 550 enough. Usually these customers are expressing expectations (that 551 can be viewed as loose security requirements). Customers may also 552 express guidelines such as which critical communications are to be 553 preserved during critical events, which hosts are to service even 554 during severe security attacks, etc. 556 Here are some examples of Service Oriented Security Policies: 558 o Pass FW/IPS for Subscriber "xxx" with Port "y" 559 o enable basic parental control 560 o enable "school protection control" 561 o allow Internet traffic from 8:30 to 20:00 [time = 8:30- 562 20:00] 564 o scan email for malware detection [check type = malware] 565 protect traffic to corporate network with integrity and 566 confidentiality [protection type = integrity AND 567 confidentiality] 568 o remove tracking data from Facebook [website = 569 *.facebook.com] 570 o my son is allowed to access facebook from 18:30 to 20:00 572 One Service Layer Security Policy may need multiple security 573 functions at various locations to achieve the enforcement. Service 574 layer Security Policy may need to be updated by users or Application 575 Gateway when user's service requirements have been changed. 577 I2NSF will not standardize the Service Layer security policies. IETF 578 SUPA - Shared Unified Policy Automation, if approved and chartered, 579 seems to be a good candidate to play in this space. [I2NSF-Demo] 580 describes an implementation of translating a set of Service Layer 581 policies to the Capability Layer instructions to NSFs. 583 7. Capability Negotiation 585 When a NSF can't perform the desired provisioning due to resource 586 constraint, it has to inform the controller. 588 The protocol needed for this security function/capability 589 negotiation may be somewhat correlated to the dynamic service 590 parameter negotiation procedure [RFC7297]. The Connectivity 591 Provisioning Profile (CPP) template documented in RFC7297, even 592 though currently covering only Connectivity (but includes security 593 clauses such as isolation requirements, non-via nodes, etc.), 594 could be extended as a basis for the negotiation procedure. 595 Likewise, the companion Connectivity Provisioning Negotiation 596 Protocol (CPNP) could be a candidate to proceed with the 597 negotiation procedure. 599 The "security as a service" would be a typical example of the kind 600 of (CPP-based) negotiation procedures that could take place 601 between a corporate customer and a service provider. However, more 602 security specific parameters have to be considered by this 603 proposed work. 605 8. Types of I2NSF clients 607 It is envisioned that I2NSF clients include: 609 - Application Gateway: 611 - For example, Video Conference Mgr/Controller needs to 612 dynamically inform some FW/IPS/IDS security functions on 613 special policies based specific fields in the packets for the 614 specific encrypted flows for a certain time span. Otherwise, 615 some flows can't go through the FW/IPS/IDS because the 616 payload is encrypted. 618 - Security Administrators 620 - Enterprise 621 - Operator Management System dynamically update, monitor and 622 verify the security policies to security functions 623 - Third party system 624 - management system 626 - Security functions send requests for more sophisticated functions 627 upon detecting something suspicious 629 9. Manageability Considerations 631 Management of NSFs usually include 632 - life cycle management and resource management of vNSFs 634 - configuration of devices, such as address configuration, 635 device internal attributes configuration, etc, 637 - signaling, and 639 - policy provisioning. 641 I2NSF will only focus on the policy provisioning part, i.e. the 642 last bullet listed above. 644 10. Security Considerations 646 Having a secure access to control and monitor NSFs is crucial for 647 hosted security service. Therefore, proper secure communication 648 channels have to be carefully specified for carrying the 649 controlling and monitoring information between the NSFs and their 650 management entity (or entities). 652 11. IANA Considerations 654 This document requires no IANA actions. RFC Editor: Please remove 655 this section before publication. 657 12. References 659 12.1. Normative References 661 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 662 Requirement Levels", BCP 14, RFC 2119, March 1997. 664 [RFC7297] Boucadair, M., "IP Connectivity Provisioning Profile", 665 RFC7297, April 2014. 667 12.2. Informative References 669 [I2NSF-ACCESS] A. Pastor, et al, "Access Use Cases for an Open OAM 670 Interface to Virtualized Security Services", , Oct 2014. 673 [I2NSF-DC] M. Zarny, et al, "I2NSF Data Center Use Cases", , Oct 2014. 676 [I2NSF-MOBILE] M. Qi, et al, "Integrated Security with Access 677 Network Use Case", , Oct 2014 680 [I2NSF-Problem] L. Dunbar, et al "Interface to Network Security 681 Functions Problem Statement", , Jan 2015 684 [ACL-MODEL] D. Bogdanovic, et al, "Network Access Control List (ACL) 685 YANG Data Model", , Nov 2014. 687 [gs_NFV] ETSI NFV Group Specification, Network Functions 688 Virtualizsation (NFV) Use Cases. ETSI GS NFV 001v1.1.1, 689 2013. 691 [NW-2011] J. Burke, "The Pros and Cons of a Cloud-Based Firewall", 692 Network World, 11 November 2011 694 [SC-MobileNetwork] W. Haeffner, N. Leymann, "Network Based Services 695 in Mobile Network", IETF87 Berlin, July 29, 2013. 697 [I2NSF-Demo] Y. Xie, et al, "Interface to Network Security Functions 698 Demo Outline Design", , April 2015. 701 13. Acknowledgments 703 Acknowledgements to xxx for his review and contributions. 705 This document was prepared using 2-Word-v2.0.template.dot. 707 Authors' Addresses 709 Edward Lopez 710 Fortinet 711 899 Kifer Road 712 Sunnyvale, CA 94086 713 Phone: +1 703 220 0988 714 Email: elopez@fortinet.com 716 Diego Lopez 717 Telefonica 718 Email: diego.r.lopez@telefonica.com 720 XiaoJun Zhuang 721 China Mobile 722 Email: zhuangxiaojun@chinamobile.com 724 Linda Dunbar 725 Huawei 726 Email: Linda.Dunbar@huawei.com 728 Joe Parrott 729 BT 730 Email: joe.parrott@bt.com 732 Ramki Krishnan 733 Dell 734 Email: ramki_krishnan@dell.com 736 Seetharama Rao Durbha 737 CableLabs 738 Email: S.Durbha@cablelabs.com