Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
>> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
>> > I *really* don't understand this stuff, but how long could the rollover
>> > take, for a reasonably large IoT network (presumably thousands of
>> > devices)? Are we talking about a few seconds when no new sessions could
>> > start, or what?
>>
>> For sleepy IoT devices that wake up once a day, and run on a slow
network?
>> Could be a few weeks, easily.
>>
>> But, on such networks, the devices mostly don't talk to each other at
all.
> What, no networks of cooperating sensors ("I've detected smoke, did you
> detect smoke too?")
yeah, but since both sensors are sleeping, the coordination would be in the
central point.
>> Industrial situations like factories aren't doing a lot of device2device
>> communication (i.e. without involving the control system), but if they
did,
>> then they'd want to schedule the certificate renewal/rollover at a
specific time.
> Agreed, that would be normal procedure in control systems of all kinds.
> It's less clear in what are euphemistically called tactical networks; a
> certificate rollover on a battlefield could be a big deal.
the scene is the back of a truck (or sparse fuselage: think Edge of
Tomorrow), with 10 soldiers on each side: "Marines! Drop in five. Synchronize
your trust anchors!"
>> I think that we could do this by issuing new certificates with a
notBefore
>> date in the future, but to date, I don't think we have a clear
specification
>> that says this.
> Ack.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
