Collaboration Agreement for Security Service Function

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 .

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 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.

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: 'Resilient', in which the provider is expected to handle the whole load of that traffic; and '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). Here are the parameters associated to the collaboration agreement: ca_id: identifies the collaboration agreement and it can be used later to refer to a specific collaboration agreement. initiator: designates the locators (e.g. IP address or FQDN) as well as the authentication credentials associated to the initiator. provider: see initiator collaboration type: indicates the type of collaboration (Best Effort and Resilient). 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. SSF type: designates the type of the security instances running. expiration time: designates the expiration of the collaboration. interconnections: defines how the interconnection between the initiator and the provider is performed. This includes the definition of the alternate path. direction: defines if the provider is expected to be in front of the initiator or behind it.

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: 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. 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. 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. 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: The initiator provides a list of proposals to the provider 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. 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. 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. 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.

Once the collaboration agreement has been agreed between the initiator and provider, the following actions need to be considered during its life cycle. 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. 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. 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. 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.

The following Error message have been considered so far:

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:

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

The collaboration type is defined as follow:

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:

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

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

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

A proposal object can also be defined as follows:

The response object is similar to the request object except that: The response must include a provider object. The proposed list of attribute values must be of size one with the chosen value.

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.