IMHO, gear replacement after large outages is quite relevant:
I have seen equipment become unusable after bad
power situations (spike, brownout, electrical storms,..) because of
el-cheapo power supply/circuitry as well as wired interface
circuitry/protection. Certifications in Telco/IoT make that type of gear
often better, but those certifcations are a zoo.
- Large organizations will have spares. With ANIMA, those spares should
be stored pre-enrolled to avoid MASA/registrar dependency during
recovery/replacements: Receive gear on any site (no central provisioning
site needed), but unpack, plug in for short period, then stash away.
This is imo an easy requirement also useful without desaster requirements
- aka: enrolled spares would likely also have better theft/abuse protection
than non-enrolled. And yes, you will have to power up these spares
once a year. Which IMHO is ok. And of course certs should therefore
be somewhat longer than 1 year).
- If sparing would be cross-locations (eg: spares sent from some site to
other sites during recovery), then its important that the ANIMA certs do
not include any location specific attributes that would prohibit thart
movement. So far BRSKY does not include any such attributes, but in
discussions, three has been interest to lock into the cert some device
role specific attributes, and for a spare piecce of equipment, those
attributes may not be predetermined.
Aka: Desaster sparing means domain certs need to be simple, devices
reuseable across domain.
- If spares are done by a shared facility: vendor, FEMO (for fed networks)
or the like, one could think of that entity offering (emergency)
enrolment service.
Such an entity would have desaster proof MASA connectivity on site,
and the customers would provide it with (emergency) registrar certs.
(emergency) meaning that the entity is only permitted to enrol during
emergencies, and the customer could be able to verify the emergency
entities behavior by pulling from the MASA an audit log.
If the customer would give the emergeny registrar credentials
cert/private/public-key to the emergeny entities, then the customer
itself also has the cert/private-key and could ask the MASA.
This option would work with current BRSKY text. I am just not sure
about security BCP (having two copies of a public key pair...).
- If the shared spare storage facility is Best Buy, and the Jones
family wants to replace some electric storm victims @home while
their ISP takes its days (my ISP C*...*T took almost 48 hours in one case),
then the gear should probably come with a nonceless voucher
printed on on a scratcher piece of paper inside the box.
Beyond these BRSKY considerations, the next cool ANIMA piece to consider
for these use-cases is of course the ASA driven "re-configuration" of the
spare device, aka: In larger outages, you should not except the whole
network provisioning backend to be up and running. And its IMHO
illusionary to expect devices to ONLY be driven from intent for many
years (in complex networks... in a clean homenet they are driven by
intent today..).
Aka: for pre-intent-only desaster proof networks, we'd need:
- ASA to cache neighbors configs.
- reapply neighbor stored config when replacement gear is inserted.
- IMHO: An anima definition for a "device-role-id" which is not
the ACP IPv6 address (which will change upon gear replacement
without enrolment support).
Cheers
toerless
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
