idnits 2.17.1 draft-mglt-i2nsf-ssf-collaboration-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 : ---------------------------------------------------------------------------- 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 date (June 28, 2016) is 2852 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RFC Beautification Working Group D. Migault 3 Internet-Draft A. Ranjbar 4 Intended status: Informational Ericsson 5 Expires: December 30, 2016 June 28, 2016 7 Collaboration Agreement for Security Service Function 8 draft-mglt-i2nsf-ssf-collaboration-00.txt 10 Abstract 12 This document specifies a collaboration agreement protocol. The 13 collaboration agreement makes possible individual security services 14 functions (SSF) to collaborate with each other. The collaboration is 15 mostly intended for SSF located in different administrative domains, 16 in which case the collaboration cannot be performed by a shared 17 orchestrator. 19 The collaboration between SSF in different domains assumes the 20 traffic is steered through the two domains. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 30, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Collaboration Agreement . . . . . . . . . . . . . . . . . . . 3 59 4. Collaboration Agreement Protocol . . . . . . . . . . . . . . 4 60 5. Collaboration Agreement Management operations . . . . . . . . 6 61 6. Error Message handling . . . . . . . . . . . . . . . . . . . 6 62 7. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Collaboration Agreement Objects . . . . . . . . . . . . . 7 64 7.2. Collaboration Agreement Protocol . . . . . . . . . . . . 11 65 7.2.1. Collaboration Agreement Protocol Request . . . . . . 11 66 7.2.2. Collaboration Agreement Protocol Response . . . . . . 12 67 7.3. Collaboration Agreement Protocol Additional Operations . 12 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 71 11. Normative References . . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Requirements notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Introduction 82 Security Service Function (SSF) has been deployed to mitigate and 83 detect malicious traffic and security threats in networks. 85 A typical use case would consider today's cloud-based services were a 86 data flows is forwarded from the Internet Service Provider to the 87 cloud which hosts the destination service or any on-path services. 88 The services deployed in the cloud are at least partly implemented 89 using a combination of one or more SSF. Similarly, the ISP may also 90 implement a set of on path SSF. The purpose of the collaboration is 91 to enable a SSF running in the cloud administrative domain to take 92 advantage of specific SSF running in the ISP administrative domain. 93 The SSF may be of same type or of different type. 95 As the SSFs belong to different administrative domains, collaboration 96 between these two SSFs is unlikely to happen through a common shared 97 orchestrator. To enable the collaboration between individual SSFs, a 98 collaboration agreement protocol is proposed in this document. This 99 protocol is expected to provide: better detection by exchanging real- 100 time information about the detected attacks between SSFs, better 101 mitigation by enforcing mitigation strategies on more effective 102 network segments (e.g. cloud vs ISP), and better resource usage by 103 eliminating the need for frequent deployment of similar service 104 functions and by spreading the tasks among different SSFs. 106 3. Collaboration Agreement 108 The SSFs initiating and accepting the collaboration are called, 109 respectively, 'initiator' and 'provider'. The initiator sends to 110 potential providers a Collaboration Agreement (CA), which defines the 111 necessary attributes involved in the collaboration. Such attributes 112 are expected not to be SSF specific. However attributes that 113 characterize the SSF, such as the SFF type, input and output flows, 114 may be part of the CA simply to allow collaborators to define whether 115 or not they are eligible to provide the corresponding services. 117 For management purposes, the collaboration agreement should also 118 include an 'agreement ID' and a 'duration' indicating its lifespan. 119 It is the responsibility of the 'initiator' to renew the agreement 120 before it expires, although the 'provider' should also be able to 121 notify the former that the agreement needs to be revised or 122 interrupted earlier due to some unexpected event. 124 Two collaboration modes are envisioned: 126 1) 'Resilient', in which the provider is expected to handle the 127 whole load of that traffic; and 129 2) 'Best Effort', which indicates that the provider supplies the 130 service for a fraction of the load. When the Best Effort mode is 131 chosen, an 'alternate path' indicates where non-treated traffic 132 is forwarded, and 'resource' indicates the resources allocated 133 for the service. The use of 'alternate path' enhances the 134 collaboration between SSFs by allowing the provider to 135 temporarily assign specific amount of resources for handling the 136 packets and send the non-treated traffic through the alternate 137 path to be processed by the initiator. The resources assigned in 138 the Best Effort mode can be expressed in specific ways, such as a 139 combination of various computational resources e.g., CPU, I/O, 140 bandwidth, packet rate, or maximum latency. The manner by which 141 such resources are controlled is left for the provider's 142 implementation (e.g., by leveraging containers and micro services 143 technologies). 145 Here are the parameters associated to the collaboration agreement: 147 o ca_id: identifies the collaboration agreement and it can be used 148 later to refer to a specific collaboration agreement. 150 o initiator: designates the locators (e.g. IP address or FQDN) as 151 well as the authentication credentials associated to the 152 initiator. 154 o provider: see initiator 156 o collaboration type: indicates the type of collaboration (Best 157 Effort and Resilient). 159 o resource: designates the resources agreed on between the initiator 160 and the provider. Note that this parameter is optional as 161 resources are only negotiated when collaboration is in a best 162 effort mode. 164 o SSF type: designates the type of the security instances running. 166 o expiration time: designates the expiration of the collaboration. 168 o interconnections: defines how the interconnection between the 169 initiator and the provider is performed. This includes the 170 definition of the alternate path. 172 o direction: defines if the provider is expected to be in front of 173 the initiator or behind it. 175 4. Collaboration Agreement Protocol 177 The purpose of the collaboration agreement protocol is to negotiate 178 between the initiator and provider and make an agreement for 179 cooperation between SSFs placed in a single or multiple domains. 180 Currently, the collaboration agreement protocol is always originated 181 from the initiator. In other words, the provider is not initiating 182 the exchanges as to announce what it can provide. 184 The collaboration agreement protocol should include the following 185 attributes: 187 o ca_id: the is the collaboration agreement identifier. In a case 188 the value is not acceptable, an ERROR_UNACCEPTABLE_CA_ID MUST be 189 returned. There are, however, little reasons such a collision 190 occurs. If such a collision occurs, the negotiation is aborted 191 and must be restarted with a new ca_id. 193 o initiator: it includes information that the initiator offers to 194 the provider. Upon receiving the request for collaboration, the 195 provider may reject the collaboration agreement by sending a 196 ERROR_UNACCEPTABLE_INITIATOR. 198 o provider: it consists of information about the provider to be 199 verified by the initiator. Upon receiving this information, the 200 initiator my abort the negotiation with 201 ERROR_UNACCEPTABLE_PROVIDER. The reason for refusing the 202 provider, may be that the provider is not in a white list or that 203 the provider has been explicitly banned by the initiator. 205 o resource: it represents allocated resources by the provider for 206 collaboration with the initiator. When the collaboration mode is 207 set to Resilient, the resource is not expected to be provided by 208 the provider. For the best effort mode, the resource provided by 209 the provider may consider the indication provided by the initiator 210 or not. Given the resource provided by the provider, the 211 initiator is likely to close the collaboration or to accept it. 213 In order to define a flexible framework, the negotiation steps 214 between the initiator and provider is designed as mentioned below: 216 1. The initiator provides a list of proposals to the provider 218 2. A proposal may contain multiple proposition for a given 219 attribute. For example, let P1 be a proposal offered by the 220 initiator. In this case, the initiator may be willing to make an 221 agreement with the providers either in Best Effort or Resilient 222 modes. In this case, the initiator will set P1 with an object of 223 collaboration type set to Best Effort AND an object of 224 collaboration type set to Resilient. 226 3. When multiple proposals are received by the provider, the 227 provider is expected to choose a single proposal. The chosen 228 proposal is the one that contains the attributes that fits the 229 provider. 231 4. When a proposal is chosen, the provider must select for each 232 attribute the preferred value. More especially, when multiple 233 values for a same attribute type are available, the provider 234 selects the preferred value for that attribute. Also, the chosen 235 proposal must have the same amount of attribute types which means 236 the provider is not allowed to remove some attributes or 237 selectively reject attributes. 239 5. The provider may send an acceptable proposal to the initiator. 240 If none of the proposals are acceptable by the provider, the 241 provider returns a ERROR_UNACCEPTABLE_PROPOSALS. 243 5. Collaboration Agreement Management operations 245 Once the collaboration agreement has been agreed between the 246 initiator and provider, the following actions need to be considered 247 during its life cycle. 249 o END_AGREEMENT: This action can be performed by either peers, that 250 is to say the initiator or the provider. This action requires the 251 ca_id and credentials to identify peers in the agreement. 253 o UPDATE_EXPIRATION_DATE: This action is initiated by either peers. 254 It intends to update the expiration date. The expiration date can 255 be extended or advanced. The input parameters are the ca_id and 256 the new expiration date. The possible responses are to accept or 257 reject this request. In case of rejection, 258 ERROR_UNACCEPTABLE_NEW_EXPIRATION_DATE is sent to the requested 259 peer. 261 o UPDATE_RESOURCE: This action is expected to be triggered by the 262 provider. It indicates the amount of resources the provider 263 offers for collaboration. This is an informative message. It may 264 be useful for the initiator to know how much resource will be 265 dedicated to the collaboration by the provider so it can adjust 266 its strategy. 268 o REDIRECT_SSF: This action is triggered when peers change their 269 location. This actions is initiated by either peers. It may 270 result in changes in Alternate Path in case of Best Effort mode. 272 6. Error Message handling 274 The following Error message have been considered so far: 276 ERROR_UNACCEPTABLE_CA_ID 277 ERROR_UNACCEPTABLE_PROVIDER 278 ERROR_UNACCEPTABLE_INITIATOR 279 ERROR_UNACCEPTABLE_PROPOSALS 280 ERROR_UNACCEPTABLE_NEW_EXPIRATION_DATE 282 7. Payload Format 284 7.1. Collaboration Agreement Objects 286 This section represents the Collaboration Agreement object. The 287 collaboration agreement is an object with properties. Some of these 288 properties are object themselves. In order to enrich the object 289 definition, the Collaboration is defined on different objects 290 including 'peer' and 'resource' objects. 292 'Peer' object represents the necessary information associated to a 293 peer. A peer can be either the initiator or provider. The 294 description of a peer object is as follows: 296 { 297 "peer":{ 298 "type": "object", 299 "description": "provides different elements associated to the 300 initiator or the provider. This includes 301 location as well as authentication credentials", 302 "properties": { 303 "rsakey": { 304 "type": "string", 305 "description": "RSA public key used to identify the 306 initiator" 307 }, 308 "cert": { 309 "type": "array", 310 "description": "list of certificates to authenticate the 311 initiator" 312 }, 313 "fqdn": { 314 "type": "string", 315 "description": " FQDN associated to the initiator" 316 }, 317 "ipv4": { 318 "type": "string", 319 "description": "IPv4 address used to reach the initiator" 320 }, 321 "ipv6": { 322 "type": "string", 323 "description": "IPv6 address used to reach the initiator" 324 } 325 } 326 } 327 } 328 The following object designates the resources agreed between the 329 initiator and the provider. 331 { 332 "resource": { 333 "type":object, 334 "description": "resource engaged into the collaboration", 335 "properties": { 336 "cpu": { 337 "type": "number", 338 "description": "cpu limit" 339 }, 340 "memory": { 341 "type": "number", 342 "description": "memory limit" 343 }, 344 "net": { 345 "type": "number", 346 "description": "net limit" 347 }, 348 "blkio": { 349 "type": "number", 350 "description": "block limit" 351 } 352 } 353 } 354 } 356 The collaboration type is defined as follow: 358 TYPE CODE 359 Resilient 0 360 Best Effort 1 362 SSF instance types can be extended to any number of available 363 services. We do not limit SSF types and we expect to extend this 364 number in future. Some example SSFs can be defined as follows: 366 TYPE CODE 367 Rate limiting 0 368 DNSoverTCP 1 369 PacketDropper 2 371 The following object is a Collaboration Agreement object which 372 includes several properties to define an agreement between the 373 provider and initiator. 375 { 376 "type": "Collaboration Agreement", 377 "description": "This object designates the Collaboration 378 Agreement properties", 379 "properties": { 380 "ca_id" : { 381 "type": "number", 382 "description" : "unique identifier of the Collaboration 383 agreement" 384 }, 385 "initiator": { 386 "type": "peer", 387 "description": "provides the different elements associated 388 to the initiator. This includes location 389 as well as authentication credentials" 390 }, 391 "provider": { 392 "type": "peer", 393 "description": "provides the different elements associated 394 to the provider. This includes location as 395 well as authentication credentials" 396 }, 397 "collaboration_type": { 398 "type": "number", 399 "description": "defines whether the type of the 400 collaboration" 401 }, 402 "security_service_instance_type": { 403 "type": "number", 404 "description": "the type of security service instance" 405 }, 406 "interconnections":{ 407 "type": "interconnections", 408 "description": "the type of security service instance" 409 }, 410 "resource":{ 411 "type": "resource", 412 "description": "the type of security service instance" 413 }, 414 "direction":{ 415 "type": "direction", 416 "description": "indicates whether the provider MUST 417 be placed downstream or upstream" 418 } 419 } 420 } 422 7.2. Collaboration Agreement Protocol 424 The collaboration agreement protocol can be defined as request or 425 response objects. 427 7.2.1. Collaboration Agreement Protocol Request 429 The following object defines the request object which includes 430 information about initiator, resources and a set of proposal objects. 432 { 433 "type": "collaboration protocol agreement request", 434 "description": "object", 435 "properties": { 436 "ca_id" : { 437 "type": "number", 438 "description" : "unique identifier for collaboration 439 agreement" 440 }, 441 "initiator":{ 442 "type": "peer", 443 "description": "provides different elements associated 444 to the initiator. This includes location 445 as well as authentication credentials" 446 }, 447 "informative resource requested":{ 448 "type": "resource", 449 "description": "the type of security service instance" 450 }, 451 "proposals":{ 452 "type": "Array", 453 "description": "Array of proposals offered by the initiator" 454 } 455 } 456 } 458 A proposal object can also be defined as follows: 460 { 461 "type": "object", 462 "description": "A single proposal with a set of attributes. 463 The expected attribute types are collaboration 464 type, security service instance type and 465 interconnections", 466 "properties":{ 467 "proposal_id":{ 468 "type": "number" 469 } 470 "proposed-attribute":{ 471 "type": "object" 472 "properties":{ 473 "attribute-type"{ 474 type: string 475 } 476 "attribute-values"{ 477 "type": "array" 478 "items": { 479 attribute-value 480 } 481 } 482 } 483 } 484 } 485 } 487 7.2.2. Collaboration Agreement Protocol Response 489 The response object is similar to the request object except that: 491 o The response must include a provider object. 493 o The proposed list of attribute values must be of size one with the 494 chosen value. 496 7.3. Collaboration Agreement Protocol Additional Operations 498 When the initiator and provider are placed in different domains, 499 additional orchestration operations might be needed between domains 500 to make an agreement. Moreover, in case of Best Effort mode, 501 additional operations is needed to establish an alternate path and 502 separate the treated traffic from non-treated traffic e.g. by 503 deploying classifiers on the path. 505 8. Security Considerations 507 9. IANA Considerations 509 10. Acknowledgements 511 11. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, 515 DOI 10.17487/RFC2119, March 1997, 516 . 518 Authors' Addresses 520 Daniel Migault 521 Ericsson 522 8400 boulevard Decarie 523 Montreal, QC H4P 2N2 524 Canada 526 Phone: +1 514-452-2160 527 Email: daniel.migault@ericsson.com 529 Alireza Ranjbar 530 Ericsson 531 Hirsalantie 11 532 Jorvas 02420 533 Finland 535 Phone: +358-442992904 536 Email: alireza.ranjbar@ericsson.com