[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
RFC Beautification Working Group                              D. Migault
Internet-Draft                                                A. Ranjbar
Intended status: Informational                                  Ericsson
Expires: December 30, 2016                                 June 28, 2016


         Collaboration Agreement for Security Service Function
               draft-mglt-i2nsf-ssf-collaboration-00.txt

Abstract

   This document specifies a collaboration agreement protocol.  The
   collaboration agreement makes possible individual security services
   functions (SSF) to collaborate with each other.  The collaboration is
   mostly intended for SSF located in different administrative domains,
   in which case the collaboration cannot be performed by a shared
   orchestrator.

   The collaboration between SSF in different domains assumes the
   traffic is steered through the two domains.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 30, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Migault & Ranjbar       Expires December 30, 2016               [Page 1]


Internet-Draft         ssf-collaboration-agreement             June 2016


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Collaboration Agreement . . . . . . . . . . . . . . . . . . .   3
   4.  Collaboration Agreement Protocol  . . . . . . . . . . . . . .   4
   5.  Collaboration Agreement Management operations . . . . . . . .   6
   6.  Error Message handling  . . . . . . . . . . . . . . . . . . .   6
   7.  Payload Format  . . . . . . . . . . . . . . . . . . . . . . .   7
     7.1.  Collaboration Agreement Objects . . . . . . . . . . . . .   7
     7.2.  Collaboration Agreement Protocol  . . . . . . . . . . . .  11
       7.2.1.  Collaboration Agreement Protocol Request  . . . . . .  11
       7.2.2.  Collaboration Agreement Protocol Response . . . . . .  12
     7.3.  Collaboration Agreement Protocol Additional Operations  .  12
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Security Service Function (SSF) has been deployed to mitigate and
   detect malicious traffic and security threats in networks.

   A typical use case would consider today's cloud-based services were a
   data flows is forwarded from the Internet Service Provider to the
   cloud which hosts the destination service or any on-path services.
   The services deployed in the cloud are at least partly implemented
   using a combination of one or more SSF.  Similarly, the ISP may also
   implement a set of on path SSF.  The purpose of the collaboration is
   to enable a SSF running in the cloud administrative domain to take
   advantage of specific SSF running in the ISP administrative domain.
   The SSF may be of same type or of different type.

   As the SSFs belong to different administrative domains, collaboration
   between these two SSFs is unlikely to happen through a common shared



Migault & Ranjbar       Expires December 30, 2016               [Page 2]


Internet-Draft         ssf-collaboration-agreement             June 2016


   orchestrator.  To enable the collaboration between individual SSFs, a
   collaboration agreement protocol is proposed in this document.  This
   protocol is expected to provide: better detection by exchanging real-
   time information about the detected attacks between SSFs, better
   mitigation by enforcing mitigation strategies on more effective
   network segments (e.g. cloud vs ISP), and better resource usage by
   eliminating the need for frequent deployment of similar service
   functions and by spreading the tasks among different SSFs.

3.  Collaboration Agreement

   The SSFs initiating and accepting the collaboration are called,
   respectively, 'initiator' and 'provider'.  The initiator sends to
   potential providers a Collaboration Agreement (CA), which defines the
   necessary attributes involved in the collaboration.  Such attributes
   are expected not to be SSF specific.  However attributes that
   characterize the SSF, such as the SFF type, input and output flows,
   may be part of the CA simply to allow collaborators to define whether
   or not they are eligible to provide the corresponding services.

   For management purposes, the collaboration agreement should also
   include an 'agreement ID' and a 'duration' indicating its lifespan.
   It is the responsibility of the 'initiator' to renew the agreement
   before it expires, although the 'provider' should also be able to
   notify the former that the agreement needs to be revised or
   interrupted earlier due to some unexpected event.

   Two collaboration modes are envisioned:

   1)  'Resilient', in which the provider is expected to handle the
       whole load of that traffic; and

   2)  'Best Effort', which indicates that the provider supplies the
       service for a fraction of the load.  When the Best Effort mode is
       chosen, an 'alternate path' indicates where non-treated traffic
       is forwarded, and 'resource' indicates the resources allocated
       for the service.  The use of 'alternate path' enhances the
       collaboration between SSFs by allowing the provider to
       temporarily assign specific amount of resources for handling the
       packets and send the non-treated traffic through the alternate
       path to be processed by the initiator.  The resources assigned in
       the Best Effort mode can be expressed in specific ways, such as a
       combination of various computational resources e.g., CPU, I/O,
       bandwidth, packet rate, or maximum latency.  The manner by which
       such resources are controlled is left for the provider's
       implementation (e.g., by leveraging containers and micro services
       technologies).




