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

peter van der Stok <stokcons@xs4all.nl> Thu, 16 February 2017 08:49 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB441294A9 for <anima-bootstrap@ietfa.amsl.com>; Thu, 16 Feb 2017 00:49:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjO5dpmfJq3Y for <anima-bootstrap@ietfa.amsl.com>; Thu, 16 Feb 2017 00:49:44 -0800 (PST)
Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A8F3129538 for <anima-bootstrap@ietf.org>; Thu, 16 Feb 2017 00:49:44 -0800 (PST)
Received: from webmail.xs4all.nl ([194.109.20.195]) by smtp-cloud2.xs4all.net with ESMTP id lLpi1u0084CYHle01LpipC; Thu, 16 Feb 2017 09:49:42 +0100
Received: from AMontpellier-654-1-69-96.w90-0.abo.wanadoo.fr ([90.0.44.96]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 16 Feb 2017 09:49:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 16 Feb 2017 09:49:42 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <20582.1487174374@obiwan.sandelman.ca>
References: <20170117171732.GA14606@faui40p.informatik.uni-erlangen.de> <20170117172824.GB14606@faui40p.informatik.uni-erlangen.de> <11820.1486936729@obiwan.sandelman.ca> <8a8567bb1b9993c077d84abf4bfc82f3@xs4all.nl> <18113.1487095987@obiwan.sandelman.ca> <f035b7675e761046b6486db3f54794e8@xs4all.nl> <20582.1487174374@obiwan.sandelman.ca>
Message-ID: <77ef9d9a0fe928ce0d857de188fc991b@xs4all.nl>
X-Sender: stokcons@xs4all.nl
User-Agent: XS4ALL Webmail
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/qcW8AnsLwR5T4qO4zKeb-tZKADc>
Cc: anima-bootstrap@ietf.org, Toerless Eckert <tte@cs.fau.de>, consultancy@vanderstok.org
Subject: Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes)
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2017 08:49:45 -0000

> 
>     > <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);
>       }
> 
This looks like a caricature of the mDNS text regarding the sleep.
I don't think the text is intended for lots of sleepy sensors.
 From an inter-operability point of view it looks OK.  One can argue 
about the load generated on the network.
> ?
> 
>     >> 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?
*I* don't. preferably link-local though.
> 
>     >> 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.
personally I would use CoAP discovery; we talk about CoAP here.
And specify a join-proxy resource-type in the coap registry.
> Don't be shy.
Try to be bold.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-