Subject: [I2nsf] Is the “Security Service Function (SSF)” in draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the I2NSF-problem-and-use-cases?

From: Linda Dunbar <[email-masked]>
Date: Mon, 12 Sep 2016 21:59:25 +0000

Daniel and Alirezza,

Is the “Security Service Function (SSF)” in your draft equivalent to the Network Security Function (NSF) defined in https://www.ietf.org/id/draft-ietf-i2nsf-problem-and-use-cases-01.pdf  ?

NSF: Network Security Function. An NSF is a function that detects abnormal activity and blocks/mitigates the effect of such abnormal activity in order to preserve the availability of a network or a service. In addition, the NSF can help in supporting communication stream integrity and confidentiality.

Flow-based NSF: An NSF which inspects network flows according to a
security policy. Flow-based security also means that packets are
inspected in the order they are received, and without altering
packets due to the inspection process (e.g., MAC rewrites, TTL
decrement action, or NAT inspection or changes).

If they are the same, can you change the terminology? If they are different, can you elaborate the differences in your draft?

Second question:
When the “Cloud based services” need network provider to enforce certain flow rules for the traffic destined to (originated from) the “Cloud based services”, do you anticipate those flow rules to be applied to specific SSFs belonging to different administrators?  Or can those rules be to the “controller” of the SSFs belonging to network providers?  As described by  https://datatracker.ietf.org/doc/draft-kumar-i2nsf-controller-northbound-framework/ ?

Thanks,
Linda

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 13 Sep 2016 15:25:35 -0400

Linda and Daniel: 

To follow-up on Linda's second question,  this draft appears to be similar
to the draft-inter-cloud-DDOS Yang model
(draft-hares-i2nsf-ddos-yang-dm-00).  Is it reasonable to have to different
yang models or to make one an augmentation of the other data model? 

It might make sense to have a general collaboration model for inter-domain
SSF functions with the DDOS Yang model as a sub-function.  I'll send some
Yang model interactions offline. 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, September 12, 2016 5:59 PM
To: 'Daniel Migault'; Alireza Ranjbar; [email-masked]
Subject: [I2nsf] Is the "Security Service Function (SSF)" in
draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the
I2NSF-problem-and-use-cases?

Daniel and Alirezza, 

Is the "Security Service Function (SSF)" in your draft equivalent to the
Network Security Function (NSF) defined in
https://www.ietf.org/id/draft-ietf-i2nsf-problem-and-use-cases-01.pdf  ? 

NSF: Network Security Function. An NSF is a function that detects abnormal
activity and blocks/mitigates the effect of such abnormal activity in order
to preserve the availability of a network or a service. In addition, the NSF
can help in supporting communication stream integrity and confidentiality.

 

If they are the same, can you change the terminology? If they are different,
can you elaborate the differences in your draft? 

Second question: 

When the "Cloud based services" need network provider to enforce certain
flow rules for the traffic destined to (originated from) the "Cloud based
services", do you anticipate those flow rules to be applied to specific SSFs
belonging to different administrators?  Or can those rules be to the
"controller" of the SSFs belonging to network providers?  As described by
https://datatracker.ietf.org/doc/draft-kumar-i2nsf-controller-northbound-fra
mework/ ?

Thanks, 

Linda

---

From: Daniel Migault <[email-masked]>
Date: Wed, 21 Sep 2016 09:04:19 -0400

Hi Linda,

I apology for the delay. Please find my response and additional questions –
mostly for Susan ;-). If you are find with the response, I can also send
them on the ML.

Q1: There is no difference between SSF and NSF. We will change that in the
next version. Thanks for raising it, this is a good reminder to update our
terminology.

Q2: Our protocol defines how the two domains interconnect to have NSF
working in different domains interacting properly. In our case, the
security controller of the cloud and the security controller of the
cloudlet agree on how the cloudlet and the cloud needs to interconnect
their data plane as well as how the cloud can configure or control the NSF
in the cloudlet. The configuration of the NSF itself is not part of the
collaboration protocol typically we expect that NETCONF/YANG be used.

My understanding of draft-kumar-i2nsf-controller-northbound-framework-00
[1] is that is provides some requirements for an API to be able to manage a
whole domain of NSF provided by multiple vendors. In our case if a cloud
were using such API, we would consider the security controller of the cloud
got control over a significant part of the resource of the cloudlet. In our
case, we would like that collaboration of the cloudlet can be performed
with a reduced footprint from the cloud. The foot print is limited by the
cloudlet by limiting the interaction from the cloud to the NSF
instantiating in the cloud.

BR,

Daniel

On Mon, Sep 12, 2016 at 5:59 PM, Linda Dunbar <[email-masked]>
wrote:

