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

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 14 July 2019 21:13 UTC

Return-Path: <mcr@sandelman.ca>
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 32C0B120183 for <6tisch@ietfa.amsl.com>; Sun, 14 Jul 2019 14:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 XhNK388hnTzA for <6tisch@ietfa.amsl.com>; Sun, 14 Jul 2019 14:13:43 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3161912003E for <6tisch@ietf.org>; Sun, 14 Jul 2019 14:13:43 -0700 (PDT)
Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id A86B21F44D; Sun, 14 Jul 2019 21:13:40 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3CCB61301; Sun, 14 Jul 2019 17:13:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tero Kivinen <kivinen@iki.fi>
cc: =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= <malishav@gmail.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6tisch@ietf.org" <6tisch@ietf.org>
In-reply-to: <23846.22697.490492.979920@fireball.acr.fi>
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> <23846.22697.490492.979920@fireball.acr.fi>
Comments: In-reply-to Tero Kivinen <kivinen@iki.fi> message dated "Thu, 11 Jul 2019 00:29:13 +0300."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sun, 14 Jul 2019 17:13:59 -0400
Message-ID: <8120.1563138839@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/Cniw7eiihqYkL5ANCXDYyp53i-Y>
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: Sun, 14 Jul 2019 21:13:46 -0000

Tero Kivinen <kivinen@iki.fi> wrote:
    >> 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.

Agreed.

{If the attacker is this good at finding non-overlapping bandwidth, then
attacker could instead make $$$$ fast offer network optimization services :-)}

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [