Hi Michael,
thanks for this extended explanation. This really helps to understand
the final goals and motivation.
A few questions below to remove my remaining confusion.
Michael Richardson schreef op 2017-03-20 22:57:
Some background:
There are two of them because there is some concern that a full
zero-touch
bootstrap will require too many round trips. In the smallest networks a
completely manual bootstrap is acceptable to some.
I need some more explanation here.
It will help if there are some numbers comparing the two approaches.
And is "completely manual" identical to "one touch"?
Or do you see gradations from completely manual to fully automatic?
In the biggest industrial networks, nothing less than a full asymmetric
key
bootstrap is acceptable. This is often due to human factors as well
well
(installers not trusted with symmetric keys!). In between are some
networks
where managing a large number of (hopefully unique!) symmetric join
keys
that have to be provisioned at the factory is acceptable. This is how
pre-6tisch 802.15.4 networks are being deployed today.
The above applies to 6tisch networks only?
We are doing this work in 6tisch because we can pin down a number of
variables that would otherwise cause significant scope creep:
1) we assume a clueful network operator (or contractor) who can
sanely
operate our Join Registrar/Coordinator [which is in the zero-touch
case,
is a CA].
---> this means our solution does not scale to residential or
small
office situations, and that is acceptable to us.
That is a very large logical step for me; small offices and residential
are small networks in my view.
And small networks do not accept zero touch? Probably, I misunderstand
the reasoning.
4) we use RPL as the routing protocol across a mesh, which forms one
(or
more) tree-like DAGs. Close to the root there are significant
bandwidth
constraints, and the convergence of traffic there can cause
congestion.
If properly provisioned, upper-mesh nodes may not suffer as much
from
energy, it can really hurt nodes further down the tree if they
transmit
packets upwards, only to have them dropped due to congestion, and
then
are forced to carry useless retransmits.
As such, we are looking for solutions that where can coordinate
the
join process centrally, and we can accomodate innovation at the
edges
in the form of DoS defenses.
Coordinate meaning a central control algorithm?
The RPL bandwidth constraints at the root is a general problem. Can this
not be separated out?
REUSE
=====
One of the major goals of the 6tisch-security design team is invent as
little
as possible! In particular, code and libraries that would be present
for
bootstrap and be unused during the application usage are to avoided!
Code
space is precious, but more precious is developers paying attention to
quality of implementation issues in the core.
So we are trying to reuse as much of the ACE "platform" as we can:
I completely approve, this should also apply to other than 6tisch
networks
a) CoAP is the base.
b) CoAP block transfer where we need bigger blocks.
c) rekeying using OSCOAP to access a CoMI defined set of 802.15.4 mgmt
interfaces.
interesting thought; Make re-keying a management issue.
e) we think that our enrollment protocol is ideally suited to
make the introductions between RS<->RO, and C<->RqP that ACE
needs for bootstraping it's trust model.
RS <-> RO and C<->RqP?; what is the mapping to pledge, JA and Registrar?
Looking forward to the presentations,
Peter
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
