| 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
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.
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 (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 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.
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].
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:
Here are the parameters associated to the collaboration agreement:
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:
In order to define a flexible framework, the negotiation steps between the initiator and provider is designed as mentioned below:
Once the collaboration agreement has been agreed between the initiator and provider, the following actions need to be considered during its life cycle.
ERROR_UNACCEPTABLE_CA_ID
ERROR_UNACCEPTABLE_PROVIDER
ERROR_UNACCEPTABLE_INITIATOR
ERROR_UNACCEPTABLE_PROPOSALS
ERROR_UNACCEPTABLE_NEW_EXPIRATION_DATE
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":{
"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"
}
}
}
}
'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:
{
"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 following object designates the resources agreed between the initiator and the provider.
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
{
"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"
}
}
}
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.
{
"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"
}
}
}
The following object defines the request object which includes information about initiator, resources and a set of proposal objects.
{
"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
}
}
}
}
}
}
A proposal object can also be defined as follows:
The response object is similar to the request object except that:
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.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |