Re: [Anima-bootstrap] BRSKI State Machine

[Michael Richardson <[e-mail]>]

Max Pritikin (pritikin) <[e-mail]> wrote:
    >> In "real life" this would allow some visual feedback at the install
    >> site, so that the engineer knows whether he should wait or can go.
    >> [note: there may be security reasons to NOT give a reason for
    >> rejection, need to think more about this]

    > I think here we need to provide information about what happened. This
    > is why s5.4 exists to have the pledge send telemetry back to the
    > network that attempted bootstrapping.

This is a hard problem I think, ; there is potential for a lot of chaff in
the log if we do it wrong.

    > But note this is from the pledge to the domain. The device is assumed
    > to be headless/zero-touch etc so I wasn’t thinking in terms of sending
    > error messages to it. I’m open to doing so though.

I agree that this is important...

    >> - we need to specify precisely the discovery method, with mDNS field
    >> names, and other details. In my head we're using mDNS here, and I
    >> *think* we agreed on that?

    > yes. with understanding that the proxy to registrar SHOULD be
    > discovered using GRASP for ACP devices.

https://datatracker.ietf.org/doc/draft-richardson-anima-6join-discovery

Posted yesterday, needs work. Needs to be merged into bootstrap document, I think.

    MB> But, we'll need the same method also for the ACP draft: When both
    MB> nodes have a certificate, they need to discover each other as well.
    MB> I've been haggling with Toerless about this :-)   I think we should
    MB> take the mDNS insecure discovery into a separate, new draft.

    > I don’t follow. mDNS simply *is* insecure. This is important since we
    > can’t establish a secure discovery yet.

mDNS is just fine to find *a* proxy for a pledge that doesn't know anything else.
(And couldn't verify the proxy anyway).

I'm still unclear how the GRASP multicast discovery process is going to work
(the details) such that it leads to an IKEv2 connection.  *All* we need to
form the ACP links is a multicast that says, "I speak ACP", and as I
suggested before, this could be an multicast IKEv2 PARENT_I1 as much as
anything else.   Or we use the GRASP discovery multicast port, and the
response is not a TCP connection that says, "I'm here", as much as just an
IKEv2 packet instead.

so I disagree with MB above: it's not the same protocol requirements at all.

    > I think discovery of the proxy must be in this draft. I’m happy to move
    > the proxy’s discovery of the registrar to another draft but I think its
    > ok to recommend GRASP for that connection so I don’t see a problem with
    > that.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-