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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 25 June 2019 15:36 UTC

Return-Path: <mcr+ietf@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 5684212062C for <6tisch@ietfa.amsl.com>; Tue, 25 Jun 2019 08:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 UTQkOTAdvgOU for <6tisch@ietfa.amsl.com>; Tue, 25 Jun 2019 08:36:56 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BECA120611 for <6tisch@ietf.org>; Tue, 25 Jun 2019 08:36:56 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E8E73808A; Tue, 25 Jun 2019 11:35:13 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 34B21109C; Tue, 25 Jun 2019 11:36:55 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 322229BC; Tue, 25 Jun 2019 11:36:55 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malishav@gmail.com>
cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Tero Kivinen <kivinen@iki.fi>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <62FC2528-9165-4E2E-89E5-6452D93030E0@gmail.com>
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>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 25 Jun 2019 11:36:55 -0400
Message-ID: <28248.1561477015@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/4cNz2TllZjVWntjIZJhm5OqGVts>
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: Tue, 25 Jun 2019 15:36:58 -0000

Mališa Vučinić <malishav@gmail.com> wrote:
    > Instead, as with traditional TSCH, the joined node can obtain its time
    > information from its time source neighbor, i.e. RPL preferred parent,
    > by triggering an exchange of link-layer frames with L2 security
    > features enabled. The MSF draft already mandates that the first
    > outgoing message from the joined node after joining is the 6P ADD
    > message to its preferred parent, which consequently gets protected with
    > L2 security.

But, how can the L2-security work if the newly-joined node has an ancient
ASN?  Won't the parent just drop the packet as being a replay, and then what?

    > What needs to be specified clearly is that this first 6P
    > exchange should not be encrypted but only authenticated at L2.
    > Upon successful completion of the first 6P exchange with its time (routing)
    > parent, the joined node obtains a negotiated cell and as a side effect
    > proves freshness of the ASN used.

I'd rather that we added a new exchange, rather than special casing some 6P
interaction here.   An RPL DIS would be a better choice here, I think, with
an RPL DAO unicast reply.  Still, I hate to special case this as being
authenticated only.
Doesn't that have to happen first?

Is the DIS unicast or multicast. Hmm.
How do we put something unique in it that has to be replied to proving the
freshness of the ASN against a reply attack.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-