Subject: [I2nsf] Questions to draft-mglt-i2nsf-ssf-collaboration

From: Linda Dunbar <[email-masked]>
Date: Wed, 2 Nov 2016 15:48:56 +0000

Daniel,

Your draft 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]> [mailto:[email-masked]] On Behalf Of Daniel Migault
Sent: Wednesday, September 21, 2016 8:04 AM
To: Linda Dunbar
Cc: Alireza Ranjbar; [email-masked]<mailto:[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,

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

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

---

From: Daniel Migault <[email-masked]>
Date: Wed, 2 Nov 2016 23:09:00 -0400

Hi Linda,

Thank you for the feed back. It is unlikely we will present an updated
version of the draft at the ietf in Seoul, but we will probably be able to
update the draft by the  end of teh year. I understand your question is
about the protocol used to configure the NSF.

Will different NSFs have different “protocol” to work across domains?

Can you give some examples of those NSFs?
We hope no, but it may happen. At least netconf and restconf are two
distinct protocols and NSF may implement one of teh other over time. Our
agreement template defines some attributes so the Cloud ( or Customer) can
actually configure the NSF in the Cloudlet. Suppose the NSF is a firewall.
We do not consider the configuration of the firewall as part of the
agreement. Instead the provider instantiates the firewall and provides the
necessary element for the controller of the Cloud to configure the
firewall. We expect for example that the configuration of the firewall will
be performed using netconf and YANG.

Is the protocol straightly between two NSF instances?

I understand thsi as wether the netconf session terminates at the NSF. No
it depends on the arcnitecture.  The controller is expected to configure
the instance. It may directly reach the NSF but it can also be proxyfied.
In our example teh Cloud receives an attribute that indicates it can
configure the firewall NSF at this IP/port address with Netconf. In our
infrastructure the IP/port is on the  Controller of the Cloudlet. The
Controller of the Cloud reaches the Controller of the Cloudlet which in
turn configures the NSF. Other architectures may consider a direct
connection between teh COntroller of the Cloud and the NSF. What is behind
the IP/port is out of control of the Cloud.

Is it necessary for the NSFs in two domains by same vendors?

When configuration of the NSF is performed using Netconf/YANG there is no
need that the NSF be from the same vendor. If te configuration is performed
using a vendor specific protocol then likely yes.

Yours,
Daniel

On Wed, Nov 2, 2016 at 11:48 AM, Linda Dunbar <[email-masked]>
wrote:

>
>
> Daniel,
>
>
>
> Your draft 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?
>
>
>
> *From:* [email-masked] [mailto:[email-masked]
> <[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]>
> 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  ?
>
>
>
>
>
> 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-controll
> er-northbound-framework/ ?
>
>
>
>
>
> Thanks,
>
> Linda
>
>
> [email-masked]
> [email-masked]