Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes)

On 16/02/2017 04:59, Michael Richardson wrote:
> 
> peter van der Stok <stokcons@xs4all.nl> wrote:
>     > discovery functions may be used.  I like to point out mDNS due to its
>     > long-standing existence.
> 
> okay.  I also prefer not to re-invent everything.

To repeat myself: we have always expected that non-autonomic pledges
would *not* use GRASP to discover their join assistant. A join assistant
would support multiple discovery methods if necessary.

Nothing prevents a tiny subset of GRASP running in a non-autonomic
pledge, just for the purpose of receiving M_FLOODs. But we have no
particular reason to push for that.

    Brian

> 
>     > <pvds> The beginning of section 8 says: " Whenever a Multicast DNS
>     > responder starts up, wakes up from sleep, receives an indication of a
>     > network interface "Link Change" event, or has any other reason to
>     > believe that its network connectivity may have changed in some
>     > relevant way, it MUST perform the two startup steps below: Probing
>     > (Section 8.1) and Announcing (Section 8.3).  " Much of the text of
> 
> Yes, that's the case on the first interval.  Once it's none that, it's not
> supposed to be proactively announce itself again, from what I understand.
> It's a service, so it doesn't to defend it's name.
> 
>     > rfc6762 is about suppressing superfluous traffic.  The method relies
>     > on repetitive querying and reactive responding, with a response at
>     > responder re-activation (see above).  There is a lot of operational
>     > experience here, and deserves attention.  </pvds>
> 
> Okay, but would this be a valid implementation:
>       unsigned char stuff[]={ 0x01,0x02, /* encoded DNS-SD reply */
>       while(true) {
>                   sleep(60);
>                   sendmsg(stuff, multicast-address, port-5353);
>       }
> 
> ?
> 
>     >> It might be that in the end we don't care about the anonimity of the
>     >> pledge.
> 
>     > <pvds> Did we? IMO, almost impossible in an unsecured bootstrapping
>     > network.  Once keys are distributed, pledge looses it identity and
>     > starts afresh (I reckoned) </pvds>
> 
> Okay, *DO YOU* care about anonimity of the pledge?
> Do *YOU* care if the pledge must solicit a Join Proxy by multicasting a query?
> 
>     >> If the pledge can ask the network about Join Proxy, then there is
>     >> nothing to stop us from using mDNS here.
> 
>     > <pvds> Or anything else dependent on the operational environment of
>     > the SDO using the bootstrapping protocol.  </pvds>
> 
> Agreed.
> What would you like to chose here?  Tell us your opinion.
> Don't be shy.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> Anima-bootstrap@ietf.org
> https://www.ietf.org/mailman/listinfo/anima-bootstrap
> 