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

Brian E Carpenter <> Fri, 07 February 2020 03:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 336E712011D for <>; Thu, 6 Feb 2020 19:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MO4NaApstHyh for <>; Thu, 6 Feb 2020 19:42:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 488D812001B for <>; Thu, 6 Feb 2020 19:42:18 -0800 (PST)
Received: by with SMTP id dw13so335570pjb.4 for <>; Thu, 06 Feb 2020 19:42:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aNc5xZ4IwkE0IH9FckyUvAQ88e7s/Nirmda8QE0xrkU=; b=c8EWojBs5lWBIQIZIK6fC7995Ent0pK5V0XclWeNkBFxsgB5tPYCn1Evathwo9hrAH QJppiZnrOXcRa3fuYdilH07p7cTV9ScLgNitrZjJ/6wlVAr7BxpBlyv6lr3vaSLw99WT fSy53TDszcPjs/lzM50TMloNxMwLkAKTuHOIE4zSCVu83sLCxPhgo1p/pku4dwYDp0uP 8Oc4+4YBiTtyA2HKbq+z6JpVTi3A1/NAx6XDkbn0m3pO1IP0TCunagq09SRnJ/P91Exa 9+/JhVZdjVgJpRn2HWTY/WLkcVKy4RYGeVX59tp88IvjeqpD/t2lzUdHYFTKklBSXpaD tzSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aNc5xZ4IwkE0IH9FckyUvAQ88e7s/Nirmda8QE0xrkU=; b=GScXG+nKsTB6YC5p8dN5EGfLfZ4Ki2qbaqJsYkkFFW7uLsUykyMCB2dSrbYItU6m9L qEd1w7C3PmZcIDhJlLKVRQHldA8g/y7QGd1xSnF959riPWO1LzuATlD+Oxb1j4mh8loG 6SicK8RIMZKORqVUoR085ag1dMF9U96yYBSyrBd7dvvL7hIenbJY29R49Fa8BCeE5eTO 0+R3jKxCWA7lyTghvGgL5ScvEBqv9swQdzPe/12Rt6w5YffXsllk7NxnmKKOPYO2kwvn Bi/hCtLzsfAkteigOHHGR3Bh0aLr6nz0ejbcfVMz4yZazWri6/CGAA33eg2jfCujXIro QeiQ==
X-Gm-Message-State: APjAAAUqr59OGJyv3v4dSmDpcV1eB9bsnL096TRSH1/8OA4le+VI+M6p XkyJRdVjANF4fl+RBAY2SqvbR1ii
X-Google-Smtp-Source: APXvYqxWuUbNcIhpXgaEFX2+Nl+EhLRFkW8SH0fyCcszdDFoTIBbtTsDAOOtIWcLmUDaGaIezwFcpA==
X-Received: by 2002:a17:90a:ac18:: with SMTP id o24mr1414873pjq.33.1581046937431; Thu, 06 Feb 2020 19:42:17 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id b3sm846450pfr.88.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 19:42:16 -0800 (PST)
To: Michael Richardson <>, Toerless Eckert <>
References: <> <23372.1581026131@dooku>
From: Brian E Carpenter <>
Message-ID: <>
Date: Fri, 7 Feb 2020 16:42:13 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <23372.1581026131@dooku>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] Brian/anima: trust notion of ASA communications
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Feb 2020 03:42:20 -0000

Yes, this is certainly a gap, and it's why I put register_asa and register_objective in the API, thinking that when we add some kind of trust/authorize magic dust, this would be created when registering the ASA to (a) run and (b) manage certain GRASP objectives. I feel quite far from having a complete model in my head though. I guess we should start with understanding what threats we are protecting against.

   Brian Carpenter

On 07-Feb-20 10:55, Michael Richardson wrote:
> Toerless Eckert <> 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 <>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-