Migault & Ranjbar       Expires December 30, 2016               [Page 3]


Internet-Draft         ssf-collaboration-agreement             June 2016


   Here are the parameters associated to the collaboration agreement:

   o  ca_id: identifies the collaboration agreement and it can be used
      later to refer to a specific collaboration agreement.

   o  initiator: designates the locators (e.g.  IP address or FQDN) as
      well as the authentication credentials associated to the
      initiator.

   o  provider: see initiator

   o  collaboration type: indicates the type of collaboration (Best
      Effort and Resilient).

   o  resource: designates the resources agreed on between the initiator
      and the provider.  Note that this parameter is optional as
      resources are only negotiated when collaboration is in a best
      effort mode.

   o  SSF type: designates the type of the security instances running.

   o  expiration time: designates the expiration of the collaboration.

   o  interconnections: defines how the interconnection between the
      initiator and the provider is performed.  This includes the
      definition of the alternate path.

   o  direction: defines if the provider is expected to be in front of
      the initiator or behind it.

4.  Collaboration Agreement Protocol

   The purpose of the collaboration agreement protocol is to negotiate
   between the initiator and provider and make an agreement for
   cooperation between SSFs placed in a single or multiple domains.
   Currently, the collaboration agreement protocol is always originated
   from the initiator.  In other words, the provider is not initiating
   the exchanges as to announce what it can provide.

   The collaboration agreement protocol should include the following
   attributes:

   o  ca_id: the is the collaboration agreement identifier.  In a case
      the value is not acceptable, an ERROR_UNACCEPTABLE_CA_ID MUST be
      returned.  There are, however, little reasons such a collision
      occurs.  If such a collision occurs, the negotiation is aborted
      and must be restarted with a new ca_id.




Migault & Ranjbar       Expires December 30, 2016               [Page 4]


Internet-Draft         ssf-collaboration-agreement             June 2016


   o  initiator: it includes information that the initiator offers to
      the provider.  Upon receiving the request for collaboration, the
      provider may reject the collaboration agreement by sending a
      ERROR_UNACCEPTABLE_INITIATOR.

   o  provider: it consists of information about the provider to be
      verified by the initiator.  Upon receiving this information, the
      initiator my abort the negotiation with
      ERROR_UNACCEPTABLE_PROVIDER.  The reason for refusing the
      provider, may be that the provider is not in a white list or that
      the provider has been explicitly banned by the initiator.

   o  resource: it represents allocated resources by the provider for
      collaboration with the initiator.  When the collaboration mode is
      set to Resilient, the resource is not expected to be provided by
      the provider.  For the best effort mode, the resource provided by
      the provider may consider the indication provided by the initiator
      or not.  Given the resource provided by the provider, the
      initiator is likely to close the collaboration or to accept it.

   In order to define a flexible framework, the negotiation steps
   between the initiator and provider is designed as mentioned below:

   1.  The initiator provides a list of proposals to the provider

   2.  A proposal may contain multiple proposition for a given
       attribute.  For example, let P1 be a proposal offered by the
       initiator.  In this case, the initiator may be willing to make an
       agreement with the providers either in Best Effort or Resilient
       modes.  In this case, the initiator will set P1 with an object of
       collaboration type set to Best Effort AND an object of
       collaboration type set to Resilient.

   3.  When multiple proposals are received by the provider, the
       provider is expected to choose a single proposal.  The chosen
       proposal is the one that contains the attributes that fits the
       provider.

   4.  When a proposal is chosen, the provider must select for each
       attribute the preferred value.  More especially, when multiple
       values for a same attribute type are available, the provider
       selects the preferred value for that attribute.  Also, the chosen
       proposal must have the same amount of attribute types which means
       the provider is not allowed to remove some attributes or
       selectively reject attributes.






