Hi Linda: I remember that adding text in Security Considerations about the security risks would allow the reader to understand them and to use case 2 at its own risk.
I think that was also a comment in the past and that is why we added section 9.1 and 9.2. In any case, I do not see any problem to include additional text in section 9.2 where the case 2 can be used (somehow this text is scattered in the document right now). For example, we mention: "Alternatively, Case 2 allows lighter NSFs (no IKEv2 implementation), which benefits the deployment in constrained NSFs.” Another point to add is about secure management channel. Our assumption is you are using NETCONF, as a consequence TLS, or SSH security association is in place between the Controller and the NSFs, but it is better, as you mention, explicitly state it. Best Regards. > El 18 oct 2018, a las 23:18, Linda Dunbar <[email protected]> escribió: > > Gabriel and Rafa, > > I remember in IETF102 I2NSF session, you agreed to add some description on > how/where your Option 2 can be used ( i.e. Using Controller to assist the > IPsec key computation and pass the SA attributes together with its IPsec > session key to the pair-wise Nodes via a secure management channel), such as > - for some special secure environment (e.g. in one physically isolated > data center) or > - some resource constrained IoT deployment that can tolerance some > risks. > > It is important to document the risks associated with the option, so that > users can make the informed decision. > > > Thanks, Linda Dunbar ------------------------------------------------------- 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
