Re: [6tisch-security] Short address assignment, nonces, and TSCH
Mališa Vučinić <malisa.vucinic@inria.fr> Fri, 02 December 2016 10:07 UTC
Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: 6tisch-security@ietfa.amsl.com
Delivered-To: 6tisch-security@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 49EE7129BC0
for <6tisch-security@ietfa.amsl.com>; Fri, 2 Dec 2016 02:07:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.796
X-Spam-Level:
X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896]
autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3M0iyUCJBnoo for <6tisch-security@ietfa.amsl.com>;
Fri, 2 Dec 2016 02:07:11 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr
(mail3-relais-sop.national.inria.fr [192.134.164.104])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 43ADA129BB5
for <6tisch-security@ietf.org>; Fri, 2 Dec 2016 02:07:11 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.33,729,1477954800"; d="scan'208";a="202584372"
Received: from unknown (HELO [128.93.84.195]) ([128.93.84.195])
by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA;
02 Dec 2016 11:07:09 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= <malisa.vucinic@inria.fr>
In-Reply-To: <22592.7216.968126.340725@fireball.acr.fi>
Date: Fri, 2 Dec 2016 11:07:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <163CC403-7DDC-4895-A2EA-A8C1D8396B5F@inria.fr>
References: <22592.7216.968126.340725@fireball.acr.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch-security/JfCu4AVSL4kS5GAqTsdl-lz4lJs>
Cc: 6tisch-security@ietf.org
Subject: Re: [6tisch-security] Short address assignment, nonces, and TSCH
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Extended Design Team for 6TiSCH security architecture
<6tisch-security.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch-security>,
<mailto:6tisch-security-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch-security/>
List-Post: <mailto:6tisch-security@ietf.org>
List-Help: <mailto:6tisch-security-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch-security>,
<mailto:6tisch-security-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Dec 2016 10:07:14 -0000
Thanks, Tero, for this summary email. Before adding the lease time to the join response, I would like to make sure that the problem you describe cannot be solved by simply avoiding to reuse the address. 65K should give more than enough space for the coordinator not to have to reuse the address it had once assigned. 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), 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? Mališa > On 01 Dec 2016, at 13:48, Tero Kivinen <kivinen@iki.fi> 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. > > In all of this discussions I assume we are using IEEE Std. > 802.15.4-2015 security. > > When not using TSCH the nonce is generated using Source address + > Frame counter and security level. As Frame counter is separate for > each device, that means that only thing that makes sure the nonces are > different is the Source address. Because of this the Source address > must be extended address, as short addresses are only unique during > certain time, not globally. > > 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. > > Now, if the short address assinged to the node A does not have any > timeframe how long it is valid, the coordinator does not know when the > node A stops using the short address, thus it cannot reuse the > address. It cannot assume that all nodes will contact it before going > away and send release for the address lease, so it must use some other > mechanism to guarantee that. > > 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 > of 0x1234, and say that node A is allowed to use it until ASN > 0x12345678a0. After that ASN is reached the node A would need to > contact coordinator again to renew the short address lease (or most > likely it would contact bit earlier and renew the lease so it gets the > same address again). > > This is explained in the IEEE Std. 802.15.4-2015 section 9.3.2.2: > ---------------------------------------------------------------------- > 9.3.2.2 CCM* nonce for TSCH mode > > When TSCH mode is enabled, the nonce shall be formatted as > shown in Figure 9-2. > > +----------------+--------+ > | Octets: 8 | 5 | > +----------------+--------+ > | Source Address | ASN | > +----------------+--------+ > Figure 9-2—CCM* nonce in TSCH mode > > The Source Address shall either be set to the extended address > of the device originating the frame or shall be formatted as > illustrated in Figure 9-3. > > +-----------------+------+--------+---------------+ > | Octets: 3 | 1 | 2 | 2 | > +-----------------+------+--------+---------------+ > | IEEE 802.15 CID | 0x00 | PAN ID | Short address | > +-----------------+------+--------+---------------+ > Figure 9-3—Source Address field for TSCH mode with short addressing > > The IEEE 802.15 CID field contains the CID for IEEE 802.15. > > The PAN ID field contains the PAN ID. > > The Short Address field contains the short address of the > device originating the frame. > > NOTE—When using short addresses in the nonce, it is important > that the coordinator assign unique short addresses. > > The ASN shall be set to the ASN of the timeslot during which > the frame is sent. > ---------------------------------------------------------------------- > 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). > -- > kivinen@iki.fi > > _______________________________________________ > 6tisch-security mailing list > 6tisch-security@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch-security
- [6tisch-security] Short address assignment, nonce… Tero Kivinen
- Re: [6tisch-security] Short address assignment, n… Mališa Vučinić
- Re: [6tisch-security] Short address assignment, n… Tero Kivinen
- Re: [6tisch-security] Short address assignment, n… Michael Richardson
- Re: [6tisch-security] Short address assignment Michael Richardson
- Re: [6tisch-security] Short address assignment, n… Michael Richardson
- Re: [6tisch-security] Short address assignment, n… Tero Kivinen
- Re: [6tisch-security] Short address assignment Tero Kivinen
- Re: [6tisch-security] Short address assignment Michael Richardson