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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 15 February 2017 16:04 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 0E9BD126579 for <anima-bootstrap@ietfa.amsl.com>; Wed, 15 Feb 2017 08:04:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 T9flireS_OZd for <anima-bootstrap@ietfa.amsl.com>; Wed, 15 Feb 2017 08:04:41 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59F61294B9 for <anima-bootstrap@ietf.org>; Wed, 15 Feb 2017 07:59:35 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 46F46E1D4; Wed, 15 Feb 2017 11:21:04 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 964506381A; Wed, 15 Feb 2017 10:59:34 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: consultancy@vanderstok.org
In-Reply-To: <f035b7675e761046b6486db3f54794e8@xs4all.nl>
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>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Wed, 15 Feb 2017 10:59:34 -0500
Message-ID: <20582.1487174374@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/FyK0WeA_8aafPxbqQoxnvaxVPf8>
Cc: anima-bootstrap@ietf.org, Toerless Eckert <tte@cs.fau.de>
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
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: Wed, 15 Feb 2017 16:04:42 -0000

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.

    > <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>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-