Subject: Re: [I2nsf] New Version Notification for draft-mglt-i2nsf-ssf-collaboration-00.txt

From: Daniel Migault <[email-masked]>
Date: Thu, 7 Jul 2016 10:04:39 -0400

Hi,

This mail is an attempt to clarify:
    1) the different parties involved into the agreement
    2) key information exchanged.

The negotiation protocol has been designed to be context independent, which
means it could be re-used in various scenrios where some agreement is
needed between different parties. However, its design has been motivated
for the deployment of network security functions.

Currently most of the protocol uses HTTP/JSON. What we would like to
understand is whether the design fits I2NSF architecture, and how to make
this work more inline with I2NSF. We also have additional questions we would
like to get feed backs on.

1) Different parties involved in the negotiation

In our specific context, the collaboration agreement between independent
domains involves
  - 1) allocation of computing resources - such as the instantiation of a
NSF, which is typically implemented in a VM or a container
  - 2) network management - such as steering the output flows of the SFs
through different paths depending on the SF evaluation. In our case, the
collaboration is agreed between the security orchestrators of each domain.
With I2NSF terminology, it seems to me that collaboration is likely to
occur between the "Network Operator Management Security Controllers of the
two respective domains.

That said, it is a design choice to centralize the management of the
Security on each domain, and we also consider collaboration between NSF or
between NSF and the Security Controller. In our case, the DOTS seems a
better interface between NSF and the Security Controller.

2) Key information exchanged

As mentioned earlier, the collaboration protocol has been designed to
remain flexible as the key information to be agreed on may vary in
different situations. This is the reason the protocol has been designed to
set a collaboration, and any key information associated to the
collaboration could be negotiated on top of it.
In our specific case, the main information the two domains agree on are:
    - The type of Network Security Service: The service could be a
firewall, a anti-tcp-syn service , a drop service..... The main difficulty
on defining the service is to adopt an consistent designation of the
service. We would appreciate discussion and opinion regarding this topic.
   - The resource engaged into the collaboration. Again, there is also a
large panel on how to describe resource. One way would consist in adopting
a high level description such as proposed by AWS, finer description could
also include the cgroup terminology... Again any feed back on how you think
this type of resource should be described would be appreciated.
   - Network Configuration: For this type of resource, we designated it as
"Alternate Path" the path where packets that have not been treated are
steered.

BR,
Daniel

On Tue, Jun 28, 2016 at 11:42 AM, Daniel Migault <daniel.migault@ericsson
.com> wrote:

> Hi,
>
> Please find our draft for elaborating a collaboration between security
> services locate in different administrative domains.
>
> Feed backs /Comments are welcome!
> BR,
> Daniel
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 28, 2016 6:40 PM
> To: Daniel Migault; Alireza Ranjbar
> Subject: New Version Notification for
> draft-mglt-i2nsf-ssf-collaboration-00.txt
>
>
> A new version of I-D, draft-mglt-i2nsf-ssf-collaboration-00.txt
> has been successfully submitted by Daniel Migault and posted to the IETF
> repository.
>
> Name:           draft-mglt-i2nsf-ssf-collaboration
> Revision:       00
> Title:          Collaboration Agreement for Security Service Function
> Document date:  2016-06-28
> Group:          Individual Submission
> Pages:          13
> URL:
> https://www.ietf.org/internet-drafts/draft-mglt-i2nsf-ssf-collaboration-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mglt-i2nsf-ssf-collaboration/
> Htmlized:
> https://tools.ietf.org/html/draft-mglt-i2nsf-ssf-collaboration-00
>
>
> 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.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 7 Jul 2016 10:22:43 -0400

Hi Med,

Thank you for the feed backs. Please see inline my responses. I would be
happy discuss more in depth these questions in Berlin!

BR,
Daniel

On Wed, Jun 29, 2016 at 8:19 AM, <[email-masked]> wrote:

> Hi Daniel, all,
>
> Thank you for sharing this draft.
>
> I have some high-level questions about this proposal:
> * In which deployment case you think that a service function will take the
> responsibility to contact another service function located in another
> domain to ask for collaboration? Wouldn't that be the responsibility of the
> respective administrative entities managing those domains?
>

MGLT: In our case, the collaboration is established between between the
administrative entity of each domain. Once the provider and the initiator
have agreed on setting a collaboration defined by the resources to be
engaged, as well as the service, I would say the collaboration is set. in
some cases, the security service instantiated may require additional
configurations. For example, when a firewall is being instantiated by the
provider, the initiator may then need to configure the firewall. Such
configuration in our view is not pat of the collaboration. Instead what
would be part of the collaboration is the ability for the firewall to be
configured by X using protocol Y. X could be a SF or the orchestrator of
the domain.

