Thanks, Rafa.
Just one response below.
> On 14 Nov 2018, at 11:30, Rafa Marin-Lopez <[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]
https://www.ietf.org/mailman/listinfo/i2nsf
