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