> Daniel and Alirezza,
>
>
>
> Is the “Security Service Function (SSF)” in your draft equivalent to the
> Network Security Function (NSF) defined in https://www.ietf.org/id/draft-
> ietf-i2nsf-problem-and-use-cases-01.pdf  ?
>
>
>
>
>
> to preserve the availability of a network or a service. In addition, the
> NSF can help in supporting communication stream integrity and
> confidentiality.
>
>
>
> If they are the same, can you change the terminology? If they are
> different, can you elaborate the differences in your draft?
>
>
>
>
>
> Second question:
>
> When the “Cloud based services” need network provider to enforce certain
> flow rules for the traffic destined to (originated from) the “Cloud based
> services”, do you anticipate those flow rules to be applied to specific
> SSFs belonging to different administrators?  Or can those rules be to the
> “controller” of the SSFs belonging to network providers?  As described by
> https://datatracker.ietf.org/doc/draft-kumar-i2nsf-controller-northbound-
> framework/ ?
>
>
>
>
>
> Thanks,
>
> Linda
>
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf
>
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 21 Sep 2016 09:07:31 -0400

Hi Susan,

I deeply apology for not having read carefully the
draft-hares-i2nsf-ddos-yang-dm-00, but my understanding is that our
protocol would – for example – end up in agreeing using inter-cloud-ddos
NSF with the inter-cloud-ddos NETCONF/YANG model. The remaining
configuration NETCONF/YANG will be done outside of our protocol.

We wondered whether using YANG or JSON and we decided to use JSON as
YANG seemed to us non appropriated for our protocol. That said we
might be completely wrong and would be happy to change if necessary.
The reasoning behind was:
I saw NETCONF/YANG as one way to get operational data or to push a
configuration. In our case, the collaboration agreement seemed
different from a configuration file as a given attribute may have a
preset of values. “A”, “B”, “C” and “D”, but the cloud and the
cloudlet may have different policies regarding the attribute. For
example the cloud only accepts “A” “B” and “C” and the cloudlet only
accepts “C” and “D”. In that sense, the purpose of the our protocol is
to let the cloud announce to the cloudlet that it only accepts answers
that are in “A” “B” “C” , and let the cloudlet responds with “C”.

One way to do that in YANG would be to have attributes like:

Attribute-proposal-list and Attribute-chosen, but I am not sure that
is really appropriated.

We are happy to receive feed back on your opinion using YANG/JSON!

BR,
Daniel

On Tue, Sep 13, 2016 at 3:25 PM, Susan Hares <[email-masked]> wrote:

> Linda and Daniel:
>
>
>
> To follow-up on Linda’s second question,  this draft appears to be similar
> to the draft-inter-cloud-DDOS Yang model (draft-hares-i2nsf-ddos-yang-dm-00).
> Is it reasonable to have to different yang models or to make one an
> augmentation of the other data model?
>
>
>
> SSF functions with the DDOS Yang model as a sub-function.  I’ll send some
> *From:* I2nsf [mailto:[email-masked]] *On Behalf Of *Linda Dunbar
> *Sent:* Monday, September 12, 2016 5:59 PM
> *To:* 'Daniel Migault'; Alireza Ranjbar; [email-masked]
> *Subject:* [I2nsf] Is the “Security Service Function (SSF)” in

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 26 Sep 2016 20:15:04 +0000

Daniel,

You said:
“Our protocol defines how the two domains interconnect to have NSF working in different domains interacting properly. In our case, the security controller of the cloud and the security controller of the cloudlet agree on how the cloudlet and the cloud needs to interconnect their data plane as well as how the cloud can configure or control the NSF in the cloudlet. The configuration of the NSF itself is not part of the collaboration protocol typically we expect that NETCONF/YANG be used.”
Will different NSFs have different “protocol” to work across domains? Is the protocol straightly between two NSF instances? Is it necessary for the NSFs in two domains by same vendors?

Can you give some examples of those NSFs?

Thanks, Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Wednesday, September 21, 2016 8:04 AM
To: Linda Dunbar
Cc: Alireza Ranjbar; [email-masked]
Subject: Re: [I2nsf] Is the “Security Service Function (SSF)” in draft-mglt-i2nsf-ssf-collaboration same as the NSF defined by the I2NSF-problem-and-use-cases?

Hi Linda,

I apology for the delay. Please find my response and additional questions – mostly for Susan ;-). If you are find with the response, I can also send them on the ML.

Q1: There is no difference between SSF and NSF. We will change that in the next version. Thanks for raising it, this is a good reminder to update our terminology.

Q2: Our protocol defines how the two domains interconnect to have NSF working in different domains interacting properly. In our case, the security controller of the cloud and the security controller of the cloudlet agree on how the cloudlet and the cloud needs to interconnect their data plane as well as how the cloud can configure or control the NSF in the cloudlet. The configuration of the NSF itself is not part of the collaboration protocol typically we expect that NETCONF/YANG be used.

My understanding of draft-kumar-i2nsf-controller-northbound-framework-00 [1] is that is provides some requirements for an API to be able to manage a whole domain of NSF provided by multiple vendors. In our case if a cloud were using such API, we would consider the security controller of the cloud got control over a significant part of the resource of the cloudlet. In our case, we would like that collaboration of the cloudlet can be performed with a reduced footprint from the cloud. The foot print is limited by the cloudlet by limiting the interaction from the cloud to the NSF instantiating in the cloud.

BR,
Daniel

On Mon, Sep 12, 2016 at 5:59 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Daniel and Alirezza,

Second question:

Thanks,
Linda

_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf