Warren Kumari <[email protected]> wrote: > Here is a link to the slidedeck from IETF104 to refresh your memory - > https://datatracker.ietf.org/meeting/104/materials/slides-104-opsawg-draft-wkumari-opsawg-sdi-01.pdf > -- basically the entire document is summarized in 2 slides (slide 9, > 10). If you'd prefer video -- https://youtu.be/a479Zohc5yg?t=1266
> The main design criteria for this was to be as simple as possible, to
> make it trivial to implement and use. This is specifically designed to
> just augment existing auto-install functionality; there are much more
> ambitious and fully featured solutions (such as ANIMA and RFC 8572)
> available for those who can / want to use them.
Your claim that BRSKI is too complex is interesting, and I'd like to discuss
this with you over beer. But, I appreciate you trying to do this.
Saving CO2 expended by silly airplane flights is appreciated.
We did consider a protocol such as you describe.
The limitation is that it does not necessarily enroll the new device into the
ISP's security domain, and we really wanted that.
The Config file provided could do that, and as you say, some staging
mechanism could also use ssh to do that as well. But, that wouldn't really
be a standard, and we needed something more specific.
I think you need a bit more text to explain why the device should trust the
DHCP server; and also how the owner convinces the manufacturer to turn over
this key. As written, it looks like if I get a good look at the label of a
BFR I have a good chance of getting the key, and I'm sure you intend
something more involved.
It's unclear to me if this key should be retained in the factory reset
situation or not; I think you offer both possibilities, but each version has
some security gotchas, and I think it needs to be explained.
I would like you to consider specifying a standard format for the encrypted
configuration. CMS, PGP, JOSE, COSE... pick one or more. That way, we can
have tools that can support a multiple of vendors equipment.
Failing such a choice, I don't see anything in this description which a
manufacturer can't unilaterally do today. So maybe it's a BCP, and and it
can go into an RFP. I don't think it's Informational: BCP or STD.
> I'd really appreciate your review and comment; it's short (if you
> ignore the ASCII art diagrams and example appendix and similar it is 7
> or 8 pages, and much of that is background). W
Adopt it.
ps: it would be nice if the initial DHCP request included a MUD URL, so that
the infrastructure can know what the device is expected to do,
particularly if that might involve calling home to get the latest
firmware before operating.
Should the device get any kind of Internet access from the DHCP server?
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
