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

Tero Kivinen <kivinen@iki.fi> Tue, 25 November 2014 11:18 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 49CF31A00EF for <6tisch@ietfa.amsl.com>; Tue, 25 Nov 2014 03:18:01 -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 VaLsd6zwHf8y for <6tisch@ietfa.amsl.com>; Tue, 25 Nov 2014 03:17:59 -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 3777D1A00F0 for <6tisch@ietf.org>; Tue, 25 Nov 2014 03:17:54 -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 sAPBHSDd007058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Nov 2014 13:17:28 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sAPBHQYM011479; Tue, 25 Nov 2014 13:17:26 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21620.25926.119766.130028@fireball.kivinen.iki.fi>
Date: Tue, 25 Nov 2014 13:17:26 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD848A77CB5@xmb-rcd-x01.cisco.com>
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>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 50 min
X-Total-Time: 25 min
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/JFWH7TbksOJ_eY206I_2wgT_Sig
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "6tisch@ietf.org" <6tisch@ietf.org>, Robert Moskowitz <rgm@htt-consult.com>, "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.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, 25 Nov 2014 11:18:01 -0000

Pascal Thubert (pthubert) writes:
> [PT] The use of a well-known beacon key (Defaulting to"6TISCHJOIN")
> has been debated for a while. The lack of an ethertype has already
> lead in the field to frame from protocol A being understood -wrong-
> by protocol B. 

So when someone is running the protocol A and B both over the same
default well-known key then you still have the problem...

You could add new header information element to the beacon specifying
the "service name" and then use that to separate the network where you
want to join. That would be clearer, and better way of doing that. 

> Even if that looks anecdotic, we are now facing the need to reuse
> some messaging footprint in 6LoWPAN, and if that happens, we need to
> make sure that the overlapping protocol elements never mix in a same
> network. 

Didn't 6LoWPAN add some multiplexer in the beginning of data, or do I
remember wrong? 

> So, agreeably, the beacon key does not provide protection against
> rogues, but it does provide protection against unexpected impact of
> coexisting but incompatible protocols. 

Only if they are not using the same well known keys. I.e. if you
cannot coordinate protocol A and B running on the same are not to mess
up each other, there is nothing saying you cannot have same mixup
happening over the same well-known keys.

Anyways even if the device gets garbage in, that should not cause
any catastrophic problems, it might just cause some upper layer
processes to start up and see garbage and then throw things out. The
system should be robust against such attacks, regardless whether they
are from the real attackers or from someone just happening to using
same band for some other traffic. 

> IOW, the beacon key can be seen as an SSID that will isolate
> networks that are incompatible or should not be mixing for some
> policy reasons. 

Adding SSID Header IE would most likely be better solution. 

> The KIM would probably be 0 (correct?) and some meta would indicate
> the bundle that is used to join (a bundle reserved for that purpose
> actually), and on that bundle, no actual security can be expected,
> so all sort of preventive actions, such as defense against DoS, will
> be activated. 

Key Identifier Mode 0, cannot be used, as it is peer to peer keys, and
there is only one of those keys between the peers, i.e. if you use Key
Identifier Mode 0, then this is the ONLY key that can be used between
the coordinator and peer.

Also as the new device joining the network do not know who is going to
send beacons, it cannot create the KeyDescriptor entries for it, i.e.
all devices in the network needs to be configure with macPANId and
macCoordExtendedAddress, i.e the device needs to know the extended
address of the coordinator sending the beacon beforehand. This is bit
hard to set up...

For the same reason you cannot use Key Identifier Mode 1, as that
would require configuring the extended address of the coordinator in
the macDefaultKeySource PIB entry.

Hmmm..actually even Key Identifier Modes 2 or 3 cannot be used, as
they also require the MAC to fill the KeyDescriptor beforehand, and
there they will need to now the extended address of the coordinator.

Of course the 15.4 does not tell how the KeyDescritors are created, I
have always assumed that upper layer creates them when the inbound
security processing fails with UNAVAILABLE_KEY. I.e. this error would
somehow be passed to the upper layer along with the KeyIdMode,
KeySource, KeyIndex, device addressing mode, device PANID and device
address. The upper layer would then see if it can create KeyDescriptor
entry for the key and if so, it would do so and for the next packet
from the same peer the entry would be there. All of this is of course
NOT specified in the 15.4, so there is no way to say what
implementations do.

So if this kind of joining key for beacon is wanted, I think the best
way would be to use Key Identifier Mode 3, as then the beacon actually
has all the information needed to create the KeyDescriptor. This will
then mean that beacons will have 14 bytes of auxiliary security
header, and 4 to 16 bytes of MIC. Adding for example 10-byte SSID
Header IE would make packets smaller...

Note, that receiving peer needs to know the extended address of the
sender in the 15.4 to be able to decrypt the packet, as the nonce
generation depends on that. There is no way around that. 
-- 
kivinen@iki.fi