Re: [Anima] Brian/anima: trust notion of ASA communications

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 06 February 2020 21:55 UTC

Return-Path: <mcr@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 07E1512011B for <anima@ietfa.amsl.com>; Thu, 6 Feb 2020 13:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4xQkma4LjpJT for <anima@ietfa.amsl.com>; Thu, 6 Feb 2020 13:55:34 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966481200B3 for <anima@ietf.org>; Thu, 6 Feb 2020 13:55:34 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [IPv6:2a02:8109:b6c0:52b8:1993:81d7:2ab0:b9b6]) by relay.sandelman.ca (Postfix) with ESMTPS id 73B961F45A; Thu, 6 Feb 2020 21:55:32 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id F01C41A096A; Thu, 6 Feb 2020 22:55:31 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Toerless Eckert <tte@cs.fau.de>
cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, anima@ietf.org
In-reply-to: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de>
References: <20200206205949.GD14549@faui48f.informatik.uni-erlangen.de>
Comments: In-reply-to Toerless Eckert <tte@cs.fau.de> message dated "Thu, 06 Feb 2020 21:59:49 +0100."
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 06 Feb 2020 22:55:31 +0100
Message-ID: <23372.1581026131@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/uHtYk1Ha-kBFDf3CGhqOAIxRJdA>
Subject: Re: [Anima] Brian/anima: trust notion of ASA communications
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: Thu, 06 Feb 2020 21:55:37 -0000

Toerless Eckert <tte@cs.fau.de> wrote:
    > I just got reminded through ongoing ACP spec review about something that
    > would be good to write into the appropriate ASA spec, but not sure which
    > one:

    > One of the fundamental problems we have to solve longer term is how we
    > can establish better than "Any ANI peer is equally trusted" notion.

I agree.
But, at this point, all the ANI peers are equal.

None do anything special yet... Once we have protocol(s) that can do
something different, then we need to figure out what the requirements for
that protocol.

Putting the trusted-to-do-foo bit into the certificate is probably unwise.

It seems that in an autonomic network that there ought to be a service that
can be used to ask, "should I trust node FOO to do X?".
That could be the (cmc)RA or another node so designated.
It seems that GRASP can pretty much do all of this.

COSE can be used to sign answers.
That is probably a thing we need to add.

    > I think DINRG is working in this direction, but have failed to track.
    > Maybe there is a way to collaborate on this, aka: see if/when they might
    > have output we could think to adopt/leverae.

I don't know what they are doing either.

    > Right now we expect objective announcements from any node to be equally
    > trustworthy and decide on selecting one only on announced parameters
    > (also subject to equal trust) and network parameter comparison.
    > And of course, this goes beyond trust into performance vetting by
    > others and so on.

At some level, if you are looking for resource X, and some node can provide
X, and it works and does what you need... then maybe it is reasonable to
trust it.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-