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 <linda.dunbar@huawei.com> 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:i2nsf-bounces@ietf.org <mailto:i2nsf-bounces@ietf.org>] On Behalf Of Yoav Nir
> Sent: Wednesday, November 14, 2018 12:33 PM
> To: Rafa Marin-Lopez <rafa@um.es <mailto:rafa@um.es>>
> Cc: i2nsf@ietf.org <mailto:i2nsf@ietf.org>; Paul Wouters <paul@nohats.ca <mailto:paul@nohats.ca>>
> Subject: Re: [I2nsf] Reviewing sdn-ipsec-flow-protection
>  
> Thanks, Rafa.
>  
> Just one response below.
> 
> 
> On 14 Nov 2018, at 11:30, Rafa Marin-Lopez <rafa@um.es <mailto:rafa@um.es>> wrote:
>  
> Hi Yoav:
> 
> 
> El 8 nov 2018, a las 17:11, Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>> 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
> I2nsf@ietf.org <mailto:I2nsf@ietf.org>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>