Subject: Re: [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04

From: Linda Dunbar <[email-masked]>
Date: Tue, 21 May 2019 16:02:01 -0500

Gabriel and Rofa,

Just to clarify: the purpose of asking you changing from "container.." to
"grouping.." is for  "i2nsf-nsf-facing-interface-dm"  to the "ikev2" and
"ietf-ipsec" structure defined in
draft-ietf-i2nsf-sdn-ipsec-flow-protection.
Not other way around, i.e. not asking
draft-ietf-i2nsf-sdn-ipsec-flow-protection to import other properties.

By the way, i2nsf-nsf-facing-interface-dm only imported two other data
structure "ietf-inet-types" & "ietf-yang-types" besides the "ikev2" and
"ietf-ipsec".

It has nothing to do with other modules for TTL, SSL, etc.

Thanks, Linda

On Tue, May 21, 2019 at 3:42 AM Gabriel Lopez <[email-masked]> wrote:

> Hi Linda, Paul.
>
> El 20 may 2019, a las 19:52, Linda Dunbar <[email-masked]> escribió:
>
> Gabriel,
>
> Thanks for the explanation.
>
> Agree with you that *"it does not imply to extend the NSF client
> interface to include all the available yang models for every security
> service a NSF can support.". *
> But a network function that supports I2NSF should be allowed to your IPsec
> module, should it?
>
>
> Sure.
>
> Regards, Gabi.
>
> P.D. Linda, be aware you have included other email destination addresses
> in the “subject” field of our email.
>
>
>
>
>
> what does it mean by you saying the following?
> "the Actual IPsec Configuration" is not same as "our I2NSF interface"?
>
> *That is, our data models assume that the actual IPsec configuration will
> be handled by Rafa's IPsec module through NETCONF, and*
> *our I2NSF interfaces will do nothing related to the IPsec configuration.*
>
>
> Thanks, Linda
>
>
> ----------------------
>
> Hi Paul, Linda.
>
>
> Thanks again for your comments.
>
>
> El 18 may 2019, a las 7:11, Mr. Jaehoon Paul Jeong <[email-masked]>
> escribió:
>
>
> Hi Linda,
> For your first question,
> it seems like Gabriel does not like to modify their code to let NSF-Facing
> Interface data module import ikev2 and ietf-ipsec (i.e., ike-less)
> according to IETF YANG conventions such as TLS, SSH, IDS, and ACL.
> In our data models, we will specify whether an NSF supports an IPsec
> configuration mechanism (IKEv2 or IKEless),
> or does not support any IPsec configuration mechanism.
> That is, our data models assume that the actual IPsec configuration will
> be handled by Rafa's IPsec module through NETCONF, and
> our I2NSF interfaces will do nothing related to the IPsec configuration.
>
>
>
>
>
>
> The question is not whether I (we) like or don't like to modify the model.
> The question is whether it is the best technical approach or not.
> As said before, the ipsec model has been designed to work in a standalone
> mode in a NSF, so the controller can configure ipsec on NSFs without any
> other module.
>
>
> You mention the consensous on the last meeting, but what I get from this
> consensous is to study how, making use of the capability model, the
> controller can learn if the NSF node supports IKE case or IKE-less case,
> and then in the discussion there is a mention to a "reference" to the
> corresponding data model implementing these capabilities (our model) (here
> the "reference" clause could be used). But it does not imply to extend the
> NSF client interface to include all the available yang models for every
> security service a NSF can support.
>
>
> Our main concerns is if the objective of the nsf-client-dm is:
>
>
> - To import all other models (SSH, TLS, ALCs, etc...) just for sake of
> having all of them gathered in a single model (nsf-client-dm). But I don't
> see the benefit. In fact, SSH or TLS yang models are designed to be used by
> other yang model for especific applications, such as a model for HTTPS
> importing the TLS model or a model for a SSH server importing the SSH
> model. What is the service in this case?. In the case of the ACL yang
> module, it is also defined to work in a standalone mode (no main grouping
> based). In the case of IDS, could you point out the yang module?
>
>
> - To adapt them in some way to the ECA model. The ECA model is the
> keystone of the nsf-client-dm, as described in section 4. If it is the
> case, then it is difficult to see examples of how they can be adapted.
>
>
>
>
> Said that, the draft is a WG item and the WG has to decide what is the
> right way to proceed.
>
>
> Regards, Gabi.
>
>
> -----------------------------------------------------------
> Gabriel López Millán
> Departamento de Ingeniería de la Información y las Comunicaciones
> University of Murcia
> Spain
> Tel: +34 868888504
> Fax: +34 868884151
> email: [email-masked] <[email-masked]>
>
>
>
>

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Fri, 24 May 2019 11:29:39 +0200

Hi Linda:

> El 21 may 2019, a las 23:02, Linda Dunbar <[email-masked]> escribió:
> 
> Gabriel and Rofa,
> 
> Just to clarify: the purpose of asking you changing from "container.." to "grouping.." is for  "i2nsf-nsf-facing-interface-dm"  to the "ikev2" and "ietf-ipsec" structure defined in draft-ietf-i2nsf-sdn-ipsec-flow-protection.

Yes, that was clear from the beginning. One of the concern I see is the following:

If the industry only wants to implement draft-ietf-i2nsf-sdn-ipsec-flow-protection for IPsec management, it can do it only if we leave the document as it is. In other words, the ideas in the document were designed to be standalone and that is why the container definition.

For example, if you check https://tools.ietf.org/html/rfc8519 my understanding is a device can deploy that RFC to manage ACLs. It does not need to implement anything else. IPsec YANG model is defined in the same way.

If we change from “container” to “grouping ..” then we would remove that option which, in my opinion, is not good.

I think Paul’s suggestion is in this line as well when he mentioned that their data models assumed that the actual IPsec configuration will be handled by IPsec module through NETCONF (draft-ietf-i2nsf-sdn-ipsec-flow-protection), and our I2NSF interfaces will do nothing related to the IPsec configuration.

In other words, it seems to me there is no need to integrate both.

Best Regards.

> Not other way around, i.e. not asking draft-ietf-i2nsf-sdn-ipsec-flow-protection to import other properties.
> 
> By the way, i2nsf-nsf-facing-interface-dm only imported two other data structure "ietf-inet-types" & "ietf-yang-types" besides the "ikev2" and "ietf-ipsec".
> 
> On Tue, May 21, 2019 at 3:42 AM Gabriel Lopez <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Linda, Paul.
> 
>> El 20 may 2019, a las 19:52, Linda Dunbar <[email-masked] <mailto:[email-masked]>> escribió:
>> 
>> Gabriel,
>> 
>> Agree with you that "it does not imply to extend the NSF client interface to include all the available yang models for every security service a NSF can support.".
>> But a network function that supports I2NSF should be allowed to your IPsec module, should it? 
> 
> Sure.
> 
> Regards, Gabi.
> 
> P.D. Linda, be aware you have included other email destination addresses in the “subject” field of our email.
> 
> 
> 
> 
>> 
>> That is, our data models assume that the actual IPsec configuration will be handled by Rafa's IPsec module through NETCONF, and
>> El 18 may 2019, a las 7:11, Mr. Jaehoon Paul Jeong <[email-masked] <mailto:[email-masked]>> escribió:
>>  
>> Hi Linda,
>> For your first question,
>> it seems like Gabriel does not like to modify their code to let NSF-Facing Interface data module import ikev2 and ietf-ipsec (i.e., ike-less)
>> In our data models, we will specify whether an NSF supports an IPsec configuration mechanism (IKEv2 or IKEless), 
>> That is, our data models assume that the actual IPsec configuration will be handled by Rafa's IPsec module through NETCONF, and
>> The question is not whether I (we) like or don't like to modify the model. The question is whether it is the best technical approach or not.
>> As said before, the ipsec model has been designed to work in a standalone mode in a NSF, so the controller can configure ipsec on NSFs without any other module.
>>  
>> You mention the consensous on the last meeting, but what I get from this consensous is to study how, making use of the capability model, the controller can learn if the NSF node supports IKE case or IKE-less case, and then in the discussion there is a mention to a "reference" to the corresponding data model implementing these capabilities (our model) (here the "reference" clause could be used). But it does not imply to extend the NSF client interface to include all the available yang models for every security service a NSF can support.
>>  
>> - To import all other models (SSH, TLS, ALCs, etc...) just for sake of having all of them gathered in a single model (nsf-client-dm). But I don't see the benefit. In fact, SSH or TLS yang models are designed to be used by other yang model for especific applications, such as a model for HTTPS importing the TLS model or a model for a SSH server importing the SSH model. What is the service in this case?. In the case of the ACL yang module, it is also defined to work in a standalone mode (no main grouping based). In the case of IDS, could you point out the yang module?
>>  
>> - To adapt them in some way to the ECA model. The ECA model is the keystone of the nsf-client-dm, as described in section 4. If it is the case, then it is difficult to see examples of how they can be adapted. 
>>  
>>  
>> Said that, the draft is a WG item and the WG has to decide what is the right way to proceed. 
>>  
>> Regards, Gabi. 
> 
> email: [email-masked] <mailto:[email-masked]>
> 
> 
> 
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf