Re: [Anima-bootstrap] 6tisch join -01 documented posted

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 27 October 2016 01:00 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 894731294FE; Wed, 26 Oct 2016 18:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 jv_19cUvHK-W; Wed, 26 Oct 2016 18:00:42 -0700 (PDT)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 83C7F1294C0; Wed, 26 Oct 2016 18:00:42 -0700 (PDT)
Received: by mail-pf0-x22f.google.com with SMTP id 197so6144619pfu.0; Wed, 26 Oct 2016 18:00:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jCdbdd+87KlKiabV7KaJYtUCDrJdpsa8O1zpbHByetU=; b=z2MT5ND65YpOCLBJ1g5VWZdE2nf7n9znf7rJBeOLOLT7w8HcWrrciBAIOFbt/3be92 7zautEphB+9houXGSDRSje4ipmBw9qo9tY+Fg/NZ8tdAE/lPzNvOp2o27WB2OkLc+sEC T0Rh35IhYPvZ9oQHdp/3/jaLsMDFODXJnKK3a21zodv8Cu8sogYoRyH+BkPhE88FpLbY H3hfVEnPppzIhhQSRrZL83sJJyro4G3V/I3dc6RuwDIi+hMndBHopZbYEqgrJj6IffyV o2PsQX82KVcB4gSopmkiURtG0FaSOWarf/jjXquG7liNF5seQfXQJMJCAWxIwyxk4aX+ R9YA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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=jCdbdd+87KlKiabV7KaJYtUCDrJdpsa8O1zpbHByetU=; b=mfUynDselkymJTNwr5pNYgCosEHBaOyjcprLIBg1vh3KVNiV225iVHw6JyAVPeiVBs aoPN1YcNinGuk+/Anyv97WwSQIjJpcRFe8WjMKkNY9xKIVr8P6NmGYZCf99w8JqhiJTI oYgcvAGW1JVkiqAYCDcqltF9gJfq+n1Q30mBphuRfHqI9w+RjheSZhn3ptj6fMryw+Hq GGQ47As5xQMLCbCHJAfNBUfKsEdSLw98mJGBBuiUjjmMSj3BCCw0xyHGmIBSt/lN3wAT RmyGZo7uBAy5LoVgYs0I/+Sl6c9gUwmjiza0FfIgahGckRafpTlHRBBSCvrl+uWJIffb sefA==
X-Gm-Message-State: ABUngvcTM0vWklwoSf/pzOGKxz7BlS5EXTAQPbkpAqCeM5PnmJcjSfn/tsWxkoYTt34d8Q==
X-Received: by 10.99.188.1 with SMTP id q1mr7587672pge.145.1477530041873; Wed, 26 Oct 2016 18:00:41 -0700 (PDT)
Received: from ?IPv6:2406:e007:44d7:1:28cc:dc4c:9703:6781? ([2406:e007:44d7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id yz6sm6732590pab.35.2016.10.26.18.00.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Oct 2016 18:00:40 -0700 (PDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>, 6tisch-security <6tisch-security@ietf.org>
References: <20351.1476971471@obiwan.sandelman.ca> <0343d14c-5b18-b821-c9ad-d77fb7dae490@gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <12808a8a-5de1-c6cb-3f96-945573041ee4@gmail.com>
Date: Thu, 27 Oct 2016 14:00:44 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <0343d14c-5b18-b821-c9ad-d77fb7dae490@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/V0YR8bbz3-tB8uyYDPJPQjL6z6k>
Cc: anima-bootstrap <anima-bootstrap@ietf.org>
Subject: Re: [Anima-bootstrap] 6tisch join -01 documented posted
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, 27 Oct 2016 01:00:44 -0000

Hi Michael,

I said: TL;DR;WRL (will read later)

Well, now is "later". Two comments:

1. I seemed to recall from various corridor discussions in Berlin that
the anima-bootstrap preference was for a GRASP flooding model. However,
I have no strong preference; and in fact your approach could make more use
of GRASP than the flooding approach. But for discussion, here's the way
a flooded objective would look (i.e. the registrar floods it out to all
potential proxies (= Join Assistants).

objective = ["AN_Registrar", objective-flags, loop-count, [radius, priority, weight, method]]

method /= "BRSKI_TLS"
method /= "BRSKI_COAP"

radius = 0..255 ; the initial loop-count, so that the recipient can calculate
                ; the distance by subtraction

priority =      ; same semantics as mDNS priority
weight =        ; same semantics as mDNS weight

The IP address, protocol and port are supplied as part of the M_FLOOD message
(sorry, people who aren't familiar with draft-ietf-anima-grasp-07
won't get that).

My model was that the proxy would get all the floods available and choose
the one it liked best, based on the available method and distance, using the
weight and priority as for mDNS. (Personally I think the mDNS stuff is overkill,
but Toerless suggested we should be feature-equivalent.)

That's what is coded in Python at https://www.cs.auckland.ac.nz/~brian/graspy/brski/

Of course, since it's flooded there is no response, so I was assuming that
the pledge's IID would be part of the first actual BRSKI message.

2. Your CDDL looks OK to me. The format and semantics of the value field of
a GRASP objective are completely flexible, so I don't see a problem with
the first "request" to the Registrar being [IID, join-method]. The reply
from the registrar could be [IID, another-join-method] if it didn't like
the first one proposed. Once either side receives a join-method it likes,
it would send [M_END,,[O_ACCEPT]] and we're done.

3. Mini-question, is this really IPv6-specific? If not I'd prefer a name
that flags it as an AN infrastructure objective, e.g. "AN_Join"

Regards
   Brian

On 21/10/2016 08:38, Brian E Carpenter wrote:
> On 21/10/2016 02:51, Michael Richardson wrote:
> ...
>> b) https://datatracker.ietf.org/doc/draft-richardson-anima-6join-discovery/
>>    I wrote this document to reference from secure-join to explain the GRASP
>>    query that the Join Assistant will do to inform the Registrar about a new
>>    pledge.
>>
>>    I think that this document goes into draft-ietf-anima-bootstrapping-keyinfra.
>>
>>    Based upon some feedback on the anima list about how M_NEGOTIATE works,
>>    there are some major things wrong in this document when it comes to how an
>>    ANIMA Join Assistant would discover the *EST* port of the Registrar.
> 
> TL;DR;WRL (will read later)
> 
> I think you could look at my BRSKI toys (in Python) without needing to look at
> my actual GRASP code. They express my understanding of the options.
> 
> https://www.cs.auckland.ac.nz/~brian/graspy/brski/
> start with the README
> 
> Regards
>    Brian
>