idnits 2.17.1 draft-sonata-nfvrg-devops-gatekeeper-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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Lopez 3 Internet-Draft TID 4 Intended status: Experimental J. Bonnet 5 Expires: September 14, 2017 Altice Labs 6 M. Peuster 7 UPB 8 P. Aranda Gutierrez 9 UC3M 10 March 13, 2017 12 The Role of a Mediation Element in NFV DevOps 13 draft-sonata-nfvrg-devops-gatekeeper-03 15 Abstract 17 This document describes how a mediation element (a "gatekeeper") can 18 be applied to support DevOps practices in the provisioning of network 19 services based on Network Function Virtualisation (NFV). 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 http://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 14, 2017. 38 Copyright Notice 40 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 57 3. The Essential Components for NFV DevOps . . . . . . . . . . . 4 58 4. The Role of the Gatekeeper . . . . . . . . . . . . . . . . . . 6 59 4.1. User Management . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Package Management . . . . . . . . . . . . . . . . . . . . 7 61 4.3. Monitor Data Transfer . . . . . . . . . . . . . . . . . . 9 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 The DevOps model is already an established concept in IT industry 73 reducing time to market by close collaboration between service 74 developers and service operators. The switch to virtualisation 75 technologies in the network and its potential for quicker time-to- 76 market deployment requires the application of agile development 77 cycles supporting a DevOps approach. This kind of approach will 78 overcome key inhibitors that network operators face when deploying 79 NFV, such as lack of legacy compatibility, resource orchestration, 80 automation and multi-vendor interoperability, hence facilitating the 81 transition to a software-driven network. The adoption of the DevOps 82 model for network services will contribute to interaction between 83 development, testing, and operation of network functionalities and 84 network services. Both the function/service description formats as 85 well as the infrastructure resource descriptions will be able to 86 express and use legacy cases, e.g., the case of a non-virtual network 87 function bound to a specific place in the network, with the data 88 flows routed accordingly. 90 Network Service Providers (NSPs) must be able to orchestrate diverse 91 network functions from multiple sources for automation and streamline 92 them into an inter-organizational DevOps workflow. To embrace the 93 DevOps model implies not only to shorten time between deploying, 94 testing and validating of services, but also to enable the mechanisms 95 for the network to consider application layer requirements and 96 reaction to SLAs, and to ease network reconfiguration in order to 97 achieve fast reaction in a timely manner. 99 Development and operational tools, the two essential pillars of 100 DevOps, translate into the need of addressing the interfacing of 101 service development tasks and the service platform, which in DevOps 102 are closely linked together. It is required to emphasize the need 103 for quick turn-around times in service development and operation, and 104 materialize it in a mediated interface making a direct collaboration 105 on both the development and the platform side possible. 107 The branching to multiple stakeholders in the service lifecycle 108 creates an inter-organizational dynamics that must be taken into 109 account. A realistic NFV DevOps approach has to take into account a 110 trustworthy cycle with a mediation element that ensures compliance 111 policies set by the NSP considering legacy situation, allowing 112 developers across stakeholders to enter the ecosystem. Such a 113 mediation element is what we will refer as a "gatekeeper" in the rest 114 of this document. The resulting strategy opens collaborating 115 opportunities while mitigating liability risks across the network 116 service lifecycle. 118 2. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 In this document, these words will appear with that interpretation 125 only when in ALL CAPS. Lower case uses of these words are not to be 126 interpreted as carrying RFC-2119 significance. 128 3. The Essential Components for NFV DevOps 130 The collaboration between the development and operational tasks to 131 build a service lifecycle according to the DevOps principles requires 132 to combine service programming and orchestration frameworks by means 133 of the following components: 135 o Catalogues, storing static information regarding network functions 136 and services: code, executables, configuration data, and specific 137 management requirements and preferences. Contents, location, 138 organization, and implementation of catalogues for different 139 artefacts can vary considerably. However, users of these 140 catalogues need to deal with them in a consistent fashion and the 141 differences across different catalogues need to be harmonized and 142 abstracted away. As a high-level categorization, the following 143 three types of catalogues can be considered: 145 * Private catalogues of service developers, where they can 146 define, access, reuse, and modify services and service 147 components. 149 * Service platform catalogues made available to authorized 150 service developers for reusing existing components in their 151 services, and used for storing services and their components 152 that need to be deployed by the service platform. 154 * Public catalogues storing artefacts developed and maintained by 155 third-party developers on arbitrary platforms accessible to 156 service developers and service platform operators. 158 o Service Development Kit (SDK). The SDK supports service 159 developers by providing a service programming model and a 160 development tool-chain, designed to support developers in defining 161 and testing complex services consisting of multiple network 162 functions, and to facilitate custom implementations of individual 163 network functions. The tools of this tool-chains provides all 164 necesaray interfaces to establish fully automated continuous 165 integration (CI) workflows. The implemented artefacts are stored 166 in the developer's private catalogues. Moreover, service 167 components can easily be obtained from external catalogues. The 168 obtained artefacts can be directly used in a service or after 169 being modified and tested using the SDK development tools. The 170 service components and all the information necessary for 171 deployment and execution of a service are bundled together into a 172 package. The service package can be handed over to a service 173 platform for actual deployment and for testing, debugging, and 174 profiling purposes. The tools provided by a service development 175 tool-chain can be classified as follows: 177 * Pre-validation tools used by service developers to ensure the 178 correctness of service and function descriptions, including 179 syntax checks, static structure validation, and integrity 180 ensurance tools. 182 * Offline testing and emulation tools used by service developers 183 to conduct functional tests of complex services in well- 184 defined, reproducible environments. Especially focusing on the 185 integration and interoperability between multiple network 186 functions combined to a single service. 188 * Packaging tools responsible to create the final service bundle. 189 This class includes tools that automatically resolve external 190 dependencies of a service to automatically include required 191 artifacts into a package. It also contains tools which sign 192 the final package to give service platforms the necessary 193 confidence that service packages have not been altered during 194 the uploading procedure and to ensure the authenticity of the 195 package. 197 * Tools to support the interaction of a developer with service 198 platforms as well as services and functions deployed in these 199 platforms. This includes two ways of interactions. First, 200 uploading, instantiation and management of service packages on 201 service platforms. Second, receiving runtime, debugging, and 202 monitoring information from the platform as well as accessing 203 artifacts stored in platform catalogues. 205 o Service Platform. The service platform receives the service 206 packages implemented and created with the help of the SDK and is 207 responsible for placing, deploying, provisioning, scaling, and 208 managing the services on existing cloud infrastructures. It can 209 also provide direct feedback about the deployed services to the 210 SDK, for example, monitoring data about a service or its 211 components. The service developer can ship the service package to 212 the service platform together with service- or function-specific 213 lifecycle management requirements and preferences. A gatekeeper 214 module in the service platform is responsible for processing the 215 incoming and outgoing requests. 217 o Underlying Infrastructure. The infrastructure needs to host and 218 execute the actual network functions of a service, e.g., as a 219 virtual machine. The service platform sends necessary information 220 and instructions for execution and lifecycle management of 221 services to the infrastructure. The infrastructure may belong to 222 the service platform operator, or to a third-party infrastructure 223 operator. The interaction between the service platform and the 224 infrastructure is done through a Virtual Infrastructure Manager 225 (VIM). In a typical deployment, the service platform runs 226 directly on top of an actual infrastructure. However, there can 227 be service platforms supporting a recursive deployment model, 228 where a service platform can act as an abstraction to the 229 underlying infrastructure for another service platform. The 230 service platform gatekeeper can play a relevant role to support 231 mediated recursion as well. 233 The DevOps workflow is supported by the integration between the SDK 234 and the service platform. This workflow implies continuous 235 deployment and continuous integration during service development. 236 The main entity exchanged between the SDK and the service platform is 237 the service package to be deployed and runtime information like 238 monitoring data and performance measurements regarding the service 239 package, which is provided to the service developer during the 240 development phase, as well as the runtime. This information can be 241 used for optimizing, modifying, and debugging the operation and 242 functionality of services. 244 4. The Role of the Gatekeeper 246 The gatekeeper is the module in the service platform that mediates 247 the interactions between the SDK and the SP, settling the development 248 and operational tasks, by performing the basic functions described 249 here. 251 4.1. User Management 253 User management allows the service platform owner to control who can 254 do what in the platform. This feature is particularly important in 255 recursive scenarios, on which we may have a chain of service 256 platforms interacting for the implementation of an end-to-end 257 service. 259 The most basic feature of any user management component will be to 260 know who is the user, a feature that is usually called 261 authentication. Authentication requires user registration and the 262 maintenance of user identity attributes, including not only 263 identification attributes (user identifiers, passwords, public keys, 264 trusted signing certificates, etc.) but also other information 265 supporting different authorization schemas, such as group-based or 266 role-based ones. 268 The definition of what each (known) user can do is usually called 269 authorization. The most common approach nowadays to authorization is 270 called role-based, in which each user is assigned one (or more) 271 role(s) and different roles have different permissions. This extra 272 level of indirection, that is users to roles and roles to 273 permissions, simplifies the overall maintenance of the system, when 274 compared to a more direct scheme, like users permissions. Specially 275 when accessing external APIs, it is common to issue temporary keys 276 (then usually called tokens) which enable temporary access to those 277 APIs. Real keys therefore do not leave the realm on which they are 278 valid and useful, thus increasing the overall level of security. 280 To support a DevOps environment the following roles are considered: 282 o Developer, able to publish and update service packages on the 283 service platform through the SDK, as well as other operations 284 related to service package status. 286 o Service provider, in charge of structuring and managing the 287 services available for a certain organization, or organizational 288 group, defining an administrative domain. 290 o Customer, as a user of the public services available for the 291 administrative domain they belong to, managing their lifecycles 292 (instantiating, pausing, resuming, retiring...). 294 o Service platform admin, with management capabilities on the 295 platform itself, as well as superuser-like control over the 296 available services. These capabilities include the registration 297 of roles and users, and the association of users to roles, 298 enabling the authentication and authorization mechanisms described 299 above. 301 4.2. Package Management 303 The gatekeeper receives the software to be validated in the form of 304 packages. Package management is mostly about accepting and 305 validating new or updated packages. The metadata describing such 306 packages is called package descriptor, and constitutes the core of 307 the gatekeeper interface. 309 Only known (i.e., successfully authenticated) and authorized users 310 will be able to submit new or revised services through the 311 gatekeeper. On-boarding of a package can only be considered 312 successful when package validation and attestation is successful. 313 Only then the (new version of) the package will become part of the 314 catalogue. On-boarding requests are usually processed in a first 315 come, first served way, otherwise contradictory requests may 316 jeopardize the whole system. The usual solution for this problem is 317 to use a queue mechanism that guarantees this sequence. 319 A package descriptor is validated in several ways: 321 o Syntax, comprising the validation against the expected package 322 descriptor format. 324 o Semantics, which includes the validation of at least the basic 325 parameters. The exact semantic aspects to be validated will 326 depend on the content and format chosen for the package 327 descriptor. 329 o Licensing, by checking that all external dependencies (i.e., 330 packages, libraries or services) have to have their licenses 331 checked before being used. 333 o Tests availability. Although this might be seen as part of the 334 syntactic/semantic correction, there must be a set of tests that 335 can be executed when validating the package. Depending of the 336 scope and complexity of the service, these tests may be a subset 337 of the unit tests or a more elaborate suit of integration tests. 339 o Tests execution. Besides providing a suit of tests, these have to 340 be successfully executed. This execution may (usually will) imply 341 the creation and initialization of at least one test environment. 342 When the package under test depends on other packages, libraries 343 or services, those too should be taken into account in the 344 execution of the package tests. 346 The service package must include signatures, generated by the SDK's 347 packaging tools, that allow the validation of the integrity and 348 authenticity of the package's contents, the component VNFs, and other 349 components (forwarding graphs, test suites, etc.). These signatured 350 can be optionally used to attest the components at different stages 351 of their lifecycle, and/or during runtime. 353 Requests for a change in the life-cycle of a package must be 354 validated. This might be a simple authorization configuration. 356 o Deployment. Valid packages, available at the service platform 357 repository, may receive a request for deployment. Package 358 deployment implies the creation of all the environments and 359 connections needed for the package and its dependencies to work 360 and of an instance of that package. 362 o Instance (re)-configuration. A deployed package instance may need 363 to be configured. A special kind of configuration might be, for 364 packages supporting multi-tenancy, adding a new tenant. The 365 package may have "open parameters" that can only be closed upon 366 instantiation (e.g., an IP address). If a Package upgrade 367 happens, a reconfiguration of the instance must also be made. 369 o Instance (re-)start. When, e.g., configuration changes. 371 o Instance monitoring. This is not strictly a change in the life- 372 cycle, but would require the execution of certain aspects 373 identified by the package descriptor or its components. 375 o Instance stop. Includes soft-stop (i.e., not accepting new 376 requests and letting currently running request reach their end of 377 life normally, with a pre-defined time-out) and hard-stop (i.e., a 378 sudden stop, with requests still being answered by the service). 380 o Instance termination. Frees any resource(s) that were being used, 381 taking care of dependencies. 383 o Removal. It requieres an evaluation of currently running 384 instances and dependencies. 386 4.3. Monitor Data Transfer 388 The gatekeeper is the first point of access to reach the SP from the 389 SDK. Service developers can use their identities from the SDK to 390 access monitor data from the SP. After the successful AuthN/AuthZ 391 phase, developers are granted a session token to access monitoring 392 data. Multiple developers will use different data access views to 393 get their own set of authorized monitor data. 395 It is desirable that the gatekeeper is transparent to the monitor 396 data transfer, acting as a pure forwarder, apart from the AuthN/AuthZ 397 phase. Optionally, the gatekeeper could filter non-numerical 398 monitored data (e.g. obfuscate domain names, IP/MAC addresses...) 399 transferred in logfiles or packet streams. The session token is used 400 by the monitor data management components to decide on which data to 401 expose, so metrics of another user, other services not started by the 402 developer or the SP itself can never be queried by the SDK. In 403 addition, other limits can be enforced, such as: 405 o Limit the number of monitor samples 407 o Limit the data size to be received 409 o Limit the time frame during which metrics are accessible 411 5. Security Considerations 413 The gatekeeper acts as the security enforcement point for all DevOps 414 interactions between the development and operational tasks, and even 415 between different layers in recursive structure. 417 Gatekeeper APIs will have to be secured, providing identification, 418 confidentiality, integrity and non-repudiation. 420 Other potential threats are related to denial-of-service, whereby an 421 adversary could make the whole NFV environment unusable by 422 overloading the gatekeeper with a high number of requests or requests 423 tailored to exhaust its resources. Mechanisms for overload detection 424 and mitigation should be put in place. 426 6. IANA Considerations 428 This document requires no IANA actions. 430 7. Acknowledgements 432 This work has been partially performed in the scope of the SONATA 433 project [SONATA], which has received funding from the European 434 Union's Horizon 2020 research and innovation programme. The authors 435 would like to acknowledge the contributions of their colleagues. 436 This information reflects the consortium's view, but the consortium 437 is not liable for any use that may be made of any of the information 438 contained therein. 440 8. References 442 8.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 446 RFC2119, March 1997, 447 . 449 8.2. Informative References 451 [SONATA] "Project SONATA", . 453 Authors' Addresses 455 Diego R. Lopez 456 Telefonica I+D 457 Zurbaran, 12 458 Madrid, 28010 459 Spain 461 Phone: +34 913 129 041 462 Email: diego.r.lopez@telefonica.com 464 Jose Bonnet 465 Altice Labs 466 Rua Eng. Jose Ferreira Pinto Basto 467 Aveiro, 3810-106 468 Portugal 470 Phone: +351 234 403 200 471 Email: jbonnet@alticelabs.com 473 Manuel Peuster 474 Paderborn University 475 Warburgerstrasse 100 476 Paderborn, 33098 477 Germany 479 Phone: +49 5251 60 4341 480 Email: manuel.peuster@upb.de 482 Pedro A. Aranda Gutierrez 483 UC3M 485 Email: paaguti@hotmail.com