Hi Yoav: > El 8 nov 2018, a las 17:11, Yoav Nir <[email protected]> escribió: > > Hi, all > > As discussed in the room, we need some reviewers for the > sdn-ipsec-flow-protection draft ([1])
Thanks for these comments. Please see our response below. > > While any comments on any part of the document are welcome, I would like > people to concentrate on the following issues: > The YANG model in Appendix A > Some of the crypto seems obsolete (example: DES). We would get into trouble > in SecDir review. OTOH ChaCha20-Poly1305 is missing.. Agree. We will remove DES and add the algorithm you mention. > Some of the modes are obsolete (BEET) We will remove it. > KINK & IKEv1 We will remove it. > The YANG model in Section 6 > I think there’s a bit of TMI in there: Not all fields in an IPsec > implementation need to be sent from the controller (SA state, like “larval”) True. We will try to polish this. > The interaction between Controller and NSF > There’s no way for the controller to retrieve NSF capabilities. What if the > NSF does not implement rc5? It’s fine if we say that the Controller knows in > advance what the capabilities of each NSF are, but it should be stated. Agree. Nevertheless, I would say that the most correct way is when the controller asks the NSF about capabilities after NSF and controller connect. > ISTM like the Controller sends the private key and the certificate to the > NSF. While this is a possible model, it is also quite common for private keys > to be generated in the NSF and never leave the cryptographic boundary. I > think this should be at least allowed. I guess you’re referring to section 9.1 We think the NSF should always generate the public and private key. If raw public key is used the NSF sends that public key to the Controller just for a simple registration. If the public key needs to be in a certificate, the NSF can send the public key to the Security Controller for certification. In summary, the private key never leaves the NSF in both cases. If agreed, we will modify this text to only consider this case. > > Thanks to Paul Wouters and two others who volunteered to review. Substantive > reviews will be rewarded with a beer in Prague. Thanks Paul, and volunteers. > > Yoav > > [1] https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 > <https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-03>_______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
