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

From: Thomas Watteyne <[email-masked]>
Date: Wed, 4 Jan 2017 13:38:02 +0100

Brian,
Just a quick admin update that the authors have taken your comments into
account, which will be integrated in -18.
We will discuss the proposed resolutions at an interim meeting this Friday
and publish it next week.
Thomas

On Sat, Dec 10, 2016 at 11:39 PM, Brian Carpenter <
[email-masked]> wrote:

> Reviewer: Brian Carpenter
> Review result: Almost Ready
>
> Gen-ART Last Call review of draft-ietf-6tisch-minimal-17
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-6tisch-minimal-17.txt
> Reviewer: Brian Carpenter
> Review Date: 2016-12-11
> IETF LC End Date: 2016-12-20
> IESG Telechat date: 2017-01-05
>
> Summary: Almost Ready
> --------
>
> Comment:
> --------
>
> Although I found some issues, this is a good document which is mainly
> very clear. I was not in a position to check IEEE802.15.4 details.
>
> It's too late now, but judging by the shepherd's writeup, this draft
> would have been an excellent candidate for an Implementation Status
> section under RFC 6982.
>
> Major Issues:
> -------------
>
> I was very confused for several pages until I went back and read this
> again:
>
> >   This specification defines operational parameters and procedures
> for
> >   a minimal mode of operation to build a 6TiSCH Network.  The
> 802.15.4
> >   TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective
> >   Function 0 (OF0) [RFC6552], are used unmodified.
>
> Then I realised that there is some very basic information missing at
> the beginning
> of the Introduction. That little phrase "the 6LoWPAN framework" seems
> to be the clue.
> What is the 6LoWPAN framework? Which RFCs? I'm guessing it would be
> RFC4944, RFC6282
> and RFC6775, but maybe not. In any case, the very first sentence of
> the Introduction
> really needs to be a short paragraph that explains in outline, with
> citations, how a
> 6TiSCH network provides IPv6 connectivity over NBMA. With that, the
> rest of the document
> makes sense.
>
> But related to that, the Abstract is confusing in the same way:
>
> > Abstract
> >
> >   This document describes a minimal mode of operation for a 6TiSCH
> >   Network.  It provides IPv6 connectivity over a Non-Broadcast
> Multi-
> >   Access (NBMA) mesh...
>
> "It" is confusing since it seems to refer to this document, which
> hardly
> mentions IPv6 connectivity. I suggest s/It/6TiSCH/.
>
> As far as I know a Security Considerations section is still always
> required. I understand
> that this document discusses security in detail, but that doesn't
> cancel the
> requirement (https://tools.ietf.org/html/rfc3552#section-5).
>
> Minor issues:
> -------------
>
> > 4.4.  Timeslot Timing
> ...
> >   The RX node needs to send the first bit after the
> >   SFD of the MAC acknowledgment exactly tsTxAckDelay after the end
> of
> >   the last byte of the received packet.
>
> I don't understand "exactly". Nothing is exact - there is always clock
> jitter.
> Shouldn't there be a stated tolerance rather than "exactly"?
>
> > 4.5.  Frame Formats
> >
> >   The following sections detail the RECOMMENDED format of link-layer
> >   frames of different types.  A node MAY use a different formats
> (bit
> >   settings, etc)...
>
> Doesn't this create an interoperability issue for independent
> implementations?
> How can you mix and match implementations that use variants of the
> frame format?
> This seems particularly strange:
>
> >   The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames
> >   SHOULD include the Source Address field and the Destination
> Address
> >   field.
>
> How will it work if some nodes omit the addresses?
>
> > 4.6.  Link-Layer Security
> ...
> >   For early interoperability testing, value 36 54 69 53 43 48 20 6D
> 69
> >   6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1.
>
> Shouldn't this also say that this value MUST NOT be used in
> operational networks?
>
> Nits:
> -----
>
> > 1.  Introduction
> >
> >   A 6TiSCH Network provides IPv6 connectivity...
>
> I would expect to see a reference to [RFC2460] right there.
>
> Outdated reference: draft-ietf-6lo-paging-dispatch has been published
> as RFC 8025
>
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 4 Jan 2017 15:43:27 +0100

Brian, all,

We have discussed the possible resolutions to your comments with Xavi. I
have captured those in a slideset [1] to be presented at this Friday's
interim meeting [2].

Early comments about the discussions and proposed resoltuion in the
slideset, in preparation for their presentation on Friday, welcome.

Thomas

[1]
https://bitbucket.org/6tisch/meetings/src/master/170106_webex/slides_170106_webex_b_minimal_brian.ppt?fileviewer=file-view-default
[2] https://www.ietf.org/mail-archive/web/6tisch/current/msg05106.html

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Jan 2017 11:34:44 +1300

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.

I hope the interim goes well, it is too far out of my time zone to attend!

Thanks
   Brian

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Jan 2017 18:04:45 +0200

> 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.

-- 
[email-masked]

---

From: Kristofer PISTER <[email-masked]>
Date: Thu, 5 Jan 2017 13:44:44 -0800

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.

ksjp

---

From: PWK <[email-masked]>
Date: Fri, 6 Jan 2017 08:55:23 -0600

Kris; I totally agree with your explanation, but perhaps a slight editorial change?

"This specification assumes the existence of one protocol identifier, P1, and one cryptographic
key K2.  P1’s purpose is to provide message integrity, it is not to provide security.”

Pat

On 5, Jan2017, at 15:44, Kristofer PISTER <[email-masked]> wrote:

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.

ksjp

On Thu, Jan 5, 2017 at 8:04 AM, Tero Kivinen <[email-masked] <mailto:[email-masked]>> wrote:

--
[email-masked] <mailto:[email-masked]>

_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 9 Jan 2017 17:40:01 +0200

Kristofer PISTER writes:
> 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.

Clearly. 

> 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."

I do not undestand why you want to throw away the protection K1 can
provide?

If you have two cryptographic keys, K1 and K2, they both will provide
protection against different types of attack. K1 makes sure that
no outsider who does not know K1 can create fake EBs. This means that
sleeping nodes waking up and wanting to resync themself to the
network, which has not changed its K1 during the nodes sleep, can do
so by just seeing K1 protected EB.

It also means that there is at least some protection for the devices
already in the network against malicious EBs which could try to change
the network parameters of the network.

If K1 is not secret, then both of these protections are lost.

K2 is used to provide confidentiality and authenticity of the other
messages than EBs.

There is actually no reason why K1 and K2 needs to be separate, but
both of them needs be secret and unique.

> 2) use a well-known protocol identifiier, with no security value

