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

Tero Kivinen <> Mon, 22 July 2019 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96C6B1202F4; Mon, 22 Jul 2019 08:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.419
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sHJ0Pmey2Nm6; Mon, 22 Jul 2019 08:12:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDB971202D2; Mon, 22 Jul 2019 08:12:40 -0700 (PDT)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTPS id x6MFCSQ4011289 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jul 2019 18:12:28 +0300 (EEST)
Received: (from kivinen@localhost) by (8.15.2/8.14.8/Submit) id x6MFCRKP007422; Mon, 22 Jul 2019 18:12:27 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
Date: Mon, 22 Jul 2019 18:12:27 +0300
From: Tero Kivinen <>
Cc: "Pascal Thubert (pthubert)" <>, "" <>, "" <>, Michael Richardson <>, "" <>, Thomas Watteyne <>, David Mandelberg <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 5 min
X-Total-Time: 5 min
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jul 2019 15:12:54 -0000

Mališa Vučinić writes:
> For (2), my understanding is that we have consensus that the
> protection is the existing mechanism specified in RFC8180 making the
> pledge wait for MAX_EB_DELAY before selecting a JP in order to have
> at least NUM_NEIGHBOURS_TO_WAIT distinct JP candidates, with
> legitimate ones advertising a value of ASN that is higher than that
> replayed by the attacker. What seems missing is a note in the
> minimal-security draft that the pledge MUST remain listening on the
> initial channel after receiving the first EB, in order not to enable
> the attacker to desync it from the network. 

Note, that JN cannot yet verify the EBs, and if you take the one with
largest ASN, that allows very easy way for attacker to cause DoS,
i.e., just send ASN of 0xffffff0000 which is very big, and all new
nodes will want to join that.

Also there is no way of knowing whether there is one or multiple TSCH
networks in the same place. One of them could be using ASN of
0x0000123456 and the other might be using 0x0087654321. We do want to
the node to be able to try both.... I do not think the node can really
pick the network based on the EBs properly, and whatever the node is
doing it mught make things worse and might open new attacks.