Subject: Re: [6tisch-security] Short address assignment, nonces, and TSCH

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Feb 2017 09:03:13 -0500

Tero Kivinen <[email-masked]> wrote:
    > When using TSCH the situation is bit different as Frame counter is
    > replaced with network global ASN. This means that Source address part
    > needs to be unique for that timeslot. This means that coordinator
    > assigining the short address must make sure that same short address is
    > not given to multiple nodes at the same time, but it can give short
    > address to node A, and when it is sure that node A does not use the
    > short address anymore, it can give the same short address to node B.
    > This means it can reuse the short addresses and it will not run out of
    > short addresses unless it has more than 65k nodes in network.

If the coordinator rekeyed the network, and knew that it had not rekeyed node
A, that would also work, would it not?

    > Easiest way would be to send the lifetime along the short address. As
    > we do have global time in the network (ASN), we can use that as a
    > global time frame, so the coordinator can send node A a short address

Agreed.

Could we set a minimum lifetime, such that we could send just the upper 24 bits
of ASN or something like that?  (5 bytes of ASN pushes us into 8-byte
integers, I think, wasting 3 bytes every time)

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Feb 2017 11:00:41 -0500

Tero Kivinen <[email-masked]> wrote:
    > During the teleconf I pointed out about the issues with the short
    > address assignments and security. This email provides background
    > information and explains the situation bit more.

thank you!

    > needs to be unique for that timeslot. This means that coordinator

Attached below is a yang module to describe the short-address assignment.

    > PAN ID is added, as large networks might use multiple PANs, but still
    > use same secret key (it does not matter whether the ASNs are in sync or
    > not).

Do you think we should slip the PANID in with the short-address assignment?

We have not explained how the pledge knows about PANIDs: clearly it could
just use whatever PANID the beacons it hears contain.   Do you think we need
to be more explicit?

Perhaps we should at least put it in the yang model such that it read back?
I have included an inception date for the short-address for this reason as
well. I called it "effectiveat", but maybe there is a better name.

====

module ietf-6tisch-short-address {
  yang-version 1.1;

  namespace
    "urn:ietf:params:xml:ns:yang:6tisch-shortaddress";
  prefix "ietf6shortaddr";

  //import ietf-yang-types { prefix yang; }
  //import ietf-inet-types { prefix inet; }

  organization
   "IETF 6tisch Working Group";

  contact
   "WG Web:   <http://tools.ietf.org/wg/6tisch/>
    WG List:  <mailto:[email-masked]>
    Author:   Michael Richardson
              <mailto:[email-masked]>";

  description
   "This module defines an interface to set and interrogate the short (16-bit) layer-2 address
    used in 802.15.4 TSCH mode networks.  The short addresses are used in L2 frames
    to save space.  A lifetime is included in terms of TSCH Absolute Slot Number, which
    acts as a monotonically increasing clock.  ";

  revision "2017-03-01" {
    description
     "Initial version";
    reference
     "RFC XXXX: 6tisch minimal security";
  }

  // top-level container
  container ietf6shortaddresses {
    config false;
    description
      "A 16-bit short address for use by the node.";

    leaf shortaddress {
      type binary;
      length 2;
      mandatory true;
      description
        "The two byte short address to be set.";
    }
    leaf validuntil {
      type uint32;
      description "The Absolute Slot Number/256 at which the address ceases to be valid.";
      mandatory true;
    }

    leaf effectiveat {
      type uint32;
      description "The Absolute Slot Number/256 at which time the address was originally set. This is a read-only attribute that records the ASN when the shortaddress element was last written or updated.";
      mandatory false;
    }
  }
}

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Feb 2017 12:26:14 -0500

Tero Kivinen <[email-masked]> wrote:
    >> Then, the question becomes whether we need a mechanism to detect nodes
    >> that are no longer present in the network. In case we use the lease
    >> time as you propose, to have such a mechanism useful, we would need to
    >> set it to a fairly small value (24h or less),

    > Why? The only reason for the lease time is to allow JCE to clean up
    > unused short addresses, and as there is 65k of them, it could be also
    > much longer time, lets say a year or so. If the JCE ever starts running
    > out of addresses (i.e., more than half of the address space is in use),
    > it can shorten the lifetime to a day or so for new devices.

Yes, but that just makes the new devices fight each other for new addresses.
Probably, it should be allocating addresses with some kind of time-based
horizon against which it allocates.  If it knows it will rekey everything by
time X, then it always allocates lifetimes such that they expire by X.

    > As far as I have understood the networks are supposed to be up and
    > running for years, thus having life time of one year etc is not an
    > issue.

