Re: [I2nsf] question on ipsec YANG model

[Christian Hopps <[e-mail]>]

Yes, I understand that you were going after the SDN functionality; however, the modules doen't actually contain that in their names, and it certainly seems a very good starting point for ipsec in general. The main issues I'm raising are ones that will make it hard to re-use/augment this model for more general use. This is the only ipsec model that exists AFAICT.

So the question is will we (IETF) have to duplicate all this effort you've made so far for general ipsec use, or can we still make a few changes and get a lot more use out of your work?

If you believe the ship has sailed, and I do realize this has been pushed to the IESG, then perhaps the modules names (URIs et al) should at minimum include "-sdn-" in their names to make clear they aren't trying to, and can't be the base model for general IPsec use. Right now you are naming your modules "ietf-ipsec-common", "ietf-ipsec-ike", "ietf-ipsec-ikeless" which doesn't indicate the heavy SDN focus that the models have.

Thanks,
Chris.

> On Jul 11, 2020, at 2:09 PM, Rafa Marin-Lopez <[e-mail]> wrote:
> 
> Dear Christian:
> 
> Thank you very much for your interest. See our comments inline.
> 
>> El 9 jul 2020, a las 18:46, Christian Hopps <[e-mail]> escribió:
>> 
>> Hi,
>> 
>> We are looking at using the ipsec model defined in "draft-ietf-i2nsf-sdn-ipsec-flow-protection" for augmenting to support IPTFS (https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01). This isn't necessarily b/c we have an interest in SDN per-se, but just that it appears to be *the* available IPsec YANG model. :)
>> 
>> When we started to augment in our configuration and operations state we encountered some issues.
>> 
>> The biggest issue is that the IKE model does not have a SAD. This seems to be a fairly large omission.
> 
> 
> The reason of this omission is the following (please, take into account that we work in a scenario where we have an I2NSF controller): IKE handles IPsec SAs and therefore the SAD. Therefore, there was not strong reason to access the SAD from “outside” (I2NSF controller).  The IKE implementation is in charge of completely handling the SAD.
> 
> Having said that, the module should be able to provide certain features for the IPsec SAs that IKE must negotiate. That is included in the container child-sa-info for configuration.
> 
> Regarding operational state, we did not see any value from the I2NSF controller standpoint to know the details of the IPsec SAs managed by the IKE implementation since IKE is just a layer that abstract this from “outside”. In fact, we did not see any objection in the I2NSF WG about this.
> 
> Unlike the IKE-less case, where the I2NSF controller needs to configure the SAD and to have complete control of it, in the IKE case, the I2NSF controller relies on the IKE implementation to abstract those details.
> 
>> 
>> For example the conn-entry in in the IKE model has a list of encryption algorithms and integrity algorithms etc.. these would be used to make a proposal to the remote IKE; however, eventually something is selected, and an IKE SA, and subsequent CHILD_SA) are created. These SAs will have the specific selected parameters as well as other operational state (e.g., packet and byte counters etc).
>> 
>> This SA operational state should be accessible in the YANG model. One obvious way to do this would be to re-use the ikeless SAD by moving it to ipsec-common.
>> 
>> The other smaller issue is how the IKE connection entry configuration uses an SPD entry (I think).
> 
> Mmmmm, it is a container with a "list spd-entry” so there are several and not only one. But yes, those values are for configuration for the reason we mentioned above.
> 
> 
>> When IKE actually initiates a connection there may be multiple SPD entries that are created in order to support, for example, an IPsec tunnel. I believe the SPD entry under conn-entry in the ipsec-ike model though is being used only to specify the policy for the child SA that will be created. All the actual SPD entries that are created due to an IKE connection being established (with the corresponding child SAs referenced by reqid for the PROTECT versions) should probably be accessible from YANG as well. Otherwise one cannot view things such as BYPASS policy that has been installed.
> 
> The dynamic generation of SPD entries is not considered in the model. The question is: how is this useful for the I2NSF controller operation? That was our question taking into account that we do have interest in the SDN model. The conclusion was that we wanted a simple and operative interface (based on YANG model) for IKE case, taking into account we have IKE in the NSF. In fact, that is precisely one of the advantages of having IKE.
> 
> 
>> 
>> The most obvious fix here would be to move the SPD out of ipsec-ikeless and into ipsec-common.
>> 
>> This doesn't leave anything in ipsec-ikeless though. :)  It could be that the IKE created SAs and SPDs also should only be accessible as read-only (operational state), but that would probably have to be determined by the YANG server and not specified in the model if the SAD and SPD would be shared by both IKE and IKE-less operation.
>> 
>> Thoughts?
> 
> The summary is we wanted a very simple and operable model for IKE case taking into account that IKE implementation does several actions on behalf the I2NSF controller. We hope these clarifications help to understand the motivation of defining the YANG model in this way.
> 
> Best Regards and many thanks.
> 
>> 
>> Thanks,
>> Chris.
>> 
> 
> -------------------------------------------------------
> Rafa Marin-Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: [phone] Fax: [phone] e-mail: [e-mail]
> -------------------------------------------------------