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

["Max Pritikin (pritikin)" <[e-mail]>]

> On Dec 7, 2015, at 12:07 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> 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.

Michael, I failed to parse your response. 

Are you agreeing with Toerless’ argument that the new device should be a responder? 

Or, are you arguing that the new device should initiate the bootstrapping; but do so in a way that does not expose it is a new device? 

- max

>>> 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 =-
> 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap