Rafa, Thanks for getting a better reference. I like your approach.
Linda From: Rafa Marin Lopez [mailto:[email protected]] Sent: Thursday, December 06, 2018 3:39 AM To: Linda Dunbar <[email protected]> Cc: Rafa Marin Lopez <[email protected]>; Yoav Nir <[email protected]>; [email protected]; Paul Wouters <[email protected]> Subject: Re: [I2nsf] YANG module update when new algorithms added to IPsec, RE: Reviewing sdn-ipsec-flow-protection Hi Linda: That was also suggested. In fact, our doubt is whether we should refer to something like: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-02 In fact you can see in this reference things like: identity hmac-sha2-256-128 { base "mac-algorithm"; description "Generating a 256 bits MAC using SHA2 hash function and truncate it to 128 bits"; reference " RFC 4868 : Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPSec"; Although I think that the content of this reference should be expanded. As another example, besides yours, they follow the model of importing: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-08 Best Regards. El 5 dic 2018, a las 21:48, Linda Dunbar <[email protected]<mailto:[email protected]>> escribió: Yoav asked: “What is our plan for future expansions? Suppose there’s some hot, new algorithm that everyone is implementing. How do you update the YANG model in the future when you add new values to the enumerations? Is it up to the administrator to make sure that the controller and NSFs are all on the “same page”?” We can use “import” and “augment” to add new attributes as demonstrated byhttps://datatracker.ietf.org/doc/draft-lee-ccamp-optical-impairment-topology-yang/?include_text=1 Linda From: I2nsf [mailto:[email protected]] On Behalf Of Yoav Nir Sent: Wednesday, November 14, 2018 12:33 PM To: Rafa Marin-Lopez <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Paul Wouters <[email protected]<mailto:[email protected]>> Subject: Re: [I2nsf] Reviewing sdn-ipsec-flow-protection Thanks, Rafa. Just one response below. On 14 Nov 2018, at 11:30, Rafa Marin-Lopez <[email protected]<mailto:[email protected]>> wrote: Hi Yoav: El 8 nov 2018, a las 17:11, Yoav Nir <[email protected]<mailto:[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. The TLS working group went quite far with TLS 1.3. Only 2 ciphers remain: AES-GCM with 16-byte ICV, and ChaCha20-Poly1305. That’s it. Specifically, they’ve deprecated everything that isn’t an AEAD. The IPsecME working group hasn’t gone that far yet. But in practice pretty much nothing is used except 3DES, AES-CBC, and AES-GCM. Perhaps ChaCha20-Poly1305 is starting to see some use by now. We have RFC 8221, especially sections 5 and 6. I think (although it’s up to the working group) that we should be fine defining only the MUSTs and the SHOULDs in those sections. That brings another question. What is our plan for future expansions? Suppose there’s some hot, new algorithm that everyone is implementing. How do you update the YANG model in the future when you add new values to the enumerations? Is it up to the administrator to make sure that the controller and NSFs are all on the “same page”? Thanks Yoav _______________________________________________ I2nsf mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2nsf
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
