Re: [Gen-art] [6tisch] Review of draft-ietf-6tisch-minimal-17

Kristofer PISTER <> Thu, 05 January 2017 21:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6CA1129428 for <>; Thu, 5 Jan 2017 13:44:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EiHz0EV68Rht for <>; Thu, 5 Jan 2017 13:44:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9BC21295CB for <>; Thu, 5 Jan 2017 13:44:45 -0800 (PST)
Received: by with SMTP id p127so43409028iop.3 for <>; Thu, 05 Jan 2017 13:44:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BJkNSGZTykj1EVRZXKBqJ7XZ2xYRe0S4Mu30lEcOOuM=; b=QjJuqK501dKF3cXwh9bn2Rhf8VfMliNbAqr0wFrfSDabE6HuFr71ncBxIMARLQi2Hp wOq2jvyji3gMIyCtXTtBKksw1l0dIa00DR2cTUPW8igedkJ50sVsOvAsCivwduPeRWBd AjgBOwihR8uPEHPBnZeReRpHm4pQDV51rX9e0+9F5GchNzvzz1uxhe2jO7apUnj1lijR RKS6BbziMhesRtXSdB8plJ07XTkgy9dDfKOiSUS19CX6qltSdOZTkiFjcbCCfMTGCctl 4KMn+A73BTvgLMlEzKnD1Vea9mTbK/6cRnCOHL3ng+pVMIfP5Wg6HNBk8Dt0TcpqE/Ky M5mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=BJkNSGZTykj1EVRZXKBqJ7XZ2xYRe0S4Mu30lEcOOuM=; b=sVgby8Q3FRUtR+0fOavqII2X++lwjCJvo8Kts7QBgl8ACTFK2vyx9TQqsp1KP6piFt fsKdNbP+Uu2z8qhemQ3nsGSLwOCdw45varEnrPG6THy0sPiI3oI/QjN9sOd7PRmVEr4x 8mN0wialA8JIAuq6UHQHygH6s48TEc3uofT05s4PSjKa/9CLRBW0xZmcz2p2IvWLmuyt pcuLmK1YBxWKDw77iKvfKpe8FtcXIvZvCHywXTbE1ZijjmBIqd8e1YvYZ7pGDM+ApZNk AUGPuzdX8ZqTsGWK+cEQm1MC50ZpBSB6Bd8cl0aQE+aKETH/8mnfXOWY/JB8DNbgKeG3 n2Cw==
X-Gm-Message-State: AIkVDXI35wmMjXooukZLqZAA67iVz0J4D0HKU7iQdxsEgkXBg6Ouf3+r6kl3UyRvfJehI+brpwVEw9XBQIpV12vn
X-Received: by with SMTP id y82mr34864563ioy.232.1483652684884; Thu, 05 Jan 2017 13:44:44 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 5 Jan 2017 13:44:44 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Kristofer PISTER <>
Date: Thu, 5 Jan 2017 13:44:44 -0800
Message-ID: <>
To: Tero Kivinen <>
Content-Type: multipart/alternative; boundary=001a11447c1640d55705455fcf51
Archived-At: <>
Cc: "" <>,, Thomas Watteyne <>,
Subject: Re: [Gen-art] [6tisch] Review of draft-ietf-6tisch-minimal-17
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jan 2017 21:44:49 -0000

Tero - you bring up a good point that after all of the discussion of this
issue we have
still not done a good job explaining it, since it's clear that there are
still misunderstandings.

The text in section 4.6 says "This specification assumes the existence of
two cryptographic keys."
That is incorrect, and should be changed.  I propose
"This specification assumes the existence of one protocol identifier, P1,
and one cryptographic
key K2.  P1 provides no security."

Let me go over the reasoning behind having P1.  Any implementation of
6TiSCH has one of
three choices for message integrity on the EBs:
1) use no message integrity
2) use a well-known protocol identifiier, with no security value
3) use a secret key

There is ample evidence that sending 15.4 frames without message integrity
is problematic, so
we'd prefer not to do option 1.
Option 2 provides no security, but it does provide message integrity, and
it provides some level
of confidence that the sender of the frame is using the same version of the
protocol that the
receiver is using.
Option 3 provides all of the benefits of option 2, plus some level of
security.  It is a fine option,
but it assumes the existence of a pre-distributed cryptographic key K1,
which is a non-starter.


On Thu, Jan 5, 2017 at 8:04 AM, Tero Kivinen <> wrote:

> Brian E Carpenter writes:
> > Hi Thomas,
> >
> > The responses to my comments almost all look fine to me. Just one point,
> > on MINOR COMMENT 4 (slide 8):
> >
> > "Shouldn't this also say that this value MUST NOT be used in
> > operational networks?"
> >
> > We've seen many cases over the years of informal values making it into
> shipped
> > products... generally a Bad Thing. But with my lack of IEEE802.15.4
> expertise,
> > I really don't know whether it matters in this case. Whatever the WG
> decides
> > is good, as long as the point is considered.
> It does matter. If anybody knows the key they can do single packet DoS
> attack against network and kill it...
> I.e. send EB to some of the nodes, so that it changes the schedule.
> After that the nodes in the network are out of sync, and after few
> minutes or tens of minutes they will realize this and start to
> recover, but it takes long time, and can cause lots of disruption.
> If node receives EB which says that the EB slot is not timeslot 0, or
> that it has channel offset of 1 or something like that, then it will
> be listening EBs from wrong channel after that. After it misses enough
> of packets from the network it realizes it is out of sync and
> reinitializes itself back to network. This means it needs to do
> passive scan over the 16 channels listening each channel for slot
> frame size * timeslot duration * EB_PERIOD (at minimum, perhaps twice
> in case it happens to miss EB). Meaning that with 101 slot frames, and
> 10ms timeslot duration, and with EB_PERIOD of 3 that is 3 seconds per
> channel, and for 16 channels it takes 48 seconds.
> During that time nodes which were children of that node, will notice
> that it has gone, and they will start doing same...
> The attacker can cause even more confusion by changing the timeslot
> parameters, or channel hopping order, but I would hope that
> implementations would ignore changes to those IEs while the network is
> running.
> On the other changing channel offset or timeslot number for EBs, is
> something that might happen, so nodes might need to cope with that.
> I have complained this clear text password in the specification for
> long time, and I do not think there is any reason to include that key
> in the RFC. The early interoperability testing people can agree on key
> they use in the interoperability events it does not need to be
> hardcoded in the RFC or in the code.
> > I hope the interim goes well, it is too far out of my time zone to
> attend!
> --