And only option 3 makes any sense if any security is needed. If you
are willing to run network without any security you can then go with
option 1 and 2, but don't use them if you want security. 

> There is ample evidence that sending 15.4 frames without message
> integrity is problematic, so we'd prefer not to do option 1.

I think most of that evidence is based on the 802.15.4 frames and not
802.15.4-2015 EB frames with TSCH related IEs.

Yes, getting random garbage looking like 11-21 byte beacon frame with
valid checksum is going to happen every now and then.

Having random garbage with length 48 bytes to match EB with acceptable
TSCH related IEs is much more improbable.

As joining process is only very small amount of the use of the
network, we should not try to optimize the performance during joining
process, and sacrifice the security of the rest of the network use
time.

After the joining process is done, the node knows K1, and then it can
get much better protection against random garbage.

> 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.

Yes, it does provide that for the joining process, but sacrifices the
security of the rest of the time, i.e., after the node has joined the
network.

Also option 2 only causes issues for the nodes trying to join the
network. I.e., they might try to join network they think are there,
because they see random garbage that looks like valid EB. So what.
They waste a bit of resources there, but if they see valid EB they can
pick that. Also easy solution to that is to wait for two valid EBs
from the same coordinator before trying to join. I.e., when node sees
first EB, they will know where the next EB can be, so they can jump to
that channel to listen for it and so on on until it finds second copy
of the same EB. After that they can be sure that there is network
there.

They still do not know if that network is correct for them to join in,
but using option 2 does not provide that information either. It only
tells that there is some (or multiple) networks using same P1. And if
we put P1 in the RFC everybody will be using that same P1.

> 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.

No, it does require pre-distributed cryptographic K1.

It requires clients to join the network without knowing K1, and after
they have joined the network they will learn the K1 and K2, and after
that they can start using K1 and K2 to secure the traffic in the
network.

The 802.15.4 do provide a way for nodes to parse EBs and join the
networks WITHOUT knowing the key used to protect the EB.

Also even if you do know K1, you still cannot use that to protect the
first EB. The first EB contains the ASN, which is needed to validate
the EB, and before the ASN can be read from the IE contained in the
EB, the EB frame needs to be authenticated, which is not possible as
the ASN is not known... I.e., chicken and egg problem.

Because of this the 802.15.4 do allow EBs to be passed higher layer
even if their security processing failed (either because of not
knowing the key to protect it, or not knowing the ASN used to
calculate Nonce). So the higher layer can then take the ASN out from
there, configure that to the MAC layer, and send some unprotected
joining messages to the coordinator, asking to join the network, and
the coordinators are using the SecExempt flag to allow those joining
nodes to bypass the security checks for the incoming traffic for those
joining messages so those messages can be processed in clear tetx even
when everything else is mandated to be protected.

So to repeat this one more time:

Using known K1 or P1 or whatever it is called, is BAD idea, and it is
better to use unique K1, which is distributed to the network at the
same time as K2 is generated for the network nodes. 
-- 
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Jan 2017 11:17:48 +1300

FYI, I have checked the -18 draft that just appeared and it
answers all my points. If asked to review it again, I expect
to say "Ready".

Thanks
   Brian Carpenter