Re: [6tisch] 6tisch join requirements for 6top
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 25 November 2014 13:14 UTC
Return-Path: <pthubert@cisco.com>
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 AA4901A0393 for <6tisch@ietfa.amsl.com>; Tue, 25 Nov 2014 05:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 eyCcUqai1tvR for <6tisch@ietfa.amsl.com>; Tue, 25 Nov 2014 05:14:54 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6462D1A0392 for <6tisch@ietf.org>; Tue, 25 Nov 2014 05:14:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6113; q=dns/txt; s=iport; t=1416921295; x=1418130895; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ni5CADJ+l7pXyiXCU7b6Lrnqmf5bh98ySnatl7qV+XI=; b=TohffXLUe99t9FdRNgLM1jYvt92oE/FqdM4bfDv6Alr1qkH8IrVkMXzX pUgDsq1p9AE4MCtKbSsLn9O6RqtcXmxqywqLRSrbiPqF9AQGvdHPZQBTy xuTuZp2noCRhDQT7c+cMy/MDFBpxOroQ1lptrKW0ohG0vFiqaU4UdFDNs 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAO9/dFStJA2I/2dsb2JhbABbgwaBLcZriQQCgREWAQEBAQF9hAMBAQMBOj8FCwIBCCIUEDIlAgQODROIHAnRGAEBAQEBAQEBAQEBAQEBAQEBAQEZimmFOyYxB4MugR8FkmOjNYICIIFagX5BgQIBAQE
X-IronPort-AV: E=Sophos;i="5.07,455,1413244800"; d="scan'208";a="375130596"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 25 Nov 2014 13:14:54 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAPDErlW008458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Nov 2014 13:14:53 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.182]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 07:14:52 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tero Kivinen <kivinen@iki.fi>
Thread-Topic: [6tisch] 6tisch join requirements for 6top
Thread-Index: AQHQCKFuTcLng3AfvkeaQCVYn0xqc5xxTmSw
Date: Tue, 25 Nov 2014 13:14:52 +0000
Deferred-Delivery: Tue, 25 Nov 2014 13:14:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD848A79AF3@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> <21620.25926.119766.130028@fireball.kivinen.iki.fi>
In-Reply-To: <21620.25926.119766.130028@fireball.kivinen.iki.fi>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.49.80.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/lBa4ofj5PRnvsKyCT6kze5DZvvk
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 13:14:56 -0000
> > [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. [PT] Too late, not enough room. But yes, the discussion is either this or a key. > > > 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? [PT] Not all 802.15.4 obey 6LoWPAN's hopeful thinking. As it goes, even with 6LoWPAN horizon, there is a need to differentiate route-over from mesh under so as to reuse the 33% of the space that was engulfed by mesh-under. So we are discussing a plan B for sorting out network type A from network type B. And yes, we expect that whoever handles non-default keys is conscious enough not to use the WirelessHART key for a 6TiSCH network. > > 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. > [PT] The default key is part of the standard. Any other key would be admin, and certainly there's the limit. We can only hope that an admin who is capable of configuring a non-default key is capable enough to avoid configuring the same key for incompatible networks. Considering the range of 6TiSCH networks, I'd ignore the probability of having 2 different admins come up with the same key in the same area. > 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. > [PT] We are compressing things to a point that nothing is garbage anymore. Agreeably devices may not go wrong, but is a command is interpreted as a reset, reset it will cause. In fact, there is more to an SSID than the MAC encoding. We need something to select a network, by name or type, in the first place. > > 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. [PT] Maybe. The issue is still barring others. > > 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... > [PT] Thanks a bunch for the insight, Tero. > 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. [PT] Ack Pascal
- [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