IETF Logo Mail Archive

Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 12 August 2019 22:25 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C582F120996; Mon, 12 Aug 2019 15:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVaQJBULtyI9; Mon, 12 Aug 2019 15:25:09 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65085120DA5; Mon, 12 Aug 2019 14:29:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CF73B3818D; Mon, 12 Aug 2019 17:28:26 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AEAA69A; Mon, 12 Aug 2019 17:29:11 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "iot-onboarding@ietf.org" <iot-onboarding@ietf.org>, Jack Visoky <jmvisoky@ra.rockwell.com>
cc: "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>, "anima@ietf.org" <anima@ietf.org>
In-Reply-To: <DM5PR2201MB1340ECB3168E4E444DFFB6E199D00@DM5PR2201MB1340.namprd22.prod.outlook.com>
References: <BYAPR08MB4903F02A37ED9AE092A59B8EFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <BYAPR08MB4903129ECDEADF61E681DE0BFAD50@BYAPR08MB4903.namprd08.prod.outlook.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <BYAPR08MB490385B1BED4C665C79B1937FAD70@BYAPR08MB4903.namprd08.prod.outlook.com> <4671.1565279232@localhost> <BYAPR08MB49034F3B36F6979D59561FC3FAD70@BYAPR08MB4903.namprd08.prod.outlook.com> <DM5PR2201MB1340BD83D6CF3F95E82518C299D60@DM5PR2201MB1340.namprd22.prod.outlook.com> <19592.1565471757@localhost> <BYAPR08MB49035E6C8A4C9CD1A596B7F2FAD10@BYAPR08MB4903.namprd08.prod.outlook.com> <15583.1565485709@localhost> <DM5PR2201MB1340ECB3168E4E444DFFB6E199D00@DM5PR2201MB1340.namprd22.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 12 Aug 2019 17:29:11 -0400
Message-ID: <17156.1565645351@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/yp1dNZMNnDz5k8unGlrKuKIxXqI>
Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Aug 2019 22:25:13 -0000

Jack Visoky <jmvisoky@ra.rockwell.com> 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   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

v2.23.0 | Report a Bug | By Email