> * Based on which criteria an SSF may decide that it needs collaboration
> with another SSF? Wouldn't that be driven by service requirements and
> objectives (that are not visible to a monolithic SSF)?
>

MGLT: In our case, the criteria is when a DDoS attack is being detected,
and the attack can be better mitigated in another domain. This means that
the orchestrator takes the decision given the various inputs it receives
from the SSFs. But the collaboration could also be requested by a single
SSF.

> * Given that service functions deployed in a given domain are unlikely to
> be disclosed outside that domain, how SSF discovery is achieved?
>

MGLT: That is a good question. Currently we assume that the you know the
next upper/ lower provider you woudl like to set the collaboration with. We
have not yet designed an appropriated SSF discovery protocol. One reason
also for it is that we need to think of a common language for service
designation.

> * Would collaboration be tied to the 'initiator' and 'provider' instances
> which are involved in a CA? Is that optimal given that multiple instances
> of the same SSF may be deployed in a given domain for various reasons
> (load-balancing, resiliency, etc.)?
>
> MGLT: In our case, collaboration is mostly set between the orchestrators
of the different domain. We also had scenario with a single domain where
one SSF dynamically ask duplication of its SSF instances, and when multiple
SSF are duplicated, we had one collaboration per duplicated instance.

> Thank you.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Dots [mailto:[email-masked]] De la part de Daniel Migault
> > Envoyé : mardi 28 juin 2016 17:43
> > À : [email-masked]; [email-masked]
> > Cc : Alireza Ranjbar; [email-masked]
> > Objet : Re: [Dots] New Version Notification for draft-mglt-i2nsf-ssf-
> > collaboration-00.txt
> >
> > Hi,
> >
> > Subject: New Version Notification for draft-mglt-i2nsf-ssf-collaboration-
> > 00.txt
> >
> >
> > Status:         https://datatracker.ietf.org/doc/draft-mglt-i2nsf-ssf-
> > collaboration/
> > Htmlized:       https://tools.ietf.org/html/draft-mglt-i2nsf-ssf-
> > collaboration-00
> >
> >
> > Abstract:
> > _______________________________________________
> > Dots mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dots
>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 7 Jul 2016 15:17:02 +0000

Daniel,

Based on your description, your proposed collaboration information exchange is between two domain’s orchestration systems,  i.e. the “A” interface in the I2NSF framework, Correct?
              +-----------------------------------------------------+
              |      I2NSF Client                                   |
              | E.g. Overlay Network Mgnt, Enterprise network Mgnt  |
              |  another network domain’s mgnt, etc.                |
              +----------+------------------------------------------+
                         |
                         |  Client Facing Interface (A)
                         |
                   +-----+---------------+
                   |Network Operator mgmt|               +-------------+
                   | Security Controller | < --------- > | Developer’s |
                   +---------------+-----+  Registration | Mgnt System |
                                   |         Interface   +-------------+
                                   |
                                   | NSF Facing Interface (B)
                                   |
       +---------------------------+-----------------------+
       |                                                   |
       |                                                   |
   +---+--+         +------+             +------+       +--+---+
   + NSF-1+ ------- + NSF-n+             +NSF-1 + ----- +NSF-m +  . . .
   +------+         +------+             +------+       +------+

   Developer A                                 Developer B
Figure 1: I2NSF Reference Model

Is it necessary for the "Down" network to provide the list of SFs to "Upper" network? or it is up to the “down” network to use its own SFs based on the policies from “Upper” network?

Thanks, Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Thursday, July 07, 2016 9:23 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Alireza Ranjbar
Subject: Re: [I2nsf] New Version Notification for draft-mglt-i2nsf-ssf-collaboration-00.txt

Hi Med,
Thank you for the feed backs. Please see inline my responses. I would be happy discuss more in depth these questions in Berlin!
BR,
Daniel

On Wed, Jun 29, 2016 at 8:19 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel, all,

I have some high-level questions about this proposal:
* In which deployment case you think that a service function will take the responsibility to contact another service function located in another domain to ask for collaboration? Wouldn't that be the responsibility of the respective administrative entities managing those domains?

