Re: [I2nsf] YANG module update when new algorithms added to IPsec, RE: Reviewing sdn-ipsec-flow-protection

Rafa,

Thanks for getting a better reference. I like your approach.

Linda

From: Rafa Marin Lopez [mailto:rafa@um.es]
Sent: Thursday, December 06, 2018 3:39 AM
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: Rafa Marin Lopez <rafa@um.es>; Yoav Nir <ynir.ietf@gmail.com>; i2nsf@ietf.org; Paul Wouters <paul@nohats.ca>
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 <linda.dunbar@huawei.com<mailto: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 byhttps://datatracker.ietf.org/doc/draft-lee-ccamp-optical-impairment-topology-yang/?include_text=1

Linda
From: I2nsf [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