Subject: [babel] [Babel-users] Reworked implementation of Babel-over-DTLS

From: Antonin Décimo <[email-masked]>
Date: Fri, 15 Mar 2019 14:55:46 +0100

Hello lists,

I’ve finally managed to rework my implementation of Babel-over-DTLS
(spoiler: it seems to be working).  Thanks to Juliusz for the help.
You can get the code by doing

    git clone -b dtls2 https://github.com/MisterDA/babeld

The code requires the mbedTLS library (version 2.16) [1].

The code is still heavily instrumented (lots of printfs…).  While this
code is not carefully tested, it is meant to eventually implement the
protocol described in

    https://tools.ietf.org/html/draft-ietf-babel-dtls

Known issues:

  - no interoperability testing has been done yet;
  - we don’t timeout neighbours properly, which makes us vulnerable to
    delayed packets;
  - there is no user interface to provide certificates and keys, they
    are all hard-coded in the DTLS library.

It is unclear to me how the user interface to provide certificates and
private keys should look like, and if we prefer CA certificates or
self-signed.  Perhaps the draft should be more specific about that.

You can test this code by saying something like:

    babeld -C 'interface eth0 unicast true dtls true'

The "unicast true" flag tells babeld to send all TLVs but Hello TLVs
over unicast, "dtls true" tells babeld to use DTLS on the selected
interface.  The "unicast" flag is required for Babel-over-DTLS to
operate as expected.  Use "dtls-protocol-port" to specify a port.  The
default port is hard-coded to 50000, a port number has been requested
to IANA.

[1]: https://tls.mbed.org/

--
Antonin Décimo

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 15 Mar 2019 22:46:05 +0000

> (spoiler: it seems to be working).  Thanks to Juliusz for the help.

Cool. This is great.

<snip>

> It is unclear to me how the user interface to provide certificates and private
> keys should look like, and if we prefer CA certificates or self-signed.  Perhaps
> the draft should be more specific about that.

Since no one else answered, here are my opinions...

My reading of the babel-dtls draft (and DTLS references) is 2 types of certificates are mentioned: X.509 is mandatory and Raw Public Key is optional. Raw Public Key has no signature (self or CA). X.509 can be self-signed or signed by someone else (i.e., a CA). In all cases, the implementation needs (somehow) to be configured with the certificates it trusts for use with Babel. If CAs are going to be trusted to sign usable-for-my-Babel-network certs, then the implementation needs to be configured with CA X.509 certificates that are trusted by the owner of the Babel network.

For a basic implementation, I would suggest having a Babel trust store for certificates that are directly trusted for use with Babel (independent of whether or how they are signed). If the certificate is in the Babel trust store, it's trusted.

If you also want to support CA-signed trust of X.509 certificates (that are not yet in the Babel trust store), then you need a store of trusted Babel CA certificates. This store MUST NOT be the same trust store used for any web browsers or software updates, etc. It MAY be a trust store of CAs trusted to sign certificates for devices allowed to operate on this (local or virtually local) network. Even if you support CA-signed, you can store received certificates signed by trusted CAs in the "directly trusted" Babel store for future direct trust. 

As for user interface: One way to do this simply would be to allow a person to provide a file (for trusted certificates) with one or more certificates in PEM format. For the device's own certificate, you could probably get it to generate its own (self-signed certificate) and then provide a file with the certificate in PEM format (that you can then load into other devices). Since the certificate was locally generated, it will already have the private key -- so you won't need to deal with that. All certificate-generating utilities support PEM. If you're running a CA that will generate all the certificates and associated private keys, you'll need to see what file formats that CA implementation supports, for exporting certificates and private keys. Then support that. PEM will likely be supported, but you'll need to see how Certificate+Key gets done.

Barbara