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

[Michael Richardson <[e-mail]>]

Max Pritikin (pritikin) <[e-mail]> wrote:
    >> IMHO, i would let the proxy periodically (30 secs)

    > Is it acceptable that a new device sits for 30s before joining? Should
    > this be shorter? Longer? What criteria do we use to choose (see below
    > before answering).

    >> I don't want the enrolling device to be more attackable than
    >> necessarily.  Arguably such a greenfield device may be more attackable
    >> than a configured device. An unconfigured device that periodically
    >> broadcasts "hey, i am unconfigured and look for a proxy server"
    >> (especially when powered on in a non-AN enviroment) is the best victim
    >> ever to do a port-scan etc. pp.  on (or just find the console
    >> interface). And just because a vendor has added autonomic networking
    >> doesn't mean he has now also fixed all security for all OS services
    >> many of which may not even be off by default but would likely be
    >> configured off by security sensitive operators.

This is one reason I'd like the new device to do things that configured
devices do regularly.
So sending out a multicast IKEv2 INIT might really make sense here.
Every device should do it every 5 to 15 minutes.

A new device will either send them, or receive them.  Either way, it can
respond and within the privacy of IKEv2, can do something.
That doesn't you can't use a proxy to get things through: the resulting
one-hop-ACP won't be part of the production ACP.

    >> So, i think we can use GARP DISCOVER for this periodic multicast,

    > Multicast DNS supports multicast “unsolicited” responses and also
    > specifically states that peers cache these. So the basic behavior you
    > are requesting is fundamentally available from mDNS as well. This is a
    > design choice for Anima but I doesn’t seem to dramatically impact our
    > choice of discovery protocols.

mDNS is another good mechanism to use --- and it doesn't scream out, "newbie"
either.

    >> Also comparison with mDNS as we discussed it: - code size: We need
    >> GRASP for more functions in AN beside discovery, we do not need mDNS
    >> for anything in AN, so on IoT devices we would save code size. TBD:
    >> Size of an mDNS stack (note: We MAY want "normal" DNS, so the code
    >> size for mDNS may not be that large as a delta on top of "normal"
    >> DNS).

    > This is where the real value/difference discussion comes in. I guess we
    > could build an avahi library and see how much the entire thing takes or
    > how big pieces of it are.

I claim that much of what we are doing with the ACP and GRASP is outside the
code space limit for a constrained IoT device, so I don't buy this argument.

1) mDNS *IS* useful in IoT space, so the code isn't wasted.
2) GRASP is *not* useful in constrained IoT space.

    >> And i guess one could define a TXT RR with the signed timestamp. Aka:
    >> I could probably do the same thing i was describing above also with
    >> mDNS. Not sure if mDNS people would like that…

    > For a DNS based solution I guess DNSsec integration would be
    > logical. I’m not sure I like any approach where we try to cram security
    > into the discovery protocol — the truth is that we don’t have
    > sufficient information to trust crypto methods in the
    > response/broadcast information until after we complete bootstrapping at
    > which point its relatively moot. Instead we can cut to the heart of
    > your security value by tracking "locator-option” information seen and
    > freaking out if an unexpected one was seen (assuming GRASP).

Exactly: You can't easily do DNSSEC easily here: no trust anchors available for
         joining device.  DNSSEC can give you an alternative to 802.1AR
         certificates though, but it replaces that part.

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