Re: [Anima-bootstrap] [6tisch-security] developments on 6tisch join scheduling

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 12 September 2016 12:45 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 97BD712B275; Mon, 12 Sep 2016 05:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.409
X-Spam-Level:
X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 aC8jrE1aG3rV; Mon, 12 Sep 2016 05:45:00 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6481512B0FF; Mon, 12 Sep 2016 05:44:59 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D5E892009E; Mon, 12 Sep 2016 08:57:30 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 404146392D; Mon, 12 Sep 2016 08:44:58 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: tisch-security <6tisch-security@ietf.org>, "anima-bootstrap\@ietf.org" <anima-bootstrap@ietf.org>
In-Reply-To: <1ed0a6c6bbbe481fab1bc1c6e36c53d2@XCH-RCD-001.cisco.com>
References: <24944.1471387601@obiwan.sandelman.ca> <1ed0a6c6bbbe481fab1bc1c6e36c53d2@XCH-RCD-001.cisco.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 12 Sep 2016 08:44:58 -0400
Message-ID: <31666.1473684298@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/695zff-bbnazdM2Uw2GzqJroEhk>
Subject: Re: [Anima-bootstrap] [6tisch-security] developments on 6tisch join scheduling
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: Mon, 12 Sep 2016 12:45:01 -0000

{after some days in the drafts queue}

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > About your subdivision:

    > One may note that to root sees it all, and it the ultimate limit of the
    > bandwidth that may be given to join process.

Yes. Very much agreed, and I want to subordinate all join scheduling to the
limit that the root has established.

    > The bigger the network the slower a given JA can accept new joins. And
    > the deeper the JA, the more overall resources will be consumed by a
    > join.

    > Since this is dynamic and dependent on the network, it may be that we
    > need the root to provide JAs with a MTBJ (mean time between joins) that
    > depends on the rank or something.

Yes, that was essentially my goal.


    > We can wonder if the root itself could be the proxy, being triggered by
    > a DAR message as you described. The root can afford to maintain an EST
    > session.
    > The root would arbitrate when that request is being served. And that
    > the root may instruct in the DAC when the device is entitled to
    > continue its join process.

Yes, this is what I want to do: add something to the DAC that instructions
the new device when it should retry.

    > For this purpose, the DIO may contain new information about root
    > capabilities in the DODAG Configuration option.

I agree that the root ought to have the resources to maintain sessions if
needed, but I don't know if we need that.  The DTLS (or EDHOC) session itself
needs to extend to the new pledge for cryptographic reasons.

    >> What is needed is a way to adjust things so that the pledges will attempt to join
    >> in a way that does not overwhelm the network, and more so, that the proxy
    >> nodes can easily police that they are doing so.

...

    >> This is where the hard part is, how to come up with a simple to describe, and
    >> simple to code algorithm which would fill up the available bandwidth, and be
    >> easily subdividable.

Upon further reflection, I think that the 6LBR shall decide and provide the
interval via the DAC.


--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-