Re: [6tisch] 6tisch join requirements for 6top

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 02 December 2014 14:00 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F201A1B44 for <6tisch@ietfa.amsl.com>; Tue, 2 Dec 2014 06:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 BlrvQ5QbLh6j for <6tisch@ietfa.amsl.com>; Tue, 2 Dec 2014 06:00:30 -0800 (PST)
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 45F611A0155 for <6tisch@ietf.org>; Tue, 2 Dec 2014 06:00:30 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 45B4E2002A; Tue, 2 Dec 2014 09:03:45 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id B33D3637F5; Tue, 2 Dec 2014 09:00:28 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 98AD3637EA; Tue, 2 Dec 2014 09:00:28 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <26401CE1-D6CB-43CB-B195-AB1AA279EC9B@tzi.org>
References: <D0876D12.C03C%rsudhaak@cisco.com> <32412.1415737868@sandelman.ca> <D087B62D.C081%rsudhaak@cisco.com> <10653.1415740821@sandelman.ca> <CADJ9OA_LFkGDuyG_0bf=07d7cvC9FNRr5cMGTmYw2PR=g9XQHA@mail.gmail.com> <8193.1416253349@sandelman.ca> <21619.12717.53454.214321@fireball.kivinen.iki.fi> <E045AECD98228444A58C61C200AE1BD848A77CB5@xmb-rcd-x01.cisco.com> <21620.25926.119766.130028@fireball.kivinen.iki.fi> <54750807.9070901@berkeley.edu> <CADJ9OA_FS2qsTEGCDMMu_wwN=NsfARW26rw_9g9ROP=AHorB3g@mail.gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B29D05F10@TGXML210.toshiba.local> <7934.1417488456@sandelman.ca> <CADJ9OA-rfcMRwNOtOmYnWB+bxH3eY7PTF85NPe_ozaq27JNPMA@mail.gmail.com> <26401CE1-D6CB-43CB-B195-AB1AA279EC9B@tzi.org>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.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-sha1"; protocol="application/pgp-signature"
Date: Tue, 02 Dec 2014 09:00:28 -0500
Message-ID: <13827.1417528828@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/P2MKMAWU96CW2nRwsTu5kRvYegQ
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, Kris Pister <ksjp@berkeley.edu>, "6tisch@ietf.org" <6tisch@ietf.org>, "yoshihiro.ohba@toshiba.co.jp" <yoshihiro.ohba@toshiba.co.jp>
Subject: Re: [6tisch] 6tisch join requirements for 6top
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 02 Dec 2014 14:00:32 -0000

Carsten Bormann <cabo@tzi.org> wrote:
    >> When the node re-joins the network, it will hear the (updated) ASN and
    >>start using that. 

    > Unless it actually "re-joins” an attacker.

So, we are talking about the *join* network not the production network here.
(Nodes that joined the production network would have production keys, and 
would only listen to beacons from other nodes on the "inside".)

Nodes that reboot having not yet joined the production network could very
well join an attacker's network.  This is understood regardless of using a
well known beacon key.  A node which is still in "join stage" might want to
be promiscuous about listening to beacons, and accepting ones with lower
ASN. There is definitely a heuristic here, and it is definitely possible for
a determined attacker who is proximate to the joining node to continuously
DoS the join process.

This conversation started with the assertions that using a well known beacon
key was either impossible, or required too many resources on the part of some
node (unclear to me be if join assistant or join node).

We discussed in some of the design team calls that a node that went through
the join process and discovered that "this wasn't the network it was looking
for" (as a result of failure to authenticate the JCE at the DTLS part of the
6top setup), would have to remember the extended address and/or PANID of the
networks tried so far, and try another one.  I don't think that this
discussion adequatedly made it into draft-richardson-6tisch-security-6top.


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