idnits 2.17.1 draft-dunbar-nsaas-problem-statement-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. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 10. 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: ' 11. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 4, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'Gartner-2013' on line 478 looks like a reference -- Missing reference section? 'RFC2119' on line 466 looks like a reference -- Missing reference section? 'NW-2011' on line 481 looks like a reference -- Missing reference section? 'RFC7297' on line 469 looks like a reference -- Missing reference section? 'Boucadair-framework' on line 474 looks like a reference -- Missing reference section? 'SC-MobileNetwork' on line 484 looks like a reference -- Missing reference section? 'Application-SDN' on line 487 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Dunbar 2 Internet Draft Huawei 3 Intended status: Informational M. Zarny 4 Expires: January 2015 Goldman Sachs 5 C. Jacquenet 6 France Telecom 7 S. Chakrabarty 8 US Ignite 10 July 4, 2014 12 Dynamic Network Security as a Service Problem Statement 13 draft-dunbar-nsaas-problem-statement-00.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, except to publish it 23 as an RFC and to translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on January 4, 2009. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Abstract 60 This draft describes the motivation, use cases, and the problem 61 statement for network security as a service. 63 Table of Contents 65 1. Introduction...................................................3 66 1.1. Motivation................................................3 67 1.2. Network Security Functions under Consideration............4 68 1.3. The scope of the proposed work............................5 69 2. Conventions used in this document..............................6 70 3. Use Case: Virtual Firewall Function On Demand in Cloud DCs.....7 71 4. Use Case: Security Functions provided to a Mobile Operator.....7 72 5. Problem Space..................................................8 73 5.1. Issues of the current Cloud-based Security Solutions......8 74 5.2. Other problems............................................9 75 5.3. The Benefits..............................................9 76 6. Related industry initiatives..................................10 77 6.1. OpenStack Firewall/Security as a Service.................10 78 6.2. Security as a Service by Cloud Security Alliance.........10 79 7. Potential Solutions...........................................11 80 8. Conclusion and Recommendation.................................11 81 9. Manageability Considerations..................................11 82 10. Security Considerations......................................11 83 11. IANA Considerations..........................................11 84 12. References...................................................12 85 12.1. Normative References....................................12 86 12.2. Informative References..................................12 87 13. Acknowledgments..............................................12 89 1.Introduction 91 This draft describes the motivation, use cases, and the problem 92 statement for dynamic network security as a service. 94 1.1. Motivation 96 The main benefits of virtualized network functions are increased 97 flexibility to efficiently share the resources, and decreased setup 98 and management costs. These services can be deployed in enterprise 99 networks or in provider networks. Many enterprises are increasing 100 consuming these services hosted in their providers' networks. In 101 particular, they are consuming network security services hosted off 102 premises. 104 Some of the reasons driving up this demand are the need and desire 105 to: 107 . Dynamically provision and update firewall policies 108 . Implement stringent security functions at branch offices where 109 minimal security infrastructures/capabilities exist 110 . Provide virtual network security services for applications 111 operating over virtual networks such as NVO3 112 . Maintain consistent security policies across a large number of 113 small low powered/low processing sensors 115 According to [Gartner-2013], the demand for cloud-based security 116 services is growing. Small and medium-sized businesses (SMBs) are 117 increasingly adopting cloud-based security services to replace on- 118 premises security tools, while larger enterprises are deploying a 119 mix of traditional and cloud-based security services. 121 Despite their increasing popularity, most common cloud security 122 services-like most cloud services in general-do not yet have 123 industry standards by which users can request their desired services 124 from some vendors. (The "user-provider" relationship may exist 125 between two different firms or between different domains of the same 126 firm.) 128 Another area ripe for standardization is how these services may be 129 dynamically provisioned, updated, or/and verified to fulfill on- 130 demand requests. Issues here range from the more typical ones like 131 the scalability, availability and extensibility of the cloud-based 132 services to more esoteric ones like a lack of intelligent policy to 133 configuration translation and a lack of consistent way to implement 134 policies across multiple regions and entities. 136 Open source projects like OpenStack and CloudStack have begun to 137 tackle the issues but much work remains. The objective of this draft 138 is to describe the problem set for which future architecture and 139 solutions can be developed. 141 1.2. Network Security Functions under Consideration 143 There are many network functions being deployed and new ones are 144 popping up with business and application demands. In order to have a 145 concrete context for the protocols discussion, we start with the 146 following network security related functions: 148 . Firewall 149 . DDOS/Anti-DOS 150 . Access control/Authorization/Authentication 151 . Remote identity management 152 . Secure Key management 153 . Intrusion Detection System/ Intrusion Prevention System 154 (IDS/IPS) 155 . Threat detection: Eavesdropping, Trojans, viruses and worms, 156 Malware, etc. 158 The reason for starting with security-related functions is due to 159 the wide acceptance of security functions that are not running on 160 customer/enterprise premises. Numerous security vendors are now 161 leveraging cloud based models to deliver security solutions. This 162 shift has occurred for a variety of reasons including greater 163 economies of scale, streamlined delivery mechanisms, and the demand 164 of business and applications for more sophisticated security 165 functions that they do not have. Consumers, enterprise clients as 166 well as applications are embracing the business model of requesting 167 for security functions that do not run on their own premises on 168 demand, also known as Security as a Service. 170 1.3. The scope of the proposed work 172 Virtual Security Function is a security function that can be 173 requested by one domain (e.g., two different domains of one service 174 provider, enterprise clients, or applications, etc.) but may be 175 owned or managed by another domain (e.g., service provider). Those 176 security functions may be hosted on physical appliances or 177 instantiated as virtual machines on common compute server (i.e. the 178 Virtualized network functions defined by ETSI NFV). 180 Note: Virtual Security Function and "Cloud-based Security Functions" 181 are used interchangeably in this draft. 183 The "requester <-> provider" relationship has different connotations 184 in different scenarios: 186 . Client <-> Provider relationship, i.e. client requesting some 187 network functions from its provider; 188 . Inter-domain, e.g. Domain A <-> Domain B relationship, i.e. one 189 operator domain requesting some network functions from another 190 operator domain, where "A" and "B" can be from same operator or 191 different operators; or 192 . Applications <-> Network relationship, i.e. an application 193 (e.g. cluster of servers) requesting some functions from 194 network, etc. 196 The security functions offered by 3rd party need Bi-directional 197 periodic communications between the requesters and the providers for 198 policies negotiation, validation, potentially re-directing traffic 199 to higher level security functions, etc. Therefore, the service 200 requires protocol exchange. Simply API is not enough. 202 The objective of the proposed work is to standardize the protocols 203 (or the interface) and architecture for Requester and Provider to 204 negotiate the functions needed as well as the associated attributes. 206 The proposed protocols between requester and provider can be used 207 for the following scenarios: 209 . A Client requests a certain network security function from a 210 provider 212 . The provider fulfills the request for example, by instantiating 213 an instance of the service in question, or configures an 214 additional rule in an already provisioned service. 216 2. Conventions used in this document 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC-2119 [RFC2119]. 222 In this document, these words will appear with that interpretation 223 only when in ALL CAPS. Lower case uses of these words are not to be 224 interpreted as carrying RFC-2119 significance. 226 Cloud DC: The data centers that are not on premises of enterprises 227 yet have the compute/storage resources that can be 228 requested or purchased by the enterprises. What the 229 enterprises actually get is Virtual Data Centers. 231 DC: Data Center 233 Domain: The term "Domain" in this draft has different 234 connotations in different scenarios: 235 Client <-> Provider relationship, i.e. client requesting 236 some network functions from its provider; 237 Domain A <-> Domain B relationship, i.e. one operator 238 domain requesting some network functions 239 from another operator domain; or 240 Applications <-> Network relationship, i.e. an 241 application (e.g. cluster of servers) 242 requesting some functions from network, etc. 244 Virtual Network Function: an L4-L7 network function that can be 245 requested by one domain (e.g. two different domains of 246 one service provider, enterprise clients, or 247 applications, etc.) but may be owned or managed by 248 another domain (e.g. service provider). Those network 249 functions would be running over physical appliances or 250 instantiated as virtual machines on common compute 251 servers (i.e. the ETSI NFV defined Virtualized network 252 functions). The "Network Function" here means a range of 253 L4-L7 functions. 255 Virtual Security Function: a security function that can be requested 256 by one domain but may be owned or managed by another 257 domain. 259 Cloud-based security functions: used interchangeably with the 260 "Virtual Security Functions" in this draft. 262 3. Use Case: Virtual Firewall Function On Demand in Cloud DCs 264 Clients of a cloud data center not only need virtual networks to 265 interconnect their virtual compute/storage resources, but they also 266 need virtual firewall services to enforce the proper communication 267 policies. VPN clients, especially branch office access points, may 268 need firewalls that are hosted by the VPN provider to be integrated 269 with the VPN service. 271 Per [NW-2011], A cloud-based firewall is different from an on- 272 premise one (aside from its location) in three key areas: 273 scalability, availability and extensibility. 275 . Scalability: Cloud-based firewalls are designed to serve 276 multiple customers and their increasing demand. Unlike with an 277 on-premise firewall, upgrading a cloud-based firewall-e.g., 278 for greater throughput-should be transparent to enterprise 279 users. 280 . Availability: Cloud-based firewall providers tend to offer 281 extremely high availability through their highly redundant and 282 resilient data centers. In contrast, most enterprises may not 283 be able to offer "carrier-grade" high availability. 284 . Extensibility: Enterprises looking for vendor diversity can 285 subscribe to cloud-based firewalls from different providers. 286 Furthermore, additional features can be added more seamlessly, 287 transparently. 289 4. Use Case: Security Functions provided to a Mobile Operator 291 Maintaining security is challenging, especially in mobile 292 environments, where all kinds of user devices (smartphones, pads, 293 personal assistants, etc.) access applications located in the cloud. 294 Not only are applications no longer hosted in contained data 295 centers, (which have a higher chance of encountering various 296 security threats), but also the mobile devices might not have the 297 sophisticated processing power or expertise to run up-to-date 298 security protection functions to guard against rapidly changing 299 threats. 301 Evolving threats to mobile networks can affect mobile devices, radio 302 access networks (RANs), and applications hosted in cloud data 303 centers. 305 The trend is to have security functions delivered as a service from 306 the provider, without requiring on-premise hardware or software 307 maintenance. 309 These security services often include authentication (e.g., the 310 ability to authenticate employees to control the cloud services and 311 data they have access to), anti-virus, anti-malware/spyware, 312 intrusion detection, and security event management, among others. 314 The security function offering can be between different domains of 315 one operator or between subscribers to providers. Backhaul operators 316 can offer the security function services to mobile operators. 318 Security-as-a-Service to mobile environments offers a number of 319 benefits, including: 321 . Greater security expertise than typically available to mobile 322 users, 323 . Flexibility of managing evolving threats 324 . Ensuring service availability 325 . Reducing deployment and operational costs 326 . Effectively organizing groups of apps or users, 327 . Constant virus definition updates. 329 5. Problem Space 331 5.1. Issues of the current Cloud-based Security Solutions 333 Many vendors already offer Security as a Service in the cloud. 334 However, all their solutions are proprietary, with different 335 interfaces and different modes of operation. Some offerings follow a 336 peer-to-peer model: i.e. requiring clients to peer with vendor 337 provided functions hosted in the cloud. A competing model requires 338 clients to download their desired functions to local devices. In 339 this model, it is difficult to maintain consistent software updates 340 across all the devices. Consistency issues can exist across: (1) 341 multiple regions for a single application; (2) multiple 342 applications; and/or (3) multiple zones (e.g., between internal and 343 perimeter zones). 345 In addition, the current mode of operation for Security as a Service 346 via a Cloud infrastructure does not have any common 347 interfaces/mechanisms for clients or applications to verify if the 348 required functions can fulfill the policies needed by the 349 clients/applications. There is a lack of user-friendly service 350 (policy) template. 352 5.2. Other problems 354 Here are some other problems associated with Security Function on 355 Demand that might be out of the scope of this proposed WG: 357 . Diverse security services: 358 The proposed WG might not be able to cover every possible 359 security service. 361 . Scalability: 362 Not only diverse CPU/memory needed for different security 363 functions can be difficult to manage, but the solution itself 364 may have some limits, e.g. maximum number of firewall rules. 366 . Availability: 367 The VNF pool is to address the availability of virtualized 368 network functions. 370 . Converting policies to vendor-specific configurations 371 . Dynamic features update 373 5.3. The Benefits 375 The goal of the proposed work is to establish an architectural 376 framework and mechanisms for clients (or one domain) to request 377 security functions from a network provider (or another domain). The 378 framework allows the clients to view, request, and/or verify the 379 security functions/solution offered by different vendors. This 380 framework can make it easy for a cluster of devices requiring the 381 similar security policies to have consistent policies across 382 multiple sites. 384 The network service providers, with their physical access to a vast 385 number of enterprises and consumers, are very well positioned to 386 provide the "Security Function on Demand" platform. The providers 387 can act as security function brokers to their directly connected 388 domains. They can offer a service catalog and standard mechanisms by 389 which enterprises (or applications) can query request, or/and verify 390 the needed security functions. 392 With the standard protocols for clients to request the needed 393 security functions, network operators can leverage their current VPN 394 to enterprises and access to a vast population of end users to offer 395 a set of consolidated Security solutions. The IETF can play an 396 instrumental role in defining this common interface and framework 397 for network operators. 399 6. Related industry initiatives 401 6.1. OpenStack Firewall/Security as a Service 403 OpenStack completed the Firewall as a Service project and specified 404 the set of APIs for Firewall services: 405 http://docs.openstack.org/admin-guide- 406 cloud/content/fwaas_api_abstractions.html 408 OpenStack has defined the APIs for managing Security Groups: 409 http://docs.openstack.org/admin-guide- 410 cloud/content/securitygroup_api_abstractions.html 412 The attributes defined by OpenStack Firewall/Security as a Service 413 will be the basis of the information model for the proposed work at 414 the VNFOD IETF initiative. 416 6.2. Security as a Service by Cloud Security Alliance 418 https://cloudsecurityalliance.org/research/secaas/#_get-involved 420 SaaS by CSA is at the initial stage of defining the scope of work. 422 7. Potential Solutions 424 While it is too early to specify any solutions, some potential 425 candidates are described just to prove that the identified problem 426 is well bounded for the IETF to specify the needed solutions. 428 The protocol needed for this negotiation may be somewhat correlated 429 to the dynamic service parameter negotiation procedure [RFC7297]. 430 The CPP template documented in RFC7297, even though currently 431 covering only Connectivity, could be extended as a basis for the 432 negotiation procedure. Likewise, the companion CPNP protocol could 433 be a candidate to proceed with the negotiation procedure. 435 The "security as a service" would be a typical example of the kind 436 of (CPP-based) negotiation procedures that could take place between 437 a corporate customer and a service provider. However, more security 438 specific parameters have to be considered by this proposed work. 440 8. Conclusion and Recommendation 442 Although open source projects such as OpenStack have taken on the 443 security as a service initiative, much work needs to be done. For 444 example, OpenStack today covers only a minimal set of security 445 functions. The IETF has a responsibility to define a comprehensive 446 framework and necessary standards by which network security 447 functions may be offered, requested, implemented or verified. 449 9. Manageability Considerations 451 TBD. 453 10. Security Considerations 455 TBD 457 11. IANA Considerations 459 This document requires no IANA actions. RFC Editor: Please remove 460 this section before publication. 462 12. References 464 12.1. Normative References 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, March 1997. 469 [RFC7297] Boucadair, M., "IP Connectivity Provisioning Profile", 470 RFC7297, April 2014. 472 12.2. Informative References 474 [Boucadair-framework] M. Boucadair, et al, "Differentiated Service 475 Function Chaining Framework", < draft-boucadair-service- 476 chaining-framework-00>; Aug 2013 478 [Gartner-2013] E. Messmer, "Gartner: Cloud-based security as a 479 service set to take off", Network World, 31 October 2013 481 [NW-2011] J. Burke, "The Pros and Cons of a Cloud-Based Firewall", 482 Network World, 11 November 2011 484 [SC-MobileNetwork] W. Haeffner, N. Leymann, "Network Based Services 485 in Mobile Network", IETF87 Berlin, July 29, 2013 487 [Application-SDN] J. Giacomonni, "Application Layer SDN", Layer 123 488 ONF Presentation, Singapore, June 2013 490 13. Acknowledgments 492 Acknowledgements to Andy Malis for his review and contributions. 494 This document was prepared using 2-Word-v2.0.template.dot. 496 Authors' Addresses 498 Linda Dunbar 499 Huawei Technologies 500 5340 Legacy Drive, Suite 175 501 Plano, TX 75024, USA 502 Phone: (469) 277 5840 503 Email: ldunbar@huawei.com 505 Myo Zarny 506 Goldman Sachs 507 30 Hudson Street 508 Jersey City, NJ 07302 509 Email: myo.zarny@gs.com 511 Christian Jacquenet 512 France Telecom 513 Rennes 35000 514 France 515 Email: Christian.jacquenet@orange.com 517 Shaibal Chakrabarty 518 US Ignite 519 1776 Massachusetts Ave NW, Suite 601 520 Washington, DC 20036 521 Phone: (214) 708 6163 522 Email: shaibalc@us-ignite.org