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
>
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
