Mališa Vučinić <[email protected]> wrote: mcr> A power and compute-saving thing for the JCE to do would be to mcr> have the mcr> JN provide the JCE with a session-resumption ticket... and for the mcr> JCE mcr> to pass that onto the PCE.
> This seems like a great idea for nodes that may often loose
> connectivity and would need to re-run the join process. For instance,
> we work with energy-harvesting nodes with very small batteries (20
> mAh) and repeating the whole thing once some energy becomes available
> is simply out of the question.
I think that you mis-understand the purpose of the join process.
It's not about joining the DODAG or the network, it's about joining the
local security domain. The energy harvesting node would run the join
process once, and would then get provisioned with a number of things.
Specifically:
1) a locally relevant certificate and/or MSK (from the JCE)
2) a set of paths and timeslots (from the PCE)
3) some application specific set of things (e.g. a light switch
is told which light bulbs to control, or perhaps which multicast
groups to use to announce the switch changes if bulbs listen to
switches ...)
Certainly, if you need security for 3, one could use a a TLS
session-resumption ticket for that state.
But, there is no reason for this node to rerun the join process.
As Tero has pointed out, the node might need to stay awake long enough to
hear the ASN from the EB if it hasn't got a good clock.
I wonder how we can make this seperation of responsibility clearer.
If you understand what I'm saying, perhaps you can tell me how to avoid
this misunderstanding in the future?
> Since the format of a stateless session ticket from RFC 5077 does not
> affect interoperability, in the context of 6TiSCH we would need to
> mandate the session resumption support on the JCE side. However, could
> it be possible to use a 6TiSCH-specific format of this ticket for the
> initial join as well, where the session state would be encrypted with
> a PSK shared between JN and JCE? Obviously, in this case JCE would
> need to generate the session resumption state before a session has
> been even established but I believe this would greatly speed up the
> join process.
So, here, I think you are imagining using some kind of pre-provisioned
session-resumption ticket to replace the initial TLS handshake.
I think that this is something that one could imagine: the initial TLS
handshake is done at the factory, and then, based upon a bearer token,
the factories' MASAS (see draft-pritikin-anima-bootstrapping-keyinfra-01)
might return that.
Is this what you are thinking about?
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