Migault & Ranjbar       Expires December 30, 2016               [Page 5]


Internet-Draft         ssf-collaboration-agreement             June 2016


   5.  The provider may send an acceptable proposal to the initiator.
       If none of the proposals are acceptable by the provider, the
       provider returns a ERROR_UNACCEPTABLE_PROPOSALS.

5.  Collaboration Agreement Management operations

   Once the collaboration agreement has been agreed between the
   initiator and provider, the following actions need to be considered
   during its life cycle.

   o  END_AGREEMENT: This action can be performed by either peers, that
      is to say the initiator or the provider.  This action requires the
      ca_id and credentials to identify peers in the agreement.

   o  UPDATE_EXPIRATION_DATE: This action is initiated by either peers.
      It intends to update the expiration date.  The expiration date can
      be extended or advanced.  The input parameters are the ca_id and
      the new expiration date.  The possible responses are to accept or
      reject this request.  In case of rejection,
      ERROR_UNACCEPTABLE_NEW_EXPIRATION_DATE is sent to the requested
      peer.

   o  UPDATE_RESOURCE: This action is expected to be triggered by the
      provider.  It indicates the amount of resources the provider
      offers for collaboration.  This is an informative message.  It may
      be useful for the initiator to know how much resource will be
      dedicated to the collaboration by the provider so it can adjust
      its strategy.

   o  REDIRECT_SSF: This action is triggered when peers change their
      location.  This actions is initiated by either peers.  It may
      result in changes in Alternate Path in case of Best Effort mode.

6.  Error Message handling

   The following Error message have been considered so far:

       ERROR_UNACCEPTABLE_CA_ID
       ERROR_UNACCEPTABLE_PROVIDER
       ERROR_UNACCEPTABLE_INITIATOR
       ERROR_UNACCEPTABLE_PROPOSALS
       ERROR_UNACCEPTABLE_NEW_EXPIRATION_DATE









Migault & Ranjbar       Expires December 30, 2016               [Page 6]


Internet-Draft         ssf-collaboration-agreement             June 2016


7.  Payload Format

7.1.  Collaboration Agreement Objects

   This section represents the Collaboration Agreement object.  The
   collaboration agreement is an object with properties.  Some of these
   properties are object themselves.  In order to enrich the object
   definition, the Collaboration is defined on different objects
   including 'peer' and 'resource' objects.

   'Peer' object represents the necessary information associated to a
   peer.  A peer can be either the initiator or provider.  The
   description of a peer object is as follows:

   {
     "peer":{
       "type": "object",
       "description": "provides different elements associated to the
                       initiator or the provider. This includes
                       location as well as authentication credentials",
       "properties": {
         "rsakey": {
           "type": "string",
           "description": "RSA public key used to identify the
                           initiator"
         },
         "cert": {
           "type": "array",
           "description": "list of certificates to authenticate the
                           initiator"
         },
         "fqdn": {
           "type": "string",
           "description": " FQDN associated to the initiator"
         },
         "ipv4": {
           "type": "string",
           "description": "IPv4 address used to reach the initiator"
         },
         "ipv6": {
           "type": "string",
           "description": "IPv6 address used to reach the initiator"
         }
       }
     }
   }





Migault & Ranjbar       Expires December 30, 2016               [Page 7]


Internet-Draft         ssf-collaboration-agreement             June 2016


   The following object designates the resources agreed between the
   initiator and the provider.

   {
     "resource": {
       "type":object,
       "description": "resource engaged into the collaboration",
       "properties": {
         "cpu": {
           "type": "number",
           "description": "cpu limit"
         },
         "memory": {
           "type": "number",
           "description": "memory limit"
         },
         "net": {
           "type": "number",
           "description": "net limit"
         },
         "blkio": {
           "type": "number",
           "description": "block limit"
         }
       }
     }
   }

   The collaboration type is defined as follow:


       TYPE          CODE
       Resilient      0
       Best Effort    1


   SSF instance types can be extended to any number of available
   services.  We do not limit SSF types and we expect to extend this
   number in future.  Some example SSFs can be defined as follows:


       TYPE               CODE
       Rate limiting       0
       DNSoverTCP          1
       PacketDropper       2






Migault & Ranjbar       Expires December 30, 2016               [Page 8]


