Subject: [6tisch] comments draft-piro-6tisch-security-issues-01

From: Thomas Watteyne <[email-masked]>
Date: Mon, 6 Jan 2014 23:37:17 -0800

Authors,

I went through the draft and have the following comments. Most of them are
clarifying questions. I leave it up to the security folks to comment on the
validity of the proposed security mechanism, and whether they
are complementary/in conflict with other work.

About the scope, can you confirm that this document covers L2 security
exclusively, i.e. it does not cover the establishment of a secure session
between two devices separated by multiple hops, or between a device in a
6TiSCH network and an outside host?

About the functionality, the draft describes 5 configurations (Full,
Unsecured, Partial, Hybrid, Flexible), some of which support a combination
of secured and unsecured L2 frames depending on the capabilities of the
devices. Can you comment on the rationale between these configurations? I
believe it is useful to look at desired functionality first, and determine
the configurations afterwards. Naively, I am a bit scared of combining
secured and unsecured. TSCH networks are envisioned in the context of the
IT/OT convergence to operate in mission critical environments, so I would
lean towards having only a single configuration: fully secured.

About the network architecture, could you discuss the concept of cluster a
bit (I don't think we have discussed this in the 6TiSCH architecture)? In
particular, I have a hard time understanding what its implications are on
the overall architecture. From Figs. 12 and 13, am I right in saying that a
remote mote and the coordinator need to be one hop away from one another?
If that is the case, can you comment on how this consolidates with the
multi-hop nature of a 6TiSCH network?

About the alignment with the IEEE802.15.4e TSCH:
- The concepts of beacon-enabled and non-beacon-enabled modes is pretty
foreign to IEEE802.15.4e TSCH. Thoughts?
- The same holds for the concepts of RFD and FFD. Comments welcome.
- IEEE802.15.4e introduces enhanced ACK messages (5.2.2.3 in 4e standard)
which supports security. I believe this contradicts the statement "The
table reported in Fig. 5 does not consider ACK messages because they must
not be protected (as imposed by the IEEE 802.15.4 standard)"
- association is optional for TSCH networks. As a result, it is unclear
what the MLME-ASSOCIATE.request primitive does.
- IEEE802.15.4e TSCH specifies that the ASN is used as the frame counter
(section 5.1.1.5.2). Not sure what implications this has on e.g. the
generation of the link key described in 6.3.6.

Finally, section 6.3.1 describes a new IEEE802.15.4 command MAC frame. This
is outside of 6TiSCH's scope. I would recommend alternatives such as using
IEs, in tight coordination with 6top.

Thomas

---

From: Giuseppe Piro <[email-masked]>
Date: Sat, 18 Jan 2014 18:04:43 +0100

Thomas,

many thanks for your comments. Please, find below some answers to your very
useful comments.

> 6TiSCH network and an outside host?

Yes, I confirm: our proposal focus the attention on the L2 and its goal is
to provide security services at the MAC layer.

> lean towards having only a single configuration: fully secured.

Basically, Full, Unsecured, and Partial security configurations maps
possible security levels introduced in Tab 56 of the IEEE 802.15.4 std.
Other configurations have been conceived to offer security features in
heterogeneous scenarios in which there are nodes with security capabilities
and nodes without security capabilities.

Anyway, if the 6tisch target is a fully secured IoT network.... we could
delete other configuration from the draft (no problem for that).

> bit (I don't think we have discussed this in the 6TiSCH architecture)?
>

In literature, some papers use the term "cluster" to indicate a group of
nodes that are one hop away from the other. Could you please suggest the
correct term, which is compatible with the 6tisch architecture, to use in
this case ?

> In particular, I have a hard time understanding what its implications are
> on the overall architecture. From Figs. 12 and 13, am I right in saying
> that a remote mote and the coordinator need to be one hop away from one
> another? If that is the case, can you comment on how this consolidates with
> the multi-hop nature of a 6TiSCH network?
>

As I've confirmed before, our procedure sets the security at the L2 and it
assumes that nodes are one hop away among them.
In multi-hop networks, the procedure should be replicated in each hop. We
supposed that the procedure should be replicated in each "cluster"... but
I've realized that that term is not suitable in the 6tisch context...

> generation of the link key described in 6.3.6.

We will revised the draft in order to fix these issues (thanks).

>
> Finally, section 6.3.1 describes a new IEEE802.15.4 command MAC frame.
> This is outside of 6TiSCH's scope. I would recommend alternatives such as
> using IEs, in tight coordination with 6top.
>
>
Sure, as I've already highlighted in another discussion on the ML, we will
re-design the security procedure by using IEs.

I'm looking forward to receive your replies to my comments.

Cheers
Giuseppe

-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: telematics.poliba.it/piro

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 22 Jan 2014 21:32:06 -0800

Giuseppe,

I would argue that designing a security system with a mix of secured and
unsecured nodes makes little sense. What do others think?

Instead of cluster, what about one-hop neighborhood? Regardless of the
term, can you comment on the suitability of the proposed scheme to a
multi-hop network? What exactly do you mean by "the procedure should be
replicated"?

Thomas

On Sat, Jan 18, 2014 at 9:04 AM, Giuseppe Piro <[email-masked]>wrote:

> Thomas,
>
> many thanks for your comments. Please, find below some answers to your
> very useful comments.
>
>
> On Tue, Jan 7, 2014 at 8:37 AM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> Authors,
>>
>> I went through the draft and have the following comments. Most of them
>> are clarifying questions. I leave it up to the security folks to comment on
>> the validity of the proposed security mechanism, and whether they
>> About the network architecture, could you discuss the concept of cluster
>> a bit (I don't think we have discussed this in the 6TiSCH architecture)?
>>
>

---

From: Tom Phinney <[email-masked]>
Date: Wed, 22 Jan 2014 23:29:30 -0700

> What exactly do you mean by "the procedure should be
replicated"?

He probably means "iterated transitively across the connected
subnet".

One useful way to view the "secured and unsecured nodes" issue is to
consider a spectrum of node security, from 0) none, to 1) lightly
secured by today's standards, to 2) highly secured by today's
standards, to 3) highly secured by tomorrow's standards. Should a
network today be limited to 1) and 2)? Should a network tomorrow be
limited to 2) and 3)? How much difference is there really today
between 1) and 0)? How much difference is there tomorrow between 2)
and 1)? Whatever decision criteria are used today to permit or
reject 0) should apply equally well tomorrow to permit or reject 1).

