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

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Aug 2016 18:46:41 -0400

During discussions at IETF96, it became clear that the join ordering/time
sequence envisioned for 6tisch would be less possible than I thought.
The bad news is that a new mechanism might be hard to actually design.
The good news is that I think a new mechanism would put 6tisch join
and ANIMA bootstrap almost identical.

To go back, the proposal was:
  1) a new pledge would send a NA with an EARO, which would turn into a
     DAC/DAR process up to the 6LBR.  The 6LBR would let the JCE know
     about the new node through mechanism TBD.
     The new pledge would receive a NA in reply, which, for the pledge
     would acknowledge that they might be knocking on the right door.
     (A network which didn't like that node would reply in some negative
     fashion, which naturally could also be forged)

  2) the JCE would reach out (via the proxy) to the pledge, on a schedule
     determined by the JCE.  The JCE would control the order of joining,
     and since CoAP would be used with using something like:
          draft-wang-6tisch-6top-protocol-00
     all joining nodes would remain quiet except when responding to
     queries from the JCE.

The goal of having the pledge be passive was one of bandwidth conservation,
the JCE would enroll only as many pledges as it felt it had available
bandwidth in the upper parts of the MESH DODAG tree.  A 6tisch network might
allocate a rather small amount of bandwidth for join messages, and utilizing
the bandwidth responsabily is important.  That means never wasting any energy
among the lower parts of the DODAG when the packets would just get dropped
further upwards.

In discussions, it appears that the EARO as described in
draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID
of draft-sarikaya-6lo-ap-nd-02, and the process is slightly different.

One additional reason why the passive pledge turns out to be a problem is
that the JCE does not actually know the wake/sleep schedule for the pledge.
In the 6tisch case, it ought to be possible for the pledge to sync up to
the schedule and so the proxy will know when it can transmit to it, but
in order to keep the proxy from having to store a lot of data coming from the
JCE, the JCE also needs to know the schedule out at the edge.  This does not
seem unsolveable, but it was an additional concern raised.

Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP
discovery (or DNSSD) to find a proxy.  The new pledge uses the proxy to
initiate an EST session using the proxy.  The enrollment process in the ANIMA
case is driven by the pledge, on the assumption that the ANIMA ACP has
sufficient bandwidth for normal congestion control present in TCP and CoAP to
deal with a limits.

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.

So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy,
but in addition, in the reply, to get some kind of number to seed a backoff
algorithm that causes the pledge to attempt to initiate the join process
at times deterministic to the network.  I'm not talking about an exponential
backoff.

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.

By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, at
rank 3, that it would be able to easily pass some percent of that bandwidth
to a new proxy at rank 4 in a way that does not mean reconfiguring the entire
mesh to delegate bandwidth.

Removing the subdivable property, some simple pseudo-random number generator,
with the right seed would be the right idea.   A good PRNG ought to span
the available time space evenly.  I don't have a solution, but I'm trying to
write up the requirements more clearly.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Aug 2016 13:45:56 +1200

> but in addition, in the reply, to get some kind of number

If you are asking for *content* in a Discovery Response, you are actually
asking for GRASP rapid mode (an objective included in the response message).

I'm not suggesting that this is a problem.

Regards
   Brian

On 17/08/2016 10:46, Michael Richardson wrote:
> _______________________________________________
> Anima-bootstrap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Aug 2016 13:04:17 +0000

Hello Michael

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. 
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.

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.
For this purpose, the DIO may contain new information about root capabilities in the DODAG Configuration option. 

Cheers,

Pascal

> -----Original Message-----
> From: 6tisch-security [mailto:[email-masked]] On Behalf Of
> Michael Richardson
> Sent: mercredi 17 août 2016 00:47
> To: tisch-security <[email-masked]>
> Cc: [email-masked]
> Subject: [6tisch-security] developments on 6tisch join scheduling
> 
> 
> The good news is that I think a new mechanism would put 6tisch join and ANIMA
> bootstrap almost identical.
> 
> the JCE would enroll only as many pledges as it felt it had available bandwidth in
> the upper parts of the MESH DODAG tree.  A 6tisch network might allocate a
> rather small amount of bandwidth for join messages, and utilizing the bandwidth
> responsabily is important.  That means never wasting any energy among the
> lower parts of the DODAG when the packets would just get dropped further
> upwards.
> 
> draft-thubert-6lo-rfc6775-update-00 might be replaced by the Crypto-ID of
> draft-sarikaya-6lo-ap-nd-02, and the process is slightly different.
> 
> One additional reason why the passive pledge turns out to be a problem is that
> the JCE does not actually know the wake/sleep schedule for the pledge.
> In the 6tisch case, it ought to be possible for the pledge to sync up to the
> schedule and so the proxy will know when it can transmit to it, but in order to
> keep the proxy from having to store a lot of data coming from the JCE, the JCE
> also needs to know the schedule out at the edge.  This does not seem
> unsolveable, but it was an additional concern raised.
> 
> Meanwhile, in ANIMA bootstrap, the initial contact is through a GRASP discovery
> (or DNSSD) to find a proxy.  The new pledge uses the proxy to initiate an EST
> session using the proxy.  The enrollment process in the ANIMA case is driven by
> the pledge, on the assumption that the ANIMA ACP has sufficient bandwidth for
> normal congestion control present in TCP and CoAP to deal with a limits.
> 
> 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
> So the idea is to use the ANIMA GRASP discovery mechanism to find a proxy, but
> in addition, in the reply, to get some kind of number to seed a backoff algorithm
> that causes the pledge to attempt to initiate the join process at times
> deterministic to the network.  I'm not talking about an exponential backoff.
> 
> By subdividable, I mean, if we pass 5% of the join bandwidth to proxy A, at rank
> 3, that it would be able to easily pass some percent of that bandwidth to a new
> proxy at rank 4 in a way that does not mean reconfiguring the entire mesh to
> delegate bandwidth.
> 
> the available time space evenly.  I don't have a solution, but I'm trying to write
> up the requirements more clearly.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>