Re: [6tisch] [secdir] secdir review of draft-ietf-6tisch-architecture-21

Tero Kivinen <kivinen@iki.fi> Thu, 11 July 2019 21:00 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 0FFC6120168 for <6tisch@ietfa.amsl.com>; Thu, 11 Jul 2019 14:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, 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 zfA7Y4FhgPqQ for <6tisch@ietfa.amsl.com>; Thu, 11 Jul 2019 14:00:26 -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 50CD5120156 for <6tisch@ietf.org>; Thu, 11 Jul 2019 14:00:26 -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 x6BL01MW019976 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jul 2019 00:00:01 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6ALTDo3001979; Thu, 11 Jul 2019 00:29:13 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23846.22697.490492.979920@fireball.acr.fi>
Date: Thu, 11 Jul 2019 00:29:13 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Mališa Vučinić <malishav@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <15836.1561564142@localhost>
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>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 5 min
X-Total-Time: 4 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/S4E22e94tKSPlwTSoW0QjkFdK6E>
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: Thu, 11 Jul 2019 21:00:29 -0000

Michael Richardson writes:
> hmm.   Or, it sees a new beacon, which it can integrity check, and then sees
> the ASN jump forward.  This would be the same as if it had slept for awhile.
>
> Unless the attacker can continuously *block* the node from seeing
> the latest beacons, and continuously feeds it old beacons, the
> problem should go away.

Note, that if attacker forces joining node to be offsetted from real
network, then node will never see real beacon, and attacker has easy
task of replaying old beacons forever.

I.e., real network sends beacon with ASN 12345 on channel 1 at time t.
Then on time t+20 attacker replies that beacon on channel 1 with ASN
12345 for attacked node. Then real network sends its next beacon with
ASN 12445 on channel=8 at time t+100. Attacker replays that at time
t+120 on channnel 8 for the attacked node. The real network would use
channel 11 at time t+120, so those two networks will never hear from
each other.
-- 
kivinen@iki.fi