Pascal Thubert (pthubert) <[email protected]> wrote: > For the sake of proposing an item for the next charter, we need to > specify how much we overlap with ANIMA and how we’ll proceed to cover > that overlap.
Agreed, and to pass the IESG, it be clear what the boundary is.
> ANIMA will be the place where the autonomic bootstrap will be defined.
> They will have an eye to try and maintain applicability to IoT but
> that is not a constraint in the charter.
ANIMA has two design teams at present:
http://trac.tools.ietf.org/wg/anima/trac/wiki
Signaling (approved) and Bootstrap (not yet approved).
http://trac.tools.ietf.org/wg/anima/trac/wiki/Bootstrap
There are many interactions between signaling and bootstrap, the details
of which are not yet clear. The bootstrap protocol "messages" needs to be
carried back to the Domain owner via the signaling protocol, and the
signaling protocol needs to be secured... I am not convinced GDNP is the
right signaling protocol, and there are many other existing choices.
I don't think that the ANIMA signaling protocol will be suitable for 6tisch
industrial uses (and may unsuitable for other LLN uses too).
The bootstrap protocol is not identical to what I have proposed here,
but as one is based upon the other, the 10% discrepancy will go away.
What is unknown on the ANIMA side, and it became clear last year during
the 6tisch-security design team, is that while we might think we know
what we want from the protocol, we are not unanimous.
As such, a critical rechartering item is to produce a set of security
(protocol) requirements for 6tisch.
This includes answering questions like:
- how is the ASN securely communicated to:
- prospective joining nodes ("pledges" or "ducklings")
- hung-over nodes (slept too long/clock drift/didn't write it to flash)
- if the PANID used for joining is the same as that for production.
- what 802.15.4(-2015) encryption and authentication modes will be used.
- what kind of join DoS attacks are relevant to defend against
- what "zero-touch" means
Some of this is "we need a solution that does X", and some of this is,
"we plan to use mode X, which imposes a constraint Y"
ps: I don't claim that we don't have answers to the above questions.
I claim that we haven't written it down in a document that the WG
has adopted.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
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
