Subject: Re: [6tisch-security] developments on 6tisch join scheduling

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Sep 2016 08:44:58 -0400

{after some days in the drafts queue}

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > About your subdivision:

    > One may note that to root sees it all, and it the ultimate limit of the
    > bandwidth that may be given to join process.

Yes. Very much agreed, and I want to subordinate all join scheduling to the
limit that the root has established.

    > The bigger the network the slower a given JA can accept new joins. And
    > the deeper the JA, the more overall resources will be consumed by a
    > join.

    > Since this is dynamic and dependent on the network, it may be that we
    > need the root to provide JAs with a MTBJ (mean time between joins) that
    > depends on the rank or something.

Yes, that was essentially my goal.

    > We can wonder if the root itself could be the proxy, being triggered by
    > a DAR message as you described. The root can afford to maintain an EST
    > session.
    > The root would arbitrate when that request is being served. And that
    > the root may instruct in the DAC when the device is entitled to
    > continue its join process.

Yes, this is what I want to do: add something to the DAC that instructions
the new device when it should retry.

    > For this purpose, the DIO may contain new information about root
    > capabilities in the DODAG Configuration option.

I agree that the root ought to have the resources to maintain sessions if
needed, but I don't know if we need that.  The DTLS (or EDHOC) session itself
needs to extend to the new pledge for cryptographic reasons.

    >> What is needed is a way to adjust things so that the pledges will attempt to join
    >> in a way that does not overwhelm the network, and more so, that the proxy
    >> nodes can easily police that they are doing so.

...

    >> This is where the hard part is, how to come up with a simple to describe, and
    >> simple to code algorithm which would fill up the available bandwidth, and be
    >> easily subdividable.

Upon further reflection, I think that the 6LBR shall decide and provide the
interval via the DAC.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-