Mote M has a number of CoAP resources, including temperature and light
sensors
coap://M/S/T and /S/L
as well as 6top resources such as slotframes and cells
/6t/6/sf1 and /6t/4/c12_14 (I don't actually know the format).
I might want to allow anyone (host A) on the internet to access the
temperature, /S/T,
but only a select few to access anything in /6t. Maybe some with READ
(L2 neighbors, B),
maybe only one with DELETE (e.g. the PCE, C).
Today the assumption is that we will have a DTLS session to protect
these resources.
Some problems that I see:
What is the mechanism that the mote uses to differentiate between A, B,
and C?
Let's assume that the hand-off between the DTLS module and the CoAP module
tells CoAP if the packet was properly encrypted (vs. the hand-off from
UDP). My
mote needs some sort of table that binds resources to security
requirements. That
takes care of host A asking for temperature (OK) vs. slotframe info (not
allowed if
not protected with DTLS).
But how does the mote differentiate between a READ and a DELETE from mote B
or C? Both will be encrypting their requests with DTLS. Does the mote
need a
table of hosts, each with a list of resources, each resource with a 4
bit flag of
permissions?
And what about OTF, where we will be sending CoAP packets as MLME IEs
protected
at layer2?
I know that ACE is working on this, and I'm trying to understand the
three competing
solutions and their impact on 6TiSCH. No matter what they do, it won't
completely
solve the OTF/coapIE problem.
Thoughts?
ksjp
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
