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
- [6tisch] CoAP resource management - draft-ietf-6t… Raghuram Sudhaakar (rsudhaak)
- Re: [6tisch] CoAP resource management - draft-iet… Michael Richardson
- Re: [6tisch] CoAP resource management - draft-iet… Carsten Bormann
- Re: [6tisch] CoAP resource management - draft-iet… Raghuram Sudhaakar (rsudhaak)
- Re: [6tisch] CoAP resource management - draft-iet… Michael Richardson
- Re: [6tisch] CoAP resource management - draft-iet… Thomas Watteyne
- Re: [6tisch] CoAP resource management - draft-iet… Pascal Thubert (pthubert)
- [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Xavier Vilajosana
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top Pascal Thubert (pthubert)
- [6tisch] on the fallacy of default keys (was: Re:… Rene Struik
- Re: [6tisch] on the fallacy of default keys (was:… Pascal Thubert (pthubert)
- Re: [6tisch] on the fallacy of default keys Rene Struik
- Re: [6tisch] 6tisch join requirements for 6top Pat Kinney
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top Pascal Thubert (pthubert)
- Re: [6tisch] 6tisch join requirements for 6top Kris Pister
- Re: [6tisch] 6tisch join requirements for 6top Thomas Watteyne
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- [6tisch] emails on 802.15.4 specs Rene Struik
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top yoshihiro.ohba
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Thomas Watteyne
- Re: [6tisch] 6tisch join requirements for 6top Carsten Bormann
- Re: [6tisch] 6tisch join requirements for 6top Thomas Watteyne
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top Tero Kivinen
- Re: [6tisch] 6tisch join requirements for 6top yoshihiro.ohba
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top dejichen
- Re: [6tisch] 6tisch join requirements for 6top Michael Richardson
- Re: [6tisch] 6tisch join requirements for 6top Thomas Watteyne