Hi Christian: Yes, we think it may be a little bit late at this point of time. I guess we may change the name of the module to include "-i2nsf-“ if the I2NSF WG is ok with that.
Having said that, we would be interested in collaborating with you in the effort in IPsecme, what do you think? Best regards. > El 12 jul 2020, a las 0:32, Christian Hopps <[email protected]> escribió: > > 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 <[email protected]> wrote: >> >> Dear Christian: >> >> Thank you very much for your interest. See our comments inline. >> >>> El 9 jul 2020, a las 18:46, Christian Hopps <[email protected]> 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: +34868888501 Fax: +34868884151 e-mail: [email protected] >> ------------------------------------------------------- > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
