Hi, all
As discussed in the room, we need some reviewers for the
sdn-ipsec-flow-protection draft ([1])
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..
Some of the modes are obsolete (BEET)
KINK & IKEv1
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")
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.
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.
Thanks to Paul Wouters and two others who volunteered to review. Substantive
reviews will be rewarded with a beer in Prague.
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
