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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 16 February 2017 00:57 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 6FF39129C22 for <anima-bootstrap@ietfa.amsl.com>; Wed, 15 Feb 2017 16:57:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 oPWVkxw42ps1 for <anima-bootstrap@ietfa.amsl.com>; Wed, 15 Feb 2017 16:57:01 -0800 (PST)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6ABF129C1E for <anima-bootstrap@ietf.org>; Wed, 15 Feb 2017 16:57:00 -0800 (PST)
Received: by mail-pg0-x235.google.com with SMTP id t188so1012629pgt.2 for <anima-bootstrap@ietf.org>; Wed, 15 Feb 2017 16:57:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DzniEHXywrLa7iBmdijy7n45O3XjwMZJihbm396n5mQ=; b=Z7oTwwTptJeW7nt+4lvcCpax/yfe8C6ZjP29L0/NDVx8YKEUofHGefYa+dWGj9ohOL Qrt/b8xVV1/jWWZKadIhS3Gj0tvw3NBxf1ChkTZNp4c99GLwnw68rhzIcxhqUyOdqTD9 RiRYQKE4w0AJL/Oqs9M9+HKfUMA9oaWziHg6ATsePytzN6Kdt3Oj6xzQULhj5jAu8ocY pylB3uIbJ7RA8e7ACR7IcN8X+dWo5tI4jvAxyY9zVHBA0WsruNELVnHWdftdpVLSWuM3 9LYPYIySkjfOlp/2pOKqT9Rc3F+BzgNDsfscarEaEsm06Cnyj0YkYdo1KAUKM8U9xXek J8Dw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=DzniEHXywrLa7iBmdijy7n45O3XjwMZJihbm396n5mQ=; b=aWsz8gift9KPCkfduiVZ3a1N5H1pdgTrTnJLkZKLvSz6Yjp6dIa3xj1rtEd8XyFVrU G0P77FrIO9f37SEai6JkYhHcp1XGQnbOpfBe8AJ56EnWTXNcLHcavzdkQ8P1QqJbIzAf K/5fBQY2WIWKUmW5SNf2oFTz9FQTQmFCYCs23PGwM/bw0FyuoLgj6LRdOoIXqZ9bfPDI OESc7anLZnLJ8Trs8/rXuM8RH+yAld3A3o96VxOPgxn8G0dooYak40B1InIU4fchM/1c ZJfkX0kgt7iemmyQW5cqAhVWQILYOFF9J7CouDjdjcTT72oVwa0J0K/4MaiaFuWGICRi wNEQ==
X-Gm-Message-State: AMke39lEzegd6VGdTtX84EcDNtijDdWFgRoMiP7CwI+jCaaXTwbFL2+T1WLJGL8v2p5prg==
X-Received: by 10.84.195.164 with SMTP id j33mr47524330pld.171.1487206620503; Wed, 15 Feb 2017 16:57:00 -0800 (PST)
Received: from [192.168.178.21] ([118.148.112.221]) by smtp.gmail.com with ESMTPSA id i21sm9542625pfi.94.2017.02.15.16.56.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 16:56:59 -0800 (PST)
To: Michael Richardson <mcr+ietf@sandelman.ca>, consultancy@vanderstok.org
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>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <a34ff612-edef-630a-7074-e095467a9f69@gmail.com>
Date: Thu, 16 Feb 2017 13:57:02 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <20582.1487174374@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/-k7XZ7oViW0mI0cAqZXdpufgLVU>
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: Thu, 16 Feb 2017 00:57:02 -0000

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>ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> Anima-bootstrap@ietf.org
> https://www.ietf.org/mailman/listinfo/anima-bootstrap
>