Thanks Brian, as always, great recommendation.
It would be great if followup work in ANIMA would tackle the
problem of role management. In the case of this drafts
simple view at the world its a simple master/slave role
assignment: You have few master nodes such as those in the NOC
and registrars that are still "manually" configured, and a
much larger number of "zero-touch" slave nodes (all the other nodes)
that are controlled by the masters via a combination of
ANIMA/ANI and SDN. And we could easily add this model
via simple binary distinctions in the Domain Certificates.
And appropriate signing element in GRASP messages.
I just wonder if its worth tackling this role management
problem if we only have an idea how to solve this simple
"SDN"'ish case. Would be a lot more useful if we had a more
generalized solution that would also work in more
autonomic networks with a lot more ASA - aka: how do
we manage the privileges/roles of ASAs... ? The classic
solution is probably role/privilege assignment from those
NOC-master nodes. And if such schemes can distribute
appropriate credentials (role certificates), we can easily add
this too.
Then again, i think more fully distributed, autonomic
networks might want to have a more innovative solution approach
to roles. There is for example the proposal direction
we wanted to present in DINRG to use blockchain/distributed
ledger technologies. Or in other words: An ASA could
ultimately raise to a particular role by collecting credit
in the blockchain through "proof of doing a good job and
being trustworthy".
This would be cool stuff to get into ANIMA, but of course, i
at this point in time i am no sure how far away this type
of technology is from being applicable to IETF (as opposed
to being refined in IRTF).
Cheers
Toerless
On Mon, Jul 09, 2018 at 03:57:38PM +1200, Brian E Carpenter wrote:
> Hi,
>
> I've had a very quick look at this draft, and it didn't ring any alarms.
> Just one small comment on the Security Considerations, which starts:
>
> > There is no protection against "unauthorized" ACP nodes to generate
> > service announcements, because there is no authorization scheme in
> > GRASP.
>
> That sounds a bit brutal. I suggest replacing the sentence:
>
> All ACP nodes are at the same level of trust, as a result of
> successfully enrolling and joining the ACP. However, there is
> currently no mechanism in GRASP for indicating and authorizing
> the role of a node. Therefore there is no protection against ACP
> nodes generating inappropriate service announcments.
>
> Regards
> Brian
>
> _______________________________________________
> 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
