On Thu, Feb 06, 2020 at 10:55:31PM +0100, Michael Richardson wrote:
> I agree.
> But, at this point, all the ANI peers are equal.
Except for cmc(RA).
> 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.
Or rather service. yes. Thats what i am asking for.
> Putting the trusted-to-do-foo bit into the certificate is probably unwise.
Well...
a) see above (registrar)
b) I think its wise, but i do understand how the crypto folks don't lke it
and every time you ask crypto folks think outside the box it takes
eternities. Aka: to me its not different from the implied trust
expressed by a weeb certificate through the name. If i have cert bits
indicating more generic "roles" thats IMHO quite similar.
c) But the main ask here was to see if there is some actionable output
of research that moves us beyond this model.
> 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?".
Sure, and i am going to run a hacked ACP node thats announcing in GRASP
to be the "best-ever" node to provide that service ;-) How to you
prohibit me to happen ? -> Anser: i dont have a fitting certificate, or
there is some ACP crowd intelligence that says i am untrustworthy.
> That could be the (cmc)RA or another node so designated.
Right. Thats the "role" indications in certificate approach. And of
course we want to limit that to really "lifetime role assignments"
(lifetime larger than cert lifetime..).
> 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.
Right.
> > 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.
Yes, discovering violation of trust is the biggest issue for crowd intelligence.
The easier starting point case would be crowd intelligence based on
client measured service performance experience. Think DNS proxies on
each edge-router circling around the set of DNS services announced, DNS
proxies measure RTT and failure rate, exchange amongst themselves those
parameters and adjust their use of these servers accordingly. Easy to
see how this might easily wipe out unreliable servers. Much more difficult
to do the solution to optimize overall load when the best server becomes
overloaded because everybody wants to start using it.
Cheers
Toerless
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
