Re: [Anima] Is this how BRSKI/IPIP works?

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 14 July 2017 20:14 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6EF131940 for <anima@ietfa.amsl.com>; Fri, 14 Jul 2017 13:14:01 -0700 (PDT)
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 tFsBg463Rl1v for <anima@ietfa.amsl.com>; Fri, 14 Jul 2017 13:14:00 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 1975E1319B4 for <anima@ietf.org>; Fri, 14 Jul 2017 13:13:59 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id e7so50185301pfk.0 for <anima@ietf.org>; Fri, 14 Jul 2017 13:13:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8z2UqDfy2TZ1/IFPbBPwYG/bEyCkTvfRW8rNIdgRuiM=; b=EuEPkmsPv404Kq82OAQKT93NfHyGPDjRFA44Su837dmFotxSB6naXJlTx+JDZEscyG t20N5GGfnCcTe7qP+Ir1D0qQvv7wFcptwrJEcAd9dR/EbwfM2LMnoUhtXwOnUXlyE4T4 K+/kFcNTef/2LFVksMZxHRFvmao/a8sqzezVALO99VYVks6ukDGhg1LwFZ7GGyY+pyxU HiA1lwj06jrQ6kc69aprKCwi0IsJz2ekJM5AIqX70SH8yFp5wlmbud8bA96U/qGQxrVi KNVZ7WkI9LhqxHhwEm74tbIsa69qkg0Hva2cOp01sBFlTegi7vGUIEjpFLgB5QgQv0+9 BT8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=8z2UqDfy2TZ1/IFPbBPwYG/bEyCkTvfRW8rNIdgRuiM=; b=VixGDoP9WiwPjzfxEtFWsONkh5lDEM/w1kdQyiGLHgxUeA8HHUsRdt3wDNmOxncsdI BYJl480p3U6zR/rfNgdMs4MPre9W4d2xxxxtmWyfYTe1G/PEXOLW3pGRON++YYw+0aDP DlM766leh3a6x/e9qIBNhngAVINGKiWbZjO9pF/QA8JPMwqQEaEYSAzrgNgo7tIO+uAt cSogydbNi4lmBeL02JLnz2rHAl1d4bX3JrqVPTycB/eh75zbus4sDMa90HMiEO/LYm6J lFlbt90j7hP/8PA6E6pT+4iBnSLdgdF2VonkcTHuv49LBI7k5QFekKJZ7K7s7ptP0C2m YcGw==
X-Gm-Message-State: AIVw110Dz6oZNvLxHc3BK+Miv/KYt0VQSNMEotges2EFKoZ4+nYMxktW emOg8rNdD3U1Yw1a
X-Received: by 10.84.178.129 with SMTP id z1mr17624189plb.260.1500063239395; Fri, 14 Jul 2017 13:13:59 -0700 (PDT)
Received: from ?IPv6:2406:e001:55f4:1:28cc:dc4c:9703:6781? ([2406:e001:55f4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p5sm17123208pgf.50.2017.07.14.13.13.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 13:13:58 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, Eliot Lear <lear@cisco.com>
Cc: Toerless Eckert <tte@cs.fau.de>, Anima WG <anima@ietf.org>
References: <467b3a9b-6fe0-c01f-6165-18e6e290a28c@gmail.com> <20170706033719.GF14122@faui40p.informatik.uni-erlangen.de> <827f69e7-4730-7bd2-c0ac-987e94adc61d@gmail.com> <20170706070938.GG14122@faui40p.informatik.uni-erlangen.de> <c885cdc9-0ec9-98fd-858d-07c66bb84e25@cisco.com> <9854.1500037758@dooku.sandelman.ca>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <a3e62089-a035-f38e-2907-efa78975bbb9@gmail.com>
Date: Sat, 15 Jul 2017 08:14:04 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <9854.1500037758@dooku.sandelman.ca>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/FM9WewNU9EiNRh5kn8Y2TO1mq3U>
Subject: Re: [Anima] Is this how BRSKI/IPIP works?
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jul 2017 20:14:02 -0000

On 15/07/2017 01:09, Michael Richardson wrote:
> 
> Eliot Lear <lear@cisco.com> wrote:
>     > On 7/6/17 9:09 AM, Toerless Eckert wrote:
>     >> On Thu, Jul 06, 2017 at 04:34:05PM +1200, Brian E Carpenter wrote:
>     >>> It used to be, but the recommendation today is a pseudo-random
>     >>> value (RFC7217). In any case it's a software choice.
> 
>     >> brand new recommendations do not equate to be expected
>     >> standard practice in products. Would be very good to have
>     >> folks with practical insight into various products to
>     >> provide more information.
> 
>     > On this point, I think it's quite likely that we will see a good number
>     > of devices fielded that will do a lousy job of PRNG, and so it would be
>     > inadvisable for them to implement RFC7217, lest they test their DAD code
>     > in ways not really intended.  I'm not thinking about iPhones here, but
>     > energy harvesting devices like some light switches, and a bunch of,
>     > well,... crap.
> 
>     > The question is whether you should design for these devices.  IMHO "no"
>     > is a perfectly valid answer, but I'm still a bit skeptical about the
>     > value of 7217 for these class of devices in any event.
> 
> 1) Constrained devices are out of scope for ANIMA.

True, but let's not use that as an excuse, because our stuff
might just get used more widely.

> 2) even if they were in scope, kinetic powered light switches are not
>    good candidates for join proxies.  Light bulbs, however.

But On 14/07/2017 18:13, Eliot Lear wrote:
...
> I made my comment in the context of a possible interface collision in
> your diagram.  Those had to do with the autonomic nodes, not the
> proxies, as I understand things.  To avoid those sorts of collisions, it
> seems like using the h/w address remains sensible.  A collision in those
> circumstances would be extremely unlikely, whereas relying on poor PRNG
> almost assures it of happening.  These devices are likely to have very
> little entropy available to them.

And they may well be BRSKI pledges, just not using GRASP for discovery.
So Eliot's point seems valid (but not an issue for ANIMA alone).

    Brian