Internet-Draft         ssf-collaboration-agreement             June 2016


   The following object is a Collaboration Agreement object which
   includes several properties to define an agreement between the
   provider and initiator.
















































Migault & Ranjbar       Expires December 30, 2016               [Page 9]


Internet-Draft         ssf-collaboration-agreement             June 2016


   {
     "type": "Collaboration Agreement",
     "description": "This object designates the Collaboration
                     Agreement properties",
     "properties": {
       "ca_id" : {
         "type": "number",
         "description" : "unique identifier of the Collaboration
                          agreement"
       },
       "initiator": {
         "type": "peer",
         "description": "provides the different elements associated
                         to the initiator. This includes location
                         as well as authentication credentials"
           },
       "provider": {
         "type": "peer",
         "description": "provides the different elements associated
                         to the provider. This includes location as
                         well as authentication credentials"
       },
       "collaboration_type": {
         "type": "number",
         "description": "defines whether the type of the
                         collaboration"
       },
       "security_service_instance_type": {
         "type": "number",
         "description": "the type of security service instance"
       },
       "interconnections":{
         "type": "interconnections",
         "description": "the type of security service instance"
       },
       "resource":{
         "type": "resource",
         "description": "the type of security service instance"
       },
       "direction":{
         "type": "direction",
         "description": "indicates whether the provider MUST
                         be placed downstream or upstream"
       }
     }
   }





Migault & Ranjbar       Expires December 30, 2016              [Page 10]


Internet-Draft         ssf-collaboration-agreement             June 2016


7.2.  Collaboration Agreement Protocol

   The collaboration agreement protocol can be defined as request or
   response objects.

7.2.1.  Collaboration Agreement Protocol Request

   The following object defines the request object which includes
   information about initiator, resources and a set of proposal objects.

   {
     "type": "collaboration protocol agreement request",
     "description": "object",
     "properties": {
       "ca_id" : {
         "type": "number",
         "description" : "unique identifier for collaboration
                          agreement"
       },
       "initiator":{
         "type": "peer",
         "description": "provides different elements associated
                         to the initiator. This includes location
                         as well as authentication credentials"
       },
       "informative resource requested":{
         "type": "resource",
        "description": "the type of security service instance"
       },
       "proposals":{
         "type": "Array",
         "description": "Array of proposals offered by the initiator"
       }
     }
   }

   A proposal object can also be defined as follows:














Migault & Ranjbar       Expires December 30, 2016              [Page 11]


Internet-Draft         ssf-collaboration-agreement             June 2016


   {
     "type": "object",
     "description": "A single proposal with a set of attributes.
                     The expected attribute types are collaboration
                     type, security service instance type and
                     interconnections",
     "properties":{
       "proposal_id":{
         "type": "number"
       }
       "proposed-attribute":{
         "type": "object"
         "properties":{
           "attribute-type"{
             type: string
           }
           "attribute-values"{
             "type": "array"
             "items": {
               attribute-value
             }
           }
         }
       }
     }
   }

7.2.2.  Collaboration Agreement Protocol Response

   The response object is similar to the request object except that:

   o  The response must include a provider object.

   o  The proposed list of attribute values must be of size one with the
      chosen value.

7.3.  Collaboration Agreement Protocol Additional Operations

   When the initiator and provider are placed in different domains,
   additional orchestration operations might be needed between domains
   to make an agreement.  Moreover, in case of Best Effort mode,
   additional operations is needed to establish an alternate path and
   separate the treated traffic from non-treated traffic e.g. by
   deploying classifiers on the path.







Migault & Ranjbar       Expires December 30, 2016              [Page 12]


Internet-Draft         ssf-collaboration-agreement             June 2016


8.  Security Considerations

9.  IANA Considerations

10.  Acknowledgements

11.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

Authors' Addresses

   Daniel Migault
   Ericsson
   8400 boulevard Decarie
   Montreal, QC   H4P 2N2
   Canada

   Phone: +1 514-452-2160
   Email: daniel.migault@ericsson.com


   Alireza Ranjbar
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Phone: +358-442992904
   Email: alireza.ranjbar@ericsson.com


















Migault & Ranjbar       Expires December 30, 2016              [Page 13]