Now that many of you have been exposed to some (but by no means all)
of the types of exploits used by NSA and other state signals
intelligence services, you may have concluded that the difference
between 0) and 1) is less than you might previously have imagined.
If that is the case, and I believe that it is, then this is not a
binary decision but rather a realization that any node might be
compromised after installation, or be trojaned before installation
(possibly at birth or during shipment). Thus security must be viewed
as occurring among semi-cooperating but not completely mutually
trusting nodes. I took that view when working on the ISA100.11a
security design, and advise others to do likewise.

-Tom

=====

On 2014.01.22 22:32, Thomas Watteyne
wrote:

Giuseppe,

I would argue that designing a security system with a mix
of secured and unsecured nodes makes little sense. What do
others think?

Instead of cluster, what about one-hop neighborhood?
Regardless of the term, can you comment on the suitability of
the proposed scheme to a multi-hop network? What exactly do
you mean by "the procedure should be replicated"?

Thomas

On Sat, Jan 18, 2014 at 9:04 AM,
Giuseppe Piro <[email-masked]>
wrote:

Thomas,

many
thanks for your comments. Please, find below some
answers to your very useful comments.

On Tue, Jan 7, 2014 at 8:37 AM, Thomas
Watteyne <[email-masked]>
wrote:

Authors,

I went through the draft and have the
following comments. Most of them are
clarifying questions. I leave it up to the
security folks to comment on the validity of
the proposed security mechanism, and whether
they are complementary/in conflict with other
work.

About the scope, can you confirm that this
document covers L2 security exclusively, i.e.
it does not cover the establishment of a
secure session between two devices separated
by multiple hops, or between a device in a
6TiSCH network and an outside host?

Yes, I confirm: our
proposal focus the attention on the L2 and its
goal is to provide security services at the MAC
layer.

About the functionality, the draft
describes 5 configurations (Full, Unsecured,
Partial, Hybrid, Flexible), some of which
support a combination of secured and unsecured
L2 frames depending on the capabilities of the
devices. Can you comment on the rationale
between these configurations? I believe it is
useful to look at desired functionality first,
and determine the configurations afterwards.
Naively, I am a bit scared of combining
secured and unsecured. TSCH networks are
envisioned in the context of the IT/OT
convergence to operate in mission critical
environments, so I would lean towards having
only a single configuration: fully secured.

Basically, Full,
Unsecured, and Partial security configurations
maps possible security levels introduced in Tab 56
of the IEEE 802.15.4 std.

Other configurations
have been conceived to offer security features in
heterogeneous scenarios in which there are nodes
with security capabilities and nodes without
security capabilities.

Anyway, if the 6tisch
target is a fully secured IoT network.... we could
delete other configuration from the draft (no
problem for that).

About the network architecture, could you
discuss the concept of cluster a bit (I don't
think we have discussed this in the 6TiSCH
architecture)?

In literature, some
papers use the term "cluster" to indicate a group
of nodes that are one hop away from the other.
Could you please suggest the correct term, which
is compatible with the 6tisch architecture, to use
in this case ?

In particular, I have a hard time
understanding what its implications are on the
overall architecture. From Figs. 12 and 13, am
I right in saying that a remote mote and the
coordinator need to be one hop away from one
another? If that is the case, can you comment
on how this consolidates with the multi-hop
nature of a 6TiSCH network?

As I've confirmed
before, our procedure sets the security at the L2
and it assumes that nodes are one hop away among
them.

In multi-hop networks,
the procedure should be replicated in each hop. We
supposed that the procedure should be replicated
in each "cluster"... but I've realized that that
term is not suitable in the 6tisch context...

About the alignment with the IEEE802.15.4e
TSCH:

- The concepts of beacon-enabled and
non-beacon-enabled modes is pretty foreign
to IEEE802.15.4e TSCH. Thoughts?

- The same holds for the concepts of RFD and
FFD. Comments welcome.

- IEEE802.15.4e introduces enhanced ACK
messages (5.2.2.3 in 4e standard) which
supports security. I believe this contradicts
the statement "The table reported in Fig. 5
does not consider ACK messages because they
must not be protected (as imposed by the IEEE
802.15.4 standard)"

- association is optional for TSCH
networks. As a result, it is unclear what
the MLME-ASSOCIATE.request primitive does.

- IEEE802.15.4e TSCH specifies that the ASN
is used as the frame counter (section
5.1.1.5.2). Not sure what implications this
has on e.g. the generation of the link key
described in 6.3.6.

We
will revised the draft in order to fix these issues
(thanks).

Finally, section 6.3.1 describes a new
IEEE802.15.4 command MAC frame. This is
outside of 6TiSCH's scope. I would recommend
alternatives such as using IEs, in tight
coordination with 6top.

Sure, as I've already
highlighted in another discussion on the ML, we
will re-design the security procedure by using
IEs.

I'm looking forward to
receive your replies to my comments.

Cheers

Giuseppe

--

Giuseppe
Piro, PhD

Post Doc Researcher

DEI, Politecnico di Bari

email: [email-masked]

phone: +39 080
5963301

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