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 protected] [mailto:[email protected]]
> 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
>
>
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
