Re: [6tisch] 6tisch join requirements for 6top

Tero Kivinen <kivinen@iki.fi> Tue, 02 December 2014 10:59 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293EF1A1A9F for <6tisch@ietfa.amsl.com>; Tue, 2 Dec 2014 02:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.131
X-Spam-Level:
X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=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 i-0Akj_4vBd0 for <6tisch@ietfa.amsl.com>; Tue, 2 Dec 2014 02:59:33 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 1A49A1A1A93 for <6tisch@ietf.org>; Tue, 2 Dec 2014 02:59:32 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id sB2AsPrr012814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Dec 2014 12:54:25 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sB2AsOKG028430; Tue, 2 Dec 2014 12:54:24 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21629.39519.998453.904918@fireball.kivinen.iki.fi>
Date: Tue, 02 Dec 2014 12:54:23 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr+ietf@sandelman.ca>
In-Reply-To: <12253.1417451294@sandelman.ca>
References: <D0876D12.C03C%rsudhaak@cisco.com> <32412.1415737868@sandelman.ca> <D087B62D.C081%rsudhaak@cisco.com> <10653.1415740821@sandelman.ca> <CADJ9OA_LFkGDuyG_0bf=07d7cvC9FNRr5cMGTmYw2PR=g9XQHA@mail.gmail.com> <8193.1416253349@sandelman.ca> <21619.12717.53454.214321@fireball.kivinen.iki.fi> <E045AECD98228444A58C61C200AE1BD848A77CB5@xmb-rcd-x01.cisco.com> <21620.25926.119766.130028@fireball.kivinen.iki.fi> <5693.1417383361@sandelman.ca> <21628.26818.749893.359404@fireball.kivinen.iki.fi> <12253.1417451294@sandelman.ca>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 16 min
X-Total-Time: 8 min
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/Q9rt3EWQld8RIFnOi7iqCNwJ_Yw
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Robert Moskowitz <rgm@htt-consult.com>
Subject: Re: [6tisch] 6tisch join requirements for 6top
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 02 Dec 2014 10:59:35 -0000

Michael Richardson writes:
>     > So unless you know the extended address of the sender, you cannot
>     > decrypt the packet, as you cannot calculate the Nonce for the AES-CCM
>     > operation. 
> 
> What I'm reading is that multicasted messages must always use
> extended addresses if they are secured. For other messages, if one
> has a node to node security, then one can map the 16-bit address to
> an extended address, and create the nonce. If one does not have node
> to node security, then the receiving node might not have the
> mapping: does that mean one has to use extended addressing whenever
> there is a single, network-wide key?

Not completely true. If the network is set up so that everybody knows
the mapping from short address to extended address then you can also
use short address when sending packet. For example if you have one PAN
coordinator and everybody knows it because they associate to it first,
then you can use the PAN coordinators short address (or just set the
addressing mode to NONE, in which case no address information is sent
in the packet, and everybody assumes it was sent by the coordinator,
and as they know the coordinators short or extended address, they can
use that to map to the extended address of the sender (i.e.
coordinator in this case)).

All this different addressing models are quite complicated in the
15.4, and there are lots of different ways of doing this. If I have
understood correctly, then most of the networks just use subset of the
options, i.e. they decide that for example coordinator always uses
NONE addressing mode (except for beacons), and everybody knows the
extended address of the coordinator, so there is no need to send it in
frames when sending frames to or from coordinator.

Similarly instead of using the extended address of the owner of the
multicast key, they can also allocate one PAN Id and short address for
the owner. Then the coordinator just needs to be sure that it never
gives that short address to anybody, and the owner of the multicast
key needs to know he is the owner.

So there is lots of different options, and depending on the features
you want you can pick some of the options and use them. So firstly you
need to decide what features you want to have. 
-- 
kivinen@iki.fi