Subject: [babel] info-model: DTLS config parameters

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 10 Jul 2019 18:47:57 +0000

I was reviewing the minutes from Prague, and saw they indicated we didn't have resolution on whether certain DTLS configuration parameters should be global or at the interface level.
----------------------
The current revision has the following global parameters:

   babel-dtls-enable:  Indicates whether the DTLS security mechanism is
      enabled (true) or disabled (false).  An implementation MAY choose
      to expose this parameter as read-only ("ro").

   babel-dtls-cert-types:  List of supported DTLS certificate types.
      Possible values include "X.509" and "RawPublicKey".
-----------------------
And the following are at the interface level:

   babel-dtls-cached-info:  Indicates whether the cached_info extension
      is included in ClientHello and ServerHello packets.  The extension
      is included if the value is "true".  An implementation MAY choose
      to expose this parameter as read-only ("ro").

   babel-dtls-cert-prefer:  List of supported certificate types, in
      order of preference.  The values MUST be among those listed in the
      babel-dtls-cert-types parameter.  This list is used to populate
      the server_certificate_type extension in a Client Hello.  Values
      that are present in at least one instance in the babel-dtls-certs
      object of a referenced babel-dtls instance and that have a non-
      empty babel-cert-private-key will be used to populate the
      client_certificate_type extension in a Client Hello.

Please let me know if you disagree with this set of global/interface DTLS config parameters.
Barbara

---

From: David Schinazi <[email-masked]>
Date: Thu, 11 Jul 2019 12:18:37 -0700

I would personally recommend having all of these be per-interface, so you
can use DTLS on a Wi-Fi interface and unencrypted Babel on a virtual IPsec
tunnel interface. But I don't feel overly strongly.

David

On Wed, Jul 10, 2019 at 11:48 AM STARK, BARBARA H <[email-masked]> wrote:

> I was reviewing the minutes from Prague, and saw they indicated we didn't
> have resolution on whether certain DTLS configuration parameters should be
> global or at the interface level.
> ----------------------
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 12 Jul 2019 01:19:49 +0200

> I would personally recommend having all of these be per-interface,

I agree.  In the protocol, they're naturally per-interface, it would be
awkward if the management model weren't congruent with what the protocol
naturally yields.

-- Juliusz "I know what congruent means" Chroboczek

---

From: Antonin Décimo <[email-masked]>
Date: Fri, 12 Jul 2019 13:51:58 +0200

I fully concur with the all per-interface.
It’s also more-or-less easy and natural to implement.

Antonin

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 12 Jul 2019 14:30:57 +0000

Thx David (and Juliusz and Antonin – but I’m replying to David’s email since he included the context in his response).

OK, I’ll move dtls-enable to the interface object.

I think dtls-cert-types still belongs at the global layer, since this is a non-configurable statement of capability (which certificate types are supported – presumably by the implementation) and I don’t envision that differing per interface. Note that the interface-level dtls-cert-prefer parameter is what identifies which of these certificate types gets included in a server_certificate_type extension in a Client Hello. As stated in that parameter’s description, the included values are constrained by the requirement that at least one of the certificates associated with the interface must have the certificate type. The global parameter is intended to prevent certificates from being used that the implementation doesn’t know how to parse/use/read.

While I only asked about DTLS parameters, I’m thinking the html-enable should also be moved to the interface object, for the same reason as DTLS (and to provide a certain degree of symmetry). Would anyone object to that?

Barbara

I would personally recommend having all of these be per-interface, so you can use DTLS on a Wi-Fi interface and unencrypted Babel on a virtual IPsec tunnel interface. But I don't feel overly strongly.

David

On Wed, Jul 10, 2019 at 11:48 AM STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
I was reviewing the minutes from Prague, and saw they indicated we didn't have resolution on whether certain DTLS configuration parameters should be global or at the interface level.
----------------------
The current revision has the following global parameters:

   babel-dtls-enable:  Indicates whether the DTLS security mechanism is
      enabled (true) or disabled (false).  An implementation MAY choose
      to expose this parameter as read-only ("ro")..

   babel-dtls-cached-info:  Indicates whether the cached_info extension
      is included in ClientHello and ServerHello packets.  The extension
      is included if the value is "true".  An implementation MAY choose
      to expose this parameter as read-only ("ro")..

_______________________________________________
babel mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/babel<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_babel&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=EHDJHfK0Bm3z9u5TKwhyjjL1p0fdxmXQqf61QbIFn80&s=_GZFMXNfG79TWWM-kCf4uqCubdDzz_qqpttxH9QJ2f4&e=>

---

From: Antonin Décimo <[email-masked]>
Date: Fri, 12 Jul 2019 18:19:30 +0200

Hello Barbara,

> I think dtls-cert-types still belongs at the global layer

After given some thoughts, I completely agree. dtls-cert-types is
simply a superset of all supported certificate types, and
dtls-cert-prefer can be a strict subset if we don’t want to allow a
certain type of certificate on an interface.

-- Antonin

---

From: David Schinazi <[email-masked]>
Date: Fri, 12 Jul 2019 09:48:47 -0700

I agree about making cert types global and hmac per interface.

David