MGLT: In our case, the collaboration is established between between the administrative entity of each domain. Once the provider and the initiator have agreed on setting a collaboration defined by the resources to be engaged, as well as the service, I would say the collaboration is set. in some cases, the security service instantiated may require additional configurations. For example, when a firewall is being instantiated by the provider, the initiator may then need to configure the firewall. Such configuration in our view is not pat of the collaboration. Instead what would be part of the collaboration is the ability for the firewall to be configured by X using protocol Y. X could be a SF or the orchestrator of the domain.

* Based on which criteria an SSF may decide that it needs collaboration with another SSF? Wouldn't that be driven by service requirements and objectives (that are not visible to a monolithic SSF)?

MGLT: In our case, the criteria is when a DDoS attack is being detected, and the attack can be better mitigated in another domain. This means that the orchestrator takes the decision given the various inputs it receives from the SSFs. But the collaboration could also be requested by a single SSF.

* Given that service functions deployed in a given domain are unlikely to be disclosed outside that domain, how SSF discovery is achieved?

MGLT: That is a good question. Currently we assume that the you know the next upper/ lower provider you woudl like to set the collaboration with. We have not yet designed an appropriated SSF discovery protocol. One reason also for it is that we need to think of a common language for service designation.

* Would collaboration be tied to the 'initiator' and 'provider' instances which are involved in a CA? Is that optimal given that multiple instances of the same SSF may be deployed in a given domain for various reasons (load-balancing, resiliency, etc.)?
MGLT: In our case, collaboration is mostly set between the orchestrators of the different domain. We also had scenario with a single domain where one SSF dynamically ask duplication of its SSF instances, and when multiple SSF are duplicated, we had one collaboration per duplicated instance.

Thank you.

Cheers,
Med

> De : Dots [mailto:[email-masked]<mailto:[email-masked]>] De la part de Daniel Migault
> À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc : Alireza Ranjbar; [email-masked]<mailto:[email-masked]>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> URL:            https://www.ietf.org/internet-drafts/draft-mglt-i2nsf-ssf-
> collaboration-00.txt
> tools.ietf.org<http://tools.ietf.org>.
>
> The IETF Secretariat
>
> [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Mon, 11 Jul 2016 13:13:58 +0000

Hi Daniel,

Please see inline.

Cheers,
Med

De : [email-masked] [mailto:[email-masked]] De la part de Daniel Migault
Envoyé : jeudi 7 juillet 2016 16:23
À : BOUCADAIR Mohamed IMT/OLN
Cc : [email-masked]; [email-masked]; Alireza Ranjbar
Objet : Re: New Version Notification for draft-mglt-i2nsf-ssf-collaboration-00.txt

Hi Med,

MGLT: In our case, the collaboration is established between between the administrative entity of each domain.

[Med] OK, thanks. It would be helpful if the draft indicates this assumption. BTW, the draft seems to indicate that the collaboration is between SSFs themselves, e.g., “The SSFs initiating and accepting the collaboration are called,
   respectively, 'initiator' and 'provider'.”.

Once the provider and the initiator have agreed on setting a collaboration defined by the resources to be engaged, as well as the service, I would say the collaboration is set. in some cases, the security service instantiated may require additional configurations. For example, when a firewall is being instantiated by the provider, the initiator may then need to configure the firewall. Such configuration in our view is not pat of the collaboration. Instead what would be part of the collaboration is the ability for the firewall to be configured by X using protocol Y. X could be a SF or the orchestrator of the domain.

MGLT: In our case, the criteria is when a DDoS attack is being detected, and the attack can be better mitigated in another domain
[Med] Asking for collaborating during an attack may be too late to be efficient (because the process may involve administrative validation in inter-domain contexts, resource dimension and provisioning, etc.). I would expect that service collaboration request is to established prior to invoking the service (ddos mitigation in your example). BTW, why security functions are to be involved in the collaboration process? Wouldn’t be adequate for the peer orchestrators to talk with each other?

. This means that the orchestrator takes the decision given the various inputs it receives from the SSFs. But the collaboration could also be requested by a single SSF.

* Would collaboration be tied to the 'initiator' and 'provider' instances which are involved in a CA? Is that optimal given that multiple instances of the same SSF may be deployed in a given domain for various reasons (load-balancing, resiliency, etc.)?
MGLT: In our case, collaboration is mostly set between the orchestrators of the different domain.
[Med] Please add this mention to the draft.
We also had scenario with a single domain where one SSF dynamically ask duplication of its SSF instances, and when multiple SSF are duplicated, we had one collaboration per duplicated instance.

Thank you.

Cheers,
Med