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 protected]> 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? > > > > Can you give some examples of those NSFs? > > > > Thanks, Linda > > > > *From:* [email protected] [mailto:[email protected] > <[email protected]>] *On Behalf Of *Daniel Migault > *Sent:* Wednesday, September 21, 2016 8:04 AM > *To:* Linda Dunbar > *Cc:* Alireza Ranjbar; [email protected] > *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 protected]> > 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-controll > er-northbound-framework/ ? > > > > > > Thanks, > > Linda > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf > > > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf > >
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
