peter van der Stok <stokc...@xs4all.nl> wrote:
>> 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?
"completely manual" means: attach JTAG to device, write K1 key in.
Or, "burn keys into source code", deploy. If one was using one of the
testbeds, that might be rather easy.
>> 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?
I'm not claiming that the constraints and opportunities that are specific to
6tisch networks are unique to 802.15.4 TSCH in Industrial settings. I'm
rather saying that these are the constraints that allow us to make progress
without unweidly scope creep.
>> 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.
Such networks do not at present, by default, have clueful operators to run
the JRC. If a JRC can be assumed (homenet...), if it can be packaged up to
be trivial, or if an upstream ISP or service provider can provide it, then
progress could be made. That's a lot of IFs however, and it can hide a lot of
ratholes.
>> 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?
Once the network is constructed there are a number of observations.
1) if the network is for control (such lighting), P2PRPL might provide for
completely different paths which are not so contrained.
2) RPL DAO projection could remove traffic away from the root.
3) a data collector (in the P2MP metering scenarios) can also do management
of bandwidth
4) 6tisch includes mechanisms to allocate bandwidth for different
applications via the 6p mechanisms, so bandwidth can be reserved
and latency can be made deterministic.
5) 6tisch envisions (but is not yet chartered) to deal with a PCE,
[such as is used in ISA100, I'm told] that could plan tracks
across the mesh in a centralized way.
The point is that we can't spend very much of the available bandwidth for
join traffic, it would be wasteful and would make the impact of DoS attacks
higher.
>> 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,
I haven't asked for time at ACE about the join process.
I think this is a simple application of OSCOAP to generate a new set of keys.
This is a partly open OSCOAP issue. I'd also like to generate keys for the
CoMI (rekey) interface.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
