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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 21 February 2017 14:03 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 4FD8F129BC7 for <6tisch-security@ietfa.amsl.com>; Tue, 21 Feb 2017 06:03:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 GzeEYCMnSZXO for <6tisch-security@ietfa.amsl.com>; Tue, 21 Feb 2017 06:03:15 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C199B129BC2 for <6tisch-security@ietf.org>; Tue, 21 Feb 2017 06:03:15 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7C671203AF; Tue, 21 Feb 2017 09:25:03 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 65AC4636BB; Tue, 21 Feb 2017 09:03:13 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tero Kivinen <kivinen@iki.fi>
In-Reply-To: <22592.7216.968126.340725@fireball.acr.fi>
References: <22592.7216.968126.340725@fireball.acr.fi>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 21 Feb 2017 09:03:13 -0500
Message-ID: <11405.1487685793@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch-security/yMZafx3QFdEIhQZxaU3cqfK1p-8>
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: Tue, 21 Feb 2017 14:03:17 -0000

Tero Kivinen <kivinen@iki.fi> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-