Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 21 February 2017 19:45 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 443661294D0 for <anima-bootstrap@ietfa.amsl.com>; Tue, 21 Feb 2017 11:45:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001, WEIRD_PORT=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 nLJBpLqU00Mr for <anima-bootstrap@ietfa.amsl.com>; Tue, 21 Feb 2017 11:45:17 -0800 (PST)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 9D8D3129CA3 for <anima-bootstrap@ietf.org>; Tue, 21 Feb 2017 11:44:49 -0800 (PST)
Received: by mail-pg0-x234.google.com with SMTP id z128so2859672pgb.0 for <anima-bootstrap@ietf.org>; Tue, 21 Feb 2017 11:44:49 -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=ARIXWSK4d+qgGUiVbCn8laQHSPaqih0BGfpSzGFsz64=; b=XhP3HvPXd347jzqBZgL2GGgO8nGAcMV35/NFFNtwBWymEn6gS/uw61OdO6fGE15JrA taw/H/DWUcaMow5o4X6Fkb5O01MvU8Tav0z65+OtER1mruiJsfEZGhGOBmFrG7WjeIhl l5X8sG1U1AbkNw5AOiPZouVDuBjUpI3SmCR5GPeuHFzbMmWWpGoZHNPMPYrrSpTsF+d4 Dz+VBw5NJ3xpXZFV1CBHb5u4g4x0RHwgzvhmd8+reKoeqhTehNwvZA34VRww70fEl/bD heCjDJSPSkOmiFHtDhwIIMYNieSzN/Nv1XOnVuM6OjtwKILnHYlO77xFSfzYkTHydLM4 obFA==
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=ARIXWSK4d+qgGUiVbCn8laQHSPaqih0BGfpSzGFsz64=; b=QSpjAoD1wzQVrqo6x13rnb5sgHWVj22T0VvGkippnfKNV2hZ1WMhEFANVQgUd0oT7P iPpzkV6cp62v1mjhqauH+MBZoFaTlvjPDsMQfm2EMGdZUZdgqE89CosTv9RzJRLN+0Dd RQ02ApKCAeTO/v6ZNerEDcAMpwrLCDC/2ntDmxz/ICxZOaU+yyolWrxHldAkBBEGL+Xt P25Cz/qsGFJ9v9mZE0tgcwgzSPpJgbZmvImGxBIEH9Ysfh/jwHWMREqR4mS4/zMSTlEn HPGmWvM7olz909fUaOX0qJIjhiTpBa4QoNQiXkwZHVHFbUAxQxvZRBdNHhHH2J/NvMwY 3acw==
X-Gm-Message-State: AMke39mIR7MhSy6FZvD1pikJ0Z5veMr888i9mT+H+chxxEZyHFfNOzc/8aWaNK19mVUzbw==
X-Received: by 10.99.109.4 with SMTP id i4mr2571821pgc.11.1487706288937; Tue, 21 Feb 2017 11:44:48 -0800 (PST)
Received: from ?IPv6:2406:e007:474b:1:28cc:dc4c:9703:6781? ([2406:e007:474b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w16sm42727834pgc.15.2017.02.21.11.44.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 11:44:48 -0800 (PST)
To: Toerless Eckert <tte@cs.fau.de>
References: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <6b414f54-4164-5c9d-390e-30d21f786cca@gmail.com>
Date: Wed, 22 Feb 2017 08:44:49 +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: <20170221155002.GA8168@faui40p.informatik.uni-erlangen.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/iVZ5ZDsi991YZe8JKXdkHf4z-Mc>
Cc: anima-bootstrap <anima-bootstrap@ietf.org>
Subject: Re: [Anima-bootstrap] Brian: GRASP parameter for registrar discovery by proxy
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: Tue, 21 Feb 2017 19:45:19 -0000

Hi Toerless,

First of all, did you look at draft-carpenter-anima-ani-objectives-01
and https://www.cs.auckland.ac.nz/~brian/graspy/brski/ ?

I am not defending the details in those but they do indicate what's
possible with GRASP, and how I think this could be solved.

More below:

On 22/02/2017 04:50, Toerless Eckert wrote:
> Hi Brian
> 
> In the anima bootstrap meeting we tried to figure out the necessary
> GRASP message elements for discovery of registrars by proxies. And make
> it extensible.
> 
> If you check:
> 
> http://etherpad.tools.ietf.org:9000/p/anima-boostrapping?useMonospaceFont=true
> 578 - 608

That seems to go back to using discover/response. Wrong answer, IMHO; flooding
is simpler: fewer messages and richer semantics. I'm going to assume that below. 

> We may have a bunch of different possible proxy behaviors:
> 
>   - TCP circuit proxy in conjunction with HTTPs
>   - UDP proxy in conjunction with CoAP
>   - IPinIP proxy in conjunction with either HTTPs or CoAP

Sure. In the above, these are what I call the "method" amd they would be
defined by a text string name, which makes it easy to add new ones.
They could be anything; in my examples I used "BRSKI-TLS" and "BRSKI-COAP"
but "tcp-circuit" etc would work fine too. Whatever you want.
 
> MichaelR's text was currently suggesting to indicate in the GRASP message
> what the registrar supports via the locators:
> 
>     locator1  = [O_IPv6_LOCATOR, fe80::1234, 6,  <any,eg:443>]
>     locator2  = [O_IPv6_LOCATOR, fe80::1234, 17, <any,eg:5683>]
>     locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]
> 
> The first line would indicate TCP circuit proxy, the second UDP proxy,
> the third one IPinIP proxy.
> 
> I am quite uncomfortable to indicate the desired proxy behavior
> purely via the IP protocol field in a locator (6, 17, 41). It already
> is IMHO underspecified,  eg: unclear why the UDP proxy would (only) support
> CoAP, and what actually the IPinIP stack supports (CoAP, HTTPs, ...).

Correct. It's insufficient because it cannot separate the upper layer cases.

(Also, using link-local examples is an oversight, surely: this should
be an ACP address, e.g. fdab:dead:beef::1234, I think.)

> So, how/where would we most easily indicate the stack in the GRASP
> response ? For example:
> 
>     locator1  = [O_IPv6_LOCATOR, fe80::1234, 6,  <any,eg:443>, tcp-circuit]
>     locator2  = [O_IPv6_LOCATOR, fe80::1234, 17, <any,eg:5683>, coap-udp]
>     locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil, tcp-ip-in-ip]
>     locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil, coap-ip-in-ip]

No, that would be a protocol change by adding an extra field to the locator
syntax. However, this is already covered by a feature of the Flood message
which we added a while back. Each item in a flood message is optionally associated
with its own locator:

flood-message = [M_FLOOD, session-id, initiator, ttl, 
                 +[objective, (locator-option / [])]]

so we'd send several copies of the objective, each with its own "method"
and locator.

So for example we'd flood 
the objective ["AN_join_registrar", F_NEG, 6, ["tcp-circuit"]]
with locator  [O_IPv6_LOCATOR, fdab:dead:beef::1234, 6, 443]
and an objective ["AN_join_registrar", F_NEG, 6, ["coap-udp"]]
with the locator [O_IPv6_LOCATOR, fdab:dead:beef::1234, 17, 5683]

The could be sent all in one Flood message, or in separate ones,
possible from different sources if there were actually two registrars,

Truly, if you read the draft and eyeball the Python, you can see how it
works.

If you really don't want to use flooding, it gets more tricky. Discovery
alone won't do the trick in a simple way. I know how to do it but it will
involve more messages.

Regards
   Brian

> 
> Thanks!
>     Toerless
>