Re: [Anima-bootstrap] anima-bootstrap: Bootstrap proxy discovery options

[Michael Richardson <[e-mail]>]

Max Pritikin (pritikin) <[e-mail]> wrote:
    >> For non-challenged (IoT) devices on non-challenged networks, the new device should
    >> initiate and drive the bootstrapping.
    >>
    >> It would be best if this communication was indistinguishable from other ACP
    >> communication to an outsider.

    > This can only occur if bootstrapping is over a “provisional” ACP. I’m
    > uncomfortable with having GRASP and ACP include special cases for
    > bootstrapping. My gut feel is that the simplicity of a specific
    > bootstrapping sequence — even if identifiable — is preferable.

If we believe that a device could belong to multiple ACPs (see my other
post in reply to Brian for some reasons for an intra-ISP ACPs), then having
an extra tunnel up, on a "disconnected" VRF, for a joining device is not a
big deal, I think.

    > A *non-privacy* preserving bootstrapping is preferable from a certain
    > point of view. I want my autonomic network to track and identify any
    > overlapping autonomic bootstrapping to domains I don’t recognize.

Assuming that we use some non-private way to discover the enrollment proxy,
and we use (D)TLS 1.3, then observers would only see that there was a
bootstrap occuring.  They would observe the address of the enrollment, which
they might realize was not their own.

A multicasted IKE_INIT plus ACP would result in a tunnel with a device which
is not a recognized device, so would reveal the same amount of information to
an IDS.

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