Re: [Anima] Use of M_FLOOD for discovery of Proxy

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 08 July 2017 01:48 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 B9A5C131466 for <anima@ietfa.amsl.com>; Fri, 7 Jul 2017 18:48:11 -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 AvnSRuoJRU_b for <anima@ietfa.amsl.com>; Fri, 7 Jul 2017 18:48:09 -0700 (PDT)
Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 D7A3E129B16 for <anima@ietf.org>; Fri, 7 Jul 2017 18:48:09 -0700 (PDT)
Received: by mail-pg0-x242.google.com with SMTP id u36so5818520pgn.3 for <anima@ietf.org>; Fri, 07 Jul 2017 18:48:09 -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=H02bN+ZMLzjyvpEaiBeNMdTDPXSQzJI1cztn+Zd9mCg=; b=J7NR1j7XVqD+h1T7ndsQL8Z4hmXr4xMe5wHcsV9mTLDaBF3NVn09O8EvfhnymdwMHz oF8H5TWhbD0vm+iB0xTdVMN/1+GdE8qJXZ64ggMHVciqox5n36HkBzbDXH6HNQxoA2kq sadaT1H1RtmduuIv6prE8aQpKUOL5KK65j1U74L5yWO9VyiptdKi1ThWdqAfCP96y9gu cqLNWF+/NtDYb9lAX2UTH/vtwMN4n0gT4JZl6K0A17WbKcxIyWqoiWwsbBxVOVxo5Sbm EinE4unShvPr9uBlYXuVBJCoWCG10aOWYJhxy15kBzISpCcEws/jbUmVP1M29nL7Wns/ phhg==
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=H02bN+ZMLzjyvpEaiBeNMdTDPXSQzJI1cztn+Zd9mCg=; b=bdO+aJzaYQKNSiMdOqCz54jqeHY7v0qL61V3GNleaEH6zfhhO+eT/bqPjfw1lAY+nM 9QP2e+Wj3roZzHyXeWDrt4TVhMjVMUo/HxZs4pQmz9PxL8Eisl1Tbc2fNCcn55XesWcs 5x6dcI0Sp9mJ6LFK44uyk65MyX7IY3L9rjrAQyMzbByXgSK93XkGHK6uSM8616zVcT21 vvTd8RLVFrRJs22uoE3WjE4sGnc5CvHWAFTC3hE6PXnOqgaIlzxQJGI/wmr/jAPC9SJa BlqdLeNTWlHGFjQVyr56o2/zehZ4Vr8msrQIKOYAnP8kGkLqcWOreKi+Q8GHG7D1suIq KM3g==
X-Gm-Message-State: AIVw113hDOXZsza8JjX08qpXaUQxBUe4QlGyZPVhf+TpnrEQY1zd7rFq P18VqYqaFoJRN4wq
X-Received: by 10.84.128.74 with SMTP id 68mr6057497pla.236.1499478489191; Fri, 07 Jul 2017 18:48:09 -0700 (PDT)
Received: from ?IPv6:2406:e007:6d62:1:28cc:dc4c:9703:6781? ([2406:e007:6d62:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q3sm2754322pfk.8.2017.07.07.18.48.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jul 2017 18:48:08 -0700 (PDT)
To: Toerless Eckert <tte@cs.fau.de>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: anima@ietf.org
References: <149566389334.8737.940293315082013190@ietfa.amsl.com> <e24d09bd-9497-3066-7659-895c664bb248@gmail.com> <2540.1497281932@obiwan.sandelman.ca> <20170617000102.GI20021@faui40p.informatik.uni-erlangen.de> <28650.1497805133@obiwan.sandelman.ca> <1dc4daff-5e31-c918-0db4-071f43f3ef9d@gmail.com> <24980.1497879364@obiwan.sandelman.ca> <20170708003910.GA28540@faui40p.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <0198fd68-84d4-e5b6-bd98-29441d2e9dd0@gmail.com>
Date: Sat, 08 Jul 2017 13:48:16 +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: <20170708003910.GA28540@faui40p.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/hjvub6FED-S7186RF9rbfEKhjLo>
Subject: Re: [Anima] Use of M_FLOOD for discovery of Proxy
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: Sat, 08 Jul 2017 01:48:11 -0000

On 08/07/2017 12:39, Toerless Eckert wrote:
> Seems i dropped the ball on these:
> 
> I am not sure i see the crucial need to be able to optimize the number of packets of periodic ACP and BRSKI announcements. 

Sure, unless we plan to flood these at a high rate, it isn't important; but
it's an option that GRASP provides.

> 
> Assume BRSKI, ACP and GRASP are diferent ASAs. We'd need a GRASP API feature to request coalescion of announcement. How would you define that API feature...

If you had a monolithic implementation, it wouldn't be using the API. I think that
was Michael R's model. (Or you could roll up the proxy and the acp logic in a single
ASA, I guess. But I don't think it is a particularly good idea.)

> 
> The idea was to use M_FLOOD for BRSKI because that would allow the pledge to be quiet. Which is more secure because pledge is potentially easy to attack.
> 
> For ACP i also have M_FLOOD in the text because thats the solution with just one message. No need for two-way handshake. 
> 
> Check out brians ani-objective. The alternative to M_FLOOD he lines out are more complicated.

Actually I took them out of the latest (02) version, I think. Just flooding
for ACP and Proxy, and Synchronization for the Registrar. If you want the
Registrar to flood as well, that's easy too. Just tell me.

I'm updating my demo code too, but I was hoping to get the IPIP stuff clarified
first.

    Brian

> 
> Cheers
>     Toerless
> 
> On Mon, Jun 19, 2017 at 09:36:04AM -0400, Michael Richardson wrote:
>>
>> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>     >> If a node doesn't want to announce itself as a proxy, it would omit that
>>     >> objective.
>>     >>
>>     >> As for implementation, I've done it. It's a question of about a page
>>     >> of C
>>     >> code (given a cbor library), or about ten lines of ruby. Probably a
>>     >> similar
>>     >> number of lines of python.
>>
>>     > I'm thinking that if we want to make a tiny extension to GRASP syntax for
>>     > this special purpose, we can do so in the BRSKI document. That's yet
>>     > another benefit of using CBOR.
>>
>>      flood-message = [M_FLOOD, session-id, initiator, ttl,
>>                      +[objective, (locator-option / [])]]
>>
>> You added the +[] there so that we can announce multiple objectives.
>> I don't think that there is anything more to do in GRASP.
>>
>> All we need to do is define the AN_Proxy objective, and ACP has to
>> define the AN_ACP objective.  I just don't see any problem here.
>>
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-
>>
>