Jack Visoky <[email protected]> wrote: >> I think so; there are some details of resale that BRSKI would like to >> make out-of-scope for the first document. Some way, we have to deal >> with it, and I would actually like feedback from OPC about the >> parameters of different solutions here.
> So in this case would the MASA need to be OPC specific, that is, use
> OPC Security and OPC methods? Apologies if I'm getting ahead of myself
> on this conversation.
I don't think that the MASA would be OPC specific.
The Registrar would have to speak the OPC security rather than HTTPS on the
plant side. The Registrar would still speak HTTPS to the MASA.
This is what we have done in draft-ietf-anima-constrained-voucher:
it speaks CoAPS (CoAP over DTLS) or OSCORE-EDHOC (CoAP with OSCORE, keyed
by EDHOC) on the plant side, and HTTPS to the Registrar.
There are (at least) two major ways to build a Registrar.
1) a single monolithic application framework, it receives
the voucher-request, and then does a synchronous HTTPS request to the MASA.
(Perhaps doing 100-Continue).
2) The other way is for the pledge-facing part of the Registrar to put it all
into a database, return 202, and wait for another query. Asynchronously some
other part sends requests to the MASA and stores the answers back in the
database. Perhaps the only thing connecting the two parts is some
multi-master database replication...
Case 1 is appropriate up to a certain level of load and complexity.
It's certainly way easier to test!
Case 2 has scaling advantages, some security advantages, and also makes it
way easier to build different plant facing interfaces.
I believe that all implementations are case 1 so far.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
