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?

["Susan Hares" <[e-mail]>]

Daniel: 

 

Can we chat at 5pm at the welcome reception?   

 

Sue 

 

From: I2nsf [mailto:[e-mail]] On Behalf Of Daniel Migault
Sent: Saturday, November 12, 2016 9:38 AM
To: Susan Hares
Cc: [e-mail]; Alireza Ranjbar; Linda Dunbar
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

So here are the work i believe that are related to the negociation agreement.
https://www.ogf.org/documents/GFD.107.pdf

There is also the following document that is similar but in a different context:

https://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-protocol-12

I would be more than happy to discuss to position these efforts.

Yours,

Daniel

 

On Nov 11, 2016 4:34 PM, "Susan Hares" <[e-mail]> wrote:

Daniel:

 

I just sent a note to the I2NSF Mail list. I think we are working on 2 different paradigms.  

 

Sue:  peer-wise negotiation [like BGP]

Daniel:  something else? 

 

Please send me the OASIS references if you get a chance.   

 

Thanks,  Sue 

 

From: I2nsf [mailto:[e-mail]] On Behalf Of Daniel Migault
Sent: Friday, November 11, 2016 1:02 AM
To: Susan Hares
Cc: [e-mail]; Alireza Ranjbar; Linda Dunbar
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?

 

I believe - with my knowledge of netconf --what we are missing is the ability to negotiate a proposal in an efficient way.
The closest we found so far is an oasis standard.

Happy to discuss it sunday!

Yours
Daniel

 

On Nov 10, 2016 08:55, "Susan Hares" <[e-mail]> wrote:

Daniel: 

 

I think RESTCONF/NETCONF can be used for inter-cloud as well as setting specific configuration.  NETCONF has a JSON encoding as well.  Therefore, what we really need to determine is the benefit of your protocol versus the existing code base changes.   I believe my data model does the same things  you are proposing and plugs into the capability model we are developing.   

 

I will send additional comments to the list during the next few days, but I really hope we can meet on Sunday at the IETF social to discuss these points.   The best result would be to determine the right solution across multiple protocols (just like NETCONF/RESTCONF/I2RS have done). 

 

Cheers, 

 

Sue 

 

From: I2nsf [mailto:[e-mail]] On Behalf Of Daniel Migault
Sent: Wednesday, September 21, 2016 9:08 AM
To: Susan Hares
Cc: [e-mail]; Alireza Ranjbar; Linda Dunbar
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 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 <[e-mail]> 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? 

 

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:[e-mail]] On Behalf Of Linda Dunbar
Sent: Monday, September 12, 2016 5:59 PM
To: 'Daniel Migault'; Alireza Ranjbar; [e-mail]
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.

 

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
[e-mail]
https://www.ietf.org/mailman/listinfo/i2nsf

 


_______________________________________________
I2nsf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2nsf


_______________________________________________
I2nsf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2nsf