Subject: Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-04.txt

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Nov 2016 11:54:20 +0900

Brian E Carpenter <[email-masked]> wrote:
    > registrars. In this case it will be possible for autonomic nodes that
    > wish to join the AN to use GRASP with no need for mDNS. If we don't do

Please be clear: are these enrolled nodes, or new pledges?

    > this, the Anima solution will not be complete in itself. Especially
    > during the early formation of an AN after a cold start, this is a
    > problem.

Please define "cold start", here.

    > So specifically I want bootstrapping-keyinfra to specify that -
    > registrars and proxies MUST be disoverable by both mDNS/DNS-SD and
    > GRASP.  - pledges MUST use one of these two mechanisms

Sure, but as a pledge, I don't want to announce a TCP socket that is open for
attack.  This is the part that I'm concerned about.  The mDNS announcements
From the JA can be multicast, and therefore can be observed without announcing
oneself...

    > Unfortunately I will not be in Seoul to argue this point, so it would
    > be nice to settle it by email.

okay.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Nov 2016 16:27:11 +1300

> Please be clear: are these enrolled nodes, or new pledges?

Pledges.

> Please define "cold start", here.

Power off on all racks; humans pressing factory reset buttons. Systems coming
back in random order. All dependencies broken.

> From the JA can be multicast, and therefore can be observed without announcing

Yes, and that's why I thought that in Berlin we'd agreed on a Flood based
model (where the proxy floods out its info and any pledge can listen).
That's what's coded in demo form as Reggie.py, Procksy.py and Pledji.py at
https://www.cs.auckland.ac.nz/~brian/graspy/brski/ . I also coded the
discovery approach but it's more complex as well as more vulnerable.

  Brian

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Nov 2016 20:34:12 +0900

Brian E Carpenter <[email-masked]> wrote:
    >> > during the early formation of an AN after a cold start, this is a >
    >> problem.
    >> 

    > Power off on all racks; humans pressing factory reset buttons. Systems
    > coming back in random order. All dependencies broken.

I think that we need to define "factory reset" in a document somewhere!

Thanks to ANIMA and LDevID certificates, I think that there are two kinds of
reset, but I'd like the WG to come to consensus.

There is "reset to factory defaults", which I would take to make to erase
all configuration files and all administrative credentials, and might even
mean to boot a specific OS image.  But, it wouldn't mean to remove the LDevID.
An operator would do this when redeploying the equipment from one purpose to
another.

The second kind of "factor reset", would mean to delete the LDevID.
Still, I'm skeptical that we'd ever want to do that; it might mean to boot
using the IDevID.  It might really mean, specifically, to run bootstrap again
without doing anything else.  This is what a machine might do if it's LDevID
certificate is expired.

So, Max, Toerless, MichaelB, what are your thoughts here?

And I agree with Brian that we need a pure ANIMA solution when we cold start
a rack of equipment.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-