Subject: [6tisch] avoiding allocating cells for join traffic

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Feb 2017 11:52:33 -0500

Malisa and I, when editing the documents this week came across a concern
that we had.  It involves the traffic between the Join Proxy (JP), and the
Join Registrar/Coordinator (JRC, formerly known as JCE).

This is regular traffic, and is would flow through the mesh as would any
other traffic.  Only the JP and JRC would know it was join traffic, and
if the JRC is not-within the LLN (beyond the DODAG root), then the DODAG
root wouldn't be able to identify the join traffic.  In a
smarter-than-minimal network a specific track could be allocated for this
traffic.

The specific concern I have with minimal is that there could be surges in
join traffic (from newly activated pledges, some of which could be
malicious).  That minimal might react by allocating new cells for the extra
traffic, and this might be a bad thing.

I can't say that I know what the right behaviour is.  Clearly the network
should not be allocating cells that it needs for more important things,
and I think that 6p can do deny things appropriately.  But the intermediate
nodes might not recognize the traffic as join traffic, and might allocate
anyway.
Is there a way we can mark join traffic so that this doesn't happen?
Either explicitely (DSCP perhaps?), or implicitely (this cell is join traffic).

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Mon, 6 Feb 2017 09:52:08 +0100

Hi Michael,

when you say minimal, do you refer to the minimal configuration or the
minimal security?

I understand it in the following way.

1) a mesh network is formed and all nodes that already joined the network
run minimal + 6P + some SF (e.g SF0). This guarantees that any node already
joined can relay traffic.  Nodes react allocating more cells if they detect
and increment of cell usage.
2) a joining node learns the minimal schedule from the EB and then starts
the joining process through that minimal slot. Until it has not been
allocated the security keys it cannot start 6P to allocate more cells.
3) Your point is that a malicious node can start to do join requests and
cause 6P to allocate more cells in the schedule in the intermediate nodes
in the network, introducing churn. Is this your concern?

Could't we protect this from the JP?
X

2017-02-03 17:52 GMT+01:00 Michael Richardson <[email-masked]>:

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

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain