Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21
Tero Kivinen <kivinen@iki.fi> Wed, 10 July 2019 22:08 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 55D53120236 for <6tisch@ietfa.amsl.com>; Wed, 10 Jul 2019 15:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Level:
X-Spam-Status: No, score=-3.419 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, URIBL_BLOCKED=0.001] 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 xWq6PqtMJDuy for <6tisch@ietfa.amsl.com>; Wed, 10 Jul 2019 15:08:34 -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 27BC212022D for <6tisch@ietf.org>; Wed, 10 Jul 2019 15:08:33 -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 x6AM8NBC028869 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jul 2019 01:08:23 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6AM8NAx001936; Thu, 11 Jul 2019 01:08:23 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Message-ID: <23846.25047.178698.128250@fireball.acr.fi>
Date: Thu, 11 Jul 2019 01:08:23 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Mališa Vučinić <malisa.vucinic@inria.fr>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <C6BEEFF1-CE2C-4958-ACAB-F1B1FD54B3A3@inria.fr>
References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <MN2PR11MB35651735463F27A247B4B0F0D8E00@MN2PR11MB3565.namprd11.prod.outlook.com> <23825.24715.882644.180316@fireball.acr.fi> <5229f400-076c-80e3-e0dc-a7cf3998abed@mandelberg.org> <MN2PR11MB35654D7658F0EEB05443F2ABD8E30@MN2PR11MB3565.namprd11.prod.outlook.com> <BYAPR11MB3558261B37E1E8FFFF4D8D27D8E30@BYAPR11MB3558.namprd11.prod.outlook.com> <62FC2528-9165-4E2E-89E5-6452D93030E0@gmail.com> <28248.1561477015@localhost> <7C7A7473-7266-4B09-BB41-79C871142BC9@gmail.com> <15836.1561564142@localhost> <MN2PR11MB356596FED088A56533857022D8FD0@MN2PR11MB3565.namprd11.prod.outlook.com> <C6BEEFF1-CE2C-4958-ACAB-F1B1FD54B3A3@inria.fr>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 14 min
X-Total-Time: 14 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/6emr9GJkoU-K_L4jXQKde2rxmSY>
Subject: Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21
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: Wed, 10 Jul 2019 22:08:37 -0000
Mališa Vučinić writes: > Pascal, > > Before the pledge selects a JP, the text from RFC8180 that is relevant seems to be (Section > 6.2): > > When a node joins a network, it may hear EBs sent by different nodes > already in the network. The decision of which neighbor to > synchronize to (e.g., which neighbor becomes the node's initial time- > source neighbor) is implementation specific. For example, after > having received the first EB, a node MAY listen for at most > MAX_EB_DELAY seconds until it has received EBs from > NUM_NEIGHBOURS_TO_WAIT distinct neighbors. Recommended values for > MAX_EB_DELAY and NUM_NEIGHBOURS_TO_WAIT are defined in Figure 5. > When receiving EBs from distinct neighbors, the node MAY use the Join > Metric field in each EB to select the initial time-source neighbor, > as described in Section 6.3.6 of IEEE Std 802.15.4 [IEEE.802.15.4]. > > To me, this text is ambiguous on whether the pledge should duty > cycle its radio according to the schedule found in the first > received EB. When I asked this from 802.15.4 experts they said that normally nodes start listening on channel 1 and stays there for some time, and then move to channel 2 and so on, but usually only limits themselfs to first n channels, as going through all channels to find beacons takes very long time. Normal parameters means that 10 ms * 100 slots = shared slot every second on some channel, with EB_PERIOD of 3 or so, means there will be beacon every 3 seconds, and with 16 channels there will be beacon on channel 1 every 48 seconds. If we would want the system to work even if we miss two beacons then we would need to stay on channel 1 for 144 seconds to be sure that there is no beacons there. Then we would move to channel 2, and repeat. To repeat this process for 16 channels takes 38 minutes... The reason we might not hear anything from channel 1 is because it might be omitted from the hopping sequence as there might be interference on it. Thats why you need to try more than one channel, but there is no need to listen all 16 channels, as if most of the channels have too much interference to cause them not be used, then that network is no longer functional... > In case the pledge does not duty cycle its radio upon receiving the > first EB that happens to be a replay, the attacker cannot really > desync the pledge due to its radio being on 100% of the time waiting > for additional beacons. I think pledge should never do that. It should always stay for same few channels when finding beacons as otherwise attacker sending beacon to pledge can throw it completely out of sync, and single packet can cause join to fail. > Eventually, as Michael noted, one fresh EB will arrive from a > legitimate node with a higher ASN, at which point it becomes > critical for the pledge to select the JP with the largest available > ASN for a given advertised PAN ID. I believe this text deserves > expanded discussion in the Security Considerations of > minimal-security but I am not convinced on the need for a special > mechanism to exchange/sign the ASN. This only works if pedge stays on the same channel while listening beacons, otherwise it will never hear any other beacons after it received attackers beacon (which attacker can send all the time, making sure this is the beacon pledge will hear, and attacker can send it on first channel always, as that is most likely where the pledge starts listening first. But yes, listening on the same channel for multiple beacons, after you hear first one should be ok, with EB_PERIOD of 3 you should get another beacon 48 seconds later, so if you stay for that channel for 180 seconds you should 3-4 beacons. -- kivinen@iki.fi
- [6tisch] FW: [secdir] secdir review of draft-ietf… Pascal Thubert (pthubert)
- Re: [6tisch] [secdir] secdir review of draft-ietf… Mališa Vučinić
- Re: [6tisch] [secdir] secdir review of draft-ietf… Pascal Thubert (pthubert)
- Re: [6tisch] [secdir] secdir review of draft-ietf… Michael Richardson
- Re: [6tisch] [secdir] secdir review of draft-ietf… Mališa Vučinić
- Re: [6tisch] [secdir] secdir review of draft-ietf… Pascal Thubert (pthubert)
- Re: [6tisch] [secdir] secdir review of draft-ietf… Michael Richardson
- Re: [6tisch] [secdir] secdir review of draft-ietf… Pascal Thubert (pthubert)
- Re: [6tisch] [secdir] secdir review of draft-ietf… Mališa Vučinić
- Re: [6tisch] [secdir] secdir review of draft-ietf… Pascal Thubert (pthubert)
- Re: [6tisch] [secdir] secdir review of draft-ietf… Mališa Vučinić
- Re: [6tisch] [secdir] secdir review of draft-ietf… Tero Kivinen
- Re: [6tisch] [secdir] secdir review of draft-ietf… Tero Kivinen
- Re: [6tisch] [secdir] secdir review of draft-ietf… Tero Kivinen
- Re: [6tisch] [secdir] secdir review of draft-ietf… Michael Richardson