Rekeying once a year seems reasonable to me.
Once you rekey, you have to reach out to every node, and the ones that you
fail to reach after some time, are gone, and get cleaned up.

    > On the other hand TSCH nodes, are required to keep constant
    > communication with their timekeeping neighbors (i.e., send packet every
    > few minutes), thus the extra power consumption used for renewal of the
    > address every day or so is negligible.

That might be reasonable, but I think the scale can be extended a lot.

    >> but then we require the whole network to ‘rejoin’ in the same time
    >> frame, which is quite an overhead. I am thinking whether we could
    >> achieve the same functionality by having neighboring nodes report to
    >> JCE that a node left the network upon the removal from the neighbor
    >> table. What do you think?

    > JCE could of course also use the routing table to find out which nodes
    > are still in the network, but that requires whole routing table to be
    > known to the JCE (I am not familiar with the routing protocol used, so
    > I do not know whether it is true or not).

6tisch networks are generally non-storing, which means that the DODAG root(s)
know how to get to every single node.  The JRC (new name for JCE) might have
access to that routing table, but access could be arranged using something
like i2rs perhaps.  In any case, presence of a route does not mean that the
node is alive, or that it's a current route.  RPL is reactive rather than
proactive: if links go in active and nobody is in the forest to notice, then
nobody hears it (to paraphrase a philosophical question).

The JRC contacting the node to attempt to rekey it would be traffic, and said
traffic would cause either a reactive attempt to find the node (if it was
reachable from the same next-hop router), or would fail until the node woke
up and reconnected.  Upon failure, the node's address could be cleaned up at
next rekey, I think.

    > Anyways we are going to need some kind of renewal method, i.e., where
    > node comes back to JCE and says he wants to use same address he had
    > before. This is needed if the node is temperarely disconnect from the
    > network, and when he rejoins the network he needs to go back to the JCE
    > and verify his address is not given out to anybody else while he was
    > away.

    > So as this mechanism is needed regardless whether we have lease time or
    > not if want to cope with JCE reusing addresses, then requiring nodes to
    > do it periodically based on the lease time is not really big overhead.

If the lease time hasn't expired, I think that the address should not be
garbage collected, until a rekey.  Upon rekey, the node is off the network
anyway, and has to do something.

I think that most networks will have enough fewer than 64K nodes that they
can tolerate some leak/loss of 2-byte addresses and mostly never have to
change addresses, even through rekeys.  But the leak will be reclaimed upon
rekey.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Feb 2017 14:29:44 +0200

> A, that would also work, would it not?

Yes, but then it also must make sure, that node A never updates to new
key while someone else is using the same short address.

> integers, I think, wasting 3 bytes every time)

Using ASN value as global time to base expirations is ok, and as
typical ASN will go forward by 100 / second, so not sending lower
16-bits, and only using upper 24 bits will give you resolution of 10
minutes for expiration. On the other hand, in different networks the
timings can be different, so it might be better to allow bit wider
range of values. Perhaps use 32 bits for expiration time, and only
leave lower 8-bits out from the ASN. That will give few seconds
resolution for normal case, but even if the timings are much slower,
the resolution is still adequate.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 24 Feb 2017 13:34:41 +0200

> Do you think we should slip the PANID in with the short-address

What do you mean by that?

> We have not explained how the pledge knows about PANIDs: clearly it
> could just use whatever PANID the beacons it hears contain. Do you
> think we need to be more explicit?

When device searches for network it will listen beacons, and when it
hears beacons it will pick one and set its macPanId to match for that
and join that network. Device can only be part of one PAN at the same
time, i.e. it can only receive frames which are directed to its
macPanId value (or broadcast PAN ID). It can send frames to other PANs
by providing both source and destination PAN.

Each short address is associated with exactly one PAN, i.e., the PAN
of the coordinator who gave it out. 

> Perhaps we should at least put it in the yang model such that it

Could be useful if we at one point want to have networks crossing
multiple PANs. 

> I have included an inception date for the short-address for this
> reason as well. I called it "effectiveat", but maybe there is a
> better name.

Looks ok to me.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Feb 2017 12:47:28 -0500

> What do you mean by that?

I mean, should the JRC set the PANID at the same time as it sets the
short-address.  This provides the option for the join network to be in a
different PANID than the production network, (yes, requires two sets of
beacons, etc.), but also perhaps provides for changing the PANID at the
next rekey.

    > by providing both source and destination PAN.

Right: this is the implicit PANID set.  The new device assumes it should use
the PANID that it hears.

    > Each short address is associated with exactly one PAN, i.e., the PAN of
    > the coordinator who gave it out.

    >> reason as well. I called it "effectiveat", but maybe there is a better
    >> name.

    > Looks ok to me.

Thanks.