Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

Tero Kivinen <kivinen@iki.fi> Thu, 29 August 2019 23:16 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78667120129; Thu, 29 Aug 2019 16:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.42
X-Spam-Level:
X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 v6A9SZpRW5oJ; Thu, 29 Aug 2019 16:16:08 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 D44901200D6; Thu, 29 Aug 2019 16:16:07 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x7TNFLqo017559 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Aug 2019 02:15:21 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x7TNFKQY000661; Fri, 30 Aug 2019 02:15:20 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23912.23688.508274.381182@fireball.acr.fi>
Date: Fri, 30 Aug 2019 02:15:20 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Roman Danyliw <rdd@cert.org>, "shwetha.bhandari\@gmail.com" <shwetha.bhandari@gmail.com>, "6tisch-chairs\@ietf.org" <6tisch-chairs@ietf.org>, The IESG <iesg@ietf.org>, "6tisch\@ietf.org" <6tisch@ietf.org>, "draft-ietf-6tisch-architecture\@ietf.org" <draft-ietf-6tisch-architecture@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
In-Reply-To: <MN2PR11MB35654D0C271FE2B297EECD43D8A30@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <156523837973.8301.2864865066450595993.idtracker@ietfa.amsl.com> <MN2PR11MB3565FC066DB6EB01DA5E30F1D8A50@MN2PR11MB3565.namprd11.prod.outlook.com> <359EC4B99E040048A7131E0F4E113AFC01B343BFC0@marathon> <MN2PR11MB35657EF40A759366396FD3FCD8A10@MN2PR11MB3565.namprd11.prod.outlook.com> <23909.10610.552936.793775@fireball.acr.fi> <21458.1566927814@localhost> <MN2PR11MB35654D0C271FE2B297EECD43D8A30@MN2PR11MB3565.namprd11.prod.outlook.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 9 min
X-Total-Time: 8 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/lKQB9Ouyz_8z-8e0ZgEQCpczJYk>
Subject: Re: [6tisch] Roman Danyliw's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2019 23:16:11 -0000

Pascal Thubert (pthubert) writes:
> - If we keep resource blocks of 10ms in 5G, there will be multiple
> packets, so ASN will need an extension (at least an additional octet
> that would be signaled in band) to count the packet with a finer
> granularity than ASN, within the time slot.

There is no space in the nonce to extend ASN, so changing ASN size to
bigger number, or transmitting multiple packets from the same source
address inside the same ASN is not a problem that can be solved
easily. ASN already stole one byte from the nonce so it was able to be
expanded to 5 octets (frame counter is 4 octets and the 5th octet in
normal nonce is used for security level to protect against MIC
truncation problems when using same key with different length MICs).

The current TSCH security do assume that every node sends at most one
frame during one timeslot. Multiple nodes might send other frames
at the same timeslot using different channels etc, as the nonce
contains source address, and different nodes have different source
addresses. In normal case there is two frames sent inside the same
timeslot, one from sender to recipient using extended address of
sender in nonce, and one Ack from the recipient to sender using
extended address of the recipient in the nonce. Both of them use same
ASN and extended address + ASN makes the 13 octets we have available
in nonce.
-- 
kivinen@iki.fi