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
- [Anima] Defined-Trust Transport for Limited Domai… Brian E Carpenter
- Re: [Anima] Defined-Trust Transport for Limited D… Toerless Eckert