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]> 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 by > <>https://datatracker.ietf.org/doc/draft-lee-ccamp-optical-impairment-topology-yang/?include_text=1 > > <https://datatracker.ietf.org/doc/draft-lee-ccamp-optical-impairment-topology-yang/?include_text=1> > > > Linda > From: I2nsf [mailto:[email protected] <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 > <https://www.ietf.org/mailman/listinfo/i2nsf>
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
