Re: [Anima] Defined-Trust Transport for Limited Domains (draft-nichols-tsv-defined-trust-transport)

Toerless Eckert <tte@cs.fau.de> Wed, 03 August 2022 19:26 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 D7182C14F748 for <anima@ietfa.amsl.com>; Wed, 3 Aug 2022 12:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level:
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VV42Qvw1rlb for <anima@ietfa.amsl.com>; Wed, 3 Aug 2022 12:26:10 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C8AC14F6EC for <anima@ietf.org>; Wed, 3 Aug 2022 12:26:09 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id BC253549C4E; Wed, 3 Aug 2022 21:26:02 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id A26144EB652; Wed, 3 Aug 2022 21:26:02 +0200 (CEST)
Date: Wed, 03 Aug 2022 21:26:02 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Anima WG <anima@ietf.org>
Message-ID: <YurLyg93WU27YrRF@faui48e.informatik.uni-erlangen.de>
References: <69016614-d499-d765-785d-974ce04e89fe@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <69016614-d499-d765-785d-974ce04e89fe@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/fADSGJYFwhdS8fla3MYhYeAVNzM>
Subject: Re: [Anima] Defined-Trust Transport for Limited Domains (draft-nichols-tsv-defined-trust-transport)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 03 Aug 2022 19:26:12 -0000

Thanks for the pointer. Interesting, but frustrating read explain as much of
the important solution details as ACP drafts did when they where only 30 pages long ;-)).

I am professionally pessimistic about the performance characteristics of distributed set
reconcilliation via Invertible Bloom Lookup, especially given how industrial control
is a lot more stream based than a (limited size) distributed set of state in e.g.:
databases, which i think this solution was originally designed for. So i inquired
with the authors about that aspect. And professionally pessimistic means either i am right
or i can be shown that the stuff will really scale to OT and then i'd be extremely happy
to be wrong.

Having a pub/sub concept with explicit membership is IMHO definitely necessary for
any distributed system. Such as our AF/ASA. As long as we do magic handwaving like the
DeftT draft as to who establishes these memberships, it is really not that hard to build.
I guess we haven't gone down there, because we would maybe like a little bit better
sollution than:

  "instead of having a big heap of router config, ANIMA (or DefTT) lets the operator
  now focus on configuring a big heap of security". Which is a bit nastily how i would
  describe all those security solutions. Including MUD (which pretty much is the same
  as DeftT expect for relying on ACL instead of crypto our BRSKI of course (where BRSKI is
  most lightweight because it "only" hands out certs and TA, but as soon as the backend
  would have to add cert specific attributes like group membreship, its the same play". 

If we ignore this fundamental operational problem, i would certainly love to see a layer on GRASP
that would allow to specify permitted sender (pub) and receiver (sub) of objectives (maybe
objective-groups). Would be nice if there where protocol pieces for this that
we could steal from some other place in the IETF. 

Doesn't seem like a lot of work:
- Sign GRASP message with your ANI cert (we need a signature field)
- Have the same additional layer of who can send/receive to which group
- enforce that layer on sender, GRASP forwarders (for floods) and receivers

The main issue is that researchers only play the "my universe" game, like subject
draft, as opposed to looking for such incremental solutions that add those important
elements to existing industry solutions. Then again, our ANIMA solution obviously has
not enough industry acceptance to be something for researchers to flock to (except for BRSKI).

Cheers
    Toerless

you can start reworking all 
On Thu, Jul 21, 2022 at 05:28:45PM +1200, Brian E Carpenter wrote:
> Hi,
> 
> I think this draft by Kathie Nichols, Van Jacobson and Randy King might be of some interest to ANIMA. That may not be obvious at first sight, but it's about a network domain with well defined and secure membership, and is heavily based on IPv6 link-local multicast.
> 
> It has one significant difference from BRSKI + ACP: a per-node trust model instead of a "we trust every node in the domain equally" as in the ACP (and GRASP). It also has some pub/sub ability, which is another property intrinsically lacking in ANIMA (but proposed by draft-ietf-anima-grasp-distribution).
> 
> https://www.ietf.org/archive/id/draft-nichols-tsv-defined-trust-transport-00.html
> 
> I'm not saying we should adopt this technology, but it does answer some of the questions that ANIMA hasn't even asked yet.
> 
> (With my GRASP hat on, I note that GRASP's security requirement is only for a secure transport substrate with link-local multicast ability. If DeftT supplies that, GRASP could use it.)
> 
> Regards
>    Brian Carpenter
> 

-- 
---
tte@cs.fau.de